주문-수금 판매 주문 처리 데이터 템플릿
주문-수금 판매 주문 처리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 실무 안내
주문-수금 판매 주문 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 판매 주문 SalesOrder | 주문부터 현금 회수까지의 프로세스에서 기본 케이스로 사용하는 판매 주문의 고유 식별자입니다. | ||
| 설명 판매 주문 번호는 고객 주문을 수명 주기 전체에 걸쳐 고유하게 식별합니다. 주문 생성과 확인부터 이행, 송장 발행, 최종 결제까지 관련 활동을 연결하는 기준이 됩니다. process mining에서는 관련 이벤트를 하나의 케이스로 묶는 데 이 속성이 필요합니다. 판매 주문별로 분석하면 전체 프로세스를 파악하고, 총 소요 시간을 계산하며, 주문별 프로세스 변형을 찾고, 여러 부서와 시스템을 거치는 주문의 흐름을 추적할 수 있습니다. 중요한 이유 케이스 ID입니다. 모든 프로세스 이벤트를 연결해 개별 고객 주문의 전체 흐름을 추적할 수 있습니다. 확보 방법 일반적으로 Oracle Fusion의 판매 주문 헤더 테이블에서 확인할 수 있습니다. 예를 들어 DOO_HEADERS_ALL 테이블을 참조하세요. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 SO-100567SO-100568SO-100569 | |||
| 이벤트 시각 EventTime | 판매 주문에서 특정 활동이나 이벤트가 발생한 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 프로세스의 각 활동에 날짜와 시간을 부여해 이벤트의 시간 순서를 정합니다. 각 단계가 정확히 언제 발생했는지 기록하므로 시간 기준 프로세스 분석의 토대가 됩니다. process mining에서는 EventTime을 사용해 소요 시간, 활동 간 경과 시간, 케이스 전체 처리 시간을 계산합니다. 대기 시간을 기준으로 성과를 분석하고 병목을 찾으며, 적시성에 관한 서비스 수준 계약(SLA) 준수 여부를 모니터링할 수 있습니다. 시간 기반 KPI와 대시보드는 모두 이 속성의 정확성에 좌우됩니다. 중요한 이유 이 타임스탬프는 이벤트의 시간 순서를 정하고 소요 시간 등 시간 기반 지표를 계산하는 데 필요합니다. 확보 방법 주문 생성일, 배송일, 송장일, 결제일 등 Oracle Fusion의 여러 테이블에 있는 타임스탬프 필드에서 가져와 생성하는 파생 속성입니다. 예시 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| 활동명 ActivityName | 판매 주문 프로세스에서 발생한 구체적인 업무 이벤트나 작업의 이름입니다. | ||
| 설명 이 속성은 판매 주문에서 특정 시점에 수행된 단계를 나타냅니다. 예를 들어 '판매 주문 생성', '상품 배송', '결제 수령' 등이 있습니다. 각 케이스에서 활동이 이어지는 순서가 프로세스 흐름을 구성합니다. ActivityName 분석은 process mining의 기본입니다. 프로세스 맵을 시각화하고 다양한 프로세스 변형을 발견하며 케이스가 쌓이는 병목을 찾을 수 있습니다. 단계 간 전환 시간과 주문부터 현금 회수까지의 프로세스 운영 순서를 파악하는 데도 활용됩니다. 중요한 이유 프로세스 맵의 단계를 정의해 프로세스 흐름을 시각화하고 분석할 수 있습니다. 확보 방법 Oracle Fusion의 여러 테이블에서 거래 상태나 이벤트 유형을 가져와 표준 활동명 목록에 매핑해 생성하는 파생 속성입니다. 예를 들어 주문 상태, 배송 상태, 송장 상태 등을 매핑합니다. 예시 판매 주문 생성상품 출하송장 생성결제 수령 | |||
| 결제 기한 PaymentDueDate | 고객이 송장 대금을 결제해야 하는 날짜입니다. | ||
| 설명 결제 기한은 송장 발행일과 고객과 합의한 결제 조건을 기준으로 계산합니다. 기한 내 결제를 위한 마감일입니다. 이 속성은 '기한 내 결제 회수율' KPI를 산출하는 데 필요합니다. 결제 기한과 실제 결제 수령일을 비교해 결제가 제때 이루어졌는지 판단할 수 있습니다. 이를 통해 매출채권 성과를 모니터링하고 현금 흐름을 관리할 수 있습니다. 중요한 이유 기한 내 결제율을 계산하는 마감일로, 현금 흐름 효율을 측정하는 주요 지표입니다. 확보 방법 Oracle Fusion의 매출채권 또는 송장 테이블에서 확인할 수 있습니다. 예를 들어 AR_PAYMENT_SCHEDULES_ALL 테이블을 참조하세요. 예시 2023-06-192023-07-012023-06-25 | |||
| 고객명 CustomerName | 판매 주문을 제출한 고객의 이름입니다. | ||
| 설명 이 속성은 판매 주문과 연결된 고객 계정의 법적 명칭을 식별합니다. 고객 관점에서 프로세스를 구분하고 분석하는 데 사용하는 주요 기준입니다. 고객별 분석을 통해 특정 고객의 처리 시간이 길거나 재작업이 많거나 프로세스 편차가 발생하는지 확인할 수 있습니다. 분석 결과를 고객 서비스 개선과 주요 고객에 맞춘 프로세스 설계, 고객 만족도에 영향을 미치는 문제 조사에 활용할 수 있습니다. 중요한 이유 고객별로 프로세스를 분석해 특정 고객에게 영향을 미치는 문제를 찾고 고객 만족도를 높일 수 있습니다. 확보 방법 고객 마스터 데이터 테이블(예: HZ_PARTIES)에서 가져오며 고객 ID를 통해 판매 주문과 연결합니다. 예시 Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| 사용자 이름 UserName | 활동을 수행한 사용자의 이름 또는 ID입니다. | ||
| 설명 이 속성은 특정 프로세스 단계를 수행한 직원이나 시스템 사용자를 식별합니다. 사용자별 성과와 업무량 분포, 표준 절차 준수 여부를 분석할 수 있습니다. 사용자별 분석을 통해 교육이 필요한 부분을 찾고 성과가 높은 개인이나 팀을 파악하며 특정 사용자가 일으킨 편차를 조사할 수 있습니다. 누가 어떤 작업을 수행했는지 추적하므로 규정 준수와 감사에도 유용합니다. 중요한 이유 사용자별 성과와 업무량 분포를 분석하고 개인별 수작업 재처리 패턴을 찾을 수 있습니다. 확보 방법 일반적으로 Oracle Fusion 거래 테이블의 CREATED_BY 또는 LAST_UPDATED_BY와 같은 필드에서 가져옵니다. FND_USER와 같은 사용자 마스터 테이블과 연결되는 경우가 많습니다. 예시 john.smithjane.doesystem_batch_user | |||
| 실제 배송일 ActualDeliveryDate | 상품이 실제로 고객에게 배송된 날짜입니다. | ||
| 설명 이 속성은 최종 배송일을 기록하며 프로세스의 이행 단계가 완료된 시점을 나타냅니다. 계획일이나 요청일과 비교하는 실제 결과입니다. 이 날짜를 RequestedDeliveryDate와 비교해 기한 내 배송 성과를 계산합니다. '기한 내 배송률' KPI와 '배송 SLA' 대시보드에 필요한 값으로, 물류와 공급망의 효과를 명확하게 측정할 수 있습니다. 중요한 이유 기한 내 배송률을 계산하고 고객 요청에 따른 이행 성과를 평가하는 실제 완료일입니다. 확보 방법 Oracle Fusion의 배송 및 인도 거래 테이블에서 가져옵니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 2023-05-202023-06-032023-05-25 | |||
| 요청 배송일 RequestedDeliveryDate | 고객이 요청한 주문 배송일입니다. | ||
| 설명 이 속성은 고객이 상품을 받기를 원하는 날짜를 기록합니다. 주문부터 현금 회수까지의 프로세스 중 이행 단계에서 성과 목표로 사용합니다. '기한 내 배송률' KPI를 계산하고 '배송 서비스 수준 계약(SLA)' 대시보드를 구성하는 데 필요합니다. 이 날짜를 ActualDeliveryDate와 비교하면 고객의 기대에 부응했는지 측정하고 배송 지연의 근본 원인을 찾을 수 있습니다. 중요한 이유 기한 내 배송 성과와 고객 서비스 수준 계약(SLA) 준수 여부를 측정하는 기준입니다. 확보 방법 일반적으로 Oracle Fusion의 판매 주문 라인 품목 테이블에서 확인할 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 2023-05-202023-06-012023-05-25 | |||
| 자동 수행 여부 IsAutomated | 활동을 시스템이 자동으로 수행했는지 사용자가 직접 수행했는지 나타내는 플래그입니다. | ||
| 설명 이 불리언 속성은 시스템이 처리한 이벤트(예: 자동 신용도 확인, 시스템 생성 송장)와 사용자가 직접 수행한 작업을 구분합니다. 일반적으로 활동에 연결된 사용자 이름을 기준으로 파생하며, 일반 시스템 ID가 있으면 자동 처리로 판단합니다. 이 속성을 분석하면 프로세스의 자동화 수준을 측정할 수 있으며 '수작업 재처리 주문 비율' KPI의 직접 입력값으로 사용할 수 있습니다. 시간이 오래 걸리거나 오류가 잦은 수작업 단계를 파악해 추가 자동화 기회를 찾을 수 있습니다. 중요한 이유 프로세스의 자동화 수준을 수치화하고 비용이 많이 드는 수작업을 줄일 기회를 찾을 수 있습니다. 확보 방법 일반적으로 UserName 속성에 규칙을 적용해 생성하는 파생 필드입니다. 예를 들어 사용자가 'SYSTEM' 또는 'BATCH'이면 이 플래그를 true로 설정합니다. 예시 truefalse | |||
| 판매 주문 총액 SalesOrderTotalAmount | 판매 주문의 총 금액입니다. | ||
| 설명 이 속성은 판매 주문 전체에 대해 고객에게 청구되는 총액을 나타냅니다. 모든 라인 품목의 금액과 세금, 기타 비용을 합산하며 할인은 적용하기 전 금액입니다. 프로세스 분석에서는 금액 기준 process mining에 활용됩니다. 주문을 금액대별로 나누어 고액 주문과 소액 주문의 프로세스 경로나 소요 시간이 다른지 확인할 수 있습니다. 재무 영향이 큰 케이스를 우선으로 프로세스 개선을 추진하는 데도 도움이 됩니다. 중요한 이유 재무 영향을 분석해 고액 주문의 프로세스 개선 우선순위를 정하고 비용 발생 요인을 파악할 수 있습니다. 확보 방법 일반적으로 Oracle Fusion의 판매 주문 헤더 테이블에서 확인할 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 5250.00125000.75980.50 | |||
| 판매 채널 SalesChannel | 판매 주문이 접수된 채널입니다. | ||
| 설명 이 속성은 판매 주문의 유입 경로를 구분합니다. 예를 들어 '웹', '직접 판매', '파트너', 'EDI' 등이 있습니다. 주문이 조직에 접수된 경로를 파악할 수 있습니다. 판매 채널별로 프로세스를 나누면 '판매 채널 성과 개요' 대시보드에서 채널별 효율성, 소요 시간, 오류율을 비교할 수 있습니다. 이를 통해 주문 처리에 가장 효과적인 채널과 프로세스 개선이나 추가 자동화가 필요한 채널을 찾을 수 있습니다. 중요한 이유 채널별 성과를 분석해 주문 처리 효율이 높은 채널과 낮은 채널을 찾을 수 있습니다. 확보 방법 판매 주문 헤더의 전용 필드에 저장될 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 직접 판매웹 포털EDI재판매업체 | |||
| 결제 조건 PaymentTerms | 고객과 합의한 결제 조건입니다. | ||
| 설명 이 속성은 고객이 송장 대금을 결제해야 하는 조건을 나타냅니다. 예를 들어 '30일 이내 결제' 또는 '60일 이내 결제'가 있습니다. 이 조건을 기준으로 PaymentDueDate를 계산합니다. 결제 조건별로 프로세스를 나누면 결제 주기 소요 시간의 차이를 설명하는 데 도움이 됩니다. 조건에 따라 결제 행태가 달라지므로 '기한 내 결제율' KPI를 해석할 때 참고할 수 있습니다. 신용 정책과 현금 흐름 예측에도 활용할 수 있습니다. 중요한 이유 결제 행태를 분석하는 데 필요한 맥락을 제공하고 송장 발행부터 결제까지 걸리는 시간의 차이를 설명하는 데 도움이 됩니다. 확보 방법 Oracle Fusion의 판매 주문 또는 고객 계정 수준에서 확인할 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 30일 이내 결제60일 이내 결제수령 즉시 결제 | |||
| 결제 지연 여부 IsLatePayment | 결제 기한이 지난 뒤 결제액을 수령한 경우 true로 설정되는 계산 플래그입니다. | ||
| 설명 이 불리언 속성은 실제 결제 수령일과 PaymentDueDate를 비교해 생성합니다. 송장이 기한 내 결제되었는지 명확하게 나타냅니다. 이 속성은 '기한 내 결제율' KPI를 계산하는 데 사용합니다. 기한 내 결제와 지연 결제를 구분해 지연 고객의 특성, 지연의 일반적인 원인, 운전자본에 미치는 재무 영향을 분석할 수 있습니다. 중요한 이유 수금 효과를 직접 측정하고 연체된 결제를 간편하게 분석합니다. 확보 방법 계산 필드입니다. 계산식은 다음과 같습니다. PaymentReceivedDate > PaymentDueDate. 예시 falsetrue | |||
| 고객 국가 CustomerCountry | 고객이 위치한 국가입니다. | ||
| 설명 이 속성은 고객의 배송지 또는 청구지 주소에서 국가 정보를 가져옵니다. 지역별 분석에 사용하는 주요 기준입니다. 국가별로 프로세스를 나누면 프로세스 성과, 소요 시간, 결제 행태의 지역별 차이를 확인할 수 있습니다. 현지 규정, 물류 문제, 시장 상황이 주문부터 현금 회수까지의 프로세스에 미치는 영향을 파악하는 데 유용합니다. 중요한 이유 지역별 프로세스 효율성, 규정 준수, 고객 행동의 차이를 파악할 수 있습니다. 확보 방법 판매 주문과 연결된 고객 마스터 데이터 테이블(HZ_LOCATIONS, HZ_PARTY_SITES)에서 가져옵니다. 예시 USA독일일본 | |||
| 기한 내 배송 여부 IsOnTimeDelivery | 실제 배송일이 요청 배송일과 같거나 빠르면 true로 설정되는 계산 플래그입니다. | ||
| 설명 이 불리언 속성은 ActualDeliveryDate와 RequestedDeliveryDate를 비교해 생성합니다. 케이스별 배송 성과를 간단히 나타냅니다. 이 플래그는 전체 '기한 내 배송률' KPI를 계산하는 기준입니다. 필터링과 분석을 간소화해 지연 주문을 빠르게 추려내고 지연 요인의 근본 원인을 분석할 수 있습니다. 중요한 이유 고객의 기대에 비추어 이행 성과를 직접 측정하고 지연 주문을 쉽게 분석할 수 있습니다. 확보 방법 계산 필드입니다. 계산식은 ActualDeliveryDate <= RequestedDeliveryDate입니다. 예시 truefalse | |||
| 배송 방법 ShippingMethod | 고객에게 상품을 배송할 때 사용하는 방법이나 운송업체입니다. | ||
| 설명 이 속성은 배송에 사용된 물류 운송업체나 서비스 수준을 나타냅니다. 예를 들어 '육상 화물', '항공 특송', '지역 배송업체' 등이 있습니다. 이 정보는 '배송 방법별 배송 규정 준수' 대시보드에 필요합니다. 배송 방법과 운송업체별 기한 내 배송 성과와 배송 비용을 비교해 물류 전략과 공급업체를 최적화할 수 있습니다. 중요한 이유 운송업체와 배송 방법별 성과를 비교해 물류 분석을 지원합니다. 확보 방법 Oracle Fusion의 배송 및 이행 테이블에서 확인할 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 FedEx 일반 배송UPS 익일 항공 배송DHL 국제 배송 | |||
| 사업부 BusinessUnitName | 판매 주문을 담당하는 내부 사업부의 이름입니다. | ||
| 설명 이 속성은 거래를 담당하는 회사 내 특정 부서나 운영 조직을 나타냅니다. 조직 내 여러 부문의 성과를 비교할 수 있습니다. 사업부별로 프로세스를 나누면 회사 내 효율성, 비용, 규정 준수의 차이를 파악할 수 있습니다. 성과가 높은 사업부의 모범 사례를 공유하거나 성과가 낮은 사업부에 맞춤형 프로세스 개선을 적용할 수 있습니다. 중요한 이유 조직 단위별 성과를 비교하고 프로세스 일관성을 분석할 수 있습니다. 확보 방법 일반적으로 판매 주문 헤더에서 확인할 수 있으며 Oracle Fusion에 정의된 조직 구조와 연결됩니다. 예시 사업부-북미사업부-유럽·중동·아프리카글로벌 서비스 | |||
| 소스 시스템 SourceSystemIdentifier | 이벤트 데이터를 추출한 소스 시스템을 식별합니다. | ||
| 설명 이 속성은 데이터의 출처를 나타내며, 주문부터 현금 회수까지의 프로세스에 여러 시스템이 관여하는 환경에서 특히 유용합니다. 예를 들어 주문 데이터는 Oracle Fusion에서, 배송 데이터는 외부 물류 시스템에서 가져올 수 있습니다. 분석 시 데이터 계보를 파악하고 특정 시스템의 이벤트만 프로세스 화면에 표시하도록 필터링할 수 있습니다. 데이터 검증과 여러 IT 환경에 걸친 프로세스 분절을 찾는 데도 중요합니다. 중요한 이유 데이터 출처를 파악할 수 있어 여러 시스템을 사용하는 환경에서 데이터 거버넌스와 문제 해결에 도움이 됩니다. 확보 방법 일반적으로 데이터 추출 및 변환 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다. 예시 Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| 송장 번호 InvoiceNumber | 고객 송장의 고유 식별자입니다. | ||
| 설명 이 속성은 판매 주문에서 생성된 송장에 부여되는 고유 번호입니다. 판매 및 이행 활동을 프로세스의 재무 정산 단계와 연결합니다. 판매 주문을 기본 케이스 ID로 사용하지만, 송장 번호는 송장 발행과 결제 하위 프로세스를 분석하는 데 필요합니다. 송장 수정, 분쟁, 결제 상태를 추적하고 '송장 정확도 및 재작업 분석'과 같은 대시보드를 구성하는 데 활용됩니다. 중요한 이유 매출채권 프로세스와 연결하는 데 필요하며 송장 재작업과 결제 주기를 분석할 수 있습니다. 확보 방법 Oracle Fusion의 매출채권 거래 테이블에서 확인할 수 있습니다. 예를 들어 RA_CUSTOMER_TRX_ALL 테이블을 참조하세요. 예시 INV-93485INV-93486INV-93487 | |||
| 제품명 ProductName | 판매하는 제품이나 서비스의 이름입니다. | ||
| 설명 이 속성은 판매 주문 라인의 품목을 나타냅니다. 주문에 여러 라인이 있으면 라인 품목 수준에서 케이스를 분석하거나 헤더 수준으로 집계할 수 있습니다. 제품별 분석을 통해 특정 제품이 잦은 배송 지연이나 결제 문제 등 복잡하거나 문제가 많은 프로세스 흐름과 관련이 있는지 파악할 수 있습니다. 분석 결과를 제품 관리와 공급망 전략에 활용할 수 있습니다. 중요한 이유 제품별 프로세스 성과를 분석해 이행이나 송장 발행 경로가 복잡할 수 있는 품목을 찾을 수 있습니다. 확보 방법 판매 주문 라인 품목 테이블에서 가져와 제품 마스터 테이블과 조인합니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 표준 위젯 X1프리미엄 서비스 패키지부품 Y2-B | |||
| 주문 유형 OrderType | '표준 주문'이나 '반품 주문'과 같이 판매 주문을 분류하는 유형입니다. | ||
| 설명 주문 유형은 업무 목적에 따라 판매 주문을 분류하는 데 사용합니다. 일반적인 유형으로 표준 판매, 서비스 주문, 반품 승인(RMA), 내부 주문 등이 있습니다. 주문 유형별 프로세스 분석이 중요한 이유는 유형마다 프로세스 흐름과 성과 목표가 다를 수 있기 때문입니다. 유형별로 구분하면 의도된 정상적인 프로세스 차이를 파악해 편차로 잘못 해석하는 일을 방지할 수 있습니다. 중요한 이유 표준 주문과 반품 주문처럼 정당하게 구분되는 프로세스 흐름을 나누어 공정하고 정확하게 분석할 수 있습니다. 확보 방법 일반적으로 Oracle Fusion의 판매 주문 헤더 테이블 필드에서 확인할 수 있습니다. 자세한 내용은 Oracle Fusion Financials 문서를 확인하세요. 예시 표준 판매 주문반품 승인서비스 주문 | |||
| 청구서 수정 여부 IsInvoiceCorrected | 청구서가 처음 생성된 후 수정 또는 정정되었는지 나타내는 플래그입니다. | ||
| 설명 이 불리언 속성은 청구서에 'Invoice Corrected' 활동이 기록되어 수정 절차를 거친 경우 true로 설정됩니다. 청구 단계에서 재작업이 발생한 사례를 표시합니다. 'Invoice Accuracy & Rework Analysis' 대시보드와 'Invoice Rework Rate' KPI의 주요 입력값입니다. 청구 오류가 발생한 정도를 파악하고, 수정이 필요한 원인을 분석하는 데 도움이 됩니다. 이를 통해 수작업과 결제 지연을 줄일 수 있습니다. 중요한 이유 청구서 재작업을 식별합니다. 이는 프로세스 비효율, 데이터 품질 문제, 결제 지연 가능성을 보여주는 주요 지표입니다. 확보 방법 계산 필드입니다. 일반적으로 케이스의 이벤트 로그에 'Invoice Corrected' 활동이 있으면 true로 설정됩니다. 예시 falsetrue | |||
| 최종 데이터 업데이트 LastUpdateDate | 소스 시스템에서 이 이벤트의 데이터가 마지막으로 새로 고쳐진 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 process mining 데이터 세트의 데이터를 마지막으로 추출하거나 업데이트한 시점을 기록합니다. 분석 대상 데이터가 얼마나 최신인지 확인할 수 있습니다. 사용자는 이 정보를 바탕으로 프로세스 분석이 현재 상황을 얼마나 반영하는지 파악할 수 있습니다. 데이터의 최신성에 대한 기대치를 관리하고 데이터 새로 고침 일정을 설정하고 모니터링하는 데도 유용합니다. 중요한 이유 데이터의 최신성을 나타내므로 사용자가 프로세스 분석의 최신 여부를 확인할 수 있습니다. 확보 방법 데이터를 추출하고 변환할 때마다 데이터 세트에 생성해 기록하는 값입니다. 예시 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
주문-수금 판매 주문 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 결제 수령 | 고객의 결제가 접수되어 매출채권에서 송장에 적용된 활동입니다. 현금 수령 적용 내역이 전기될 때 기록됩니다. | ||
| 중요한 이유 '주문부터 현금 회수까지의 전체 소요 시간'과 '기한 내 결제율'을 측정하는 주요 기준점입니다. 판매가 현금으로 전환되는 시점을 나타냅니다. 확보 방법 Oracle Accounts Receivable에 명시적으로 기록되는 이벤트입니다. 수령액을 송장에 적용하면 AR_RECEIVABLE_APPLICATIONS_ALL과 같은 현금 수령 테이블에 기록됩니다. 기록 AR의 현금 수령 적용 레코드에서 'apply date' 타임스탬프를 가져옵니다. 이벤트 유형 explicit | |||
| 상품 출하 | 상품이 창고에서 출고되어 고객에게 배송되기 시작하는 시점을 나타냅니다. Oracle Shipping에서 출하 확인 거래가 처리될 때 기록됩니다. | ||
| 중요한 이유 이 주요 시점은 이행 단계의 완료를 나타내며 송장 발행을 시작합니다. 정시 출하와 배송 리드 타임을 측정하는 데 필요합니다. 확보 방법 Oracle Shipping Execution에 명시적으로 기록되는 이벤트입니다. 출하 확인 거래가 처리되면 WSH_DELIVERY_DETAILS와 같은 배송 테이블에 출하 날짜가 포함된 레코드가 생성됩니다. 기록 주문 라인과 연결된 배송 상세 레코드의 'actual ship date' 타임스탬프를 사용합니다. 이벤트 유형 explicit | |||
| 송장 생성 | Accounts Receivable 모듈에서 고객 송장을 생성하는 활동입니다. 일반적으로 출하 확인 이벤트가 발생하면 송장 번호와 생성일이 포함된 레코드가 생성됩니다. | ||
| 중요한 이유 대금 회수 주기가 공식적으로 시작되는 시점입니다. 'Invoice to Payment Time'과 전반적인 현금 흐름 효율을 측정하는 기준이 됩니다. 확보 방법 Oracle Accounts Receivable(AR)에 명시적으로 기록되는 이벤트입니다. RA_CUSTOMER_TRX_ALL 테이블에 거래 날짜가 포함된 송장 레코드가 생성됩니다. 기록 AR 모듈에서 송장 거래가 생성된 날짜를 사용합니다. 이벤트 유형 explicit | |||
| 주문 마감 | 프로세스의 마지막 활동입니다. 판매 주문의 모든 라인에 대한 이행과 송장 발행이 완료되고 라인이 마감되면 주문 헤더 상태가 'Closed'로 업데이트됩니다. | ||
| 중요한 이유 판매 주문 수명 주기가 정상적으로 끝났음을 나타냅니다. 전체 프로세스 소요 시간을 계산하고 끝내 마감되지 않는 장기 미결 주문을 찾는 데 필요합니다. 확보 방법 DOO_HEADERS_ALL 테이블에서 판매 주문 헤더 상태가 'Closed'로 변경된 경우로 추정합니다. 최종 상태 변경 타임스탬프를 이벤트 시점으로 사용합니다. 기록 판매 주문 헤더의 상태가 'Closed'로 변경된 타임스탬프를 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 주문 확인 | 이 주요 시점은 판매 주문이 신용 승인을 포함한 초기 확인을 모두 통과해 이행 단계로 넘어갈 준비가 되었음을 나타냅니다. 일반적으로 주문 상태가 'Awaiting Shipping'이나 'Scheduled'와 같은 상태로 변경될 때 추론합니다. | ||
| 중요한 이유 이 활동은 'Average Order Confirmation Time'을 계산하는 주요 시점이며, 주문 입력 단계에서 이행 단계로 넘어가는 시점을 나타냅니다. 확보 방법 판매 주문 헤더나 라인 상태가 이행 준비 완료를 나타내는 값(예: 'Awaiting Shipping')으로 변경된 기록을 통해 추론합니다. DOO_HEADERS_ALL 또는 DOO_FULFILL_LINES_ALL의 상태 열을 확인합니다. 기록 주문 상태가 확인 완료 또는 일정 확정 상태로 변경된 타임스탬프를 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 판매 주문 생성 | 이 활동은 Oracle Fusion에 새 판매 주문을 입력하는 시점으로, 판매 주문 프로세스의 시작을 나타냅니다. 일반적으로 사용자가 Order Management 모듈에서 새 주문 레코드를 저장할 때 명시적으로 기록됩니다. | ||
| 중요한 이유 프로세스의 시작 활동으로, 전체 Order to Cash 처리 시간을 측정하고 주문 접수량을 분석하는 데 필요합니다. 확보 방법 Order Management Cloud에서 판매 주문 레코드가 생성될 때 명시적으로 기록됩니다. DOO_HEADERS_ALL 테이블에서 생성 타임스탬프를 확인합니다. 기록 판매 주문 헤더 레코드의 생성 타임스탬프를 사용합니다. 이벤트 유형 explicit | |||
| 상품 배송 완료 | 고객이 배송 상품을 수령했음을 나타냅니다. 운송업체에서 정보를 받아 Oracle Fusion에 업데이트하는 경우가 많으며, 출하 날짜에 표준 운송 시간을 더해 추론할 수도 있습니다. | ||
| 중요한 이유 'On-Time Delivery Rate' KPI를 계산하고 고객 서비스 수준을 정확하게 측정하는 데 필요한 활동입니다. 확보 방법 일반적으로 Oracle에 기본 이벤트로 기록되지 않습니다. 운송업체 연동이 설정되어 있으면 기록할 수 있고, 'Goods Shipped' 날짜에 표준 운송 시간을 더해 계산할 수도 있습니다. 시스템 분석이 필요합니다. 기록 운송업체 데이터 피드를 통해 추론하거나 출하 날짜에 평균 운송 시간을 더해 계산합니다. 이벤트 유형 inferred | |||
| 상품 피킹 | 주문 이행을 위해 창고에서 상품을 실제로 피킹하는 활동입니다. 물류 과정의 주요 단계이며 일반적으로 창고 관리 또는 배송 모듈에 기록됩니다. | ||
| 중요한 이유 이 활동을 통해 창고 운영 상황을 파악할 수 있습니다. 재고 예약부터 피킹까지 지연이 발생하면 창고의 리소스나 프로세스에 병목이 있을 수 있습니다. 확보 방법 Oracle Fusion Cloud SCM(Supply Chain Management) 모듈에 기록됩니다. 판매 주문 라인과 연결된 피킹 웨이브나 피킹 전표의 상태 변경을 통해 추론할 수 있습니다. 기록 SCM 모듈의 피킹 거래 완료 타임스탬프를 통해 추론합니다. 이벤트 유형 inferred | |||
| 송장 수정 | 기존에 생성한 송장을 오류나 고객 이의 제기로 수정하거나 재발행하거나 대변 처리할 때 발생합니다. 일반적으로 대변 메모를 생성하거나 송장의 새 버전을 만들어 기록합니다. | ||
| 중요한 이유 송장 수정 내역을 추적하면 '송장 재작업률' KPI를 산출할 수 있습니다. 이 지표는 결제를 지연시키고 관리 비용을 늘릴 수 있는 청구 프로세스의 문제를 보여줍니다. 확보 방법 원본 송장과 연결된 대변 메모가 생성되거나 RA_CUSTOMER_TRX_ALL 테이블에 동일한 송장의 후속 버전이 생성된 경우로 추정합니다. 기록 이전 송장 거래를 참조하는 대변 메모나 송장을 식별해 산출합니다. 이벤트 유형 inferred | |||
| 신용 보류 적용 | 신용 확인에 실패하거나 기타 신용 관련 문제가 발생해 판매 주문이 자동 또는 수동으로 보류될 때 발생하는 활동입니다. 일반적으로 시스템에서 주문의 보류 상태가 변경된 기록으로 확인할 수 있습니다. | ||
| 중요한 이유 신용 보류를 추적하면 주문 처리 지연의 원인을 파악하고 신용 보류 해제 절차의 효율을 측정할 수 있습니다. 확보 방법 판매 주문에 보류가 적용된 기록을 통해 추론합니다. 일반적으로 DOO_HOLDS_ALL과 같은 보류 관련 테이블에 판매 주문과 연결되어 기록됩니다. 기록 주문 보류 테이블에 'Credit' 유형의 보류 레코드가 생성된 기록을 통해 추론합니다. 이벤트 유형 inferred | |||
| 신용 확인 수행 | 고객의 신용도를 평가하기 위해 고객 계정에 대해 신용 확인을 수행하는 활동입니다. 주문 처리 워크플로에서 자동 또는 수동으로 진행되며, 완료 시 상태 업데이트나 작업 완료 기록으로 남는 경우가 많습니다. | ||
| 중요한 이유 신용 확인에 걸리는 시간을 분석하면 주문 승인 과정의 병목을 찾을 수 있습니다. 'Credit Check to Confirmed Time' KPI를 측정하는 데 중요한 활동입니다. 확보 방법 판매 주문 상태가 'Pending Credit Approval'로 변경된 기록이나 신용 관리 기능의 명시적인 이벤트 로그를 통해 추론할 수 있습니다. 기록 주문 상태 변경이나 신용 검토 작업과 관련된 타임스탬프를 통해 추론합니다. 이벤트 유형 inferred | |||
| 재고 예약 | 판매 주문 라인을 이행하기 위해 실제 재고를 할당하거나 예약하는 활동입니다. 시스템이 특정 재고를 확보해 주문 피킹 시점에 사용할 수 있도록 합니다. | ||
| 중요한 이유 이 활동을 추적하면 'Inventory Allocation Lead Time' KPI를 분석하고 주문 확인부터 재고 확보까지의 지연을 파악할 수 있습니다. 확보 방법 재고 또는 공급망 실행 모듈에 기록되는 경우가 많습니다. 이행 라인의 상태가 재고 상세 정보 입력 또는 예약을 나타내도록 변경된 기록을 통해 추론할 수 있습니다. 기록 재고 예약이나 일정 수립과 관련된 이행 라인 상태 변경을 통해 추론합니다. 이벤트 유형 inferred | |||
| 주문 라인 마감 | 개별 판매 주문 라인이 최종 마감된 상태입니다. 상품 배송과 송장 발행이 모두 완료되어 추가 거래가 예상되지 않으면 시스템에서 라인 상태를 'Closed'로 업데이트합니다. | ||
| 중요한 이유 주문 라인을 마감하면 해당 품목에 대한 계약상 의무가 모두 완료되었음을 의미합니다. 이 활동을 분석하면 이행과 결제가 끝난 뒤에도 장기간 열려 있는 주문을 찾을 수 있습니다. 확보 방법 DOO_FULFILL_LINES_ALL 테이블에서 이행 라인의 상태가 'Closed'로 변경된 경우로 추정합니다. 상태가 변경된 타임스탬프가 이벤트 시점을 나타냅니다. 기록 이행 라인의 상태가 'Closed'로 변경된 타임스탬프를 기준으로 산출합니다. 이벤트 유형 inferred | |||
| 주문 취소 | 판매 주문의 상품이 모두 배송되기 전에 주문이 취소된 상태입니다. 여러 사유로 발생할 수 있으며 최종 상태는 'Cancelled'가 됩니다. | ||
| 중요한 이유 예외 경로에 해당합니다. 취소 주문을 분석하면 재고 부족, 가격 문제, 고객 변심 등의 근본 원인을 찾아 프로세스 개선에 활용할 수 있습니다. 확보 방법 판매 주문 헤더나 라인의 상태가 'Cancelled'로 변경된 경우로 추정합니다. 상태 변경 타임스탬프를 이벤트 시점으로 기록합니다. 기록 주문 헤더나 라인의 상태가 'Cancelled'로 변경된 타임스탬프를 기준으로 산출합니다. 이벤트 유형 inferred | |||
데이터 추출 가이드
단계
- Oracle BI Publisher로 이동: BI Administrator 또는 BI Author 권한이 있는 사용자로 Oracle Fusion 환경에 로그인합니다. Navigator 메뉴에서 Tools > Reports and Analytics로 이동합니다. 'Browse Catalog'를 클릭해 Business Intelligence Catalog를 엽니다.
- 새 데이터 모델 만들기: BI Catalog에서 적절한 폴더(예: Shared Folders > Custom)로 이동합니다. 'New' 드롭다운 메뉴를 클릭하고 'Data Model'을 선택합니다.
- SQL Query 데이터 세트 정의: Data Model 편집기에서 '+' 아이콘을 클릭해 새 데이터 세트를 만들고 'SQL Query'를 선택합니다. 대화상자가 나타나면 데이터 세트 이름(예: 'OrderToCash_EventLog')을 입력하고 Data Source로 'Oracle BI EE', SQL 유형으로 'Standard SQL'을 선택합니다.
- SQL Query 입력: 이 문서의 'query' 섹션에 있는 전체 SQL Query를 복사해 SQL Query 입력란에 붙여 넣습니다. Query에 포함된 시작일 및 종료일 매개변수(:p_start_date 및 :p_end_date)는 BI Publisher에서 자동으로 인식됩니다.
- 데이터 모델 속성 설정: Query를 붙여 넣은 후 'OK'를 클릭합니다. 데이터 모델 편집기 왼쪽 창에서 'Properties' 섹션으로 이동합니다. 'Include Parameter Tags'가 선택되어 있는지 확인합니다. 원하는 경우 날짜 매개변수의 기본값도 설정할 수 있습니다.
- 데이터 모델 확인 및 저장: 'Data' 탭을 클릭합니다. 날짜 매개변수 값을 입력하라는 메시지가 표시될 수 있습니다. 테스트할 짧은 날짜 범위를 입력하고 'View'를 클릭해 샘플 데이터를 확인합니다. 데이터가 올바르게 표시되면 저장 아이콘을 클릭하고 설명이 포함된 이름(예: 'OrderToCash_EventLog_DM')을 지정해 데이터 모델을 저장합니다.
- 데이터 모델에서 보고서 만들기: 데이터 모델을 저장한 후 오른쪽 위의 'Create Report' 버튼을 클릭합니다. 보고서 생성 마법사가 열립니다.
- 보고서 설정: 마법사에서 'Use Data Model'을 선택합니다. 마법사의 안내에 따라 레이아웃을 설정합니다. 간단한 CSV 내보내기에는 'Table' 레이아웃을 선택하면 됩니다. 모든 열을 표로 끌어다 놓습니다. 'Next'를 클릭한 다음 'Show Grand Totals Row'의 선택을 해제합니다. 'Finish'를 클릭해 보고서를 저장하고 'OrderToCash_EventLog_Report'와 같은 이름을 지정합니다.
- 보고서 실행: 새로 만든 보고서를 엽니다. 추출할 시작일과 종료일을 입력하라는 메시지가 표시됩니다. 원하는 날짜 범위를 입력합니다.
- 데이터 내보내기: 보고서가 실행되면 'View' 드롭다운을 클릭하고 'View Report'와 같은 다른 보기 옵션을 선택합니다. 'Export' 링크나 아이콘을 찾아 내보내기 형식으로 'CSV'를 선택합니다. 이벤트 로그 파일이 다운로드됩니다.
- 업로드 준비: 다운로드한 CSV 파일을 엽니다. 열 이름이 필수 속성인 SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate, IsAutomated와 일치하는지 확인합니다. 이제 파일을 process mining 도구에 업로드할 수 있습니다.
구성
- 사용자 권한: 'BI Administrator' 또는 'BI Author'와 같이 BI Publisher 데이터 모델 및 보고서 생성 권한이 있는 역할이 필요합니다.
- 데이터 소스: Query는 트랜잭션 데이터베이스(Fusion Apps)에 연결하는 표준 'Oracle BI EE' 애플리케이션 데이터 소스를 사용하도록 작성되었습니다. 일반적으로 별도 설정은 필요하지 않습니다.
- 날짜 범위 매개변수: Query는 데이터를 필터링하기 위해 :p_start_date와 :p_end_date 두 매개변수를 사용합니다. 보고서 시간 초과와 성능 문제를 방지하려면 한 번에 3~6개월씩 관리 가능한 단위로 추출하는 것이 좋습니다.
- 사업부 필터링: 추출 범위를 제한하려면 Query의 BaseOrders CTE에 WHERE 절을 추가해 특정 사업부 ID로 필터링할 수 있습니다(예: AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID])).
- 주문 유형 필터링: BaseOrders CTE에서 dhead.SOURCE_ORDER_TYPE_CODE 조건을 추가해 특정 판매 주문 유형만 추출할 수도 있습니다.
- 성능: 여러 해에 걸친 대규모 데이터에는 단일 Query 방식이 느릴 수 있습니다. 사용량이 적은 시간대에 실행하거나 월별로 나누어 추출하세요. 복잡한 UNION Query에 영향을 줄 수 있으므로 Data Model에서 'Enable SQL Pruning' 속성을 선택하지 않았는지 확인합니다.
샘플 쿼리 sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' 단계
- BICC 콘솔 접속: BICC_ADMINISTRATOR 역할이 있는 사용자로 Oracle Fusion Applications 인스턴스에 로그인합니다. Tools로 이동해 메뉴에서 Business Intelligence Cloud Connector를 선택합니다.
- 새 제공 항목 만들기: BICC 콘솔에서 Configure External Storage를 클릭해 Oracle Universal Content Management(UCM) 또는 OCI Object Storage 버킷을 대상 위치로 설정합니다. 연결 정보와 인증 정보가 올바른지 확인합니다.
- 새 추출 작업 시작: Manage Extract Jobs 섹션으로 이동합니다. + 아이콘을 클릭해 새 작업을 만들고 ProcessMind_O2C_SalesOrder_Extract와 같이 알아보기 쉬운 이름을 지정합니다.
- 데이터 저장소(PVO) 선택: 작업 설정에서 판매 주문의 전체 흐름을 파악하는 데 필요한 Public View Objects(PVO)를 검색해 추가합니다. FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice, FscmTopModelAM.ArTopAM.CashReceiptApplication 등 여러 PVO를 추가해야 합니다.
- 각 PVO의 열 설정: 선택한 각 PVO에서 Actions 메뉴를 클릭하고 Select Columns를 선택합니다. HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate, 사용자 식별자 등 이벤트 로그 생성에 필요한 열을 신중하게 선택합니다. 각 PVO에서 필요한 열의 자세한 목록은 Query 매니페스트를 참조하세요.
- 증분 적재 필터 적용: 데이터 양을 관리하려면 각 PVO의 LastUpdateDate 열을 기준으로 필터를 적용합니다. 최초 실행에서는 넓은 날짜 범위를 선택할 수 있습니다. 이후 예약 실행에서는 마지막 작업 이후 업데이트된 레코드만 추출하도록 필터를 설정합니다.
- 추출 작업 예약: Manage Schedule 섹션으로 이동해 작업 일정을 만듭니다. 시스템 성능에 미치는 영향을 줄이려면 매일 야간 등 사용량이 적은 시간대에 실행하는 것이 좋습니다.
- 작업 제출 및 모니터링: 설정을 마치면 작업을 제출합니다. Manage Extract Jobs 화면에서 진행 상황을 확인할 수 있습니다. 작업이 완료되면 압축된 CSV 형식의 데이터 파일이 설정한 클라우드 저장소에 생성됩니다.
- 원시 데이터를 이벤트 로그로 변환: 추출한 CSV 파일을 다운로드합니다. BICC는 형식이 지정된 이벤트 로그가 아니라 원시 테이블 데이터를 제공합니다. Python, 데이터베이스 스크립트 또는 ETL 플랫폼과 같은 외부 도구로 파일을 처리해야 합니다. 작업에는 다음이 포함됩니다.
- 여러 파일의 데이터를 조인합니다(예: 청구서 데이터를 판매 주문 헤더와 연결).
- 날짜 열을 개별 활동 행으로 변환합니다. 예를 들어 FscmTopModelAM.DooTopAM.Header 파일의 CreationDate를 사용해 Sales Order Created 행을 만들고, ClosedDate를 사용해 Order Closed 행을 만듭니다.
- 상태 코드나 플래그를 Order Confirmed 또는 Order Cancelled와 같은 활동에 매핑합니다.
- 변환한 데이터를 필수 열인 SalesOrder, ActivityName, EventTime을 포함하는 단일 파일로 통합합니다.
- 업로드용 파일 준비: 변환한 데이터를 필수 및 권장 속성에 맞는 열로 구성된 단일 CSV 파일로 저장합니다. 이제 파일을 ProcessMind에 업로드할 수 있습니다.
구성
- PVO 선택: 이벤트 로그의 정확도는 올바른 PVO를 선택하는 데 달려 있습니다. 주요 PVO에는 주문 생성 및 종료 정보를 제공하는 FscmTopModelAM.DooTopAM.Header, 배송 이벤트 정보를 제공하는 FscmTopModelAM.ScmTopAM.ShipmentLine, 청구 정보를 제공하는 FscmTopModelAM.ArTopAM.ReceivableInvoice가 있습니다.
- 증분 추출: 반복 추출에는 항상 LastUpdateDate 필터를 사용합니다. 성능을 유지하고 수 GB 규모의 동일한 데이터를 반복 추출하지 않으려면 이 설정이 중요합니다. 최초 전체 적재로 기준 데이터를 만들고, 이후 실행에서는 변경된 데이터만 가져옵니다.
- 날짜 범위: 최초 이력 데이터 적재에서는 데이터의 완전성과 관리 가능한 용량을 고려해 최근 3~6개월 등 대표 기간을 추출합니다. 이후에는 증분 방식으로 실행합니다.
- 저장소 설정: BICC는 Oracle UCM 또는 OCI Object Storage로 데이터를 내보낼 수 있습니다. 대량 데이터 처리와 후속 ETL 도구 연동에는 일반적으로 OCI Object Storage를 권장합니다.
- 작업 예약: Oracle Fusion Financials 트랜잭션 시스템의 성능 저하 가능성을 줄이려면 업무 시간 외에 추출 작업을 예약합니다.
- 사전 요건: 작업을 설정하는 사용자에게는 BICC_ADMINISTRATOR 역할이 필요합니다. 클라우드 저장소 인증 정보를 미리 설정하고 추출 후 필요한 데이터 변환 로직을 파악해야 합니다.
샘플 쿼리 config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering 시작할 준비가 되셨나요?
이 템플릿으로 데이터 수집을 간소화하고 process mining을 시작하세요. 지금 주문-수금 판매 주문 처리 최적화를 시작할 수 있습니다.
지금 주문-수금 판매 주문 처리 최적화하기
병목을 찾아 주문-수금 주기를 30% 단축하세요.
신용카드 없이 14일간 무료로 체험할 수 있습니다.