EDIFACT DESADV validation: syntax, shipment hierarchy, and partner rules

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.

Check the validator's declared coverage

A DESADV option in a tool can mean basic parsing, structural checks, a directory implementation, or a configured partner profile. Read the stated scope and reported limitations before treating a passing result as complete partner compliance. The current interface is the authority for the formats and checks offered by a particular product release.

What is an EDIFACT DESADV message?

DESADV is the UN/EDIFACT despatch advice message. It communicates information about goods being dispatched so the receiving party can prepare and reconcile the delivery. In a practical integration, that means connecting shipment identity, orders, packages, items, quantities, and relevant movement details. The receiver's implementation determines which optional structures and fields are required for its workflow.

The spelling “despatch advice” is used in the standard's message name, while people also search for dispatch advice, advance shipping notice, or ASN. Those phrases describe related business needs. They do not establish that the underlying message formats are interchangeable. Identify the requested standard family and profile before selecting a sample or conversion tool.

For a supplier, the useful outcome is a notice that accurately represents the warehouse's released shipment. A valid message containing the wrong quantities remains operationally wrong. A full EDI solution therefore needs both format-specific validation and business reconciliation. Keep those results separate so users understand whether a finding concerns syntax, partner usage, or disagreement with source records.

Read the directory and message identity before choosing rules

The message header identifies DESADV and its release information. The official UNECE D96A reference, for example, identifies the message type, directory version and release, and controlling agency for that definition. That is a concrete reference for D96A; it is not evidence that every partner uses D96A or that all later releases accept identical structures. UNECE DESADV D96A reference

Store the detected identity in the validation result and compare it with the configured profile. If a partner expects one release and the document declares another, report the mismatch explicitly. A parser may still tokenize the bytes, but successful tokenization does not justify applying the wrong directory rules. Make unsupported coverage visible rather than returning an unqualified green result.

Version the partner restrictions independently. A retailer may use a subset of a directory with additional business constraints. Updating your neutral parser should not silently change that retailer's profile. Preserve the profile revision and source reference with each result so a historic document can be reviewed under the rules that were active when it was processed.

Understand separators, composites, and release characters

EDIFACT uses service characters to distinguish segments, data elements, and component data elements. A parser must interpret them according to the syntax in use, including a UNA service string advice when present and applicable. Splitting text on every apostrophe or plus sign without accounting for release behavior can corrupt legitimate values and create misleading segment boundaries.

Keep the original bytes before formatting or extracting fields. A human-friendly viewer can show one segment per line and expand composites, but it should retain a route back to the original position. If formatting changes the message, identify the output as a new representation rather than implying that it is the exact submitted artifact. Validation evidence should refer to the bytes actually being checked.

Test escaped service characters, empty elements, repeated composites where supported, alternate service-character configurations, and truncated input. A parser should fail clearly when it cannot interpret the syntax safely. Do not “repair” an uncertain delimiter by guessing the most common character and continuing to generate business data. That can turn a visible parsing problem into an invisible mapping error.

Use an EDIFACT formatter without confusing it with validation

A formatter improves readability. It can insert visual breaks, number segments, and display component positions. A validator checks defined rules. A reader may explain names without applying the complete directory. These capabilities are useful in different ways, but a nicely indented DESADV is not proof of a correct message.

For troubleshooting, a good formatter lets an operator search for an order or container reference and see its surrounding group context. It preserves empty positions and makes release characters understandable. It should also disclose whether processing occurs locally in the browser or on a server. Shipping documents can contain commercially sensitive partner, address, and quantity information.

If you export formatted text, compare it with the original in a controlled test before using it in another system. Some receivers accept presentation line breaks while others expect a specific transport representation. The safest production process serializes from a validated model under an explicit output contract rather than copying text out of an explanatory viewer.

Explain the main DESADV information groups

