GDST 1.1: сопоставление для Индонезии — готовые EPCIS‑файлы за 7 шагов

Практическое, адаптированное для Индонезии руководство по превращению ваших журналов WPP, записей STELINA/MDPI и заводских документов в GDST 1.1 EPCIS‑файлы, которые принимают покупатели. Включает сопоставление WPP→FAO, варианты идентификаторов судов, поток 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, тип орудия
- Идентификатор судна и государство флага. Даты начала/окончания рейса
- Дата и порт выгрузки. Если была транcшиппинг, укажите судно‑перевозчик и дату
- Код лота/партии у переработчика, дата производства, количество и единица измерения
- Идентификатор предприятия (GLN, если он у вас есть, либо номер утверждения завода)
- Ссылки на сертификаты/разрешения (когда релевантно)
Фермерская креветка ваннамея
- Вид, метод производства = aquaculture (аквакультура)
- Идентификатор фермы (пруд/кластер), дата уборки, местоположение (провинция/координаты, если доступны)
- Идентификаторы инкубатория и поставщика корма — если покупатель запрашивает
- Код лота/партии у переработчика, дата производства, количество
- Идентификатор предприятия

Если ваш покупатель строго следует GDST, добавьте: уникальные идентификаторы для каждого события, часовую зону, бизнес‑шаг и 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 → зачастую смешанные случаи. Моря Тимор/Саву обычно относятся к FAO 57. Арафура обычно относится к FAO 71. Если у вас нет координат, многие покупатели принимают указание обеих зон FAO 57 и 71 с пометкой.

Карта Индонезии с выделением восточной части Индийского океана и западно‑центральной части Тихого океана разными цветами, с зоной перехода вокруг морей Тимор, Саву и Арафура для обозначения неоднозначности сопоставления; силуэты лодок с ручными удочками и портового крана дают контекст рыболовства.

Два неочевидных совета:

Если в вашей записи о выгрузке есть координаты или названное место лова, включите их. Неоднозначные случаи WPP 718 быстро разрешаются, когда вы добавляете широту/долготу.
Сохраните исходный WPP в поле «notes» (примечания). Аудиторам нравится видеть вашу исходную ссылку.

Нужна быстрая проверка соответствия для конкретного промысла? Вы можете связаться с нами в WhatsApp.

У наших судов нет номеров IMO. Какие идентификаторы приемлемы?

На практике индонезийские лодки для ручной ловли/дневные лодки редко имеют IMO. GDST 1.1 допускает несколько типов идентификаторов:

Национальный регистрационный или лицензионный номер (например, из документов MMAF)
Радиопозывной (IRCS) или MMSI, если есть
UVI (Unique Vessel Identifier), если назначен через программу или реестр
CFR для судов под флагом ЕС (редко для прибрежного флота Индонезии)

Наше правило: выберите тот идентификатор, который указан в вашей записи о выгрузке или в лицензии и остаётся стабильным год от года. Для малых судов в FIP, управляемых MDPI, используйте код судна, применяемый в программе, и свяжите его с вашей бумажной лицензией в примечаниях.

Можно ли начать в 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), и программ сашими, использующих Yellowfin Saku (Sushi Grade).

Как отразить очистку/обрезку с блендами или разделениями?

Отражайте смешивание и выход продукции с помощью TransformationEvent. Входы — это сырые лоты. Выходы — обработанные лоты.

Пример: очистка креветки (peeling), при которой два прудовых урожая объединяются в один готовый лот.

{
  "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 зона, орудие и идентификатор судна.

Бесплатные инструменты, которые мы используем или видим в применении:

Валидаторы и линтеры JSON Schema для проверки структуры
Открытые инструменты тестирования EPCIS 2.0 для базовой проверки событий и контекста
Простой скрипт на Python или Node для утверждения наличия KDE по типу события перед отправкой

Если ваш покупатель предоставляет собственную проверялку, всегда прогоняйте файл через неё вначале, чтобы избежать лишних итераций.

Может ли GDST использовать данные из STELINA или MDPI, которые мы уже собираем?

Да, и вы должны это делать. Мы маппим так в Индонезии:

Записи STELINA о рейсе/выгрузке: ID рейса, дата/порт выгрузки, виды, количества и лицензия судна становятся KDE для ObjectEvents при выгрузке/приёме. Сохраняйте STELINA ID в notes.
Приложения MDPI или FIP: код судна, ручная снасть, WPP и детали рейса заполняют ваши KDE по улову и FAO‑сопоставление. Если есть координаты — включайте их.

Вам не нужно вводить данные дважды. Ссылайтесь на исходные идентификаторы в примечаниях KDE, чтобы аудиторы могли отследить до STELINA или MDPI.

Сопоставление полей сертификата здоровья BKIPM с KDE GDST

Мы регулярно извлекаем эти поля напрямую:

Описание продукта, HS код, научное название → KDE вида/продукта
Нетто‑вес и тип упаковки → количество и единица измерения
Дата производства и лот/партия → идентификаторы лотов и eventTime для обработки
Номер утверждения экспортёра/переработчика → идентификатор предприятия
Пункт назначения, контейнер и пломба → событие уровня отгрузки ObjectEvent (bizStep = shipping), если вы включаете логистику

Интересно, что сертификат BKIPM уже охватывает большую часть KDE, требуемых GDST. Используйте его.

Типичные ошибки, замедляющие утверждение

Путаница FAO 57/71 для WPP 718. Если вы не уверены, включите координаты или укажите обе зоны с примечанием.
Идентификаторы судов, которые не фигурируют ни в одном документе. Используйте номер лицензии или радиопозывной, которые команда может сфотографировать.
Коды лотов меняются в процессе. Если при обрезке образуются новые лоты, указывайте их через TransformationEvent.
Отсутствие часовых поясов. Всегда указывайте eventTimeZoneOffset для индонезийских перерабатывающих предприятий.

Когда этот совет применим (и когда нет)

Этот подход работает для прибрежного флота Индонезии, ручного лова тунца, рифовой рыбы и фермерской креветки ваннамея. Если вы имеете дело с транcшиппингом в море или с дальневосточными флотами, вероятно, потребуются дополнительные KDE для судов‑перевозчиков и отчётности RFMO. Для полной прослеживаемости до розницы с сериализацией на уровне единицы товара потребуется интеграция с маркировкой, выходящая за рамки данного руководства.

Если вы хотите быстрый обзор ваших столбцов CSV и шаблон EPCIS «копировать/вставить», адаптированный для тунца или креветки, свяжитесь с нами по электронной почте.

Итоговые выводы

Начинайте с документов, которым вы доверяете. Журналы WPP, записи STELINA/MDPI и сертификаты BKIPM могут заполнить 90% KDE GDST.
Сопоставляйте WPP с FAO, используя 57 для Индийского океана и 71 для Тихого, внимательно относитесь к WPP 718.
Используйте TransformationEvents для любой обрезки, очистки, разделения или смешивания. Если это произошло у вас на площадке — зафиксируйте.
Проверяйте структуру и бизнес‑правила перед отправкой. Покупатели действуют быстрее, когда файлы чисты с первого раза.

Когда будете готовы, ваш GDST‑полезный груз может следовать с любой экспортной линией — будь то программа сашими‑класса для тунца или замороженные розничные филе. Если вам нужны примеры продуктов, просмотрите наши текущие линейки и посмотрите, как KDE соотносятся со спецификациями упаковок. Просмотреть наши продукты.