The test the books never heard about
What the user reports
Monday 21 December. Rockford's floor sends its confirmations to the core as messages. The four ES-200 on the order for four were assembled, tested and confirmed on the floor, and the warehouse has received all four pumps. The controller wants to settle the order before the holidays.
The error: Settlement refused: the order still has an unconfirmed operation, 0020 Pressure test. The test technician says the test was confirmed on Friday.
What you'll do
- See the problem as the cost controller: On Production orders, Settle the order for four ES-200.
- Find the cause: The dispatch list says the pressure test was confirmed on the floor; on Production orders, 0020 has no actual hours. Where is the test's confirmation?
- Fix it as the integration 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: In the interface queue: the floor sent it as an upload message, it failed on the way and nobody reprocessed it.
With the upload on, a confirmation on the floor becomes a message, and the hours post only when the interface delivers it. This one timed out three times and the floor system stopped retrying, so it sits as Failed on Floor system interface: the floor thinks the test is done, the books don't. Nothing else is wrong, so delivering it again is the whole fix. Floor confirmations don't wait for month end or for approval in this lab.
Why it broke
An interface between two systems can fail quietly. The floor system recorded the test, sent the message, got no answer three times and gave up; the core never knew. Nothing was wrong with the data, so the message only had to be delivered again. Until then the order looked 720.00 cheaper than it was, and settlement, the one step that needs every operation, was the first to notice.
How teams prevent it
Someone owns the interface queue and looks at it every day, not when a controller complains: failed messages raise an alert with the order and the operation. Retries back off and keep trying for longer than a short outage. A daily comparison of what the floor confirmed against what the books booked (the comparison on Floor system interface) catches anything the alert misses, and the month-end checklist includes an empty queue.
Across teams
The test technician did the work and sees it as confirmed; the controller can't settle and sees a cheap order; the integration specialist owns the queue; the production supervisor answers for both. A lost confirmation also hides cost from the cost center report and, with backflush, can leave stock looking higher than it is.
Where AI fits
Watching a queue and raising an alert is plain automation. A model can help where volume is high: group failed messages by cause (timeouts, data errors, sequence holds) and say which can simply be reprocessed (classify), or flag a work center whose floor and book confirmations drift apart (predict). Reprocessing a timeout can be automated once the cause is known; a data error needs a person.
Learn more: How SAP systems talk: integration styles and when to use each