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

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for 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](https://ref.gs1.org/standards/cbv/), and the pinned EPCIS 2.0
JSON-LD context (sha256 `5056c65f…`, verifiable against
[the family's pins](https://epcis.dev/conformance/)) carries the machine
form:

```json
"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:

```text
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:

```json
{
  "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](/blog/the-asn-said-48-the-dock-saw-47/) —
is one query, not three. It means the trace a buyer reads on
[visibility.cloud](https://visibility.cloud/asn-po-context-in-traces)
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](/blog/the-standard-already-named-your-paperwork/)
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](/blog/hl-loop-to-aggregation-events/),
[the N1 parties become source and destination](/blog/n1-loops-are-your-sourcelist/),
and the full worked run — every byte of an 856 accounted for in a
validated EPCIS document — is
[the compile post](/blog/from-856-to-epcis-document/). The identifiers the
tree hangs on — SSCC, GTIN — are [barcoding.dev](https://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](/get-access/), and the onboarding flow takes the
details.

---
Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt