반품 및 환불 처리 데이터 템플릿
반품 및 환불 처리 데이터 템플릿
- 수집 권장 속성
- 프로세스 분석을 위해 추적할 주요 활동
- Oracle Fusion SCM 데이터 추출 단계별 안내
반품 및 환불 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
반품 건 ID
ReturnCaseId
|
특정 고객의 반품 또는 환불 요청과 관련된 모든 활동을 연결하는 기본 식별자입니다. | ||
|
설명
반품 건 ID는 반품 및 환불 프로세스 전체에서 건을 고유하게 식별합니다. 최초 반품 자재 승인(RMA) 생성부터 최종 환불 처리와 건 종료까지 모든 이벤트를 연결합니다. process mining 분석에서 이 속성은 각 반품의 전체 처리 과정을 재구성하는 데 기본이 됩니다. 분석 담당자는 이를 사용해 전체 처리 과정을 추적하고 총 처리 시간을 측정하며 반품 유형별 처리 방식의 차이를 파악할 수 있습니다. 다른 모든 이벤트 수준 데이터는 이 ID를 기준으로 그룹화되어 하나의 일관된 프로세스 뷰를 구성합니다.
중요한 이유
관련 이벤트를 하나의 프로세스 인스턴스로 연결하는 데 필요한 식별자로, 전체 처리 과정의 분석을 가능하게 합니다.
확보 방법
일반적으로 반품 요청이 시작될 때 Oracle Order Management 또는 Service 모듈에서 생성됩니다.
예시
RMA-2023-00123RMA-2023-00456RMA-2023-00789
|
|||
|
이벤트 시각
EventTime
|
특정 활동이나 이벤트가 발생한 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이벤트 시각 또는 시작 시각은 원본 시스템에 활동이 기록된 정확한 날짜와 시간입니다. 프로세스의 각 단계를 시간순으로 파악할 수 있습니다. 이 타임스탬프는 시간 기반 분석에 필수적입니다. 이벤트 순서를 올바르게 정하고 활동 간 처리 시간을 계산하며 건의 전체 소요 시간을 측정하고 서비스 수준 계약(SLA) 대비 성과를 평가하는 데 사용됩니다. 타임스탬프가 정확하지 않으면 프로세스 효율성을 분석하거나 지연을 찾아내고 프로세스의 진행 양상을 파악할 수 없습니다.
중요한 이유
이 속성은 이벤트의 시간순서를 제공하며, 모든 소요 시간 기반 지표를 계산하고 프로세스 병목을 찾는 데 기본이 됩니다.
확보 방법
일반적으로 Oracle Fusion SCM의 거래 또는 상태 레코드에 있는 '생성일', '타임스탬프' 또는 '최종 업데이트일' 필드에서 확인할 수 있습니다.
예시
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
활동
ActivityName
|
반품 및 환불 프로세스에서 발생한 특정 업무 단계 또는 이벤트의 이름입니다. | ||
|
설명
이 속성은 'RMA 생성', '상품 검사 완료', '환불 처리 완료'와 같이 반품 처리 과정의 개별 단계나 주요 시점을 나타냅니다. 각 활동은 시스템 이벤트 로그에 기록된 프로세스상의 특정 시점입니다. 활동의 순서와 소요 시간을 분석하는 것이 process mining의 핵심입니다. 이를 통해 프로세스 맵을 시각화하고 단계 사이의 병목을 찾아내며 활동별 처리 시간을 계산할 수 있습니다. 이 데이터는 프로세스 흐름과 재작업 반복, 표준 운영 절차 준수 여부를 파악하는 데 중요합니다.
중요한 이유
활동은 프로세스 맵의 기반이 되며 프로세스 흐름과 편차, 병목을 시각화하고 분석할 수 있게 합니다.
확보 방법
이벤트 로그, 상태 변경 또는 Order Management와 Inventory Management 같은 Oracle Fusion SCM 모듈의 특정 거래 레코드에서 가져옵니다.
예시
RMA 생성상품 입고대변 메모 생성환불 처리 완료
|
|||
|
원본 시스템
SourceSystem
|
데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 이벤트 데이터가 기록된 원본 정보 시스템을 식별합니다. 이 프로세스에서는 일반적으로 'Oracle Fusion SCM'을 가리킵니다. 여러 시스템을 연동한 환경에서는 데이터 계보를 추적하고 문제를 해결하는 데 이 필드가 중요합니다. 데이터의 출처를 확인하고 특정 시스템의 이벤트만 분석하도록 필터링할 수 있어 데이터 품질과 맥락을 유지하는 데 도움이 됩니다.
중요한 이유
데이터 출처에 관한 중요한 맥락을 제공하므로 여러 시스템을 사용하는 환경에서 데이터 검증과 분석에 필수적입니다.
확보 방법
데이터 추출, 변환, 적재(ETL) 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값인 경우가 많습니다.
예시
Oracle Fusion SCMOracle SCM Cloud
|
|||
|
최종 데이터 업데이트 시각
LastDataUpdate
|
원본 시스템에서 데이터를 마지막으로 새로 고치거나 추출한 시각입니다. | ||
|
설명
이 속성은 데이터 세트가 마지막으로 업데이트된 시점을 나타냅니다. 개별 이벤트가 아니라 데이터 세트 전체의 최신성을 보여주는 날짜입니다. 마지막 데이터 업데이트 시각을 알면 사용자가 분석 데이터의 최신성을 파악할 수 있습니다. 실시간 정보인지 몇 시간 또는 며칠 전 데이터인지 확인해 대시보드와 KPI를 올바르게 해석할 수 있습니다. 모든 process mining 프로젝트에서 중요한 메타데이터입니다.
중요한 이유
데이터가 얼마나 최신인지 알려주므로 분석의 맥락과 시점을 정확히 파악할 수 있습니다.
확보 방법
데이터 추출, 변환, 적재(ETL) 과정에서 생성해 추가하는 타임스탬프입니다.
예시
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
반품 사유
ReturnReason
|
고객이 상품을 반품하는 이유입니다. | ||
|
설명
이 속성에는 반품 사유가 기록됩니다. 일반적으로 고객이 '상품 결함', '사이즈 오류', '더 이상 필요하지 않음'과 같은 사전 정의된 목록에서 선택합니다. 반품 사유를 분석하면 제품 품질, 판매 프로세스의 정확성, 고객 행동을 파악할 수 있습니다. 결함률이 높은 제품을 찾고, 잘못된 주문을 줄이도록 제품 설명을 개선하며, 반품의 근본 원인을 파악하는 데 활용할 수 있습니다. 분석 결과를 바탕으로 전체 반품 건수를 줄이는 개선을 추진할 수 있습니다.
중요한 이유
반품이 발생하는 이유를 파악해 제품과 판매 프로세스를 개선하는 데 활용할 수 있습니다.
확보 방법
일반적으로 Oracle Order Management의 RMA 품목에 코드 또는 텍스트 필드로 저장됩니다.
예시
결함잘못 배송된 상품배송 지연더 저렴한 가격으로 구매 가능
|
|||
|
반품 상태
ReturnStatus
|
반품 건의 현재 상태 또는 최종 상태입니다. | ||
|
설명
이 속성은 특정 시점의 반품 건 전체 상태나 최종 결과를 나타냅니다. 예를 들어 '종료 - 환불 완료', '종료 - 반려', '진행 중' 등이 있습니다. 반품 상태는 결과 분석과 모니터링에 중요합니다. 결과에 따라 건을 필터링하고 승인된 반품과 반려된 반품의 프로세스 흐름을 비교하며 '현재 반품 건 상태 대시보드'를 구성할 수 있습니다. 프로세스의 효과를 측정하려면 결과 분포를 파악해야 합니다.
중요한 이유
건의 결과를 제공하므로 필터링과 비교 분석, 프로세스 성공률 파악에 필요합니다.
확보 방법
일반적으로 Oracle Order Management의 기본 반품 또는 RMA 헤더 레코드에서 상태 필드로 확인할 수 있습니다.
예시
입고 대기검사 완료종료 - 환불 완료종료 - 거부됨
|
|||
|
실제 환불 금액
ActualRefundAmount
|
고객에게 실제로 지급된 최종 환불 금액입니다. | ||
|
설명
이 속성은 상품 검사와 금액 조정, 수수료 적용을 모두 마친 뒤 고객에게 지급하기로 확정된 최종 금액입니다. 반품 건의 실제 재무 결과를 나타냅니다. 이 데이터는 '요청 금액과 실제 환불 금액' 대시보드에 사용되는 중요한 재무 지표입니다. 요청 금액과 비교하면 '환불 금액 차이율' KPI를 계산하고, 반품 정책과 상품 상태, 처리 과정의 조정이 재무에 미치는 영향을 파악할 수 있습니다.
중요한 이유
반품의 실제 재무 결과를 나타내며, 금액 차이 분석과 재무 보고에 활용됩니다.
확보 방법
Oracle Fusion Financials에서 반품 건과 연결된 Credit Memo 또는 Accounts Payable 거래 기록을 통해 확인할 수 있습니다.
예시
129.9940.000.00
|
|||
|
요청 환불 금액
RequestedRefundAmount
|
고객이 반품을 요청할 때 처음 제시한 환불 금액입니다. | ||
|
설명
이 속성은 프로세스 시작 시 고객이 요청한 환불 금액을 기록합니다. 최종 환불 금액과 비교하는 기준 금액입니다. 이 데이터는 '요청 금액과 실제 환불 금액' 대시보드와 '환불 금액 차이율' KPI에 필요합니다. 요청 금액과 실제 금액의 차이를 분석하면 잘못 반품된 상품, 재입고 수수료, 정책 조정 등의 문제를 파악하고 재무 정확성과 고객 만족도를 살펴볼 수 있습니다.
중요한 이유
재무 분석의 기준이 되며, 환불 금액 차이를 계산하고 잠재적인 문제를 파악하는 데 활용됩니다.
확보 방법
이 값은 Oracle Fusion SCM의 RMA 또는 반품 요청 헤더에 저장해야 하며, Order Management 모듈에 있을 가능성이 높습니다.
예시
129.9945.501200.00
|
|||
|
종료 시각
EndTime
|
활동이 완료된 시점을 나타내는 타임스탬프입니다. | ||
|
설명
종료 시각은 활동이 완료된 시점을 나타냅니다. StartTime은 이벤트가 시작된 시점을 나타내며, 종료 시각은 해당 이벤트의 실제 처리 시간을 계산하는 데 필요합니다. 순간적으로 끝나는 이벤트는 StartTime과 종료 시각이 같을 수 있습니다. 분석에서는 종료 시각과 StartTime의 차이로 활동의 '처리 시간'을 계산합니다. 이를 통해 단계 사이의 대기 시간이 아니라 실제로 시간이 오래 걸리는 단계를 찾아낼 수 있습니다. 상세한 병목 분석과 리소스 효율성 계산에 필수적입니다.
중요한 이유
개별 활동의 실제 처리 시간을 계산하고 실제 작업 시간과 대기 시간을 구분하는 데 필요한 속성입니다.
확보 방법
원본 시스템 로그의 별도 필드일 수 있으며, 다음 활동의 StartTime을 기준으로 계산할 수도 있습니다.
예시
2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
|
|||
|
처리 담당자
ProcessingAgent
|
반품 프로세스의 특정 활동을 수행한 사용자 또는 담당자입니다. | ||
|
설명
이 속성은 RMA 승인이나 환불 처리와 같은 작업을 수행한 직원 또는 시스템 사용자를 식별합니다. 개인별 담당자를 추적하지 않는 경우 팀이나 부서를 가리킬 수도 있습니다. 담당자별 성과 분석은 운영 관리에 중요합니다. 이 속성을 사용하면 '반품 처리 담당자 성과' 대시보드에서 담당자별 업무량, 활동 소요 시간, 재작업률을 비교할 수 있습니다. 분석 결과를 통해 교육이 필요한 영역을 찾고 성과가 높은 담당자를 파악하며 리소스를 더 효과적으로 배분할 수 있습니다.
중요한 이유
사용자나 팀별 성과를 분석해 성과가 높은 담당자, 교육 기회, 업무량 불균형을 파악할 수 있습니다.
확보 방법
일반적으로 Oracle Fusion SCM의 거래 로그에서 'USER_ID', 'PROCESSED_BY', 'AGENT_NAME'과 같은 필드로 확인할 수 있습니다.
예시
홍길동김민지이준호
|
|||
|
환불 SLA 목표일
RefundSlaTargetDate
|
서비스 수준 계약에 따라 환불을 완료해야 하는 날짜입니다. | ||
|
설명
이 속성은 각 반품 건의 환불 완료 기한을 지정합니다. SLA 목표는 회사 정책, 고객 등급 또는 반품 사유에 따라 정해지는 경우가 많습니다. 이 날짜는 처리 적시성과 규정 준수를 측정하는 기준입니다. '환불 정책 SLA 준수' 대시보드에 직접 사용되며, '환불 SLA 준수율' KPI를 계산하는 데 필요합니다. 실제 환불 완료일을 목표일과 비교하면 SLA 미준수 건을 찾고 지연 위험이 있는 건의 우선순위를 정할 수 있습니다.
중요한 이유
기한 내 처리 여부를 측정하는 기준이며, SLA 준수 KPI 계산에 필요합니다.
확보 방법
반품 건에 날짜 필드로 저장되어 있을 수 있으며, 반품 접수일에 미리 정한 기간(예: 14일)을 더해 계산해야 할 수도 있습니다.
예시
2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
|
|||
|
RMA 번호
RmaNumber
|
Return Merchandise Authorization 거래를 식별하는 고유 ID입니다. | ||
|
설명
RMA 번호는 고객이 제품을 반품할 수 있도록 발급하는 공식 승인 번호입니다. 반품 건 ID와 같은 경우가 많지만, 일부 시스템에서는 별도의 선행 식별자로 관리합니다. 이 속성은 내부 사용자와 고객 모두가 사용하는 주요 업무 참조 번호입니다. 반품 건을 검색하고 필터링할 때 활용할 수 있으며, 반품 관련 커뮤니케이션에서 주로 사용하는 번호이기도 합니다.
중요한 이유
주요 업무 참조 번호로, 운영 현황 추적과 고객 커뮤니케이션에 활용됩니다.
확보 방법
Oracle Order Management의 Return Merchandise Authorization 객체에 지정된 기본 식별자입니다.
예시
789001789002789003
|
|||
|
SLA 준수 여부
IsSlaCompliant
|
환불이 정해진 SLA 목표 시간 내에 처리됐는지 나타내는 불리언 값입니다. | ||
|
설명
이 계산 속성은 각 반품 건의 SLA 준수 여부를 참 또는 거짓으로 표시합니다. 실제 환불 완료 시각을 'RefundSlaTargetDate'와 비교해 결정합니다. 이 값은 준수율을 간편하게 측정하고 시각화하는 데 필요합니다. '환불 정책 SLA 준수' 대시보드에 사용되며, '환불 SLA 준수율' KPI 계산을 간소화합니다. 또한 건을 빠르게 필터링하고 근본 원인을 분석해 SLA를 지키지 못한 이유를 파악할 수 있습니다.
중요한 이유
날짜 비교 결과를 불리언 지표로 표시해 SLA 모니터링과 보고를 간소화합니다.
확보 방법
계산 필드입니다. 'Refund Processed' 시각이 'RefundSlaTargetDate'와 같거나 이르면 참, 그렇지 않으면 거짓입니다.
예시
truefalse
|
|||
|
고객 ID
CustomerId
|
반품을 신청한 고객의 고유 ID입니다. | ||
|
설명
이 속성은 반품 건과 관련된 고객을 식별하는 고유 ID입니다. 반품 프로세스와 고객 데이터베이스를 연결합니다. 고객 관점에서 반품을 분석하면 중요한 패턴을 찾을 수 있습니다. 예를 들어 반품 빈도가 유난히 높은 고객을 파악해 만족도 문제나 사기 가능성을 살펴볼 수 있습니다. 고객 세그먼트별 분석을 통해 특정 그룹의 반품 행동이 다른지도 확인할 수 있습니다.
중요한 이유
고객별 분석을 통해 반복 반품 고객과 세그먼트별 행동, 사기 가능성을 파악할 수 있습니다.
확보 방법
Oracle Order Management에서 원래 판매 주문 또는 반품 요청 헤더의 고객 ID나 파티 ID로 확인할 수 있습니다.
예시
CUST-100589743ACC-54321
|
|||
|
반품 유형
ReturnType
|
환불, 교환, 수리 등 예상 결과에 따라 반품을 분류합니다. | ||
|
설명
이 속성은 처리 중인 반품의 유형을 구분합니다. 고객이 환불을 받는지, 교체 제품을 받는지, 수리된 제품을 받는지에 따라 프로세스 흐름과 필요한 단계가 크게 달라질 수 있습니다. 반품 유형별 분석은 프로세스의 차이를 파악하는 데 필요합니다. 환불과 교환의 프로세스 맵을 각각 작성해 경로별 병목과 성과 특성을 찾을 수 있습니다. 이러한 구분은 대상에 맞는 프로세스 개선을 추진하는 데 중요합니다.
중요한 이유
교환과 환불은 처리 단계가 다른 경우가 많으므로, 프로세스 경로별로 분석을 구분할 수 있습니다.
확보 방법
일반적으로 Oracle Order Management의 RMA 헤더 또는 품목에 범주나 유형 필드로 저장됩니다.
예시
환불교환수리
|
|||
|
재작업 여부
IsRework
|
활동이 재작업 루프에 포함되는지 나타내는 불리언 값입니다. | ||
|
설명
이 값은 같은 건에서 이전 단계가 반복된 활동을 표시해 프로세스 루프나 재작업을 식별합니다. 예를 들어 상품이 검사에 불합격해 다시 검사해야 한다면 두 번째 검사 이벤트를 재작업으로 표시합니다. 이 속성은 프로세스 비효율을 정량화하는 데 중요합니다. '반품 처리 재작업률' 대시보드와 '반품 재작업 이벤트 빈도' KPI 계산에 사용됩니다. 재작업의 규모와 원인을 파악하는 것은 process mining의 주요 목적입니다. 이를 통해 낭비되는 작업과 지연, 비용 증가를 직접 확인할 수 있습니다.
중요한 이유
프로세스 비효율과 반복 작업을 직접 표시해 재작업의 원인을 쉽게 정량화하고 분석할 수 있습니다.
확보 방법
단일 건에서 반복된 활동을 감지하는 process mining 소프트웨어의 알고리즘으로 계산하는 속성입니다.
예시
truefalse
|
|||
|
제품 ID
ProductId
|
반품 대상 제품을 식별하는 고유 ID입니다. | ||
|
설명
이 속성은 반품 대상 제품을 식별하는 SKU 또는 품목 번호와 같은 고유 ID입니다. 반품 프로세스와 제품 카탈로그를 연결합니다. 제품별 분석은 문제가 있는 품목을 찾는 데 중요합니다. 제품 ID를 기준으로 프로세스 분석을 필터링하거나 구분하면 반품률이 높거나 검사 시간이 길고 특정 결함 유형이 반복되는 제품을 파악할 수 있습니다. 이 정보는 품질 관리, 공급망 관리, 제품 개발에 유용합니다.
중요한 이유
반품 프로세스를 특정 제품과 연결해 제품 품질과 반품 유형을 분석할 수 있습니다.
확보 방법
Oracle Order Management 또는 Inventory 모듈의 RMA 품목에 있는 'INVENTORY_ITEM_ID' 또는 이와 유사한 필드입니다.
예시
PROD-5540-ASKU-98765ITEM-001-B
|
|||
|
창고 ID
WarehouseId
|
반품 상품을 인수한 창고 또는 시설의 식별자입니다. | ||
|
설명
이 속성은 고객이 반품한 상품을 인수하고 처리한 물리적 장소를 나타냅니다. 물류 센터나 창고 등이 해당합니다. 창고별 분석은 특정 장소에서 발생하는 성과 문제를 찾는 데 중요합니다. 시설별 검사 시간, 처리 결과, 전체 처리 시간을 비교할 수 있습니다. 이를 통해 특정 사업장의 운영 비효율, 인력 문제, 교육 필요성을 파악할 수 있습니다.
중요한 이유
장소별 성과를 분석해 지역이나 시설에 따른 병목과 비효율을 파악할 수 있습니다.
확보 방법
흔히 'ORGANIZATION_ID'라고 하는 이 필드는 Oracle Inventory Management의 입고 거래와 연결됩니다.
예시
WH-US-WESTWH-EU-CENTRALDC-01
|
|||
|
처리 결과 코드
DispositionCode
|
반품된 실물 상품의 최종 처리 방식을 나타내는 코드입니다. | ||
|
설명
처리 결과 코드는 검사 후 반품된 제품의 처리 방식을 나타냅니다. 예를 들어 재고로 다시 입고했는지, 폐기했는지, 재정비를 위해 보냈는지, 공급업체에 반송했는지를 기록합니다. 이 정보는 반품이 재무와 운영에 미치는 영향을 분석하는 데 유용합니다. 처리 결과 코드를 분석하면 재판매할 수 없는 상품과 관련된 비용을 파악하고 재정비 프로세스를 개선할 기회를 찾을 수 있습니다. 반품 프로세스를 재고 및 재무 결과와 연결하는 정보입니다.
중요한 이유
반품 후 재고가 어떻게 처리됐는지 보여 주므로 회수율과 비용을 파악할 수 있습니다.
확보 방법
검사 활동이 끝난 뒤 Oracle Inventory Management 또는 Warehouse Management 모듈에 기록됩니다.
예시
RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
|
|||
|
환불 금액 차이
RefundAmountDiscrepancy
|
요청 환불 금액과 실제 환불 금액의 차이를 계산한 값입니다. | ||
|
설명
이 지표는 고객이 요청한 금액과 실제로 받은 금액의 차이를 나타냅니다. 'RequestedRefundAmount'에서 'ActualRefundAmount'를 빼서 계산합니다. 이 계산값은 '환불 금액 차이율' KPI의 기준이 됩니다. 0이 아닌 값은 처리 과정에서 금액이 조정됐음을 의미합니다. 재입고 수수료나 파손에 따른 공제 등 차이가 발생한 이유를 분석하면 정책의 효과와 고객 안내 방식을 살펴볼 수 있습니다.
중요한 이유
환불 과정에서 조정된 금액을 정량화해 정책과 검사 결과가 미치는 영향을 분석할 수 있습니다.
확보 방법
계산 필드: 'RequestedRefundAmount' - 'ActualRefundAmount'.
예시
0.005.50-10.00
|
|||
반품 및 환불 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
RMA 생성
|
이 활동은 Oracle Fusion SCM에서 반품 자재 승인(RMA)이 생성되는 시점으로, 반품 프로세스의 공식적인 시작을 나타냅니다. 사용자가 새 RMA 판매 주문 레코드를 생성하거나 자동 프로세스가 이를 생성할 때 이벤트가 명시적으로 기록되는 경우가 많습니다. | ||
|
중요한 이유
반품 프로세스 전체의 주요 시작 이벤트입니다. 이 활동부터 다른 활동까지 걸린 시간을 분석하면 전체 처리 기간을 파악하고 초기 지연을 찾을 수 있습니다.
확보 방법
Oracle Fusion Order Management의 반품 주문 헤더 생성 시각을 기준으로 기록합니다. RMA 문서를 처음 저장한 시점에 해당합니다.
기록
반품 주문 헤더 레코드의 생성일을 추적합니다.
이벤트 유형
explicit
|
|||
|
RMA 승인
|
이 주요 단계는 반품 요청이 업무 규칙에 따라 검증되고 승인되었음을 나타냅니다. 일반적으로 RMA 상태 변경을 기준으로 추정하며, 이후 고객의 상품 발송과 같은 단계가 진행될 수 있습니다. | ||
|
중요한 이유
승인은 프로세스의 중요한 관문입니다. 이 단계가 지연되면 전체 반품 처리 시간과 고객 만족도에 직접 영향을 줍니다. 승인 병목을 분석하려면 이 활동을 반드시 살펴봐야 합니다.
확보 방법
RMA 주문 헤더 또는 라인의 상태가 '승인됨' 또는 '입고 대기'로 변경된 시각을 기준으로 추정합니다.
기록
RMA 상태가 승인 상태로 변경된 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
대변 메모 생성
|
고객 환불을 승인하기 위해 매출채권(Accounts Receivable)에서 대변 메모를 생성하는 재무 활동입니다. Order Management의 반품 프로세스가 시작하는 명시적 이벤트입니다. | ||
|
중요한 이유
대변 메모 생성은 회사가 고객에게 환불하기로 확정한 시점을 나타냅니다. 프로세스의 재무 정산 단계 전체를 시작하는 기준이 됩니다.
확보 방법
Oracle Accounts Receivable에 명시적으로 기록되는 거래입니다. 대변 메모의 판매 주문 참조를 통해 원래 RMA와 연결할 수 있습니다.
기록
AR에서 대변 메모 거래가 생성된 날짜를 사용합니다.
이벤트 유형
explicit
|
|||
|
반품 건 종료
|
RMA와 관련된 입고, 처리 방식 결정, 재무 정산 등의 모든 작업이 완료되었음을 나타내는 마지막 활동입니다. 일반적으로 RMA 주문의 최종 '종료' 상태를 기준으로 추정합니다. | ||
|
중요한 이유
이 이벤트는 프로세스의 최종 종료 시점입니다. 전체 처리 시간을 계산하고 미종결 상태로 남아 있는 건이 없는지 확인하는 데 중요합니다.
확보 방법
Oracle Order Management에서 RMA 주문 헤더와 모든 라인이 최종 '종료' 상태가 된 시각을 기준으로 추정합니다.
기록
RMA 헤더 또는 라인의 상태가 '종료'로 변경된 마지막 시각을 기록합니다.
이벤트 유형
inferred
|
|||
|
상품 검사 완료
|
상품 검사가 끝나고 품질 평가 결과가 기록된 시점을 나타냅니다. 일반적으로 Oracle Inventory Management 또는 Quality Management에서 RMA 상태를 업데이트하는 명시적 거래로 기록됩니다. | ||
|
중요한 이유
검사 결과에 따라 환불 승인이나 거부 등 다음 단계가 결정됩니다. 검사 활동 자체에 걸린 시간은 창고 효율성을 나타내는 주요 지표입니다.
확보 방법
검사 담당자가 Oracle Inventory 또는 Quality Management에서 RMA 입고 건의 검사 작업을 완료한 거래 타임스탬프를 기준으로 기록합니다.
기록
검사 거래의 완료 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
상품 입고
|
창고나 처리 센터에 반품 상품이 실제로 도착한 시점을 나타냅니다. 상품을 스캔해 RMA에 입고된 것으로 기록할 때 Oracle Fusion Inventory Management에 명시적으로 저장되는 이벤트입니다. | ||
|
중요한 이유
상품 입고는 이후 검사와 처리 단계를 시작하는 중요한 시점입니다. 'RMA 승인'부터 '상품 입고'까지 걸린 시간을 측정하면 물류 및 배송 성과를 분석할 수 있습니다.
확보 방법
Oracle Inventory Management에 명시적으로 기록되는 거래입니다. RMA 입고 거래일에 해당합니다.
기록
Inventory의 RMA 입고 거래 타임스탬프를 사용합니다.
이벤트 유형
explicit
|
|||
|
환불 처리 완료
|
고객에게 환불금 지급이 완료된 시점을 나타냅니다. 지급 정산 거래가 Oracle Financials에 기록될 때 명시적으로 저장되는 이벤트입니다. | ||
|
중요한 이유
고객 관점에서 전체 환불 처리 시간을 측정하는 중요한 종료 시점입니다. 고객에 대한 재무상 의무가 이행되었음을 확인합니다.
확보 방법
대변 메모를 정산하는 지급 거래의 회계일 또는 정산일을 Oracle Accounts Payable이나 Treasury에서 확인해 기록합니다.
기록
대변 메모를 정산하는 지급 거래의 정산일을 사용합니다.
이벤트 유형
explicit
|
|||
|
RMA 반려
|
고객의 반품 요청을 최종적으로 거부한 결정을 나타냅니다. 일반적으로 승인 단계에서 RMA 상태가 '반려' 또는 '취소'로 변경된 시점을 기준으로 추정합니다. | ||
|
중요한 이유
중요한 예외 경로입니다. 반려 빈도와 사유를 분석하면 반품 정책, 고객 기대 또는 사기 시도와 관련된 문제를 찾을 수 있습니다.
확보 방법
RMA 주문 헤더 또는 라인의 상태가 '반려' 또는 이에 해당하는 최종 상태로 변경된 시각을 기준으로 추정합니다.
기록
'반려' 또는 '취소' 상태로 변경된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
RMA 승인 요청 제출
|
생성된 RMA를 내부 검토 및 승인 절차에 제출한 시점을 나타냅니다. 보통 RMA 상태가 초안 또는 입력 상태에서 승인 대기 상태로 변경된 시점을 기준으로 추정합니다. | ||
|
중요한 이유
이 시점을 추적하면 승인 전 단계에 걸린 시간을 측정할 수 있습니다. 데이터 입력 시간과 승인 담당자의 조치를 기다린 시간을 구분할 수 있습니다.
확보 방법
Order Management 승인 워크플로에서 RMA 주문 헤더 또는 라인의 상태가 '승인 대기' 또는 이에 해당하는 상태로 변경된 시각을 기준으로 추정합니다.
기록
'승인 대기' 상태로 변경된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
|
고객 안내 완료
|
환불 처리나 교환 상품 발송 등 반품 건의 처리 결과를 고객에게 알린 시점을 나타냅니다. 일반적으로 커뮤니케이션 로그나 건의 상태 업데이트를 통해 기록합니다. | ||
|
중요한 이유
고객 만족을 위해 적시에 안내하는 것이 중요합니다. 이 활동을 분석하면 커뮤니케이션 관련 서비스 수준 계약을 준수하는지 확인할 수 있습니다.
확보 방법
시스템 분석이 필요합니다. 연동된 CRM이나 커뮤니케이션 플랫폼에 기록될 수 있으며, RMA 또는 관련 서비스 요청의 상태를 수동으로 업데이트할 수도 있습니다.
기록
외부 커뮤니케이션 시스템의 타임스탬프 또는 수동 업데이트 시각입니다.
이벤트 유형
inferred
|
|||
|
고객의 반품 상품 발송
|
고객이 반품 상품을 회사로 발송하는 활동입니다. Oracle SCM에 직접 기록되지 않는 경우가 많지만, 운송사 연동 데이터나 수동 상태 업데이트를 통해 추정할 수 있습니다. | ||
|
중요한 이유
이 활동을 통해 고객 행동과 상품 운송에 걸리는 시간을 파악할 수 있습니다. 내부 처리 지연과 배송 지연을 구분하는 데 도움이 됩니다.
확보 방법
RMA와 연결된 운송사 배송 데이터를 바탕으로 추정하거나 Oracle SCM에서 상태를 수동으로 업데이트할 수 있습니다. 연동이 없다면 이 이벤트를 사용할 수 없을 수 있습니다.
기록
연동된 운송사 API의 타임스탬프 또는 수동 입력 필드의 시각입니다.
이벤트 유형
inferred
|
|||
|
교환 주문 생성
|
고객이 환불 대신 교환을 요청한 경우 발생하는 활동입니다. 일반적으로 원래 RMA와 연결된 새 판매 주문이 생성되는 명시적 이벤트입니다. | ||
|
중요한 이유
이 활동은 중요한 프로세스 변형을 식별합니다. 각 경로의 처리 시간을 정확히 분석하려면 교환 프로세스와 환불 프로세스를 구분해야 합니다.
확보 방법
Order Management에서 새 판매 주문 문서를 생성하는 명시적 이벤트입니다. 참조 필드를 통해 RMA와 연결해야 합니다.
기록
RMA와 연결된 새 판매 주문의 생성일을 사용합니다.
이벤트 유형
explicit
|
|||
|
반품 상품 처리 방식 결정
|
검사 후 반품 상품을 '재고로 반입'하거나 '폐기'하는 등 처리 방식을 결정하는 활동입니다. 상품을 최종 목적지로 이동하는 명시적 재고 거래를 통해 기록됩니다. | ||
|
중요한 이유
이 단계는 재고 정확성과 재무 조정에 중요합니다. 처리 방식을 분석하면 반품 사유와 제품 품질 문제를 파악할 수 있습니다.
확보 방법
검사 후 Oracle Inventory Management에 하위 재고 이동이나 상품 상태 업데이트 등의 거래로 기록됩니다.
기록
처리 방식을 실행한 재고 거래의 타임스탬프를 추적합니다.
이벤트 유형
explicit
|
|||
|
상품 검사 시작
|
반품 상품의 상태를 확인하기 위한 실물 검사가 시작된 시점을 나타냅니다. 창고 관리 모듈에서 상품의 위치나 상태가 변경된 시점을 기준으로 추정하거나, 스캔 이벤트를 명시적으로 기록할 수 있습니다. | ||
|
중요한 이유
상품 입고부터 검사 시작까지 걸린 시간을 측정하면 검사 구역에서 발생하는 대기 지연을 파악할 수 있습니다. 이는 흔히 발생하는 병목입니다.
확보 방법
입고 라인의 상태 변경이나 Oracle Inventory Management에서 상품을 검사 위치로 옮긴 거래를 통해 기록할 수 있습니다. 명시적으로 기록하려면 별도의 설정이 필요할 수 있습니다.
기록
상태 변경 또는 검사 구역으로의 재고 이동이 발생한 시각입니다.
이벤트 유형
inferred
|
|||
|
환불 처리 시작
|
환불 지급 절차가 시작된 시점을 나타냅니다. 대변 메모 상태가 미결에서 지급 처리 중을 나타내는 상태로 변경된 시점을 기준으로 추정하는 경우가 많습니다. | ||
|
중요한 이유
이 활동을 통해 대변 메모의 승인 및 생성 단계와 실제 지급 처리를 구분할 수 있습니다. 지급 처리는 다른 팀이나 시스템에서 담당할 수 있으며 지연이 발생하는 원인일 수 있습니다.
확보 방법
Accounts Receivable에서 대변 메모 상태가 변경된 시점이나 대변 메모를 참조하는 지급 레코드가 Accounts Payable에 생성된 시점을 기준으로 추정합니다.
기록
대변 메모 상태가 '지급 대기' 또는 유사한 상태로 변경된 시각을 확인합니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내서
시작할 준비가 되셨나요?
이 템플릿으로 데이터 수집을 간소화하고 반품 및 환불 처리에 관한 분석 결과를 확인하세요. 지금 프로세스 개선을 시작해 보세요.
반품 및 환불 처리의 병목을 해소하고 지금 최적화하세요
Oracle Fusion SCM의 비효율을 찾아 처리 시간을 30% 단축합니다.
신용카드가 필요하지 않습니다. 5분 이내에 설정할 수 있습니다.