The Monthly That Never Came
A count plan in our system asks you how often you intend to count, requires an answer and stores it. Until 1 October 2026 nothing then happened on that rhythm — no session was ever raised. Now a daily job opens the count when the plan says it is due, and tells the person who has to do it.
The most expensive kind of missing feature is not the one that is absent. It is the one that is present, configurable, saved successfully, and connected to nothing — because an absent feature makes somebody ask a question, and a stored setting makes them stop asking.
We had one of these in our stock counting module. We found it while writing about something else, published it, and on 1 October 2026 we wired it. This post now describes both halves: what the field used to do, and what it does today.
What the plan asks you, and what it now does with the answer
Setting up a count plan is a considered piece of design. You define what is in scope, who counts it, whether counters can see the expected quantity, and what size of variance needs review. And you are asked how often the count should run — a required field, offered as a fixed set of choices, refused if you leave it blank, defaulting to monthly if you say nothing.
For months that answer was stored faithfully, shown back to you, and read by nothing. A plan that said monthly raised exactly as many counts as a plan that said annually, which was none.
Today a plan also carries a next due date and an assignee. Every morning a scheduled job looks for active plans whose date has arrived and opens a count session from each one — the same session you would get by pressing the button yourself, with the plan's scope, its blind and freeze settings and its due window. The assignee is told in the app, or the person who created the plan if nobody is assigned, and the next date moves on one period. Opening a count from a plan by hand moves the date on too, so a manager who counts early does not get a second count a week later.
The rhythm used to be recorded in the product and performed by nobody. Now the product performs it, and a named person hears about it.
Two details are deliberate. If the previous count from the same plan is still open, the job does not stack a second one on top of it; it skips that day and moves the date on. And a plan set to on demand is never opened automatically, because on demand means exactly that.
It was one of five, and that was the real finding
A single inert field is an oversight. Five is a pattern worth naming, and naming it was more useful than any of the individual bugs. Four of them were wired on the same day this one was.
Settings in our product that were saved and read by nothing
- The count plan frequency — required, validated, stored, and never scheduled. The subject of this post. Wired 1 October 2026.
- A per-item stock rotation policy — a column written by nothing and read by nothing. It now chooses earliest-expiry-first or first-received-first per item on every allocation path. Wired 1 October 2026. Argued in the rotation you could not switch off.
- A capacity on every storage location — settable and checked by nothing. It now shows on-hand against capacity, warns on an edit that leaves a location over, and raises a Smart Alert. Wired 1 October 2026. Argued in the shelf that could not be full.
- An entire supplier performance record that no code had ever written a value into. It now holds each vendor's scorecard, refreshed nightly. Wired 1 October 2026. Argued in the scorecard nobody filled in.
- Value thresholds on the approval engine — stored against rules, and not consumed by the approval path, which gates on permissions instead. This one is still open.
They all shared a shape. Somebody designed the right model, built the surface to capture it, shipped that, and the part that would act on it was left for later. Later did not arrive on its own, and nothing failed loudly enough to remind anyone — because a stored value looks identical to a working one from every screen in the product.
A field that does nothing is not a small bug. It is a claim, made by the software, that something is being taken care of.
Why this matters more the further apart your sites are
For a single warehouse the inert setting cost almost nothing, because the count happened when the manager decided it happened and the plan was never doing the remembering. The person and the rhythm are in the same building.
Now run distribution across a country that is long — a head office in one city, branches strung out along the coast and inland, some of which nobody from head office will visit this quarter. The plan is not a convenience there. It is the supervision. It is the mechanism by which somebody in Cairo knows that stock in Alexandria and Aswan is being verified on a rhythm, without being present to see it.
While the plan was inert that assurance was not weakened, it was imaginary — the plan existed, it was correct, it read monthly, and everybody who looked at it concluded that counting was under control. With the schedule wired, the count now appears in the Aswan branch on the morning it is due, assigned to a named person, whether or not anybody in Cairo remembered.
How much of the counting discipline is actually enforced by the system
The count rhythm
A due count is opened and assigned on its own. What is still recorded only: a count that runs late, or a day skipped because the last one was still open.
Who may count
Permission-gated properly — counting, reviewing and approving are separable.
Blind counting
If the plan hides expected quantities, the counter genuinely cannot see them.
Variance review
A session cannot be closed while lines are unreviewed. This is a hard stop, not a warning.
Recount of a disputed line
A per-line recount with a reason and an audit entry; an approved line cannot be quietly edited.
Writing variances to stock
A variance raises an adjustment for approval rather than moving stock directly.
The weak point used to be the one thing that decided whether any of the rest ever happened. It now happens on its own; what is left is noticing when it happens late.
What to do about it today
Give every plan an assignee and a first due date, and check the frequency is the one you meant — a plan left at the monthly default will now produce a count every month. If a plan exists only so somebody can start a count when they choose, set it to on demand.
And keep asking the question this post started with, of every scheduling field in every system you run, ours included. The test is not whether the field exists. It is whether anything has ever happened because of it.
The verdict
Everything hard about stock counting was built here and built well — blind counts, per-line recounts with reasons, sessions that refuse to close over unreviewed variances, and a count that cannot silently rewrite your stock. The one thing missing was the easy thing, and it happened to decide whether any of the rest ever ran. Since 1 October 2026 a plan opens its own count on the date it is due and tells a named person. What a far-flung operation still needs on top is a view of the counts that ran late and the locations that were never counted — and that is the next thing we would build.
Four questions to ask about any scheduling setting
Set a plan to weekly. Show me the count it raises next week.
What a straight answer sounds like
A session appearing on its own, assigned to somebody. Ours now does this.
Why it matters
This is the whole test. Every scheduling field in every system should be asked to demonstrate one occurrence.
Which of my locations has not been counted this quarter?
What a straight answer sounds like
A report. Ours is the next thing we would build.
Why it matters
Coverage is the question a plan is supposed to be answering. If nothing reports it, somebody has to work it out.
What happens when a scheduled count is missed?
What a straight answer sounds like
An escalation, a flag, or nothing.
Why it matters
A schedule with no consequence for being missed is a preference, not a control. Ours logs a skipped day; surfacing it is the next build.
Which settings in this product are stored but not yet acted on?
What a straight answer sounds like
Discomfort, then an honest list. Ours had five and four were wired on one day.
Why it matters
Every mature product has some. A vendor who can name theirs is telling you they know their own system.
What AWRA OpsHub does today
- Counts opened on the plan's schedule. A daily job opens a session from every active plan whose due date has arrived, with the plan's scope, blind and freeze settings and due window, and moves the next date on one period.
- The assignee told in the app when a scheduled count opens — or the plan's creator, where nobody is assigned.
- Blind counting that is genuinely blind — where the plan says so, the counter cannot see the expected quantity.
- Per-line recount with a reason and an audit entry, so a disputed line is settled without re-running the whole count and an approved line cannot be quietly changed.
- Sessions that will not close over unreviewed lines, which is a hard refusal rather than a warning.
- Variance thresholds on the plan, so large discrepancies are separated from rounding.
- Variances raised as adjustments for approval, rather than written straight to stock — so a count cannot silently rewrite your inventory.
- Separable permissions for counting, reviewing and approving.
More we can add to your workspace
- An overdue notice for a scheduled count, so a count that runs past its due window, or a day skipped because the last count was still open, reaches a person rather than a log.
- A count accuracy measure — variance is captured per line, and aggregating it into a score, a trend and a comparison between counters or locations is the build.
- A coverage report, answering which of your locations have not been counted this quarter in one screen.
Where we point you to a specialist
- We publish no statutory stocktake requirement for any country in this region. Where a rule appears anywhere on this site it carries a date and a source, and this would not.
- We are not presenting the counting module as weak. It is one of the better-built parts of this product, which is exactly why one inert field in it was worth a whole post — and worth fixing.
The clock is built. Two pieces remain
The scope, the blind setting, the variance thresholds and now the schedule are all built and working. What is left is seeing when the schedule slipped, and measuring what the counts found.
Overdue visibility
A scheduled count that has passed its due window without closing, or a day the schedule skipped, surfaced to somebody — with the branch, the plan and how long it has been. The schedule already writes the event; this puts it in front of a person.
Coverage and accuracy reporting
Which locations were counted, when, and how accurate they turned out to be. Variance is already captured per line, so the raw material is there. Without this, a counting programme can be run but not managed.
The scheduler shipped on its own because it was the piece that made the field honest. Overdue visibility is the half that makes it a control rather than a convenience, and it is the one we would build first.
Talk to us about stock countingTell us how many sites and how far apart
We will show you a plan opening its own count, what the counting module enforces today, and what still depends on somebody noticing.
Talk to us about counting