반품 및 환불 처리 데이터 템플릿
반품 및 환불 처리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
반품 및 환불 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 반품 건 ID ReturnCaseId | 개별 고객 반품 프로세스를 식별하는 고유 ID로, 시작부터 종료까지 관련된 모든 활동을 연결합니다. | ||
| 설명 반품 건 ID는 하나의 반품 건에 속하는 모든 이벤트와 활동을 묶는 기본 식별자입니다. 고객의 반품 요청마다 고유 ID가 부여되어 전체 프로세스를 처음부터 끝까지 추적할 수 있습니다. process mining에서 이 속성은 프로세스 흐름을 재구성하는 데 필수적입니다. 각 반품 건의 이벤트를 연결해 일관된 타임라인을 구성하므로 처리 시간, 프로세스 변형, 병목을 분석할 수 있습니다. 예를 들어 '반품 요청 시작', '상품 입고', '환불 처리'와 같이 서로 다른 이벤트를 하나의 반품 건으로 연결합니다. 중요한 이유 반품을 시작부터 끝까지 추적하는 데 필요한 기본 키입니다. 이를 통해 처리 시간과 프로세스 변형을 비롯한 건별 분석을 수행할 수 있습니다. 확보 방법 일반적으로 반품 주문 헤더 테이블 VBAK의 판매 문서 번호(VBELN)입니다. 문서 범주(VBTYP)는 반품을 나타냅니다. 예시 600001896000019060000191 | |||
| 이벤트 시각 EventTime | 특정 활동이 발생한 시점을 나타내는 정확한 타임스탬프입니다. | ||
| 설명 이벤트 시각은 시스템에 업무 이벤트가 기록된 날짜와 시간을 나타냅니다. 활동을 시간순으로 정렬하고 시간 기반 분석을 수행하는 데 필요한 정보입니다. process mining에서는 이 속성을 사용해 활동 간 처리 시간을 계산하고 각 단계에 걸리는 시간을 파악하며 시간에 따른 프로세스 성과를 분석합니다. 병목을 찾고 SLA 준수 여부를 모니터링하며 반품 프로세스의 시간적 흐름을 이해하는 기준이 됩니다. 중요한 이유 이 타임스탬프는 이벤트를 시간순으로 정렬하고 처리 시간과 주기를 계산하며 프로세스 지연을 파악하는 데 필요합니다. 확보 방법 일반적으로 문서 생성이나 상태 변경과 관련된 날짜 및 시간 필드에서 가져옵니다. 예를 들어 VBAK, LIKP, BKPF 등의 테이블에 있는 ERDAT(생성일)와 ERZET(생성 시간), 또는 회계 문서의 전기일(BUDAT)을 사용합니다. 예시 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| 활동 이름 ActivityName | 반품 및 환불 프로세스에서 발생한 특정 업무 활동 또는 이벤트의 이름입니다. | ||
| 설명 이 속성은 반품 처리 주기의 개별 단계나 이정표를 나타냅니다. '반품 주문 승인', '상품 검수 완료'와 같은 활동은 실제로 수행된 업무를 보여줍니다. SAP S/4HANA에 기록된 상태 변경, 문서 생성 또는 특정 사용자 작업을 바탕으로 도출합니다. 활동의 순서와 빈도를 분석하는 것이 process mining의 기본입니다. 이를 통해 프로세스 맵을 시각화하고 일반적이거나 드문 경로를 파악할 수 있습니다. 자주 반복되는 활동을 찾아 재작업이나 비효율이 발생하는 지점도 확인할 수 있습니다. 중요한 이유 활동은 프로세스 맵의 기본 구성 요소입니다. 이를 통해 프로세스 흐름을 시각화하고 분석하며 병목과 변형을 파악할 수 있습니다. 확보 방법 활동 이름은 일반적으로 여러 데이터에서 도출합니다. 예를 들어 VBUK/VBUP의 문서 상태 변경, VBAK(판매 문서) 및 BKPF(회계 문서)와 같은 헤더 테이블의 생성 이벤트, MSEG의 자재 이동 상태를 활용합니다. 예시 반품 요청 시작창고에 상품 입고대변 메모 생성환불 처리 | |||
| 소스 시스템 ID SourceSystemId | 데이터를 추출한 소스 시스템의 식별자입니다. | ||
| 설명 이 속성은 이벤트 데이터가 생성된 기준 시스템을 나타냅니다. 이 프로세스에서는 일반적으로 SAP S/4HANA 인스턴스 ID를 사용합니다. 여러 시스템을 사용하는 환경에서는 데이터 계보를 추적하고 문제를 해결하며 데이터 무결성을 확인하는 데 이 필드가 중요합니다. 반품이 여러 ERP 인스턴스에서 처리되거나 창고 관리 시스템과 같은 외부 시스템에 연계되는 경우 데이터의 출처를 구분할 수 있습니다. 중요한 이유 여러 시스템을 사용하는 환경에서 데이터의 출처와 계보를 파악하는 데 필요한 정보를 제공해 데이터 추적성과 신뢰성을 높입니다. 확보 방법 일반적으로 데이터 추출 시 설정하는 고정값입니다. 시스템 ID(SID)와 같은 SAP 시스템 관리 정보를 통해 확인할 수 있습니다. 예시 S4H_PROD_100S4Q_DEV_200 | |||
| 최근 데이터 업데이트 LastDataUpdateTimestamp | 이벤트 데이터가 마지막으로 새로 고침되거나 추출된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 데이터가 마지막으로 추출되거나 업데이트된 날짜와 시간을 기록합니다. 분석 중인 데이터 세트의 최신 상태를 보여주는 메타데이터입니다. process mining 분석에 사용되는 데이터가 얼마나 최신인지 파악하는 데 중요합니다. 사용자는 데이터의 최신 상태를 확인할 수 있으며, 진행 중인 건을 추적하는 운영 모니터링과 대시보드에서 특히 유용합니다. 중요한 이유 데이터의 최신 상태를 나타냅니다. 최신 정보를 바탕으로 분석하고 대시보드를 구성하는 데 필요합니다. 확보 방법 일반적으로 ETL 또는 데이터 파이프라인 도구가 데이터를 추출할 때 데이터 세트에 생성해 기록합니다. 예시 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 고객 ID CustomerId | 반품을 요청한 고객의 고유 식별자입니다. | ||
| 설명 이 속성은 반품을 요청한 고객을 식별하고 프로세스 건을 고객 마스터 데이터의 특정 고객과 연결합니다. 고객별 반품을 분석하면 반품률이 유난히 높은 고객과 같은 패턴을 파악할 수 있습니다. 이는 부정 행위나 고객 불만을 나타낼 수 있습니다. 고객 유형, 거래 금액, 이력에 따라 반품 프로세스를 분류해 맞춤형 서비스 수준을 제공하는 데도 활용할 수 있습니다. 중요한 이유 반품을 특정 고객과 연결해 고객 행동과 고객군을 분석하고 반품이 잦은 고객을 파악할 수 있습니다. 확보 방법 반품 주문 헤더 테이블(VBAK)의 고객 번호 필드(KUNNR)에서 확인할 수 있습니다. 예시 CUST-001234CUST-005678CUST-009012 | |||
| 반품 사유 ReturnReason | 고객이 상품을 반품하는 이유입니다. | ||
| 설명 이 속성은 '상품 불량', '사이즈 오류', '더 이상 필요하지 않음'과 같이 고객이 밝힌 반품 사유를 기록합니다. 일반적으로 반품을 시작할 때 미리 정의된 사유 코드 목록에서 선택합니다. 반품 사유를 분석하면 제품 품질 문제를 파악하고 상품 설명을 개선하거나 판매 프로세스를 보완할 수 있습니다. 고객 불만의 원인을 직접 확인하고 반품률을 낮추기 위해 개선이 필요한 영역의 우선순위를 정하는 데 도움이 됩니다. 중요한 이유 반품이 발생하는 이유를 파악할 수 있어 제품 품질, 주문 처리 오류, 고객 기대와의 차이 등 근본 원인을 분석하는 데 도움이 됩니다. 확보 방법 일반적으로 반품 판매 주문 품목 테이블(VBAP)의 ABGRU 필드(판매 문서 거부 사유)에 저장됩니다. 예시 001 - 품질 불량002 - 운송 중 파손005 - 잘못된 상품 배송 | |||
| 사용자 이름 UserName | 활동을 수행한 직원의 사용자 ID입니다. | ||
| 설명 이 속성은 반품 승인이나 대변 메모 생성과 같은 작업을 완료한 사용자 또는 시스템 에이전트를 식별합니다. SAP에서는 문서를 생성하거나 변경한 사용자를 기록하는 필드에 저장되는 경우가 많습니다. 사용자별 분석을 통해 성과가 높은 개인이나 팀, 교육이 필요한 영역, 업무량 분포를 파악할 수 있습니다. 프로세스 작업을 특정 사용자와 연결하므로 편차를 조사하고 규정 준수 및 감사 업무를 지원하는 데도 필요합니다. 중요한 이유 프로세스 활동을 특정 사용자와 연결해 팀 성과, 업무량, 규정 준수 여부를 분석할 수 있습니다. 확보 방법 일반적으로 문서 헤더 테이블에서 확인할 수 있습니다. 예를 들어 VBAK(판매 주문), LIKP(납품), BKPF(회계 문서)의 ERNAM(생성자) 필드가 있습니다. 사용자 마스터 테이블 USR21의 정보를 추가로 활용할 수 있습니다. 예시 CBROWNASMITHWF_BATCH | |||
| 이벤트 종료 시각 EventEndTime | 활동이 완료된 시점을 나타내는 타임스탬프로, 활동 소요 시간을 계산하는 데 사용합니다. | ||
| 설명 StartTime(EventTime)이 활동의 시작 시점을 나타낸다면 EventEndTime은 종료 시점을 나타냅니다. 시스템에서 자동 생성되는 이벤트는 순간적으로 발생하므로 시작과 종료 시각이 같은 경우가 많습니다. 반면 '상품 검수'처럼 소요 시간을 측정할 수 있는 활동에서는 이 속성이 중요합니다. 이 속성을 사용하면 활동별 처리 시간을 직접 계산할 수 있습니다. 활동 사이의 대기 시간뿐 아니라 실제로 어느 단계에서 시간이 가장 많이 걸리는지 파악하는 성과 분석의 기본 정보입니다. 중요한 이유 개별 활동의 소요 시간을 정확히 계산해 특정 프로세스 단계의 비효율을 파악할 수 있습니다. 확보 방법 다른 데이터에서 도출하는 경우가 많습니다. 일부 활동은 별도 필드에 기록되지만, 일반적으로 해당 건에서 다음 활동이 시작된 시각을 사용합니다. 예시 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| 제품 ID ProductId | 반품 대상 상품의 고유 식별자입니다. | ||
| 설명 이 속성은 반품 대상인 자재 또는 제품을 나타냅니다. 반품 프로세스를 제품 카탈로그의 특정 상품과 연결합니다. 제품별 반품을 분석하면 반품률이 높은 상품을 파악할 수 있습니다. 이는 품질 결함, 부정확한 상품 설명, 제조 문제를 나타낼 수 있습니다. 이 데이터는 제품 설계, 공급업체 관리, 재고 전략에 관한 의사결정에 도움이 됩니다. 중요한 이유 반품 프로세스를 특정 제품과 연결해 상품별 반품률을 분석하고 품질이나 설명의 문제를 파악할 수 있습니다. 확보 방법 반품 주문 품목 테이블(VBAP) 또는 반품 납품 품목 테이블(LIPS)의 자재 번호 필드(MATNR)에서 확인할 수 있습니다. 예시 FG-10023HW-45981SW-LICENSE-PREM | |||
| 환불 금액 RefundAmount | 고객에게 환불한 최종 금액입니다. | ||
| 설명 이 속성은 반품 프로세스가 완료된 후 고객에게 실제로 대변 처리하거나 환불한 금액을 나타냅니다. 대변 메모와 같은 재무 문서에 기록됩니다. 다양한 분석에 활용되는 주요 재무 지표입니다. '환불 금액 차이 분석' 대시보드에서 요청 금액과 비교하는 데 필요합니다. 금액별로 반품을 분류해 고액 반품의 처리 경로가 다르거나 해결에 더 오래 걸리는지도 확인할 수 있습니다. 중요한 이유 반품의 재무 영향을 추적합니다. 환불 정확도를 분석하고 고액 반품을 파악하며 전체 비용을 이해하는 데 필요합니다. 확보 방법 대변 메모 문서의 순액 필드(NETWR)에서 가져옵니다. VBRK(청구 문서 헤더) 또는 BSEG(회계 문서 개별 항목)와 같은 테이블에서 확인할 수 있습니다. 예시 125.50999.0049.99 | |||
| 대변 메모 번호 CreditMemoNumber | 환불을 승인하는 대변 메모 문서의 고유 식별자입니다. | ||
| 설명 대변 메모는 반품 상품에 대해 고객 계정에 공식적으로 대변을 반영하는 청구 문서입니다. 이 속성은 해당 재무 문서의 고유 번호입니다. 대변 메모 번호를 추적하면 반품 프로세스의 재무 정산 단계를 분석할 수 있습니다. 환불 지급을 시작하는 중요한 이정표이며 재무 조정과 감사에도 필요합니다. 중요한 이유 환불을 위한 공식 재무 거래를 나타냅니다. 프로세스의 마지막 단계를 추적하고 재무 감사를 수행하는 데 중요합니다. 확보 방법 청구 문서 헤더 테이블(VBRK)의 청구 문서 번호(VBELN)입니다. 문서 범주는 대변 메모를 나타냅니다. 예시 900003459000034690000347 | |||
| 반품 납품 번호 ReturnDeliveryNumber | 반품 납품 문서의 고유 식별자입니다. | ||
| 설명 고객이 상품을 실제로 반품하면 SAP에서 입고 물류를 관리하기 위한 반품 납품 문서를 생성합니다. 이 속성은 해당 문서의 고유 번호입니다. 이 ID는 반품 상품의 실제 이동을 추적하는 데 중요합니다. 반품의 재무 처리와 물류 처리를 연결해 입고 및 검수 단계의 세부 사항을 분석할 수 있습니다. 중요한 이유 반품 주문과 상품의 실제 입고를 연결하는 중요한 정보입니다. 물류 및 창고 처리 시간을 분석하는 데 필요합니다. 확보 방법 납품 헤더 테이블(LIKP)의 납품 문서 번호(VBELN)입니다. 문서 범주는 반품 납품을 나타냅니다. 예시 840000128400001384000014 | |||
| 반품 정책 ID ReturnPolicyId | 해당 반품 건에 적용되는 반품 정책의 식별자입니다. | ||
| 설명 이 속성은 거래에 적용되는 반품 정책 또는 규칙 집합을 나타냅니다. 정책은 제품 유형, 고객 세그먼트, 구매 후 경과 기간에 따라 달라질 수 있습니다. 이 데이터는 '반품 정책 준수 현황'을 확인하는 데 필요합니다. 각 케이스에 정책을 연결하면 시스템에서 반품 기한이나 상품 상태 요건 등의 준수 여부를 자동으로 확인하고, 분석이 필요한 예외를 표시할 수 있습니다. 중요한 이유 업무 규칙에 따라 규정 준수 여부를 자동으로 확인하여 반품 처리가 일관된 정책에 따라 이루어지도록 지원합니다. 확보 방법 일반적인 SAP 필드가 아니므로 제품 유형, 고객, 판매일 등의 데이터를 바탕으로 업무 로직에 따라 값을 산출해야 할 수 있습니다. 구현된 경우 사용자 정의 필드에 저장할 수 있습니다. 예시 표준-30일전자제품-90일 보증최종 판매-결함 | |||
| 반품 정책 준수 ReturnPolicyAdherence | 반품 케이스가 정해진 반품 정책을 준수하는지 나타내는 플래그입니다. | ||
| 설명 이 계산된 불리언 속성은 반품이 적용되는 정책의 기준을 충족하는지 나타냅니다. 예를 들어 허용된 기간 안에 반품을 신청했는지, 해당 제품에 유효한 반품 사유인지 확인할 수 있습니다. 이 속성은 '반품 정책 준수 현황' 대시보드에 직접 활용됩니다. 규정 준수율을 수치화하고 정책을 준수하지 않은 케이스를 확인해 예외 사유를 파악할 수 있으므로 정책을 더 효과적으로 적용할 수 있습니다. 중요한 이유 업무 규칙 준수 수준을 수치화하여 수익성에 영향을 주거나 프로세스 예외를 일으킬 수 있는 정책 위반을 파악하고 줄이는 데 도움이 됩니다. 확보 방법 업무 규칙에 따라 계산합니다. 예를 들어 (반품 신청일 - 최초 구매일) <= [허용 반품 기간]으로 계산할 수 있습니다. 이 계산에는 최초 구매일과 정책 규칙이 필요합니다. 예시 truefalse | |||
| 반품 주문 상태 ReturnOrderStatus | 반품 케이스의 현재 전체 상태입니다. | ||
| 설명 이 속성은 특정 시점의 반품 케이스 전체 상태를 '접수', '처리 중', '종료' 등으로 나타냅니다. 일반적으로 마지막으로 완료된 주요 단계의 상태를 종합해 산출합니다. '현재 반품 케이스 상태 대시보드'에서 운영 현황과 케이스 분포를 확인하는 데 필요합니다. 각 프로세스 단계에 있는 케이스 수를 파악하여 리소스와 업무량을 더 효과적으로 관리할 수 있습니다. 중요한 이유 각 케이스가 현재 프로세스의 어느 단계에 있는지 보여줍니다. 현재 업무량과 상태를 추적하는 운영 대시보드에 필요한 정보입니다. 확보 방법 관련 문서의 상태 필드에서 값을 도출합니다. 예를 들어 관련 판매 주문(VBUK/VBUP)이나 납품 문서의 헤더 상태(GBSTK) 또는 품목 상태(LFSTK)를 사용할 수 있습니다. 예시 상품 입고 대기검사 대기환불 대기종료 | |||
| 상품 검사 결과 ItemInspectionOutcome | 반품 상품을 실물 검사한 결과입니다. | ||
| 설명 이 속성은 상품이 창고에 입고된 후 진행한 검사 결과를 기록합니다. 일반적인 결과로는 '승인 - 재판매 가능', '거부 - 손상', '승인 - 재판매 가능' 등이 있습니다. 이 데이터는 이후 프로세스 단계에 필요한 맥락을 제공합니다. 전액 환불, 부분 환불 또는 환불 불가 여부를 결정하는 데 사용됩니다. 검사 결과를 분석하면 반품 거부 사유를 파악할 수 있으며, 운송 중 상품이 자주 손상되는 경우 포장 방식이나 배송 협력사에 대한 개선 의견을 얻을 수 있습니다. 중요한 이유 환불 승인 또는 거부의 판단 근거를 설명하고, 상품 상태와 환불액 조정 사유를 파악하는 데 필요한 데이터를 제공합니다. 확보 방법 이 정보는 품질 관리 모듈(QM)의 검사 로트, 반품 납품 품목(LIPS)의 상태 또는 사유 코드에 기록될 수 있습니다. 사용자 정의 필드에 저장될 수도 있습니다. 예시 승인 - 재판매 가능승인 - 수리 후 판매거부 - 고객 과실로 인한 손상거부 - 다른 상품 반품 | |||
| 요청 환불 금액 RequestedRefundAmount | 프로세스 시작 시점에 처음 요청했거나 예상한 환불 금액입니다. | ||
| 설명 이 속성은 최초 반품 요청에 기재된 반품 상품의 금액을 기록합니다. 최종 환불 금액과 비교할 기준으로 사용합니다. 이 필드는 '환불 금액 차이 분석' 대시보드에 필요합니다. 요청 금액과 실제 환불 금액을 비교하면 상품 손상에 따른 부분 환불, 재입고 수수료, 기타 조정으로 발생한 차이를 파악해 재무 처리의 정확성과 투명성을 높일 수 있습니다. 중요한 이유 환불 정확도를 측정하는 기준으로 활용하며, 예상 환불액과 실제 환불액의 차이를 파악하고 분석하는 데 도움이 됩니다. 확보 방법 일반적으로 최초 반품 판매 주문의 품목 순액을 기준으로 합니다. VBAP 테이블의 해당 품목에 기록된 순액(NETWR)을 사용합니다. 예시 125.501050.0049.99 | |||
| 자동화 여부 IsAutomated | 시스템과 사람이 작업을 수행했는지 나타내는 플래그입니다. | ||
| 설명 이 불리언 속성은 workflow나 백그라운드 작업처럼 시스템이 자동으로 실행한 작업과 사용자가 수동으로 수행한 작업을 구분합니다. '자동 환불 승인율' KPI를 계산하고 자동화 기회를 찾는 데 필요합니다. 수동 작업을 필터링하면 속도, 비용, 정확도 측면에서 자동화 효과가 큰 영역에 프로세스 개선 노력을 집중할 수 있습니다. 중요한 이유 수동 작업과 자동화된 작업을 구분합니다. 자동화 기회를 찾고 디지털 전환의 효과를 측정하는 데 중요합니다. 확보 방법 일반적으로 사용자 이름을 기준으로 값을 도출합니다. 예를 들어 사용자가 'WF_BATCH' 또는 다른 시스템 ID인 경우 해당 작업을 자동화된 것으로 표시합니다. 예시 truefalse | |||
| 재작업 여부 IsRework | 케이스 내 작업이 이전 작업의 반복인지 나타내는 플래그입니다. | ||
| 설명 이 계산된 불리언 속성은 같은 케이스에서 작업이 두 번 이상 수행된 재작업을 식별합니다. 예를 들어 상품 검사를 다시 하거나 대변 메모를 생성한 뒤 취소하고 다시 생성하는 경우입니다. '환불 처리 재작업 분석' 대시보드와 '환불 재작업률' KPI에 필요한 속성입니다. 오류가 발생하기 쉽거나 여러 번 시도해야 하는 작업을 표시해 프로세스 비효율을 수치화하고, 통제나 교육을 강화할 영역을 찾을 수 있습니다. 중요한 이유 반복 작업을 표시해 프로세스의 비효율과 오류를 파악하고, 낭비와 지연을 줄이기 위한 개선에 집중할 수 있습니다. 확보 방법 일반적으로 process mining 도구에서 계산하거나 데이터 변환 단계에서 미리 계산합니다. 같은 케이스에서 동일한 활동명이 이전에 나타났는지 확인합니다. 예시 truefalse | |||
| 처리 담당자 ProcessingAgent | 수동 작업을 처리하는 담당자 또는 리소스 그룹입니다. | ||
| 설명 이 속성은 특정 작업을 수행한 담당자나 팀을 식별합니다. 특히 공유 서비스 환경에서는 '사용자 이름'보다 구체적인 역할이나 팀을 나타낼 수 있습니다. '환불 승인 효율성' 대시보드에서 담당자나 팀별 성과를 분석하는 데 유용합니다. 업무량 분포를 파악하고, 교육이 필요한 영역을 찾으며, 모범 사례를 공유할 우수 담당자나 팀을 확인할 수 있습니다. 중요한 이유 담당자 또는 팀 단위로 성과를 분석하여 업무량을 관리하고, 교육 기회를 파악하며, 효율성을 높일 수 있습니다. 확보 방법 담당자가 지정된 경우 SAP Business Partner 기능에서 이 정보를 확인할 수 있습니다. 또는 HR 조직 구조에 등록된 사용자의 부서나 역할을 바탕으로 도출할 수 있습니다. 예시 1차 지원창고 검사팀재무 부서 - 매입채무 | |||
| 판매 조직 SalesOrganization | 최초 판매와 반품을 담당하는 조직 단위입니다. | ||
| 설명 판매 조직은 제품과 서비스의 판매 및 유통을 담당하는 단위를 나타내는 SAP의 주요 조직 구조입니다. 반품 거래에도 지정됩니다. 이 속성을 사용하면 사업부, 지역, 부문별로 반품 프로세스를 필터링하고 비교할 수 있습니다. 특정 판매 조직의 반품률이 높거나 반품 처리 효율이 낮은지 파악해 조직별 성과를 분석할 수 있습니다. 중요한 이유 사업부, 지역, 판매 채널별로 반품 프로세스의 성과와 반품률을 비교할 수 있습니다. 확보 방법 반품 주문 헤더 테이블(VBAK)의 판매 조직 필드(VKORG)에서 확인할 수 있습니다. 예시 10002100US01 | |||
| 환불 SLA 목표일 RefundSlaTargetDate | 반품 건의 환불 처리를 완료해야 하는 목표일입니다. | ||
| 설명 이 속성은 환불 처리에 적용되는 서비스 수준 계약(SLA)의 기한을 정의합니다. 보통 반품 승인일이나 상품 입고일로부터 일정 기간을 더하는 등 업무 규칙에 따라 날짜를 계산합니다. 이 필드는 '환불 SLA 준수 모니터링' 대시보드와 관련 KPI의 기준이 됩니다. SLA를 지키지 못할 위험이 있는 케이스를 미리 추적하고 지연 원인을 분석하여 고객 만족도를 높일 수 있습니다. 중요한 이유 SLA 준수 여부를 측정하는 기준으로, 성과를 모니터링하고 장기 미처리 케이스의 우선순위를 정하며 고객 만족도를 높이는 데 도움이 됩니다. 확보 방법 대부분의 경우 다른 데이터에서 산출하는 필드입니다. 반품 요청 생성일과 같은 기준일에 업무 규칙으로 정한 기간을 더해 계산하며, 고객 유형이나 반품 사유에 따라 기간이 달라질 수 있습니다. 예시 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| 환불 SLA 준수 여부 RefundSlaAdherence | 환불이 서비스 수준 계약(SLA)의 목표 기한 내에 처리되었는지 나타내는 플래그입니다. | ||
| 설명 이 계산된 속성은 '환불 처리' 활동이 '환불 SLA 목표일' 당일 또는 그 전에 발생했는지 확인합니다. 각 케이스의 SLA 준수 여부를 참 또는 거짓으로 표시합니다. '환불 SLA 준수 모니터링' 대시보드와 '환불 SLA 준수율' KPI의 주요 지표입니다. 고객과의 약속에 따른 성과를 측정하고 기대에 미치지 못한 케이스를 찾아 지연 원인을 분석할 수 있습니다. 중요한 이유 고객에게 약속한 처리 기준에 대한 성과를 직접 측정하므로 서비스 품질과 고객 만족도를 보여주는 중요한 지표입니다. 확보 방법 각 케이스의 '환불 처리' 활동 EventTime과 'RefundSlaTargetDate'를 비교해 계산합니다. 예시 truefalse | |||
반품 및 환불 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 대변 메모 생성 | 반품 상품에 대해 고객 계정에 대변을 반영하는 공식 청구 문서를 생성하는 활동입니다. 대변 메모 요청에서 대변 메모가 생성될 때 명시적 이벤트로 기록됩니다. | ||
| 중요한 이유 대변 메모 생성은 중요한 재무 이정표입니다. 환불 금액을 확정하고 지급 절차를 시작할 수 있도록 합니다. 확보 방법 테이블 VBRK에서 문서 범주가 대변 메모를 나타내는 청구 문서가 생성될 때 기록됩니다. VBFA 테이블을 통해 대변 메모 요청과 연결됩니다. 기록 신규 대변 메모 청구 문서를 저장하면 이벤트가 기록됩니다(예: 트랜잭션 VF01 사용). 이벤트 유형 explicit | |||
| 대변 메모 요청 생성 | 검수가 성공적으로 끝난 뒤 고객에게 대변 처리를 요청하는 문서를 생성하는 활동입니다. 원래 반품 주문을 참조하는 신규 판매 문서인 대변 메모 요청으로 기록됩니다. | ||
| 중요한 이유 반품 프로세스에서 재무 정산 단계가 시작되는 시점입니다. 검수부터 이 단계까지 걸리는 시간을 분석하면 물류에서 재무로 업무를 인계하는 과정의 효율성을 확인할 수 있습니다. 확보 방법 테이블 VBAK에서 문서 범주가 대변 메모 요청인 판매 문서가 생성될 때 기록됩니다. 반품과의 연결 정보는 문서 흐름 테이블 VBFA에 유지됩니다. 기록 신규 대변 메모 요청 문서를 저장하면 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 반품 건 종료 | 반품 프로세스가 완료되어 해당 건에 추가 조치가 필요하지 않음을 나타내는 마지막 활동입니다. 일반적으로 시스템에서 반품 주문 문서의 상태가 최종 또는 종료 상태에 도달하면 추정합니다. | ||
| 중요한 이유 이 이벤트는 프로세스 처리 주기의 종료 시점을 정의하므로 전체 처리 시간을 계산할 수 있습니다. 해당 건이 완전히 해결되었음을 확인합니다. 확보 방법 테이블 VBAK의 반품 주문 전체 상태나 VBAP의 품목 상태가 '완료' 또는 '종료' 상태에 도달하면 추정합니다. 해당 상태는 시스템의 상태 관리 설정에 따라 결정됩니다. 기록 반품 주문 문서 상태가 '완료'로 변경되면 추정합니다. 이벤트 유형 inferred | |||
| 반품 요청 시작 | 반품 프로세스의 시작점으로, 시스템에서 반품 주문을 정식으로 생성합니다. SAP S/4HANA에서 반품 주문 유형의 신규 판매 문서를 저장하면 이 이벤트가 명시적으로 기록됩니다. | ||
| 중요한 이유 이 활동은 반품 건의 처리 주기가 공식적으로 시작되는 시점을 나타냅니다. 이 이벤트부터 종료까지 걸리는 시간을 분석하면 전체 반품 처리 시간과 고객 경험을 측정할 수 있습니다. 확보 방법 테이블 VBAK에서 판매 문서가 생성될 때 기록되는 명시적 이벤트입니다. 문서 범주(VBAK-VBTYP)가 반품 주문을 나타내며, 생성 시각은 VBAK-ERDAT에 기록됩니다. 기록 신규 반품 판매 주문을 저장하면 이벤트가 기록됩니다(예: 트랜잭션 VA01 사용). 이벤트 유형 explicit | |||
| 상품 검수 완료 | 반품 상품의 품질과 상태 평가가 완료된 시점을 나타냅니다. Advanced Returns Management에서는 검수 결과와 환불 또는 폐기와 같은 후속 조치를 기록하는 명시적 단계인 경우가 많습니다. | ||
| 중요한 이유 검수에 걸리는 시간과 결과는 환불 처리 시간과 재고 관리에 직접 영향을 줍니다. 검수 효율과 재작업을 분석하는 데 중요한 활동입니다. 확보 방법 SAP Advanced Returns Management(ARM)에서는 검수 트랜잭션에서 명시적 이벤트로 기록될 수 있습니다. 검수 결과를 나타내는 반품 주문 품목의 상태 변경을 통해 추정할 수도 있습니다. 기록 ARM의 물류 후속 활동과 관련된 트랜잭션 로그나 상태 변경에서 확인합니다. 이벤트 유형 explicit | |||
| 창고에 상품 입고 | 반품 상품이 창고나 처리 센터에 실제로 도착한 시점을 나타냅니다. 반품 납품에 대해 입고 전기(Post Goods Receipt, PGR)를 실행해 자재 문서를 생성하면 명시적으로 기록됩니다. | ||
| 중요한 이유 검수와 후속 처리가 시작되는 중요한 이정표입니다. 이 시점 전의 지연은 고객 측 요인에 따른 것이고, 이후의 지연은 내부 요인에 따른 것입니다. 확보 방법 반품에 해당하는 입고 이동 유형의 자재 문서 테이블 MSEG 및 MKPF에서 확인합니다. 전기일(MKPF-BUDAT)이 이벤트 시각을 나타냅니다. 기록 반품 납품에 대한 입고 전기가 이루어질 때 기록되는 이벤트입니다. 이벤트 유형 explicit | |||
| 환불 처리 | 환불 프로세스의 마지막 단계로, 재무상 대변 잔액을 반제해 고객에게 지급이 완료되었음을 나타냅니다. 재무 모듈에서 고객 계정의 미결 대변을 정산하는 반제 문서가 생성되면 이 활동을 추정할 수 있습니다. | ||
| 중요한 이유 고객에게 실제로 환불이 이루어지는 시점입니다. 반품 요청 시작부터 이 단계까지 걸리는 시간은 고객 만족도에 큰 영향을 미치며 SLA 준수 여부를 측정하는 데 중요합니다. 확보 방법 재무회계 개별 항목 테이블 BSEG의 반제 문서 정보에서 추정합니다. 대변 메모와 연결된 고객 개별 항목의 반제일(BSEG-AUGDT)이 환불 처리 시점을 나타냅니다. 기록 대변 메모와 연결된 회계 문서의 반제일 필드가 입력된 경우로 추정합니다. 이벤트 유형 inferred | |||
| 교환 주문 생성 | 환불 대신 고객에게 교체 상품을 보내기 위해 신규 판매 주문을 생성하는 대체 처리 활동입니다. 원래 반품을 참조하는 신규 판매 주문이 생성되면 기록됩니다. | ||
| 중요한 이유 환불 반품과 교환 반품을 구분하는 데 도움이 됩니다. 두 유형은 프로세스 경로와 고객에게 제공되는 결과가 다르므로 변형 분석에 중요합니다. 확보 방법 테이블 VBAK에서 신규 판매 문서가 생성되고 문서 흐름 테이블 VBFA를 통해 반품 주문과 연결될 때 기록됩니다. 기록 교체 상품용으로 지정된 신규 판매 주문 문서를 저장하면 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 반품 거부 | 반품 상품이 반품 정책의 기준을 충족하지 못해 환불 또는 대변 처리가 거부된 상태입니다. 일반적으로 검수 후 반품 주문 품목에 특정 상태나 사유 코드가 적용되면 기록됩니다. | ||
| 중요한 이유 거부 사례를 추적하면 반품 정책 준수 여부를 분석하고 거부의 일반적인 사유를 파악할 수 있습니다. 프로세스에서 예외 경로에 해당하는 중요한 활동입니다. 확보 방법 반품 주문 품목에 거부 사유(VBAP-ABGRU)가 설정되거나 Advanced Returns Management의 검수 과정에서 특정 상태가 지정된 경우로 추정합니다. 기록 반품 문서 품목에 거부 사유가 설정되거나 '거부됨' 상태가 지정된 경우로 추정합니다. 이벤트 유형 inferred | |||
| 반품 납품 생성 | 반품 상품의 실제 입고를 관리하는 입고 납품 문서를 생성하는 활동입니다. 반품 주문을 참조하는 납품 문서가 생성되면 시스템에 명시적으로 기록됩니다. | ||
| 중요한 이유 이 단계는 물류 처리의 주요 이정표입니다. 반품 승인부터 납품 문서 생성까지 걸리는 시간을 보면 반품 정보를 창고나 입고 부서에 전달하는 과정의 효율성을 확인할 수 있습니다. 확보 방법 테이블 LIKP에서 납품 헤더가 생성될 때 기록되며, 문서 흐름 테이블 VBFA를 통해 앞선 반품 주문과 연결됩니다. 기록 신규 반품 납품 문서를 저장하면 이벤트가 기록됩니다(예: 트랜잭션 VL01N 사용). 이벤트 유형 explicit | |||
| 반품 주문 승인 | 반품 주문이 다음 단계로 진행할 수 있도록 정식으로 승인하거나 릴리스하는 활동입니다. 일반적으로 판매 문서 헤더나 품목의 상태 변경을 통해 확인하며, 차단 상태가 해제되었음을 나타냅니다. | ||
| 중요한 이유 승인 단계는 지연의 주요 원인이 될 수 있습니다. 이 활동을 추적하면 반품 프로세스 초기 승인 단계의 병목을 파악할 수 있습니다. 확보 방법 상태 관리 테이블이나 VBAK 또는 VBAP 테이블의 상태 필드에서 확인할 수 있습니다. 릴리스 상태가 변경되거나 납품 차단(VBAP-LIFSP)이 해제되면 승인된 것으로 볼 수 있습니다. 기록 반품 주문 헤더 또는 품목의 상태 필드가 릴리스 또는 승인을 나타내도록 변경된 경우로 추정합니다. 이벤트 유형 inferred | |||
| 회계 문서 생성 | 대변 메모가 재무회계 모듈에 성공적으로 전기되면 이 이벤트가 발생합니다. 총계정원장에 관련 항목이 생성되어 회계상 대변 처리가 완료됩니다. | ||
| 중요한 이유 이 활동은 대변 처리가 재무 시스템에 반영되었음을 확인합니다. 대변 메모 생성부터 회계 전기까지 걸리는 시간을 보면 청구와 재무 간 연계 과정의 문제를 파악할 수 있습니다. 확보 방법 회계 테이블 BKPF에서 문서 헤더가 생성될 때 기록되며, VBRK의 대변 메모(VBRK-BELNR)와 연결됩니다. 기록 청구 문서가 재무회계에 성공적으로 전기되면 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
데이터 추출 가이드
단계
- 사전 요구사항 확인: 데이터를 추출하는 사용자 계정에 필요한 Core Data Services(CDS) 뷰에 액세스할 수 있는 SAP S/4HANA 권한이 있는지 확인합니다. 주요 뷰는 I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry, I_ClearedItem입니다.
- 쿼리 도구 액세스: SAP S/4HANA 데이터베이스에 연결된 SQL 클라이언트 또는 데이터 통합 도구에 로그인합니다. SAP Analytics Cloud와 같은 SAP 도구나 타사 ETL 플랫폼을 사용할 수 있습니다.
- 쿼리 매개변수 설정: 실행 전에 제공된 SQL 쿼리를 수정해야 합니다. 자리표시자 값을 찾아 환경에 맞는 값으로 바꿉니다. 여기에는
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]및 기타 문서 유형이나 회사 코드 필터가 포함됩니다. - 추출 쿼리 실행: 전체 SQL 쿼리를 복사해 도구에서 실행합니다. 여러 SELECT 문의 결과를 결합해 지정된 모든 활동을 하나의 데이터 세트로 수집하도록 설계된 쿼리입니다.
- 쿼리 로직 이해:
UNION ALL구조의 각SELECT블록은 특정 활동 하나를 추출합니다. 여러 CDS 뷰를 조인해 필요한 속성을 가져오고,ActivityName에는 고정 문자열을 지정하며,EventTime에는 해당 타임스탬프를 선택합니다. - 원시 데이터 검토: 쿼리 실행이 끝나면 결과를 간단히 확인합니다. 행 수가 적절한지,
ReturnCaseId,ActivityName,EventTime과 같은 주요 열에 예상한 값이 들어 있는지 살펴봅니다. - 데이터 변환: 쿼리는 평면형 이벤트 로그를 생성하도록 구성되어 있어 일반적으로 구조를 크게 변환할 필요가 없습니다. 다만 대상 시스템의 요구사항에 따라 타임스탬프 형식이나 데이터 유형을 조정해야 할 수 있습니다.
- 이벤트 로그 내보내기: 쿼리 결과를 CSV 파일로 내보냅니다. 특히 사용자 이름이나 제품 설명에 문자가 깨지지 않도록 UTF-8 인코딩을 사용합니다.
- process mining 도구에 업로드: 생성된 CSV 파일을 ProcessMind와 같은 process mining 플랫폼에 업로드할 수 있습니다. 파일의 열을 도구의 해당 필드에 매핑합니다. 예:
ReturnCaseId는 케이스 ID,ActivityName은 활동,EventTime은 타임스탬프에 매핑합니다.
구성
- 사전 요건: 실행 사용자에게 판매 문서(VBAK), 납품(LIKP), 청구(VBRK), 회계(BSEG, BKPF) 관련 객체의 조회 권한이 필요합니다. 기반 CDS View에 액세스할 수 있어야 합니다.
- 데이터 범위 필터: 반품 프로세스만 추출하려면 특정 문서 유형으로 쿼리를 필터링해야 합니다. 반품 주문 유형(예: 'RE'), 대변 메모 요청 유형(예: 'G2'), 교환 주문 유형(예: 'SO')의 자리표시자를 설정합니다. 데이터 범위를 제한하려면
CompanyCode또는SalesOrganization으로 필터링하는 것도 좋습니다. - 기간 필터링: 성능과 데이터 양을 관리하려면 항상 기간 필터를 적용합니다. 최근 3~6개월의 데이터부터 시작합니다. 쿼리는 최초 반품 주문의 생성일(
I_SalesDocument.CreationDate)을 기본 필터 조건으로 사용합니다. - 성능 고려사항: 여러 대규모 CDS View를 조인하는 종합 쿼리이므로 소스 S/4HANA 시스템의 리소스를 많이 사용할 수 있습니다. 영향을 줄이려면 업무량이 적은 시간대에 추출을 예약합니다. 데이터가 매우 많다면 증분 로딩 방식을 고려합니다.
샘플 쿼리 sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' 단계
- 관련 판매, 납품, 청구, 자재 문서, 검사, 상태 및 회계 데이터가 포함된 SAP HANA 스키마에 직접 읽기 권한이 있는지 확인합니다. 스키마, 뷰, 필드 이름은 SAP S/4HANA 배포 환경에 따라 다르므로 대괄호로 표시된 각 자리표시자를 시스템에 설정된 객체와 필드로 바꿉니다.
- [Start date], [End date], [Company Code filter], [Return document type filter]를 사용해 추출 범위를 정합니다. 초기 추출은 3~6개월의 기간으로 시작하고, 성능과 데이터 완전성을 검증한 뒤에만 기간을 늘립니다.
- [Your sales document header table]과 [Your sales document item table]에서 반품 주문 모집단을 식별합니다. [Your return order document type configuration]에 설정된 반품 주문 문서 유형만 포함합니다. 후속 문서와 연결할 수 있도록 반품 주문 번호와 품목 번호를 유지합니다.
- [Your document flow table or view]를 사용해 반품 주문에서 반품 입고 납품, 대변 메모 요청, 교환 주문, 대변 메모로 이어지는 문서 흐름을 확인합니다. 문서 흐름이 VBAK 또는 VBAP에 저장되어 있다고 가정하지 마세요. 시스템의 문서 흐름 모델에 맞춰 관계 필드를 설정합니다.
- 관련 문서 헤더 및 품목 레코드에서 생성 이벤트를 명시적으로 추출합니다. 승인, 거부, 검사, 종료, 입고, 회계 처리 및 반제 이벤트는 설정된 상태, 검사, 자재 문서, 회계 및 반제 데이터 소스에서 추출합니다. ProcessMind는 이벤트를 추론하지 않으므로 활동마다 별도의 이벤트 행을 생성해야 합니다.
- 타임스탬프를 일관된 데이터베이스 타임스탬프 유형과 시간대로 정규화합니다. 활동별로 설정된 이벤트 타임스탬프 우선순위를 적용합니다. 날짜와 시간만 있는 경우 [Your system time zone]에 설정된 시스템 시간대를 기준으로 결합합니다.
- 모든 이벤트에 ReturnCaseId를 입력합니다. 최초 반품 주문 번호를 사용하거나, Advanced Returns Management에서 별도의 케이스 키를 사용하는 경우 설정된 반품 케이스 식별자를 사용합니다. 반품 케이스에 연결할 수 없는 이벤트는 제외하거나 예외 결과에 넣어 수정합니다.
- 필수 열인 ReturnCaseId, ActivityName, EventTime, SourceSystemId, LastDataUpdateTimestamp를 입력합니다. 사용 가능한 경우 EventEndTime, UserName, ReturnReason, RefundAmount, ProductId, CustomerId 등 권장 열도 입력합니다. 활동 발생 건마다 한 행을 유지하고 활동을 단일 케이스 행으로 집계하지 않습니다.
- validationSteps의 검사 항목을 사용해 결과를 검증합니다. 12개 활동 이름이 모두 있는지, 각 케이스의 타임스탬프 순서가 타당한지, 문서 참조가 소스 테이블과 일치하는지 확인합니다.
- 결과를 UTF-8 CSV 또는 ProcessMind에서 지원하는 다른 표 형식으로 내보냅니다. 열 이름을 그대로 유지하고 헤더 행은 하나만 사용합니다. 타임스탬프는 모호하지 않은 ISO 형식으로 저장합니다. ReturnCaseId를 케이스 식별자로, ActivityName을 활동 열로 설정해 이벤트 로그를 업로드합니다.
구성
- 기간: 3~6개월부터 시작합니다. [Start date]와 [End date] 매개변수를 사용하고, 선택한 기간 전에 시작해 기간 내에 완료된 케이스도 포함할 수 있도록 충분한 이력을 확보합니다.
- 반품 모집단: [Your return order document type configuration]에 설정된 반품 주문 문서 유형으로 필터링합니다. 대상 시스템에서 확인하지 않은 문서 유형을 코드에 고정하지 마세요.
- 조직 필터: 필요한 경우에만 [Company Code filter], 판매 조직, 유통 경로, 제품 부문, 플랜트 또는 고객 필터를 적용합니다. 필터로 인해 회사 간 또는 계열사 간 후속 문서가 제외되지 않는지 확인합니다.
- 소스 객체: [Your table name] 및 [Your view name] 자리표시자를 승인된 SAP S/4HANA 테이블 또는 CDS View로 바꿉니다. 배포 환경에서 VBAK, VBAP, VBRK, VBRP를 사용할 수 있지만, 실행 전에 사용 가능 여부와 확장 사항을 확인해야 합니다.
- 타임스탬프 처리: 활동별 소스 타임스탬프 필드와 시간대를 설정합니다. EventTime과 EventEndTime은 일관된 방식으로 저장하며, UTC 또는 합의된 ProcessMind 시간대를 사용하는 것이 좋습니다.
- 상태 해석: 시스템에서 승인, 거부, 검사 완료, 케이스 종료를 나타내는 정확한 상태 값, 사유 코드, 검사 결과 및 종료 표시를 설정합니다.
- 소스 시스템 식별자: [Source system identifier]를 추출 플랫폼에서 사용하는 SAP 시스템 식별자와 같이 변하지 않는 값으로 바꿉니다.
- 새로 고침 타임스탬프: [Extraction timestamp]를 쿼리 실행이 시작된 시각 또는 소스 스냅샷 생성 시각으로 바꿉니다. 행별 새로 고침 타임스탬프가 필요한 경우가 아니라면 한 번의 추출 실행에서 모든 행에 같은 값을 사용합니다.
- 성능: 대규모 문서 흐름, 회계, 자재 문서 및 상태 데이터 소스를 조인하기 전에 초기 반품 모집단을 제한합니다. 인덱스가 있거나 파티션을 줄일 수 있는 필드를 사용하고, 전체 테이블을 무제한으로 검색하지 않습니다. 중간 결과를 구체화하려면 데이터베이스 관리자의 승인을 받습니다.
- 증분 추출: 정기적으로 실행할 때는 [Last successful extraction timestamp]와 관리되는 중복 기간을 사용해 늦게 반영된 업데이트를 가져옵니다. ReturnCaseId, ActivityName, 소스 문서 키, EventTime을 기준으로 중복을 제거합니다.
- 권한 및 사전 요건: 설정된 모든 소스 객체와 필드에 대한 읽기 권한을 확보하고, 데이터베이스 직접 액세스 승인을 받습니다. 해당되는 경우 필요한 SAP 구성 요소와 Advanced Returns Management 기능이 활성화되어 있는지도 확인합니다.
- 데이터 보호: 고객 및 재무 필드는 필요한 최소한으로 제한하고, 조직의 개인정보 보호 정책을 따르며, 내보낸 파일을 안전하게 관리합니다.
샘플 쿼리 sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; 시작할 준비가 되셨나요?
이 템플릿을 활용하면 반품 및 환불 처리 데이터를 추출하고 분석하는 데 필요한 기본 지식을 갖출 수 있습니다. 지금 프로세스 개선을 시작해 보세요.
지금 SAP S/4HANA의 반품 및 환불 처리 프로세스를 개선하세요
비효율을 파악하고 처리 시간을 30% 단축해 만족도를 높이세요.
신용카드 없이 이용할 수 있습니다. 지금 개선을 시작하세요.