The Monthly That Never Comes
A count plan in our system asks you how often you intend to count, requires an answer, validates it and stores it. Nothing then happens on that rhythm — no session is raised, ever. The field is not missing, which is what makes it dangerous: a plan reading "monthly" looks exactly like a control that is running.
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 have one of these in our stock counting module, and we found it while writing about something else.
What the plan asks you, and what it 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.
It is stored faithfully. It is shown back to you. And there is nothing anywhere in the product that reads it. No scheduled job, no background task, no reminder. A plan that says monthly raises exactly as many counts as a plan that says annually, which is none, forever.
The rhythm is not missing from the product. It is recorded in the product and performed by nobody.
It is the third one of these, and that is the real finding
A single inert field is an oversight. Five is a pattern worth naming, and naming it is more useful to you than any of the individual bugs. Three were known when this post was written and two more turned up in the same week of auditing, which is itself the point.
Settings in our product that are saved and read by nothing
- The count plan frequency — required, validated, stored, and never scheduled. The subject of this post.
- A per-item first-expiry policy — a column written by nothing and read by nothing. As it happens the underlying behaviour is better than the setting implies, because expiry ordering is applied unconditionally everywhere, but the field itself does nothing at all.
- Value thresholds on the approval engine — stored against rules, and not consumed by the approval path, which gates on permissions instead.
- A capacity on every storage location — settable on three screens and checked by nothing, so a shelf can never be full. Argued in the shelf that cannot be full.
- An entire supplier performance record — on-time delivery, quality score and pricing trend — that no code has ever written a value into. Argued in the scorecard nobody fills in.
All three share 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, 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 costs almost nothing, because the count happens when the manager decides it happens 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.
When the plan is inert, that assurance is not weakened, it is imaginary — and it is imaginary in the specific way that is hardest to catch, because the plan exists, it is correct, it reads monthly, and everybody who looks at it concludes that counting is under control.
How much of the counting discipline is actually enforced by the system
The count rhythm
Stored on the plan and acted on by nothing. This is the subject of this post.
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 pattern here is the useful part: the counting module is strong almost everywhere, and the single weak point is the one thing that decides whether any of it ever happens.
What to do about it today
Put the rhythm somewhere that has a clock. A recurring task assigned to the branch manager, a calendar entry, a line in a monthly close checklist — anything that will produce a consequence when it is missed. The count plan holds the scope, the blind setting and the variance thresholds, and all of that works; it simply cannot be what reminds you.
And treat this as a question to ask about every scheduling field in every system you run, not just ours. 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 is 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 is the easy thing, and it happens to be the thing that decides whether any of the rest ever runs. If you operate from one building, put the rhythm in a recurring task and you have lost nothing. If your branches are far enough apart that the plan is how you supervise them, understand that today the plan is a statement of intent with nothing behind it, and ask us — and everyone else — to show you a count appearing on its own.
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, or an admission. Ours is an admission.
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 cannot answer it.
Why it matters
Coverage is the question a plan is supposed to be answering. If nothing reports it, the plan is decoration.
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.
Which settings in this product are stored but not yet acted on?
What a straight answer sounds like
Discomfort, then an honest list. Ours has three and they are named in this post.
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
- 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.
What it does not do
- The count frequency does nothing. It is required, validated and stored, and no session is ever raised from it.
- No reminder or overdue notice, so a plan that has not run since March looks identical to one that ran last week.
- No count accuracy measure — variance is captured per line, but nothing aggregates it into a score, a trend, or a comparison between counters or locations.
- No coverage report, so "which of my locations have not been counted this quarter" has no answer in the product.
Not ours, by choice
- 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 is worth a whole post.
Three, and the first is a day
The scope, the blind setting and the variance thresholds are all built and working. What is missing is a clock and a way to see whether it ran.
A scheduler that raises the count
A daily job that looks at each plan, works out whether a session is due on its stated frequency, and creates one. The plan model already carries everything this needs. This is the smallest of the three and it is the one that makes the field honest.
Overdue visibility
A plan that has not produced a count when it should have, surfaced to somebody — with the branch, the plan and how long it has been. A schedule without an overdue state is only half a control, since the failure mode is silence.
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; nothing aggregates it. Without this, a counting programme cannot be managed, only performed.
We would ship the first two together, because a scheduler with no overdue state replaces one silent failure with another. The third is the one that turns counting from an activity into a measurement, and it is the one most customers will notice.
Talk to us about stock countingTell us how many sites and how far apart
We will show you what the counting module enforces today, what depends on somebody remembering, and how customers in the same position are covering the gap while the scheduler is built.
Talk to us about counting