쇼핑몰 반품 현황 대시보드 개발: 회수·검수·환불 상태 확인

쇼핑몰 반품 현황 대시보드 개발은 여러 판매 채널의 반품 접수, 회수, 검수와 환불 상태를 공통 기준으로 조회하고 미확인 건을 따로 표시하는 데서 시작합니다. 원천별 확정 시점과 담당자를 기록해 현황을 대사하세요. 환불 승인·결제 취소·재고 원장 수정은 조회와 별도로 정할 개발 범위입니다.

판매 채널 관리자에는 반품이 접수됐지만 택배사에는 아직 회수 지시가 없고, 창고는 이미 물품을 받았는데 쇼핑몰 화면에는 배송 중으로 남을 수 있습니다. 담당자가 서로 다른 화면에서 각 상태를 확인해야 한다면 어느 원천이 어떤 사실을 알려주는지부터 나눕니다. 고객이 반품을 신청한 시각과 실제 상품을 받은 시각, 환불이 승인된 시각도 같은 사건이 아닙니다.

소규모 운영팀이라면 각 채널의 기본 보고서와 공통 스프레드시트를 먼저 비교해 보세요. 거래량이 적고 담당자가 매일 확인 대상을 명확히 인계할 수 있다면 새 개발 없이도 충분할 수 있습니다. 채널별 표가 자주 어긋나 누가 회수·검수·환불을 맡는지 찾기 어렵다면 기존 시스템을 유지한 채 조회 화면을 도입하는 방향을 검토할 수 있습니다.

대시보드의 단위는 반품 요청 1건인지 주문 상품행인지 먼저 결정합니다. 한 주문에서 셔츠 두 개 중 한 개만 반품할 수 있으므로 주문 전체를 하나의 반품 완료로 처리하면 수량이 어긋납니다. 이 글의 표본은 설명을 위해 주문당 단일 상품, 반품 요청당 하나의 행이라고 가정합니다. 실제로는 주문행·반품행과 수량, 원천 채널과 처리 버전을 함께 확인해야 합니다.

이 글의 회사와 주문·상태·수량은 실제 고객 사례가 아닌 가상 예시입니다. 특정 채널과 택배사에서 동일한 상태 코드나 API를 제공한다고 가정하지 않습니다. 개인정보가 들어간 원본을 외부에 공유하기보다 주문 식별자와 연락처를 가린 표본으로 필요한 필드와 조회 권한을 먼저 합의합니다.

공식 문서가 설명하는 범위와 적용 한계#

Microsoft Dynamics 365 Commerce 문서는 반품 거래를 처리할 때 반품 상품과 사유, 결제 수단 등 제품에서 제공하는 절차를 설명합니다. 별도 문제 해결 문서는 환불 처리가 거절될 수 있는 경우를 다룹니다. 이는 해당 제품과 결제 흐름에 관한 설명이며 국내 모든 채널의 반품 상태나 환불 순서가 같다는 뜻이 아닙니다. 아래 공통 상태표와 네 건의 수량은 기존 제품 설정이나 특정 고객 납품 실적이 아닌 가상 설계 예시입니다.

• Microsoft Learn: POS 반품 처리: 반품 상품과 사유를 다루는 제품별 예시입니다.
• Microsoft Learn: 반품 환불 거절 문제: 환불 처리 실패를 별도로 확인해야 하는 제품별 사례입니다.

원천·권한·실패 처리를 업무별로 나눕니다#

판매 채널의 반품 요청 ID, 원 주문번호, 주문 상품행, 수량과 상태 갱신 시각을 연결할 수 있는지 확인합니다. 택배사 송장과 창고 수령 번호가 주문번호와 다르다면 승인된 연결 키를 정합니다. 채널마다 옵션 코드나 부분 반품 표시 방식이 다르면 원천별 매핑표와 유효 시점을 보존하고, 대응값이 없을 때 임의로 완료로 바꾸지 않습니다.

상태의 정본은 단계별로 다를 수 있습니다. 접수 취소는 판매 채널, 실제 물품 수령은 창고, 환불 성공은 결제 주체의 확인이 필요할 수 있습니다. 이 구분은 일반적인 설계 선택지이며 실제 사용 중인 제품과 계약이 제공하는 데이터를 확인해야 합니다. 서로 다른 상태가 동시에 보이면 한쪽을 덮어쓰지 말고 각각의 원천과 기준 시각을 보여줍니다.

고객 연락처, 주소, 결제 정보가 화면과 다운로드에 모두 필요한지 먼저 판단합니다. 반품 현황만 보는 담당자에게 필요한 최소 필드를 정하고, 다른 채널이나 거래처 데이터를 볼 수 없는 권한을 부여합니다. 외부 물류업체에 공유하는 화면과 내부 CS 화면은 목적과 계약이 다르므로 접근 범위, 보관 기간과 반환·삭제 담당을 별도 합의합니다.

