desadv is the ASN — the spec says so in its own words

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer who has lost an afternoon to the ASN naming argument.

One thesis: the spec already ended the naming argument — CBV 2.0 defines desadv as the despatch advice, notes it is "Also called an 'Advanced Shipment Notice,'" and rules that the value desadv is always used regardless of local nomenclature. Every 856, DESADV, and fulfillment webhook is the same reference type.

The local-nomenclature problem

Ask four systems what announces an inbound shipment and you get four nouns. The X12 lane says 856 or ship notice. The EDIFACT lane says despatch advice. The retail ops team says ASN. The commerce platform says fulfillment. They are one document — the sender's advance statement of what is on the truck, how it is packed, and which order it answers — but four names means four fields, four filters, and at least one meeting per quarter about which is authoritative.

The spec's answer, in its own words

CBV 2.0 §7.3, in the definition of the desadv business-transaction type, settles it. The definition names the despatch advice, then adds — quoting the ratified text — "Also called an 'Advanced Shipment Notice,'" and rules that the value desadv is always used regardless of local nomenclature. The ratified PDF is freely downloadable from ref.gs1.org, and the pinned EPCIS 2.0 JSON-LD context (sha256 5056c65f…, verifiable against the family's pins) carries the machine form:

"desadv": "cbv:BTT-desadv"

"Always used regardless" is the load-bearing clause. It is not a suggestion to prefer one synonym; it is a normalization law written into the vocabulary itself. Whatever the wire called the document, the record calls it desadv — which means the record's consumers filter on one value, forever, and the naming argument is over because the standard already had it and you were not invited.

Where the reference identifier comes from in each dialect

Naming the type is half the job; the reference also needs an identifier. Each dialect keeps its shipment identifier in a different place, and the compile maps all three to one CBV §8.5 reference:

X12 856          BSN02 — the shipment identification
                 BSN*00*SHIP20260730001*20260730*1800
EANCOM DESADV    BGM document number
                 BGM+351+SHIP20260730001+9'
Shopify          the Fulfillment object's id
                 { "fulfillment": { "id": 4353378615478, ... } }

All three land as the same entry on every event compiled from the document:

{
  "type": "desadv",
  "bizTransaction": "urn:epcglobal:cbv:bt:0614141000012:SHIP20260730001"
}

The URN is CBV §8.5's own scheme — urn:epcglobal:cbv:bt: followed by the GLN of the party that assigned the reference, then the reference itself — so a shipment id that was only unique within one sender becomes globally unambiguous without a registry. That exact shape is pinned in the golden join corpus: the fixture 856-ship-notice-01.edi carries the BSN above, and its expected output stamps this reference on the shipping ObjectEvent and on every AggregationEvent in the packing tree. The ruling that the BSN02 reference lands on every event from the document (not just the top one) is itself pinned data in the join map, changed only by journaled ruling — never silently.

What normalization buys you downstream

One value in the type position means the reconcile question — does what was shipped match what was seen — is one query, not three. It means the trace a buyer reads on visibility.cloud answers "which ASN covered this case" identically whether the supplier runs a 4010 VAN mailbox or a webhook. And it means an agent consuming the record matches type == "desadv" and is done — no synonym table, no per-partner configuration, no folklore.

The contrast is worth naming. A pipeline that stores "ASN" for X12 partners and "fulfillment" for API partners has re-created the partner map inside its own database — the exact liability the controlled vocabulary exists to delete. The §7.3 close reading covers the whole enumeration; this post is the one value where the spec took a side in a naming war and wrote the verdict into the definition.

One more consequence worth naming: the law is direction-blind. The same desadv value covers the ASN you receive from a supplier and the one you send to a retail hub, the drop-ship notice from the 3PL and the warehouse's inbound pre-advice. Systems that model "inbound ASN" and "outbound ASN" as different document types are encoding a point of view into a record that outlives the point of view; the vocabulary encodes the document, and lets the event's source and destination say which way it was traveling.

The document behind the word

The despatch advice is also the structurally richest document in the cycle — a packing hierarchy, party identifiers, item grain, dates — and each of those has its own compile: the HL tree becomes AggregationEvents, the N1 parties become source and destination, and the full worked run — every byte of an 856 accounted for in a validated EPCIS document — is the compile post. The identifiers the tree hangs on — SSCC, GTIN — are barcoding.dev's layer.

If your stack currently holds the four-names version of this document, the fix is a compiler, not a meeting: say what you compile, and the onboarding flow takes the details.

---

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