반품 및 환불 처리 데이터 템플릿
반품 및 환불 처리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- NetSuite 데이터 추출 안내
반품 및 환불 처리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| Return Case ID ReturnCaseId | 반품 또는 환불 건 하나를 식별하는 고유 ID입니다. 시작부터 종료까지 관련된 모든 활동을 연결합니다. | ||
| 설명 Return Case ID는 반품의 전체 처리 과정을 추적하는 기본 식별자입니다. 각 ID는 하나의 반품 승인에 해당하며, 상품 입고, 검수, 환불 처리 등 관련 이벤트를 종합적으로 분석할 수 있습니다. process mining에서는 이 ID를 사용해 각 반품의 전체 프로세스 흐름을 재구성하고, 처리 시간을 계산하며 건별 편차를 파악합니다. 중요한 이유 process mining의 기본 속성으로, 개별 이벤트를 하나의 일관된 전체 프로세스 인스턴스로 연결합니다. 이를 통해 프로세스 흐름과 성과를 분석할 수 있습니다. 확보 방법 일반적으로 NetSuite Return Authorization 레코드의 Internal ID 또는 Transaction ID입니다. 예시 RMA-0012345RMA-0012346RMA-0012347 | |||
| 이벤트 시각 EventTimestamp | 활동이 발생한 정확한 날짜와 시각으로, 프로세스의 시간 순서를 구성하는 기준입니다. | ||
| 설명 이벤트 시각은 활동이 발생한 정확한 시점을 기록합니다. 이벤트를 올바른 순서로 정렬하고 시간 기반 분석을 수행하는 데 필요한 데이터입니다. 활동 간 소요 시간, 건별 전체 처리 시간, 대기 시간을 계산하는 데 사용되며, 이는 성과 모니터링, 병목 분석, SLA 준수 확인의 기본 자료입니다. process mining 분석의 신뢰도를 확보하려면 시각 데이터가 정확해야 합니다. 중요한 이유 이 속성은 이벤트의 시간 순서를 제공하며, 프로세스 흐름을 찾고 처리 시간과 대기 시간 등 성과 지표를 계산하는 데 필요합니다. 확보 방법 일반적으로 NetSuite 레코드의 'Date Created' 또는 'Last Modified Date' 필드나 거래와 연결된 System Notes 하위 목록의 시각 정보를 사용합니다. 예시 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:12:05Z | |||
| 활동명 ActivityName | 반품 프로세스에서 발생한 구체적인 업무 이벤트나 단계의 이름입니다. 예를 들면 '상품 검수 완료' 또는 '환불 처리'가 있습니다. | ||
| 설명 활동명은 반품 및 환불 과정의 개별 단계나 주요 시점을 나타냅니다. 활동을 시각순으로 정렬해 프로세스 흐름을 구성합니다. 활동의 순서와 빈도를 분석하면 가장 일반적인 처리 경로, 단계 사이의 병목, 재작업이나 반복 활동을 파악할 수 있습니다. 예를 들면 '반품 승인 생성', '상품 입고', 'Credit Memo 승인'이 있습니다. 중요한 이유 이 속성은 프로세스 단계를 정의합니다. 프로세스 맵을 시각화하고 흐름의 차이를 분석하며 병목이나 재작업 반복을 찾는 데 필요합니다. 확보 방법 일반적으로 Return Authorization 및 Credit Memo와 같은 거래 레코드의 상태 변경이나 시스템 메모 또는 사용자 지정 이벤트 로그에 기록된 사용자 작업을 바탕으로 산출합니다. 예시 반품 승인 생성반품 상품 입고상품 검수 완료환불 처리Return Authorization 종료 | |||
| 원천 시스템 SourceSystem | 데이터를 추출한 시스템입니다. 데이터 출처를 추적하는 데 사용합니다. | ||
| 설명 이 속성은 프로세스 데이터의 출처를 나타냅니다. 이 경우 일반적으로 'NetSuite'입니다. 여러 시스템의 데이터를 통합할 수 있는 환경에서는 원천 시스템을 지정해야 데이터 계보와 추적 가능성을 명확히 할 수 있습니다. 중요한 이유 데이터 출처를 식별합니다. 데이터 거버넌스와 문제 해결에 중요하며, 여러 시스템의 데이터를 결합해 프로세스 전체를 파악하는 경우에도 필요합니다. 확보 방법 일반적으로 데이터 추출 및 변환 과정에서 추가하는 고정값('NetSuite')입니다. 예시 NetSuiteNetSuite ERP | |||
| 최근 데이터 업데이트 LastDataUpdate | 이 프로세스의 데이터가 마지막으로 새로 고침되거나 업데이트된 시각입니다. | ||
| 설명 이 속성은 원천 시스템에서 데이터셋을 마지막으로 업데이트한 시점을 기록합니다. 분석 데이터의 최신성을 사용자에게 알리는 중요한 메타데이터입니다. 대시보드에 이 정보를 표시하면 데이터가 얼마나 최신인지 파악한 상태에서 의사결정을 내릴 수 있습니다. 중요한 이유 데이터의 최신성을 투명하게 보여줍니다. 사용자가 분석을 신뢰하고 현재 운영 상태와의 관련성을 이해하는 데 필요합니다. 확보 방법 데이터 추출, 변환, 적재(ETL) 과정에서 생성해 추가하는 시각 정보입니다. 예시 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| 반품 상태 ReturnAuthorizationStatus | 반품 승인 건의 현재 상태입니다. 예: '승인 대기', '승인', '종료'. | ||
| 설명 이 속성은 반품 건의 현재 진행 상태를 나타냅니다. 반품 진행 상황을 파악하고 건을 분류하는 데 기본이 됩니다. 예를 들어 '입고 대기' 상태에 머문 시간이 길면 배송 지연을, '승인 대기' 상태가 오래 지속되면 내부 병목을 의심할 수 있습니다. 또한 '종료' 또는 '거부'와 같은 최종 결과를 확인하는 데도 사용합니다. 중요한 이유 각 반품이 현재 프로세스의 어느 단계에 있는지 보여주므로 건별 분포, 상태별 소요 시간, 처리 결과를 분석할 수 있습니다. 확보 방법 NetSuite Return Authorization 레코드의 'Status' 필드 또는 이에 해당하는 필드입니다. 예시 승인 대기입고 대기승인거부종료 | |||
| 반품 유형 ReturnType | 고객이 제시한 사유를 기준으로 반품을 분류한 유형입니다. | ||
| 설명 반품 유형은 '상품 결함', '사이즈 오류', '단순 변심', '설명과 다름' 등 반품 사유에 따라 건을 분류합니다. 근본 원인을 분석하는 데 중요한 기준입니다. 반품 유형별 프로세스 지표를 분석하면 제품 품질 문제, 부정확한 상품 설명, 주문 처리 오류를 파악할 수 있습니다. '유형 및 채널별 반품 성과' 대시보드의 주요 속성입니다. 중요한 이유 반품의 근본 원인을 파악해 제품, 마케팅 설명, 주문 처리 프로세스를 개선하고 반품 건수를 줄이는 데 도움이 됩니다. 확보 방법 일반적으로 Return Authorization 양식에서 반품 사유를 기록하는 사용자 지정 필드나 표준 목록/레코드 필드입니다. 예시 제품 결함잘못된 상품 배송고객 불만족사이즈/색상 오류 | |||
| 부서 Department | 특정 단계에서 반품 건을 처리하는 업무 부서 또는 팀입니다. | ||
| 설명 이 속성은 프로세스 활동을 '고객 서비스', '창고', '재무'와 같은 부서에 연결합니다. 팀 간 업무 인계를 파악하고 부서별 병목을 찾는 데 필요합니다. 특정 부서에서 건이 처리되거나 대기하는 시간을 분석하면 지연 원인을 찾아 리소스 배분을 개선할 수 있습니다. '부서별 반품 프로세스 성과' 대시보드의 주요 분석 기준입니다. 중요한 이유 업무 기능별 프로세스 성과를 분석해 부서 간 인계 지연과 부서별 병목을 파악할 수 있습니다. 확보 방법 활동과 연결된 사용자 또는 직원 레코드나 거래 자체의 'Department' 필드에서 가져올 수 있습니다. NetSuite에서는 직원 레코드에 설정하는 경우가 많습니다. 예시 창고고객 지원재무품질 보증 | |||
| 실제 환불 금액 ActualRefundAmount | 고객에게 실제로 환불한 최종 금액입니다. | ||
| 설명 이 속성은 Credit Memo 또는 환불 거래에 기록된 실제 지급 또는 환불 금액을 나타냅니다. 재입고 수수료, 배송비 또는 손상 상품에 대한 부분 환불 등의 조정으로 요청 금액과 다를 수 있습니다. 재무 보고와 '환불 금액 차이율' KPI 계산에 필요한 속성입니다. 중요한 이유 반품의 실제 재무 영향을 나타내며, 재무 조정과 환불 정확도 분석에 필요합니다. 확보 방법 Return Authorization에서 생성된 Credit Memo 거래의 'Total' 필드에서 가져옵니다. 예시 99.99140.000.00 | |||
| 처리 담당자 ProcessingAgent | 반품 프로세스에서 특정 활동을 수행한 직원 또는 사용자입니다. | ||
| 설명 처리 담당자는 반품 승인이나 상품 검수와 같은 작업을 수행한 사람을 나타냅니다. 사용자별 성과 분석에 중요한 속성입니다. 성과가 높은 직원을 파악하고 추가 교육이 필요한 영역과 팀 내 업무량 불균형을 확인할 수 있습니다. 담당자별 활동 분석은 '부서별 반품 프로세스 성과' 대시보드의 주요 기능입니다. 중요한 이유 개인 및 팀 성과, 업무량 균형, 교육 필요성을 분석해 운영 효율에 직접 영향을 주는 요인을 파악할 수 있습니다. 확보 방법 NetSuite 거래의 'Created By', 'Approved By' 필드나 System Notes 하위 목록의 사용자 필드에서 가져올 수 있습니다. 예시 Alice JohnsonBob WilliamsCharlie Brown | |||
| SLA 준수 여부 IsSlaCompliant | 환불이 정해진 SLA 목표 시간 안에 처리되었는지 나타내는 계산된 플래그입니다. | ||
| 설명 이 불리언 속성은 '환불 처리' 타임스탬프와 '환불 SLA 목표일'을 비교해 계산합니다. 환불이 목표일 당일 또는 그 전에 처리되면 true, 그렇지 않으면 false입니다. 이 플래그를 사용하면 '환불 SLA 준수 모니터링' 대시보드 같은 규정 준수 보고서와 대시보드를 쉽게 만들고 '환불 SLA 달성률' KPI를 계산할 수 있습니다. 중요한 이유 각 사례의 SLA 성과를 명확하게 준수 또는 미준수로 표시하므로 시간에 따른 준수율을 쉽게 추적하고 보고하며 분석할 수 있습니다. 확보 방법 이 속성은 데이터 변환 단계나 process mining 도구에서 계산합니다. 계산식은 다음과 같습니다. 예시 truefalse | |||
| 고객 ID CustomerId | 반품을 요청한 고객을 식별하는 고유 ID입니다. | ||
| 설명 고객 ID는 반품 거래를 특정 고객과 연결합니다. 이를 통해 반품이 잦은 고객을 찾아 고객 중심으로 분석할 수 있으며, 잦은 반품은 불만이나 사기 가능성을 나타낼 수 있습니다. 고객 유형이나 가치에 따라 프로세스 성과를 구분해 분석하고 주요 고객에게 서비스를 우선 제공하는 데도 활용할 수 있습니다. 중요한 이유 고객별 반품 행태를 분석하고 고객 세그먼트나 생애 가치 같은 속성에 따라 프로세스를 구분해 분석할 수 있습니다. 확보 방법 NetSuite의 Return Authorization 레코드 헤더에 있는 'Customer' 또는 'Entity' 필드입니다. 예시 CUST-001CUST-002CUST-003 | |||
| 반품 상품 상태 ReturnCondition | 검수 시 확인한 반품 상품의 상태입니다. 예: '새 상품', '손상됨', '사용됨'. | ||
| 설명 이 속성은 반품 상품의 실물 검수 결과를 기록합니다. 상품 상태에 따라 전액 환불, 재입고 또는 폐기 여부 등 후속 절차가 결정됩니다. '반품 상품 상태 평가 품질' 대시보드에서는 평가의 일관성과 처리 시간을 분석합니다. 이 정보는 재무 조정과 재고 관리에도 중요합니다. 중요한 이유 반품의 재무 결과와 후속 재고 처리에 직접 영향을 줍니다. 평가가 일관되지 않으면 재무 손실이나 프로세스 재작업이 발생할 수 있습니다. 확보 방법 일반적으로 Item Receipt 또는 Return Authorization 레코드의 사용자 지정 필드이며, 창고 직원이 검수 중 입력합니다. 예시 재판매 가능손상됨, 포장 상자 내사용됨, 양호한 상태부품 누락 | |||
| 반품 채널 ReturnChannel | 최초 구매 또는 반품 요청이 이루어진 채널입니다. | ||
| 설명 반품 채널은 반품이 발생한 경로를 나타냅니다. 예: '온라인', '매장', '마켓플레이스'. 채널마다 반품 절차, 비용, 고객 기대가 다를 수 있습니다. 채널별 성과를 분석하면 각 프로세스를 개선하고 리소스를 효율적으로 배분하며 채널별 문제를 파악할 수 있습니다. '유형 및 채널별 반품 성과' 대시보드의 주요 속성입니다. 중요한 이유 사업 채널별 성과를 비교해 반품 요청 및 처리 방식에 따른 비효율과 모범 사례를 찾을 수 있습니다. 확보 방법 반품과 연결된 원래 Sales Order 레코드에서 가져오는 경우가 많습니다. 'Channel' 또는 'Location' 필드에 저장될 수 있습니다. 예시 온라인 스토어소매 매장Amazon 마켓플레이스전화 주문 | |||
| 요청 환불 금액 RequestedRefundAmount | 반품 건에 대해 처음 요청했거나 예상한 환불 금액입니다. | ||
| 설명 이 속성은 프로세스 시작 시점의 예상 환불 금액을 저장합니다. 일반적으로 반품 상품의 최초 구매 가격을 기준으로 합니다. 최종 환불 금액과 비교할 기준값으로 사용합니다. '환불 금액 차이율' KPI는 이 값과 실제 환불 금액을 직접 비교해 재입고 수수료, 부분 환불 또는 기타 조정으로 발생한 차이를 파악합니다. 중요한 이유 재무 분석의 기준값으로 활용해 예상 환불 금액과 실제 환불 금액의 차이를 추적하고 조정 사유를 파악할 수 있습니다. 확보 방법 Return Authorization 거래의 항목별 'Amount' 또는 'Rate' 필드에서 가져옵니다. 예시 99.99150.0025.50 | |||
| 자동 처리 여부 IsAutomated | 시스템이 활동을 자동으로 수행했는지 나타내는 불리언 플래그입니다. | ||
| 설명 이 속성은 활동을 사용자가 수행했는지, 자동화된 시스템, 스크립트 또는 workflow가 수행했는지 나타냅니다. 예를 들어 고객 포털에서 '반품 승인 생성' 이벤트가 자동으로 발생할 수 있지만, '상품 검수'는 수동 활동입니다. 자동화 여부를 추적하면 수동 단계를 자동화할 기회를 찾고 기존 자동화의 효율 개선 효과를 측정할 수 있습니다. 중요한 이유 수동 작업과 자동화된 작업을 구분할 수 있습니다. 자동화 기회를 찾고 디지털 전환의 효과를 측정하는 데 중요합니다. 확보 방법 이벤트에 연결된 사용자를 기준으로 추론할 수 있습니다. NetSuite에서 시스템이 생성한 이벤트에는 특정 시스템 사용자나 스크립트 ID가 연결되는 경우가 많습니다. 예시 truefalse | |||
| 정책 준수 여부 ReturnPolicyAdherence | 반품이 회사의 정해진 반품 정책을 준수하는지 나타냅니다. | ||
| 설명 이 불리언 또는 범주형 속성은 반품 기간, 상품 상태, 구매 증빙 등 사전 정의된 기준을 반품이 모두 충족하는지 표시합니다. 규정 준수 현황을 모니터링하고 예외를 관리하는 데 사용합니다. '반품 정책 준수 예외' 대시보드는 특별한 처리나 검토가 필요한 사례를 이 속성으로 식별해 위험을 줄이고 규칙을 일관되게 적용하도록 돕습니다. 중요한 이유 반품 정책을 모니터링하고 적용하는 데 도움이 됩니다. 정책을 준수하지 않는 반품으로 인한 재무 위험을 줄이고 공정성과 일관성을 유지할 수 있습니다. 확보 방법 대개 Return Authorization 레코드에 체크박스나 목록 형태의 사용자 지정 필드로 추가하고, workflow를 통해 관리합니다. 예시 정책 준수정책 미준수, 반품 기간 초과예외 승인 | |||
| 제품 식별자 ProductIdentifier | 반품 대상 제품을 식별하는 고유 값입니다. 예: SKU 또는 Item Number. | ||
| 설명 이 속성은 반품 대상 상품을 식별합니다. 제품별 반품을 분석하면 반품률이 높은 상품을 찾아 품질 결함, 부정확한 설명 또는 기타 문제를 파악할 수 있습니다. 이 데이터를 바탕으로 제품 성과를 자세히 분석하고 제품 개발, 소싱, 마케팅 관련 의사결정을 내릴 수 있습니다. 중요한 이유 반품 프로세스 데이터를 특정 제품과 연결해 제품 관련 문제의 근본 원인을 분석하고 전체 반품률을 낮추는 데 도움이 됩니다. 확보 방법 Return Authorization 레코드의 'Items' 하위 목록에 있으며, 'Item' 필드에 해당합니다. 예시 SKU-TEE-BL-LPROD-00543ITEM-987123 | |||
| 환불 SLA 목표일 RefundSlaTargetDate | 서비스 수준 협약에 따라 환불 처리를 완료할 것으로 예상하는 목표일입니다. | ||
| 설명 환불 SLA 목표일은 고객에게 약속한 환불 처리 기한을 나타내는 계산된 타임스탬프입니다. 일반적으로 '상품 수령' 또는 '환불 승인' 같은 주요 이벤트에 영업일 기준 5일 등의 사전 정의된 기간을 더해 계산합니다. 이 속성은 '환불 SLA 준수 모니터링' 대시보드와 '환불 SLA 달성률' KPI에 필요하며, 고객과의 약속을 기준으로 성과를 측정할 수 있습니다. 중요한 이유 고객과의 약속을 기준으로 성과를 정량적으로 측정할 수 있어 고객 만족과 신뢰를 유지하는 데 중요합니다. 확보 방법 일반적으로 표준 필드가 아니므로 '상품 수령' 날짜 같은 주요 타임스탬프에 사전 정의된 SLA 기간(예: 5일)을 더해 계산해야 합니다. 예시 2023-11-01T23:59:59Z2023-11-05T23:59:59Z2023-11-10T23:59:59Z | |||
| 환불 금액 차이 RefundAmountDiscrepancy | 요청 환불 금액과 실제 환불 금액의 차이를 계산한 값입니다. | ||
| 설명 '요청 환불 금액'에서 '실제 환불 금액'을 빼 계산합니다. 0이 아닌 값은 재입고 수수료나 상품 손상 등으로 프로세스 중 금액이 조정되었음을 나타냅니다. '환불 금액 차이율' KPI 분석에 사용해 재무 조정 폭이 큰 사례를 추가 검토 대상으로 표시할 수 있습니다. 중요한 이유 반품 과정에서 발생한 재무 조정을 보여 주므로 차이가 발생한 이유와 조정이 일관되고 타당한지 분석할 수 있습니다. 확보 방법 계산된 속성입니다. 계산식: 예시 0.0010.00-5.00 | |||
반품 및 환불 처리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| Credit Memo 생성 | Credit Memo를 생성해 반품의 재무 처리를 시작하는 활동입니다. 이 문서에는 고객에게 환불할 금액이 명시되며, 상품 입고와 승인 후 Return Authorization을 바탕으로 생성됩니다. | ||
| 중요한 이유 Credit Memo 생성은 재무 처리의 주요 단계입니다. 상품 입고부터 Credit Memo 생성까지 걸리는 시간을 보면 검수부터 대변 처리까지의 효율을 파악할 수 있습니다. 확보 방법 이 이벤트는 CreditMemo 거래가 생성된 시각입니다. Credit Memo의 'Created From' 필드에서 ReturnAuthorization과의 연결을 확인할 수 있습니다. 기록 NetSuite CreditMemo 거래의 생성일입니다. 이벤트 유형 explicit | |||
| Return Authorization 종료 | 모든 처리가 끝난 후 반품 건을 행정적으로 마무리하는 최종 활동입니다. Return Authorization 레코드의 상태가 '종료'로 변경된 것을 확인해 추론합니다. | ||
| 중요한 이유 프로세스의 최종 종료 지점으로, 전체 처리 시간을 계산하고 환불 처리 후에도 오랫동안 열려 있는 건을 찾는 데 필요합니다. 확보 방법 ReturnAuthorization 레코드의 시스템 메모 또는 워크플로 이력을 확인해 추론합니다. 'Status' 필드가 '종료'와 같은 최종 상태로 변경된 시점을 기준으로 합니다. 기록 ReturnAuthorization 레코드의 상태가 '종료'로 변경된 시점을 감지합니다. 이벤트 유형 inferred | |||
| 반품 상품 입고 | 창고나 처리 센터에 반품 상품이 실제로 도착한 활동입니다. NetSuite에서는 원래 Return Authorization과 연결된 Item Receipt 거래를 생성해 명시적으로 기록합니다. | ||
| 중요한 이유 이 주요 단계에서 고객의 반품 절차가 내부 처리로 넘어갑니다. '반품 승인'부터 '상품 입고'까지의 시간은 고객의 반품 속도를, 입고 이후의 시간은 내부 처리 효율을 보여줍니다. 확보 방법 이 이벤트는 ItemReceipt 거래가 생성된 시각입니다. 이 레코드는 반품을 시작한 ReturnAuthorization에 직접 연결됩니다. 기록 RA와 연결된 NetSuite ItemReceipt 거래의 생성일입니다. 이벤트 유형 explicit | |||
| 반품 승인 생성 | 고객이 상품 반품을 요청하면 반품 프로세스가 시작됩니다. NetSuite에서 새 Return Authorization(RA) 레코드를 생성해 이 활동을 명시적으로 기록하며, 이 레코드는 반품 건의 기본 식별자로 사용됩니다. | ||
| 중요한 이유 프로세스의 시작 단계인 이 활동은 반품 전체 처리 시간과 기간별 반품 요청 건수를 분석하는 데 필요합니다. 확보 방법 이 이벤트는 NetSuite에서 ReturnAuthorization 레코드가 생성된 시각입니다. 일반적으로 레코드에 사용자, 날짜, 초기 상태(예: '승인 대기')가 기록됩니다. 기록 NetSuite ReturnAuthorization 거래 레코드의 생성일입니다. 이벤트 유형 explicit | |||
| 반품 승인 승인 | 직원이 고객의 반품 요청을 공식 승인해 다음 단계로 진행할 수 있게 되는 활동입니다. 일반적으로 Return Authorization 레코드의 상태가 '승인 대기'에서 '입고 대기'로 변경된 것을 확인해 기록합니다. | ||
| 중요한 이유 이 승인 단계를 추적하면 초기 검토 단계의 병목을 파악할 수 있습니다. 이 단계가 지연되면 고객에게 안내하고 반품 상품을 받는 시점도 늦어집니다. 확보 방법 ReturnAuthorization 레코드의 시스템 메모 또는 워크플로 이력을 확인해 추론합니다. 특히 'Status' 필드가 승인 상태(예: '입고 대기')로 변경된 시점을 기준으로 합니다. 기록 ReturnAuthorization 레코드의 상태가 '승인'으로 변경된 시점을 감지합니다. 이벤트 유형 inferred | |||
| 환불 처리 | 고객에게 자금을 반환하는 최종 재무 처리입니다. Credit Memo를 바탕으로 Customer Refund 거래를 생성해 명시적으로 기록합니다. | ||
| 중요한 이유 SLA 준수와 고객 만족도를 측정하는 데 중요한 활동입니다. 'Credit Memo 승인'부터 '환불 처리'까지 걸리는 시간은 자금 관리 또는 재무 부서의 처리 속도를 직접 보여줍니다. 확보 방법 이 이벤트는 CustomerRefund 거래가 생성된 시각입니다. 해당 거래의 'Created From' 필드에서 CreditMemo와의 연결을 확인할 수 있습니다. 기록 NetSuite CustomerRefund 거래의 생성일입니다. 이벤트 유형 explicit | |||
| Credit Memo 승인 | Credit Memo를 공식 승인하는 단계입니다. 고액 환불이나 재무 통제 절차에서 승인이 필요할 수 있습니다. Credit Memo 레코드의 상태가 적용 또는 지급 가능한 상태로 변경된 것을 확인해 추론합니다. | ||
| 중요한 이유 재무 승인이 필요한 경우 이 단계에서 병목이 발생할 수 있습니다. 처리 시간을 분석하면 고객 환불을 늦추지 않으면서 재무 통제를 효율화할 수 있습니다. 확보 방법 CreditMemo 레코드의 시스템 메모를 확인해 추론합니다. 특히 승인 상태 필드가 '승인 대기'에서 '승인' 또는 '미결'로 변경된 시점을 기준으로 합니다. 기록 CreditMemo 거래의 상태가 '승인'으로 변경된 시점을 감지합니다. 이벤트 유형 inferred | |||
| Credit Memo 적용 | 현금 환불 대신 미결 고객 송장에 Credit Memo를 적용하는 활동입니다. Credit Memo의 'Applied To' 연결을 확인해 대변 금액이 사용된 시점을 추론합니다. | ||
| 중요한 이유 현금 환불과 대변 적용을 구분하면 재무 분석에 도움이 됩니다. 이 경로는 직접 환불과 다른 방식으로 프로세스를 마무리합니다. 확보 방법 CreditMemo의 시스템 메모 또는 관련 레코드를 확인해 추론합니다. 특히 고객 잔액을 상계하기 위해 Invoice 거래와 연결된 시점을 기준으로 합니다. 기록 CreditMemo가 Invoice 거래에 적용된 시점을 감지합니다. 이벤트 유형 inferred | |||
| 고객 안내 | 승인, 상품 입고, 환불 처리 등 주요 상태 변경을 고객에게 알리는 활동입니다. 일반적으로 레코드의 커뮤니케이션 탭에 기록된 시스템 발송 이메일의 시각을 바탕으로 추론합니다. | ||
| 중요한 이유 고객 만족을 위해서는 적시에 안내해야 합니다. 주요 단계가 완료된 시점과 고객에게 알린 시점 사이의 지연을 측정하면 고객 경험의 공백을 찾을 수 있습니다. 확보 방법 시스템 분석이 필요합니다. ReturnAuthorization 또는 CreditMemo의 Communication 하위 탭에 기록된 발신 이메일이나 사용자 메모의 시각을 확인합니다. 기록 해당 건과 연결된 이메일 또는 커뮤니케이션 로그 항목의 시각입니다. 이벤트 유형 inferred | |||
| 교환 주문 생성 | 환불 대신 고객에게 교환 상품을 제공하기 위해 새 판매 주문을 생성하는 활동입니다. 일반적으로 원래 Return Authorization과 연결된 Sales Order가 생성된 것을 확인해 기록합니다. | ||
| 중요한 이유 교환을 별도의 경로로 추적하면 고객 선호도와 환불 대비 교환 처리의 효율을 분석할 수 있습니다. 교환은 흔히 발생하는 중요한 처리 유형입니다. 확보 방법 이 이벤트는 새 SalesOrder 거래가 생성된 시각입니다. ReturnAuthorization과의 연결은 표준 필드나 사용자 지정 필드에 있을 수 있으므로 시스템 분석이 필요합니다. 기록 ReturnAuthorization과 연결된 SalesOrder의 생성일입니다. 이벤트 유형 explicit | |||
| 반품 승인 거부 | 고객의 반품 요청을 거부하는 결정입니다. 정책 위반 등이 사유일 수 있습니다. Return Authorization 레코드의 상태가 '거부' 또는 추가 처리 없이 '종료'로 변경된 것을 확인해 기록합니다. | ||
| 중요한 이유 거부 사례를 분석하면 규정을 준수하지 않은 반품 요청의 주요 사유를 파악할 수 있습니다. 이를 바탕으로 고객 안내를 개선하고 정책을 명확히 할 수 있습니다. 정상적인 처리 경로에서 벗어난 주요 사례이기도 합니다. 확보 방법 ReturnAuthorization 레코드의 시스템 메모 또는 워크플로 이력을 확인해 추론합니다. 특히 'Status' 필드가 최종 상태인 '거부'로 변경된 시점을 기준으로 합니다. 기록 ReturnAuthorization 레코드의 상태가 '거부'로 변경된 시점을 감지합니다. 이벤트 유형 inferred | |||
| 상품 검수 완료 | 반품 상품의 상태를 확인하는 실물 검수가 완료된 활동입니다. NetSuite에는 표준 'Inspection' 객체가 없으므로, 일반적으로 Return Authorization 또는 Item Receipt의 사용자 지정 필드나 상태 변경을 바탕으로 추론합니다. | ||
| 중요한 이유 검수는 병목이 되는 경우가 많습니다. 검수 완료 시간을 추적하면 담당자별 성과와 판단의 일관성, 이후 환불 승인에 미치는 영향을 분석할 수 있습니다. 확보 방법 시스템 분석이 필요합니다. ReturnAuthorization 레코드의 사용자 지정 'Inspection Status' 필드 변경으로 추론할 수 있지만, 기록되지 않는 오프라인 절차일 수도 있습니다. 기록 Return Authorization 또는 Item Receipt의 사용자 지정 상태 필드 변경을 바탕으로 추론합니다. 이벤트 유형 inferred | |||
데이터 추출 안내
단계
- Saved Search 생성 화면으로 이동: NetSuite에 로그인합니다. Reports > New Search로 이동합니다. New Saved Search 페이지에서 'Transaction'을 클릭합니다.
- 기본 조건 설정: Saved Search 설정 페이지의 'Criteria' 탭에서 'Standard' 하위 탭을 열고 다음 필터를 설정해 Return Authorization 레코드만 조회합니다.
TypeisReturn AuthorizationMain LineisYesDate Created필터를 추가하고 원하는 기간을 설정합니다. 예: '최근 3개월'. 데이터 양을 관리하는 데 중요합니다.
- 속성 결과 열 설정: 'Results' 탭으로 이동합니다. 이벤트 로그의 속성으로 사용할 다음 필드를 추가합니다. 필요하면 'Custom Label'로 알아보기 쉽게 이름을 바꿉니다.
- Case ID:
Document Number또는TranID(Custom Label: ReturnCaseId) - 반품 상태:
Status(Custom Label: ReturnAuthorizationStatus) - 처리 담당자:
Created By또는 해당하는 사용자 지정 필드 (Custom Label: ProcessingAgent) - 부서:
Department(Custom Label: Department) - 반품 유형:
[Your Return Reason Field]같은 사용자 지정 필드 (Custom Label: ReturnType) - 환불 금액:
Amount(Custom Label: ActualRefundAmount)
- Case ID:
- 이벤트 타임스탬프용 수식 열 추가: 가장 중요한 단계입니다. 12개 활동 각각에 'Formula (Date/Time)' 열을 추가합니다. 각 수식은 CASE 문을 사용해 해당 이벤트가 발생한 경우에만 타임스탬프를 반환합니다. 활동별 수식은 'query' 섹션을 참조하세요.
- 고정 열 추가: 결과에 'Formula (Text)' 열 두 개를 추가합니다.
SourceSystem에는'NetSuite'수식을 사용합니다.LastDataUpdate에는{today}처럼 실행 날짜를 나타내는 수식을 사용합니다. 정확한 타임스탬프가 필요하면 내보내기 시간을 사용합니다.
- 검색 저장 및 내보내기: 검색에 'ProcessMind Returns Extraction'처럼 알아보기 쉬운 이름을 지정합니다. 'Save & Run'을 클릭합니다. 결과가 표시되면 Export 아이콘을 클릭하고 'CSV'를 선택합니다.
- 데이터를 이벤트 로그로 변환: 내보낸 CSV는 반품 사례마다 한 행이 있고 이벤트 타임스탬프별 열이 여러 개인 'wide' 형식입니다. 이를 'long' 형식의 이벤트 로그로 변환해야 합니다. Microsoft Excel Power Query(Unpivot Columns), Python 또는 다른 스크립트 도구를 사용할 수 있습니다.
- CSV의 각 행에서 값이 있는 이벤트 타임스탬프 열마다 새 행을 만듭니다.
- 변환된 표에는
ReturnCaseId,ActivityName,EventTimestamp같은 열이 있어야 합니다.ActivityName은 원본 타임스탬프 열의 헤더(예: 'Return Authorization Created')에서 가져오고,EventTimestamp는 해당 열의 값으로 설정합니다.
- 업로드 준비 완료: 최종 CSV에 필수 헤더
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdate와 권장 속성이 포함되어 있는지 확인합니다. 이제 ProcessMind에 업로드할 수 있습니다.
구성
- 검색 유형: 저장된 검색은
거래검색이어야 합니다. - 기간: Return Authorization의
Date Created필드에 기간 필터를 적용해야 합니다. 데이터 완전성과 성능을 고려해 3~6개월을 권장합니다. - 기본 필터: 반품 케이스마다 최초 레코드 하나만 가져오려면
유형이Return Authorization이고Main Line이예인 항목만 검색해야 합니다. - 사용자 지정 필드: 특히 '품목 검사 완료'와 같은 개념적 이벤트나 '반품 유형' 속성을 정확히 추출하려면 조직에서 거래 레코드에 사용자 지정 필드를 어떻게 사용하는지가 중요합니다. 제공된 수식에는
{custbody_...}와 같은 자리표시자가 포함되어 있으며, NetSuite 설정에 맞게 수정해야 합니다. - 사용자 권한: 검색을 실행하는 사용자에게는 Return Authorization, Item Receipt, Credit Memo, Customer Refund, Sales Order 등 관련된 모든 거래 유형의 보기 권한이 필요합니다.
- 성능: 반품 건수가 매우 많은 계정에서는 이 검색을 실행하는 데 시간이 걸릴 수 있습니다. 사용량이 적은 시간에 실행하거나 파일 캐비닛으로 자동 내보내도록 예약하는 방안을 고려합니다.
샘플 쿼리 config
This configuration represents the settings in the NetSuite Saved Search UI. The 'Results' tab should be configured with the following columns and formulas.
**Criteria Tab:**
* `Type` = `Return Authorization`
* `Main Line` = `true`
* `Date Created` = `[Specify Desired Date Range]`
**Results Tab (Columns):**
| Custom Label | Field / Formula Type | Formula / Field ID |
|---|---|---|
| `ReturnCaseId` | Formula (Text) | `{tranid}` |
| `SourceSystem` | Formula (Text) | `'NetSuite'` |
| `LastDataUpdate` | Formula (Date/Time) | `{today}` |
| `ReturnAuthorizationStatus` | Field | `Status` |
| `ProcessingAgent` | Field | `Created By` |
| `Department` | Field | `Department` |
| `ReturnType` | Field | `{custbody_return_reason}` |
| `ActualRefundAmount` | Field | `Amount` |
| `CycleTime` | Formula (Numeric) | `CASE WHEN {status} = 'Closed' THEN {lastmodifieddate} - {datecreated} ELSE NULL END` |
| `Activity_ReturnAuthorizationCreated` | Field | `Date Created` |
| `Activity_ReturnAuthorizationApproved` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Pending Receipt' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ReturnAuthorizationRejected` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Rejected' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` |
| `Activity_ItemReceived` | Formula (Date/Time) | `{applyingtransaction.trandate}` |
| `Activity_ItemInspected` | Formula (Date/Time) | `CASE WHEN {custbody_inspection_status} = 'Complete' THEN {custbody_inspection_date} ELSE NULL END` |
| `Activity_CreditMemoCreated` | Formula (Date/Time) | `{createdfrom.trandate}` |
| `Activity_CreditMemoApproved` | Formula (Date/Time) | `MIN(CASE WHEN {createdfrom.systemnotes.newvalue} = 'Open' AND {createdfrom.systemnotes.field} = 'Status' THEN {createdfrom.systemnotes.date} ELSE NULL END)` |
| `Activity_RefundProcessed` | Formula (Date/Time) | `{createdfrom.appliedtotransaction.trandate}` |
| `Activity_CreditMemoApplied` | Formula (Date/Time) | `CASE WHEN {createdfrom.status} = 'Fully Applied' AND {createdfrom.appliedtotransaction.type} = 'Invoice' THEN {createdfrom.appliedtotransaction.date} ELSE NULL END` |
| `Activity_ExchangeOrderCreated` | Formula (Date/Time) | `{custbody_exchange_order.trandate}` |
| `Activity_CustomerNotified` | Formula (Date/Time) | `MAX({messages.messagedate})` |
| `Activity_ReturnAuthorizationClosed` | Formula (Date/Time) | `MIN(CASE WHEN {systemnotes.newvalue} = 'Closed' AND {systemnotes.field} = 'Status' THEN {systemnotes.date} ELSE NULL END)` | 단계
- SuiteAnalytics Connect 활성화: NetSuite 계정에 SuiteAnalytics Connect 라이선스가 있는지 확인합니다. 관리자는 Setup > Company > Enable Features > Analytics에서 기능을 활성화해야 합니다.
- 사용자 권한 부여: 연결에 사용할 사용자 역할에 'SuiteAnalytics Connect' 권한을 부여합니다. 이 사용자에게는 조회 대상인 거래, 직원, 고객 등의 레코드 조회 권한도 필요합니다.
- ODBC 드라이버 설치: NetSuite의 SuiteAnalytics Connect 다운로드 페이지에서 운영 체제에 맞는 NetSuite ODBC 드라이버를 다운로드해 설치합니다.
- DSN 설정: 쿼리를 실행할 컴퓨터에 Data Source Name(DSN)을 설정합니다. Service Data Source, Server Hostname, Port, Role ID, Account ID와 인증 정보를 입력합니다.
- SQL 클라이언트 연결: DBeaver 또는 Microsoft SQL Server Management Studio 같은 SQL 클라이언트에서 설정한 DSN을 사용해 NetSuite에 연결합니다.
- SQL 쿼리 준비: 제공된 SQL 쿼리를 클라이언트에 복사합니다. 이 쿼리는 반품 및 환불 프로세스의 주요 이벤트를 추출하도록 작성되었습니다.
- 쿼리 사용자 지정: 쿼리의 자리표시자 값을 수정합니다. 최소한
ReturnAuthorizations공통 테이블 식(CTE)의 날짜 범위를 원하는 기간으로 변경해야 합니다. NetSuite 설정에 따라CUSTBODY_RETURN_TYPE같은 사용자 지정 필드 이름이나 특정 상태 값도 조정해야 할 수 있습니다. - 쿼리 실행: 사용자 지정한 SQL 쿼리를 NetSuite 데이터베이스 복제본에서 실행합니다. 실행 시간은 날짜 범위와 데이터 양에 따라 달라질 수 있습니다.
- 데이터 검토 및 내보내기: 쿼리가 완료되면 결과가 올바른지 검토합니다. 전체 결과를 CSV 파일로 내보냅니다.
- 업로드 준비 완료: CSV 파일의 헤더가 필수 속성인
ReturnCaseId,ActivityName,EventTimestamp,SourceSystem,LastDataUpdate등과 일치하는지 확인합니다.EventTimestamp열의 날짜 및 시간 형식이 일관적인지도 확인합니다. 이제 ProcessMind에 업로드할 수 있습니다.
구성
- 사전 요구 사항: SuiteAnalytics Connect 추가 모듈이 포함된 NetSuite 라이선스가 필요합니다. 연결을 실행하는 사용자에게는 'SuiteAnalytics Connect' 권한이 있는 역할과 거래, 엔터티, 직원 레코드에 대한 읽기 권한이 있어야 합니다.
- 데이터 소스 설정: NetSuite ODBC 드라이버를 사용해 DSN(Data Source Name)을 설정해야 합니다. Account ID, Role ID와 인증 정보가 필요합니다. 프로덕션 환경의 서비스 호스트는 일반적으로
odbcserver.netsuite.com입니다. - 날짜 범위 필터링: Return Authorization을 선택하는 초기 CTE에 날짜 범위 필터를 반드시 적용해야 합니다. 필터가 없으면 모든 반품 데이터를 가져오려 하므로 쿼리 실행이 매우 느려지거나 시간 초과가 발생할 수 있습니다. 초기 분석에는 3~6개월 범위를 권장합니다.
- 주요 거래 유형: 쿼리는 ReturnAuthorization, ItemReceipt, CreditMemo, CustomerRefund, SalesOrd(교환용) 등 주요 거래 유형을 대상으로 합니다. 프로세스에서 이러한 표준 객체를 사용하는지 확인하세요.
- 사용자 지정 필드 의존성: '상품 검수' 같은 활동과 '반품 유형' 같은 속성은 사용자 지정 필드에 기록되는 경우가 많습니다. 제공된 쿼리에는
CUSTBODY_INSPECTION_STATUS및CUSTBODY_RETURN_TYPE같은 자리표시자가 있습니다. 시스템에서 올바른 사용자 지정 필드 ID를 확인해 쿼리에 반영해야 합니다. - 성능 고려 사항: 이 쿼리는 여러 조인과 대규모
UNION ALL구조를 포함해 복잡합니다. 시스템 성능에 미치는 영향을 줄이려면 사용량이 적은 시간대에 실행하세요. 데이터가 매우 많다면 짧은 기간 단위로 쿼리를 실행한 뒤 결과를 합치는 방법을 고려하세요.
샘플 쿼리 sql
WITH ReturnAuthorizations AS (
SELECT
T.TRANSACTION_ID AS ReturnCaseId,
T.TRANDATE
FROM
TRANSACTION T
WHERE
T.TYPE = 'ReturnAuthorization'
AND T.TRANDATE BETWEEN TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD') AND TO_DATE('[YYYY-MM-DD]', 'YYYY-MM-DD')
)
SELECT
RA.ReturnCaseId AS "ReturnCaseId",
'Return Authorization Created' AS "ActivityName",
T.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION T
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON T.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Pending Receipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Rejected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE IN ('Rejected', 'Closed')
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Received' AS "ActivityName",
IR.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION IR
INNER JOIN TRANSACTION T_RA ON IR.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON IR.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE IR.TYPE = 'ItemReceipt'
UNION ALL
SELECT
RA.ReturnCaseId,
'Item Inspected' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SN.FIELD = 'TRANSACTION.CUSTBODY_INSPECTION_STATUS' AND SN.NEW_VALUE = 'Completed'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Created' AS "ActivityName",
CM.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION CM
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON CM.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Approved' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.APPROVAL_STATUS' AND SN.NEW_VALUE = 'Approved'
UNION ALL
SELECT
RA.ReturnCaseId,
'Refund Processed' AS "ActivityName",
REF.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
ABS(REF.TOTAL) AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION REF
INNER JOIN TRANSACTION CM ON REF.APPLIED_TO_TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON REF.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE REF.TYPE = 'CustomerRefund'
UNION ALL
SELECT
RA.ReturnCaseId,
'Credit Memo Applied' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION CM ON SN.TRANSACTION_ID = CM.TRANSACTION_ID
INNER JOIN TRANSACTION T_RA ON CM.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE CM.TYPE = 'CreditMemo' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE = 'Fully Applied'
UNION ALL
SELECT
RA.ReturnCaseId,
'Exchange Order Created' AS "ActivityName",
SO.CREATED_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T_RA.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T_RA.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM TRANSACTION SO
INNER JOIN TRANSACTION T_RA ON SO.CREATED_FROM_ID = T_RA.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T_RA.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SO.CREATED_BY_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE SO.TYPE = 'SalesOrd'
UNION ALL
SELECT
RA.ReturnCaseId,
'Customer Notified' AS "ActivityName",
MSG.MESSAGE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
T.STATUS AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM MESSAGES MSG
INNER JOIN TRANSACTION T ON MSG.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON MSG.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE MSG.INCOMING = 'F'
UNION ALL
SELECT
RA.ReturnCaseId,
'Return Authorization Closed' AS "ActivityName",
SN.NOTE_DATE AS "EventTimestamp",
'NetSuite' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
SN.NEW_VALUE AS "ReturnAuthorizationStatus",
E.full_name AS "ProcessingAgent",
D.full_name AS "Department",
T.CUSTBODY_RETURN_TYPE AS "ReturnType",
NULL AS "ActualRefundAmount",
NULL AS "CycleTime"
FROM SYSTEM_NOTES SN
INNER JOIN TRANSACTION T ON SN.TRANSACTION_ID = T.TRANSACTION_ID
INNER JOIN ReturnAuthorizations RA ON T.TRANSACTION_ID = RA.ReturnCaseId
LEFT JOIN EMPLOYEE E ON SN.AUTHOR_ID = E.EMPLOYEE_ID
LEFT JOIN DEPARTMENT D ON E.DEPARTMENT_ID = D.DEPARTMENT_ID
WHERE T.TYPE = 'ReturnAuthorization' AND SN.FIELD = 'TRANSACTION.STATUS' AND SN.NEW_VALUE LIKE '%Closed%'; 시작할 준비가 되셨나요?
이 데이터 템플릿을 활용해 반품 및 환불 처리를 개선하세요. 지금 NetSuite 워크플로를 최적화해 효율과 고객 만족도를 높이세요.
반품 및 환불 프로세스를 최적화해 NetSuite 효율을 높이세요
NetSuite 반품 처리 주기를 30% 단축하세요. 지금 운영 개선을 시작하세요.
신용카드가 필요하지 않습니다 • 몇 분이면 설정할 수 있습니다