There Is No Moment When Nothing Happens
Low stock announces itself: there is a moment when the quantity crosses the line, and something can be hung on that moment. Stock that has stopped moving has no such moment, because it is defined by the absence of one — so it has to be gone looking for.
Nobody opens a report about stock that is not moving. Not moving is precisely why it is not on anybody's mind.
There are two kinds of thing worth alerting on, and almost every system only ever handles the first.
Something happened
- Stock falls below its reorder point.
- There is an instant when it crosses the line.
- The code writing the stock can check, right there.
- The alert fires at the moment of the change.
- Easy, and correct, and what everybody builds.
Nothing happened
- Stock has not moved in ninety days.
- There is no instant. Nothing occurred.
- No code runs, because no code was called.
- The alert has to come from something that went looking.
- Harder, rarer, and where the money is sitting.
Dead stock is defined by nothing happening, so it has to be scanned for.
This is a genuinely useful distinction to carry around, well outside inventory. A subscription that stopped renewing, an integration that stopped receiving, a colleague who stopped submitting timesheets, a supplier who stopped quoting — every one of them is a non-event, and every one of them is invisible to alerting built on things happening.
A report is not a control
A dead stock report already existed, and it was accurate. That was the problem it did not solve.
A report waits to be opened. Anything that appears only in a report is competing for attention against everything already on somebody's mind — and the defining property of dead stock is that it is not on anybody's mind. The report was correct and unread, and the capital stayed tied up.
So the same measurement was turned around: instead of waiting to be asked, it goes and finds items that have stopped moving and pushes them at somebody. Same figures, opposite direction.
Two details that decide whether it is trusted
It measures idleness exactly as the report does — the same field, with the same fallback to the item's creation date for something that has never moved at all, over the same population of items that actually have stock on hand.
That sameness is deliberate and it is the whole basis of trust in the alert. If the alert and the report used slightly different definitions of idle, they would disagree, and the alert would become noise — a message contradicted by the screen it points you at.
It fires once per item and remembers. The item is stamped when alerted, so it is not reported again the following night. The stamp is cleared the next time the item moves, so an item that is revived and later goes quiet again is alerted afresh.
That is the difference between an alert and a nightly list. A permanent non-mover, reported every night for a year, teaches everybody to ignore the message.
The window is one number, and zero switches it off
The idle period is set per workspace and defaults to ninety days. Setting it below one turns the alerting off entirely rather than alerting on everything, which is the sensible reading of somebody deliberately clearing the field. There is also a dry run that reports what would fire without stamping anything or sending anything — worth using before changing the window, because a shorter window on a first run alerts on the whole backlog at once.
Three ways to make the finding actionable
Detecting the non-event is the hard half and it is done. What turns a detection into a decision is context the alert does not yet carry.
The capital in the alert
The value tied up alongside the count, so a hundred idle low-value items and one idle expensive one are not the same message.
One digest rather than many alerts
A single weekly summary ranked by value, since the whole point is that these arrive in batches after a quiet period.
A disposal path from the alert
Marking an item for clearance, write-down or transfer from the message itself, so the finding leads somewhere rather than being noted.
We publish scope, not dates.
Scope dead stock alertingThree questions to ask about any alerting you rely on
Which of your alerts detect an absence?
A good answer sounds like
A short list, named.
What ours actually is
Dead stock is the clear one. Ask this of any system — most alerting covers only things that happen, and the answer is often none.
Does the alert measure the same way the report does?
A good answer sounds like
The same fields, deliberately.
What ours actually is
The same field with the same fallback, on purpose. An alert contradicted by the screen it links to gets ignored within a fortnight.
Does it repeat every night?
A good answer sounds like
No, it fires once and resets on activity.
What ours actually is
Once per item, cleared the next time the item moves. A nightly repeat of a permanent condition trains people to dismiss the message.
Our take
The engineering here is modest and the idea behind it is worth more than the feature. Alerting is almost always built on the write path, because that is where an event is available to hang something on — and everything that consists of an absence is therefore structurally invisible to it. Going and looking is the only implementation, and it needs a schedule, a memory of what has already been reported, and a way to forget once the condition clears. All three are present. What the alert does not yet carry is money: an item idle for ninety days is a fact, and the value tied up in it is what decides whether anybody acts.
What AWRA OpsHub does today
- A scheduled scan that finds items with stock on hand which have not moved for the configured idle period, rather than waiting for somebody to open a report.
- Idleness measured with the same field and the same fallback the report uses, so the alert and the screen it points at cannot disagree.
- Items that have never moved at all covered, by falling back to when the item was created.
- One alert per item, stamped so it is not repeated the following night.
- That stamp cleared the next time the item moves, so a revived item that later goes quiet is alerted again.
- The idle window configurable per workspace, defaulting to ninety days, with a value below one switching the alerting off rather than alerting on everything.
- A dry run that reports what would fire without stamping items or sending anything.
- The scan runnable for one workspace at a time.
- Unit cost resolved from the item's weighted average cost, falling back to its buying price.
More we can add to your workspace
- The value tied up shown in the alert, so the message distinguishes a hundred idle low-value lines from one idle expensive one.
- A single ranked digest rather than separate alerts, since these arrive in batches by their nature and a batch of individual messages is a batch nobody reads.
- A disposal action from the alert itself — clearance, write-down or transfer — so a finding leads somewhere.
- An idle window that varies by category, so a slow-moving spare part and a fast consumable are held to different expectations.
- Seasonality awareness, so stock that is idle every winter and sells every summer is distinguishable from stock that has genuinely stopped.
- A trend on how much capital is sitting idle, so the total is a figure that can be managed down rather than a list that is worked through.
Where we point you to a specialist
- We would decline to have the system act on idle stock by itself — writing it down, marking it for clearance or moving it. What to do about capital tied up in stock is a commercial judgement with a cost either way, and the alert exists to put it in front of the person who makes that judgement.
- Where an accounting standard governs when slow-moving or obsolete stock must be written down, that standard governs and we point you to your own advisers on where the line sits. Our part is to surface the age and the value promptly enough that the decision can be made on time.
The value tied up, shown in the alert and totalled in a weekly digest, is the piece that turns this from a notification into something a finance lead manages. Both figures are already resolved by the scan.
Ask which of your alerts detect an absence
Whatever systems you run, list the alerts you receive and mark the ones triggered by something failing to happen. For most organisations the answer is none, and the failures that consist of nothing happening are the ones nobody is watching.
Talk through alertingFrequently asked questions
Why does dead stock need a scan when low stock does not?
Because low stock has a moment. Something writes a stock figure, the figure crosses the reorder point, and the code doing the writing can check right there. Dead stock is defined by no such write occurring, so no code runs and there is nothing to hang a check on. The only implementation is something that goes and looks on a schedule.
How is idleness measured?
By when the item last moved, falling back to when it was created for an item that has never moved, over items that actually have stock on hand. Those are exactly the same fields the dead stock report uses, and that sameness is deliberate: an alert measuring idle slightly differently from the report would send you to a screen that disagreed with it, and an alert contradicted by its own evidence is ignored within a fortnight.
Will I be told about the same item every night?
No. Each item is stamped when it is alerted and is not reported again while that stamp stands. The stamp is cleared the next time the item moves, so an item that is revived and later goes quiet is alerted afresh. A permanent non-mover reported nightly for a year would teach everybody to dismiss the message, which is the usual way this kind of alerting dies.
What is the default idle period?
Ninety days, set per workspace. Setting it below one switches the alerting off rather than alerting on everything, which is the sensible reading of somebody deliberately clearing the field. There is also a dry run that shows what would fire without stamping or sending anything — worth using before shortening the window, because a shorter window on its first run alerts on the entire backlog at once.
Does the alert tell me how much money is involved?
Not yet, and it is the item we would scope first. The scan already resolves a unit cost from the item's weighted average cost, falling back to its buying price, so the figure is available. Putting it in the message and totalling it in a weekly digest is what turns a list of idle items into a number a finance lead can manage down.
Does the system do anything about the idle stock?
No, and we would decline to. Writing stock down, marking it for clearance or moving it are commercial judgements with a cost whichever way they go. The value of detecting a non-event is putting it in front of the person who makes that judgement early enough for the decision to still be worth making.
