Standard Order

Workflow: Retail
Flow: 850 → 855 → 856 → 810

Purpose

The Standard Order is the baseline retail integration test. It validates your full order-to-cash capability — from receiving a purchase order through to sending your invoice. Every retail integration must pass this scenario. It's also the scenario that powers linked test runs across your trading partner coverage list, so passing it here proves your integration works with all of your retail partners simultaneously.

Steps

Step 1 — Receive Purchase Order (850, inbound)

Your Demo Leader sends a test 850 Purchase Order to your EDI account automatically when the checklist is created. You don't trigger this — it arrives on its own.

What to do: Confirm your system received and parsed the 850. You don't need to do anything in Orderful for this step — it completes when you send a valid 855 in Step 2.

What's validated: The 850 was successfully delivered to your EDI account. Step 1 will show "Acknowledge the 850" until your 855 is received — this is expected and is not an error.

Step 2 — Send Purchase Order Acknowledgment (855, outbound)

Send an 855 that accepts all line items on the 850.

What to do: Generate and send an 855 to your Demo Leader's EDI account on the test stream. Every line item must carry acknowledgment code IA (Item Accepted). Reference the original 850.

What's validated:

Line numbers carry through from the 850 to the 855
All line items are acknowledged with accepted status
Line item references match between the 850 and 855
Product IDs match between the 850 and 855
Acknowledged quantities match ordered quantities
Units of measure are consistent

Step 3 — Send Advance Ship Notice (856, outbound)

Send an 856 confirming shipment of all ordered items.

What to do: Generate and send an 856 referencing your 855. Include all line items from the 855 at their full ordered quantities.

What's validated:

All acknowledged lines from the 855 are present in the 856
Line item and product ID references are consistent with the 855
Quantities match between 855 and 856

Step 4 — Send Invoice (810, outbound)

Send an 810 invoicing for all shipped items at the original ordered price.

What to do: Generate and send an 810 referencing the original 850. Invoice for all shipped lines at the prices from the 850.

What's validated:

All shipped lines from the 856 are present in the 810
Invoice prices match the original 850 prices
Quantities and line references are consistent across the 856 and 810

Seller Initiated Changes

Workflow: Retail
Flow: 850 → 855 (mixed ACK codes) → 856 (accepted and price-changed lines only) → 810

Purpose

Tests your ability to handle line-level complexity in your acknowledgment — where not every line is simply accepted. In this scenario, you respond to the 850 with a mix of acknowledgment codes, and your subsequent 856 and 810 must correctly reflect only the lines that are actually shippable, with price-changed lines invoiced at your updated price.

Steps

Step 1 — Receive Purchase Order (850, inbound)

Same as Standard Order. Your Demo Leader sends a test 850 automatically. Confirm your system received it.

Step 2 — Send Purchase Order Acknowledgment with ACK codes (855, outbound)

Send an 855 with mixed line-level acknowledgment codes.

What to do: Respond to the 850 with an 855 that uses all four line-level ACK codes across the order lines:

IA — Item Accepted (line ships as-is at 850 price)
IB — Item Backordered (line cannot ship now)
IP — Item Price Changed (line ships, but at a different price than the 850)
IR — Item Rejected (line will not ship)

What's validated:

The 855 carries a mix of IA, IB, IP, and IR line-level acknowledgment codes
The overall 850 acknowledgment status is ACCEPTED (the order is accepted even though individual lines vary)
Line references are consistent with the 850

Step 3 — Send Advance Ship Notice (856, outbound)

Send an 856 covering only the lines that are actually shipping.

What to do: Generate an 856 that includes only IA (accepted) and IP (price-changed) lines from your 855. Do not include IB (backordered) or IR (rejected) lines — they are not shipping.

What's validated:

Only IA and IP lines from the 855 appear in the 856
IB and IR lines are correctly excluded
Quantities and line references are consistent with the 855

Step 4 — Send Invoice (810, outbound)

Send an 810 with correct pricing per line type.

What to do: Invoice for all shipped lines (IA and IP). Use the original 850 price for IA lines and your updated 855 price for IP lines.

What's validated:

IA lines are invoiced at the 850 price
IP lines are invoiced at the 855 (updated) price
All shipped lines from the 856 are covered
Line references are consistent across the 855, 856, and 810

Buyer Initiated Changes

Workflow: Retail
Flow: 850 → 860 (buyer change) → 856 → 810

Purpose

Tests your ability to receive a buyer-initiated change to an existing order and correctly reflect those changes in your outbound transactions. When a retailer modifies a PO after it's been placed, they send an 860 — your system must parse that change and update the shipment and invoice accordingly.

Steps

Step 1 — Receive Purchase Order (850, inbound)

Your Demo Leader sends a test 850 automatically. This is the baseline PO that will be modified in Step 2.

What to do: Confirm your system received and parsed the 850. No action needed in Orderful.

Step 2 — Receive Purchase Order Change Request (860, inbound)

Your Demo Leader sends an 860 that modifies the original 850 — adjusting quantities, prices, or line items.

What to do: Confirm your system received and parsed the 860. Your system needs to apply the changes from the 860 to its internal representation of the order. No outbound transaction is required for this step — it completes once the 860 is delivered.

What's validated:

The 860 is successfully delivered to your EDI account
The 860 correctly references the original 850

Step 3 — Send Advance Ship Notice (856, outbound)

Send an 856 that reflects the post-change order state.

What to do: Generate and send an 856 based on the 860, not the original 850. Line quantities and items must match what the buyer requested in their change, not the original order.

