신용 관리 및 채권 회수 데이터 템플릿
신용 관리 및 채권 회수 데이터 템플릿
- 심층 분석에 권장되는 속성
- 프로세스 탐색을 위해 추적할 주요 활동
- 단계별 데이터 추출 안내
신용 관리 및 채권 회수 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 송장 번호 InvoiceNumber | 각 고객 송장을 식별하는 고유 번호로, 신용 관리 프로세스에서 기본 케이스 식별자로 사용됩니다. | ||
| 설명 송장 번호는 송장 생성부터 최종 정산 또는 대손 처리까지 하나의 매출채권과 관련된 모든 이벤트와 활동을 연결하는 기준입니다. 이를 통해 송장 수명 주기 전체를 확인할 수 있습니다. process mining 분석에서는 이 속성을 사용해 송장별 처리 과정을 재구성합니다. 관련 활동을 하나의 송장 번호로 묶으면 프로세스 흐름을 시각화하고, 일반적인 경로와 예외 경로를 찾아내며, 전체 프로세스나 분쟁 해결 및 결제 전기 같은 특정 단계의 주기 시간을 측정할 수 있습니다. 중요한 이유 관련된 모든 프로세스 단계를 연결하는 필수 Case ID입니다. 송장 발행부터 마감까지의 과정을 재구성하고 분석할 수 있습니다. 확보 방법 Oracle Fusion Financials의 RA_CUSTOMER_TRX_ALL 테이블에서 TRX_NUMBER로 확인할 수 있습니다. 예시 INV-1005679884321AR-2023-04-112 | |||
| 이벤트 시각 EventTime | 활동이 발생한 정확한 날짜와 시간으로, 이벤트의 타임스탬프 역할을 합니다. | ||
| 설명 이벤트 시각 또는 타임스탬프는 활동이 발생한 정확한 시점을 기록합니다. 정확한 프로세스 흐름을 구성하려면 이벤트를 시간순으로 정렬해야 하므로 이 속성이 중요합니다. 타임스탬프가 정확하지 않으면 이벤트 순서를 올바르게 파악할 수 없습니다. 분석에서는 이 속성을 사용해 활동 간 소요 시간과 주기 시간을 계산합니다. 이는 성과 측정에 중요하며, 분쟁 해결 주기 시간이나 송장 결제 주기 시간 같은 KPI를 계산하는 데 활용됩니다. 또한 기간별 프로세스 성과 추세를 분석할 수 있습니다. 중요한 이유 이 타임스탬프는 이벤트 정렬, 주기 시간과 소요 시간 계산, 시간에 따른 프로세스 성과 분석에 필수적입니다. 확보 방법 송장 생성의 경우 RA_CUSTOMER_TRX_ALL의 TRX_DATE, 채권 회수 활동의 경우 해당 활동의 생성일 등 Oracle Fusion Financials 테이블의 여러 날짜 필드에서 도출합니다. 예시 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| 활동 이름 ActivityName | 신용 관리 프로세스에서 특정 시점에 발생한 업무 이벤트나 작업의 이름입니다. | ||
| 설명 이 속성은 '송장 생성', '연체 안내 절차 시작', '대금 수령'과 같이 송장 수명 주기의 개별 단계를 나타냅니다. 각 활동은 케이스를 다음 단계로 진행시키는 별도의 이벤트입니다. 활동의 순서와 빈도를 분석하는 것은 process mining의 기본입니다. 실제 프로세스 흐름을 파악하고, 케이스가 정체되는 병목을 찾으며, 활동이 반복되는 재작업을 감지하고, 실제 프로세스를 설계된 프로세스 또는 이상적인 프로세스와 비교할 수 있습니다. 활동 이름은 프로세스 맵을 만들고 단계 간 전환 시간을 계산하는 데 필수적입니다. 중요한 이유 이 속성은 프로세스 맵의 단계를 정의해 송장 수명 주기를 처음부터 끝까지 시각화하고 분석할 수 있게 합니다. 확보 방법 Oracle Fusion Financials의 여러 업무 이벤트에서 도출하는 개념적 필드입니다. 매출채권(AR) 및 Advanced Collections 같은 모듈의 거래 상태, 이벤트 날짜 또는 특정 작업을 매핑해 구성하는 경우가 많습니다. 예시 송장 생성연체 안내 절차 시작대금 수령분쟁 등록 | |||
| 마지막 데이터 업데이트 LastDataUpdate | 이 이벤트의 데이터가 소스 시스템에서 마지막으로 새로 고쳐지거나 추출된 시각입니다. | ||
| 설명 이 속성은 가장 최근 데이터 추출 날짜와 시간을 나타냅니다. 업무 프로세스 자체에는 포함되지 않는 메타데이터이지만, 분석 대상 데이터가 얼마나 최신인지 파악하는 데 중요합니다. 분석 담당자는 이 타임스탬프로 최신 정보가 사용되고 있는지 확인하고 데이터의 기준 시점을 파악합니다. 데이터 거버넌스와 대시보드 및 보고서의 데이터 최신성에 대한 사용자 기대를 관리하는 데도 필요합니다. 중요한 이유 데이터의 최신성을 나타내므로 분석 담당자와 이해관계자가 데이터의 시의성과 관련성을 파악할 수 있습니다. 확보 방법 데이터 추출 및 적재(ETL) 과정에서 각 레코드에 생성해 기록하는 값입니다. 예시 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 소스 시스템 SourceSystem | 데이터가 생성된 시스템입니다. | ||
| 설명 이 속성은 이벤트 데이터가 기록된 소스 애플리케이션을 식별합니다. 복잡한 IT 환경에서는 하나의 엔드투엔드 프로세스에 여러 시스템이 관여할 수 있습니다. 소스 시스템을 지정하면 데이터 거버넌스와 문제 해결에 도움이 되고 데이터의 맥락을 파악할 수 있습니다. 여러 시스템의 이벤트를 하나의 프로세스 보기로 통합할 때 출처를 구분하고 데이터 계보를 명확히 할 수 있습니다. 중요한 이유 데이터 출처를 명확히 보여주므로 데이터 검증과 거버넌스, 프로세스의 기술적 맥락을 파악하는 데 도움이 됩니다. 확보 방법 일반적으로 데이터 추출 시 레코드의 출처를 식별하기 위해 추가하는 고정 값입니다. 예시 Oracle Fusion FinancialsOracle AROracle Collections | |||
| 고객 번호 CustomerNumber | 송장과 연결된 고객을 식별하는 고유 번호입니다. | ||
| 설명 고객 번호는 송장을 특정 고객 계정과 연결합니다. 이를 통해 고객 속성에 따라 신용 및 채권 회수 프로세스를 구분해 분석할 수 있습니다. 고객 번호를 포함하면 특정 고객이 반복해서 늦게 결제하는지, 분쟁을 더 자주 제기하는지, 더 많은 회수 활동이 필요한지 조사할 수 있습니다. 이 정보는 고객별 회수 전략 수립, 신용 조건 조정, 위험도가 높은 고객군 식별에 중요합니다. 고객군별 송장 대손 처리율 분석도 이 속성을 활용합니다. 중요한 이유 고객별로 프로세스를 구분해 분석할 수 있어 고객별 패턴과 위험, 맞춤형 회수 전략의 기회를 파악하는 데 도움이 됩니다. 확보 방법 일반적으로 RA_CUSTOMER_TRX_ALL 테이블의 BILL_TO_CUSTOMER_ID에서 확인하며, 이 값은 HZ_CUST_ACCOUNTS와 연결됩니다. 예시 CUST-0012389455ACME-CORP-US | |||
| 고객군 CustomerSegment | 규모, 업종 또는 전략적 중요도에 따라 고객을 분류한 그룹입니다. | ||
| 설명 고객군은 공통 특성에 따라 고객을 묶는 범주형 속성입니다. '전략 고객', '중소기업', '대기업'처럼 규모나 중요도를 기준으로 구분하거나, '제조업', '소매업'처럼 업종별로 나눌 수 있습니다. 이 속성을 활용하면 고객군별 성과를 비교할 수 있습니다. 예를 들어 특정 고객군에서 분쟁 발생률이 더 높거나 결제 주기가 더 긴지 확인할 수 있습니다. 이러한 분석 결과를 바탕으로 각 고객군의 요구와 위험에 맞춰 신용 정책과 회수 전략을 조정할 수 있으며, 고객군별 송장 대손 처리율 분석 대시보드에도 활용할 수 있습니다. 중요한 이유 고객군별 프로세스 성과와 위험의 차이를 파악할 수 있어 비교 분석에 유용합니다. 확보 방법 고객 마스터 데이터(HZ_CUST_ACCOUNTS 또는 관련 테이블)에서 관리하거나 매출액, 업종 등의 고객 속성으로부터 도출하는 경우가 많습니다. 예시 대기업중소기업정부 기관전략적 파트너 | |||
| 독촉 단계 DunningLevel | 송장에 적용된 독촉 절차의 단계 또는 수준입니다. | ||
| 설명 독촉 단계는 수금 독촉의 강도를 나타내며, 일반적으로 시간이 지날수록 높아집니다. 예를 들어 1단계에서는 정중한 이메일 알림을 보내고, 3단계에서는 공식 서한을 보내거나 전화할 수 있습니다. 독촉 단계별로 프로세스를 분석하면 독촉 전략의 효과를 평가할 수 있습니다. 독촉 효과 대시보드는 이 속성을 사용해 각 독촉 단계에서 결제로 이어지는 비율을 시각화합니다. 이를 통해 기업은 어떤 독촉 조치가 가장 효과적인지 파악하고, 수금액을 늘릴 수 있도록 알림 시점과 내용을 조정할 수 있습니다. 중요한 이유 수금 조치의 단계별 진행 상황을 추적합니다. 독촉 전략의 효과를 평가하는 데 중요한 정보입니다. 확보 방법 이 데이터는 Oracle Advanced Collections 모듈에서 관리합니다. IEX_DUNNINGS와 같은 독촉 이력 관련 테이블에서 확인할 수 있습니다. 예시 1단계: 알림2단계: 경고3단계: 최종 통지 | |||
| 사용자 User | 활동을 수행한 사용자 또는 시스템 ID입니다. | ||
| 설명 이 속성은 신용 한도 승인, 결제 전기, 분쟁 해결과 같은 활동을 수행한 직원 또는 자동화 시스템 사용자를 식별합니다. 사용자별 활동을 분석하면 업무량 분배, 개인별 실적, 규정 준수 여부를 파악할 수 있습니다. 자동화된 활동의 경우 시스템 프로세스가 관여한 내역을 추적할 수 있습니다. 사용자 행동을 모니터링해 교육이 필요한 영역이나 잠재적인 부정 행위를 파악하는 데에도 활용할 수 있습니다. 중요한 이유 프로세스 활동을 특정 사용자나 자동화 시스템에 연결해 실적 추적, 업무량 분석, 감사에 활용할 수 있습니다. 확보 방법 Oracle Fusion Financials 전반의 여러 거래 및 이력 테이블에 있는 'CREATED_BY' 또는 'LAST_UPDATED_BY' 열에서 가져옵니다. 예시 jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| 송장 금액 InvoiceAmount | 송장의 총 금액입니다. | ||
| 설명 송장 금액은 고객에게 청구한 상품이나 서비스의 총액입니다. 프로세스가 재무에 미치는 영향을 파악하는 데 중요한 속성입니다. 분석에서는 고액 연체 송장에 회수 활동을 우선 배정하는 데 활용합니다. 거래 금액에 따른 결제 행태를 분석하고 대손 처리의 재무적 영향을 계산하는 데도 사용됩니다. 송장 대손 처리율 분석 대시보드에서는 이 값을 바탕으로 재무 손실 규모를 평가합니다. 중요한 이유 프로세스의 재무적 맥락을 보여주므로 고액 송장의 우선순위를 정하고 프로세스 비효율이 금액에 미치는 영향을 분석할 수 있습니다. 확보 방법 송장별 미수 금액을 저장하는 AR_PAYMENT_SCHEDULES_ALL 테이블에서 가져올 수 있습니다. 예시 5000.001250.75250000.00 | |||
| 지급 기한 DueDate | 송장 대금을 지급해야 하는 날짜입니다. | ||
| 설명 지급 기한은 계약에 따라 정해진 중요한 날짜로, 지급이 제때 이루어졌는지 판단하는 기준입니다. 이 속성은 연체 송장을 식별하고 연체 일수를 계산하는 데 필수적입니다. 독촉 절차를 시작할 시점을 정하는 주요 기준이며, 매출채권 회전일수(DSO)와 같은 KPI를 계산할 때도 사용합니다. 미수금의 경과 기간을 구분하는 연령 분석 보고서를 작성하는 데에도 필요합니다. 중요한 이유 송장의 연체 여부를 판단하는 기준으로, 수금 활동을 시작하고 경과 기간을 분석하는 데 활용됩니다. 확보 방법 AR_PAYMENT_SCHEDULES_ALL 테이블의 DUE_DATE 필드에서 확인할 수 있습니다. 예시 2023-05-302023-06-152023-07-01 | |||
| 채권 회수 담당자 Collector | 송장에 배정된 채권 회수 담당자의 이름 또는 ID입니다. | ||
| 설명 채권 회수 담당자는 연체 송장의 회수 활동을 관리하는 개인 또는 팀입니다. 담당자 배정은 채권 회수 워크플로의 주요 단계입니다. 이 속성은 채권 회수 부서의 성과 관리와 리소스 배분에 중요합니다. 담당자별 결과를 분석하면 관리자는 회수 효과를 평가하고, 교육이 필요한 부분을 찾으며, 업무량을 조정할 수 있습니다. 담당자별 성공률과 주기 시간을 비교하는 채권 회수 담당자 배정 효과 대시보드에서도 이 속성을 사용합니다. 중요한 이유 담당자나 팀별 성과를 분석해 리소스 배분을 최적화하고 전반적인 회수 효율을 높일 수 있습니다. 확보 방법 일반적으로 Oracle Advanced Collections 모듈의 IEX_CASES_ALL_B 또는 관련 배정 테이블에 저장됩니다. 예시 홍길동김영희수금팀 A | |||
| 대손 처리 여부 IsWrittenOff | 송장이 대손으로 처리되었는지 나타내는 불리언 플래그입니다. | ||
| 설명 이 파생 플래그는 기업이 회수 불가능하다고 판단해 활성 매출채권에서 제외한 송장을 식별합니다. 일반적으로 송장 처리 과정에서 발생하는 가장 바람직하지 않은 최종 결과입니다. 이 속성은 송장 대손 처리율 KPI와 관련 분석 대시보드를 계산하는 데 필수적입니다. 분석가는 수금에 실패한 송장만 추려 고객 세그먼트나 송장 금액 등 대손 위험 증가와 관련된 공통 특성을 찾을 수 있습니다. 이러한 분석 결과를 신용 정책과 수금 전략 개선에 활용합니다. 중요한 이유 수금 실패 사례를 명확하게 식별해 대손의 근본 원인을 분석하고 대손 처리율을 계산할 수 있습니다. 확보 방법 계산 필드입니다. 케이스에 '송장 대손 처리' 활동이 있는지 또는 송장 상태가 '대손 처리'인지 확인해 값을 산출합니다. 예시 truefalse | |||
| 분쟁 사유 DisputeReason | 고객이 송장에 이의를 제기하며 밝힌 사유입니다. | ||
| 설명 고객은 송장에 이의를 제기할 때 '가격 오류', '상품 파손', '중복 송장'과 같은 사유를 제시합니다. 이 속성은 해당 사유를 기록합니다. 분쟁 사유 분석은 근본 원인을 파악하는 데 중요합니다. 이를 통해 주문 관리나 청구와 같은 선행 프로세스에서 발생해 결제를 지연시키는 반복 문제를 찾을 수 있습니다. 분쟁 사유별 발생 빈도를 분류하고 추적하면 근본 원인을 해결하기 위한 조치를 취할 수 있으며, 분쟁 해결 주기를 단축하는 데 도움이 됩니다. 중요한 이유 송장 분쟁의 근본 원인을 파악해 선행 프로세스를 개선하고 향후 분쟁을 예방할 수 있습니다. 확보 방법 분쟁 관리 절차를 공식화한 경우 Oracle Advanced Collections 또는 Oracle Channel Revenue Management 모듈에 기록할 수 있습니다. AR_DISPUTE_HISTORY와 같은 테이블에 저장될 수 있습니다. 예시 수량 오류가격 불일치상품 파손서비스 미제공 | |||
| 사업부 BusinessUnit | 송장을 발행한 사업부 또는 조직 단위입니다. | ||
| 설명 대규모 조직은 여러 사업부로 나뉘어 운영되는 경우가 많습니다. 이 속성은 송장과 연결된 사업부를 식별합니다. 사업부별로 프로세스를 분석하면 조직 내 각 부문의 실적을 비교할 수 있습니다. 신용 및 수금 정책이 일관되게 적용되는지 확인하고, 매출채권 관리에 더 효과적인 사업부를 파악할 수 있습니다. 이를 바탕으로 우수 사례를 공유하고 필요한 경우 프로세스를 표준화할 수 있습니다. 중요한 이유 조직 단위별 실적을 비교해 우수 사례와 개선이 필요한 영역을 파악할 수 있습니다. 확보 방법 RA_CUSTOMER_TRX_ALL 테이블의 ORG_ID 필드에서 확인할 수 있으며, 이 필드는 조직 구조와 연결됩니다. 예시 북미 사업부EMEA 사업부글로벌 서비스 부문 | |||
| 송장 상태 InvoiceStatus | 송장 처리 과정에서 현재 상태를 나타냅니다. | ||
| 설명 송장 상태를 보면 프로세스에서 송장이 현재 어떤 단계에 있는지 확인할 수 있습니다. 일반적인 상태로는 '미결', '결제 완료', '분쟁 중', '기한 초과', '대손 처리'가 있습니다. 이 속성은 매출채권의 전반적인 상태를 보여줍니다. process mining에서는 이 속성으로 케이스를 필터링해 기한이 지난 미결 송장 등 특정 대상을 분석할 수 있습니다. 연체 송장 경과 기간 및 상태 대시보드의 주요 분석 기준으로, 송장 포트폴리오의 현재 상태를 한눈에 파악하고 수금 활동의 우선순위를 정하는 데 도움이 됩니다. 중요한 이유 송장의 현재 상태를 빠르게 파악하고 수금 조치의 우선순위를 정할 수 있도록 필터링 기준을 제공합니다. 확보 방법 일반적으로 AR_PAYMENT_SCHEDULES_ALL 테이블의 STATUS 필드에서 확인할 수 있습니다. 예시 미결종료분쟁 중수금 진행 중 | |||
| 송장 통화 InvoiceCurrency | 송장 금액을 표시하는 통화입니다. | ||
| 설명 이 속성은 USD, EUR, GBP 등 송장에 사용된 통화를 나타냅니다. 다국적 조직에서는 여러 통화로 송장을 발행하는 경우가 많습니다. 여러 통화의 데이터를 분석할 때는 주의가 필요합니다. 이 속성을 사용하면 통화별로 프로세스 보기를 필터링하거나 통합 재무 보고에 적절한 환율을 적용할 수 있습니다. 금액을 정확히 해석하고 동일한 기준으로 비교할 수 있습니다. 중요한 이유 여러 통화를 사용하는 환경에서 재무 데이터를 정확히 해석하고 올바르게 분석하는 데 필요합니다. 확보 방법 일반적으로 RA_CUSTOMER_TRX_ALL 테이블의 INVOICE_CURRENCY_CODE에서 확인할 수 있습니다. 예시 USDEURGBPJPY | |||
| 신용 한도 금액 CreditLimitAmount | 고객에게 승인된 최대 신용 금액입니다. | ||
| 설명 신용 한도 금액은 기업이 특정 고객에게 허용하는 총 신용 익스포저입니다. 신용 심사 과정에서 이 금액을 결정합니다. 이 속성은 신용 한도 결정 영향 대시보드에 필수적입니다. 승인된 신용 한도와 이후 결제 행태 및 대손 처리 내역을 연계하면 신용 위험 정책의 효과를 평가할 수 있습니다. 분석을 통해 지나치게 높은 신용 한도가 대손 증가로 이어지는지 확인하고 신용 승인 프로세스를 개선할 수 있습니다. 중요한 이유 승인된 신용 한도와 결제 결과 및 대손 처리 내역을 비교해 신용 위험 정책의 효과를 평가하는 데 중요합니다. 확보 방법 Oracle Credit Management에서 관리하며, 일반적으로 HZ_CUST_PROFILE_AMTS와 같은 고객 신용 프로필 관련 테이블에 저장됩니다. 예시 10000.0050000.00250000.00 | |||
| 연체 여부 IsOverdue | 송장의 지급 기한이 지났는지 나타내는 불리언 플래그입니다. | ||
| 설명 이 파생 속성은 송장이 연체되었는지 참 또는 거짓으로 표시합니다. 일반적으로 현재 날짜 또는 결제일을 송장의 지급 기한과 비교해 계산합니다. 이 플래그는 분석 대상을 필터링하고 구분하는 데 유용합니다. 분석가는 연체 송장만 빠르게 추려 프로세스 경로, 수금 활동의 효과 및 기타 특성을 살펴볼 수 있습니다. 연체 송장 경과 기간 및 상태 대시보드처럼 연체 채권 관리에 초점을 둔 대시보드와 KPI를 간편하게 구성할 수 있습니다. 중요한 이유 연체 송장을 명확하게 식별하고 분석할 수 있습니다. 연체 송장은 수금 프로세스의 주요 관리 대상입니다. 확보 방법 계산 필드입니다. 로직은 다음과 같습니다. IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. 예시 truefalse | |||
| 연체 일수 DaysOverdue | 송장의 지급 기한이 지난 일수입니다. | ||
| 설명 이 계산 지표는 미결 송장의 연체 일수를 나타냅니다. 미결 송장은 현재 날짜에서 지급 기한을 빼고, 종료된 송장은 결제일에서 지급 기한을 빼서 계산합니다. 연체 일수는 경과 기간 분석과 수금 우선순위 설정에 중요한 지표입니다. 연체 송장 경과 기간 및 상태 대시보드의 주요 지표로, 송장을 연체 기간별 구간(예: 1 중요한 이유 결제 지연 정도를 수치화해 수금 우선순위를 정하고 경과 기간을 분석하는 주요 지표로 활용합니다. 확보 방법 계산 필드입니다. 미결 송장은 CurrentDate - DueDate, 종료된 송장은 PaymentDate - DueDate로 계산합니다. 예시 1545920 | |||
| 종료 시간 EndTime | 소요 시간이 있는 활동이 완료된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 시작과 종료 시점이 구분되는 활동의 완료 시간을 기록합니다. process mining에서 많은 이벤트는 순간적으로 발생하지만, '분쟁 조사'와 같은 활동은 일정 기간 이어질 수 있습니다. 종료 시간이 별도로 있으면 활동 처리 시간을 정확하게 계산할 수 있습니다. 특히 활동 사이에 대기 시간이 있는 경우, 다음 활동의 시작 시간으로 소요 시간을 추정하는 것보다 정확합니다. 리소스 활용률을 분석하고 프로세스에서 시간이 오래 걸리는 단계를 찾는 데에도 중요합니다. 중요한 이유 각 활동에 걸리는 시간을 정확하게 계산해 병목과 리소스 활용 현황을 더 자세히 파악할 수 있습니다. 확보 방법 개념상 정의되는 속성인 경우가 많습니다. 활동에 해당하는 원본 테이블의 '마지막 업데이트' 타임스탬프나 특정 '종료일' 필드에서 가져올 수 있습니다. 예시 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| 지급 약속일 PromiseToPayDate | 고객이 대금을 지급하기로 약속한 날짜입니다. | ||
| 설명 수금 과정에서 고객이 향후 특정 날짜에 대금을 지급하겠다고 약속할 수 있습니다. 이 약속을 추적하기 위해 '지급 약속일'을 기록합니다. 이 속성은 수금 워크플로를 관리하고 고객의 지급 약속 이행 여부를 평가하는 데 중요합니다. 지급 약속일과 실제 입금일을 비교하면 수금 담당자가 약속 이행률을 파악할 수 있습니다. 현금 흐름을 더 정확하게 예측하고 약속이 지켜지지 않았을 때 수금 조치를 강화할 시점을 결정하는 데에도 도움이 됩니다. 중요한 이유 고객의 지급 약속을 추적해 현금 유입을 예측하고 수금 협상의 효과를 관리할 수 있습니다. 확보 방법 Oracle Advanced Collections 모듈에 저장되며, IEX_PROMISES_T와 같은 테이블에서 확인할 수 있습니다. 예시 2023-06-102023-06-252023-07-05 | |||
| 지급 조건 PaymentTerms | 지급 기한을 정하는 합의된 조건입니다. | ||
| 설명 지급 조건은 고객이 대금을 지급해야 하는 시점을 정합니다. 예를 들어 '30일 이내 지급' 또는 '60일 이내 지급'과 같은 조건이 있습니다. 이 조건을 기준으로 송장의 지급 기한을 계산합니다. 지급 조건별 결제 실적을 분석하면 유용한 패턴을 찾을 수 있습니다. 예를 들어 지급 기한이 짧은 고객이 오히려 늦게 결제하는 경우가 더 많을 수 있습니다. 이러한 정보를 바탕으로 신용 정책을 검토하고 조정하거나, 고객을 구분해 서로 다른 수금 전략을 적용할 수 있습니다. 특정 송장이 연체되는 이유를 파악하는 데에도 도움이 됩니다. 중요한 이유 합의된 지급 일정을 보여주므로 신용 조건별 결제 행태를 분석할 수 있습니다. 확보 방법 RA_TERMS 테이블에 저장되며 송장 거래와 연결됩니다. 예시 30일 이내 지급60일 이내 지급수령 즉시 지급 | |||
신용 관리 및 채권 회수 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 결제 기한 경과 | 송장이 완납되지 않은 상태에서 현재 날짜가 결제 기한을 지난 경우 발생하는 계산 이벤트입니다. 이 이벤트는 송장 상태가 '정상'에서 '연체'로 바뀌는 시점을 나타냅니다. | ||
| 중요한 이유 이 시점은 채권 회수와 연체 안내 프로세스를 시작하는 주요 기준입니다. 결제 기한이 지난 송장의 건수와 금액을 분석하는 일은 운전자본 관리와 신용 위험 평가에 중요합니다. 확보 방법 AR_PAYMENT_SCHEDULES_ALL 테이블에서 STATUS가 'OP'(미결)인 송장의 DUE_DATE와 시스템의 현재 날짜를 비교해 계산합니다. 기록 계산 이벤트: SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE일 때 발생합니다. 이벤트 유형 calculated | |||
| 결제 적용 | 수령한 결제를 특정 송장에 적용해 미수 잔액을 줄이는 단계입니다. 결제와 송장을 공식적으로 연결합니다. | ||
| 중요한 이유 이 활동은 송장이 결제되었음을 확인하는 데 중요합니다. 매출채권 회전일수(DSO)와 결제 전기 주기를 계산하는 실제 종료 시점입니다. 확보 방법 현금 영수금을 고객 거래(송장)와 연결하는 AR_RECEIVABLE_APPLICATIONS_ALL 테이블의 APPLY_DATE에서 직접 가져오는 이벤트입니다. 기록 해당 송장에 대한 AR_RECEIVABLE_APPLICATIONS_ALL의 APPLY_DATE입니다. 이벤트 유형 explicit | |||
| 대금 수령 | 고객으로부터 자금을 받았지만 아직 특정 송장에 적용되지 않은 상태를 나타냅니다. 시스템에 현금 영수 거래가 생성될 때 기록됩니다. | ||
| 중요한 이유 이 시점은 채권 회수 프로세스의 주요 단계로, 대금을 수령했음을 나타냅니다. 이 시점부터 결제 적용까지 걸리는 시간은 내부 처리 효율을 보여줍니다. 확보 방법 AR_CASH_RECEIPTS_ALL 테이블의 RECEIPT_DATE에서 직접 가져옵니다. 이후 AR_RECEIVABLE_APPLICATIONS_ALL을 통해 영수금을 적용한 송장과 연결할 수 있습니다. 기록 AR_CASH_RECEIPTS_ALL의 RECEIPT_DATE를 사용하고 적용 테이블을 통해 연결합니다. 이벤트 유형 explicit | |||
| 송장 대손 처리 | 채권 회수 활동을 중단하고 송장 금액을 대손으로 처리하기로 공식 결정한 것을 나타냅니다. 송장 잔액을 0으로 조정하는 명시적인 재무 거래입니다. | ||
| 중요한 이유 이는 채권 회수 프로세스가 실패로 끝나는 주요 지점입니다. 고객군, 지역 또는 신용 한도별 대손 처리 현황을 분석하면 신용 정책과 회수 전략을 개선해 손실을 줄일 수 있습니다. 확보 방법 대손 또는 상각 활동을 가리키는 RECEIVABLES_TRX_ID가 있는 AR_ADJUSTMENTS_ALL 테이블의 조정 레코드 생성에서 직접 가져옵니다. 기록 대손 처리 활동 유형이 지정된 AR_ADJUSTMENTS_ALL 레코드의 생성일입니다. 이벤트 유형 explicit | |||
| 송장 생성 | Oracle Fusion Financials에서 송장 거래 레코드가 생성된 시점을 나타냅니다. 이는 매출채권 모듈에서 송장 수명 주기가 공식적으로 시작되는 시점이며, 분석의 기본 시작점으로 사용됩니다. | ||
| 중요한 이유 이 이벤트는 송장 처리 과정의 중요한 시작점입니다. 매출채권 회전일수(DSO)와 송장 결제 주기 시간 등 이후의 모든 주기 시간 계산은 이 최초 시각을 기준으로 합니다. 확보 방법 특정 TRX_NUMBER(송장 번호)에 대해 RA_CUSTOMER_TRX_ALL 테이블의 CREATION_DATE 또는 TRX_DATE 열에서 직접 가져오는 이벤트입니다. 기록 이벤트 시각은 RA_CUSTOMER_TRX_ALL 테이블의 CREATION_DATE입니다. 이벤트 유형 explicit | |||
| 연체 안내 절차 시작 | 연체 송장에 대한 연체 안내 프로세스가 공식적으로 시작되었음을 나타냅니다. 보통 첫 공식 연체 안내문 발송이 포함됩니다. 연체 안내 일괄 작업이 실행되어 해당 송장이 포함될 때 기록됩니다. | ||
| 중요한 이유 이 활동을 추적하면 연체 안내의 효과와 정책 준수 수준을 측정할 수 있습니다. 연체 안내를 시작한 뒤 대금이 납부되기까지 걸리는 시간을 측정하는 기준이 됩니다. 확보 방법 Oracle Advanced Collections 모듈에 기록됩니다. 거래 ID와 연결된 IEX_DUNNINGS 등의 테이블에서 연체 안내 레코드의 생성일을 확인할 수 있습니다. 기록 송장과 연결된 IEX_DUNNINGS 테이블 레코드의 생성일입니다. 이벤트 유형 explicit | |||
| 고객에게 송장 발송 | 송장이 전자 방식이나 인쇄물로 고객에게 공식 전달되었음을 나타냅니다. 전달 모듈에 명시적으로 기록되거나 송장 인쇄일을 바탕으로 추론할 수 있습니다. | ||
| 중요한 이유 이 활동은 고객의 결제 기한 계산이 시작되는 시점을 나타냅니다. 이를 추적하면 연체 일수를 정확히 계산하고 송장 생성부터 고객 통지까지의 지연을 분석할 수 있습니다. 확보 방법 RA_CUSTOMER_TRX_ALL의 LAST_PRINTED_DATE에서 가져올 수 있습니다. 또는 이메일 전달 시스템이나 다른 커뮤니케이션 플랫폼의 연동 로그를 바탕으로 추론할 수 있습니다. 기록 RA_CUSTOMER_TRX_ALL의 LAST_PRINTED_DATE 또는 전달 로그의 상태를 사용합니다. 이벤트 유형 inferred | |||
| 분쟁 등록 | 고객이 송장 금액의 일부 또는 전부에 대해 공식적으로 이의를 제기했음을 나타냅니다. 일반적으로 송장의 결제 일정 상태 변경으로 기록됩니다. | ||
| 중요한 이유 이 활동은 분쟁 해결 프로세스의 시작점입니다. 등록부터 해결까지 걸리는 시간을 분석하면 대금 회수를 늦추는 병목을 찾을 수 있습니다. 확보 방법 AR_PAYMENT_SCHEDULES_ALL 테이블의 STATUS가 'DS'(분쟁 중)로 변경된 경우를 바탕으로 추론합니다. 시각은 감사 테이블이나 마지막 업데이트 날짜에서 가져올 수 있습니다. 기록 송장에 대해 AR_PAYMENT_SCHEDULES_ALL.STATUS가 'DS'로 변경되는 시점을 감지합니다. 이벤트 유형 inferred | |||
| 분쟁 해결 | 등록된 분쟁에 대한 조사가 끝나고 해결된 상태를 나타냅니다. 송장의 분쟁 상태가 해제될 때 기록됩니다. | ||
| 중요한 이유 이 이벤트는 분쟁 해결 주기의 종료를 나타냅니다. '분쟁 등록'부터 이 이벤트까지 걸리는 시간은 운영 효율성과 현금 흐름에 미치는 영향을 측정하는 주요 KPI입니다. 확보 방법 AR_PAYMENT_SCHEDULES_ALL의 STATUS가 'DS'(분쟁 중)에서 'OP'(미결)로 바뀌거나, 대변 메모 또는 조정 후 'CL'(마감)로 변경될 때 추론합니다. 기록 AR_PAYMENT_SCHEDULES_ALL.STATUS가 'DS'에서 다른 상태로 변경되는 시점을 감지합니다. 이벤트 유형 inferred | |||
| 송장 마감 | 결제, 대변 메모 적용 또는 조정으로 송장의 미수 잔액이 0이 되면 발생합니다. 송장 수명 주기가 성공적으로 완료되었음을 나타냅니다. | ||
| 중요한 이유 이 이벤트는 프로세스가 성공적으로 종료되는 주요 시점입니다. 송장 마감 현황을 모니터링하는 일은 매출채권 포트폴리오의 전반적인 상태를 파악하는 데 중요합니다. 확보 방법 AR_PAYMENT_SCHEDULES_ALL 테이블의 STATUS가 'CL'(마감)로 변경된 경우를 바탕으로 추론합니다. 시각은 해당 변경의 LAST_UPDATE_DATE입니다. 기록 송장에 대해 AR_PAYMENT_SCHEDULES_ALL.STATUS가 'CL'이 되는 시점을 감지합니다. 이벤트 유형 inferred | |||
| 신용 검토 완료 | 송장과 연결된 고객의 신용 평가가 완료되었음을 나타냅니다. 일반적으로 송장 생성일과 해당 고객 계정의 가장 최근 신용 검토 완료일을 연결해 이 이벤트를 추론하며, 신용 관련 분석의 기준점으로 활용합니다. | ||
| 중요한 이유 신용 검토부터 주문 접수까지 걸리는 시간을 분석하면 주문에서 현금 회수까지 이어지는 주기의 초기 단계에서 발생하는 지연을 찾을 수 있습니다. 이 분석은 신용 승인 주기 시간 KPI를 측정하고 신용 결정의 영향을 파악하는 데 기초가 됩니다. 확보 방법 송장의 고객(RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID)에 대해 HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE를 조회해 추론합니다. 이벤트 시각은 송장의 CREATION_DATE보다 앞선 LAST_CREDIT_REVIEW_DATE입니다. 기록 송장 생성 전에 완료된 고객의 가장 최근 신용 검토일을 송장에 연결합니다. 이벤트 유형 inferred | |||
| 지급 약속 등록 | 고객이 특정 날짜에 대금을 지급하겠다고 약속한 내용을 시스템에 공식 기록한 것입니다. 채권 회수 활동의 주요 결과 중 하나입니다. | ||
| 중요한 이유 지급 약속과 이행률을 추적하는 일은 채권 회수 담당자의 주요 성과 지표입니다. 연체 매출채권의 현금 흐름을 예측하고 담당자의 효과를 평가하는 데 도움이 됩니다. 확보 방법 Oracle Advanced Collections에서 직접 생성됩니다. 생성일은 IEX_PROMISE_DETAILS 테이블에서 가져옵니다. 기록 해당 송장에 대한 IEX_PROMISE_DETAILS 테이블의 생성일입니다. 이벤트 유형 explicit | |||
| 채권 회수 담당자 활동 완료 | 채권 회수 담당자가 전화, 이메일 발송, 상담 기록 입력 등 직접 수행한 활동을 나타냅니다. 이러한 활동은 채권 회수 모듈에서 '활동' 또는 '상호작용'으로 기록됩니다. | ||
| 중요한 이유 담당자의 활동을 모니터링하면 수작업 채권 회수 워크플로의 효율과 효과를 측정할 수 있습니다. 활동 빈도와 대금 회수 성공률 간의 관계도 분석할 수 있습니다. 확보 방법 Oracle Advanced Collections의 상호작용 또는 활동 이력 테이블에서 가져옵니다. 예를 들어 JTF_IH_ACTIVITIES를 고객 및 해당 송장과 연결해 사용할 수 있습니다. 기록 JTF_IH_ACTIVITIES에서 관련 결과 코드나 사유 코드가 있는 레코드의 생성 시각입니다. 이벤트 유형 explicit | |||
| 채권 회수 전략 배정 | 연체 송장이나 고객에게 자동 채권 회수 전략이 배정될 때 발생합니다. 이 전략은 시스템이나 담당자가 따를 단계와 활동을 정의합니다. | ||
| 중요한 이유 이 이벤트를 통해 채권 회수 프로세스의 자동화 수준을 파악할 수 있습니다. 배정된 전략과 결과를 분석하면 고객군별 회수 방식을 최적화하는 데 도움이 됩니다. 확보 방법 Oracle Advanced Collections 모듈에 기록됩니다. 일반적으로 IEX_STRATEGIES 등의 테이블이나 관련 객체에서 전략 배정일을 확인합니다. 기록 고객 또는 거래와 연결된 채권 회수 테이블의 전략 작업 항목 생성일입니다. 이벤트 유형 explicit | |||
데이터 추출 안내
단계
- Oracle BI Publisher에 접속: Oracle Fusion Financials 환경에 로그인합니다. Navigator 아이콘을 클릭한 다음 Tools > Reports and Analytics를 선택해 Reports and Analytics 영역으로 이동합니다.
- 새 데이터 모델 만들기: Reports and Analytics 창에서 'Browse Catalog' 버튼을 클릭합니다. 카탈로그에서 'New' 드롭다운 메뉴를 클릭하고 'Data Model'을 선택합니다.
- SQL Query 데이터 세트 정의: Data Model 편집기에서 '+' 아이콘을 클릭해 데이터 세트를 추가하고 'SQL Query'를 선택합니다.
- 데이터 소스 설정: 새 데이터 세트 창에서 'CreditCollectionsEventLog'와 같이 알아보기 쉬운 이름을 입력합니다. Data Source로 'FSCM' 또는 해당 Oracle Fusion 애플리케이션 데이터베이스를 선택합니다. Type of SQL은 'Standard SQL'로 설정합니다.
- SQL Query 입력: 이 문서의 'query' 섹션에 있는 전체 SQL Query를 복사해 SQL Query 입력란에 붙여 넣습니다.
- 쿼리 매개변수 정의: 쿼리는 날짜 범위를 필터링하기 위해
:P_START_DATE및:P_END_DATE와 같은 매개변수를 사용합니다. BI Publisher가 이를 자동으로 감지합니다. 매개변수를 사용자 입력값으로 설정하고 데이터 유형을 'Date'로 지정할 수 있습니다. - 데이터 모델 저장 및 테스트: 데이터 모델을 공유 폴더나 사용자 지정 폴더에 저장합니다. 쿼리가 작동하는지 확인하려면 'Data' 탭으로 이동해 최근 날짜 범위와 같은 샘플 매개변수 값을 입력한 다음 'View'를 클릭해 출력 샘플을 확인합니다. 모든 열이 올바르게 표시되는지 확인합니다.
- 새 보고서 만들기: 카탈로그로 돌아가 'New' 드롭다운을 클릭하고 'Report'를 선택합니다. 'Create Report' 대화상자에서 'Use Data Model'을 선택하고 방금 저장한 데이터 모델을 찾습니다.
- 보고서 속성 설정: 보고서 편집기에서 데이터 추출에는 간단한 표 레이아웃이면 충분합니다. 기본 출력 형식을 설정합니다. process mining에는 CSV를 권장합니다. 'View a List'를 클릭하고 'Output Formats' 목록에서 'CSV'를 찾아 체크합니다. 사용하기 편하도록 다른 형식의 체크를 해제할 수 있습니다.
- 보고서 저장: 데이터 모델과 같은 폴더에 보고서를 저장합니다.
- 추출 일정 설정: 추출을 자동화하려면 보고서 실행 일정을 설정할 수 있습니다. 보고서를 열고 'Actions'를 클릭한 다음 'Schedule'을 선택합니다. 매일과 같은 실행 주기를 설정하고, 출력 형식은 CSV로 지정한 뒤 콘텐츠 서버 디렉터리나 FTP를 통한 외부 서버 등 전달 위치를 지정합니다.
구성
- 사전 요건: 보고서를 만들고 실행하는 사용자에게는 적절한 BI 역할(예: 'BI Administrator' 또는 'BI Author')과 기본 Financials 테이블(AR, IEX, HZ, JTF)에 접근할 수 있는 데이터 보안 권한이 있어야 합니다.
- 데이터 소스: 쿼리는 일반적으로 'FSCM'으로 표시되는 기본 애플리케이션 데이터베이스에서 실행해야 합니다.
- 날짜 범위 매개변수: 데이터 양을 제한하려면
:P_START_DATE및:P_END_DATE매개변수를 반드시 사용해야 합니다. 초기 테스트에는 한 달처럼 짧은 범위를 사용하세요. 운영 환경에서는 일반적으로 3~6개월의 이동 기간을 사용합니다. - 필터링: 대규모 조직에서는
invoices_base공통 테이블 식의WHERE절에BU_NAME(Business Unit Name) 매개변수를 추가해 한 번에 하나의 사업부 데이터만 처리하는 방안을 고려하세요. - 성능 고려 사항: 쿼리는 규모가 큰 트랜잭션 테이블 여러 개를 조인합니다. 필터 없이 넓은 날짜 범위로 실행하면 BI Publisher에서 처리 시간이 길어지거나 시간 초과가 발생할 수 있습니다. 사용량이 적은 시간대에 보고서를 실행하도록 예약하세요.
- 출력 형식: 기본 출력 형식이나 예약 실행 출력 형식이 CSV인지 확인합니다. CSV는 process mining 도구에서 쉽게 사용할 수 있는 구분자 기반 파일입니다. CSV 출력 속성에서 구분자와 문자 인코딩이 올바르게 설정되어 있는지 확인하세요.
샘플 쿼리 sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' 시작할 준비가 되셨나요?
이 템플릿으로 분석에 필요한 데이터를 준비하고 신용 관리 및 채권 회수 프로세스에 관한 유용한 정보를 확인하세요. 지금 프로세스 최적화를 시작하세요.
지금 신용 관리 및 채권 회수를 최적화하세요
Oracle Fusion에서 처리 시간을 30% 줄이고 재무 건전성을 높이세요.
신용카드 없이 이용할 수 있습니다. 몇 분이면 시작할 수 있습니다.