DESADV, at full depth.

The X12 post in this series had to hold a line: structure in original prose, dictionary detail linked out, because X12's license forecloses republication. This post is what the same mapping looks like when the license opens instead. UNECE publishes the UN/EDIFACT directories freely, and so the international despatch advice gets the full treatment: every segment group named, every landing zone specified, and the directory artifacts governed by a committed per-file sha256 pin ledger like every other normative input on this origin. If your corpus is European retail, this is the reference the 856 reader wishes they had.

Why this one goes dictionary-deep

The policy is structural, not editorial (stated in full here): documentation depth follows content licensing. The UN/EDIFACT directories are openly downloadable from UNECE, and EANCOM 2002 — the GS1 implementation this mapping is written against — rides on the UN/EDIFACT D.01B directory. Open publication means the artifacts answer to a pin ledger: per-file digests with retrieval dates, changed only by journaled human ruling, rendered from the committed ledger itself. The mapping below cites message structure in our own words because the structure is ours to describe.

The message, segment group by segment group

A DESADV is a header, a packing hierarchy, and the lines inside it. The working anatomy:

UNH / BGM open the message; BGM carries document code 351 and the despatch-advice number — the identifier that becomes the event-side desadv reference.
DTM carries the dates; the despatch date is the shipping event's eventTime.
RFF carries the cross-references, above all ON — the buyer's purchase-order number, which becomes the event-side po reference.
NAD names the parties by GLN: buyer (BY), supplier (SU), delivery party (DP), ship-from (SF). EANCOM's discipline is GLNs, not free-text addresses — exactly what makes the party join mechanical.
CPS is the heart: the consignment packing sequence. Each CPS names a level in the packing tree and points at its parent, spelling out a rooted hierarchy — shipment, pallet, case — the way X12 does with HL loops.
PAC / PCI / GIN describe and identify each package; in GS1 practice GIN carries the SSCC of the pallet or case.
LIN / QTY carry the trade items: GTIN and despatched quantity, inside the CPS level that physically contains them; batch and serial detail ride the same line group.

The mapping

DESADV fact	segment group	EPCIS landing zone
packing tree node with SSCC	CPS + PAC/GIN	AggregationEvent, parentID = SSCC EPC URI
trade-item line, lot-grain	LIN/QTY (+ batch)	childQuantityList — LGTIN, quantity, UoM
trade-item line, serialized	LIN + serial detail	childEPCs as SGTIN URIs
despatch-advice number	BGM	bizTransactionList: { "type": "desadv", … }
purchase-order reference	RFF (ON)	bizTransactionList: { "type": "po", … }
supplier / buyer GLNs	NAD (SU/BY)	sourceList / destinationList, owning_party
ship-from / delivery GLNs	NAD (SF/DP)	sourceList / destinationList, location
despatch date	DTM	eventTime of the shipping ObjectEvent
shipment root	CPS root	shipping ObjectEvent, bizStep: shipping

Same landing zones as the 856 — because the landing zones are the standard's, not the syntax's. CBV 2.0 §7.3 supplies the types, §7.4 the exactly-three source/destination roles, §8.5 the rule that bizTransactionList rides every event type — the join designed into the vocabulary itself.

One corpus, two syntaxes

The engineering consequence is the quiet headline: the same expected-EPCIS fixtures gate both paths. A despatch advice describing 96 each of lot 7A-4412 on one SSCC produces the same aggregation event and the same shipping event whether it arrived as an 856, a DESADV, or API-native JSON through the business-transaction door. The corpus stores fixture pairs — source document ⇄ expected events — and the acceptance gate is identical everywhere: every generated event validates against the pinned official EPCIS 2.0.1 schema before it leaves the join, and hashes stably under CBV §8.9:

$ npx epcis.dev validate desadv-expected.epcis.json
valid	schema=epcis-json-schema.json	version=2.0.1

So the X12/EDIFACT question stops being an architecture question. It is a parser-front-end question, adjudicated by one differential harness (how ground truth is manufactured when no official suite exists) and answered by one set of expected events.

EANCOM deserves its named place here: it is not "EDIFACT with extra steps" but GS1's retail profile of it — the dialect where the identifiers are already GS1 keys. GLNs in NAD, SSCCs in GIN, GTINs in LIN mean the identity systems on both sides of the mapping are the same system, which is why this join produces conformant events instead of a crosswalk table.

Read the join's spec grounding now: Business transactions in EPCIS carries the CBV citations in full, beside the door page. Run your DESADVs through the join: the EDIFACT verbs ride the capture surface — get a capture key.