EPCIS 오류 선언 검수, 원래 입고 시각을 남기는 법

EPCIS 오류 선언은 원본에 기록된 입고 시각을 유지합니다. 일반 이벤트로 정정할 수 있는지 먼저 봅니다. 2026년 11월 10일 확인 기준입니다.

창고에 11시에 입고한 상자가 시스템에는 10시로 기록됐다고 해 보겠습니다. 다음 날 원본의 시각 오류를 발견했다면 오류 선언에도 10시를 둡니다. 발견 뒤 선언한 시각은 declarationTime에 적고, 실제 11시 입고를 표현하는 보정 이벤트를 따로 기록합니다.

원본과 오류 선언에서 무엇을 대조하나요?#

EPCIS는 공급망에서 물건에 관해 관찰한 정보를 이벤트로 공유하는 GS1 표준입니다. ErrorDeclaration은 기존 이벤트가 주장한 내용이 선언 시각부터 오류라고 밝힙니다. 선언 이벤트는 ErrorDeclaration 자체와 저장소 기록 시각인 recordTime을 제외한 모든 필드가 이전 이벤트와 같아야 합니다. 여기에는 eventTime과 eventID도 들어갑니다. 원본에 ID가 없으면 선언에도 ID가 없습니다. GS1 EPCIS §7.4.1.2

원본 이벤트는 저장소에 그대로 남습니다. 같은 관찰 필드로 조회하면 원본과 선언을 함께 찾을 수 있습니다. 저장 시각 범위나 선언 시각 필터에 따라 한쪽만 보일 수 있으므로, 업무 화면에서는 조회 범위와 현재 해석을 함께 기록합니다. correctiveEventIDs는 선언에서 보정 이벤트의 ID를 가리키는 선택 필드입니다. 별도 보정 이벤트가 있더라도 그 링크는 생략할 수 있습니다. GS1 EPCIS Workbench FAQ

입고 시각 정정을 어떻게 시험하나요?#

이 예시는 원본 조회와 보정 근거 확인을 인수 조건으로 둔 창고 화면입니다. 원본·선언 짝의 확인, 보정 근거가 도착했는지, 업무 화면을 확정할지를 따로 기록합니다. 확인한 보정 ID에는 정상 이벤트 형식과 원본을 고치는 업무 의미까지 검수한 보정 이벤트만 넣습니다.

함수 입력은 원본 일반 이벤트 한 건과 대응 후보인 오류 선언 한 건입니다. 스키마·권한·시각 형식은 앞 단계에서 검사합니다. 입력 객체는 모델의 모든 필드를 유지하고, 의미가 같은 자료형 표현과 집합 순서를 앞 단계에서 통일합니다. ID가 없는 경우 예시에서는 양쪽 모두 null로 표현합니다. 코드에는 이 정규화나 보정의 업무 의미를 확인하는 절차가 들어 있지 않습니다.

import { isDeepStrictEqual } from "node:util";

export function assessPair(original, declaration, verifiedCorrectionIds) {
  if (!original) return "hold-original";
  const { recordTime: originalRecordedAt, ...originalFields } = original;
  const { recordTime: declarationRecordedAt, errorDeclaration, ...declaredFields } =
    declaration;

  if (!isDeepStrictEqual(originalFields, declaredFields)) return "hold-pair";

  const references = errorDeclaration.correctiveEventIDs ?? [];
  if (!references.every((id) => verifiedCorrectionIds.has(id))) {
    return "pair-pending-correction";
  }
  return "pair-confirmed";
}

실제 인수표에는 원본의 관찰 시각, 선언 시각, 보정 이벤트의 시각, 조회한 범위와 최종 업무 상태를 각각 적습니다. 원본·선언에 같은 ID가 나타나는 경우를 일반 중복 제거 규칙에 넣으면 선언이 사라질 수 있습니다. 소비 화면에서 두 이벤트와 보정 관계를 함께 재현하세요. 수집기·스키마·정규화 규칙을 바꾸면 같은 표본을 다시 검수합니다.

일반 이벤트로 기록하는 편이 나은 때는 언제인가요?#

10시에 정상 입고했고 나중에 실제로 반품했다면 각 업무 단계의 일반 이벤트를 기록할 수 있습니다. 기존 이벤트의 잘못된 부분을 일반 이벤트로 표현해 이력을 바로잡을 수 있을 때도 GS1은 그 방식을 우선합니다. 업무 자체가 이후에 바뀐 경우와 기록 당시의 관찰 주장이 틀린 경우를 인수표에서 구분합니다. GS1 오류 선언 사용 예시

원본이 당장 조회되지 않더라도 오류 선언에는 원본의 관찰 정보가 들어 있어 선언을 해석할 수 있습니다. 표의 원본 확인 대기는 감사 화면의 설계 조건입니다. 조회 지연 때문에 선언을 버리면 원래 이력이 정상으로 남을 수 있습니다. 순서가 뒤바뀐 웹훅의 상태 적용은 SCM 웹훅 이벤트 순서 검수에서 다룹니다.

어떤 문서에서 기준을 확인했나요?#

• GS1 EPCIS 2.0 §7.4.1.2는 오류 선언과 원본의 일치, 선언 시각 및 보정 참조를 정의합니다. 2.0.0은 2022년 6월 22일 공개.
• GS1 EPCIS 표준 아카이브는 2.0.1 게시일을 2025년 7월 1일로 기록합니다. 이 글의 절 번호와 내용은 표지가 Release 2.0인 PDF를 기준으로 삼았습니다.
• GS1 EPCIS Workbench FAQ는 일반 이벤트가 교정할 수 있는 예시와 보정 참조의 선택 조건을 설명합니다.
• 알파카랩스 업무 자동화·API 연동은 SCM 자료의 수집·누락·중복과 운영 인수 범위를 협의하는 서비스를 안내합니다.

공개 문서는 2026년 11월 10일 확인했습니다. 표의 대기·확정 판정은 이 글의 창고 화면 예시입니다.

자주 묻는 질문#

입고 오류 선언의 인수 범위를 정할 때#