Implementation reference
Amazon EDI testing: exercise the failures a happy-path 856 cannot show
One accepted sample proves only one path through one mapping. A go-live gate needs negative cases, boundary cases, hierarchy variations, replacement/retry behavior, and reconciliation with the physical shipment sources.
Direct answer: Build an executable fixture corpus covering every supported hierarchy and shipment type, every envelope/control mismatch, invalid and duplicated identifiers, quantity boundaries, multi-PO parentage, original/replacement behavior, acknowledgements, and source-to-source mismatches. Run it automatically after every mapping or ruleset change.
Separate the test layers
| Layer | What it proves | Example failure |
|---|---|---|
| Parser | Delimiters and raw transactions are read faithfully | Truncated ISA or mixed terminators |
| Envelope/schema | Controls, counts, required fields, and enums | ST02/SE02 mismatch or missing API party ID |
| Business rule | Current documented requirements are applied | Missing BOL for a covered LTL flow |
| Reconciliation | Independent sources agree | MAN SSCC differs from label scan |
| End-to-end | An operator can understand, correct, and revalidate | Finding has no usable location or fix |
| Retry/chaos | Timeouts and duplicate delivery remain safe | Webhook/API retry creates duplicate state |
Keeping the gates separate tells the team whether a regression is in parsing, serialization, a rule, mapping logic, or user experience.
Minimum adversarial fixture corpus
- One accepted shipment for every hierarchy profile and shipment type you support.
- ISA/IEA, GS/GE, ST/SE, IEA group-count, and SE segment-count mismatches.
- Duplicate, missing, and forward HL references.
- Missing PO, item identity, or quantity data at each relevant level.
- Valid and invalid SSCC check digits, duplicate SSCCs, and a label-scan mismatch.
- Zero, negative, fractional, over-shipped, and wrong-unit quantities.
- Small parcel, LTL, and FTL variations with missing or contradictory references.
- Multi-PO examples with deliberately crossed carton/order parentage.
- Original, corrected, replaced, replayed, and timeout-after-success submissions.
- Payloads at size, segment-count, nesting, and execution-time limits.
Test the evidence shown to the operator
A validator that says only “invalid” still leaves the expensive work to the user. Contract tests should pin every finding’s stable code, severity, segment/element or JSON Pointer, evidence class, source URL, rule-pack date, explanation, and corrective action.
When the source material changes, add or modify the failing fixture first. Then update the rule and its citation. Do not let a live page, validator result, and downloadable sample drift independently.
Release evidence to retain
- Ruleset and application versions.
- Source revision or retrieval date.
- Fixture checksums.
- Unit, feature, browser, accessibility, mutation, and chaos results.
- Production smoke results against non-sensitive samples.
- Named decision for any account-specific warning intentionally accepted.
The repository’s accepted and rejected samples are executed by backend and browser tests, preventing a downloadable asset from becoming a decorative, stale file.
Common questions
How many ASNs are enough?
There is no universal count. Cover every distinct hierarchy, shipment type, integration path, boundary, and known defect; add each confirmed production incident as a regression fixture.
Does a static sandbox replace local testing?
No. Local deterministic validation gives fast, exhaustive feedback. Partner testing proves behavior at the integration boundary. Both are needed because they answer different questions.
Primary sources
Public sources cannot establish every account-specific EDI rule. Current Vendor Central documentation and your trading-partner agreement remain controlling.