The Number You Typed Is Recalculated at One
Every item's reorder point is recomputed at one in the morning from thirty days of demand, a lead time and a safety stock. Nothing is excluded from the sweep, which means a number somebody typed by hand survives until the next time the job runs.
Our take
An automatically maintained reorder point is a genuinely good idea, because the alternative is a number set once during implementation and never revisited while demand doubles around it. The formula is the standard one and it is honest. What matters operationally is the scope: the sweep touches every item, not only the ones configured for it, so the reorder point is a derived figure rather than a setting. Type a number into that field and it is correct until one in the morning. The lever that actually works is the pair of inputs — lead time and safety stock — because those are what the formula reads, and a lead time nobody has filled in makes the whole calculation resolve to the safety stock alone.
Somebody sets the reorder point for cement to two hundred bags on Thursday afternoon. By Friday morning it is sixty, and nobody changed it.
What runs, and when
At one o'clock each morning a job recalculates the reorder point on every item in every workspace. It runs on a single server, never overlaps itself, and reports its own start, finish, duration and any failure to the scheduled task register — so a sweep that stopped working is visible rather than silently absent.
It works out demand for the last thirty days, divides by thirty for a daily rate, multiplies by the item's lead time, adds the item's safety stock, and rounds up.
The calculation, in full
This is the textbook formula and there is nothing exotic in it. The interesting decisions are all about what feeds it.
Three properties worth knowing
-
Every item is recalculated, not only the configured ones
The sweep has no filter. An item with no lead time, no safety stock and no recent movement is written to zero — and a reorder point of zero means the item is never short, because nothing is ever below it. This is the single most consequential property of the job.
-
A missing input counts as zero, not as unknown
Lead time and safety stock both default to zero when absent. So an item with real demand and no recorded lead time gets a reorder point equal to its safety stock alone, which for most catalogues is also zero.
-
The window is always thirty days
Not thirty days of trading, not since the item was created. An item introduced a week ago has its week of demand divided by thirty, which understates its rate by roughly four times. New items settle into a true figure about a month after launch.
The reorder point is derived, not configured
This is the practical takeaway and it is worth saying without hedging. The field is writable and the value you write is real until the sweep next runs. If you want a specific reorder point to persist, the way to get it is to set the lead time and safety stock that produce it, because those are the two values the formula actually reads and the only two it leaves alone.
What counts as demand
Demand is measured from consumption recorded against adjustments that have actually been applied. That is a narrower definition than "everything that left the warehouse", and knowing which of your outbound flows it covers is the difference between a reorder point that reflects reality and one that reflects a fraction of it.
The practical check takes ten minutes: pick a fast-moving item, look at what the sweep computed, and compare it against what you know left the shelf last month. If the computed figure is a small fraction of what you expected, your main issue path is not the one being counted, and the reorder points across the catalogue will be uniformly low in the same proportion.
A formula is only as wide as the events it can see.
One number, every building
The reorder point lives on the item, so it is one figure for your whole organisation. Stock balancing compares each warehouse and location against that single number to decide where there is too much and too little. For a business running one store that is exactly right; for one running a central warehouse and four branches it means the branch that turns over four times as much as the others is measured against the same line.
Worth being deliberate about, because the consequence is asymmetric. A single figure set to suit the busiest site makes the quiet ones look permanently overstocked, and set to suit the quiet ones makes the busy one run out. Neither is a fault in the calculation; both are the honest result of one number describing several different demand patterns.
What AWRA OpsHub does today
- A nightly recalculation at one in the morning across every item in every workspace, running on a single server and never overlapping itself.
- The standard formula — average daily usage over thirty days, multiplied by lead time, plus safety stock, rounded up.
- Lead time and safety stock stored per item, as the two inputs the calculation reads and the two it never overwrites.
- Demand measured from consumption recorded against applied adjustments, so a movement that was raised and never applied does not inflate the figure.
- Start, finish, duration and failure of the sweep reported to the scheduled task register, so a job that stopped running is visible rather than silently absent.
- A cross-organisation sweep declared as such, with demand keyed on item so no workspace's consumption can reach another's reorder point.
- Stock balancing suggestions built from the same figure, comparing each warehouse and location against it to propose internal transfers.
- A low stock reminder sent daily, so a figure crossing its line reaches somebody.
More we can add to your workspace
- A per-warehouse reorder point, so a busy branch and a quiet one are each measured against a line that suits them.
- An opt-out per item, letting a manually set reorder point stand for the items where somebody has a better reason than the formula does.
- A configurable demand window, so a seasonal business can measure against a comparable period rather than the last thirty days.
- A shorter window for new items, dividing by days since introduction rather than always by thirty.
- A wider definition of demand, counting every outbound movement rather than the one path currently measured.
- A record of what the reorder point was before each recalculation, so a figure that moved sharply can be explained rather than investigated.
- Seasonality or trend in the calculation, rather than a flat thirty-day average that treats last Tuesday and last month identically.
Where we point you to a specialist
- We will not silently stop maintaining a figure because somebody typed over it. A derived number that sometimes updates and sometimes does not, depending on invisible history, is harder to reason about than one that always updates — so the honest design is either to recalculate everything or to offer an explicit opt-out, and the opt-out is the item named above.
- Choosing your safety stock is a commercial judgement about service level and working capital, and it stays yours. We will hold the number and use it; publishing a default would be arbitrary across the range of businesses running this.
- Where a supplier contract, a licence or a regulator obliges you to hold a minimum quantity, that obligation governs and belongs on the record as a floor you set, not as something a demand formula is allowed to move.
A per-item opt-out and a per-warehouse figure are the two contained pieces here, and between them they cover almost every reason an organisation wants to overrule the nightly number.
A reorder point that fits your shape
The job, the formula and the inputs all exist. What organisations ask for is scope and override — a figure per site, and a way to say "leave this one alone".
A reorder point per warehouse
Demand measured per site and a line per site, so a branch turning over four times as much is not measured against the same number as the quiet one.
A manual override that holds
An explicit opt-out per item, so a figure somebody set for a reason survives the sweep and says who set it.
A window you choose
Thirty days is right for steady demand and wrong for seasonal trade. A configurable window, and a shorter one for items too new to have thirty days behind them.
We publish scope, not dates.
Scope reorder pointsFive questions to ask about an automatic reorder point
Is the number I type kept?
A good answer sounds like
A straight answer.
What ours actually is
Until one in the morning. The sweep touches every item, so a typed figure is replaced by the calculated one.
What is the formula?
A good answer sounds like
Written down.
What ours actually is
Thirty-day usage divided by thirty, times lead time, plus safety stock, rounded up.
What happens with no lead time recorded?
A good answer sounds like
Named behaviour.
What ours actually is
It counts as zero, so the reorder point becomes the safety stock alone — which is usually zero as well.
Is the figure per warehouse?
A good answer sounds like
A clear scope.
What ours actually is
One figure per item for the whole organisation, compared against each warehouse and location by stock balancing.
How do I know the job ran?
A good answer sounds like
A status, not a guess.
What ours actually is
It records its start, finish, duration and any failure to the scheduled task register.
Fill in two fields, not one
Lead time and safety stock are the two values the nightly job reads and the two it never touches. An afternoon spent populating them for your fastest fifty items is worth more than any amount of editing the number they produce.
Talk through stock policyFrequently asked questions
Why does the reorder point I set keep changing?
Because it is recalculated nightly for every item, without exception. The field is writable and the value holds until one in the morning, at which point the formula replaces it. To make a specific figure persist, set the lead time and safety stock that produce it — those are the inputs the calculation reads, and the only two it leaves alone.
Why is the reorder point zero on most of my catalogue?
Almost always because lead time and safety stock are empty and the item has had no recorded consumption in the last thirty days. Both missing inputs count as zero, so the formula resolves to zero — and an item with a reorder point of zero is never reported as short, because nothing is ever below it. This is the most common cause of a low stock report that never fires.
Does it work per warehouse?
No. The reorder point is a single figure on the item, applied across your whole organisation. Stock balancing compares each warehouse and location against that one number when suggesting internal transfers. For a multi-branch business with very different demand per site, a figure per warehouse is the change that matters and it is named above.
What counts as demand?
Consumption recorded against adjustments that have actually been applied, over the last thirty days. That is narrower than every outbound movement, so it is worth checking against a fast-moving item you know well. If the computed usage is a fraction of what you expect, your main issue path is not the one being measured, and every reorder point in the catalogue will be low in the same proportion.
What about seasonal stock?
A flat thirty-day average handles seasonality badly by design — it will chase a peak upward a month late and chase it downward a month after it ends. For genuinely seasonal trade the useful answer is a configurable window or a comparable-period comparison, both of which are on the list above. In the meantime, safety stock is the lever that absorbs the difference.
How do I know the calculation ran last night?
The job records its start, its finish, how long it took and any failure to the scheduled task register, and it never overlaps itself or runs twice across servers. That matters more than it sounds: a nightly recalculation that quietly stopped would leave every reorder point frozen at whatever it was on the day it died, and nothing about the numbers themselves would look wrong.
