AWRA OpsHub Search

One Stock Vocabulary Across Till and Warehouse

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.

Point of Sale AWRA OpsHub Team 11 min read

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

A warehouse issuing to jobs Correct
A distributor invoicing customers Correct
A shop with a counter and a store Understated
A shop that sells only at the till Zero
Business types given a wrong answer Two of four

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 scoped to its workspace on a different column from the rest of the product. Every other module scopes on one workspace 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.

Till sales and stock reporting, precisely

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.

More we can add to your workspace

  • 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 workspace column across every module — the till declares its own.
  • An 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.

Where we point you to a specialist

  • 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.
  • This is market-neutral. 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.

More we can add for you

What we can build for the Indian Ocean islands on top of the standard product

Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for the Indian Ocean islands, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product 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 specific to how your operation runs, or a link to a system you already have 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 integrated

Our 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 modules

Frequently 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.

Share this article

LinkedIn X WhatsApp

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center