The standard already has a field for your purchase order.

EDI is where the master data lives — party GLNs, item GTINs, the ASN's package hierarchy — and the temptation in every traceability project is to bolt that context onto events with custom extensions. You don't need to. CBV 2.0 made the business documents themselves first-class citizens of the event model, and it did it on four spec-sanctioned join points, with zero extensions required.

Join 1 — the document reference itself.

CBV 2.0 §7.3 standardizes the BusinessTransactionTypeID vocabulary: po (purchase order), inv (invoice), bol (bill of lading), prodorder, recadv (receiving advice), and — decisively for the ASN —

desadv — "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." (CBV 2.0 §7.3)

The standard saw your ASN coming and wrote it a field. And §8.5 puts that field everywhere: business-transaction identifiers "populate the 'why' dimension of EPCIS events," including "the bizTransactionList field in all EPCIS event types" — not just TransactionEvent. Every ObjectEvent, every AggregationEvent can carry { "type": "desadv", ... } and { "type": "po", ... } in core fields every conformant consumer already understands.

This is not an interpretation; it is in the pinned artifacts this origin validates against. The official JSON-LD context maps the short names to the CBV web vocabulary:

"desadv": "cbv:BTT-desadv",
"po":     "cbv:BTT-po",

— two lines from epcis-context.jsonld as GS1 publishes it, vendored here and sha256-pinned on the conformance page. And the golden corpus exercises the join today: transaction-event-po.json is a committed TransactionEvent fixture carrying

"bizTransactionList": [
  { "type": "po",
    "bizTransaction": "urn:epc:id:gdti:0614141.06012.1234" }
]

Join 2 — the parties.

CBV 2.0 §7.4 defines the source/destination vocabulary — owning_party, possessing_party, location — and §8.7 binds it to sourceList/destinationList. The parties a purchase order or despatch advice names map directly: seller GLN → source owning_party, buyer GLN → destination owning_party, ship-from and ship-to location GLNs → source and destination location. The N1 loops of an 856 and the NAD segments of a DESADV carry exactly these GLNs; the event model has exactly these slots.

Join 3 — the lines.

An ASN's line items are GTIN-grain: item identifier, quantity, lot, serial ranges. EPCIS events are the same grain — epcList sgtin EPCs, quantityList EPC classes with lot. The join key is the GTIN itself: a document line attaches to the commissioned and shipped serials that share it. The despatch advice's package hierarchy — shipment, order, pack, item, whether it arrives as X12 HL loops or EANCOM CPS sequences — is structurally an EPCIS aggregation tree: SSCC as the AggregationEvent parentID, GTIN-grain children beneath it.

Join 4 — the master data.

CBV 2.0 §9.2 defines trade-item master-data attributes (GDSN-aligned) and §9.3 the location and party attributes — the standardized cbvmda: vocabulary for exactly the product, party and location data that orders and despatch advices carry. The pinned EPCIS 2.0.1 schema carries document-level master data natively (epcisHeader → epcisMasterData → vocabularyList), and events carry instance/lot master data as ILMD (EPCIS 2.0 §7.3.7). Nothing about enriching events with document-borne master data leaves the standard.

What this means for an implementation.

Four join points, all core, all validated by the same pinned schema this origin validates against. A pipeline that parses a despatch advice — X12 856, EANCOM DESADV, or a plain JSON shipment payload — and stamps bizTransactionList, sourceList/destinationList, and GTIN-grain lists onto its events is not extending EPCIS. It is using EPCIS as written. That pipeline is the business-transaction layer; the document-side mappings are worked end to end in the 856 join and the DESADV join.

For the RFP and the architecture review, the checkable chain is short: the CBV 2.0 PDF is freely downloadable from GS1; the context mapping and the schema are vendored here with published sha256 digests; the corpus fixture is committed. Cite the sections, hash the artifacts, run the validator — nobody's word is involved, ours included.