What's validated:

Lines and quantities in the 856 match the 860 (not the 850)
Line item and product references are consistent with the 860
The 856 correctly references both the 850 and 860

Step 4 — Send Invoice (810, outbound)

Send an 810 at the post-change quantities and prices.

What to do: Invoice for the shipped goods at the quantities and prices from the 860. Do not invoice at the original 850 values if they were changed.

What's validated:

Invoice quantities and prices match the 860
All shipped lines from the 856 are covered
References are consistent across the 860, 856, and 810

Order Cancellations

Workflow: Retail
Flow: 850 → 860 (full cancellation)

Purpose

Tests your ability to receive and correctly process a full order cancellation. When a retailer cancels an order entirely, they send an 860 with a cancellation transaction set purpose code and all lines marked for deletion. This is a two-step scenario — there is no 856 or 810, because nothing ships.

Steps

Step 1 — Receive Purchase Order (850, inbound)

Your Demo Leader sends a test 850 automatically. This is the PO that will be cancelled in Step 2.

What to do: Confirm your system received and parsed the 850. No action needed in Orderful.

Step 2 — Receive Order Cancellation (860, inbound)

Your Demo Leader sends an 860 that cancels the order entirely.

What to do: Confirm your system received and correctly processed the cancellation 860. Your system should recognise this as a full cancellation and not attempt to ship or invoice against this order.

What's validated:

The 860 carries BCH01 = 01 (transaction set purpose code: Cancel)
Every line item in the 860 carries change code DI (Delete Item)
The 860 correctly references the original 850

There are no further steps. The scenario is complete once the cancellation 860 is delivered and validated.

Load Tender Accept

Workflow: Transportation
Flow: 204 → 990 (accept) → 214 (status updates) → 210 (invoice)

Purpose

The full happy-path transportation scenario. Tests your ability to receive a load tender, accept it, send shipment status updates through the delivery lifecycle, and invoice the shipper at the end. This is the most comprehensive transportation test and covers all four transaction types in the carrier workflow.

Steps

Step 1 — Receive Motor Carrier Load Tender (204, inbound)

Your Demo Leader sends a test 204 Load Tender automatically when the checklist is created.

What to do: Confirm your system received and parsed the 204. No action needed in Orderful — this step completes when you send your 990 in Step 2.

What's validated: The 204 was successfully delivered to your EDI account.

Step 2 — Send Load Tender Acceptance (990, outbound)

Send a 990 confirming you will haul the shipment.

What to do: Generate and send a 990 Response to a Load Tender with B103 = A (Accept). Reference the original 204.

What's validated:

The 990 carries B103 = A
The 990 correctly references the originating 204

Step 3 — Send Shipment Status Updates (214, outbound)

Send 214 status messages as the load moves through its lifecycle.

What to do: Generate and send 214 Carrier Shipment Status Messages covering the key lifecycle events — at minimum pickup, in-transit, and delivery. Up to 10 status messages are validated.

What's validated:

Each 214 references the correct shipment from the 204
Status codes and events are in a logical sequence
Up to 10 status messages are evaluated in chronological order

Step 4 — Send Freight Invoice (210, outbound)

Send a 210 invoicing the shipper for the completed haul.

What to do: Generate and send a 210 Motor Carrier Freight Details and Invoice for the shipment. Reference the originating 204.

What's validated:

The 210 references the correct 204
Invoice amounts and shipment details are consistent with the accepted tender

Load Tender Decline

Workflow: Transportation
Flow: 204 → 990 (decline)

Purpose

Tests your ability to decline a load tender. When you cannot or do not want to haul a shipment, your system must send a properly-formed decline response. This is a two-step scenario — no 214 or 210 follows a decline.

Steps

Step 1 — Receive Motor Carrier Load Tender (204, inbound)

Your Demo Leader sends a test 204 automatically. The scenario is set up as a decline — your carrier will reject the load in Step 2.

What to do: Confirm your system received the 204. No action needed in Orderful.

Step 2 — Send Load Tender Decline (990, outbound)

Send a 990 declining the load tender.

What to do: Generate and send a 990 with B103 = D (Decline). Reference the original 204.

What's validated:

The 990 carries B103 = D
The 990 correctly references the originating 204

The scenario is complete after the decline. No further transactions are required.

Load Tender Counter Offer

Workflow: Transportation
Flow: 204 → 990 (counter offer)

Purpose

Tests your ability to propose modified terms rather than accepting or declining a load tender outright. A counter offer 990 proposes changes — for example, an adjusted pickup window or different equipment — instead of a simple accept or decline code. Your system needs to correctly structure and send a counter offer response.

Steps

Step 1 — Receive Motor Carrier Load Tender (204, inbound)

Your Demo Leader sends a test 204 automatically. The scenario is set up as a counter offer — your system will respond with modified terms in Step 2.

What to do: Confirm your system received the 204. No action needed in Orderful.

Step 2 — Send Load Tender Counter Offer (990, outbound)

Send a 990 proposing modified terms.

What to do: Generate and send a 990 that proposes changes to the load tender terms — for example, an adjusted pickup window using the G62 segment, or different equipment specifications. The 990 should reference the original 204 and include the modified terms your system is proposing.

What's validated:

The 990 correctly references the originating 204
The 990 carries the appropriate counter offer structure with modified terms (e.g. G62 for time/date adjustments)
The response is not a simple accept (A) or decline (D) — it includes proposed modifications

The scenario is complete after the counter offer is sent and validated.