A practical, Indonesia-specific playbook to turn your WPP logs, STELINA/MDPI records, and plant paperwork into GDST 1.1 EPCIS files buyers accept. Includes WPP-to-FAO mapping, vessel ID options, CSV-to-JSON flow, and event examples.
If your buyer just asked for “GDST 1.1,” you don’t need to buy software tomorrow. You can get buyer-ready with the records you already keep in Indonesia: WPP-NRI areas, trip logs, landing notes, BKIPM docs, and plant production sheets. We’ve delivered GDST files for tuna, snapper, shrimp, and mixed-reef species this way. Here’s exactly how we map it.
The three pillars of a buyer-ready GDST file
-
Source identities you can stand behind. Use vessel IDs your crews actually carry and license. Use farm harvest IDs people can find on paper. Don’t invent IDs that never appear in your documents.
-
Clean lot logic. Decide how you track lots at receiving and through trimming/packing. If you can’t explain a split/merge on paper, it won’t validate in EPCIS.
-
Proper EPCIS packaging. Buyers increasingly want EPCIS 2.0 JSON-LD. You can start in Excel, but plan your columns so they convert 1:1 to events later.
Practical takeaway: Before you touch JSON, confirm your lot definition and what document proves each KDE. Then you’re 80% there.
What’s the minimum KDEs buyers actually ask for?
We see two common scenarios in Indonesia.
-
Wild-caught tuna, snapper, reef species
- Species (scientific + common), production method = wild-capture
- Catch area as FAO code, gear type
- Vessel identifier and flag state. Trip start/end dates
- Landing date and port. If transshipped, the carrier vessel and date
- Processor lot/batch code, production date, quantity and UoM
- Facility identifier (GLN if you have it, or plant approval number)
- Certificates/permits references (when relevant)
-
Farmed vannamei shrimp
- Species, production method = aquaculture
- Farm site identifier (pond/cluster), harvest date, location (province/coordinates if available)
- Hatchery and feed supplier IDs if requested by buyer
- Processor lot/batch code, production date, quantity
- Facility identifier
If your buyer is strict GDST, add: unique IDs for each event, time zone, business step, and readPoint (where it happened). We’ve found that when these are present, even tough buyers move fast.
WPP-NRI to FAO mapping that buyers accept
You record WPP-NRI. Buyers want FAO. Here’s a simple, widely accepted mapping used in Indonesia GDST files:
- WPP 571, 572, 573 → FAO 57 (Indian Ocean, Eastern)
- WPP 711, 712, 713, 714, 715, 716, 717 → FAO 71 (Pacific, Western Central)
- WPP 718 → Often mixed. Timor/Sawu seas are typically FAO 57. Arafura is typically FAO 71. If you don’t have coordinates, many buyers accept listing both FAO 57 and 71 with a note.
Two non-obvious tips:
- If your landing note has coordinates or a named ground, include them. Ambiguous WPP 718 cases are resolved quickly when you add lat/long.
- Keep the original WPP in a “notes” field. Auditors like to see your native reference.
Need a quick sanity check on your mapping for a specific fishery? You can Contact us on whatsapp.
Our vessels don’t have IMO numbers. What IDs are acceptable?
In practice, Indonesian handline/day boats rarely have IMO. GDST 1.1 allows several identifier types:
- National registration or license number (e.g., from MMAF documents)
- Radio call sign (IRCS) or MMSI if available
- UVI (Unique Vessel Identifier) if assigned via a program or registry
- CFR for EU-flagged vessels (rare in Indonesia coastal fleets)
Our rule: pick the identifier that appears on your landing note or license and stays stable year to year. For small boats in FIPs managed by MDPI, use the vessel code used in the program and link it to your paper license in notes.
Can we start in Excel/CSV and switch to EPCIS later?
Yes. We recommend it. Design a spreadsheet that mirrors EPCIS events so the conversion is mechanical.
Minimal columns that convert cleanly:
- 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
Then convert to EPCIS 2.0 JSON-LD. A very simple ObjectEvent for a tuna lot receipt may look like:
{
"@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"
}
}
]
}
}
We’ve used a similar approach for retail shipments like Grouper Fillet (IQF) and sashimi programs using Yellowfin Saku (Sushi Grade).
How do we show peeling/trimming with blends or splits?
Represent blending and yields with TransformationEvent. Inputs are raw lots. Outputs are processed lots.
Example: shrimp peeling that blends two pond harvests into one finished lot.
{
"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 are the same event type with one input and multiple outputs. Keep your output lot codes traceable to labels.
Quick validation before you email a buyer
We recommend a two-step check:
- Schema validation. Confirm it’s valid EPCIS 2.0 JSON-LD. Any JSON Schema validator can run the EPCIS 2.0 schema locally. If you use a script, fail the build when it doesn’t validate.
- GDST business rules. Check KDE presence by product type and event. For example, wild-capture events must have FAO area, gear, and a vessel ID.
Free options we use or see used:
- JSON Schema validators and linters for structure
- Open-source EPCIS 2.0 test tools to sanity-check events and context
- A simple Python or Node script to assert KDEs per event type before sending
If your buyer provides their own checker, always run your file through it first to avoid back-and-forth.
Can GDST pull from STELINA or MDPI data we already collect?
Yes, and you should. We map like this in Indonesia:
- STELINA trip/landing: trip ID, landing date/port, species, quantities, and vessel license become KDEs for ObjectEvents at landing/receipt. Keep the STELINA ID in notes.
- MDPI or FIP apps: vessel code, handline gear, WPP, and trip details feed your catch KDEs and FAO mapping. If coordinates are present, include them.
You don’t need to double-enter. Reference the original IDs in your KDE notes so auditors can trace back to STELINA or MDPI.
Mapping BKIPM health certificate fields to GDST KDEs
We regularly lift these fields directly:
- Product description, HS code, scientific name → species/product KDEs
- Net weight and pack type → quantity and UoM
- Production date and lot/batch → lot IDs and eventTime on processing
- Exporter/processor approval number → facility identifier
- Destination, container, and seal → shipment-level ObjectEvent (shipping bizStep) if you include logistics
What’s interesting is how much a BKIPM certificate already covers for GDST’s end of chain. Use it.
Common mistakes that slow approvals
- FAO 57/71 confusion for WPP 718. If you aren’t sure, include coordinates or list both with a note.
- Vessel IDs that don’t appear on any document. Use license or call sign your team can photograph.
- Lot codes change mid-process. If trimming creates new lots, show them with a TransformationEvent.
- Missing time zones. Always set eventTimeZoneOffset for Indonesian plants.
When this advice applies (and when it doesn’t)
This approach works for Indonesia coastal fleets, handline tuna, reef fish, and farmed vannamei shrimp. If you’re handling transshipment-at-sea or distant-water fleets, you’ll likely need additional KDEs for carrier vessels and RFMO reporting. For full chain-to-retail with item-level serialization, you’ll also need label integration beyond this guide.
If you want a quick review of your CSV columns and a copy/paste EPCIS template tailored to tuna or shrimp, Contact us on email.
Final takeaways
- Start with the documents you trust. WPP logs, STELINA/MDPI records, and BKIPM certificates can populate 90% of GDST KDEs.
- Map WPP to FAO using 57 for Indian Ocean and 71 for Pacific, watching WPP 718 closely.
- Use TransformationEvents for any trim, peel, split, or blend. If it happened on your floor, show it.
- Validate structure and business rules before sending. Buyers move faster when files are clean the first time.
When you’re ready, your GDST payload can travel with any export line, whether it’s a sashimi-grade tuna program or frozen retail fillets. If you need product examples, browse our current lines and see how the KDEs align with pack specs. View our products.