Neither Here Nor There
Stock leaves the Douala warehouse on a Tuesday and arrives inland a few weeks later. For that whole interval it is yours, it is paid for, and it appears in no warehouse's stock figure — which is fine when the gap is an afternoon and quietly serious when it is not.
Almost every inventory system in the world treats a transfer between your own warehouses as an administrative detail. Stock leaves one place, stock arrives at another, and the interval between those two events is short enough that nobody designs around it. The assumption is so reasonable that it is rarely written down anywhere, which is what makes it hard to notice when it stops being true.
On the corridors running inland from the coast into the customs union, it stops being true immediately. A consignment that clears at the port and heads for a landlocked member spends weeks, not hours, between dispatch and receipt. That interval is not an administrative detail. For a great deal of inventory it is the single longest state the stock will ever be in.
The clearing side of this is a separate problem with its own document set, and it is covered in full in the CEMAC import file, and the general mechanics of running stock across several sites are set out in multi-branch stock control. This post begins one step later, at the moment everybody treats as the end of the story: the file is complete, the goods are released, and they are on a truck.
Where the stock actually is
Start with the mechanics, because they are better than most people expect and the interesting problem is the one that survives them.
A transfer here is genuinely two phases, not one move. Dispatch decreases stock at the origin warehouse immediately, stamps who dispatched it and when, and puts the transfer into an in-transit state. Receipt is a separate, later act that will not run at all unless the transfer is in that state, and it increases stock at the destination. Between the two, the stock is not at either site — and that is not a modelling failure, it is an accurate description of a truck on a road.
Two details are worth pulling out because they are the difference between a real feature and a status flag.
- Batch identity survives the journey. The allocations that left — which batches, in what quantities — are captured at dispatch and replayed at receipt. What arrives is the same stock that left, in the record as well as on the truck.
- Receipt can be partial, and the difference is recorded. You may receive any quantity from zero up to what was dispatched, and the gap is written down as shrinkage rather than being silently absorbed.
That second one is not a small thing on a long corridor. The difference between what was loaded and what was unloaded is, for a lot of operations in this region, the single most commercially important number in the whole inventory system, and it only exists at all because receipt is a distinct act that asks how much actually turned up.
The asymmetry that matters here and nowhere else
Here is the finding, and it is the reason this post is about this region rather than being general advice with place names in it.
Inbound goods — the leg from your supplier to you — are well served. A purchase order carries a shipping status with an in-transit value, there is a delivery report, and that report has an "In Transit" figure on the front of it. If you want to know what is currently on its way to you from suppliers, that question has an answer built for it.
Internal transfers — the leg from your own warehouse to your own other warehouse — are modelled more carefully and reported less. The workflow is richer: batch allocations, partial receipt, recorded shrinkage. But there is no stock-transfers report dataset in the catalogue at all. The mechanism is there; the standing question "what is on the road right now" has no built report to answer it.
In most markets that asymmetry is harmless, and you can see why it arose: the inbound leg is the long, uncertain one and the internal leg is a van across town. On this corridor the ranking is reversed. The internal leg from the coastal warehouse to the inland one is frequently the longest, least visible and most exposed part of the entire supply chain, and it is the leg with no report.
The system knows exactly where that stock is. It simply has not been asked to put it in a list — and on a corridor measured in weeks, the list is the whole job.
What that means for the numbers people actually read
Follow the consequence through, because it is not obvious and it is the thing that catches people out.
One consignment, three weeks, four different answers
Nothing here is wrong. Every one of those four answers is a truthful answer to the question it was asked. The problem is that the question most people ask — how much do we have — is answered by the third row, and the third row is the one that leaves out the truck.
This is why a reorder point behaves oddly on a long corridor even when it is configured correctly. Lead time in days and safety stock are both available per item, so the calculation has its inputs. But the on-hand figure it fires against does not include what is already on the road, so a site can trip its reorder point and generate a replenishment need for stock that left the coast a fortnight ago and is two days away.
Once a fortnight, that is an irritation. Where the corridor is long and the reorder cycle is short, it is a mechanism for ordering the same stock twice.
What to do about it now
-
Treat dispatch as a commitment, not a keystroke
Because dispatch decrements the origin immediately, the moment somebody records it is the moment your coastal stock figure drops. If dispatch is entered when the paperwork is filed rather than when the truck leaves, every figure downstream is wrong by the difference. Fix the timing of the act before anything else — nothing else on this list survives it being wrong.
-
Always record actual received quantity, never confirm the dispatched one
Partial receipt with recorded shrinkage is the most valuable thing in this workflow and it only works if the person receiving counts. Confirming the expected number because it is faster destroys the one number the corridor exists to produce.
-
Read in-transit off the transfers themselves, not off stock figures
There is no built report for this, so the standing view has to be assembled: transfers in the in-transit state, with dispatch dates, sorted by age. An in-transit transfer that is older than the corridor normally takes is the earliest signal you get that something has gone wrong, and it arrives long before anybody at the destination is expecting a delivery.
-
Set reorder points against the route, not the item
Lead time is stored per item. On a network where the same item reaches one site in a day and another in weeks, one lead-time figure cannot be right for both. Decide which site the number serves, and manage the other one deliberately rather than assuming the field covers it.
-
Count the road when you count the warehouse
Any stock-on-hand figure used for a decision — purchasing, allocation, a stock-out investigation — needs the in-transit quantity added back manually until it is reportable. Write that step into the procedure rather than trusting people to remember which figure excludes what.
The honest position
The workflow is right and the reporting has a hole in it, and it is worth being precise about which is which — because they need different responses. A missing report is a gap you can work around this week and close properly later. A workflow that could not represent stock in transit at all would be a design problem you could not work around at any speed.
What AWRA OpsHub does today
- A genuine two-phase transfer — dispatch and receipt as separate acts, with receipt refusing to run against a transfer that is not in transit.
- Stock decremented at origin on dispatch and increased at destination on receipt, so no site ever claims stock it does not physically hold.
- Batch allocations captured at dispatch and replayed at receipt, so batch identity survives the journey rather than being reassigned on arrival.
- Partial receipt with recorded shrinkage — the difference between what was loaded and what was unloaded is written down, not absorbed.
- Dispatched-by, dispatched-at, received-by and received-at, so the corridor has named people and timestamps at both ends.
- Lead time in days and safety stock per item, feeding the reorder calculation.
- In-transit tracking on inbound purchase orders, with a delivery report and an in-transit headline figure.
What it does not do
- No stock-transfers report dataset. Thirty datasets are registered in the catalogue and this is not one of them, so "what is on the road right now" has no built report.
- In-transit stock is in no warehouse's stock figure. It is held on the transfer record and is not added into any on-hand total.
- Reorder points fire against on-hand only. Nothing nets off stock already dispatched and heading for that site.
- Lead time is per item, not per route. One item moving to two sites at very different distances has one lead-time figure between them.
- No corridor or route concept at all — no expected transit duration, no overdue-in-transit alert, no escalation when a transfer ages past normal.
- No customs, bond or duty state on a transfer. The transfer knows the stock left and has not arrived; it does not know why it is stationary.
What is not built for Cameroon 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 Cameroon. 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 DGI e-invoicing connection, a French interface, 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.
The DGI platform, once there is something to build against
Real-time issuance through the tax administration's e-Facturation platform or an accredited provider, with the retries, the failure queue and the daily report of invoices carrying no reference. Stated honestly, because it is the whole position today: the 2026 Finance Law creates the obligation, the technical specification and the accreditation route have not been published, and nobody — us included — can build against a specification that does not exist yet. Any vendor claiming Cameroon e-invoicing readiness right now is describing an intention.
MTN MoMo, Orange Money, banks and the transfer file
Mobile money settlement and bank statement feeds into the Payments Register, and — the one that actually matters here — the currency-control file assembled from the purchase record: the domiciliation reference, the customs declaration and the proof of receipt held against the payment instruction rather than in a folder somebody has to rebuild. We would not become your bank's counterparty; we would stop the file being reconstructed by hand every time.
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
Income tax, CNPS contributions and the associated schedules produced in the layout each body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
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 integratedIf you are running an operation on one of these corridors, the practical summary is short. The record of what left and what arrived is trustworthy and better built than you might assume, and it will support a shrinkage conversation with evidence behind it. The standing view of what is on the road is something you will have to assemble yourself for now — and on a corridor measured in weeks, that view is worth assembling.
Frequently asked questions
Where does stock live while it is in transit between two of our warehouses?
On the transfer record. Dispatch decreases stock at the origin immediately and receipt increases it at the destination, so during the journey it is in neither warehouse's stock figure. It is not lost — the transfer holds the quantity and the batch allocations — but any on-hand total you read will exclude it until receipt.
Can we see everything currently on the road in one place?
Not from a built report. Inbound purchase orders have in-transit tracking and a delivery report; internal stock transfers do not have a report dataset, so a standing in-transit view has to be assembled from the transfers themselves — filtered to the in-transit state and sorted by dispatch date.
What happens if less arrives than was dispatched?
Receipt accepts any quantity from zero up to the dispatched quantity, and the difference is recorded as shrinkage on the transfer. This only produces a useful number if the person receiving counts rather than confirming the expected figure — the whole value of the mechanism depends on that one habit.
Will our reorder points account for stock already heading to that site?
No. Reorder points fire against on-hand stock, and stock in transit is not in that figure. On a short internal leg this is invisible; on a corridor measured in weeks it can generate a replenishment need for stock that is already nearly there, which is a route to ordering the same goods twice.
Can we set a different lead time for a distant site than for a nearby one?
Not with the standard field — lead time in days is stored per item, not per route, so an item supplied to two sites at very different distances carries one figure between them. Decide which site that number serves and manage the other deliberately.
