The Till Sells. The Reorder Point Does Not Hear It.

A reorder point is a promise: when stock falls to this number, somebody will be told, and there will still be enough time to buy more before the shelf is empty. It is one of the few pieces of inventory mathematics that pays for itself immediately, and it is also one of the easiest to have quietly stop working without anyone noticing — because a promise that is not kept looks exactly like a promise that was never needed.

Nobody files a support ticket saying "the low-stock alert did not fire". They file one saying "we ran out of the thing we sell most", weeks later, and the alert never enters the conversation.

This post is about a specific version of that failure in AWRA, why it happens, and the single field that fixes it. It is worth reading even if you use something else, because the underlying trap is not ours alone.

The calculation, in full

There is no mystery in the formula. It is the standard one, it runs every night at one in the morning, and it looks at the last thirty days.

Read that formula for a moment with a value of zero in the usage position. The first term collapses — anything multiplied by nothing is nothing, no matter how long the lead time — and the reorder point becomes whatever the safety stock is. If safety stock is also unset, the reorder point is zero.

That is the entire mechanism of the failure. Everything else here is about how usage comes to be zero for an item you sell every single day.

What counts as usage

Measured usage is stock that left through the check-out workflow — the screen a storekeeper uses to issue stock to a department, a project, a site or a person — and only once the resulting adjustment has been posted. A check-out sitting unposted does not count yet. A posted one does.

For a very large class of business that is exactly right. A school store issuing to departments, a hospital store issuing to wards, a construction company issuing to sites, an NGO issuing to programmes — all of them move stock through check-outs, and their reorder points compute correctly from the day they start.

A sale at a till is a different path entirely. It reduces stock, correctly and immediately, through the stock service — but it does not create a check-out and it does not create a posted adjustment. It is a sale, recorded as a sale.

The counter reduces your stock and the calculation never hears about it. Both statements are true at the same time, which is why this is hard to notice.

So for an item that only ever leaves through the till, measured usage over thirty days is zero. Not approximately zero — exactly zero, because the query counts a different kind of movement.

What zero does to the alert

A reorder point of zero does not produce an alert that fires constantly, which is what people assume when they hear a threshold has collapsed. It produces the opposite, and the exact behaviour depends on which screen you are looking at.

That table is the reason this is worth a page rather than a footnote. An alert that fires late is annoying. An alert that cannot fire is invisible, and a dashboard tile reading zero items needing reorder is indistinguishable from a business in excellent shape.

The fix, which is one field

Set safety stock on the items that sell through the counter. That is it.

It works because of where safety stock sits in the formula. It is added, not multiplied — so it survives a measured usage of zero completely intact. An item with safety stock of forty and no measured usage gets a reorder point of forty every night, and the alert fires at forty units exactly as you intended.

Two things follow from that which are worth being explicit about, because both are counter-intuitive.

• Lead time on its own does nothing for a counter-only item. It multiplies against measured usage, so at zero usage a lead time of two days and a lead time of ninety days produce the same answer. Set it anyway for correctness, but do not expect it to raise the floor by itself.
• Typing a reorder point directly does not stick. The nightly job writes a reorder point for every item, calculated from the formula. A number entered by hand is replaced at one in the morning. Safety stock is an input to that calculation, which is exactly why it is the field that holds.

That second point is the one that catches people, and it catches them silently — the number is right when they leave in the evening and wrong when they arrive in the morning, and the natural conclusion is that somebody changed it.

1. List what actually sells at the counter

   Take a month of sales, sorted by quantity. The top fifty items are where the entire value of this exercise sits; the long tail can wait or stay empty.

2. Decide a floor for each, in days rather than units

   Ask how many days of cover you want before reordering, then multiply by typical daily sales. Thinking in days makes the number defensible; thinking in units makes it a guess that gets copied down a column.

3. Set safety stock to that number

   Set it on the item. Leave the reorder point alone entirely — it is an output, and the nightly job owns it.

4. Set lead time honestly too

   It does nothing for a counter-only item today, but it costs nothing and it is correct for anything that also moves through check-outs. It also means the figure is already right if your usage pattern changes.

5. Check the morning after

   Come back the next day and confirm the reorder points now read what you expect. This is the step people skip, and it is the only one that proves the change took.

6. Revisit quarterly

   Sales patterns move. A floor set once and never reviewed becomes wrong in the direction of your growth, which is the expensive direction.

Why this shape of bug is common everywhere

It is worth pulling back from our specific version, because the pattern behind it turns up in every inventory system, and recognising it is more useful than memorising one instance.

Any system that grows a second way of moving stock inherits the question of whether the analytics were told. The first path — issue to a department, post the adjustment — gets built with the reporting. The second path arrives later, correctly reduces the stock figure because that is obviously required, and quietly does not appear in a query written when only one path existed.

The result is always the same: a number that is right for one kind of business and silently wrong for another, with no error, no warning, and a perfectly plausible-looking value on screen. Zero is the most dangerous plausible value there is, because it reads as "nothing to worry about" in almost every context a person might see it.

The fourth question is the one that most reliably surprises people. Nobody thinks the difference between "at or below" and "strictly below" matters until a threshold reaches zero, at which point one of them still works and the other cannot fire.

What good looks like once it is set

With safety stock set on the items that matter, the machinery does what it was built to do. The nightly job produces a floor for every item. Items at or below it appear in the low-stock report and on the item risk flags. The dashboard count becomes a real count. Transfer suggestions start proposing a move from the branch holding a surplus rather than a purchase order, which is the cheaper answer whenever it is available.

None of that required a change to the software. It required knowing which of the four inputs the calculation was going to be able to measure, and filling in the ones it could not.

The mathematics behind the formula is set out in reorder point and safety stock, the multi-branch consequences in running multi-branch retail, and the catalogue discipline all of it depends on in the till will not sell what you have not listed.

Frequently asked questions