Your Trace Already Has a Vocabulary for Your Paperwork: `po` and `desadv` Are Core CBV

Every enterprise you have worked in runs two record worlds that do not speak. The document world — purchase orders, advance ship notices, invoices, receiving advices — lives in the EDI stack and the ERP, governed by trading-partner agreements, reconciled by a team that has done it the same way for twenty years. The event world — scans, receipts, aggregations, the material truth of what moved — lives wherever your traceability program is putting it. Between them sits a boundary every audit crosses the hard way: the trace says a case arrived; the ASN that announced it is in another system; a human joins them with a spreadsheet.

Here is the fact this post exists to put in your hands: the standard already dissolved that boundary. The Core Business Vocabulary — the companion vocabulary to EPCIS 2.0 — was written with your trading documents as first-class citizens, by name. Joining a purchase order to a custody event is not an integration your vendor builds. It is core-spec machinery.

The spec quotes, verbatim

CBV 2.0 §7.3 defines the business-transaction type vocabulary. Among its members: po (purchase order), inv (invoice), recadv (receiving advice), bol (bill of lading), prodorder — and desadv, whose definition the standard gives as:

"Despatch Advice. A document/message by means of which the seller or consignor informs the consignee about the despatch of goods. Also called an 'Advanced Shipment Notice,' but the value desadv is always used regardless of local nomenclature."

Read that second sentence twice, because a standards body wrote it about your paperwork: the ASN — the document your EDI team transmits thousands of times a week — is in the vocabulary, under a stable name, with an instruction that the name holds no matter what your industry calls it locally.

And where do those references live? CBV 2.0 §8.5 places them on the event itself: business transaction identifiers "populate the 'why' dimension of EPCIS events. This includes the bizTransactionList field in all EPCIS event types." Every event — object, aggregation, transaction, transformation, association — carries the list. Not a side table, not a linking service you subscribe to: fields of the record, defined by the same specification your program already validates against.

The joined event, as a fixture

Here is what the join looks like in practice — a conformant TransactionEvent from the tested corpus behind this record, the same corpus the conformance suite passes on. Illustrative identifiers, real grammar:

Field by field: the shipment (bizStep: shipping), the two serialized units it covers (epcList), the dock it left from (readPoint), the selling and buying parties as GLNs (sourceList / destinationList — the party join, worked in its own post, Party Identity Without a Network) — and, on bizTransactionList, the purchase order this shipment answers to, identified by a GDTI, the document-identifier syntax §8.5 itself recommends. An ASN reference rides the same list the same way: { "type": "desadv", ... }. This event validates against GS1's official pinned EPCIS 2.0 schema exactly as shown. Core fields, zero extensions.

That last phrase is the risk story, so state it as one. A join built on core vocabulary is auditable by anyone who can read the standard, portable across any conformant system, and immune to the fate of a vendor's proprietary linking layer. When your auditor asks why is this PO reference on this event, the answer is a section number — §7.3, §8.5 — not a vendor's design document. This record pushes past the standard where the standard is silent — the attested performer on every event, which no CBV field reaches — but it does so as a superset that stays conformant: the documents join on core fields, and the projection always validates.

What this changes operationally

On a record where events carry their document references, the questions that today cross the document/event boundary by spreadsheet become queries: show me every receiving event under this ASN. Show me the custody chain for everything ordered on this PO. Which shipments arrived carrying references to documents we never issued? The reconciliation discipline this enables — what the ASN said was shipped versus what the events say was seen — is worked line-by-line in Shipped vs. Seen, and the hierarchy inside the ASN itself gets the same treatment in The ASN's Hierarchy Is Your Custody Tree. The executive read across the whole document layer sits at the ASN/PO context brief, and the developer-facing side of the document layer — how an X12 856, an EDIFACT DESADV, or plain JSON from an order API compiles to these same CBV references — is transactions.dev, by visibility.cloud.

The question for your current vendors

You own both silos, which means you are the one person in the building who can ask the question that exposes the boundary: "Show me a trace that cites my PO." Not a report joining two exports — a custody trace whose events carry the document references in their own bizTransactionList, as the standard defines. Vendors running on core CBV can show you in one query. Vendors holding the join in a proprietary layer will show you a roadmap. The specification took the trouble to name your paperwork; the least a record can do is carry it.

The door here is the get-started interview: your email first, then a short interview that branches on your answers — the manufacturer branch asks how long your last quality problem took to resolve to lots, who literally holds the login for your GTIN records, and what already sits on your 2026 or 2027 plan with a date.