EDI 856 advance ship notice: hierarchical levels and what buyers check

BSN declares the shape of the document

BSN is the beginning segment for a ship notice. BSN01 is the transaction set purpose code, BSN02 the shipment identification assigned by the sender, and BSN03 and BSN04 the date and time the notice was created. BSN05 is the element that matters most for parsing: it is the hierarchical structure code, and it declares which levels will appear and in what order. 0001 declares shipment, order, packaging, item. 0004 declares shipment, order, item, which is the flatter form used where pack detail is not required. Read BSN05 before writing any loop logic.

The HL loop is the whole document

Each HL segment opens a level. HL01 is the identifier for this level, HL02 the identifier of its parent, and HL03 the hierarchical level code. A shipment level carries the carrier and routing, an order level carries the purchase order reference, a tare level carries a pallet, a pack level carries a carton, and an item level carries the goods. The parent pointer in HL02 is what turns a flat segment stream back into a physical shipment, and a broken parent pointer produces an ASN that parses cleanly and describes nothing.

• HL03 code S, shipment level, one per ASN
• HL03 code O, order level, one per purchase order in the shipment
• HL03 code T, tare level, a pallet or other outer unit
• HL03 code P, pack level, a carton
• HL03 code I, item level, the goods themselves

Read the segments buyers actually act on

At shipment level, TD5 carries the carrier and routing, TD3 the equipment, TD1 the packaging and weight, and REF with the qualifier BM carries the bill of lading number. DTM with qualifier 011 carries the shipped date. At order level, PRF quotes the purchase order number, which is the join back to the order. At pack level, MAN carries the marks and numbers, normally the SSCC-18 serial shipping container code encoded on the GS1-128 label that receiving will scan. At item level, LIN carries the product identifiers and SN1 the quantity shipped. CTT closes the document with a count of HL loops.

• REF BM at shipment level, the bill of lading number
• TD5 carrier and routing, TD3 equipment, TD1 packaging and weight
• DTM 011 shipped date
• PRF at order level, the purchase order number that joins back to the 850
• MAN at pack level, the SSCC-18 carried on the GS1-128 label
• LIN and SN1 at item level, product identifiers and quantity shipped

Reconcile the ASN against the commitment, not the original order

The common receiving dispute is not that the ASN is wrong but that it is being compared to the wrong baseline. If the supplier acknowledged 80 of 120 pieces with the balance backordered, and the buyer approved that, then an ASN for 80 is correct and an exception report built against the original 120 will raise a false shortage every time. Compare the SN1 quantity to the current committed quantity from the acknowledgment, and keep the original ordered quantity visible beside it so the full history is still readable.

Know why ASN accuracy is enforced commercially

Large retailers and distributors treat ASN accuracy as a compliance obligation, because receiving is automated against it. A late ASN, a missing SSCC, a carton whose contents do not match the pack level, or a quantity that disagrees with what arrives can all generate a chargeback under a supplier compliance program. The specific rules, timing windows, and penalty amounts are set by each trading partner in their vendor requirements document, so verify them with the partner rather than assuming an industry norm.

What Pacteva does and does not do with a ship notice

Pacteva is an acknowledgment and commitment layer, not a warehouse or transportation system. It records what a supplier committed to ship and when, and it exports that commitment so receiving and planning can compare it to what arrives. It does not receive or generate an 856, produce GS1 labels, or hold receipt records. Those stay in your EDI, warehouse, and ERP systems. The value Pacteva adds upstream is that when the ASN arrives there is an explicit committed quantity and date to reconcile it against, instead of an email thread.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.