GDST 1.1 인도네시아 매핑: 구매자 준비된 EPCIS 파일 7단계

인도네시아에 특화된 실무 가이드: WPP 로그, STELINA/MDPI 기록, 및 공장 문서를 GDST 1.1 EPCIS 파일로 전환하는 방법. WPP-FAO 매핑, 선박 ID 옵션, CSV→JSON 흐름 및 이벤트 예시 포함.

구매자가 단순히 “GDST 1.1”을 요청했다면, 내일 당장 소프트웨어를 구입할 필요는 없습니다. 인도네시아에서 이미 보관 중인 기록들( WPP-NRI 구역, 항해 로그, 상륙 노트, BKIPM 문서, 공장 생산 시트)로도 구매자 요구에 부합할 수 있습니다. 우리는 이 방식으로 참치, 도미, 새우 및 혼합 암초종에 대한 GDST 파일을 제공해 왔습니다. 아래는 우리가 정확히 어떻게 매핑하는지입니다.

구매자 준비된 GDST 파일의 세 가지 핵심

신뢰할 수 있는 출처 식별자. 승선원이 실제로 소지하거나 면허에 기재된 선박 ID를 사용하세요. 서류에서 찾을 수 있는 양식 수확 ID를 사용하세요. 문서에 전혀 나타나지 않는 ID를 새로 만들어 쓰지 마세요.
명확한 로트(lot) 논리. 수취 시점과 트리밍/포장 전후로 로트를 어떻게 추적할지 결정하세요. 분할/병합을 서류로 설명할 수 없다면 EPCIS에서 검증되지 않습니다.
적절한 EPCIS 패키징. 구매자들은 점점 EPCIS 2.0 JSON-LD를 원합니다. 엑셀(Excel)부터 시작할 수 있지만, 나중에 이벤트로 1:1 변환되도록 열을 설계하세요.

실무적 요점: JSON을 건드리기 전에 로트 정의와 각 KDE를 증명하는 문서가 무엇인지 확인하세요. 그러면 80%는 완료된 것입니다.

구매자가 실제로 요구하는 최소 KDE는 무엇인가?

인도네시아에서 두 가지 일반적인 시나리오를 봅니다.

야생 포획(자연산) 참치, 도미, 암초종
- 종(학명 + 통용명), 생산 방식 = wild-capture(자연산)
- 어획 구역을 FAO 코드로 표기, 어구 유형
- 선박 식별자 및 기국(Flag state). 항해 시작/종료 날짜
- 상륙 날짜 및 항구. 환적(transshipment)이 있다면 운송 선박 및 날짜
- 가공업체 로트/배치 코드, 생산 날짜, 수량 및 단위(UoM)
- 시설 식별자(보유 시 GLN 또는 공장 승인 번호)
- 인증서/허가서 참조(관련 있는 경우)
양식 바나메이 새우(Litopenaeus vannamei)
- 종, 생산 방식 = 양식(aquaculture)
- 양식장 식별자(연못/클러스터), 수확 날짜, 위치(가능하면 주/좌표)
- 구매자가 요구하면 치어장(hatchery) 및 사료 공급자 ID
- 가공업체 로트/배치 코드, 생산 날짜, 수량
- 시설 식별자

구매자가 엄격한 GDST 요구를 하는 경우: 각 이벤트에 대한 고유 ID, 표준 시간대(time zone), 비즈니스 단계(business step), 그리고 이벤트가 발생한 지점(readPoint)을 추가하세요. 이러한 정보가 포함되면 구매자들이 더 빠르게 진행하는 경향이 있음을 확인했습니다.

구매자가 수용하는 WPP-NRI에서 FAO로의 매핑

귀하가 WPP-NRI를 기록하면 구매자는 FAO 코드를 원합니다. 인도네시아 GDST 파일에서 널리 사용되는 단순한 매핑은 다음과 같습니다:

