The purchase order that won't save
What the user reports
Monday 2 November at Rockford. The buyer converts this morning's requisitions to purchase orders. Impellers and seal kits go through; the motor requisition for Orrin Motor Works is refused. Last week the master data team merged a duplicate Orrin record.
The error: Purchase order for the motor requisition refused: supplier 20000001 isn't set up for company code CP10.
What you'll do
- See the problem as the buyer: On Purchase requisitions, convert the
CP-MTR15requisition to a purchase order with purchasing organization PUUS and group P01. The supplier, Orrin (20000001), comes from the info record. - Find the cause: Orrin exists as a business partner and has purchasing data for PUUS. Why is the purchase order refused, and what fixes it?
- Fix it as the master data specialist.
- Prove it: run the step that failed again.
The drill runs in the lab on its own prepared copy of the fictional Calder Pumpworks, saved in this browser apart from your company. All codes and values are fictional course labels.
Answer and explanation (open after the drill)
The fix: Orrin has no company code data for CP10, so finance has no account or terms to post its invoices with.
A supplier is one business partner with several layers: general data, purchasing data per purchasing organization, and company code data per company code. The company code layer carries the reconciliation account and payment terms finance needs to post Orrin's invoice and pay it. The purchase order checks every layer it will need later, so it stops now rather than at the invoice. The other choices name settings that are in place: PUUS buys for CP11, the info record has its price, and the requisition points at 20000001.
Why it broke
Purchasing and finance each keep their own layer of the supplier. The re-created record had the purchasing layer, so it looked complete to the buyer, but finance's layer for CP10 was missing: no reconciliation account to post the payable to and no terms to set a due date. The lab refuses the order at once and names the missing layer.
How teams prevent it
Treat a supplier as complete only when every layer the processes need exists: general, purchasing per purchasing organization, company code per company code. A merge or re-creation of a duplicate should copy all layers and end with a check against the list, and a new layer should go through the same review as the rest of the record.
Across teams
The buyer saw the error, the master data team made the change that caused it, and the missing data belongs to finance. That chain is typical for master data: the person who finds the gap is rarely the one who owns it.
Where AI fits
A completeness check after every merge or new supplier is plain automation: a rule over the layers. An assistant fits around it: it reads the error, finds the supplier's layers and drafts the master data request with the values from a similar supplier for a person to confirm (retrieve). It shouldn't create finance data itself: reconciliation accounts and payment terms are finance's decision.
Learn more: Master data that every module depends on