SCM 주문 상태 코드 매핑, 미등록 값을 어떻게 검수할까

2026년 11월 기준, 조회용 SCM에서 형식이 맞는 미등록 주문 상태 코드는 원천 값을 보존하고 ‘확인 대기’로 표시합니다. 출고 완료 건수에서는 제외합니다.

원천 두 곳에서 같은 ‘S’를 보냈다고 가정해 보겠습니다. 한 곳에서는 송장 생성, 다른 곳에서는 출고 완료입니다. 코드만 보고 두 주문을 모두 출고로 세면 현장에서 아직 보내지 않은 주문이 완료 목록에 들어갑니다. 검수할 때는 주문을 열어 어느 원천의 어느 필드가 그 상태를 만들었는지 확인합니다.

같은 코드를 왜 원천별로 해석할까요?#

같은 문자라도 원천과 필드가 다르면 뜻이 달라집니다. 매핑표에는 원천 시스템, 원천 필드, 원천 코드, 적용 버전, 화면 상태, 지표에 포함되는 조건을 남깁니다. 채널이나 사업장에 따라 뜻이 다르면 그 구분도 적용 범위에 넣습니다.

GS1의 CBV 2.0은 EPCIS 이벤트에서 무슨 작업이 진행됐는지 나타내는 업무 단계와 그 뒤 객체가 어떤 상태인지 나타내는 값을 구분합니다. 주문 코드표에 직접 적용할 표준 값은 각 원천의 계약에서 확인해야 합니다. 송장을 생성한 일과 물건이 실제로 출고된 상태를 나눠 보는 데 이 구분을 참고할 수 있습니다. GS1 CBV 2.0 표준

어떤 주문을 인수 표본에 넣을까요?#

이미 매핑한 주문과 예외 주문을 같은 조건으로 조회합니다. 상세 화면의 분류, 출고 완료 카드, 확인 대기 목록이 아래처럼 맞물려야 합니다. 이 예에서는 동일한 조회 범위에서 유효한 주문을 주문 단위로 셉니다.

Microsoft의 Azure REST API 지침은 확장 가능한 응답 열거값에 문서에 없던 값이 추가될 수 있다고 설명합니다. 원천이 새 값을 보낼 수 있다면, 다른 정상 주문은 계속 조회하면서 미등록 주문만 확인 대기로 남기는 동작을 시험합니다. 필수 상태 필드가 없거나 값 형식이 계약과 다르면 해당 입력을 별도 수집 오류로 분리합니다. 오류로 집계에서 빠진 주문은 대사 화면에서 이유와 함께 확인할 수 있어야 합니다. Azure REST API 지침의 열거값 항목

코드표가 바뀌면 과거 집계도 바꿔야 할까요?#

과거 보고서를 재현하려면 당시 입력 사본 또는 같은 입력을 복원할 참조값, 매핑 버전, 집계 기준 버전을 함께 남깁니다. 원천에서 뜻을 바꾼 시점이나 원천 판본을 확인해 적용할 매핑 버전을 정합니다. 수신 시각만 기준으로 삼으면 변경 전 데이터가 늦게 들어올 때 다른 뜻으로 해석될 수 있습니다.

인수 표본의 시스템 A 주문 1건을 당시 입력과 버전 1로 조회하면 출고 완료는 0건입니다. 해당 주문을 버전 2의 적용 범위에 포함해 재산출하면 1건입니다. 비교 기록에는 주문 식별자와 두 버전, 집계 차이를 남깁니다. 기존 보고서와 재산출 보고서를 구분한 뒤 갱신 여부를 결정합니다.

확인 대기를 ‘기타’ 한 칸에 넣으면 화면은 단순해집니다. 다만 운영자가 그 행을 열어 미등록과 필드 누락을 구분할 수 있어야 수정 위치를 찾습니다. 출고 완료율을 표시한다면 분모에 확인 대기 주문이 들어가는지도 정하고, 대기 건수를 함께 보여줍니다. 카드와 상세 화면이 같은 주문을 읽는지는 SCM 집계·상세 조회 검수에서, 늦게 온 이벤트가 상태를 바꾸는 문제는 SCM 웹훅 순서 역전 검수에서 다룹니다.

근거와 적용 범위#

이 글의 코드와 주문은 가상 설계 예시입니다. GS1 CBV 2.0은 2022년 6월 비준됐습니다. GS1과 Microsoft 문서는 2026년 11월 5일에 확인했습니다. 원천 API가 허용하는 값과 코드 변경 통지는 실제 공급자의 문서와 운영 계약에서 확인합니다.

알파카랩스의 SCM·쇼핑몰 통합 운영대시보드 개발 서비스는 원천별 지표 정의와 원천·화면의 표본 대사 기준을 협의합니다. 이 글은 알파카랩스가 작성한 설계 안내이며 하단에 자사 서비스 상담 링크가 있습니다.

SCM 주문 상태 코드 매핑 FAQ#

미등록 상태 코드도 조회용 데이터에 보존하나요?

원천 계약이 허용하는 형식의 미등록 값이면 조회용 사본에 그대로 보존합니다. 집계용 상태는 확인 대기로 분류하고, 원천 코드와 적용한 매핑 버전을 상세에서 확인할 수 있게 합니다.

미등록 코드와 상태 필드 누락을 화면에서 합쳐도 되나요?

요약 카드에서 같은 확인 대기로 묶을 수 있습니다. 상세에서 원천이 보낸 값과 선택 필드가 빠졌다는 사유는 구분해야 합니다. 필수 필드 누락은 수집 오류로 분리합니다. 수정할 대상이 코드표인지 수집 경로인지 달라지기 때문입니다.

확인 대기 주문을 전체 주문 수에 포함하나요?

유효한 주문이라면 전체 주문 수에 포함할 수 있습니다. 상태가 확정된 주문 수와 확인 대기 건수를 따로 보여 주고, 출고 완료율에 사용하는 분모를 표시합니다.

과거 보고서는 최신 코드표로 다시 계산하나요?

재현 목적이면 당시 입력과 원래 적용한 매핑 및 집계 기준 버전을 사용합니다. 과거 기준까지 바꾸기로 했다면 적용 범위와 새 버전을 명시해 다시 계산하고 기존 수치와 대조합니다.

ERP와 판매 채널에 같은 코드가 있으면 매핑을 공유해도 되나요?

원천 문서와 샘플을 대조해 업무 의미와 집계 기준이 일치하는지 확인합니다. 공통 상태로 표시하더라도 원천별 필드와 코드, 적용 버전은 구분해 남깁니다.

주문 상태 매핑 인수표 협의#

비식별 주문 표본에 원천 필드, 코드, 기대 화면 상태를 적으면 정상·미등록·누락·버전 변경을 담은 인수표 초안 범위를 협의할 수 있습니다. 소요 시간은 원천 수와 표본 범위를 확인한 뒤 정합니다.