The EDIFACT ORDERS message, and what po looks like from Brussels

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer wiring the order side of an international trading lane.

One thesis: ORDERS is the open-content purchase order — carrying the same commercial semantics as the X12 850, fully documentable from the pinned UNTDID directories — and its BGM document number is the po reference that every later document in the transaction cycle echoes.

The purchase order is where the cycle's primary key is born. Whatever identifier the buyer stamps on the order is the string the despatch advice answers with, the invoice bills against, and the receiving advice settles — which means the compile decision you make here propagates through every event the shipment ever generates. This page walks the open dialect's version of that decision, end to end.

The message, worked

ORDERS is the UN/EDIFACT purchase order, and EANCOM — GS1's retail subset — is its highest-volume habitat. Because the directories are vendored here and pinned by digest, the walkthrough can be complete on the page. A self-authored example, one order, one line:

UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+4500123+9'               document: order 4500123
DTM+137:20260715:102'            order date
NAD+BY+0345678000007::9'         buyer, by GLN (code list 9 = GS1)
NAD+SU+0614141000005::9'         supplier, by GLN
NAD+DP+0345678000168::9'         delivery party, by GLN
LIN+1++00614141123452:SRV'       line 1: the trade item, by GTIN
PIA+1+ACME-XK12:SA'              supplier's article number, riding along
QTY+21:192'                      ordered quantity: 192
DTM+2:20260801:102'              requested delivery date
UNS+S'
CNT+2:1'                         control count: 1 line
UNT+13+1'

Three observations an integrator actually needs:

• GS1 identifiers are native. The GTIN arrives in LIN with the GS1 qualifier and the parties arrive as GLNs in NAD — no partner-guide archaeology about which qualifier this hub uses. (The identifier grammar itself is barcoding.dev's beat.)
• PIA is the escape hatch, not the key. Internal SKUs and supplier article numbers ride in PIA beside the LIN GTIN. The compile keys on the GTIN; the PIA values travel as context, because a join key you have to fuzzy-match is not a join key.
• BGM+220's document number is the cycle's spine. 4500123 is the string the DESADV's RFF+ON points back at, the string INVOIC bills against, and the string the receiving advice finally settles — one key, four documents, no translation table.

The compile: one reference, one identity rule

The join verb compiles this message to a po business-transaction reference — CBV 2.0 §7.3's own vocabulary, the same type an 850 compiles to:

{ "type": "po",
  "bizTransaction": "urn:epc:id:gdti:0345678.00010.4500123" }

The identifier discipline matters more than it looks. The reference needs its own identity — stable, cross-party, collision-free — because idempotency and reconciliation both hang on it: when the despatch advice, the receiving events, and the invoice all cite the order, they must cite the same string. Where the buyer owns a GS1 company prefix, a GDTI EPC URI built from it is the clean answer; where no GS1 identity exists, the hash-URI fallback gives the document a deterministic name. One document, one identifier, and every event that cites it agrees — the pipeline enforces that as a rule, not a convention.

The order's party GLNs also seed the §7.4 source/destination compile for the events that follow: buyer GLN as the destination owning_party the shipment is traveling toward, supplier GLN as the source. An ORDERS in hand means the downstream despatch events already know their endpoints.

ORDERS versus the 850, where it bites

The commercial semantics are the same — a buyer asking a supplier for quantities of identified items by dates. The differences an integrator hits in practice are mechanical:

• Envelope and self-description. EDIFACT's UNB/UNH service segments with defaulted delimiters versus X12's fixed-width ISA; one fewer nesting level, an explicit release character, and no functional group by default. Most of an integrator's first bad week lives at this layer, in both dialects.
• The document number's home. BGM's element versus the 850's BEG — same role, different address. Both decay the same way under change orders and re-releases, which is why the reference, once minted, never silently changes: an amended order is new context, not a rewritten key.
• Identifier posture. In EANCOM the GS1 code lists are the default; in X12 retail they are qualifier conventions that vary by hub — the difference between reading a directory and reading a thousand partner PDFs. The compile output is identical — which is the whole point of compiling.
• Acknowledgment lane. The EDIFACT side answers with CONTRL where X12 answers with a 997 or 999 — three acknowledgments, one question, and the compile treats all three as pure functions of a validation result.

That last symmetry is the layer's thesis in miniature: your purchase order does not care whether it traveled as an 850, an ORDERS, or a REST payload. It lands as one po reference on a core field every conformant consumer already parses, and the cycle's later documents — the despatch advice, the invoice, the receiving advice — join it there, on the event spine, where one query answers what three document stores used to. If ORDERS is on your wire — or an international lane is about to put it there — say so at the door; the onboarding flow asks which document sets are on the wire today and which D-release stamps them.

---

853 words. The access flow is at /get-access/; the family's event door is epcis.dev.