The system would not book in a full sack from a supplier
A stock system refused 100 kg received against a 90 kg order, so clerks edited the agreed order to get goods shelved. The rule was the fault.
You ordered ninety kilograms of a material. The supplier sent a full sack, a hundred, rather than opening one. Your clerk tries to book it in and the system refuses. There is no way forward.
The clerk has two options. Record ninety and let ten kilograms of real stock exist nowhere in your books. Or go and edit the purchase order so it says a hundred, which changes a document agreed with the supplier and possibly already invoiced, just to make a receipt possible. Both are wrong, and the second is what people actually do, because the goods are on the floor and the job is to put them away.
What was actually going on
The order line carried a running total of how much had been delivered, and a rule saying that total may not exceed the quantity ordered. The rule was written as if it described reality. It described a preference.
“You cannot receive more than you ordered” is not true of the world. Suppliers over-ship. They round up to a whole packing unit. They send a replacement for a damaged item with no paperwork. They deliver next month’s order early. Each one is a real event that a warehouse has to record, and a system that cannot record it stops being a record of what happened and becomes a record of what was supposed to happen.
The delivered total caused a second problem. It was a stored figure, while the real receipts lived separately, one row per delivery, each with its own date and quantity. That is the right structure, since partial deliveries are normal. But a receipt could be deleted, and when it was, nothing recalculated the total. The line then showed more delivered than the receipts added up to, the outstanding quantity was understated, and the buyer never chased a delivery that had never arrived.
There were two quieter faults of the same kind. The receipts table marked removed rows with a yes-or-no flag, while most of the system uses a removal date, so any reusable code that looks for the date would count deleted receipts. And the delivery status used the same words on the order line and on each receipt, although they answer different questions: on a receipt, did this delivery happen; on a line, how much is still outstanding.
What we changed
We removed the rule and added an over-receipt flag on the line, so the receipt goes in and the line shows why it is unusual. The purchase order stays exactly as agreed. The difference is visible to the buyer, who is the person with authority to decide whether to argue with the supplier about it.
For the stored total we kept it, maintained it in the application and added a reconciliation job that compares it with the receipts and reports every difference. Deriving the total from the receipts would be more trustworthy, and a database-maintained total next best. This was the weakest of the three options and was sometimes the only one available in an existing system.
What it did not fix
Because the total is still stored, it can still drift between reconciliation runs, and a total that is reconciled is not the same as one that cannot disagree. The two ways of marking a removed receipt, and the status words shared by line and receipt, are recorded here as findings. They are not recorded as fixed.
The pattern, for anyone who books goods in
Before a system refuses something, ask whether a person could walk into your building holding a counterexample. If they could, the refusal is a policy, not a fact, and a policy belongs somewhere a human can override it and sign their name.
A rule that stops a stock level going below zero is a fact, because a bin cannot hold less than nothing. A rule that stops receiving more than ordered is not. It should let the truth in and draw attention to it: a flag, an exception report, a tolerance, or an approval step.
Check one more thing. Ask your vendor what happens to the delivered figure on a purchase order when a receipt is deleted.
Where this ends up
That is why over-delivery on a goods receipt is a policy question in Sazinga Factory and not a fixed rule: procurement, production and stock share a single figure, and the figure has to match what is on the shelf.