Retail integration testing validates your order-to-cash EDI workflow — the full cycle from receiving a purchase order through to sending your invoice. Before going live with any retail partner, you need to prove your system can correctly handle each stage of this cycle, including the variations you'll encounter when orders change or get cancelled.
Transactions covered
Retail testing exercises the 800-series transaction set:
| Transaction | Direction | Purpose |
|---|---|---|
| 850 Purchase Order | Inbound | Your retailer sends you a PO to fulfill |
| 855 PO Acknowledgment | Outbound | You confirm receipt and respond to each line item |
| 856 Advance Ship Notice | Outbound | You notify the retailer that goods have shipped |
| 810 Invoice | Outbound | You bill the retailer for shipped goods |
| 860 PO Change Request | Inbound | Your retailer modifies or cancels an existing PO |
Scenarios
Retail testing is broken into four scenarios, each covering a distinct order flow. You need to pass all four before your retail integration is considered complete.
| Scenario | Flow |
|---|---|
| Standard Order | 850 → 855 → 856 → 810 |
| Seller Initiated Changes | 850 → 855 (mixed ACK codes) → 856 (accepted lines only) → 810 |
| Buyer Initiated Changes | 850 → 860 (buyer changes) → 856 → 810 |
| Order Cancellations | 850 → 860 (full cancellation) |
Standard Order
The baseline scenario. Your retailer sends a straightforward purchase order and you complete the full order-to-cash cycle — acknowledging the PO, confirming shipment, and invoicing for all ordered items at the original price. This is the foundational test that every retail integration must pass.
Seller Initiated Changes
Tests your ability to handle line-level complexity in your 855. Rather than accepting all lines as-is, your 855 must respond with a mix of acknowledgment codes — accepted (IA), backordered (IB), price-changed (IP), and rejected (IR) — at the individual line level. Your 856 and 810 must then correctly reflect only the shippable lines (IA and IP), with IP lines invoiced at your updated price rather than the original 850 price.
Buyer Initiated Changes
Tests your ability to receive and act on a buyer-initiated 860 PO Change Request. Your retailer modifies the original PO — adjusting quantities, prices, or line items — and you need to reflect those changes in your subsequent 856 and 810. Your outbound transactions must reference the post-change state, not the original 850.
Order Cancellations
Tests your ability to receive a 860 that cancels an order entirely. The cancellation 860 carries a transaction set purpose code of 01 (cancel) and marks every line with change code DI (delete item). Your integration needs to recognise and correctly process a full order cancellation — this is a two-step scenario with no 856 or 810 required.
What's validated
Each retail scenario validates two things independently:
Business logic (your Demo Leader run) — enforces the correctness of the full workflow: line item references carry through between transactions, acknowledgment statuses are consistent, quantities and prices align across the 855, 856, and 810, and the right lines appear in each outbound document.
Partner guideline rules (your linked test runs) — validates that each outbound transaction passes the specific field requirements, code values, and segment constraints of each of your retail partners. These rules vary by partner and are enforced independently per linked test run.
Both must pass for each scenario before a partnership can move to Ready.
See Leader linked testing for how linked test runs work across multiple retail partners.