EDIFACT DESADV validation should be its own standards family

DESADV communicates dispatch advice in UN/EDIFACT workflows. It solves a business problem similar to an X12 856, but its syntax, envelope, directories, message structure, codes, and partner profiles are different.

Direct answer: Build a dedicated EDIFACT parser, detect UNA syntax and UNB/UNH version identity, pin validation to an official UNECE directory release, apply a named partner profile, construct package and item relationships, and reconcile order, quantity, container, carrier, and dispatch evidence. Do not translate X12 rules by renaming segments.

Version identification is the first rule

UNECE publishes versioned UN/EDIFACT directories. A DESADV validator should report the detected directory and message identity before applying structural rules. If the configured partner pack does not support that version, return a clear unsupported-version finding rather than guessing from a nearby release.

Store official source metadata separately from partner restrictions. This makes it possible to update the neutral directory support without silently changing what a specific retailer accepts.

Validation layers

1. Read syntax service characters and tokenize without data loss.
2. Validate interchange and message reference controls.
3. Apply the exact DESADV directory grammar.
4. Apply the retailer or logistics-partner profile.
5. Build the neutral shipment/package/item model.
6. Reconcile it to the order, warehouse, labels, and transport movement.

The neutral model can share business invariants with the X12 856 and Amazon Vendor Shipments API. The parser and standards metadata should not be shared through conditionals inside an X12 class.

Information a useful report must expose

• directory and message version detected;
• exact segment, element, occurrence, and business location;
• whether a finding is official directory structure, partner profile, or reconciliation;
• the source revision and rule-pack version;
• the received value, safe expected shape, and next action;
• limitations where the current partner guide is unavailable.

Current structural test gate

Shipment Sentry now accepts DESADV through the public preflight and authenticated gate. The live rule surface verifies:

• UNB first and UNZ last;
• matching UNB05 and UNZ02 interchange controls;
• required UNH, BGM, DTM, RFF, LIN, QTY and UNT segments;
• a DESADV identity in UNH;
• matching UNH01 and UNT02 references plus an exact UNT01 count;
• one QTY occurrence for every LIN occurrence.

Deeper directory and partner support still requires:

• accepted and rejected official-directory fixtures for the pinned release;
• alternative delimiters and UNA cases;
• truncated, duplicate, missing-reference, and oversized inputs;
• arbitrary package/item hierarchies and quantity conservation properties;
• partner-specific fixtures from authorized current guides;
• parse/serialize/parse invariants where serialization is offered;
• browser, accessibility, security, rate-limit, and chaos coverage through the shared upload flow;
• explicit unsupported-version behavior.

Current product boundary

Shipment Sentry’s live EDIFACT DESADV validator checks EDIFACT syntax and public DESADV structure with exact finding codes and locations. It does not execute every rule in a selected UNECE directory, EANCOM subset or trading-partner guide. Those pinned rule packs and authorized partner fixtures remain required before a production route can claim that narrower conformance.