GDST 1.1 印尼映射：7 步实现买家就绪的 EPCIS 文件

一份面向印尼的实用操作手册，教你如何将 WPP 日志、STELINA/MDPI 记录和工厂纸质文件转为买家可接受的 GDST 1.1 EPCIS 文件。包含 WPP 到 FAO 的映射、船只 ID 选项、CSV 到 JSON 的流程以及事件示例。

如果买家只是要求“GDST 1.1”，你不需要马上明天就购买软件。你可以利用在印尼已经保留的记录实现面向买家的就绪：WPP‑NRI 区域、出航日志、登陆单、BKIPM 文件和工厂生产记录表。我们已经通过这种方式为金枪鱼、鲷鱼、虾和混合礁区物种交付过 GDST 文件。下面是我们如何具体映射的说明。

买家就绪 GDST 文件的三大支柱

你可以背书的来源身份。使用船员实际携带并在许可文件中出现的船只标识。使用人们能在纸质文件上找到的养殖收获编号。不要发明在任何文件中从未出现过的编号。
清晰的批次逻辑。在收货和修整/包装过程中，决定如何追踪批次。如果你无法在纸面上解释一次拆分/合并的来龙去脉，它在 EPCIS 中就不会通过验证。
规范的 EPCIS 打包。买家日益要求 EPCIS 2.0 JSON‑LD。你可以先从 Excel 开始，但在设计列时要确保它们以后可以 1:1 转换为事件。

实用结论：在你动手写 JSON 之前，先确认你的批次定义以及哪一份文件可以证明每一个 KDE（关键数据元素）。这样你就已经完成了 80%。

买家实际要求的最低 KDE（关键数据元素）有哪些？

我们在印尼看到两种常见场景。

野生捕捞的金枪鱼、鲷鱼、礁区鱼类
- 物种（学名 + 通用名）、生产方式 = wild-capture（野生捕捞）
- 捕捞区域以 FAO 代码表示，渔具类型
- 渔船标识和旗国。出航/结束日期
- 登陆日期和港口。如发生转运，记录承运船及日期
- 加工厂的批次/批号、生产日期、数量及计量单位
- 设施标识（如果有 GLN 则使用，或使用工厂批准编号）
- 证书/许可参考（在相关情况下）
养殖白对虾（vannamei）
- 物种，生产方式 = aquaculture（养殖）
- 养殖场站点标识（池塘/簇），收获日期，位置（省/坐标，如可用）
- 如果买家要求，提供苗场和饲料供应商的标识
- 加工厂的批次/批号、生产日期、数量
- 设施标识

如果你的买家严格要求 GDST，请补充：每个事件的唯一 ID、时区、业务步骤（business step）以及 readPoint（事件发生点）。我们的经验是，当这些信息齐全时，即便买家节奏很快，验证也更顺利。

买家接受的 WPP‑NRI 到 FAO 的映射

你记录的是 WPP‑NRI，买家要 FAO。以下是在印尼 GDST 文件中常用且被广泛接受的简单映射：

WPP 571、572、573 → FAO 57（印度洋东部）
WPP 711、712、713、714、715、716、717 → FAO 71（太平洋西中部）
WPP 718 → 常常是混合区。帝汶/萨乌（Timor/Sawu）海域通常归 FAO 57；阿拉富拉（Arafura）海域通常归 FAO 71。如果你没有坐标，许多买家接受同时列出 FAO 57 和 71 并附注说明。

突出显示印度洋东部和西中部太平洋为不同颜色区，并在帝汶、萨乌和阿拉富拉海域周边显示混合重叠以示映射模糊；小型手线船和港口起重机的剪影提供渔业语境的印度尼西亚地图。

两个不太明显的提示：

如果你的登陆单上有坐标或命名的渔场，务必包含它们。对于模糊的 WPP 718 情况，添加经纬度后能快速解决问题。
在“notes”（备注）字段中保留原始的 WPP 编码。审计人员喜欢看到你使用的原生参考。

需要对特定渔业的映射进行快速合理性检查？你可以在 WhatsApp 上联系我们：在 WhatsApp 上联系我们。

我们的渔船没有 IMO 编号。哪些 ID 是可以接受的？

实际上，印尼的手线/日间作业小船很少有 IMO 号。GDST 1.1 允许多种标识类型：

