반품 및 환불 처리 데이터 템플릿
반품 및 환불 처리 데이터 템플릿
- 수집 권장 데이터 필드
- 추적할 주요 프로세스 단계
- 데이터 추출 안내
반품 및 환불 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 반품 사례 ID ReturnCaseId | 고객의 반품 및 환불 사례를 식별하고 관련 활동을 연결하는 고유 ID입니다. | ||
| 설명 반품 사례 ID는 각 반품 프로세스 인스턴스를 식별하는 기본 ID입니다. 반품 주문 생성부터 최종 종료까지 특정 고객의 반품 또는 환불 요청과 관련된 모든 활동을 연결합니다. 프로세스 분석에서 이 ID는 각 반품의 전체 흐름을 재구성하는 데 필수적입니다. 전체 처리 과정을 추적하고 총 처리 시간을 측정하며 사례별 차이를 분석할 수 있습니다. 모든 이벤트와 데이터, 지표는 이 ID를 기준으로 집계하고 연결합니다. 중요한 이유 모든 프로세스 단계를 연결하는 필수 사례 ID입니다. 이를 사용해 각 반품의 시작부터 종료까지 추적하고 분석할 수 있습니다. 확보 방법 일반적으로 반품 자재 승인(RMA) 번호이거나 'Sales and marketing' 모듈에서 'Returned Order' 유형으로 지정된 판매 주문 번호입니다. 'SalesType'이 'Returned Order'인 'SalesTable' 등의 테이블에서 확인할 수 있습니다. 예시 RMA-001234RMA-001235RMA-001236 | |||
| 이벤트 시각 EventTime | 특정 활동이나 이벤트가 발생한 시각을 나타내는 타임스탬프입니다. | ||
| 설명 이벤트 시각, 즉 타임스탬프는 활동이 발생한 날짜와 시간을 정확히 기록합니다. 이벤트 로그의 각 활동에는 해당 시각이 기록되어 이벤트의 시간 순서를 확인할 수 있습니다. 이 속성은 시간 기반 process mining 분석에 필수적입니다. 활동 간 처리 시간을 계산하고 대기 시간과 병목을 찾으며 사례의 전체 소요 시간을 측정하고 서비스 수준 계약(SLA) 준수 여부를 확인하는 데 사용됩니다. 타임스탬프의 정확도는 성과 분석의 신뢰도에 직접 영향을 줍니다. 중요한 이유 처리 시간과 대기 시간 등 기간 기반 지표를 계산하는 데 필요한 정보로, 성과 분석의 토대가 됩니다. 확보 방법 'SalesTable.createdDateTime'과 같은 주문 생성 필드나 'WMSJournalTrans.createdDateTime'과 같은 창고 분개장 필드의 생성일 또는 수정일에 해당합니다. 예시 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| 활동명 ActivityName | 반품 및 환불 프로세스에서 발생한 구체적인 업무 이벤트나 작업의 이름입니다. | ||
| 설명 이 속성은 '반품 주문 생성', '상품 입고', '대변전표 전기'와 같이 반품 및 환불 과정의 특정 단계나 이벤트를 나타냅니다. 각 활동은 시스템에 기록되는 개별 프로세스 시점을 의미합니다. 활동의 순서와 빈도를 분석하는 것이 process mining의 기본입니다. 이를 통해 프로세스 맵을 시각화하고 단계 사이의 병목을 찾으며 자주 발생하거나 드물게 발생하는 프로세스 경로를 발견할 수 있습니다. 활동 집합에 따라 분석 대상 프로세스의 범위가 정해집니다. 중요한 이유 프로세스 단계를 정의해 흐름을 시각화하고 병목, 재작업, 편차를 찾아낼 수 있습니다. 확보 방법 시스템 이벤트에서 도출하는 개념적 속성입니다. 'SalesTable' 및 'WMSJournalTable'과 같은 테이블의 상태 변경이나 특정 이벤트 로그를 사용자가 이해하기 쉬운 이름으로 매핑해 생성할 수 있습니다. 예시 반품 주문 생성상품 입고처분 코드 적용대변전표 전기 | |||
| 담당 사용자 ResponsibleUser | 특정 활동을 수행했거나 해당 활동을 담당하는 사용자 또는 직원입니다. | ||
| 설명 이 속성은 프로세스 단계를 수행한 사용자를 식별합니다. 상품을 입고한 창고 직원, 품질 검사 담당자, 대변전표를 전기한 재무 담당자 등이 해당할 수 있습니다. 사용자별로 프로세스를 분석하면 업무량 분포를 파악하고 성과가 높은 직원을 찾으며 교육이 필요한 부분을 확인할 수 있습니다. 특정 직원이나 팀이 처리한 사례를 조사하고 업무 분장이 적절한지 확인하는 데도 활용할 수 있습니다. 중요한 이유 업무량 분포와 개인 또는 팀별 성과를 분석하고 교육이나 리소스 배분 기회를 찾을 수 있습니다. 확보 방법 'SalesTable.createdBy'와 같은 거래 레코드의 'created by' 또는 'modified by' 필드나 분개장 테이블에 연결된 사용자 ID에서 확인할 수 있습니다. 예시 앨리스.W밥.J크리스.P | |||
| 반품 사유 코드 ReturnReasonCode | 고객이 상품을 반품하는 이유입니다. | ||
| 설명 반품 사유 코드는 고객이 밝힌 반품 사유를 기록합니다. 예를 들어 '상품 결함', '사이즈 오류', '설명과 다름', '더 이상 필요하지 않음' 등이 있습니다. 일반적으로 반품 접수 시 수집합니다. 반품 사유를 분석하면 근본 원인을 파악하는 데 도움이 됩니다. 제품 품질 문제, 상품 설명의 오류, 물류 과정의 문제를 찾아낼 수 있습니다. 분석 결과를 제품 설계, 마케팅, 공급망 운영 개선에 활용하면 향후 반품을 줄일 수 있습니다. 중요한 이유 반품이 발생하는 이유를 파악해 근본 원인을 분석하고, 반품률을 낮추며 고객 만족도를 높이는 데 도움이 됩니다. 확보 방법 일반적으로 반품 주문의 품목 행에 저장됩니다. 반품 주문의 'SalesLine' 테이블에서 사유 코드 필드를 확인하세요. 예시 결함잘못된 상품더 이상 필요하지 않음운송 중 파손 | |||
| 반품 접수 채널 ReturnChannel | 고객이 반품을 접수한 방법 또는 채널입니다. | ||
| 설명 이 속성은 고객이 반품을 접수한 채널을 나타냅니다. 예를 들어 '온라인 포털', '매장 방문', '고객 서비스 전화', '우편' 등이 있습니다. 반품 채널별로 프로세스를 분석하면 각 채널의 성과와 효율성을 평가할 수 있습니다. 채널별 처리 시간, 비용, 고객 만족도를 비교해 우수 사례와 투자 또는 개선이 필요한 영역을 찾을 수 있습니다. 이는 '반품 채널 활용 성과' 대시보드의 주요 분석 항목입니다. 중요한 이유 반품 채널별 성과를 비교해 효율성과 비용 효과가 높은 채널을 파악하고 최적화할 수 있습니다. 확보 방법 반품 주문 헤더('SalesTable')에 저장되거나 주문을 생성한 사용자를 기준으로 확인할 수 있습니다. 사용자 지정 로직이나 전용 필드가 필요할 수 있습니다. 예시 웹 포털매장 내 키오스크고객 지원 | |||
| 제품 ID ProductId | 반품 대상 제품을 식별하는 고유 ID입니다. | ||
| 설명 제품 ID는 일반적으로 SKU(재고 관리 코드)이며, 고객이 반품하는 특정 상품을 식별합니다. 반품 주문의 각 품목 행에는 제품 ID가 연결됩니다. 제품별 반품을 분석하면 반품률이 높은 상품을 찾을 수 있습니다. 이는 품질 관리 문제, 부정확한 상품 설명 또는 제조 결함을 나타낼 수 있습니다. 분석 결과를 바탕으로 제품 관련 조사와 개선의 우선순위를 정할 수 있습니다. 중요한 이유 제품별로 반품을 분석해 품질 문제가 있거나 반품량이 많은 상품을 파악할 수 있습니다. 확보 방법 반품 주문의 'SalesLine' 테이블에서 'ItemId' 필드에 해당합니다. 예시 SKU-A-123SKU-B-456SKU-C-789 | |||
| 처분 코드 DispositionCode | 상품 검사 결과와 후속 조치를 나타내는 코드입니다. | ||
| 설명 반품 상품의 품질 검사 과정에서 처분 코드를 지정합니다. 이 코드는 'Credit', 'Replace', 'Scrap', 'Return to Customer'와 같이 이후 처리 단계를 결정합니다. 이 속성은 반품 프로세스의 주요 의사결정 기준입니다. 처분 코드별로 분석하면 반품 처리 결과를 파악하고 상품 폐기의 재무 영향을 추적하며 대체 상품 발송과 환불 등 처리 경로별 효율을 평가할 수 있습니다. 중요한 이유 이 코드는 검수 후 반품 건이 진행될 경로를 결정하므로, 프로세스 변형과 그에 따른 비즈니스 결과를 분석할 때 중요합니다. 확보 방법 품질 관리 모듈의 주요 필드입니다. 품질 주문 또는 검사 주문 처리와 관련이 있습니다. 예시 CRDTREPL-D폐기RTV | |||
| SLA 상태 SlaStatus | 서비스 수준 계약의 목표 기한 내에 건이 처리되었는지 나타냅니다. | ||
| 설명 이 계산된 속성은 일반적으로 '기한 내' 또는 '지연'으로 SLA 준수 상태를 간단히 보여 줍니다. 최종 활동(예: '반품 주문 종료')의 타임스탬프를 'RefundSlaTargetDate'와 비교해 결정합니다. 이 속성을 사용하면 '환불 처리 SLA 성과'와 같은 대시보드에서 성과를 쉽게 보고할 수 있습니다. 사용자가 날짜를 직접 비교하지 않아도 상태를 바로 확인할 수 있습니다. 이를 통해 빠르게 필터링하고 집계해 전체 '해결 SLA 준수율'을 계산할 수 있습니다. 중요한 이유 SLA 준수 여부를 한눈에 확인할 수 있어 지연 건을 쉽게 필터링하고 지연 원인을 분석할 수 있습니다. 확보 방법 파생 속성입니다. 최종 해결 활동의 타임스탬프를 'RefundSlaTargetDate' 속성과 비교해 계산합니다. 예시 기한 내지연 | |||
| 고객 ID CustomerId | 반품을 접수한 고객을 식별하는 고유 ID입니다. | ||
| 설명 고객 ID는 반품과 연결된 고객 계정을 식별하는 고유 ID입니다. 이를 통해 반품 거래를 CRM 또는 고객 데이터베이스의 특정 고객과 연결할 수 있습니다. 고객별 반품을 분석하면 반품이 유난히 잦은 고객을 찾아낼 수 있습니다. 이는 부정 행위나 지속적인 불만족을 나타낼 수 있습니다. 또한 고객을 세분화해 우수 고객에게 프리미엄 반품 서비스를 제공하는 데 활용할 수 있습니다. 중요한 이유 반품 프로세스를 특정 고객과 연결해 고객별 분석을 수행하고 반품 패턴이나 잠재적 부정 행위를 파악할 수 있습니다. 확보 방법 반품 주문의 'SalesTable'에 있는 'CustAccount' 필드입니다. 예시 CUST-00045CUST-00192CUST-00315 | |||
| 대변전표 ID CreditNoteId | 환불을 위해 생성된 대변전표 문서의 고유 ID입니다. | ||
| 설명 환불을 처리하면 대변전표 또는 대변 메모라는 재무 문서가 생성됩니다. 이 속성에는 해당 문서의 고유 ID가 저장됩니다. 이 ID를 통해 운영상의 반품 프로세스와 회계 시스템의 재무 기록을 직접 연결할 수 있습니다. 감사나 재무 차이의 상세 분석에 유용하며, 반품 건을 정산한 특정 재무 거래까지 추적할 수 있습니다. 중요한 이유 운영상의 반품 프로세스를 해당 재무 거래와 연결하므로 감사와 재무 조정에 중요합니다. 확보 방법 대변전표 번호는 일반적으로 'CustInvoiceJour' 테이블의 'InvoiceId' 필드에서 확인할 수 있습니다. 거래 유형이 'Credit note'인 항목을 반품 주문과 연결하면 됩니다. 예시 CN-10056CN-10057CN-10058 | |||
| 마지막 데이터 업데이트 LastDataUpdate | 프로세스 데이터가 마지막으로 갱신된 시각입니다. | ||
| 설명 이 속성은 원천 시스템에서 데이터를 마지막으로 추출해 process mining 도구에 반영한 날짜와 시각을 기록합니다. 분석 대상 데이터가 얼마나 최신인지 확인하는 기준이 됩니다. 마지막 데이터 업데이트 시각을 알면 분석 결과가 얼마나 최신인지 판단할 수 있습니다. 사용자는 대시보드와 KPI를 해석할 때 실시간 데이터인지 특정 시점의 스냅샷인지 확인할 수 있습니다. 운영 모니터링에 중요한 정보입니다. 중요한 이유 데이터의 최신성을 나타내므로 분석가는 프로세스 분석 결과가 어느 시점의 데이터에 기반하는지 확인할 수 있습니다. 확보 방법 데이터 수집 파이프라인에서 생성하고 저장하는 메타데이터 속성입니다. 일반적으로 ETL 작업이 완료된 시각을 나타냅니다. 예시 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| 반품 유형 ReturnType | 환불 또는 교체와 같이 예상되는 처리 결과에 따라 반품을 분류합니다. | ||
| 설명 이 속성은 고객이 원하는 처리 방식이나 기업이 제공하는 해결 방법에 따라 반품 건을 분류합니다. 일반적인 유형으로는 금액을 돌려주는 '환불', 상품을 '교체'하는 방식, '수리'가 있습니다. 이 분류를 활용하면 처리 경로별로 프로세스를 분석할 수 있습니다. 환불 처리와 교체품 발송은 프로세스 단계가 크게 다릅니다. 반품 유형별로 구분하면 각 처리 경로의 소요 시간과 병목을 더 정확하게 분석할 수 있습니다. 중요한 이유 환불과 교체는 단계와 처리 시간이 다르므로, 원하는 결과에 따라 분석 대상을 구분할 수 있습니다. 확보 방법 반품 주문 헤더의 사용자 지정 필드일 수 있습니다. 처분 코드나 교체 판매 주문 생성과 같은 후속 거래를 기준으로 도출할 수도 있습니다. 예시 환불교체매장 적립금 | |||
| 반품 주문 상태 ReturnOrderStatus | 이벤트 발생 시점의 반품 주문 전체 상태입니다. | ||
| 설명 이 속성은 반품 주문 헤더의 현재 상태를 나타냅니다. 예를 들어 '미결', '송장 발행', '취소' 등이 있습니다. 반품 건의 전체 진행 상황을 파악할 수 있습니다. 활동이 프로세스의 세부 단계를 보여 준다면, 전체 상태는 반품 건을 필터링하고 분류하는 데 유용합니다. 예를 들어 분석가는 현재 업무량을 파악하기 위해 '미결' 건만 보거나, 최종적으로 '취소'된 건의 프로세스 흐름을 분석할 수 있습니다. 중요한 이유 반품 건의 전체 상태를 요약해 보여 주므로, 건을 필터링하고 취소와 같은 결과를 파악하는 데 유용합니다. 확보 방법 'SalesTable'의 'SalesStatus' 또는 'DocumentStatus' 필드에서 확인할 수 있습니다. 예시 주문 미결배송 완료송장 발행취소 | |||
| 실제 환불 금액 ActualRefundAmount | 고객에게 지급한 최종 환불 금액입니다. | ||
| 설명 이 속성은 고객에게 실제로 환불된 최종 확정 금액입니다. 대변전표를 생성하고 전기할 때 기록됩니다. 재무 분석에 중요한 속성으로, '환불 금액 차이 분석' 대시보드와 '환불 금액 정확도' KPI에 직접 사용됩니다. 이 데이터를 분석하면 반품의 재무적 영향과 프로세스 중 발생한 조정 내역을 파악할 수 있습니다. 중요한 이유 반품으로 발생한 실제 재무 영향을 나타냅니다. 환불 정확도를 계산하고 재무 결과를 파악하는 데 중요합니다. 확보 방법 전기된 대변전표의 거래 세부 정보에서 확인할 수 있습니다. 대변전표의 'CustTrans' 및 'CustInvoiceJour' 테이블과 관련이 있습니다. 예시 99.99135.000.00 | |||
| 요청 환불 금액 RequestedRefundAmount | 고객이 요청한 환불 금액의 총액입니다. | ||
| 설명 이 속성은 반품 프로세스 초기에 요청되거나 예상된 환불 금액을 나타냅니다. 일반적으로 반품 상품의 최초 구매 가격을 기준으로 합니다. 이 값은 '환불 금액 차이 분석'의 기준이 됩니다. 요청 금액과 실제 환불 금액을 비교하면 재입고 수수료, 파손 상품에 대한 부분 환불 또는 기타 조정으로 발생한 차이를 확인할 수 있습니다. 이를 통해 재무 정확성과 정책 준수 여부를 점검할 수 있습니다. 중요한 이유 실제 환불 금액과 비교하는 기준으로 삼아 재무 처리의 정확성을 측정할 수 있습니다. 확보 방법 일반적으로 반품 대상인 원래 판매 주문 품목의 행 금액 또는 총액이며, 'SalesLine.LineAmount'에서 확인할 수 있습니다. 예시 99.99150.0024.50 | |||
| 원천 시스템 SourceSystem | 이벤트 데이터를 추출한 정보 시스템입니다. | ||
| 설명 이 속성은 데이터가 생성된 원천 정보 시스템을 식별합니다. 여기서는 주로 'Microsoft Dynamics 365'가 해당합니다. 대규모 조직에서는 하나의 프로세스가 여러 시스템에 걸쳐 진행될 수 있습니다. 각 이벤트의 원천 시스템을 지정하면 데이터 거버넌스를 수행하고 데이터 추출 문제를 해결하며 프로세스에 사용되는 기술 환경을 파악하는 데 도움이 됩니다. 분석 대상 데이터의 출처도 확인할 수 있습니다. 중요한 이유 데이터 출처에 대한 중요한 맥락을 제공하므로 데이터 거버넌스와 검증, 프로세스의 시스템 환경 파악에 도움이 됩니다. 확보 방법 일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다. 예시 Microsoft Dynamics 365 F&OD365-PROD | |||
| 정책 준수 여부 IsPolicyAdherent | 반품 승인이 정해진 반품 정책을 준수하는지 나타내는 표시입니다. | ||
| 설명 이 계산된 불리언 속성은 반품이 회사 정책에 정의된 모든 기준을 충족하는지 나타냅니다. 반품 가능 기간, 상품 상태, 반품 사유 등을 기준으로 판단할 수 있습니다. 이 속성은 '반품 승인 규정 준수 현황' 대시보드와 '규정 준수 반품 승인율' KPI에 직접 활용됩니다. 정책 준수 수준을 수치화하고 예외 승인 건과 그 사유 및 빈도를 분석할 수 있습니다. 거버넌스와 비용 관리에 중요한 정보입니다. 중요한 이유 업무 규칙 준수 여부를 직접 측정해 매출 손실로 이어질 수 있는 정책 미준수 반품 승인을 찾아 줄이는 데 도움이 됩니다. 확보 방법 파생 속성입니다. 반품일과 구매일의 차이, 반품 사유 등 반품 속성을 사전 정의된 업무 규칙과 비교하는 로직을 구성해야 합니다. 예시 truefalse | |||
| 종료 시각 EndTime | 특정 활동이 완료된 시각을 나타내는 타임스탬프입니다. | ||
| 설명 종료 시각은 활동이 완료된 타임스탬프입니다. StartTime이 시작 시각을 나타내는 반면 EndTime은 완료 시각을 나타내므로 해당 작업의 처리 시간을 계산할 수 있습니다. 이 속성은 특히 '상품 검사'처럼 소요 시간을 측정할 수 있는 작업의 상세 성과 분석에 중요합니다. StartTime과 EndTime을 비교하면 작업의 실제 처리 시간과 작업 사이의 대기 시간을 구분할 수 있습니다. 이를 통해 작업 사이뿐 아니라 개별 활동 내의 비효율도 찾아낼 수 있습니다. 중요한 이유 개별 활동의 실제 처리 시간을 계산해 대기 시간과 실제 작업 시간을 구분할 수 있습니다. 확보 방법 대개 다른 데이터에서 도출해야 합니다. 예를 들어 활동을 완료하는 상태 변경의 'modifiedDateTime'을 사용하거나 다음 활동의 StartTime을 사용할 수 있습니다. 예시 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| 창고 ID WarehouseId | 반품 상품을 접수하는 창고 또는 위치의 식별자입니다. | ||
| 설명 이 속성은 반품 상품을 처리하는 실제 창고 또는 반품 센터를 식별합니다. 위치에 따라 프로세스, 리소스 또는 성과 수준이 다를 수 있습니다. 창고별 프로세스를 분석하면 위치 간 성과를 비교할 수 있습니다. 반품 처리가 가장 효율적인 시설을 찾고, 지역별 병목을 파악하며, 물류 네트워크 전반의 리소스 배분과 프로세스 표준화에 관한 의사결정에 활용할 수 있습니다. 중요한 이유 창고 또는 반품 센터별 성과를 비교해 지역별 병목과 우수 사례를 파악할 수 있습니다. 확보 방법 입고 저널('WMSJournalTable')이나 'SalesLine' 등 재고 관련 거래의 'InventLocationId' 필드에 저장됩니다. 예시 WH-EASTWH-WESTCENTRAL-DC | |||
| 환불 SLA 목표일 RefundSlaTargetDate | 반품 및 환불 건을 모두 처리해야 하는 목표일입니다. | ||
| 설명 이 속성은 반품 건을 처리하기 위한 서비스 수준 계약(SLA) 기한을 정의합니다. 환불 전기 또는 교체품 발송과 같은 최종 처리를 완료해야 하는 날짜입니다. 이 목표일은 서비스 약속에 따른 성과를 모니터링하는 데 필요합니다. '해결 SLA 준수율' KPI를 계산하고 '환불 처리 SLA 성과' 대시보드를 구성하는 데 사용됩니다. 목표일과 실제 완료일을 비교하면 SLA 기한을 넘긴 건을 파악하고 장기 미처리 건에 선제적으로 대응할 수 있습니다. 중요한 이유 프로세스 성과를 측정하는 기준으로, SLA 준수 여부를 추적하고 지연된 건을 파악할 수 있습니다. 확보 방법 표준 필드가 아닐 수 있습니다. 반품 생성일에 사전 정의된 SLA 기간(예: 14일)을 더해 계산하는 경우가 많으며, 사용자 지정 필드에 저장될 수 있습니다. 예시 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
반품 및 환불 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 대변전표 전기 | 대변전표를 재무 원장에 공식적으로 전기해 고객이 크레딧을 사용할 수 있도록 합니다. 회사 관점에서 환불 처리가 완료되었음을 나타냅니다. | ||
| 중요한 이유 환불이 시스템에서 처리되었음을 확인하는 중요한 재무 단계입니다. 환불 SLA 준수 여부를 측정할 때 주요 활동으로 사용됩니다. 확보 방법 반품 주문의 대변전표를 확정하는 송장 분개장의 전기 시각입니다. 이때 반품 주문 상태가 'Invoiced'로 변경됩니다. 기록 반품 주문의 송장 분개장 전기입니다. 이벤트 유형 explicit | |||
| 반품 주문 생성 | 이 활동은 시스템에서 반품 자재 승인(RMA) 또는 반품 주문을 생성해 반품 프로세스를 시작하는 단계입니다. Dynamics 365에서 새 ReturnOrder 레코드가 생성될 때 명시적 이벤트로 기록됩니다. | ||
| 중요한 이유 반품 프로세스 전체의 주요 시작 이벤트입니다. 이 활동부터 다른 활동까지 걸리는 시간을 분석하면 전체 처리 시간을 파악하고 초기 단계의 병목을 찾을 수 있습니다. 확보 방법 ReturnOrder 헤더의 생성 시각을 기준으로 이벤트를 기록합니다. 일반적으로 SalesType이 'Returned Order'인 SalesTable에서 확인할 수 있습니다. 기록 SalesType = 'Returned Order'인 SalesTable 레코드의 생성 이벤트입니다. 이벤트 유형 explicit | |||
| 반품 주문 종료 | 반품 주문의 최종 상태로, 상품과 재무 거래가 모두 완료되었음을 의미합니다. 일반적으로 대변전표를 전기하거나 대체 상품을 발송한 뒤 종료됩니다. | ||
| 중요한 이유 정상적으로 완료된 반품 프로세스의 주요 종료 이벤트입니다. 주문 생성부터 이 시점까지 걸린 시간이 전체 사례 처리 시간입니다. 확보 방법 ReturnOrder 상태 필드가 'Invoiced' 또는 'Closed'와 같은 최종 값으로 변경된 것을 기준으로 추정합니다. 이후 추가 처리가 필요하지 않음을 나타냅니다. 기록 SalesTable.Status 또는 SalesTable.DocumentStatus 필드가 최종 상태로 변경된 이벤트입니다. 이벤트 유형 inferred | |||
| 상품 입고 | 반품 상품이 창고나 지정된 반품 센터에 실제로 도착했음을 나타냅니다. 반품 주문과 연결된 입고 분개장을 전기할 때 기록됩니다. | ||
| 중요한 이유 고객이 수행하는 단계에서 내부 처리 단계로 넘어가는 중요한 시점입니다. 검사와 처분 결정 등 내부 처리 시간을 계산하는 기준이 됩니다. 확보 방법 반품 주문 라인과 연결된 WMS 분개장 또는 상품 입고 분개장의 전기 시각입니다. 이때 재고 거래 상태가 'Registered' 또는 'Received'로 변경됩니다. 기록 반품 주문 라인과 연결된 상품 입고 분개장의 전기 이벤트입니다. 이벤트 유형 explicit | |||
| 처분 코드 적용 | 검사가 끝난 뒤 반품 상품의 처리 방법을 결정하는 활동입니다. 반품 주문 라인에 'Credit', 'Scrap', 'Replace' 등의 처분 코드를 지정합니다. | ||
| 중요한 이유 환불, 교환, 반품 거부 등 이후 프로세스 경로를 결정하는 주요 지점입니다. 이 단계가 지연되면 전체 처리 시간에 큰 영향을 줄 수 있습니다. 확보 방법 반품 주문 라인의 재고 거래나 관련 분개장에 DispositionCode 필드가 입력될 때 기록됩니다. 기록 반품 주문 라인에 DispositionCode를 설정할 때 발생하는 업데이트 이벤트입니다. 이벤트 유형 explicit | |||
| 대변전표 생성 | 'Credit' 처분이 결정되면 고객 환불을 승인하는 대변전표를 생성합니다. 이 단계부터 재무 정산 절차가 시작됩니다. | ||
| 중요한 이유 재무 환불이 승인되는 활동입니다. 처분 결정부터 대변전표 생성까지 걸리는 시간을 보면 환불 시작 과정의 행정 지연을 파악할 수 있습니다. 확보 방법 원래 반품 주문과 연결된 음수 금액의 새 SalesTable 레코드가 생성되었는지 확인하거나 'Create credit note' 일괄 작업을 실행해 추정할 수 있습니다. 기록 대변전표 생성입니다. 반품 주문 송장을 전기해 생성하는 경우가 많습니다. 이벤트 유형 explicit | |||
| 대체 상품 발송 | 대체 상품의 포장 명세서를 전기해 고객에게 발송했음을 기록합니다. 교환 이행 절차가 완료되는 시점입니다. | ||
| 중요한 이유 교환 경로에서 회사가 고객에게 약속한 의무를 이행했음을 나타내는 주요 단계입니다. 교환 처리 시간을 추적하는 데 중요합니다. 확보 방법 대체 판매 주문의 포장 명세서 분개장 전기일입니다. 이때 주문 상태가 'Delivered'로 변경됩니다. 기록 대체 판매 주문의 포장 명세서 전기입니다. 이벤트 유형 explicit | |||
| 대체 주문 생성 | 고객에게 대체 상품을 보내기 위해 새 판매 주문을 생성합니다. 처분 조치가 'Replace and Credit' 또는 'Replace and Scrap'인 경우 발생합니다. | ||
| 중요한 이유 교환 프로세스 경로가 시작되는 활동입니다. 환불 경로와 구분해 추적하면 교환 처리의 복잡도와 비용을 파악할 수 있습니다. 확보 방법 대체 상품에 대한 새 SalesTable 레코드 생성입니다. 일반적으로 자동 생성되며 원래 반품 주문과 연결됩니다. 기록 처분 조치를 통해 반품 주문과 연결된 새 판매 주문 생성입니다. 이벤트 유형 explicit | |||
| 반품 주문 취소 | 반품 주문이 완료되기 전에 취소됩니다. 고객 요청이나 상품이 반송되지 않은 경우 취소될 수 있습니다. | ||
| 중요한 이유 프로세스가 정상적으로 완료되지 않고 종료되는 경로입니다. 취소 사유를 분석하면 고객 행동이나 프로세스 문제를 파악할 수 있습니다. 확보 방법 ReturnOrder 상태 필드가 'Cancelled'로 변경된 것을 기준으로 추정합니다. 정상적으로 종료된 주문과 구분되는 최종 상태입니다. 기록 SalesTable.Status 필드가 'Cancelled'로 변경된 이벤트입니다. 이벤트 유형 inferred | |||
| 반품 주문 확인 | 시스템에서 반품 주문을 공식적으로 확인하는 단계로, 후속 로직이 실행되는 경우가 많습니다. 일반적으로 명시적 작업이나 ReturnOrder 헤더의 상태 변경으로 기록됩니다. | ||
| 중요한 이유 물류 작업을 시작하기 전에 거쳐야 하는 주요 단계입니다. 주문 생성 후 확인까지 지연되면 행정 업무나 시스템 처리의 적체를 나타낼 수 있습니다. 확보 방법 반품 주문의 'Confirmation' 분개장 전기 또는 SalesTable의 DocumentStatus 필드 변경으로 확인할 수 있습니다. 기록 반품 주문에 'Confirm sales order' 기능을 실행한 이벤트입니다. 이벤트 유형 explicit | |||
| 입고 분개장 생성 | 창고에서 반품 상품의 도착을 기다리고 있음을 나타내는 활동입니다. 입고 분개장을 생성해 상품을 실제로 수령할 준비를 시스템에 등록합니다. | ||
| 중요한 이유 이 단계는 물류 준비와 상품의 실제 입고를 구분합니다. 창고의 준비 상태를 분석하고 반품 입고를 계획하는 데 도움이 됩니다. 확보 방법 JournalType이 'Arrival'인 WMSJournalTable 레코드의 생성입니다. 분개장은 반품 주문 라인과 연결됩니다. 기록 반품에 해당하는 WMSJournalTable 레코드의 생성 시각입니다. 이벤트 유형 explicit | |||
| 품질 주문 생성 | 반품 상품에 정해진 검사 절차가 필요할 때 품질 주문을 생성합니다. 반품 상품을 자세히 검사하거나 품질 기준에 따라 확인해야 하는 경우에 주로 사용됩니다. | ||
| 중요한 이유 정식 검사 절차가 시작되는 활동입니다. 이 시점부터 걸리는 시간을 추적하면 품질 보증 워크플로의 효율과 소요 시간을 측정할 수 있습니다. 확보 방법 반품 주문과 연결된 InventQualityOrderTable 레코드의 생성 시각입니다. 기록 InventQualityOrderTable 레코드 생성입니다. 이벤트 유형 explicit | |||
데이터 추출 가이드
단계
- 사전 준비: Azure Active Directory에 애플리케이션 등록. Dynamics 365 API에 연결하려면 먼저 Azure AD 테넌트에 애플리케이션을 등록해야 합니다. 애플리케이션에 Dynamics 365 Finance & Operations에 액세스할 수 있는 위임된 권한을 부여하세요. 예를 들어
Financials.ReadWrite.All또는 사용자 지정 권한을 사용할 수 있습니다. - Dynamics 365에서 애플리케이션 ID 구성. Dynamics 365에서 시스템 관리 > 설정 > Azure Active Directory 애플리케이션으로 이동합니다. Azure AD 앱 등록에서 확인한 애플리케이션(클라이언트) ID를 추가하고, 필요한 데이터 엔터티를 읽을 수 있는 보안 역할이 할당된 사용자 계정과 연결합니다.
- OAuth 2.0 액세스 토큰 발급. PowerShell 또는 Python으로 Microsoft ID 플랫폼 엔드포인트에 인증하는 스크립트를 작성합니다. 애플리케이션 자격 증명(클라이언트 ID 및 암호)을 사용해 Dynamics 365 리소스 URL에 대한 액세스 토큰을 요청합니다.
- Dynamics 365 환경 URL 확인. Dynamics 365 환경의 기본 URL을 확인합니다. Web API 엔드포인트는 일반적으로
https://[YourD365FinanceAndOpsURL].dynamics.com/data형식입니다. - OData API 요청 구성 및 실행. 필요한 12개 활동 각각에 대해 OData GET 요청 URL을 구성합니다.
$select로 필요한 열만 가져오고,$filter로 날짜 범위와 상태 조건을 지정합니다. 3단계에서 발급한 인증 토큰을 각 요청의 인증 헤더에 Bearer 토큰으로 포함해야 합니다. - 추출 스크립트 작성. OData 요청 목록을 순회하는 스크립트를 만듭니다. 스크립트에서 인증과 각 GET 요청 실행을 처리하고, 응답으로 받은 JSON 데이터를 저장합니다. API 제한을 확인하고 필요한 경우 요청 사이에 대기 시간을 두세요.
- API 페이지네이션 처리. Dynamics 365는 결과가 많으면 여러 페이지로 나누어 반환합니다. 응답에
@odata.nextLink속성이 있는지 확인해야 합니다. 속성이 있으면 해당 URL로 후속 요청을 보내 다음 페이지를 가져오고,nextLink가 더 이상 반환되지 않을 때까지 반복합니다. - 데이터 변환 및 통합. 12개 API 호출에서 받은 JSON 응답을 처리합니다. 각 활동에 대해
ReturnCaseId,ActivityName,EventTime및 기타 속성을 포함하는 표준 레코드를 만듭니다. 예를 들어 '반품 주문 생성' 이벤트에서는ReturnOrderNumber를ReturnCaseId에 매핑하고,ActivityName을 '반품 주문 생성'으로 설정한 다음,createdDateTime을EventTime에 매핑합니다. 변환한 레코드를 하나의 목록이나 테이블로 통합합니다. - 타임스탬프 정리 및 표준화. 모든
EventTime값의 형식을 통일합니다.YYYY-MM-DDTHH:MM:SSZ와 같은 UTC 형식을 권장합니다. 타임스탬프가 없거나 유효하지 않은 레코드도 적절히 처리합니다. - 최종 이벤트 로그 내보내기. 모든 데이터를 수집하고 하나의 데이터 세트로 변환한 뒤 CSV 파일로 내보냅니다. 열 이름이 ProcessMind 요구사항인
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCode등과 일치하는지 확인합니다. 이제 파일을 업로드할 수 있습니다.
구성
- API 엔드포인트 URL: Dynamics 365 Finance & Operations 인스턴스의 기본 URL입니다. 형식은
https://[YourEnvironmentName].dynamics.com/data입니다. - Azure AD 애플리케이션: Azure AD에 클라이언트 ID와 암호가 있는 애플리케이션을 등록해야 합니다. Dynamics 365 데이터 엔터티에 액세스할 수 있는 API 권한도 필요합니다.
- 날짜 범위 필터링: 관련 날짜 필드(예:
createdDateTime또는modifiedDateTime)에 OData$filter매개변수를 사용해 모든 API 호출에 날짜 범위를 적용해야 합니다. 추출을 원활하게 진행하려면 최근 3~6개월 데이터를 시작 범위로 설정하는 것이 일반적입니다. - 회사 필터: 특정 법인 데이터를 추출하려면
cross-company=true쿼리 매개변수를 포함한 다음dataAreaId필드에$filter를 적용합니다. 예:?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]'. - 페이지네이션 설정: 요청에
Prefer: odata.maxpagesize=[value]헤더를 사용해 페이지당 반환되는 레코드 수를 지정합니다. 일반적으로1000~5000을 사용합니다. 대규모 엔터티를 조회할 때 API 시간 초과를 방지하는 데 도움이 됩니다. - API 요청 제한: Dynamics 365 API의 서비스 보호 제한에 유의하세요. 추출 스크립트에서
429 (Too Many Requests)응답을 처리해야 합니다. 일반적으로 지수형 대기 시간을 적용하거나 일정 시간 대기한 뒤 재시도합니다.
샘플 쿼리 graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser 단계
- TDS 엔드포인트 사용 설정: Dynamics 365 Dataverse 환경에서 Tabular Data Stream(TDS) 엔드포인트가 사용 설정되어 있는지 확인합니다. 시스템 관리자는 Power Platform 관리 센터의 환경 > 설정 > 기능에서 이를 사용 설정할 수 있습니다.
- 환경 URL 확인: 환경 URL을 확인합니다. 일반적으로
yourorg.crm.dynamics.com형식입니다. TDS 엔드포인트 서버 이름은 이 URL에 포트 5558을 붙인 값입니다. 예:yourorg.crm.dynamics.com,5558. - SQL 클라이언트로 연결: SQL Server Management Studio(SSMS) 또는 Azure Data Studio처럼 TDS를 지원하는 SQL 클라이언트를 사용합니다.
- 인증: Dataverse 환경에서 적절한 권한(일반적으로 시스템 관리자 또는 시스템 사용자 지정자)이 있는 Azure Active Directory 계정으로 서버에 연결합니다.
- 쿼리 준비: 이 문서의
query섹션에 있는 전체 SQL 쿼리를 복사해 SQL 클라이언트의 새 쿼리 창에 붙여 넣습니다. - 매개변수 설정: 쿼리에서 자리표시자를 찾습니다.
'{StartDate}'와'{EndDate}'를 추출할 날짜 범위로 바꿉니다. 예:'2023-01-01'및'2023-12-31'. 상태 코드나 처리 코드의 자리표시자도 Dynamics 365 설정에 맞게 변경합니다. - 쿼리 실행: 수정한 쿼리를 Dataverse 데이터베이스에서 실행합니다. 실행 시간은 데이터 양과 선택한 날짜 범위에 따라 달라집니다.
- 결과 검토: 쿼리가 완료되면 반환된 데이터 세트에
ReturnCaseId,ActivityName,EventTime및 권장 속성이 포함되어 있는지 확인합니다. - 이벤트 로그 내보내기: 쿼리 결과를 CSV 파일로 내보냅니다. 대부분의 SQL 클라이언트에는 결과를 파일로 바로 저장하는 기능이 있습니다. UTF-8 인코딩으로 저장하세요.
- ProcessMind에 업로드: 내보낸 CSV 파일을 ProcessMind에 새 이벤트 로그로 업로드해 process mining 분석에 사용할 수 있습니다.
구성
- 사전 준비: 관련 Dataverse 테이블(예: SalesTable, SalesLine, CustInvoiceJour)을 읽을 수 있는 사용자 계정이 필요합니다. 권한은 일반적으로 시스템 관리자와 같은 보안 역할이나 테이블에 충분한 권한을 부여한 사용자 지정 역할로 관리합니다.
- TDS 엔드포인트: 환경에서 Dataverse TDS 엔드포인트를 사용 설정해야 합니다. 이 기능을 사용하면 Dataverse 데이터베이스에 직접 읽기 전용 SQL 쿼리를 실행할 수 있습니다.
- 날짜 범위: 쿼리에는
'{StartDate}'및'{EndDate}'자리표시자가 있습니다. 초기 분석에는 성능 문제를 일으키지 않으면서 대표성 있는 데이터 세트를 확보할 수 있도록 3~6개월 범위를 권장합니다. - 회사 필터: 현재 쿼리는 사용자가 액세스할 수 있는 모든 법인(회사)을 대상으로 실행됩니다. 한 회사만 분석하려면
UNION ALL문의 각 부분에서DATAAREAID필드를 기준으로 필터링하는WHERE절의 주석을 해제하고 추가합니다. 예:AND st.DATAAREAID = '[YourCompanyID]'. - 사용자 지정 로직 자리표시자: 쿼리에는 처리 코드용
[YourReplaceCode1]과 같은 자리표시자 및 대체 주문 연결에 관한 메모가 있습니다. 실제 업무 프로세스와 Dynamics 365 설정에 맞게 구성해야 합니다. - 성능: 대규모 데이터 세트에 TDS 엔드포인트로 직접 쿼리하면 속도가 느릴 수 있습니다. 연결은 분석 쿼리에 최적화되어 있지만, 수백만 행을 대상으로 복잡한 조인을 수행하면 시간 초과가 발생할 수 있습니다. 날짜 범위를 좁혀 적용하는 것이 좋습니다.
샘플 쿼리 sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; 시작할 준비가 되셨나요?
이 템플릿을 활용해 데이터 수집을 간소화하고, 반품 및 환불 프로세스 개선에 필요한 인사이트를 찾아보세요. 지금 바로 처리 시간을 단축하고 고객 만족도를 높이기 위한 분석을 시작하세요.
반품 및 환불 지연을 줄이세요. 지금 프로세스를 최적화하세요
처리 시간을 30% 단축하고 고객 만족도를 높이세요.
신용카드가 필요하지 않습니다. 설정은 몇 분이면 완료됩니다.