# DESADV, at full depth.

[The X12 post in this series](/856-asn-to-epcis-aggregation/) 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 pin ledger under the same law as [every other normative input on this origin](/conformance/) — its per-file sha256 digests land by journaled ruling once the vendoring completes; until then the ledger records exactly that, and nothing is claimed pinned that is not. 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](/x12-link-dont-copy/)): 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. The committed ledger exists and governs today; its digest entries land when the UNECE vendoring completes by that same journaled process (the ledger currently records the blocked fetch attempt, dated, rather than minting a pin over bytes never fetched). 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](/epcis-biztransaction-po-desadv/).

## 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](/business-transactions/). 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](/differential-conformance-edi/)) 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](/business-transactions-in-epcis/) carries the CBV citations in full, beside [the door page](/business-transactions/). **Run your DESADVs through the join:** the EDIFACT verbs ride the capture surface — **[get a capture key](/get-a-key/)**.

---

**Proof, not adjectives.** This build could not verify the gateway's test suite green, so no sentence on this page claims a passing run — the last verified run is recorded in the repository's own CI, not here. Live on this origin, no key: POST /translate, /validate, /hash. No conformance attestation has ever been issued. The dated ledger is /what-ships-today/.