The Rotation You Cannot Switch Off

Rotation policy is normally a configuration question. Ours is not a question at all. Every path that takes stock out of a location sorts the available batches by expiry date, oldest first, and there is nothing anywhere that changes it.

How it actually works

Every allocation orders the candidate batches by expiry date, treating a missing date as the far future. That single rule produces the behaviour you want in all three cases without any special handling: dated batches rotate properly, undated batches are consumed only when nothing dated is available, and a mixture behaves sensibly rather than arbitrarily.

The allocations are recorded, so a batch's history shows what was taken from it and when. That is what makes a recall traceable one step forward, which is the half of traceability that is usually missing.

The column that looks like a setting

There is a rotation-policy column on the item record. It is written by nothing, read by nothing, and exposed in no screen — it exists in a migration and in two internal registries and nowhere else.

We are publishing that because a dead column is a specific kind of hazard. If you find it — through the API, through an export, through a developer looking at the schema — it reads as a per-item rotation policy that somebody has left unset. It is not. Setting it, if you could, would accomplish nothing.

The rotation is stricter than the schema suggests. That is the opposite of the usual error, and it is still an error.

This is the fifth field of that shape we have published — alongside a bin capacity that enforces nothing, a count-plan frequency that schedules nothing, approval value thresholds that route nothing, and a pick sequence that sorts nothing. The pattern is worth carrying into any evaluation, of any product: a field you can see is not evidence of a behaviour you can rely on.

When you would legitimately want to relax it

Rarely, and it is worth being honest about the cases rather than pretending there are none.

• A customer specifies a minimum remaining shelf life. A retailer refusing anything with less than two-thirds of its life left means the oldest batch is precisely the one you cannot send them. Under a strict rule you have to allocate to that order by moving stock, not by choosing a batch.
• A batch is quarantined but not expired. Held stock is excluded from allocation, which handles this correctly — but only if somebody has actually placed the hold. The rotation rule will happily allocate a batch nobody has flagged.
• Non-perishables where expiry means something else. A date used as a manufacture reference rather than a use-by will still drive the rotation, because the field is the field.
• A promotional or contract batch bought for one customer. Nothing ties a batch to a commitment, so the rotation rule will allocate it to whoever asks first.

The general shape of all four is the same: the rule is right about shelf life and knows nothing about commitments. Where those conflict, the resolution is physical — separate locations — rather than configurable.

Why Irish food and drink distribution is the right place to write this

Because it is a sector where remaining shelf life is a contractual term rather than a preference, and where the customer base is concentrated enough that a single retailer's specification shapes how you have to hold stock.

In that setting an unconditional rotation rule is mostly a gift — it is the behaviour you would have configured anyway, applied consistently by something that never gets tired at four in the afternoon. And the exception, when it comes, is not a rotation exception at all. It is a segregation problem, and the answer is a location.

Frequently asked questions