WPP 571, 572, 573 → FAO 57 (Indian Ocean, Eastern)
WPP 711, 712, 713, 714, 715, 716, 717 → FAO 71 (Pacific, Western Central)
WPP 718 → 종종 혼재됩니다. Timor/Sawu 해역은 일반적으로 FAO 57로, Arafura는 일반적으로 FAO 71로 여겨집니다. 좌표가 없다면 많은 구매자가 메모와 함께 FAO 57과 71을 모두 기재하는 것을 수용합니다.

인도네시아 지도를 강조하여 동부 인도양(Indian Ocean, Eastern)과 서중태평양(Pacific, Western Central)을 서로 다른 색 영역으로 표시하고, Timor, Sawu, Arafura 해역 주변에는 혼재(overlap)를 보여 모호한 매핑을 나타낸 이미지; 손낚시 보트와 항만 크레인 실루엣이 어업 문맥을 제공함.

비직관적인 두 가지 팁:

상륙 노트에 좌표나 명명된 어장(named ground)이 있으면 포함하세요. WPP 718과 같이 모호한 경우에는 위도/경도를 추가하면 빠르게 해결됩니다.
원래의 WPP 코드는 "notes" 필드에 보관하세요. 감사관들은 원본 참조를 보는 것을 좋아합니다.

특정 어업에 대한 매핑의 간단한 점검이 필요하신가요? WhatsApp으로 문의하기.

우리 선박에는 IMO 번호가 없습니다. 어떤 ID를 사용할 수 있나요?

실무에서 인도네시아의 손낚시/당일형 소형 선박은 거의 IMO가 없습니다. GDST 1.1은 여러 식별자 유형을 허용합니다:

국가 등록 또는 면허 번호(예: MMAF 문서)
무선 호출부호(IRCS) 또는 MMSI(가능한 경우)
프로그램이나 등록부를 통해 부여된 경우 UVI(Unique Vessel Identifier)
EU 기국 선박의 경우 CFR(인도네시아 연안 선단에서는 드뭅니다)

우리의 규칙: 상륙 노트나 면허에 실제로 나타나고 연도별로 안정적인 식별자를 선택하세요. MDPI가 관리하는 FIP의 소형선박은 프로그램에서 사용되는 선박 코드를 사용하고, 해당 코드를 노트에 있는 종이 면허와 연결하세요.

Excel/CSV로 시작하고 나중에 EPCIS로 전환할 수 있나요?

예. 권장합니다. 변환이 기계적으로 이뤄지도록 EPCIS 이벤트를 그대로 반영한 스프레드시트를 설계하세요.

클린 변환이 가능한 최소 열(컬럼):

eventType, eventTime, timeZone, bizStep, disposition, readPointId
inputLot, inputQty, inputUoM, outputLot, outputQty, outputUoM
species, productionMethod, FAOArea, gearType, vesselId, flagState
landingPort, landingDate, farmId, harvestDate
facilityId, processType (peeling, filleting), certificateRefs, notes

그런 다음 EPCIS 2.0 JSON-LD로 변환하세요. 참치 로트 수취를 위한 매우 단순한 ObjectEvent 예시는 다음과 같습니다:

{
  "@context": [
    "https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld",
    {"gdst": "https://traceability-dialogue.org/ontologies/gdst#"}
  ],
  "type": "EPCISDocument",
  "schemaVersion": "2.0",
  "epcisBody": {
    "eventList": [
      {
        "type": "ObjectEvent",
        "eventTime": "2025-08-01T07:15:00+07:00",
        "eventTimeZoneOffset": "+07:00",
        "action": "observe",
        "bizStep": "receiving",
        "disposition": "in_progress",
        "readPoint": {"id": "urn:epc:id:sgln:8999999.00001.0"},
        "quantityList": [{
          "epcClass": "urn:epc:class:lgtin:08999999.00001.20250801TUNALOT01",
          "quantity": 1200,
          "uom": "KGM"
        }],
        "gdst:kde": {
          "gdst:species": "Thunnus albacares",
          "gdst:productionMethod": "wild-capture",
          "gdst:FAOArea": ["71"],
          "gdst:gearType": "HANDLINE",
          "gdst:vesselId": "ID-BA-12345",
          "gdst:flagState": "IDN",
          "gdst:landingPort": "Bitung",
          "gdst:landingDate": "2025-07-31"
        }
      }
    ]
  }
}

