Implementation reference
EDI 856 mapping: start from the physical and commercial sources
The difficult part of an 856 mapping is not joining fields to segment positions. It is preserving the relationship between accepted purchase orders, actual pack output, logistics labels, transportation records, and the hierarchy the trading partner expects.
Direct answer: Define authoritative sources for every business value, build an intermediate shipment tree, validate it before serialization, assign HL identifiers deterministically, emit the X12 segments, regenerate controls/counts, and reconcile the final bytes back to source snapshots. Never create an ASN by copying ordered quantities when actual shipped quantities are available.
Source-of-truth map
| ASN data | Preferred source | Mapping risk |
|---|---|---|
| PO and accepted line | ERP/850/855 state | Shipping cancelled or unaccepted lines |
| Item identifier | Trading-partner item cross-reference | Wrong qualifier/value pair |
| Shipped quantity/UOM | WMS pack confirmation | Copying ordered instead of shipped quantity |
| Carton and pallet structure | WMS closeout | Flattening real packaging relationships |
| SSCC/container ID | Controlled serial allocator + label scan | Duplicate or label mismatch |
| Carrier, BOL, PRO, ARN | TMS/carrier document | Describing a different movement |
| Ship/arrival dates | Dispatch and appointment records | Future/wrong-time confirmation |
Build an intermediate tree before X12
Represent the business shipment as typed nodes—Shipment, Order, Tare, Pack, Item—with explicit parent links. Validate uniqueness, ownership, quantities, and source references there. Only after the tree is accepted should the serializer assign HL01 values and write HL02.
This prevents segment-generation order from becoming business logic and makes the same validated model usable for an X12 856 or SP-API confirmation.
Mapping pipeline
- Load immutable source snapshots for the shipment.
- Normalize identifiers, decimal quantities, dates, and units without losing the original values.
- Construct and validate the shipment tree.
- Apply partner/profile rules with explicit evidence scope.
- Assign controls and HL IDs through atomic allocators.
- Serialize once, then calculate final trailer counts.
- Parse the emitted bytes back through an independent reader.
- Compare parsed values and totals with the intermediate model and physical sources.
The parse-back step catches delimiter, escaping, truncation, and trailer bugs that unit-testing an internal object alone cannot expose.
Tests that catch mapping defects
- Two items with the same buyer ID but different internal SKUs.
- Partial shipment and split shipment across appointments.
- One pallet with several cartons and one carton with several items.
- Multiple POs sharing a physical pallet.
- Unit conversion where ordered and shipped units differ.
- Duplicate SSCC allocation under concurrent packing.
- Timeout and retry after a transmission may already have succeeded.
- Replacement/correction with stable documented identifiers.
Common questions
Should mapping rules automatically repair bad source data?
No. Normalization is appropriate when deterministic and lossless; guessing a missing PO, quantity, hierarchy parent, or identifier hides the defect and makes later reconciliation harder.
Can the same intermediate model generate API JSON?
Yes, if it represents business semantics rather than X12 segment order. Apply channel-specific schema and usage rules after the shared shipment model passes its invariant checks.
Primary sources
Public sources cannot establish every account-specific EDI rule. Current Vendor Central documentation and your trading-partner agreement remain controlling.