EDI.
Legacy exchange lives in XML. The gateway's translator takes EPCIS 1.1, 1.2 and 2.0 XML in and returns EPCIS 2.0 JSON-LD, with a round-trip fidelity report per job so the translation is reviewable rather than trusted. That translator answers at POST /translate on this origin. A hosted EDI-exchange product is not something this site claims; the migration path is what ships.
POST /capturePOST /translate
Where an 856 ends and an event begins.
EDI 856 (the shipping notice) EPCIS 2.0 (the observations)
────────────────────────────── ─────────────────────────────
HL shipment / BSN number → bizTransactionList type desadv
HL order / PRF number → bizTransactionList type po
HL pack / MAN (SSCC) → AggregationEvent parentID
HL item / LIN + SN1 qty → quantityList (class + quantity)
— (nothing: the 856 is sent) → ObjectEvent shipping / receiving
with who asserted,
capturedBy stampedIllustrative mapping: what an EDI 856 (ASN) asserts, and the EPCIS 2.0 shape that records what actually happened. The two are complements — the document is the plan, the events are the observations; the translator handles the XML era of the event side.
For the integration engineer with a decade of XML.
The evaluation that matters is your own corpus through the translation door: EPCIS 1.1/1.2 XML in, 2.0 JSON-LD out, a per-job fidelity report whose law is that loss may exist but silence about it may not. POST it to this origin from the terminal you are in — no key, no account.
Proof, not adjectives. The gateway's conformance tests pass against GS1's normative artifacts. See How for the dimension, and What ships today for the dated ledger.