주문부터 수금까지, 청구 및 송장 발행 데이터 템플릿
주문부터 수금까지, 청구 및 송장 발행 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- Oracle Fusion Financials 데이터 추출 안내
주문부터 수금까지, 청구 및 송장 발행 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
시작 시간
EventTimestamp
|
특정 활동이나 이벤트가 발생한 정확한 날짜와 시간입니다. | ||
|
설명
이벤트 타임스탬프에는 활동이 발생한 정확한 시각이 기록됩니다. 청구서별 이벤트 순서를 파악할 수 있어 프로세스 흐름을 구성하고 시간 기반 분석을 수행하는 데 필요합니다. 이 속성은 모든 소요 시간 및 성과 계산의 기준입니다. 활동 간 시간과 엔드투엔드 처리 시간을 측정하고, 지급 기한 준수 여부를 확인하며, 시간에 따른 추세를 분석하는 데 사용됩니다. '평균 청구서 승인 시간'과 '청구서 엔드투엔드 처리 시간' 등의 KPI도 이 타임스탬프를 바탕으로 계산합니다.
중요한 이유
타임스탬프는 처리 시간, 지연, 기한 준수 등 모든 성과 지표를 계산하는 데 필요하며, 정량적 프로세스 분석의 기반이 됩니다.
확보 방법
Oracle Fusion Financials의 여러 날짜 필드에서 가져옵니다. 예를 들어 RA_CUSTOMER_TRX_ALL의 CREATION_DATE나 워크플로 테이블의 상태 업데이트 타임스탬프를 사용할 수 있습니다.
예시
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
|
|||
|
청구서 번호
InvoiceNumber
|
각 청구서를 구분하는 고유 식별자로, 관련 활동을 추적할 때 기본 케이스 ID로 사용됩니다. | ||
|
설명
청구서 번호는 청구 프로세스 분석의 기준이 됩니다. 케이스 ID로 사용되어 청구서 생성부터 최종 지급 및 마감까지 모든 이벤트를 하나로 묶습니다. 이를 통해 개별 청구 문서의 전체 수명 주기를 처음부터 끝까지 확인할 수 있습니다. process mining에서 청구서 번호를 기준으로 분석하면 프로세스 변형을 시각화하고, 청구서별 처리 시간을 계산하며, 특정 거래에 영향을 주는 병목이나 재작업 루프를 찾을 수 있습니다. '청구서 엔드투엔드 처리 시간' 대시보드와 청구서별 매출채권 회수일수(DSO) 등 주요 KPI를 계산하는 데도 필요합니다.
중요한 이유
이 속성은 관련된 청구 및 지급 활동을 하나의 케이스로 연결하므로 청구서 수명 주기를 빠짐없이 정확하게 분석할 수 있습니다.
확보 방법
일반적으로 Oracle Fusion Financials의 RA_CUSTOMER_TRX_ALL 테이블에 있는 거래 번호(TRX_NUMBER)입니다.
예시
INV-1002345983451CM-55432
|
|||
|
활동 이름
ActivityName
|
청구서 수명 주기에서 특정 시점에 발생한 업무 이벤트 또는 작업의 이름입니다. | ||
|
설명
활동 이름은 '청구서 생성', '청구서 승인', '고객 지급 수령'과 같이 청구 프로세스의 단계를 나타냅니다. 이러한 이벤트가 모여 각 청구서의 프로세스 흐름을 구성합니다. 이 속성은 프로세스 탐색의 기본 요소입니다. process mining 도구는 이를 바탕으로 청구서가 실제로 처리되는 과정을 시각화합니다. 프로세스 변형을 분석하고, 여러 차례의 승인과 같은 재작업 루프를 찾으며, 각 단계의 빈도와 소요 시간을 측정하는 데 사용됩니다. 프로세스 흐름을 파악하는 모든 대시보드와 KPI가 이 속성을 활용합니다.
중요한 이유
이 속성으로 프로세스 맵의 단계를 정의하므로 청구서 워크플로를 시각화하고 분석해 비효율을 찾을 수 있습니다.
확보 방법
Oracle Fusion Financials의 여러 테이블과 상태 변경 기록에서 가져옵니다. 예를 들어 승인 관련 워크플로 이력 테이블과 거래 상태 필드가 사용됩니다.
예시
송장 생성송장 승인고객 대금 입금송장 마감
|
|||
|
고객명
CustomerName
|
대금을 청구받는 고객 또는 법인의 이름입니다. | ||
|
설명
이 속성은 청구서와 관련된 고객을 식별하며, 프로세스 데이터를 구분하고 필터링하는 주요 기준입니다. 고객명별로 분석하면 지급 주기가 긴 고객, 청구서에 이의를 제기할 가능성이 높은 고객, 꾸준히 기한 내에 지급하는 고객을 파악할 수 있습니다. DSO 추세 대시보드에 필요하며, 고객별 행동에 맞춰 채권 회수 전략을 조정하는 데도 활용됩니다.
중요한 이유
고객별로 프로세스를 구분해 행동과 지급 패턴의 차이, 현금 흐름에 영향을 주는 잠재적 관계 문제를 파악할 수 있습니다.
확보 방법
거래 테이블(RA_CUSTOMER_TRX_ALL)을 HZ_PARTIES와 같은 고객 마스터 데이터 테이블과 조인해 가져옵니다.
예시
Global Tech Inc.Innovate Solutions LLCApex Manufacturing
|
|||
|
사업부
BusinessUnit
|
조직 내에서 청구서를 발행한 사업부입니다. | ||
|
설명
사업부는 거래를 담당하는 조직 단위를 나타냅니다. 대기업의 재무 데이터를 구분하고 보고하는 데 필요한 요소입니다. 이 속성을 사용하면 회사 내 여러 조직의 프로세스 성과를 비교할 수 있습니다. 예를 들어 사업부별 DSO 차이가 큰지, 특정 사업부의 청구 재작업률이 유독 높은지 분석할 수 있습니다. 이를 통해 개선 활동이 필요한 영역을 구체적으로 찾을 수 있습니다.
중요한 이유
조직 단위별 성과를 비교해 우수 사례와 세부적인 개선 영역을 파악할 수 있습니다.
확보 방법
RA_CUSTOMER_TRX_ALL과 같은 거래 테이블에서 확인할 수 있습니다. 흔히 ORG_ID로 저장되며 사업부 정의와 연결됩니다.
예시
미국 컨설팅유럽·중동·아프리카 제조아시아·태평양 서비스
|
|||
|
지급 기한
DueDate
|
청구서 대금을 지급해야 하는 날짜입니다. | ||
|
설명
지급 기한은 지급 조건에 따라 정해지는 청구서 대금 지급 마감일입니다. 이 속성은 채권 회수와 재무 건전성을 관리하는 데 필요합니다. 기한 내 지급률 KPI를 계산하고 지급 연령 분석 보고서를 작성하는 기준이 됩니다. 대시보드에서는 예상 지급 시점을 표시해 현금 흐름을 예측하고, 채권 회수 조치가 필요한 연체 청구서를 찾는 데 사용됩니다.
중요한 이유
지급 적시성을 측정하고 DSO를 계산하며 매출채권 연령을 관리하는 주요 기준입니다.
확보 방법
AR_PAYMENT_SCHEDULES_ALL 테이블의 DUE_DATE 필드에서 확인할 수 있습니다.
예시
2023-05-302023-06-152023-07-01
|
|||
|
청구 금액
InvoiceAmount
|
청구서의 총 금액입니다. | ||
|
설명
이 속성은 청구서의 총 지급 금액을 나타냅니다. 청구 프로세스에서 처리되는 금액을 파악하는 데 중요한 재무 지표입니다. 분석 시 청구 금액을 기준으로 고액 거래의 우선순위를 정하고, 미수금 총액을 계산하며, 매출채권 회수일수(DSO)와 같은 KPI에 가중치를 적용할 수 있습니다. 재무 영향에 따라 프로세스를 구분해 고액 청구서의 승인 경로가 다르거나 지급까지 더 오래 걸리는지 분석할 수도 있습니다.
중요한 이유
각 케이스의 재무 정보를 제공하므로 금액 기준 분석, 고액 청구서 우선순위 지정, 주요 재무 KPI 계산이 가능합니다.
확보 방법
RA_CUSTOMER_TRX_ALL 테이블에서 확인할 수 있습니다. INVOICE_AMOUNT 또는 거래 총액을 나타내는 관련 필드에 저장될 수 있습니다.
예시
5000.001250.75250000.00
|
|||
|
청구서 상태
InvoiceStatus
|
수명 주기에서 청구서의 현재 상태입니다. 예를 들어 '미결', '마감', '분쟁 중' 등이 있습니다. | ||
|
설명
청구서 상태는 프로세스에서 청구서가 현재 어느 단계에 있는지 보여줍니다. 일반적인 상태로는 미결(미지급), 마감(지급 완료), 분쟁 중, 무효가 있습니다. 이 속성은 전체 현황을 모니터링하고 데이터를 필터링하는 데 유용합니다. 예를 들어 실시간 현금 흐름 예측 대시보드에서는 이 상태를 기준으로 미수 금액을 분류합니다. 연체, 분쟁 중, 정산 완료 청구서를 빠르게 파악할 수 있습니다.
중요한 이유
청구서의 현재 상태를 한눈에 파악할 수 있어 재무 보고와 운영 관리를 위한 효율적인 필터링 및 분류가 가능합니다.
확보 방법
RA_CUSTOMER_TRX_ALL 또는 AR_PAYMENT_SCHEDULES_ALL 등의 테이블에 있는 상태 필드(예: STATUS)에서 가져옵니다.
예시
미결마감분쟁 중승인 대기
|
|||
|
기한 내 지급 여부
IsPaidOnTime
|
청구서 대금이 지급 기한 당일 또는 그 전에 지급되었는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산 속성은 지급이 기한 내에 이루어졌는지 참 또는 거짓으로 표시합니다. '고객 지급 수령' 활동 날짜를 청구서의 '지급 기한' 속성과 비교해 산출합니다. 이 플래그를 사용하면 기한 내 지급률 KPI를 간편하게 분석하고 보고할 수 있습니다. 고객, 지역, 청구 금액 등의 요인이 연체와 어떤 관련이 있는지 쉽게 필터링하고 구분해 살펴볼 수 있습니다. 채권 회수 효과를 평가하는 주요 지표입니다.
중요한 이유
채권 회수 성과를 쉽게 측정하고 기한 내 지급과 연체에 영향을 주는 요인을 분석할 수 있습니다.
확보 방법
최종 지급 활동의 타임스탬프를 DueDate 속성과 비교해 계산합니다. 계산식은
예시
truefalse
|
|||
|
매출채권 회수일수
DaysSalesOutstanding
|
청구일부터 대금을 수령한 날까지의 일수입니다. | ||
|
설명
매출채권 회수일수(DSO)는 청구서 발행 후 대금을 회수하기까지 걸리는 평균 시간을 측정하는 주요 재무 지표입니다. 이 속성은 청구서별 DSO를 계산합니다. 전체 DSO는 주요 KPI이며, 청구서별로 계산하면 더 세부적인 분석이 가능합니다. 추세 대시보드를 만들고 DSO가 높은 청구서의 특성을 찾으며 프로세스 지연의 재무 영향을 측정할 수 있습니다. 이러한 세부 계산을 통해 전체 DSO KPI에 영향을 주는 요인을 파악할 수 있습니다.
중요한 이유
청구서별 현금 흐름 지표를 계산해 회수 기간과 재무 성과에 영향을 주는 요인을 자세히 분석할 수 있습니다.
확보 방법
'고객 지급 수령' 활동의 타임스탬프에서 '청구일' 속성의 값을 빼서 계산합니다.
예시
356228
|
|||
|
분쟁 사유
DisputeReason
|
고객이 청구서에 이의를 제기한 사유입니다. | ||
|
설명
고객이 청구서에 이의를 제기하면 그 사유를 기록합니다. 가격, 수량, 서비스 품질 또는 기타 문제가 원인일 수 있습니다. 분쟁 사유를 분석하면 근본 원인을 파악할 수 있습니다. 자주 발생하는 사유를 확인해 가격 책정, 주문 이행 또는 데이터 품질의 문제를 해결할 수 있습니다. 이를 통해 평균 청구서 분쟁 해결 시간을 줄이고 고객 만족도를 높일 수 있습니다.
중요한 이유
지급 지연과 고객 불만의 근본 원인을 직접 파악해 반복되는 문제를 해결할 수 있습니다.
확보 방법
Oracle Collections 또는 관련 분쟁 관리 모듈에 저장될 수 있습니다. 전용 분쟁 테이블이나 거래 자체의 사유 코드에 기록될 수 있습니다.
예시
가격 오류수량 불일치상품 파손청구서 중복
|
|||
|
사용자
User
|
해당 활동을 수행한 직원 또는 시스템 사용자입니다. | ||
|
설명
사용자 속성은 프로세스 단계를 수행한 담당자나 자동화된 에이전트를 식별합니다. 청구서를 생성한 사용자, 승인한 관리자, 독촉 안내를 발송한 채권 회수 담당자 등이 해당합니다. 사용자별 분석을 통해 교육이 필요한 영역, 업무량 분포, 개인 또는 팀 간 성과 차이를 파악할 수 있습니다. 특정 사용자의 오류율이 높은지, 특정 승인자가 반복적으로 병목을 일으키는지도 확인할 수 있습니다.
중요한 이유
프로세스 단계별 담당자를 확인해 사용자 성과와 업무량 균형을 분석하고 교육 필요성을 파악할 수 있습니다.
확보 방법
여러 거래 및 워크플로 테이블의 CREATED_BY 또는 LAST_UPDATED_BY와 같은 사용자 ID 필드에서 가져옵니다. 그런 다음 이 ID를 사용자 디렉터리 테이블(예: PER_ALL_PEOPLE_F)과 조인해 사용자 이름을 확인합니다.
예시
john.smithjane.doeCollectionsBot
|
|||
|
원천 시스템
SourceSystem
|
이벤트 데이터를 추출한 기준 시스템입니다. | ||
|
설명
데이터가 생성된 원천 애플리케이션을 나타내는 속성입니다. 이 프로세스에서는 일반적으로 Oracle Fusion Financials를 가리키지만 Oracle Receivables(AR)와 같은 특정 모듈을 지정할 수도 있습니다. 여러 시스템이 연동된 환경에서는 이 필드로 데이터 출처를 구분할 수 있어 데이터 검증과 거버넌스에 중요합니다. 분석에 올바른 데이터 집합이 사용되었는지도 확인할 수 있습니다.
중요한 이유
데이터의 출처를 식별합니다. 데이터 거버넌스와 문제 해결에 필요하며, 올바른 기준 시스템의 데이터를 분석하는지 확인하는 데도 중요합니다.
확보 방법
일반적으로 데이터 추출 및 변환 과정에서 'Oracle Fusion Financials'라는 고정값을 추가합니다.
예시
Oracle Fusion FinancialsOracle AR CloudFusion Apps
|
|||
|
재작업 여부
IsRework
|
반복 승인이나 수정처럼 활동이 재작업에 해당하는지 나타내는 불리언 플래그입니다. | ||
|
설명
이 계산 속성은 불필요하거나 중복된 작업을 나타내는 활동에 표시합니다. 예를 들어 청구서가 반려된 뒤 다시 승인을 요청하거나, 최초 생성 후 수정하는 경우가 해당합니다. 재작업을 표시하면 프로세스에 미치는 영향을 쉽게 수치화할 수 있습니다. 청구 재작업률 KPI는 이 속성을 바탕으로 계산됩니다. 대시보드에서 재작업 빈도를 시각화하고 추가 처리 시간을 측정해 비효율과 오류의 원인을 찾을 수 있습니다.
중요한 이유
불필요하거나 반복되는 작업을 표시해 프로세스 비효율을 직접 수치화하고, 품질 문제로 발생하는 비용과 시간의 영향을 측정할 수 있습니다.
확보 방법
활동 순서를 기준으로 데이터 변환 과정에서 계산합니다. 예를 들어 같은 케이스에서 '청구서 승인' 활동 전에 '청구서 반려' 활동이 있으면 재작업으로 표시합니다.
예시
truefalse
|
|||
|
종료 시간
EventEndTime
|
특정 활동이나 이벤트가 완료된 정확한 날짜와 시간입니다. | ||
|
설명
이벤트 종료 시간에는 활동이 끝난 시각이 기록됩니다. 대부분의 이벤트는 순간적으로 발생하지만, '청구서 승인'과 같은 활동은 요청 시점부터 승인 결정이 내려질 때까지 시간이 걸릴 수 있습니다. 종료 시간이 있으면 활동 처리 시간을 정확하게 계산할 수 있습니다. 사용자가 특정 작업에 얼마나 시간을 쓰는지 분석하는 데 유용합니다. 대기 시간과 실제 처리 시간을 구분해 병목 분석의 정확도도 높일 수 있습니다.
중요한 이유
활동 처리 시간을 정확하게 계산하고 실제 작업 시간과 대기 시간을 구분할 수 있어 세부적인 병목 분석에 도움이 됩니다.
확보 방법
프로세스에서 다음 활동의 시작 시간을 기준으로 산출하는 경우가 많습니다. 일부 활동은 워크플로 로그에 전용 종료 시간 필드가 있을 수 있습니다.
예시
2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
|
|||
|
지급 수단
PaymentMethod
|
계좌 이체나 신용카드 등 고객이 대금을 지급할 때 사용한 수단입니다. | ||
|
설명
이 속성은 고객이 청구서 대금을 어떤 방식으로 지급했는지 나타냅니다. 지급 추세와 비용을 분석하는 데 유용합니다. 지급 수단에 따라 처리 시간과 거래 비용이 다를 수 있습니다. 지급 수단별 분석으로 특정 수단에서 대사 오류나 지연이 자주 발생하는지 확인할 수 있습니다. 고객이 더 효율적인 지급 채널을 이용하도록 유도하는 방안을 마련하는 데도 참고할 수 있습니다.
중요한 이유
지급 채널별 처리 효율, 거래 비용, 대사 오류율을 분석하는 데 도움이 됩니다.
확보 방법
지급 수단을 나타내는 필드가 포함된 AR_CASH_RECEIPTS_ALL 등의 현금 수령 테이블에서 확인할 수 있습니다.
예시
ACH전신 송금신용카드수표
|
|||
|
지급 조건
PaymentTerms
|
'Net 30' 또는 '2% 10, Net 30'과 같이 합의된 청구서 지급 조건입니다. | ||
|
설명
지급 조건은 조기 지급 할인 가능성을 포함해 청구서 대금을 언제, 어떻게 지급해야 하는지 정합니다. 매출채권과 현금 흐름 관리에 필요한 정보입니다. 정확한 지급 기한을 계산하고 조기 지급 할인을 적용할 수 있는 거래를 찾는 데 사용됩니다. 조기 지급 할인 적용률 KPI는 할인 대상 청구서를 판별하기 위해 이 데이터에 직접 의존합니다.
중요한 이유
청구서의 지급 규칙을 정하며, 지급 기한 계산과 조기 지급 할인 적용 현황 추적 및 최적화에 직접 영향을 줍니다.
확보 방법
RA_TERMS 테이블에 있으며, RA_CUSTOMER_TRX_ALL의 term_id를 통해 거래와 연결됩니다.
예시
Net 30Net 602% 10, Net 30
|
|||
|
지역
Region
|
고객 또는 거래와 관련된 지리적 지역입니다. | ||
|
설명
지역은 일반적으로 고객 소재지를 기준으로 청구서의 지리적 정보를 나타냅니다. 이를 통해 지역별 프로세스 성과를 분석할 수 있습니다. 지역별 분석으로 현지 규정, 시장 상황, 지역 팀의 성과에 따른 차이를 찾을 수 있습니다. DSO 추세 및 청구서 엔드투엔드 처리 시간 대시보드를 지역별로 구분하면 특정 지역에서 청구서 대금 회수에 어려움이 있는지 확인할 수 있습니다.
중요한 이유
지역별로 프로세스를 구분해 성과, 고객 행동 또는 규정 준수의 차이를 파악할 수 있습니다.
확보 방법
일반적으로 TCA(HZ_LOCATIONS, HZ_PARTY_SITES)에 저장된 고객 주소 정보에서 가져옵니다. 청구서 자체에 직접 저장된 필드는 아닙니다.
예시
북미유럽아시아·태평양
|
|||
|
청구 부서
BillingDepartment
|
청구서를 생성하고 관리하는 내부 부서 또는 팀입니다. | ||
|
설명
이 속성은 조직 내에서 청구 프로세스를 담당한 팀이나 부서를 식별합니다. 분석에 조직 정보를 추가로 제공합니다. 청구 부서별로 프로세스를 구분하면 팀 간 효율성과 정확성을 비교할 수 있습니다. 재작업률이나 승인 시간이 높은 부서, DSO 증가에 더 크게 기여하는 부서를 찾아 맞춤형 교육이나 프로세스 표준화가 필요한 영역을 확인할 수 있습니다.
중요한 이유
내부 팀 간 성과를 비교해 우수 사례와 리소스 수요, 프로세스 개선이 필요한 영역을 파악할 수 있습니다.
확보 방법
청구서를 생성한 사용자를 HR 시스템의 부서 정보와 연결해 가져올 수 있습니다(예: PER_ALL_ASSIGNMENTS_F 사용).
예시
기업 청구서비스 청구 팀제품 판매 청구
|
|||
|
청구서 처리 시간
InvoiceCycleTime
|
청구서가 처음 생성된 시점부터 마감될 때까지 걸린 총시간입니다. | ||
|
설명
이 속성은 단일 케이스에서 청구서 수명 주기 전체의 엔드투엔드 처리 시간을 측정합니다. 일반적으로 첫 활동인 '청구서 생성'과 마지막 활동인 '청구서 마감' 사이의 시간 차이로 계산합니다. 이 지표는 프로세스 전반의 효율성을 보여줍니다. '청구서 엔드투엔드 처리 시간' 대시보드의 주요 측정값입니다. 고객이나 사업부 등 여러 기준으로 분석하면 처리 시간이 긴 청구서 유형을 찾고 원인을 조사할 수 있습니다.
중요한 이유
프로세스 전체의 처리 속도를 하나의 지표로 보여주므로 처음부터 완료까지 시간이 오래 걸리는 청구서를 빠르게 찾을 수 있습니다.
확보 방법
계산 지표입니다. 고유한 InvoiceNumber별로 EventTimestamp의 최댓값에서 최솟값을 빼서 산출합니다.
예시
45일 8시간32일 2시간90일 12시간
|
|||
|
청구일
InvoiceDate
|
청구서를 공식 발행한 날짜입니다. | ||
|
설명
거래일이라고도 하는 청구일은 청구서 문서에 기록된 날짜입니다. 지급 조건에 따른 기한을 계산하는 기준이 됩니다. 청구일부터 지급일까지의 기간을 측정하는 매출채권 회수일수(DSO)를 계산할 때 필요한 날짜입니다. 시스템에서 청구서를 생성한 날짜와는 다르며, 고객 관점에서 지급 주기가 공식적으로 시작되는 시점을 나타냅니다.
중요한 이유
청구서 수명 주기의 공식 시작일이며 매출채권 회수일수(DSO) KPI를 계산하는 기준입니다.
확보 방법
RA_CUSTOMER_TRX_ALL 테이블의 TRX_DATE 필드에서 확인할 수 있습니다.
예시
2023-04-142023-05-182023-06-25
|
|||
|
최근 데이터 업데이트
LastDataUpdate
|
이벤트 데이터가 원천 시스템에서 마지막으로 새로 고침되거나 추출된 시각을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성에는 가장 최근 데이터 추출 시각이 기록됩니다. 분석 대상 데이터의 최신성을 파악하는 데 필요한 메타데이터입니다. 분석가는 이 정보를 통해 최신 데이터로 작업 중인지 확인하고 데이터가 얼마나 최근에 갱신되었는지 파악할 수 있습니다. 특히 '실시간' 또는 준실시간이라고 표시된 대시보드에서는 데이터 지연 가능성을 투명하게 알리는 데 중요합니다.
중요한 이유
데이터의 최신성을 사용자에게 알려 분석과 결론이 갱신 시점을 확인할 수 있고 허용 가능한 최신 데이터에 기반하도록 합니다.
확보 방법
데이터 추출, 변환, 적재(ETL) 과정에서 생성되는 메타데이터 필드입니다. 일반적으로 데이터 파이프라인이 실행된 시각을 나타냅니다.
예시
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
주문부터 수금까지, 청구 및 송장 발행 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
고객 대금 입금
|
고객의 지급액이 현금 입금으로 시스템에 입력되었습니다. 이 단계에서는 아직 특정 송장에 적용되지 않았을 수 있습니다. | ||
|
중요한 이유
현금 유입을 나타내는 중요한 단계입니다. 입금부터 송장 적용까지 걸리는 시간은 현금 관리 효율을 보여 주는 주요 지표입니다.
확보 방법
AR_CASH_RECEIPTS_ALL 테이블에 레코드가 생성될 때 명시적으로 기록됩니다. receipt_date는 지급 처리가 이루어진 시점을 나타냅니다.
기록
AR_CASH_RECEIPTS_ALL 테이블의 creation_date 또는 receipt_date를 사용합니다.
이벤트 유형
explicit
|
|||
|
고객에게 송장 발송
|
이메일이나 인쇄물 등 고객이 선호하는 방식으로 송장을 전달했습니다. 시스템은 전달 작업이 실행된 시각을 기록하는 경우가 많습니다. | ||
|
중요한 이유
이 활동부터 지급 조건에 따른 기간이 시작됩니다. 승인부터 전달까지 걸리는 시간을 측정하면 송장 배포 프로세스의 효율을 파악할 수 있습니다.
확보 방법
RA_CUSTOMER_TRX_ALL의 'last_printed_date' 필드나 전자 전달을 사용하는 경우 Oracle Business Intelligence Publisher 로그를 통해 추론할 수 있습니다.
기록
송장과 관련된 전달 또는 인쇄 로그의 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
송장 마감
|
청구서 대금이 전액 지급되고 대사가 완료되어 수명 주기가 끝난 상태입니다. 일반적으로 청구서의 미수 잔액이 0이 되고 상태가 업데이트되면 이 이벤트가 발생한 것으로 추정합니다. | ||
|
중요한 이유
청구서 처리가 최종적으로 완료되어 프로세스가 끝나는 단계입니다. 이 상태에 도달하기까지 걸린 전체 시간이 청구 프로세스의 주요 KPI인 엔드투엔드 처리 시간입니다.
확보 방법
AR_PAYMENT_SCHEDULES_ALL 테이블에서 상태가 'CLOSED'로 업데이트되고 amount_due_remaining이 0인 경우를 기준으로 추정합니다. 'gl_date_closed' 필드에 마감일이 기록됩니다.
기록
해당 청구서의 AR_PAYMENT_SCHEDULES_ALL에서 gl_date_closed 값을 사용합니다.
이벤트 유형
inferred
|
|||
|
송장 생성
|
시스템에서 송장 거래를 처음 생성하는 단계로, 보통 초안 또는 미완료 상태입니다. 사용자가 Accounts Receivable 모듈에서 새 송장 레코드를 처음 저장할 때 이 이벤트가 명시적으로 기록됩니다. | ||
|
중요한 이유
이 이벤트는 청구 프로세스의 시작을 나타냅니다. 생성부터 완료까지 걸리는 시간을 분석하면 초기 데이터 입력 지연이나 시스템 성능 문제를 찾을 수 있습니다.
확보 방법
RA_CUSTOMER_TRX_ALL 테이블의 거래 레코드 생성일을 기준으로 이 이벤트를 수집합니다. 초기 상태는 보통 'Incomplete'입니다.
기록
해당 송장 번호의 RA_CUSTOMER_TRX_ALL 테이블에서 creation_date를 사용합니다.
이벤트 유형
explicit
|
|||
|
송장 승인
|
송장에 필요한 승인이 모두 완료되어 고객에게 보낼 수 있는 상태입니다. 승인 워크플로가 성공적으로 끝나 송장 상태가 갱신될 때 이 이벤트를 기록합니다. | ||
|
중요한 이유
이 중요한 단계가 완료되어야 송장을 고객에게 전달할 수 있습니다. 여기서 지연되면 지급 기산 시점이 늦어져 매출채권 회수일수(DSO)에 영향을 줍니다.
확보 방법
송장 거래 레코드의 최종 승인 상태 갱신 시각이나 관련 BPM 워크플로 작업의 완료 시각을 통해 추론합니다.
기록
송장 승인 상태가 'Approved'로 설정된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
송장에 지급액 적용
|
고객 입금액이 해당 송장과 성공적으로 대사되어 적용되었으며, 이에 따라 미결제 잔액이 줄었습니다. 이 활동은 별도의 거래 레코드로 기록됩니다. | ||
|
중요한 이유
이 활동은 현금이 올바르게 배분되었음을 확인합니다. 정확한 연령 보고서와 재무제표 작성에 중요하며, 매출채권에 현금을 반영하는 마지막 단계입니다.
확보 방법
AR_RECEIVABLE_APPLICATIONS_ALL 테이블에 명시적으로 기록됩니다. apply_date와 gl_date 필드에서 적용 시점을 확인할 수 있습니다.
기록
현금 입금과 송장을 연결하는 AR_RECEIVABLE_APPLICATIONS_ALL 테이블의 apply_date를 사용합니다.
이벤트 유형
explicit
|
|||
|
분쟁 접수
|
고객이 송장에 공식적으로 이의를 제기해 시스템에 분쟁 케이스가 생성되었습니다. 일반적으로 송장 지급 일정의 상태 플래그를 변경해 기록합니다. | ||
|
중요한 이유
분쟁이 발생하면 지급 절차가 중단되고 해결을 위해 수작업이 필요합니다. 분쟁 빈도와 해결 시간을 분석하면 가격이나 배송 오류와 같은 근본 원인을 찾을 수 있습니다.
확보 방법
AR_PAYMENT_SCHEDULES_ALL 테이블의 상태 필드가 분쟁 상태로 설정된 경우나 AR_DISPUTE_HISTORY의 생성 레코드를 통해 추론할 수 있습니다.
기록
송장의 지급 일정에서 분쟁 플래그나 상태가 활성화된 시점을 확인합니다.
이벤트 유형
inferred
|
|||
|
송장 반려
|
승인 담당자가 가격이나 수량 등 데이터 오류를 이유로 송장을 반려했습니다. 이 이벤트가 발생하면 송장을 수정하도록 되돌려 보내 재처리 과정이 시작됩니다. | ||
|
중요한 이유
반려를 추적하면 청구 정확도와 내부 통제의 문제를 확인할 수 있습니다. 반려 빈도와 사유를 분석하면 프로세스 개선과 교육이 필요한 영역을 찾을 수 있습니다.
확보 방법
송장 거래 레코드의 상태 갱신이나 BPM 워크플로 작업의 'Rejected' 결과를 통해 추론합니다.
기록
송장 승인 상태가 'Rejected'로 설정된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
송장 승인 요청
|
승인 워크플로가 설정된 경우 송장이 공식적으로 승인 절차에 제출됩니다. 송장 상태가 승인 대기 상태로 변경되면서 지정된 승인 담당자에게 알림이 전송되는 시점에 기록합니다. | ||
|
중요한 이유
승인 주기의 시작을 나타냅니다. 이 활동을 추적해야 후속 승인 시간을 측정하고 분석할 수 있으며, 이는 전체 송장 처리 시간의 주요 요소입니다.
확보 방법
송장 거래의 상태 변경을 통해 추론하거나 승인 작업의 시작을 기록하는 Oracle Business Process Management (BPM) 워크플로 테이블에서 수집합니다.
기록
송인의 승인 상태가 'Pending' 또는 이에 해당하는 상태로 변경된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
송장 완료
|
송장 데이터 입력이 완료되어 거래를 검증하고 회계 처리할 수 있는 상태를 나타냅니다. 일반적으로 송장 상태가 'Incomplete'에서 'Complete'로 변경되는 시점을 기록합니다. | ||
|
중요한 이유
이 시점은 데이터 입력 단계의 종료를 나타냅니다. 생성부터 완료까지 걸린 시간으로 청구 부서의 데이터 입력 및 검토 효율을 파악할 수 있습니다.
확보 방법
RA_CUSTOMER_TRX_ALL 테이블의 송장 거래 레코드에서 상태 변경을 확인해 추론합니다. 상태가 'Complete'로 변경된 시각을 확인합니다.
기록
RA_CUSTOMER_TRX_ALL 또는 관련 워크플로 테이블에서 거래 상태 이력을 추적합니다.
이벤트 유형
inferred
|
|||
|
송장 조정
|
대손 처리나 대변 조정 등으로 송장 금액이 변경되었습니다. 송장의 미결제 잔액을 변경하는 거래로 명시적으로 기록됩니다. | ||
|
중요한 이유
조정은 분쟁, 양보 또는 수정이 있었음을 나타내는 경우가 많습니다. 조정의 빈도와 금액을 분석하면 Order to Cash 프로세스의 근본적인 문제를 찾을 수 있습니다.
확보 방법
AR_ADJUSTMENTS_ALL 테이블에 명시적으로 기록됩니다. 조정 레코드의 creation_date가 이벤트 발생 시점을 나타냅니다.
기록
해당 송장에 대한 AR_ADJUSTMENTS_ALL 테이블의 creation_date를 사용합니다.
이벤트 유형
explicit
|
|||
|
지급 기한 도래
|
송장 대금의 계약상 지급 기한이 지난 시점입니다. 거래 이벤트로 기록되는 것이 아니라 송장의 지급 조건과 현재 날짜를 기준으로 계산합니다. | ||
|
중요한 이유
이 계산 이벤트는 연령 분석과 DSO 산출에 중요합니다. 기한 내 송장과 연체 송장을 구분해 필요한 회수 활동에 집중할 수 있습니다.
확보 방법
계산 이벤트입니다. 해당 송장의 AR_PAYMENT_SCHEDULES_ALL 테이블에서 현재 날짜가 due_date 필드보다 늦으면 발생합니다.
기록
현재 날짜와 AR_PAYMENT_SCHEDULES_ALL의 due_date 필드를 비교해 계산합니다.
이벤트 유형
calculated
|
|||
|
지급 안내 발송
|
연체 송장에 대해 독촉장이나 지급 안내를 고객에게 발송했습니다. 이 활동은 대금 회수 모듈에 명시적으로 기록됩니다. | ||
|
중요한 이유
지급 안내를 추적하면 대금 회수 프로세스의 효과를 측정할 수 있습니다. 어떤 안내 전략이 지급을 앞당기는지 분석할 수 있습니다.
확보 방법
Oracle Advanced Collections 모듈에 명시적으로 기록됩니다. IEX_DUNNINGS와 같은 독촉 이력 테이블에 발송 날짜와 안내 단계가 기록됩니다.
기록
독촉 이력 테이블에서 데이터를 가져와 독촉 거래와 송장을 연결합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 준비하고 주문부터 수금까지의 청구 및 송장 발행 프로세스를 간소화해 현금 전환 속도를 높이세요. 지금 Oracle Fusion Financials 운영 데이터를 분석해 개선 기회를 찾아보세요.
지금 Oracle 청구 및 송장 발행 프로세스를 개선하세요
솔루션을 활용해 청구 주기를 30% 단축하고 현금 흐름을 개선하세요.
신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.