国家登记号或许可证编号（例如来自 MMAF 文件）
无线电呼号（IRCS）或 MMSI（如果有）
UVI（Unique Vessel Identifier），如果通过某项计划或注册分配的话
对欧盟旗船的 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（去壳、去骨等）、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）和用于刺身项目的黄鳍金枪鱼 Saku（寿司级）。

如何用 TransformationEvent 表示去壳/修整以及混配或拆分？

用 TransformationEvent 来表示混配和产出率（yield）。输入为原料批次，输出为加工后批次。

示例：去壳的虾将来自两个池塘的收获混配为一个成品批次。

{
  "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）使用相同的事件类型，输入为一个批次，输出为多个批次。确保你的输出批次代码能追溯到标签上的信息。

在发给买家之前的快速校验

我们建议两步检查：

架构验证。确认其为有效的 EPCIS 2.0 JSON‑LD。任何 JSON Schema 验证器都可以在本地运行 EPCIS 2.0 架构。如果你使用脚本，发生验证失败时应使构建退出失败。
GDST 业务规则。按产品类型和事件检查 KDE 的存在。例如，野生捕捞事件必须包含 FAO 区域、渔具和船只 ID。

我们看到或使用的一些免费选项：

用于结构的 JSON Schema 验证器和代码风格检查器
开源的 EPCIS 2.0 测试工具以对事件和上下文做合理性检查
一个简单的 Python 或 Node 脚本，在发送前断言每种事件类型所需的 KDE 是否存在

如果买家提供了他们自己的校验工具，务必先用它运行你的文件，以避免反复往返。

GDST 可以拉取我们已收集的 STELINA 或 MDPI 数据吗？

可以，而且你应该这样做。我们在印尼的映射如下：

STELINA 的出航/登陆：trip ID、登陆日期/港口、物种、数量和船只许可证信息可作为登陆/收货时 ObjectEvent 的 KDE。在备注中保留 STELINA ID。
MDPI 或 FIP 应用：船只代码、手线渔具、WPP 和出航细节为你的捕捞 KDE 和 FAO 映射提供数据。如果存在坐标，请包含它们。

你无需重复录入。在 KDE 备注中引用原始 ID，使审计人员可以追溯到 STELINA 或 MDPI。

将 BKIPM 卫生证书字段映射到 GDST KDE

我们经常直接提取这些字段：

产品描述、HS 编码、学名 → species/产品 KDE
净重和包装类型 → 数量和计量单位
生产日期和批次/批号 → 批次 ID 和加工事件的 eventTime
出口商/加工厂批准编号 → 设施标识
目的地、集装箱和封条 → 如果包含物流信息，则作为运输层级的 ObjectEvent（shipping bizStep）

有意思的是，BKIPM 证书已经覆盖了链终端所需的许多 GDST 项目。好好利用它。

常见错误会延缓审批的情况

对 WPP 718 的 FAO 57/71 混淆。如果不确定，请包含坐标或同时列出两者并附注说明。
在任何文件上都未出现的船只 ID。使用许可证或呼号，并要求团队拍照留证。
批次代码在加工过程中发生变化。如果修整产生了新批次，请用 TransformationEvent 显示出来。
缺少时区。印尼工厂的事件时间请始终设置 eventTimeZoneOffset。

何时适用（何时不适用）

这种方法适用于印尼沿海船队、手线金枪鱼、礁区鱼类以及养殖白对虾。如果你处理海上转运或远洋船队，可能需要额外的 KDE 来记录承运船和 RFMO 报告。若要实现从全链到零售的逐件序列化，你还需要在本指南之外进行标签整合。

如果你希望我们快速审阅你的 CSV 列并提供针对金枪鱼或虾的可复制粘贴 EPCIS 模板，请通过电子邮件联系我们：通过电子邮件联系我们。

最终要点

从你信任的文件开始。WPP 日志、STELINA/MDPI 记录和 BKIPM 证书可以填充 90% 的 GDST KDE。
使用 57 映射印度洋、71 映射太平洋来将 WPP 转为 FAO，并对 WPP 718 保持关注。
对于任何修整、去壳、拆分或混配，使用 TransformationEvent。如果它发生在你的作业现场，就务必展示出来。
发送前验证结构和业务规则。当文件第一次就干净时，买家处理会更快。

当你准备好时，你的 GDST 有效载荷可以随任何出货线路一同传输，无论是刺身级金枪鱼项目，还是冷冻零售鱼片。如果你需要产品示例，可浏览我们的现有产品并查看 KDE 与包装规范的对齐情况。查看我们的产品。