수집이 지연되거나 인증이 만료되면 그 채널의 반품이 없었다고 표시해서는 안 됩니다. 마지막 성공 시각, 미수집 구간, 재시도 담당과 현재 확인할 수 없는 상태를 구분합니다. 동일 이벤트가 다시 수집됐을 때 요청과 상품행이 중복 집계되지 않는지도 검수합니다. 원천에서 제공하지 않는 취소나 수정 이력을 대시보드가 자동으로 복원한다고 약속할 수는 없습니다.

오래 걸리는 반품을 찾을 때는 접수 후 경과 시간인지 마지막 상태 변경 후 경과 시간인지 별도로 표시합니다. 주말이나 판매 채널 점검 시간을 지연 시간에서 뺄지도 운영 기준으로 정합니다. 기준을 합의하지 않은 채 경과 시간이 길다는 이유만으로 특정 담당자의 잘못이나 환불 지연으로 확정하지 말고 원천 기록을 함께 확인합니다.

환불 상태가 완료로 표시되더라도 대시보드가 실제 자금 반환을 수행했다는 뜻은 아닙니다. 원천 시스템의 처리 결과를 읽어온 것이며, 채널과 결제 주체의 확정 시각이 다를 수 있습니다. 조회 화면에서 직접 환불을 실행하려면 권한, 금액 검증, 사람 승인과 실패 후 재처리를 별도의 개발·계약 범위로 설정해야 합니다.

인수 문서에는 채널별 상태 매핑표, 주문행과 반품행 연결 키, 조회 시각, 지연·누락 판정 및 장애 대응 담당을 남깁니다. 데이터를 엑셀로 내보낼 때도 화면과 같은 권한·기간 필터가 적용되는지 확인하세요. 추가 채널 도입, 원천 API 변경, 지원 시간과 유지 비용은 초기 구축과 구별해 제안받는 편이 좋습니다.

채널별 조회와 기준일은 쇼핑몰 통합 대시보드 구축에서 확인하세요. 서로 다른 원천의 상태 코드는 SCM 상태 코드 매핑 검수을 참고하세요.

네 건의 가상 반품으로 화면과 원천을 검수합니다#

R1부터 R4까지 각 한 건, 총 네 건을 준비합니다. 접수 R1·회수 중 R2·검수 중 R3·환불 완료 R4를 각각 한 건씩 배치합니다. 환불 완료만 종료로 정의한 이번 예시에서는 진행 중 3건과 종료 1건을 더해 원천 총 4건이 되는지 확인합니다. 이는 예시 분류이며 회사가 거절·철회·부분 환불을 어떻게 종료 처리하는지는 별도 합의해야 합니다.

정상 시험에서는 채널과 기간 필터를 바꿔 R1~R4의 현재 상태와 각 원천 시각을 조회합니다. 회수 완료 후 검수 중인 R3가 환불 완료로 집계되지 않는지, 실제 환불 완료 증거가 있는 R4만 종료에 포함되는지 확인합니다. 단계별 누적 진입을 따로 보여준다면 그 숫자를 현재 상태 총합과 혼동하지 않도록 표기를 분리합니다.

부분 반품 시험에서는 가상의 주문 한 건에 상품행 두 개가 있고 그중 한 행만 반품된다고 가정합니다. 원 주문 한 건 전체가 반품 완료로 표시되지 않고 해당 상품행과 수량만 조회되는지 봅니다. 반품 요청 번호가 바뀌거나 재접수된 경우에는 원 요청과 새 요청을 어떻게 연결할지 정하고 중복 합계가 생기는지 확인합니다.

예외 시험에는 회수 취소, 검수 거절, 환불 실패, 미등록 상태 코드와 수집 지연을 넣습니다. 환불 실패를 완료로 바꾸거나 미등록 코드를 임의의 단계에 넣지 않아야 합니다. 원천이 늦게 도착한 경우 원래 사건 시각과 수신 시각을 구분하고 현재 표시를 갱신한 근거를 남깁니다. 재시도 후에도 같은 사건이 중복되지 않는지 대사합니다.

인수 전에는 관리자와 CS 담당자, 외부 물류 담당자의 조회·내보내기 범위를 각각 시험합니다. 권한이 없는 사용자는 다른 채널의 고객 정보가 보이지 않아야 합니다. 미확인 요청을 누가 확인하고 잘못된 매핑을 어떻게 보류·수정하는지 문서로 인계합니다. 실제 API 접근 권한이 없어 검증하지 못한 채널은 성공이 아닌 미검증으로 남깁니다.