우리는 이와 유사한 접근을 소매 배송 예(예: 그루퍼 필레(IQF))와 참치 사쿠(스시 등급) 같은 사시미 프로그램에 적용했습니다.

블렌드(혼합)나 분할이 있는 껍질 제거/트리밍(peeling/trimming)을 어떻게 표시하나요?

TransformationEvent를 사용해 블렌딩과 수율(yield)을 표현하세요. 입력은 원료 로트이고 출력은 가공된 로트입니다.

예: 두 개 연못(pond) 수확분을 혼합하여 하나의 완제품 로트로 만드는 새우 껍질 제거 예시입니다.

{
  "type": "TransformationEvent",
  "eventTime": "2025-08-02T10:00:00+07:00",
  "eventTimeZoneOffset": "+07:00",
  "bizStep": "processing",
  "readPoint": {"id": "urn:epc:id:sgln:8999999.00001.0"},
  "inputQuantityList": [
    {"epcClass": "urn:epc:class:lgtin:08999999.00001.20250801POND01", "quantity": 800, "uom": "KGM"},
    {"epcClass": "urn:epc:class:lgtin:08999999.00001.20250801POND02", "quantity": 600, "uom": "KGM"}
  ],
  "outputQuantityList": [
    {"epcClass": "urn:epc:class:lgtin:08999999.00001.20250802SHRIMPPEELED01", "quantity": 1000, "uom": "KGM"}
  ],
  "gdst:kde": {
    "gdst:processingType": "peeling",
    "gdst:productionMethod": "aquaculture",
    "gdst:farmIds": ["FARM-A-01","FARM-B-07"],
    "gdst:harvestDates": ["2025-07-29","2025-07-30"]
  }
}

분할(splits)은 입력 하나에 출력 여러 개인 동일한 이벤트 타입입니다. 출력 로트 코드는 라벨과 추적 가능하도록 유지하세요.

구매자에게 이메일을 보내기 전에 빠르게 검증하는 방법

두 단계 점검을 권장합니다:

스키마 검증(Schema validation). EPCIS 2.0 JSON-LD로 유효한지 확인하세요. 어떤 JSON Schema 검증기든 로컬에서 EPCIS 2.0 스키마를 실행할 수 있습니다. 스크립트를 사용하는 경우 검증에 실패하면 빌드를 실패 처리하세요.
GDST 비즈니스 규칙(GDST business rules). 제품 유형과 이벤트별로 KDE 존재 여부를 확인하세요. 예를 들어, 야생 포획 이벤트는 FAO 구역, 어구, 선박 ID를 반드시 포함해야 합니다.

우리가 사용하거나 관찰한 무료 옵션들:

구조 검증을 위한 JSON Schema 검증기 및 린터(linter)
이벤트와 컨텍스트를 간단히 점검할 수 있는 오픈소스 EPCIS 2.0 테스트 도구
전송 전에 이벤트별로 KDE를 확인하는 간단한 Python 또는 Node 스크립트

구매자가 자체 검사 도구를 제공하면, 파일을 보내기 전에 항상 해당 검사기를 통과시켜서 불필요한 소통을 줄이세요.

이미 수집 중인 STELINA 또는 MDPI 데이터를 GDST에서 활용할 수 있나요?

예, 활용해야 합니다. 인도네시아에서는 다음과 같이 매핑합니다:

