Deleting the paperwork behind a bill
Archive, never delete, is a rule we apply to menu items. We went through every delete in the system and found three that destroyed records of things that had actually happened — including a delivery whose supplier invoice was left behind, owing money, with nothing to explain it.
We have a standing rule: archive, never delete. It was written for menu items, because deleting a dish that appears on last month's orders takes the orders with it. It was implemented for menu items, carefully, and then it stopped.
There are sixty-two delete statements in our system, reaching forty-three different kinds of record. Most of them are settings — a fee tier, a table layout, a price override — where deleting is just what saving looks like. Asking "is this a record of something that happened, or a preference?" is a judgement, so we went through them by hand.
The one that left a bill with no document
Receiving a delivery is the busiest moment in our purchasing side. Stock goes up, each product's cost price is rewritten from what the supplier actually charged, and a pending supplier invoice is raised for what arrived.
The delete on a purchase order had no condition on it at all. Run it against a received delivery and the order disappeared, every line on it disappeared with it — and the invoice it had raised stayed, still owing, now pointing at nothing. A bill for money with the document that explains it destroyed. Two stock movements survived, each naming a purchase order that no longer existed.
What makes this one instructive is that the rule already existed six inches away. Editing a purchase order has always refused anything but a draft. Cancelling refuses a received one. Delete — more destructive than either — was the sibling nobody wrote a rule for.
Two more of the same shape
A supplier invoice could be deleted whatever state it was in, including one marked paid. That is the record that money left the account.
A timecard could be deleted after a manager had approved it. Approving is somebody saying they checked the hours; deleting afterwards throws away the decision along with the evidence.
Both now refuse, and both messages say what the record is rather than "cannot delete".
A guard with no way out is a trap
This is the part worth dwelling on, because we nearly shipped it wrong.
Approving a timecard only ever went one way. There was no un-approve. So a rule that refused to delete an approved card would have made a mistaken sign-off permanent and undeletable — a worse position than the one we were fixing, arrived at by being careful.
So approving became reversible first. The green tick in the office became a button that undoes it, the delete now shows you the refusal instead of failing silently, and the message names a step that actually exists on the screen in front of you.
The invoice needed none of that, because it already had a way back: an invoice can be set to any of its three states, so one raised in error goes back to pending and then deletes.
If you are ever told a record cannot be removed, the right follow-up question is not "why not". It is "then what is the sequence that removes it?" If there isn't one, the protection has become a different problem.