Batch book and silo deduction: why domain bookings must not simply be deleted

In many applications, delete is the fastest way to fix a mistake. The record was wrong, so it disappears. In a batch or material flow that is dangerous. A booking has already changed quantities, times and downstream state. The silo is lighter, the batch book has a line, the daily log is counting on that batch. Deleting the row hides the mistake. It does not undo the effect.

A practical picture: someone picked the wrong raw material, the scale weighed, the deduction ran. Soft-delete on that row leaves the silo where it is after the deduction, while the screen pretends nothing happened. The next shift inherits a gap that nobody can pin to a voucher. Reports become polite. Stock does not.

The better operation is a reversing entry. It keeps history, makes the correction visible and keeps reports honest. Cancellation is the related case when the batch should not take place but the deduction has already been written. Reconcile is the case in which hall and system have drifted and someone has to name the difference instead of overwriting it.

It looks like more work in the application. It avoids the larger kind: overnight gaps between silo, recipe and log that nobody can explain. A reversing entry costs a screen and a rule. An invisible correction costs a shift spent searching.

CRUD is a weak model here. Create and read still fit. Update after weighing is often already too much. Delete is almost always wrong once a downstream state has been written. If you let the ORM offer a cascade, you have handed the domain question to the library.

For technical decision-makers: model irreversibility where the hall requires it. Not where the form offers a bin button. If you are unsure, ask what still has to be true at six if someone opened the wrong batch at half past two.