STELINA 항해/상륙 기록: 항해 ID, 상륙 날짜/항구, 종, 수량 및 선박 면허 정보는 상륙/수취 시 ObjectEvent의 KDE가 됩니다. STELINA ID는 notes에 보관하세요.
MDPI 또는 FIP 앱: 선박 코드, 손낚시 장비, WPP, 항해 상세 정보는 어획 KDE 및 FAO 매핑에 활용됩니다. 좌표가 있으면 반드시 포함하세요.

중복 입력할 필요는 없습니다. 원본 ID를 KDE notes에 참조하면 감사관이 STELINA 또는 MDPI로 추적할 수 있습니다.

BKIPM 보건증명서(health certificate) 필드를 GDST KDE로 매핑하기

우리는 보통 다음 필드를 그대로 활용합니다:

제품 설명(Product description), HS 코드, 학명 → 종/제품 KDE
순중량(Net weight) 및 포장 유형 → 수량(quantity) 및 단위(UoM)
생산 날짜 및 로트/배치 → 로트 ID 및 가공 이벤트의 eventTime
수출업자/가공업체 승인 번호 → 시설 식별자
목적지, 컨테이너, 봉인(seal) → 물류를 포함하는 경우 선적 수준의 ObjectEvent(배송 비즈니스 단계)로 사용

특히 흥미로운 점은 BKIPM 증명서가 GDST의 체인-오브-엔드(end-of-chain) 요구를 상당 부분 이미 충족하고 있다는 것입니다. 활용하세요.

승인 지연을 초래하는 흔한 실수

WPP 718에 대한 FAO 57/71 혼동. 확실하지 않으면 좌표를 포함하거나 메모와 함께 두 FAO를 기재하세요.
어떤 문서에도 나타나지 않는 선박 ID 사용. 면허나 호출부호처럼 팀이 사진으로 증빙할 수 있는 식별자를 사용하세요.
가공 중 로트 코드가 중간에 변경됨. 트리밍으로 새로운 로트가 생성되면 TransformationEvent로 표시하세요.
시간대 누락. 인도네시아 공장에서는 항상 eventTimeZoneOffset을 설정하세요.

이 조언이 적용되는 경우(그리고 적용되지 않는 경우)

이 접근법은 인도네시아 연안 선단, 손낚시 참치, 암초 어종, 및 양식 바나메이 새우에 적합합니다. 만약 해상 환적(transshipment-at-sea) 또는 원양 선단(distant-water fleets)을 다루는 경우에는 운송 선박과 RFMO 보고를 위한 추가 KDE가 필요할 가능성이 높습니다. 품목 수준(item-level) 직렬화(serialization)를 포함해 소매까지 전체 체인을 다루려면 본 가이드를 넘어 라벨 통합(label integration)이 필요합니다.

CSV 열 구조의 간단한 검토와 참치 또는 새우에 맞춘 붙여넣기용 EPCIS 템플릿을 원하시면, 이메일로 문의하기.

최종 요약

신뢰하는 문서부터 시작하세요. WPP 로그, STELINA/MDPI 기록, BKIPM 증명서는 GDST KDE의 90%를 채울 수 있습니다.
WPP를 FAO로 매핑할 때는 인도양에는 57, 태평양에는 71을 사용하고 WPP 718은 주의하세요.
트림, 껍질 제거, 분할 또는 혼합에는 TransformationEvent를 사용하세요. 작업장(공장)에서 발생한 일이라면 반드시 기록하세요.
전송 전에 구조와 비즈니스 규칙을 검증하세요. 처음부터 깔끔한 파일은 구매자들의 처리를 빠르게 합니다.

준비가 되면, 귀하의 GDST 페이로드는 사시미 등급 참치 프로그램이든 냉동 소매 필레든 어떤 수출 라인과도 함께 이동할 수 있습니다. 제품 예시가 필요하다면 현재 제품 라인을 둘러보고 KDE가 포장 사양과 어떻게 정렬되는지 확인하세요. 제품 보기