At a high level, a despatch advice needs an identity, relevant dates and references, parties, packaging relationships, and item quantities. The exact segments, order, repetition, and mandatory conditions depend on the directory and partner profile. A public message reference helps explain the vocabulary; an implementation guide determines how a specific receiver uses it.

Build the mapping around business meanings. The shipment reference should come from the dispatch record. An order reference should come from the relevant customer order. Item identity should include its identifier type, and quantity should include its unit. Do not map two fields together solely because both contain a short string or a number. A reference's role is as important as its visible value.

For each target field, document source, transformation, condition, and missing-data behavior. An unknown source should remain unknown until resolved. Filling absent shipment details with a current timestamp or an arbitrary warehouse default can produce syntactically plausible output with false business content. Explicit mapping exceptions give operators a chance to correct the source before release.

Model package hierarchy before rendering the message

Package relationships determine which items belong to which logistics units. A shipment can contain pallets, cartons, and item allocations in a structure that the partner expects to receive. The CPS segment participates in packaging hierarchy in DESADV implementations, but its permitted usage must be interpreted through the relevant message definition and profile. UNECE CPS usage reference

Use a neutral packing model with explicit parent relationships and stable container identities. Validate that every referenced parent exists, no relationship creates a cycle, and item allocations remain attached to the intended package. Check that duplicate identifiers do not accidentally merge separate physical units. Then serialize that model into the target profile's required structure.

Suppose an order has twelve units split between two cartons of six. Preserve both allocations even if a spreadsheet presents only the total. If the source lacks carton-level detail and the receiver requires it, the conversion is missing necessary information. It should request packing evidence rather than inventing two equal cartons. The conversion guide explains this source-completeness check.

Reconcile DESADV quantities against orders and packing

Compare the dispatched quantities with the accepted order and warehouse release records. Differences may be legitimate partial shipments, or they may reveal mapping defects. The report should distinguish those cases using explicit business status and references. A blanket rule that every ASN must equal the entire order total can reject valid partial fulfillment.

Normalize units only through approved conversions. A quantity of five cases cannot be compared directly with five eaches. Record the pack size, source, and effective version of any conversion. If an item can be supplied in multiple configurations, the mapping needs the correct configuration for that order and shipment. Guessing from a product description is not a reliable conversion rule.

Keep cumulative shipment history and identify retransmissions. A repeated DESADV should not count as another physical dispatch merely because it arrived twice. Corrections and replacements need their own defined business semantics. Preserve the original message, the replacement relationship, and the resulting quantity effect so an operator can explain the final balance.

Check message controls and counts independently

Envelope controls and message references support integrity and correlation. Validate opening and closing relationships at the appropriate scope and calculate counts from the parsed or serialized structure under the applicable syntax rules. Do not use the number of visual lines in an editor as a proxy for the number of segments. Formatting can change line breaks without changing the message structure.

Test multiple messages in one interchange, missing trailers, mismatched references, and interrupted input. The parser should identify which message is incomplete rather than merging the remainder into the previous document. A validation report should show the relevant original reference so the sender can locate the correct artifact in its transport history.

When generating output, allocate controls through a durable policy and retain them with the emitted bytes. A transport retry and a corrected business document are different operations. Follow the partner's requirements for each, and keep a traceable relationship between attempts. A hash of a short shipment reference alone is not a sufficient general-purpose allocation strategy under concurrency and long-term reuse.

Convert X12 856 to DESADV through a business model

Both messages can describe shipment information, but their syntax and implementation choices differ. A robust conversion first interprets the source under its own profile, creates a normalized shipment model, validates required business data, and then renders the target under its own profile. This makes missing information visible and avoids treating segment names as interchangeable labels.

Preserve provenance for each normalized value. An operator should be able to trace a target order reference back to the source segment or source-system field. Where several source fields compete, define an explicit precedence rule and test it. Where no source supplies a required target value, block or request enrichment according to the workflow rather than silently defaulting it.

