Lesson 6 of 6
Testing the supplier flow
8 min
Listen to this lesson
Procurement EDI looks simple in a demo: send an 850, get an 855 and an 856, receive the goods. Production is full of partial confirmations, late dates, split shipments and suppliers who resend. Priya's test design for Lakeside Components covers those cases on purpose, each with an expected SAP result taken from configuration, not from what happened to come out.
Two layers of testing
Test the SAP side alone first, with WE19 in CMQ: copy a real ORDRSP or DESADV IDoc, change the PO number and quantities, and run Standard Inbound. That is fast and repeatable. Then run each critical case end to end: a real purchase order in CMQ, an 850 through XQ1 to Lakeside's test system, and Lakeside's 855 and 856 back through XQ1. The end-to-end run proves the mappings and Lakeside's behavior, which WE19 cannot.
The test cases
| ID | Case | Expected SAP result |
|---|---|---|
| P2P-EDI-01 | New PO for 500 CMC-RTR-200, plant 1710, $21,000 | NEU output processed; ORDERS IDoc 03; 850 in XQ1 monitor |
| P2P-EDI-02 | PO over $25,000 | No output until approved; output processed after release |
| P2P-EDI-03 | Quantity change 500 to 450 | ORDCHG via ME11; 860 in XQ1; no second 850 |
| P2P-EDI-04 | Full confirmation 855 on requested date | ORDRSP 53; one AB line for 500; creation indicator 3 |
| P2P-EDI-05 | Split confirmation 300 + 200 a week later | Two AB lines; MRP view shows two receipts |
| P2P-EDI-06 | Second 855 restating only 200 | Previous AB lines replaced; 200 confirmed; buyer alerted by the daily list |
| P2P-EDI-07 | Date outside key tolerance | Warning or 51 according to the configured message; workflow item if 51 |
| P2P-EDI-08 | PO item without confirmation key | ORDRSP 51 with key message; fix and reprocess gives 53 |
| P2P-EDI-09 | ASN for 300 (partial) | DESADV 53; inbound delivery for 300; LA line; 200 open |
| P2P-EDI-10 | ASN beyond tolerance | DESADV 51; no inbound delivery; long text names the quantity |
| P2P-EDI-11 | Duplicate ASN resend | Detected by the shipment ID rule or the duplicate monitor; second delivery cancelled |
| P2P-EDI-12 | Goods receipt against inbound delivery (171S) | GR 101 in 171S; PO history shows GR with delivery reference |
Lakeside Components procurement EDI test set (expected results from Contoso configuration).
Test data that makes the cases repeatable
Most failed EDI test cycles fail on data, not on configuration. Before the first run, Priya's team prepares a small, documented data set in CMQ client 100: supplier 17300001 with the WE20 profile pointing to XQ1, a purchasing info record for CMC-RTR-200 with Lakeside's material number, price $42.00 and confirmation control key 0001, a second info record for a test material without a key (for the negative case), and PO item tolerances set to the values the expected results assume. Lakeside's test system receives the same PO numbers range, so its testers can find the orders.
Each case also states its starting condition. P2P-EDI-06 only makes sense if P2P-EDI-05 left two confirmation lines on the item; P2P-EDI-12 needs an inbound delivery from P2P-EDI-09. Writing those dependencies down lets a tester rerun one case without rerunning the whole chain, and lets a reviewer see why a case failed when its predecessor did.
Two habits make these tests worth signing. First, every expected result comes from configuration: the tolerance on the PO item, the date message setting, the key's sequence. If a tester writes "should probably fail" the test is not ready. Second, negative cases are run deliberately, with their own evidence. P2P-EDI-08 and P2P-EDI-10 prove that errors are caught and explained, which matters as much as the happy path.
What would you do?
In P2P-EDI-10, Lakeside's test 856 for 600 rotors against 500 ordered creates an inbound delivery for 600 instead of failing. The tester marks the case failed. What should happen next?
- Test the SAP side with WE19 in CMQ, then prove each critical case end to end through XQ1 with Lakeside's test system.
- Cover partial and split confirmations, replaced acknowledgments, date tolerance, missing keys, partial and excess ASNs and duplicates.
- Every expected result comes from configuration; negative cases need their own evidence.
- Keep a small regression set for upgrades, tolerance changes and the middleware move.
Check your understanding · not graded
Lesson check
1. Why run end-to-end tests through XQ1 when WE19 already proves the SAP side?
2. Where should the expected result for an ASN beyond tolerance come from?
3. Which case proves that a missing confirmation key is caught and explained?