Order-to-Cash 청구 및 청구서 발행 데이터 템플릿
Order-to-Cash 청구 및 청구서 발행 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- SAP S/4HANA 데이터 추출 안내
Order-to-Cash 청구 및 청구서 발행 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 송장 번호 InvoiceNumber | 청구 문서를 고유하게 식별하는 번호로, 송장 발행 프로세스의 기본 케이스 식별자로 사용됩니다. | ||
| 설명 SAP에서 청구 문서 번호라고도 하는 송장 번호는 각 청구 거래를 고유하게 식별합니다. 송장 생성과 전기부터 입금 및 대사까지 관련 활동을 연결하는 기준이 됩니다. process mining에서는 케이스를 연결하는 데 필수적인 속성입니다. 송장 번호가 같은 이벤트를 하나의 프로세스 인스턴스로 묶어 송장별 전체 청구 주기를 분석할 수 있습니다. 이를 통해 처리 시간을 추적하고, 편차를 찾아내며, 각 송장의 진행 과정을 분석할 수 있습니다. 중요한 이유 관련된 모든 청구 활동을 하나의 케이스로 연결하는 기본 식별자로, 프로세스 전체를 분석할 수 있게 합니다. 확보 방법 SAP 테이블: VBRK, 필드: VBELN 예시 900012349000567890009012 | |||
| 이벤트 시간 EventTime | 활동이나 이벤트가 발생한 정확한 시각을 나타내는 타임스탬프입니다. | ||
| 설명 이벤트 시간은 각 활동의 날짜와 시각을 기록해 프로세스의 시간 순서를 구성합니다. 청구 프로세스의 단계별 소요 시간, 전체 처리 시간, 대기 시간을 계산하는 데 필요한 정보입니다. 분석에서는 활동을 시간순으로 정렬하고, 매출채권 회수일수와 송장 발행 주기 같은 KPI를 계산하며, 시간에 따른 병목을 찾아내는 데 사용합니다. 이를 통해 프로세스 성과가 시간에 따라 어떻게 달라지는지, 청구 주기의 각 단계에 얼마나 걸리는지 확인할 수 있습니다. 중요한 이유 이벤트의 시간 순서를 제공하므로 처리 시간이나 소요 시간 등 시간 기반 지표를 계산하는 데 필수적입니다. 확보 방법 활동에 따라 생성일과 생성 시간(VBRK-ERDAT, VBRK-ERZET), 변경 타임스탬프(CDHDR-UDATE, CDHDR-UTIME), 전기일(BKPF-BUDAT) 등 여러 날짜 및 시간 필드에서 추출합니다. 예시 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| 활동명 ActivityName | ‘송장 생성’이나 ‘입금’처럼 청구 프로세스에서 발생한 업무 활동 또는 이벤트의 이름입니다. | ||
| 설명 활동명은 청구 주기의 특정 단계나 주요 시점을 나타냅니다. 트랜잭션 코드, 문서 상태 변경, 특정 로그 항목 등 SAP의 여러 데이터에서 활동을 도출해 순차적인 프로세스 흐름을 구성합니다. 활동의 순서와 빈도를 분석하는 것이 process mining의 기본입니다. 이를 통해 프로세스 맵을 시각화하고, 일반적이거나 드문 프로세스 변형을 찾아내며, 단계 사이의 병목을 식별할 수 있습니다. 재작업이나 취소처럼 부가가치를 만들지 않는 활동의 빈도도 측정할 수 있습니다. 중요한 이유 프로세스의 단계를 정의해 프로세스 맵을 시각화하고 흐름, 변형, 병목을 분석할 수 있게 합니다. 확보 방법 트랜잭션 코드(SY-TCODE), 변경 문서 상태(CDHDR/CDPOS 테이블), 업무 워크플로 로그(예: SWW_WI2OBJ) 등 여러 출처에서 도출합니다. 예시 송장 생성송장 회계 전기고객 입금송장 취소 | |||
| 고객명 CustomerName | 송장을 발행한 고객의 이름입니다. | ||
| 설명 청구 대상 고객의 법인명을 식별합니다. SAP의 중앙 고객 마스터 데이터에서 가져옵니다. 고객별로 프로세스를 분석하면 특정 계정의 패턴을 파악할 수 있습니다. 예를 들어 지속적으로 지급이 늦는 고객, 이의 제기가 잦은 고객, 청구 프로세스가 비효율적인 고객을 확인할 수 있습니다. 이를 바탕으로 고객 관계 관리와 채권 회수 전략을 맞춤화할 수 있습니다. 중요한 이유 고객별 지급 행태, 이의 제기 빈도, 프로세스 비효율을 파악할 수 있습니다. 확보 방법 고객 마스터 데이터 테이블 KNA1의 NAME1 필드에서 가져오며, 송장 헤더의 지급인 ID(VBRK-KUNRG)를 통해 연결합니다. 예시 스프링필드 발전소퀵이마트사이버다인 시스템즈 | |||
| 사용자 이름 UserName | 활동을 실행한 직원의 사용자 ID입니다. | ||
| 설명 송장 생성, 문서 전기, 입금 반제 등의 이벤트를 담당한 SAP 사용자 ID를 기록합니다. 프로세스 단계와 이를 수행한 개인 또는 팀을 연결합니다. 사용자 이름별로 분석하면 성과가 높은 사용자, 교육이 필요한 영역, 업무량 불균형을 파악할 수 있습니다. 주요 활동의 수행자를 확인하는 규정 준수 분석에도 중요하며, 사용자마다 같은 프로세스를 어떻게 다르게 수행하는지 이해하는 데 도움이 됩니다. 중요한 이유 프로세스 활동을 특정 사용자와 연결해 개인 또는 팀 단위로 업무량, 성과, 규정 준수를 분석할 수 있습니다. 확보 방법 생성 이벤트의 경우 VBRK-ERNAM에 기록됩니다. 이후 변경 사항은 CDHDR-USERNAME과 같은 변경 이력 테이블이나 워크플로 로그에서 확인할 수 있습니다. 예시 CBURNSHSIMPSONLLEONARD | |||
| 송장 금액 InvoiceAmount | 송장의 총 순액입니다. | ||
| 설명 세금을 제외한 청구 상품 또는 서비스의 총 금액입니다. 각 송장 케이스의 기본 재무 데이터입니다. 송장 금액을 기준으로 프로세스를 구분해 고액 송장이 다르게 처리되거나 더 자주 지연되는지 확인할 수 있습니다. 재무 보고와 미결 매출채권 총액 계산의 기준으로도 사용됩니다. 중요한 이유 송장별 재무 가치를 수치화해 금액별 분석, 채권 회수 우선순위 설정, 재무 영향 평가를 지원합니다. 확보 방법 SAP 테이블: VBRK, 필드: NETWR 예시 1500.0025000.50125.75 | |||
| 송장 날짜 InvoiceDate | 고객에게 송장을 발행한 공식 날짜입니다. | ||
| 설명 SAP에서 청구일이라고도 하는 송장 날짜는 여러 재무 계산의 기준이 됩니다. 지급 조건과 만기일, 매출채권의 경과 기간을 산정하는 날짜입니다. 재무 분석에서 케이스별로 관리해야 하는 중요한 속성입니다. 매출채권 회수일수(DSO) KPI와 미결 송장 경과 기간 보고서를 계산하는 기준이며, 현금 흐름과 채권 회수 관리에 필수적인 자료입니다. 중요한 이유 DSO, 지급 만기일, 송장 경과 기간 분석의 기준이 되는 재무 계산의 주요 날짜입니다. 확보 방법 SAP 테이블: VBRK, 필드: FKDAT 예시 2023-03-202023-04-012023-05-18 | |||
| 종료 시간 EndTime | 활동이나 이벤트가 완료된 시점을 나타내는 정확한 타임스탬프입니다. | ||
| 설명 종료 시간은 활동이 완료된 시점을 나타냅니다. process mining에서는 해당 케이스의 다음 활동 시작 시간으로 추정하는 경우가 많으며, 시스템에서 시작과 종료 이벤트를 모두 기록한다면 종료 시간을 직접 가져올 수도 있습니다. 이 속성은 개별 활동의 처리 시간을 계산하는 데 필요합니다. 종료 시간에서 시작 시간을 빼면 각 단계에 걸린 시간을 측정할 수 있습니다. 이를 통해 청구서 승인 단계의 지연과 같은 병목을 분석할 수 있습니다. 중요한 이유 각 활동의 정확한 소요 시간인 처리 시간을 계산할 수 있어 병목 분석에 필요한 정보를 제공합니다. 확보 방법 process mining에서 파생되는 속성입니다. 일반적으로 케이스 순서상 다음 이벤트의 StartTime을 사용해 계산합니다. 일부 환경에서는 특정 테이블에 완료 시간이 기록될 수 있습니다. 예시 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| 지급 만기일 PaymentDueDate | 고객이 송장 대금을 지급해야 하는 날짜입니다. | ||
| 설명 지급 만기일은 송장 날짜와 합의된 지급 조건을 기준으로 계산합니다. 송장이 연체되기 전에 대금을 받아야 하는 기한입니다. 채권 회수 효과를 모니터링하고 현금 흐름을 예측하는 데 필요한 속성입니다. 정시 지급률 KPI 계산과 경과 기간 보고서의 송장 분류에 직접 사용됩니다. 만기일과 실제 지급일의 차이를 분석하면 지급 조건별 효과를 평가할 수 있습니다. 중요한 이유 고객의 지급 기한을 정하는 날짜로, 정시 지급률 계산과 매출채권 관리에 중요합니다. 확보 방법 이 날짜는 직접 저장되지 않습니다. SAP의 표준 날짜 산정 기능을 사용해 송장 날짜(VBRK-FKDAT)와 지급 조건 키(VBRK-ZTERM)를 기준으로 계산합니다. 예시 2023-04-192023-05-012023-06-17 | |||
| 지역 Region | 고객의 지리적 지역입니다. | ||
| 설명 지역 속성은 고객 주소에 연결된 주나 도 등의 지리적 영역을 나타냅니다. 일반적으로 고객 마스터 레코드에 포함됩니다. 지역별 청구 성과 대시보드의 주요 속성입니다. 지역별 처리 시간, 오류율, DSO 등 주요 지표를 비교할 수 있습니다. 이를 통해 프로세스 실행, 규정 준수, 효율성의 지역별 차이를 파악하고 개선과 우수 사례 표준화를 추진할 수 있습니다. 중요한 이유 지역별 청구 성과를 비교해 차이를 파악하고 프로세스를 표준화할 수 있습니다. 확보 방법 고객 마스터 데이터 테이블 KNA1의 REGIO 필드에서 가져오며, 송장 헤더의 지급인 ID(VBRK-KUNRG)를 통해 연결합니다. 예시 캘리포니아뉴욕텍사스바하 | |||
| 기한 내 지급 여부 IsPaidOnTime | 청구서 대금이 지급 기한 당일 또는 그 전에 지급되었는지를 나타내는 불리언 플래그입니다. | ||
| 설명 실제 지급일과 예정된 지급 기한을 비교해 계산하는 속성입니다. 기한 내에 지급되면 'true', 늦게 지급되면 'false'로 표시됩니다. 이 플래그를 사용하면 기한 내 지급률 KPI를 쉽게 계산하고 시각화할 수 있습니다. 기한 내 지급된 청구서와 연체된 청구서를 간편하게 필터링하고 분류해 특성을 비교할 수 있습니다. 이를 통해 특정 고객, 지역 또는 지급 조건과 연체의 연관성을 파악할 수 있습니다. 중요한 이유 각 청구서가 기한 내 지급되었는지 연체되었는지 명확히 표시해 성과 측정을 간소화하고, 기한 내 지급률 KPI 산출을 지원합니다. 확보 방법 계산 필드입니다. 'Customer Payment Received' 활동의 타임스탬프를 'PaymentDueDate' 속성 값과 비교합니다. 예시 truefalse | |||
| 대변 메모 사유 CreditMemoReason | 대변 메모 발행 사유를 나타내는 코드입니다. | ||
| 설명 청구서에 오류가 있어 대변 처리해야 하는 경우, 대변 메모 문서에 보통 사유를 지정합니다. 이를 통해 청구 오류의 원인을 일관된 기준으로 분류할 수 있습니다. 이 속성은 청구 오류율 KPI 산출에 직접 활용됩니다. 대변 메모 사유를 집계하고 분석하면 가격 오류나 제품 반품처럼 자주 발생하는 오류 유형을 파악할 수 있습니다. 분석 결과를 바탕으로 재무 조정과 재작업을 줄이는 프로세스 개선을 추진할 수 있습니다. 중요한 이유 대변 처리 사유를 분류해 청구 오류가 자주 발생하는 원인을 찾고 품질을 개선할 수 있습니다. 확보 방법 SAP 테이블: VBRK, 필드: AUGRU(오더 사유). 이 필드는 이후 청구 처리되는 대변 및 차변 메모 요청에 사용됩니다. 예시 001 - 가격 차이002 - 품질 불량005 - 고객 반품 | |||
| 분쟁 사유 CustomerDisputeReason | 고객이 청구서에 이의를 제기한 사유입니다. | ||
| 설명 고객이 청구서에 이의를 제기하면 그 사유를 기록하는 경우가 많습니다. 가격 오류, 수량 불일치, 상품 파손 등이 사유가 될 수 있습니다. 이 정보는 SAP Dispute Management 모듈이나 텍스트 메모에 저장될 수 있습니다. 분쟁 사유 분석은 청구 오류율 KPI와 관련 오류 분석의 기반이 됩니다. 청구 오류의 근본 원인을 찾아 상위 프로세스의 반복적인 문제를 해결하고, 청구서 품질과 고객 만족도를 높일 수 있습니다. 중요한 이유 청구서에 이의가 제기된 이유를 보여 주므로, 청구 오류와 고객 불만의 근본 원인을 직접 파악할 수 있습니다. 확보 방법 SAP Dispute Management를 사용하는 경우 UDM_DISPUTE와 같은 테이블에서 확인할 수 있습니다. 사용하지 않는 경우 관련 문서의 사유 코드나 텍스트 필드에서 가져올 수 있습니다. 예시 가격 오류수량 불일치상품 파손 상태로 수령 | |||
| 소스 시스템 SourceSystem | 데이터를 추출한 소스 시스템을 식별합니다. | ||
| 설명 데이터의 출처를 지정하는 속성으로, 여러 SAP 인스턴스나 다른 통합 시스템을 사용하는 환경에서 특히 유용합니다. 일반적으로 시스템 ID와 클라이언트 번호가 포함됩니다. 분석 시 시스템이나 조직별 프로세스와 성과를 구분하는 데 도움이 됩니다. 데이터 계보를 확인할 수 있으며 여러 출처의 데이터를 결합해 전체 프로세스를 살펴볼 때 필요한 맥락을 제공합니다. 중요한 이유 데이터 출처를 명확히 해 여러 시스템을 사용하는 환경에서 혼선을 줄이고 데이터 거버넌스를 지원합니다. 확보 방법 일반적으로 데이터 추출 시 지정하는 고정값이며, 시스템 ID(SY-SYSID)와 클라이언트(SY-MANDT)를 조합하는 경우가 많습니다. 예시 S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| 지급 상태 PaymentStatus | 미결, 지급 완료, 연체 등 청구서 대금의 현재 상태입니다. | ||
| 설명 지급 상태를 보면 청구서가 회수 과정의 어느 단계에 있는지 확인할 수 있습니다. SAP의 단일 필드에 저장되는 값이 아니라, 해당 회계 문서의 반제 상태를 확인해 산출합니다. 미수 청구서 경과 기간 대시보드에 필요한 속성입니다. 미결 청구서를 상태와 경과 기간에 따라 분류해 회수 담당자가 업무 우선순위를 정하도록 지원합니다. 상태 간 전환을 추적하면 채권 회수 프로세스 자체도 모니터링할 수 있습니다. 중요한 이유 청구서의 회수 상태를 한눈에 파악할 수 있어, 미수금 관리와 회수 업무의 우선순위 설정에 도움이 됩니다. 확보 방법 BSID(미결 항목) 및 BSAD(반제 항목)와 같은 재무 테이블에서 회계 문서(VBRK-BELNR)의 반제 상태를 확인해 산출합니다. 예시 미결지급 완료연체일부 지급 | |||
| 지급 조건 PaymentTerms | 지급 조건을 정의하는 코드로, 지급 가능 기간 등이 포함됩니다. | ||
| 설명 지급 조건은 고객과 사전에 합의한 조건으로, 청구서 대금의 지급 기한을 정합니다. 예를 들어 'Net 30'은 30일 이내 지급, '2/10 Net 30'은 10일 이내 지급 시 2% 할인, 그렇지 않으면 30일 이내 지급을 뜻합니다. 지급 조건별로 분석하면 각 조건의 효과를 평가할 수 있습니다. 조건별로 실제 대금 수령까지 걸린 시간을 비교하면 어떤 조건이 신속한 지급을 유도하는지 파악하고, 현금 흐름을 개선하도록 조건을 조정할 수 있습니다. 중요한 이유 합의된 지급 일정을 정의하므로, 고객이 기한 내에 대금을 지급하도록 하는 데 어떤 조건이 효과적인지 분석할 수 있습니다. 확보 방법 SAP 테이블: VBRK, 필드: ZTERM 예시 Z030Z060ZB60 | |||
| 청구 문서 유형 BillingDocumentType | 청구서, 대변 메모, 취소 문서 등 청구 문서를 분류하는 코드입니다. | ||
| 설명 청구 문서 유형은 청구 프로세스의 거래를 분류하는 주요 필드입니다. 문서 번호 범위와 회계 전기 규칙을 비롯해 문서 처리 방식을 결정합니다. 이 속성을 사용하면 특정 거래 유형을 필터링해 분석할 수 있습니다. 예를 들어 대변 메모만 별도로 분석해 재무 조정의 사유와 처리 흐름을 파악하거나, 일반 청구서와 취소 문서를 나누어 분석해 기본 청구 프로세스를 더 명확히 살펴볼 수 있습니다. 중요한 이유 거래를 유형별로 분류해 일반 청구서, 대변 메모, 취소 문서 등 특정 문서 흐름을 집중적으로 분석할 수 있습니다. 확보 방법 SAP 테이블: VBRK, 필드: FKART 예시 F2G2S1L2 | |||
| 최근 데이터 업데이트 LastDataUpdate | 이 이벤트의 데이터를 마지막으로 추출하거나 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
| 설명 소스 시스템에서 데이터를 마지막으로 가져온 날짜와 시각을 기록합니다. 분석 대상 데이터가 얼마나 최신인지 파악하는 데 중요한 메타데이터입니다. 분석의 최신성을 확인하고 데이터 새로 고침 일정을 관리하는 데 사용합니다. 프로세스 mining 대시보드와 인사이트를 바탕으로 의사결정을 내릴 때 이해관계자가 데이터의 시점을 확인할 수 있습니다. 중요한 이유 데이터의 최신성을 나타내므로 분석 결과의 신뢰성과 현재 운영 상태에 대한 관련성을 판단하는 데 중요합니다. 확보 방법 데이터 추출 및 적재(ETL) 과정에서 타임스탬프를 생성해 각 레코드에 기록합니다. 예시 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| 통화 Currency | 송장 금액의 통화 코드입니다. | ||
| 설명 USD, EUR, JPY 등 송장 금액에 적용되는 통화를 지정합니다. 모든 금액을 해석하는 데 필요한 정보입니다. 여러 국가에서 사업을 운영하는 조직은 정확한 재무 분석과 보고를 위해 통화 정보가 필요합니다. 금액을 공통 보고 통화로 환산해 집계하고, 현지 통화가 다른 지역 간 청구 성과를 비교할 수 있습니다. 중요한 이유 모든 금액의 통화를 명확히 해 정확한 재무 분석과 보고를 지원하며, 특히 여러 국가에서 운영하는 조직에 유용합니다. 확보 방법 SAP 테이블: VBRK, 필드: WAERK 예시 USDEURGBP | |||
| 판매 오더 번호 SalesOrderNumber | 청구서 발행의 근거가 된 원래 판매 오더의 식별자입니다. | ||
| 설명 판매 오더 번호를 사용하면 청구 문서를 이전 판매 활동과 연결할 수 있습니다. 하나의 판매 오더에서 청구서가 하나 이상 발행될 수 있으며, 이 연결을 통해 전체 문서 흐름을 확인할 수 있습니다. Order-to-Cash 전 과정을 분석하려면 이 속성이 필요합니다. 청구 단계에서 발생한 문제를 판매 오더 생성이나 이행 단계의 잠재적 원인과 연결해 프로세스 분석 범위를 앞 단계까지 확장할 수 있습니다. 예를 들어 오더 이행 시점부터 청구서 발행까지 걸린 전체 주기를 계산할 수 있습니다. 중요한 이유 청구서를 원래 판매 오더와 연결해 청구 단계에 국한되지 않는 Order-to-Cash 전 과정의 분석을 지원합니다. 확보 방법 SAP 테이블: VBRP(청구 문서 품목 데이터), 필드: AUBEL 예시 100001231000045610000789 | |||
| 회사 코드 CompanyCode | 재무 거래를 기록하는 조직 단위입니다. | ||
| 설명 회사 코드는 SAP Financials의 기본 조직 단위로, 재무제표를 작성하는 법적으로 독립된 회사를 나타냅니다. 각 청구 문서에는 특정 회사 코드가 지정됩니다. 여러 법인으로 구성된 조직에서는 회사 코드별 분석을 통해 프로세스 성과, DSO와 같은 재무 지표, 규정 준수를 비교할 수 있습니다. 모든 프로세스 대시보드에서 조직을 기준으로 상위 수준의 필터링을 제공합니다. 중요한 이유 법인별로 프로세스를 분석해 조직 내 성과를 비교하고 재무 정보를 통합할 수 있습니다. 확보 방법 SAP 테이블: VBRK, 필드: BUKRS 예시 10002000US01 | |||
Order-to-Cash 청구 및 청구서 발행 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 고객 입금 | 고객 입금이 재무 시스템에 전기된 시점을 나타냅니다. 이 단계에서는 입금액이 특정 송장에 아직 적용되지 않았을 수 있지만, 입금 사실은 기록된 상태입니다. | ||
| 중요한 이유 매출채권 회수일수(DSO)를 계산하는 데 중요한 단계입니다. 대사 작업이 남아 있더라도 현금이 입금됐음을 나타냅니다. 확보 방법 고객 입금 문서(일반적으로 BKPF 테이블의 문서 유형 ‘DZ’)의 전기일(BKPF-BUDAT)을 기준으로 수집합니다. 기록 BKPF/BSEG에 입금 문서가 생성된 시점을 기준으로 이벤트를 기록합니다. 이벤트 유형 explicit | |||
| 송장 생성 | 이 활동은 시스템에서 청구 문서가 생성된 시점을 나타냅니다. 사용자가 VF01과 같은 트랜잭션을 실행하거나 백그라운드 작업이 송장을 생성하면 명시적인 이벤트로 기록되며, 청구 문서 헤더 테이블에 새 항목이 추가됩니다. | ||
| 중요한 이유 청구 프로세스의 주요 시작 이벤트입니다. 주문 이행부터 이 활동까지 걸리는 시간을 분석하면 송장 발행 주기를 측정하고 초기 단계의 지연을 파악할 수 있습니다. 확보 방법 청구 문서가 생성되면 SAP S/4HANA의 VBRK 테이블(청구 문서: 헤더 데이터)에 기록됩니다. 생성일(VBRK-ERDAT)과 생성 시간(VBRK-ERZET)이 타임스탬프로 사용됩니다. 기록 VBRK 테이블에 있는 청구 문서 레코드의 생성 타임스탬프를 기준으로 이벤트를 수집합니다. 이벤트 유형 explicit | |||
| 송장 종료 | 정상적으로 대금이 지급된 송장의 최종 상태를 나타냅니다. 기능상 ‘입금 적용 및 대사 완료’와 동일하며, 해당 송장 프로세스가 끝났음을 의미합니다. | ||
| 중요한 이유 정상 경로의 주요 종료 이벤트입니다. 이 시점까지의 전체 처리 시간을 측정하면 청구 및 송장 발행의 전체 주기를 파악할 수 있습니다. 확보 방법 회계 문서의 고객 개별 항목 상태를 기준으로 추론합니다. 반제일(BSEG-AUGDT)과 반제 문서(BSEG-AUGBL) 필드에 값이 있으면 해당 항목은 종료 또는 반제된 상태입니다. 기록 송장 개별 항목에 해당하는 BSEG/ACDOCA 테이블의 반제일(AUGDT)이 입력됐는지 확인해 추론합니다. 이벤트 유형 inferred | |||
| 송장 회계 전기 | 청구 문서가 재무회계 모듈에 정상적으로 전기된 상태입니다. 송장이 공식 매출채권 항목으로 등록되고 총계정원장에 항목이 생성되는 중요한 단계입니다. | ||
| 중요한 이유 이 활동을 통해 송장이 법적 효력을 갖는 재무 문서로 등록됐음을 확인할 수 있습니다. 생성부터 전기까지 걸리는 시간은 내부 처리 효율을 보여주는 주요 KPI입니다. 확보 방법 해당 회계 문서가 생성될 때 이벤트를 수집합니다. 청구 문서(VBRK-VBELN)는 VBRK-BELNR을 통해 회계 문서(BKPF-BELNR)와 연결되며, 전기일은 BKPF-BUDAT에 기록됩니다. 기록 청구 문서와 연결된 BKPF 테이블의 회계 문서 전기일(BUDAT)을 기준으로 수집합니다. 이벤트 유형 explicit | |||
| 입금 적용 및 대사 완료 | 고객 입금을 매칭해 매출채권 보조원장의 미결 송장 항목을 반제한 시점을 나타냅니다. 재무 관점에서 거래가 완료되는 단계입니다. | ||
| 중요한 이유 입금 적용 프로세스의 효율을 측정합니다. 이 단계가 지연되면 고객 계정의 실제 상태가 잘못 표시되고 채권 관리팀의 불필요한 업무가 늘어날 수 있습니다. 확보 방법 원본 송장의 회계 문서 개별 항목에 기록된 반제일(BSEG-AUGDT)을 기준으로 이벤트를 수집합니다. 반제 문서가 항목을 반제하면 이 날짜가 입력됩니다. 기록 송장 개별 항목에 해당하는 BSEG/ACDOCA 테이블의 반제일(AUGDT) 필드에서 수집합니다. 이벤트 유형 explicit | |||
| 고객 이의 제기 등록 | 고객이 송장에 이의를 제기하고 해당 내용이 시스템에 공식 등록될 때 발생하는 활동입니다. SAP Dispute Management 모듈을 사용해야 합니다. | ||
| 중요한 이유 지급 지연을 초래하는 청구 정확성, 제품 품질 또는 서비스 제공 문제를 파악합니다. 이의 제기 사유를 분석하면 근본 원인을 해결하고 고객 만족도를 높이는 데 도움이 됩니다. 확보 방법 회계 문서 개별 항목과 연결된 Dispute Management 테이블(예: UDM_CASE)에 이의 제기 케이스가 생성될 때 기록됩니다. 기록 송장과 연결된 이의 제기 케이스 레코드의 생성 타임스탬프를 기준으로 수집합니다. 이벤트 유형 explicit | |||
| 고객에게 송장 발송 | 인쇄, 이메일 또는 EDI 등을 통해 송장을 고객에게 전송한 시점을 나타냅니다. 이벤트 수집 방식은 SAP의 출력 관리 설정에 따라 달라집니다. | ||
| 중요한 이유 고객 관점에서 대금 지급 기산점이 되는 시점입니다. 송장 발송이 지연되면 매출채권 회수일수(DSO)와 현금 흐름에 직접 영향을 줍니다. 확보 방법 NAST와 같은 출력 제어 테이블(기존 방식)이나 S/4HANA의 이에 해당하는 테이블에 명시적으로 기록될 수 있습니다. 별도 기록이 없다면 ‘송장 회계 전기’와 같은 시점으로 추정하는 경우가 많습니다. 기록 출력 관리 테이블의 처리 로그에서 송장 출력 유형과 연결된 타임스탬프를 확인합니다. 이벤트 유형 explicit | |||
| 대변 메모 생성 | 과다 청구를 수정하거나 반품 상품에 대한 대변을 제공하기 위해 고객에게 발행하는 대변 메모의 생성 활동입니다. 대개 원본 송장과 연결됩니다. | ||
| 중요한 이유 청구 후 재무 조정이 발생한 사례를 파악합니다. 대변 메모를 분석하면 가격 오류, 제품 문제 또는 매출 누수의 다른 근본 원인을 찾을 수 있습니다. 확보 방법 대변 메모 전용 청구 유형(예: ‘G2’)을 사용해 VBRK에 새 청구 문서로 생성됩니다. 원본 판매 주문이나 송장을 참조하는 경우가 많습니다. 기록 대변 메모 청구 유형으로 VBRK에 청구 문서가 생성될 때 수집합니다. 이벤트 유형 explicit | |||
| 송장 전기 차단 | 송장이 생성됐지만 신용 확인이나 데이터 불일치 등의 이유로 재무회계 전기가 자동 차단될 때 발생하는 이벤트입니다. 청구 문서의 전기 상태 필드에서 이 상태를 추론합니다. | ||
| 중요한 이유 송장이 생성된 뒤 재무회계로 즉시 전달되지 않아 전체 현금 회수 주기가 지연되는 병목을 파악합니다. 데이터 품질이나 신용 관리 문제를 나타내는 주요 지표이기도 합니다. 확보 방법 청구 문서 헤더 테이블의 전기 상태 필드(VBRK-RFBSK)를 기준으로 추론합니다. 예를 들어 ‘A’(청구 문서의 FI 전달 차단) 상태는 전기가 차단됐음을 나타냅니다. 기록 송장 생성 직후 전기 상태 필드(VBRK-RFBSK)의 값을 확인해 추론합니다. 이벤트 유형 inferred | |||
| 송장 취소 | 이미 생성된 송장을 취소할 때 발생하며, 일반적으로 이에 대응하는 취소 문서를 생성합니다. 원본 송장과 그 회계 영향을 취소하는 처리입니다. | ||
| 중요한 이유 재작업, 수정 또는 청구 오류를 나타냅니다. 취소가 자주 발생한다면 판매 주문 입력이나 청구 설정의 상위 단계에 문제가 있을 가능성이 큽니다. 확보 방법 취소 청구 문서(예: 문서 유형 ‘S1’)가 생성될 때 수집합니다. VBRK의 새 문서에는 VBRK-SFAKN 필드에 원본 송장 번호가 참조됩니다. 기록 원본 송장을 참조하는 취소 문서가 VBRK에 생성된 날짜를 기준으로 이벤트를 수집합니다. 이벤트 유형 explicit | |||
| 지급 독촉장 발송 | 연체 송장에 대해 고객에게 지급 독촉장이나 연체 안내를 발송하는 활동입니다. 자동 독촉 절차에서 명시적인 이벤트로 생성됩니다. | ||
| 중요한 이유 독촉 프로세스의 효과를 분석할 수 있습니다. 독촉장이 지급을 앞당기는지, 어떤 독촉 단계가 가장 효과적인지 파악하는 데 도움이 됩니다. 확보 방법 송장의 미결 항목에 대해 독촉 실행(Transaction F150)을 수행하면 독촉 이력 테이블(MAHNV, MHND)에 기록됩니다. 기록 독촉 이력 테이블에 기록된 독촉장 실행일을 기준으로 수집합니다. 이벤트 유형 explicit | |||
| 지급 만기일 도래 | 합의된 지급 조건에 따라 송장 대금의 공식 지급 기한이 되는 날짜를 나타내는 계산 이벤트입니다. 거래 이벤트로 직접 기록되는 것이 아니라 송장 데이터를 바탕으로 산출합니다. | ||
| 중요한 이유 정시 지급 성과를 측정하고 고객의 지급 행태를 분석하는 기준이 됩니다. 이를 통해 기한 내 지급과 연체 지급을 구분할 수 있습니다. 확보 방법 지급 기준일(BSEG-ZFBDT)과 회계 문서의 고객 개별 항목에 저장된 지급 조건을 기준으로 계산합니다. 기록 회계 문서 개별 항목(BSEG)의 지급 기준일에 지급 조건의 일수를 더해 산출합니다. 이벤트 유형 calculated | |||
| 청구 재작업 식별 | 송장이 취소된 뒤 같은 판매 주문에 대해 새 송장이 생성되는 재작업 루프를 식별하는 계산 이벤트입니다. 단일 거래가 아니라 여러 이벤트에서 나타나는 패턴입니다. | ||
| 중요한 이유 수정 사례를 수치화해 청구 재작업률 KPI를 직접 측정합니다. 이를 통해 비효율을 찾아내고 청구 프로세스의 품질 저하 비용을 파악할 수 있습니다. 확보 방법 같은 원본 문서(예: 판매 주문 번호)를 참조하는 ‘송장 취소’ 이벤트 뒤에 새 ‘송장 생성’ 이벤트가 이어지는 패턴을 식별해 계산합니다. 기록 같은 판매 주문 참조 번호에 대해 ‘송장 취소’와 ‘송장 생성’이 이어지는 순서를 찾아 산출합니다. 이벤트 유형 calculated | |||
데이터 추출 가이드
단계
- 사전 요건: SAP S/4HANA 사용자 계정과 Core Data Services (CDS) 뷰를 조회하는 데 필요한 권한이 있는지 확인합니다. 특히 I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase, I_DunningHistory 등의 뷰에 대한 읽기 권한이 필요합니다.
- 데이터 추출 도구 이용: SAP S/4HANA 시스템에 로그인합니다. SAP HANA Studio, SAP HANA 클라이언트로 연결한 DBeaver, SAP Analysis for Microsoft Excel 플러그인 등 다양한 도구로 CDS 뷰에 SQL 쿼리를 실행할 수 있습니다. 이 가이드에서는 일반 SQL 클라이언트를 사용한다고 가정합니다.
- 시스템 매개변수 확인: 쿼리를 실행하기 전에 분석 대상 Company Code와 날짜 범위를 확인합니다. 쿼리 실행 시간을 적절히 관리할 수 있도록 최근 3~6개월 데이터처럼 범위를 제한해 시작하는 것이 좋습니다.
- SQL 쿼리 준비: 이 문서의 'query' 섹션에 있는 전체 SQL 쿼리를 복사해 사용할 SQL 클라이언트에 붙여 넣습니다.
- 자리표시자 수정: 쿼리의 자리표시자 값을 수정합니다.
'YYYY-MM-DD'를 원하는 시작일과 종료일로 바꾸고,'XXXX'를 대상 Company Code로 바꿉니다. 시스템 설정에 따라 대변 메모 문서 유형 자리표시자도'G2'등의 값으로 수정해야 할 수 있습니다. - 쿼리 실행: 수정한 SQL 쿼리를 SAP S/4HANA 데이터베이스에서 실행합니다. 실행 시간은 선택한 날짜 범위의 데이터 양에 따라 달라집니다.
- 결과 검토: 쿼리가 끝나면 결과를 확인합니다. 결과는 각 행이 청구 프로세스의 단일 활동을 나타내는 평면 테이블이어야 합니다. 이 데이터가 이벤트 로그입니다.
- 데이터 변환(필요한 경우): 쿼리는 정리된 이벤트 로그 형식으로 결과를 생성하도록 설계되었습니다. 다만 타임스탬프 형식이 사용하는 process mining 도구와 호환되는지 확인합니다. 쿼리는
ABAP_SYSTEM_UTCL_TO_TIMESTAMP를 사용해 표준 UTC 타임스탬프로 변환하므로 대부분의 도구와 호환됩니다. - 이벤트 로그 내보내기: SQL 클라이언트에서 전체 결과를 CSV 파일로 내보냅니다. 문자 인코딩 문제가 발생하지 않도록 UTF-8로 저장합니다.
- ProcessMind에 업로드: 생성한 CSV 파일을 ProcessMind 플랫폼에 업로드하고, InvoiceNumber, ActivityName, EventTime 등의 열을 도구의 해당 필드에 매핑합니다.
구성
- 날짜 범위: 초기 Common Table Expression (CTE)의
WHERE절에서 시작일과 종료일을 설정합니다. 데이터 양과 성능의 균형을 고려해 초기 분석에는 3~6개월 범위를 권장합니다. 필터는BillingDocumentDate에 적용합니다. - Company Code: 하나 이상의
CompanyCode값으로 필터링해 관련 법인만 추출합니다. 데이터 범위를 관리하는 데 중요한 필터입니다. - 문서 유형: 쿼리는
BillingDocumentType을 기준으로 대변 메모를 식별합니다. 조직에서 사용하는 대변 메모 문서 유형에 맞춰('G2', 'CR')와 같은 자리표시자를 설정해야 합니다. - 사전 요건: 해당 CDS 뷰에 접근할 수 있어야 합니다. SAP 보안팀이 부여하는 특정 역할과 권한이 필요합니다. 또한 'Customer Dispute Opened' 또는 'Payment Reminder Issued'와 같은 활동을 추출하려면 SAP Dispute Management 및 SAP Financials Dunning 모듈을 시스템에서 실제로 사용해야 합니다.
- 성능: 쿼리는 여러 테이블을 조인하고 결과를 결합합니다. 데이터가 매우 많다면, 예를 들어 수년 치 데이터를 처리하는 경우 사용량이 적은 시간에 실행하거나 필터를 더 구체적으로 설정해 초기 추출량을 줄이세요.
샘플 쿼리 sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; 단계
- 청구 및 관련 재무 테이블이 있는 SAP HANA 스키마에 직접 읽기 권한이 있는지 확인합니다. 시스템 담당자에게 스키마 이름, 연결 정보, 허용된 날짜 범위, Company Code 범위, 청구 문서 유형, 고객 또는 지역 필터를 확인합니다. 쿼리에서는 연결 및 필터 자리표시자만 바꿉니다.
- 대상 시스템에서 관련 SAP S/4HANA 데이터 소스와 필드 매핑을 확인합니다. 쿼리는 청구 데이터에 VBRK와 VBRP를 사용하며, 회계, 출력 관리, 분쟁 관리, 독촉, 입금, 반제 및 문서 관계에 대한 데이터 소스가 설정되어 있어야 합니다. 대괄호로 표시된 소스 및 필드 자리표시자는 시스템 데이터 사전과 대조해 확인한 후 바꿉니다.
- 시작 타임스탬프는 포함하고 종료 타임스탬프는 제외하도록 추출 기간을 설정합니다. 첫 실행에는 3~6개월 범위를 권장합니다. 데이터 양을 관리하고 서로 관련 없는 청구 프로세스가 섞이지 않도록 Company Code와 필요한 경우 청구 유형으로 범위를 제한합니다.
- 읽기 전용 HANA 데이터베이스 사용자로 쿼리를 실행합니다. 쿼리는 명시적으로 추출한 각 활동에 대해 이벤트 행을 하나씩 생성합니다. ProcessMind가 이벤트를 추론하지 않습니다. Payment Due Date Reached 및 Billing Rework Identified를 포함한 계산 활동은 SQL 로직으로 생성되어 행으로 반환됩니다.
- 반환된 스키마를 확인합니다. 이벤트 로그에는 InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region, EndTime이 포함되어야 합니다. 모든 행에 InvoiceNumber, ActivityName, EventTime 값이 있는지 확인합니다.
- 이벤트의 의미와 관계를 검증합니다. Invoice Generated 행은 청구 헤더 생성 데이터와, Invoice Posted To Accounting 행은 회계 전기 상태와, Invoice Sent To Customer 행은 출력 기록과, 결제 행은 회계 문서와, 반제 행은 반제된 송장 항목과 비교합니다. 운영 환경에 적용하기 전에 자리표시자에 따라 달라지는 모든 구간을 검토합니다.
- ProcessMind에 맞게 결과를 정규화합니다. 이벤트마다 행을 하나씩 유지하고, 타임스탬프 데이터 유형과 시간대를 통일합니다. 앞자리 0을 보존하도록 InvoiceNumber를 텍스트로 유지하고, ActivityName 값이 필수 활동명과 정확히 일치하는지 확인합니다. 같은 시각에 이벤트가 여러 개라면 일관된 보조 정렬 기준을 적용해 InvoiceNumber와 EventTime 순으로 정렬합니다.
- 결과를 UTF-8 CSV 또는 ProcessMind가 지원하는 다른 표 형식으로 내보냅니다. InvoiceNumber는 케이스 식별자, ActivityName은 활동 열, EventTime은 이벤트 타임스탬프로 매핑합니다. 사용 가능한 경우 권장 속성도 포함한 다음, 설정된 ProcessMind 가져오기 절차를 통해 파일을 업로드하고 행 수와 활동 수를 최종 점검합니다.
구성
- 날짜 범위: 처음에는 3~6개월로 시작합니다. 증분 실행 간 이벤트가 중복되지 않도록 시작 타임스탬프는 포함하고 종료 타임스탬프는 제외합니다.
- 케이스 식별자: 청구 문서 헤더의 InvoiceNumber를 사용합니다. SAP 문서 번호에는 앞자리 0이 포함될 수 있으므로 문자열로 보존합니다.
- 필수 활동: 추출 결과에는 Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created, Billing Rework Identified 활동이 명시적인 행으로 포함되어야 합니다.
- 필터: 대상 시스템에서 해당 필드와 업무 범위를 확인한 후 Company Code, 청구 문서 유형, 영업 조직, 고객, 지역 및 날짜 필터를 적용합니다. 모든 청구 문서 유형이 동일한 회계 또는 출력 프로세스를 따른다고 가정하지 마세요.
- 소스 설정: VBRK와 VBRP는 주요 청구 데이터 소스입니다. 회계, 출력, 분쟁, 독촉, 결제, 반제 및 문서 흐름 데이터 소스는 배포된 SAP S/4HANA 버전과 활성화된 모듈에 맞게 설정해야 합니다. 대괄호로 표시된 소스 참조는 확인된 객체와 필드로 바꿉니다.
- 계산 이벤트: Payment Due Date Reached는 지급 조건과 만기일 데이터에서 계산합니다. Billing Rework Identified는 취소 후 새 송장이 생성되는 패턴에서 계산합니다. 이 이벤트는 SQL로 생성한 행이며, 거래 시스템에 원래 기록된 데이터가 아닙니다.
- 성능: 날짜, Company Code, 청구 유형 및 문서 번호 필터를 각 소스 쿼리에 적용합니다. 필요한 열만 선택하고 대규모 회계 테이블을 제한 없이 조인하지 않습니다. 월별 또는 주별로 나누어 처리하고 데이터베이스 실행 계획으로 비용이 큰 조인을 확인합니다.
- 증분 추출: 소스 생성 또는 전기 타임스탬프를 기준으로 안정적인 워터마크를 사용합니다. 늦게 도착하는 출력, 결제, 분쟁 및 반제 기록을 포함하도록 짧은 중복 기간을 다시 처리한 다음 InvoiceNumber, ActivityName, EventTime과 관련 소스 문서 키를 기준으로 중복을 제거합니다.
- 권한: 추출 사용자에게 선택한 HANA 스키마 객체와 필드에 대한 읽기 권한이 필요합니다. 조직의 보안 정책에서 직접 데이터베이스 접근을 허용하는지, 개인정보 및 고객 데이터 처리 요건을 충족하는지 확인합니다.
- 기능상 사전 요건: 출력 관리, 회계 통합, 분쟁 관리, 독촉, 입금 및 반제 데이터는 해당 기능이 시스템에 설정되어 사용 중인 경우에만 제공됩니다. 모듈이나 소스 기록이 없으면 활동이 추론되는 것이 아니라 누락됩니다.
- 시간대: ProcessMind에 필요한 시간대로 타임스탬프를 통일합니다. 소스 타임스탬프가 UTC, 시스템 현지 시간 또는 다른 설정 시간대 중 무엇으로 저장되는지 문서화합니다.
샘플 쿼리 sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; 시작할 준비가 되셨나요?
이 템플릿을 활용해 데이터 준비 시간을 줄이고 주문부터 현금화까지의 청구 및 송장 발행 프로세스를 개선해 보세요. 지금 SAP S/4H4ANA 데이터를 실행 가능한 인사이트로 전환할 수 있습니다.
주문부터 현금화까지의 청구 프로세스를 개선해 현금 흐름을 30% 빠르게
비효율을 없애고 지금부터 청구 주기를 30% 단축하세요.
신용카드가 필요하지 않습니다. 몇 분 만에 시작할 수 있습니다.