The truck that should have left yesterday
What the user reports
Monday 21 December. Brennock's second order (2 ES-200, reference BWU-PO-5648) is packed and needed on 30 December, nine days from today, and the transportation planner wants to tender it to Larkspur. On Friday the logistics analyst updated the lanes from Larkspur's new transit table.
The error: Tender refused: the freight order should have left by 20 December, and no carrier can pick it up in the past.
What you'll do
- See the problem as the transportation planner: On Freight planning, tender the freight order for BWU-PO-5648 to Larkspur Freight Lines under FA-LFL-2026.
- Find the cause: The pumps are needed in nine days and Brennock is 140 km away. The message says the truck should already have left. What makes the departure lie in the past?
- Fix it as the transportation planner.
- 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: The departure is the need date less the lane's transit days, and the lane to Brennock now says 10 days for 140 km.
Freight planning works the departure back from the customer: the date the goods are needed less the transit days on the lane to that customer. With 10 days instead of 1, the truck would have had to leave on 20 December. The departure isn't stored on the freight order; it is read from today's lanes, which is why dissolving and planning again gives the same answer. The requested date is still 30 December, and the agreement has no notice period.
Why it broke
A lane's transit days drive every date that freight planning works back: the latest departure, the pickup date in a tender and the expected arrival. One wrong digit made 140 km a ten-day trip, so the pickup date fell before today. The error is honest about the symptom (no carrier picks up in the past) but points at the plan, while the cause is master data.
How teams prevent it
Check lane changes for plausibility before saving them: transit days against distance (140 km in 10 days is under 15 km a day), and against the old value. Compare the planned arrival with the carrier's actual arrivals from the execution events, so a lane that's wrong in either direction shows up as a pattern. Load a new transit table in the test system first.
Across teams
The transportation planner can't tender, the shipping team has a pallet waiting and customer service has a date promised to Brennock. Lanes belong to transportation master data, usually kept by a logistics analyst; carriers supply the transit times, and execution events show what the trucks really take.
Where AI fits
A plausibility rule (days per kilometre, change against the old value) is plain automation. A model can predict transit time per lane from the execution events of past trips and flag lanes whose planned days don't match what trucks take (predict), which is the same data an arrival-time prediction learns from. It should suggest a correction for the analyst, not change the lane.
Learn more: Warehouse and transportation execution