The Module That Speaks a Different Language
Stock leaves this system by two paths that share no vocabulary. The till decrements stock without writing the record everything else writes, so a report that reads only that record tells a shop selling entirely through the counter that it consumed nothing at all.
The worst kind of reporting defect does not throw an error, produce a warning or look odd. It returns zero, and zero is a number a business will believe about itself for a surprisingly long time.
Two doors out of stock
Stock leaves this product two ways. Adjustments, customer invoices, procurement issues and asset conversions all write a check-out row — one shared record, one shared verb, one place to count from.
The till does not. It decrements stock through the location allocation service directly and never writes a check-out. Not sometimes; never.
So any report that counts consumption by reading check-outs reports zero for a shop that sells entirely through the counter. Not an error, not an empty state, not a warning. A confident zero, on a screen, next to a chart.
What a checkouts-only consumption figure says
The fourth row is the dangerous one, because a zero reads as "no data yet" rather than as "this report cannot see your business".
An error gets fixed the day it appears. A zero gets explained away for a quarter and then stops being looked at.
How it was found, and what was done
It was found while building an inventory turnover and days-of-inventory report, because turnover is consumption divided by average stock and somebody had to decide what consumption meant.
The answer that shipped sums both paths and does not deduplicate them, because they genuinely do not overlap — a unit sold at the till has no check-out anywhere, and a unit issued to a job has no till line. The reasoning is written into the code as a comment rather than left as tribal knowledge, which is the part worth copying.
The same method also excludes inter-warehouse transfers deliberately: moving stock between your own locations consumes nothing, and counting it would inflate turnover for any multi-branch business. That is the mirror-image mistake and it is easier to make.
The second divergence, which is stranger
The till is tenanted on a different column from the rest of the product. Every other module scopes on one tenant identifier; the sale model declares its own, and returns a different column name.
That is not a defect — it is consistent within itself and the framework supports declaring it. What it means is that any query written against till data by someone who has not read that declaration will join on the wrong column and return nothing, which is the same failure mode as the first one: silence, not an error.
The general shape, since it is not really about tills
Any module that arrived separately — bought, bolted on, or written by a different team in a different quarter — will have at least one of these. A different verb for the shared event, a different column for the shared key, a different name for the shared concept. The cost is not in the module. It is in every cross-cutting report written afterwards by somebody who assumed one vocabulary.
Four questions about cross-module reporting
Does this report include till sales?
A good answer sounds like
Yes, and they can say how.
What it actually means
Ask it of every stock report individually. The answer is not uniform in our product and is unlikely to be uniform in anyone's.
What does a zero mean on this chart?
A good answer sounds like
No activity — and they can prove it.
What it actually means
The distinction between "nothing happened" and "I cannot see it" is invisible on a chart and decisive in practice.
Do all modules record stock movement the same way?
A good answer sounds like
An honest no, with a list.
What it actually means
A confident yes usually means nobody has checked. Ours is a no and it is written into the code.
Show me turnover for a till-only branch.
A good answer sounds like
A plausible number.
What it actually means
The single test that would have caught this, and it takes thirty seconds on real data.
What AWRA OpsHub does today
- Stock decremented correctly by the till, through the same location allocation service the rest of the product uses, with batch and expiry ordering applied.
- An inventory turnover and days-of-inventory report that sums both consumption paths, with the reasoning recorded in the code rather than in somebody's memory.
- Deliberate exclusion of inter-warehouse transfers from consumption, so multi-branch turnover is not inflated.
- One cost basis shared by till margin analytics, valuation and the accounting integrity check, after the three had disagreed.
What it does not do
- A check-out record written by the till. It decrements stock without one, and always has.
- A single shared movement vocabulary across all modules. There are two, and they do not overlap.
- A common tenant column across every module — the till declares its own.
- Any automated check that a new stock report has considered both consumption paths.
- Category or location roll-ups, a trend chart or a benchmark on the turnover report.
Not ours, by choice
- The divergence is a history rather than a design, and the honest fix is not to rewrite the till but to make sure every cross-cutting report knows about both paths. That is the approach taken.
- The turnover report is correct on this point today. Older reports written before it should be treated as suspect until checked, and we would say the same about any product of this age.
- Nothing here is Malagasy. Madagascar is here because small till-only retail is the dominant shape there, and a till-only shop is precisely the business a checkouts-only figure lies to.
What is not built for the Indian Ocean islands today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in the Indian Ocean islands. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a national tax pipeline, a local payroll engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax pipelines, one country at a time
Electronic invoicing or fiscalisation against your authority's published interface, with retries, a failure queue and a daily report of invoices carrying no reference. Said carefully, because this region has no shared framework to hide behind: Mauritius runs real-time fiscalisation through certified providers, and the other three are unrelated regimes on unrelated timetables. That makes each of these a country build, and in Mauritius specifically an accreditation rather than an integration — which is a different kind of commitment and priced as one.
Bank feeds and genuinely multi-currency operations
Bank statement and card settlement feeds into the Payments Register, across the several currencies an island business actually transacts in. This is the shared condition of the region: almost everything is imported, the freight and the goods are frequently invoiced in different currencies, and the reporting currency is nobody's only working currency.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social contribution schedules per country, computed on live records and produced in the layout each filing body expects. Four countries here means four engines rather than one, and none of them is built today.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
When a stock report shows you a zero, do not accept it. Sell one thing at the till and refresh: if the number does not move, the report cannot see half your business. That test costs a minute, applies to any system, and is the only reliable way to find this class of defect from the outside.
Test the zero
The most useful thing you can do in any evaluation is make one transaction of each kind and check that every report notices. Most do not get tested this way, which is exactly why it works.
Talk about reporting across modulesFrequently asked questions
Does the till update stock levels correctly?
Yes. Stock is decremented through the same allocation service the rest of the product uses, including batch and expiry ordering. The divergence is in what record is written alongside the decrement, not in whether the decrement happens.
Which reports are affected?
The turnover report handles both paths deliberately. Any report that predates that work should be checked with the one-sale test above rather than assumed correct, and that is a fair thing to ask us to do with you.
Why not make the till write a check-out?
It would be the cleaner data model and it is a migration with live history on both sides rather than a refactor. Making every report aware of both paths is the safer order to do it in, and it is honest to say the underlying divergence is still there.
