Batch log and silo deduction: why domain postings must not be deleted

In many applications, deleting is the fastest way to fix a mistake: the record was wrong, so it goes. In a material or batch flow that is dangerous. A posting has already changed quantities, times and downstream data. The silo is emptier, the batch log has another line, and the daily log is counting on that batch. Deleting the row makes the mistake invisible and leaves its consequences in place.

An example: someone picks the wrong raw material, the scale weighs, the deduction runs. A soft delete on that row leaves the silo level as it was after the deduction, while the screen looks as if nothing happened. The next shift takes over a difference that can no longer be matched to any record. The report looks fine afterwards, and the stock is still wrong.

A reversal is the better choice. It keeps the history, makes the correction visible and keeps the reports right. A cancellation fits when the batch should never have happened but the deduction has already been written. A reconciliation fits when actual stock and system have drifted apart and someone has to name the difference.

That means a little more effort in the application: one screen and one rule. An invisible correction, by contrast, often costs a whole shift of searching when silo, recipe and log drift apart overnight and nobody can explain why.

The usual CRUD thinking is of little help here. Create and read fit. Update is often already too much after weighing. Delete is almost always wrong once downstream data has been written. Leaving that to the ORM and its cascade option means making a domain decision without noticing.

My advice to technical decision-makers: settle what cannot be undone in the process before anyone adds a bin button. When in doubt, one question helps: what still has to be right at six if someone created the wrong batch at half past two?