주문부터 현금화까지, 판매 주문 처리 데이터 템플릿
주문부터 현금화까지, 판매 주문 처리 데이터 템플릿
- 수집 권장 속성
- 분석을 위해 추적할 주요 활동
- 데이터 추출 안내
주문부터 현금화까지, 판매 주문 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
이벤트 시간
EventTime
|
특정 활동이 발생한 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이벤트 시간 또는 타임스탬프는 활동이 수행된 정확한 날짜와 시간을 기록합니다. 예를 들어 주문 생성, 송장 발송, 결제 수령 시점을 나타냅니다. 시간 정보는 process mining의 기본 데이터입니다. 이 속성을 사용해 각 케이스의 이벤트를 시간순으로 정렬하면 프로세스 흐름을 정확하게 재구성할 수 있습니다. 또한 활동 간 처리 시간, 전체 케이스 소요 시간, 지연이나 병목 파악 등 기간 및 성과 계산의 기준이 됩니다.
중요한 이유
이벤트의 시간순서를 제공하며, 처리 시간과 병목 파악을 비롯한 모든 시간 기반 성과 분석의 토대가 됩니다.
확보 방법
OE_ORDER_HEADERS_ALL의 CREATION_DATE, WSH_DELIVERY_DETAILS의 ACTUAL_SHIPMENT_DATE, RA_CUSTOMER_TRX_ALL의 TRX_DATE 등 Oracle EBS 테이블의 여러 날짜 필드에서 가져옵니다.
예시
2023-04-15T10:30:00Z2023-04-18T14:00:00Z2023-05-01T09:15:00Z
|
|||
|
판매 주문
SalesOrder
|
고객 판매 주문을 고유하게 식별하는 값으로, Order to Cash 프로세스의 기본 케이스로 사용됩니다. | ||
|
설명
판매 주문 번호는 주문 생성부터 최종 종료까지 고객 주문을 고유하게 식별합니다. 주문 확정, 출하, 송장 발행, 결제 등 관련 활동을 연결하는 기준이 됩니다. process mining에서는 이 속성을 사용해 각 주문의 전체 여정을 재구성합니다. 모든 이벤트를 하나의 판매 주문으로 묶으면 분석가는 전체 프로세스 흐름을 확인하고 주문별 차이를 파악할 수 있습니다. 또한 개별 케이스의 처리 시간과 정시 배송률 같은 KPI를 측정할 수 있습니다.
중요한 이유
케이스 ID로, 주문의 전체 수명 주기를 분석할 때 모든 프로세스 이벤트를 연결하는 기준입니다.
확보 방법
판매 주문의 기본 키입니다. 일반적으로 OE_ORDER_HEADERS_ALL.HEADER_ID와 같은 Oracle Order Management 테이블에서 확인할 수 있습니다.
예시
685127103482459
|
|||
|
활동 이름
ActivityName
|
판매 주문 수명 주기에서 발생한 특정 비즈니스 이벤트 또는 단계의 이름입니다. | ||
|
설명
이 속성에는 판매 주문에서 수행된 각 활동의 이름이 기록됩니다. 예를 들어 '주문 확정', '상품 출하', '결제 수령' 등이 있습니다. 이러한 활동은 Order to Cash 프로세스의 주요 이정표입니다. 활동의 순서와 빈도를 분석하는 것은 process mining의 기본입니다. 이를 통해 일반적인 경로와 예외, 병목을 포함한 실제 프로세스 흐름을 파악할 수 있습니다. 이 데이터로 프로세스 분석의 주요 시각화 자료인 프로세스 맵을 생성합니다.
중요한 이유
프로세스 맵의 단계를 정의하며, 프로세스 흐름을 시각화하고 분석하는 데 필요합니다.
확보 방법
Order Management, Shipping Execution, Accounts Receivable 등의 모듈에서 발생한 이벤트, 상태, 거래 날짜를 바탕으로 도출하는 개념적 필드입니다.
예시
판매 주문 생성상품 출고청구서 생성결제 회수
|
|||
|
결제 기한
PaymentDueDate
|
고객이 송장 대금을 지급해야 하는 날짜입니다. | ||
|
설명
결제 기한은 송장 날짜와 합의된 결제 조건을 기준으로 계산한 송장 대금 지급일입니다. '결제 수령' 활동의 목표 날짜로 사용합니다. 실제 결제일과 비교해 '결제 조건 준수율' KPI를 계산하는 데 필요합니다. 기한과 실제 결제일의 차이를 분석하면 수금 담당자가 업무 우선순위를 정하고, 상습 연체 고객을 파악하며, 연체 안내 절차의 효과를 측정할 수 있습니다.
중요한 이유
수금 목표일로 사용되며, 결제 적시성과 고객의 결제 조건 준수 여부를 측정할 수 있습니다.
확보 방법
송장 거래와 연결된 AR_PAYMENT_SCHEDULES_ALL 테이블의 DUE_DATE 필드에 있습니다.
예시
2023-06-152023-07-012023-08-30
|
|||
|
결제 조건
PaymentTerms
|
고객이 상품이나 서비스 대금을 지급해야 하는 시점을 정한 합의 조건입니다. | ||
|
설명
결제 조건은 송장 대금의 지급 조건을 지정합니다. 예를 들어 'Net 30', 'Net 60', '수령 즉시 지급' 등이 있습니다. 매출채권과 현금 흐름 관리에 중요한 속성입니다. 결제 조건별 프로세스 성과를 분석하면 특정 조건의 고객이 대금을 늦게 지급하는 경향이 있는지 파악할 수 있습니다. 이를 통해 재무 위험을 평가하고, 수금 전략을 최적화하며, 결제 조건별 효과를 검토할 수 있습니다. '결제 조건 준수 모니터링' 대시보드의 주요 분석 기준입니다.
중요한 이유
결제 행동 분석, 현금 흐름 모니터링, 고객 계약별 재무 위험 평가에 중요합니다.
확보 방법
RA_TERMS 테이블에서 확인할 수 있으며, 송장의 경우 RA_CUSTOMER_TRX_ALL, 주문의 경우 OE_ORDER_HEADERS_ALL 등의 테이블에 있는 TERM_ID를 통해 연결합니다.
예시
Net 30Net 60수령 즉시 지급
|
|||
|
고객 이름
CustomerName
|
판매 주문을 접수한 고객의 이름입니다. | ||
|
설명
이 속성은 판매 주문과 관련된 고객의 법적 명칭을 식별합니다. 프로세스 성과를 구분하고 분석할 때 사용하는 주요 기준입니다. 고객별로 프로세스를 필터링하거나 세분화하면 처리 시간이 긴 고객, 재작업률이 높은 고객, 결제 지연이 잦은 고객을 파악할 수 있습니다. 이 인사이트를 바탕으로 고객 관계와 서비스 수준을 개선하고 고객 행동을 이해할 수 있습니다.
중요한 이유
고객별 성과 차이를 파악하고 서비스를 개선하며 결제 행동을 이해할 수 있도록 고객 중심 분석을 지원합니다.
확보 방법
OE_ORDER_HEADERS_ALL의 SOLD_TO_ORG_ID를 HZ_CUST_ACCOUNTS 및 HZ_PARTIES 테이블과 조인해 고객 이름을 가져옵니다.
예시
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
사용자 이름
UserName
|
활동을 수행한 사용자입니다. | ||
|
설명
특정 프로세스 단계를 수행한 사용자를 식별합니다. 주문을 생성한 영업 담당자, 신용 확인을 수행한 신용 분석가, 송장을 생성한 사무 담당자 등이 해당합니다. 사용자별 활동을 분석하면 교육이 필요한 영역, 성과가 높은 개인이나 팀, 업무량 분포를 파악할 수 있습니다. 또한 무단 작업을 조사하거나 특정 사용자의 재작업 패턴을 확인하는 등 규정 준수 및 감사 추적 분석에도 중요합니다.
중요한 이유
사용자별 성과와 업무량 분포, 규정 준수 절차 이행 여부를 분석할 수 있습니다. 누가 작업을 수행했는지 확인하는 데 도움이 됩니다.
확보 방법
Oracle EBS 테이블의 CREATED_BY 또는 LAST_UPDATED_BY와 같은 사용자 관련 필드에서 가져옵니다. 전체 사용자 이름을 확인하려면 FND_USER와 조인해야 하는 경우가 많습니다.
예시
JSMITHRWILLIAMSCDAVIS
|
|||
|
주문 상태
OrderStatus
|
판매 주문 또는 주문 라인의 현재 또는 과거 상태입니다. | ||
|
설명
이 속성은 '입력', '확정', '종료', '취소' 등 시점별 판매 주문 상태를 기록합니다. 상태는 프로세스 활동과 직접 연결되는 경우가 많습니다. 주문 상태를 추적하면 진행 중인 모든 주문의 현황을 보여주는 대시보드를 만들 수 있습니다. 관리자는 주문 파이프라인을 모니터링하고 정체된 주문을 찾아 예외 상황에 선제적으로 대응할 수 있습니다. 상태 전환을 분석해 프로세스 맵의 활동을 정의하는 방법도 널리 사용됩니다.
중요한 이유
판매 주문 파이프라인을 파악하고 정체된 주문과 프로세스 예외를 관리하는 데 도움이 됩니다.
확보 방법
일반적으로 OE_ORDER_HEADERS_ALL 및 OE_ORDER_LINES_ALL 테이블의 FLOW_STATUS_CODE 열에서 확인할 수 있습니다.
예시
확정출하 대기출하 완료종료취소
|
|||
|
주문 총액
TotalOrderAmount
|
판매 주문의 총 금액입니다. | ||
|
설명
이 속성은 판매 주문의 모든 라인 금액을 거래 통화로 합산한 값입니다. 각 케이스와 관련된 주요 재무 지표입니다. 주문 금액별로 프로세스 지표를 분석하면 개선 과제의 우선순위를 정할 수 있습니다. 예를 들어 고액 주문이 소액 주문보다 지연이나 재작업을 더 많이 겪는지 조사할 수 있습니다. 특정 병목에 묶인 주문의 금액을 산출하는 등 재무적 영향도 평가할 수 있습니다.
중요한 이유
프로세스의 재무 분석을 지원해 고액 주문의 우선순위를 정하고 비효율로 인한 금전적 영향을 산출할 수 있습니다.
확보 방법
일반적으로 해당 주문의 라인 금액을 합산해 계산합니다. 라인 금액은 OE_ORDER_LINES_ALL과 같은 테이블에서 확인할 수 있습니다.
예시
5450.00125000.75980.50
|
|||
|
확정 배송일
ConfirmedDeliveryDate
|
고객에게 상품을 배송하기로 약속한 날짜입니다. | ||
|
설명
이 속성에는 고객에게 약속하거나 확인한 배송일이 저장됩니다. 정시 배송 성과를 측정할 때 목표일 또는 기준일로 사용합니다. process mining에서는 이 날짜를 실제 배송 타임스탬프('상품 배송' 활동)와 비교해 '정시 배송률' KPI를 계산합니다. 날짜 차이를 분석하면 배송 지연을 일으키는 물류, 재고 관리, 생산 계획의 구조적 문제를 파악할 수 있습니다.
중요한 이유
정시 배송 성과를 측정하는 기준이며, 고객 만족도와 운영 성과를 평가하는 주요 KPI입니다.
확보 방법
일반적으로 OE_ORDER_LINES_ALL 테이블의 주문 라인 수준에서 LATEST_ACCEPTABLE_DATE 또는 REQUEST_DATE 필드로 확인할 수 있습니다.
예시
2023-05-102023-06-012023-07-20
|
|||
|
결제 기한 준수 여부
IsPaymentOnTime
|
송장 결제 기한까지 또는 그 전에 대금을 수령했는지 나타내는 플래그입니다. | ||
|
설명
해당 송장의 '결제 수령' 활동 타임스탬프와 '결제 기한'을 비교해 계산하는 불리언 속성입니다. 결제 조건 준수 여부를 True/False로 표시합니다. 이 플래그는 '결제 조건 준수율' KPI의 기준입니다. 고객의 결제 행동과 매출채권 프로세스의 효과를 모니터링하는 대시보드와 보고서를 쉽게 만들 수 있습니다. 기한 내 결제와 연체 결제를 빠르게 구분해 고객 유형이나 결제 조건 등 관련 요인을 분석할 수 있습니다.
중요한 이유
결제 조건 준수 여부를 직접 측정합니다. 현금 흐름 관리와 고객의 재무 신뢰도 평가에 중요합니다.
확보 방법
계산 필드입니다. 로직: IF ('Payment Received' EventTime <= PaymentDueDate) THEN True ELSE False.
예시
truefalse
|
|||
|
배송 방법
ShippingMethod
|
고객에게 상품을 운송하는 데 사용하는 방법 또는 운송업체입니다. | ||
|
설명
이 속성은 배송에 사용된 운송 방식이나 서비스 수준을 지정합니다. 예를 들어 '육상 운송', '항공 특송', '지역 배송' 등이 있습니다. 배송 시간과 비용에 영향을 주는 주요 요소입니다. 이 속성으로 프로세스를 분석하면 배송 방법별 성과를 평가할 수 있습니다. 예를 들어 '배송 방법별 성과' 대시보드에서 각 방법의 '상품 출하'부터 '상품 배송'까지 걸린 시간을 비교해 속도, 비용, 신뢰성의 균형을 고려한 물류 최적화를 지원합니다.
중요한 이유
운송업체와 배송 옵션별 성과를 평가해 비용, 속도, 신뢰성을 고려한 최적의 방법을 선택할 수 있습니다.
확보 방법
일반적으로 WSH_DELIVERY_DETAILS 또는 OE_ORDER_LINES_ALL과 같은 테이블의 SHIPPING_METHOD_CODE에 저장됩니다.
예시
UPS 육상 배송FedEx 익일 우선 배송DHL 전 세계 특급 배송
|
|||
|
소스 시스템
SourceSystem
|
데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 이벤트 데이터가 생성된 소스 정보 시스템을 식별합니다. 이 프로세스에서는 항상 'Oracle E-Business Suite'로 표시됩니다. 여러 시스템을 사용하는 환경에서는 데이터 계보를 추적하고 문제를 해결하는 데 중요한 필드입니다. 단일 시스템 환경에서도 데이터 모델을 이해하고 데이터 수집 절차를 표준화하는 데 도움이 됩니다.
중요한 이유
데이터 출처를 파악하고 올바르게 해석할 수 있도록 정보를 제공합니다. 특히 여러 시스템을 사용하는 환경에서 추적성을 확보하는 데 유용합니다.
확보 방법
일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 데이터 출처를 표시하기 위해 추가하는 고정값입니다.
예시
Oracle E-Business SuiteOracle EBS R12
|
|||
|
재작업 여부
IsRework
|
반복 확인이나 업데이트 활동 등 판매 주문에 재작업이 발생했는지 나타내는 플래그입니다. | ||
|
설명
재작업을 나타내는 패턴이 포함된 케이스를 표시하는 계산형 불리언 속성입니다. 프로세스 맵에서 주문이 여러 번 확정되는 것과 같은 반복 경로를 찾거나, 시스템에 기록된 특정 변경 이벤트를 확인해 재작업을 파악할 수 있습니다. 이 플래그는 '판매 주문 재작업률' KPI 계산과 '판매 주문 재작업 분석' 대시보드에 사용됩니다. 분석가는 표준 프로세스에서 벗어난 주문을 쉽게 분리해 살펴볼 수 있습니다. 이를 통해 재작업이 처리 시간과 비용에 미치는 영향을 산출하고 비효율적인 반복 경로의 원인을 파악할 수 있습니다.
중요한 이유
수동 변경이 필요한 주문을 표시해 프로세스 비효율을 산출하고 재작업의 원인과 영향을 분석할 수 있습니다.
확보 방법
데이터 변환 과정에서 동일 케이스에 'Order Booked'가 두 번 이상 발생하는 경우처럼 반복 경로를 나타내는 활동 순서를 찾아 계산합니다.
예시
truefalse
|
|||
|
정시 배송 여부
IsOnTimeDelivery
|
확정 배송일까지 또는 그 전에 주문이 배송되었는지 나타내는 플래그입니다. | ||
|
설명
이 계산 속성은 주문이 배송 약속을 지켰는지 True/False로 표시합니다. '상품 배송' 활동의 타임스탬프와 '확정 배송일'을 비교해 계산합니다. 이 속성은 '정시 배송률' KPI를 직접 지원합니다. 주문별 결과를 명확한 이진값으로 제공해 분석과 대시보드 작성을 간소화합니다. 지연 배송의 공통 특성을 파악할 수 있도록 제품, 고객, 배송 방법별로 쉽게 필터링하고 집계할 수 있습니다.
중요한 이유
고객 서비스 수준과 주문 이행의 신뢰성을 직접 측정하며, 정시 배송 KPI를 쉽게 계산하고 시각화할 수 있습니다.
확보 방법
계산 필드입니다. 로직: IF ('Goods Delivered' EventTime <= ConfirmedDeliveryDate) THEN True ELSE False.
예시
truefalse
|
|||
|
제품 번호
ProductNumber
|
판매 주문 라인의 제품 또는 항목을 고유하게 식별하는 값입니다. | ||
|
설명
이 속성은 판매 대상인 특정 자재, 항목 또는 서비스를 식별합니다. 판매 주문 헤더보다 세부적인 수준에서 분석할 수 있습니다. 제품별 프로세스를 분석하면 제품에 따른 문제를 파악할 수 있습니다. 예를 들어 제조나 조달이 복잡한 제품은 이행 시간이 길 수 있고, 특정 제품은 배송 오류나 고객 분쟁이 더 자주 발생할 수 있습니다. 이를 바탕으로 공급망과 제품 관리를 개선할 수 있습니다.
중요한 이유
제품별 분석을 통해 프로세스 지연, 재작업 또는 기타 비효율을 유발하는 항목을 파악할 수 있습니다.
확보 방법
OE_ORDER_LINES_ALL 테이블의 INVENTORY_ITEM_ID에서 가져옵니다. MTL_SYSTEM_ITEMS_B와 조인하면 항목 번호나 설명을 확인할 수 있습니다.
예시
AS54888CM15001SV20100
|
|||
|
주문 수량
OrderQuantity
|
특정 판매 주문 라인에서 주문한 제품의 수량입니다. | ||
|
설명
이 속성은 고객이 판매 주문 라인에서 요청한 특정 제품의 수량을 나타냅니다. 라인 항목 수준에서 거래 규모를 보여줍니다. 주문 수량을 분석 기준으로 사용하면 주문 규모에 따라 프로세스가 달라지는지 확인할 수 있습니다. 예를 들어 매우 크거나 작은 주문은 서로 다른 경로로 처리되거나 다른 유형의 지연을 겪을 수 있습니다. 주문 금액과 같은 다른 지표를 해석할 때도 참고할 수 있습니다.
중요한 이유
주문 규모를 파악해 주문량이 프로세스 효율과 이행 경로에 미치는 영향을 분석할 수 있습니다.
확보 방법
OE_ORDER_LINES_ALL 테이블의 ORDERED_QUANTITY 필드에서 확인할 수 있습니다.
예시
102501
|
|||
|
최종 데이터 업데이트
LastDataUpdate
|
소스 시스템에서 데이터를 가장 최근에 새로 고친 시점입니다. | ||
|
설명
이 속성은 Oracle E-Business Suite에서 데이터를 추출해 process mining 도구에 적재한 마지막 시점을 나타냅니다. 분석 중인 데이터의 최신성을 보여줍니다. 사용자는 이 정보를 통해 조회 중인 인사이트가 얼마나 최신인지 확인할 수 있습니다. 실시간 정보인지 특정 시점의 스냅샷인지 파악할 수 있어 운영 의사결정에 도움이 됩니다.
중요한 이유
데이터의 최신성을 알려줍니다. 분석 결과를 신뢰하고 적시에 의사결정을 내리는 데 필요한 정보입니다.
확보 방법
이 타임스탬프는 데이터 추출, 변환, 적재(ETL) 과정에서 생성되어 추가됩니다.
예시
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
취소 사유
CancellationReason
|
판매 주문 또는 주문 라인을 취소한 사유로 기록된 내용입니다. | ||
|
설명
판매 주문이 취소되면 이 속성에 취소 사유가 기록됩니다. 예를 들어 '고객 요청', '재고 부족', '신용 보류' 등이 있습니다. 이 데이터는 주문 취소의 근본 원인을 분석하는 데 중요합니다. '판매 주문 취소율 및 사유' 대시보드에서 취소의 주요 원인을 파악할 수 있습니다. 이를 바탕으로 고객 이탈을 줄이고, 재고 예측을 개선하거나, 신용 정책을 조정하는 방안을 마련할 수 있습니다.
중요한 이유
주문 취소 사유를 직접 파악할 수 있어 매출 손실을 줄이고 고객 유지율을 높이기 위한 근본 원인 분석을 지원합니다.
확보 방법
이 정보는 CANCELLED_REASON과 같은 사유 코드 필드에 저장되는 경우가 많습니다. OE_ORDER_LINES_ALL 테이블이나 주문 변경 관련 테이블에서 확인할 수 있습니다.
예시
제품 단종고객 취소중복 주문
|
|||
|
통화
Currency
|
판매 주문 금액에 적용되는 통화 코드입니다. | ||
|
설명
통화 속성은 주문 금액의 표시 통화를 지정합니다. 예를 들어 USD, EUR, JPY 등이 있습니다. 주문과 관련된 재무 데이터를 해석하는 데 필요한 정보입니다. 여러 통화를 사용하는 다국적 조직의 분석에 특히 중요합니다. '주문 총액'과 같은 재무 지표를 올바르게 해석하고, 통합 보고에 필요한 경우 적절한 환산을 할 수 있습니다.
중요한 이유
모든 금액의 통화 정보를 제공해 정확한 재무 분석을 지원합니다. 특히 글로벌 비즈니스 환경에서 중요합니다.
확보 방법
OE_ORDER_HEADERS_ALL 테이블의 TRANSACTIONAL_CURR_CODE 필드에 있습니다.
예시
USDEURGBP
|
|||
주문부터 현금화까지, 판매 주문 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
결제 회수
|
고객의 결제를 받아 시스템에서 해당 청구서에 적용하는 활동입니다. Accounts Receivable 모듈에 명시적 금융 거래로 기록됩니다. | ||
|
중요한 이유
현금 흐름, 매출채권 회수일수(DSO), 결제 조건 준수를 추적하는 데 중요한 단계입니다. 재무 주기를 측정하는 주요 종료 지점입니다.
확보 방법
AR_RECEIVABLE_APPLICATIONS_ALL 테이블에 명시적으로 기록됩니다. APPLY_DATE 열에서 현금 입금액이 청구서에 적용된 타임스탬프를 확인할 수 있습니다.
기록
해당 청구서의 AR_RECEIVABLE_APPLICATIONS_ALL에서 APPLY_DATE를 사용합니다.
이벤트 유형
explicit
|
|||
|
상품 출고
|
출고 확인이 완료되어 상품이 실제로 창고를 떠나는 시점을 나타냅니다. 재고를 갱신하고 주문 상태를 다음 단계로 진행하는 배송 모듈의 주요 명시적 이벤트입니다. | ||
|
중요한 이유
정시 출고 실적을 측정하는 중요한 이행 단계입니다. 청구서 발행과 매출 인식 프로세스를 시작하는 기준이기도 합니다.
확보 방법
Oracle Shipping Execution에 명시적 거래로 기록됩니다. 타임스탬프는 WSH_NEW_DELIVERIES 테이블의 INITIAL_PICKUP_DATE에서 확인하거나 WSH_DELIVERY_DETAILS의 상태가 'Shipped'로 변경된 기록을 바탕으로 추정할 수 있습니다.
기록
WSH_DELIVERY_DETAILS 또는 WSH_NEW_DELIVERIES의 출고 확인 날짜를 사용합니다.
이벤트 유형
explicit
|
|||
|
재고 할당
|
주문 라인에 재고를 예약해 피킹에 필요한 수량을 확보하는 활동입니다. 일반적으로 판매 주문 라인의 상태 변경을 바탕으로 추정하며, 창고 출고 준비가 완료된 시점을 나타냅니다. | ||
|
중요한 이유
이 단계는 이행 준비 상태를 파악하는 데 중요합니다. 여기서 지연이 발생하면 재고 부족, 조달 문제 또는 할당 프로세스의 비효율을 의심할 수 있습니다.
확보 방법
WSH_DELIVERY_DETAILS 테이블의 상태 변경을 바탕으로 추정합니다. 라인 상태가 'Ready to Release'로 변경되면 활동이 발생하며, 관련 상태 업데이트의 타임스탬프를 사용합니다.
기록
WSH_DELIVERY_DETAILS의 라인 상태가 'Ready to Release'로 변경된 기록을 바탕으로 추정합니다.
이벤트 유형
inferred
|
|||
|
주문 종료
|
모든 주문 라인이 정상적으로 출고되고 청구서가 발행된 뒤 종료되면 판매 주문 처리가 최종 완료됩니다. 주문 헤더의 상태가 명시적으로 업데이트됩니다. | ||
|
중요한 이유
주문부터 현금 회수까지 프로세스의 주요 완료 지점입니다. 성공적으로 이행된 주문의 전체 처리 주기를 계산하는 데 필요한 최종 타임스탬프를 제공합니다.
확보 방법
OE_ORDER_HEADERS_ALL 테이블에서 FLOW_STATUS_CODE가 'CLOSED'로 변경될 때 기록됩니다. 이 상태 변경의 LAST_UPDATE_DATE가 이벤트 타임스탬프입니다.
기록
OE_ORDER_HEADERS_ALL에서 FLOW_STATUS_CODE가 'CLOSED'로 변경된 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
주문 확정
|
판매 주문을 공식적으로 확정해 활성화하고 조달 및 배송 등 후속 처리가 가능하도록 합니다. Oracle EBS에서 주문 상태를 'Entered'에서 'Booked'로 변경하는 명시적 작업입니다. | ||
|
중요한 이유
주문 확정은 이행을 위해 주문을 공식적으로 승인하는 중요한 단계입니다. 주문 생성부터 확정까지 지연되면 데이터 입력, 승인 또는 초기 검증에 문제가 있을 수 있습니다.
확보 방법
OE_ORDER_HEADERS_ALL 테이블에서 확인할 수 있습니다. BOOKED_FLAG가 'Y'로 설정되면 이벤트가 발생하며, 타임스탬프는 BOOKED_DATE 열에 기록됩니다.
기록
OE_ORDER_HEADERS_ALL 테이블의 BOOKED_DATE를 사용합니다.
이벤트 유형
explicit
|
|||
|
청구서 생성
|
출고된 상품에 대한 매출채권 청구서가 생성되는 이벤트입니다. AutoInvoice 프로세스가 Order Management 및 Shipping의 데이터를 Receivables 모듈로 가져오면서 발생하는 명시적 이벤트입니다. | ||
|
중요한 이유
이 활동부터 재무 정산 단계가 시작됩니다. 청구서 발행부터 결제까지의 주기를 측정하고 청구 효율을 모니터링하는 기준점입니다.
확보 방법
Oracle Receivables의 RA_CUSTOMER_TRX_ALL 테이블에 명시적 거래로 기록됩니다. TRX_DATE 또는 CREATION_DATE를 이벤트 타임스탬프로 사용합니다.
기록
RA_CUSTOMER_TRX_ALL 테이블의 TRX_DATE를 사용합니다.
이벤트 유형
explicit
|
|||
|
판매 주문 생성
|
시스템에서 판매 주문을 처음 생성하는 활동입니다. 사용자가 새 판매 주문 헤더를 저장할 때 명시적 이벤트로 기록되며, 주문부터 현금 회수까지의 프로세스가 공식적으로 시작되는 시점을 나타냅니다. | ||
|
중요한 이유
이 프로세스의 주요 시작 이벤트입니다. 이 시점부터 후속 활동까지 걸리는 시간을 분석하면 주문부터 현금 회수까지의 전체 주기를 측정할 수 있습니다.
확보 방법
Oracle Order Management 모듈의 OE_ORDER_HEADERS_ALL 테이블에서 이 이벤트를 확인할 수 있습니다. CREATION_DATE 열에 활동의 타임스탬프가 명시적으로 기록됩니다.
기록
OE_ORDER_HEADERS_ALL 테이블의 CREATION_DATE를 사용합니다.
이벤트 유형
explicit
|
|||
|
고객에게 청구서 발송
|
청구서를 인쇄하거나 전자 방식으로 고객에게 전송하는 시점입니다. 생성과 별도의 명시적 이벤트로 항상 기록되는 것은 아니므로 일반적으로 추정합니다. | ||
|
중요한 이유
고객의 결제 기한 계산이 공식적으로 시작되는 시점입니다. 청구서 생성부터 발송까지 지연되면 현금 흐름에 악영향을 주고 결제가 늦어질 수 있습니다.
확보 방법
RA_CUSTOMER_TRX_ALL 테이블의 LAST_PRINTED_DATE를 바탕으로 추정할 수 있습니다. 전자 청구서는 외부 문서 전송 시스템의 로그를 확인해야 할 수 있습니다.
기록
RA_CUSTOMER_TRX_ALL의 LAST_PRINTED_DATE 또는 타사 도구의 로그를 사용합니다.
이벤트 유형
inferred
|
|||
|
상품 배송 완료
|
배송물이 고객에게 도착한 활동입니다. 표준 Oracle EBS에서는 이 이벤트를 추적하지 않으므로 일반적으로 외부 운송사 시스템에서 가져오거나 추정해야 합니다. | ||
|
중요한 이유
정시 배송 KPI를 측정하고 전체 고객 경험을 파악하는 데 필요합니다. 출고와 배송 완료 사이의 차이를 통해 운송사 실적을 확인할 수 있습니다.
확보 방법
시스템 분석이 필요합니다. 이 데이터는 Oracle EBS에서 기본 제공되지 않으므로 외부 운송사 데이터 피드나 시스템과 연동된 물류 플랫폼에서 가져와야 합니다.
기록
외부 운송사 데이터를 바탕으로 추정하거나 'Goods Shipped' 이후의 표준 운송 시간을 적용해 추정합니다.
이벤트 유형
inferred
|
|||
|
신용 확인 완료
|
주문에 대한 고객 신용 확인이 완료된 활동입니다. 신용 확인 보류가 설정된 경우 이를 판매 주문에서 해제하면 주문을 다음 단계로 진행할 수 있습니다. | ||
|
중요한 이유
신용 확인 지연은 전체 이행 프로세스를 멈추게 하는 흔한 병목입니다. 이 활동을 모니터링하면 재무 통제와 승인 과정의 비효율을 파악할 수 있습니다.
확보 방법
OE_ORDER_HOLDS_ALL 테이블에서 특정 주문 헤더의 'Credit Check Hold'가 해제된 타임스탬프를 찾아 이 이벤트를 추정할 수 있습니다.
기록
OE_ORDER_HOLDS_ALL에서 신용 관련 보류가 해제된 타임스탬프를 사용합니다.
이벤트 유형
inferred
|
|||
|
주문 라인 종료
|
배송과 청구서 발행을 포함해 판매 주문의 개별 라인에 대한 처리가 모두 완료되었음을 나타냅니다. 워크플로 프로세스에서 관리하는 명시적 상태 변경입니다. | ||
|
중요한 이유
라인별 종료를 추적하면 부분 배송을 분석하고 전체 주문이 완료되기 전에 특정 제품이나 이행 경로의 문제를 찾을 수 있습니다.
확보 방법
OE_ORDER_LINES_ALL 테이블에서 FLOW_STATUS_CODE가 'CLOSED'로 변경될 때 기록됩니다. 이 상태 변경의 LAST_UPDATE_DATE를 타임스탬프로 사용할 수 있습니다.
기록
OE_ORDER_LINES_ALL에서 FLOW_STATUS_CODE가 'CLOSED'로 변경된 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
주문 취소
|
이행이 완료되기 전에 판매 주문 전체가 취소되는 것을 나타냅니다. 주문 처리 워크플로를 종료하는 명시적 이벤트입니다. | ||
|
중요한 이유
주요 예외 종료 이벤트입니다. 취소 빈도와 시점, 사유를 분석하면 매출 손실과 프로세스 또는 제품 문제를 파악하는 데 도움이 됩니다.
확보 방법
OE_ORDER_HEADERS_ALL 테이블에서 FLOW_STATUS_CODE가 'CANCELLED'이고 CANCELLED_FLAG가 'Y'로 설정되면 기록됩니다. 타임스탬프로 LAST_UPDATE_DATE를 사용할 수 있습니다.
기록
OE_ORDER_HEADERS_ALL의 CANCELLED_FLAG가 'Y'로 설정된 시점입니다.
이벤트 유형
explicit
|
|||
|
피킹 출고
|
판매 주문 라인을 창고로 보내 피킹을 시작하는 시점입니다. 피킹 전표를 생성하고 창고 작업자가 주문을 확인할 수 있도록 하는 명시적 작업입니다. | ||
|
중요한 이유
이 활동부터 실제 이행 작업이 시작됩니다. 이 시점부터 'Goods Shipped'까지 걸리는 시간을 분석하면 창고 작업의 효율과 피킹 병목을 파악할 수 있습니다.
확보 방법
Oracle Shipping Execution 모듈에 명시적 이벤트로 기록됩니다. WSH_DELIVERY_DETAILS의 배송 상세 상태가 'Released to Warehouse' 또는 'Transactable'로 변경된 기록으로 확인할 수 있습니다.
기록
WSH_DELIVERY_DETAILS.RELEASED_STATUS가 'S'(Submitted)로 변경된 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿을 활용하면 주문부터 현금화까지의 판매 주문 처리를 최적화하는 데 필요한 준비를 마칠 수 있습니다. 지금 프로세스 개선을 시작해 효율을 높이세요.
지금 판매 주문 처리 프로세스를 개선하세요!
비효율적인 부분을 찾아 주문부터 현금화까지 걸리는 시간을 30% 단축하세요.
신용카드가 필요하지 않습니다. 14일 무료 체험을 이용하세요.