Lesson 5 of 5
Testing master data with probe purchase orders
9 min
Master data is easy to look at and hard to prove. A supplier record can look perfect on screen and still produce a PO with the wrong payment terms, because a partner function points somewhere else or a plant-specific info record overrides the general one. The reliable test is to let the system use the data: create a probe purchase order and check what it proposes.
What a probe PO is
A probe PO is a test PO created with as little input as possible, so the master data has to fill everything else. You enter the product, quantity and plant (and, depending on the test, the supplier), accept every proposal and compare the result with an expected-values sheet. In a test client like 100, you can then post a receipt and an invoice to prove accounts. In production, master data teams sometimes create probe POs and then delete them without sending output; agree this with the process owner first.
- Expected valuesWrite down what each field should be before you start
- Minimal inputProduct, quantity, plant; leave supplier empty to test source determination
- Capture proposalsSupplier, price, payment terms, incoterms, delivery date, purchasing group, GR-based IV
- Post follow-ons (test client)Goods receipt and invoice to see accounts and matching behavior
- Compare and recordPass or defect for each field, with document numbers as evidence
The expected-values sheet
| Check | Where it comes from | Expected for CMC-RTR-200 / plant 1710 |
|---|---|---|
| Supplier proposed | Source list fixed entry or regular supplier | Lakeside Components |
| Net price | Info record or contract condition | $42.00 per unit |
| Payment terms | Supplier purchasing org data | Net 30 |
| Incoterms | Supplier purchasing org data or info record | FCA |
| Delivery date | Planned delivery time (plus GR processing time for planning) | PO date + 10 days |
| Purchasing group | Product purchasing view or info record | 001 |
| GR-based invoice verification | Supplier purchasing org data | Set |
| Inventory account at goods receipt | Valuation class in accounting view | Raw materials inventory |
| Price difference at goods receipt | Price control S, standard $40.00 | $2.00 per unit to price differences |
Contoso's expected-values sheet for the rotor probe PO.
Negative probes
Positive probes prove the right data is used. Negative probes prove controls work. Try a blocked source: the PO should be refused. Try a product without a valid source list entry where one is required: the PO should be refused. Try a supplier blocked for purchasing: the PO should be refused. Each negative probe is a short test, and each one proves a control the auditors will ask about.
Probes are not only for go-live. Keep a small set as a regression pack and rerun it after changes that touch master data: a new purchasing organization, a change to account determination, a mass price update or a release upgrade. Because the expected values are written down, a rerun takes minutes and shows at once whether anything moved.
What would you do?
A probe PO for rotors in plant 1720 proposes $44.00, but the expected value is $42.00 and the purchasing org info record shows $42.00. What do you check next?
- Probe POs prove master data by letting the system fill a PO from minimal input.
- Write expected values before testing; compare field by field.
- Negative probes prove controls such as blocked sources and required source lists.
- Post receipt and invoice in a test client to prove account determination.
Check your understanding · not graded
Lesson check
1. What is a probe purchase order?
2. Why write expected values before creating the probe PO?
3. Which is a negative probe?
4. How do you prove the valuation class is right?