Round-trip tests are useful but need semantic assertions. Converting X12 to a neutral model and back may change formatting or segment choices while preserving meaning. Compare identifiers, quantities, units, package relationships, and required references, then separately inspect output structure. A byte-for-byte comparison alone can be too strict for legitimate formatting differences and too weak when both serializers share the same business mistake.

Diagnose common DESADV errors in a useful order

Start with syntax recognition and truncation because those failures can generate many secondary messages. Next check envelope and message identity, then directory structure, partner restrictions, and business reconciliation. This order reduces noise. An error about a missing item can be a consequence of an earlier segment being parsed incorrectly rather than an actual absence in the source.

For each finding, report a stable code, severity, location, observed condition, and recommended next step. Keep explanations tied to the rule's scope. A generic structure warning should not say that a named retailer will reject the shipment unless the relevant partner evidence supports that conclusion. Clear boundaries make the report more useful to both developers and operations staff.

Preserve the rejected artifact and response before correction. Reproduce the failure using the same parser, directory, and profile versions. Correct the source or mapping, generate a new artifact, and compare the intended changes. Avoid editing a production file in place and losing the evidence needed to diagnose why the defect occurred.

Build a partner onboarding fixture pack

Create small accepted fixtures for the supported shipment patterns and rejected fixtures for important failure modes. Include multiple packages, mixed items, partial fulfillment, unknown item identifiers, invalid units, malformed service characters, missing references, and duplicate messages. Each fixture should state its expected normalized business result as well as its validation outcome.

Use authorized partner examples where available and record the guide revision. Public directory samples establish only the scope they actually demonstrate. A successful local test does not establish receiver acceptance. Keep partner test responses with the exact submitted artifact and configuration so future changes can be checked against concrete evidence.

Automate regression checks when a parser, directory, partner profile, or mapping changes. Review the differences before promotion. Retain old versions for historical replay and make unsupported versions visible in the interface. This version discipline is what allows a full EDI platform to expand standards coverage without making every existing route unpredictable.

Questions about EDIFACT DESADV validation

What does a small DESADV example look like?

The following header fragment illustrates message identity and a notice reference for discussion. It is deliberately incomplete: it omits the interchange envelope, message detail, and trailers and must not be submitted as a valid shipment notice.

UNH+1+DESADV:D:96A:UN'
BGM+351+DEMO-SHIPMENT-1+9'

Use the official directory and current partner profile to build a complete fixture, then add authoritative shipment facts. An EDIFACT viewer can make this fragment readable; an EDIFACT validator must also identify the missing surrounding structure instead of interpreting a recognized DESADV header as acceptance.

Can I convert EDIFACT to JSON?

Yes, but decide whether the JSON represents syntax tokens or a normalized business document. A segment array can preserve positions without explaining package relationships. A shipment model needs explicit identifiers, units, allocations, and source provenance. Keep the original message and validation scope alongside either export so downstream software does not mistake an unvalidated parse for an approved business record.

Is DESADV the same as an EDI 856?

They can serve a similar shipment-notice purpose, but they belong to different standards families and have different syntax and profiles. Use a business model to connect their meanings and a dedicated parser and serializer for each format. Do not reuse an X12 validator by renaming its segments.

Can I validate DESADV online for free?

Tools offer different scopes, from formatting to structural checks and partner validation. Check supported directory releases, privacy behavior, file limits, and the meaning of a passing result. Use a redacted fixture when evaluating a service and verify that it catches the specific failure cases relevant to your route.

Why does a valid DESADV fail after upload?

The receiver may apply a different directory or partner profile, or its business records may disagree with the notice. Confirm the exact submitted bytes and rejection scope. Then compare identities, references, quantities, units, and packing relationships against the current source records and receiver requirements.

Can an LLM explain a DESADV message?

It can help explain redacted text and propose questions for investigation. Verify field meanings and rule claims against the correct directory and partner guide. Do not let a generated explanation invent missing packing data or authorize a production resend. Deterministic validation and traceable business evidence remain necessary.