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.