Orchestrate

The delivery that won't start

Break-fix drill · Finance · about 6 minutes · starts after stage 7 of 11, "Build"

What the user reports

Monday 2 November at Rockford. Hallam Fluid Systems ordered 2 ES-200 pumps this morning, worth about 7,500.00 with tax, and owes Calder nothing. The shipping clerk can't create the delivery: the order is blocked for credit. Last week the credit team finished its annual review of distributor credit profiles.

The error: Delivery for Hallam's order HFS-2304 refused: the order is blocked for credit (limit 4,000.00 in segment CR01).

What you'll do

  1. See the problem as the shipping specialist: On Sales orders, recheck Hallam's order with customer reference HFS-2304, then on Deliveries and shipping create the delivery for it.
  2. Find the cause: Hallam has no open receivables and the order is about 7,500.00, yet the credit check blocks it against a limit of 4,000.00. The approved limit from the review is 40,000.00. What is the right fix?
  3. Fix it as the credit manager.
  4. Prove it: run the step that failed again.

Start the drill

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: Correct Hallam's credit limit in segment CR01 to 40,000.00, then recheck the order so the block clears.

The credit check worked as designed on wrong master data: the limit was keyed as 4,000.00 instead of the approved 40,000.00. Correcting the limit fixes this order and every later one, and the recheck runs the check again with the right number. Releasing the block clears one order but leaves the next Hallam order blocked too, switching the check off removes the control for every customer, and a credit limit belongs to the customer, not the channel.

Why it broke

The credit check adds the customer's exposure (open receivables and open orders) to the new order and compares the total with the limit in the customer's credit profile. The profile said 4,000.00, so even a 7,500.00 order was over. The rule and the order were fine; one master data value was wrong by a factor of ten.

How teams prevent it

Have a second person check credit limit changes against the approved list (four eyes), and report limits that changed by more than, say, half in either direction after each review. A limit is master data with money behind it, so its changes deserve a log someone reads.

Across teams

Shipping saw the block, customer service owns the order, and the limit belongs to the credit manager in finance. The quick fix (release the block) sits with the credit manager too, which is why the right question is "is the limit right?", not "can you release it?".

Where AI fits

A check that flags credit limits changed by a large factor is plain automation. An assistant fits the call that follows: it reads the block, compares the limit with the review record and the customer's payment history, and drafts a correction for the credit manager to approve (retrieve). It shouldn't change limits or release blocks itself: both are finance decisions with an owner.

Learn more: Order to cash end to end

All drills · Back to the lab

Sign in to track your progress

We'll email you a one-time sign-in link. No password needed.

or

Tell us a little about you

Optional, every field. It helps us pitch answers to your questions at the right level and decide which topics to write next. It is never shown publicly, and you can change or clear it anytime from the account menu.

SAP areas you work in