The Transfer That Arrived Short
Ninety-four cartons left Industrial Area and eighty-nine arrived in Eldoret. The system knows exactly what went on the lorry and exactly what came off it — and has no opinion whatsoever about the person in between.
Most stock control assumes stock is somewhere. It is on a shelf, in a bin, at a branch — countable, and countable by somebody. A transfer breaks that assumption for as long as the lorry is on the road, and how a system handles those hours decides whether an inter-branch shortfall is an investigation or an argument.
The failure mode is familiar to anyone running more than one location in Kenya. Head office dispatches to the branch. The branch counts what arrived, and it is five short. Nobody is lying. The storeman at the source is certain he loaded ninety-four. The branch manager is certain she received eighty-nine. And because the paperwork was a delivery note that travelled with the goods, the only two records of the event are held by the two parties disagreeing about it. A customer delivery at least produces a proof of delivery signed by somebody outside the business; an internal transfer produces nothing of the kind.
A transfer is two events, and the gap is the point
The single most useful thing a system can do here is refuse to pretend a transfer is instantaneous. Dispatch and receipt are separate acts, by separate people, at separate times, and between them the stock is in neither warehouse. That is not a modelling inconvenience — it is the literal truth, and it is where accountability has to live.
The first three are good news and the fourth is the honest catch, which we will come back to. Worth understanding first is what happens underneath, because it is better than most systems at this level and it affects how much you can trust the numbers.
On dispatch, available stock at the source is checked and the transfer is refused if there is not enough — you cannot dispatch what you do not have, which sounds obvious and is often not enforced. The quantity is then removed from the source, and the specific batches it came from are recorded on the transfer itself. On receipt, the stock is added at the destination from those recorded batches, so batch identity survives the journey and an expiry date does not reset because the goods changed warehouse. Receiving more than was dispatched is arithmetically impossible; receiving less is allowed and the difference is stored as shrinkage. And a consignment that never gets there can be returned to source with a reason.
You cannot dispatch stock you do not have, and you cannot receive stock that was never sent. Both are enforced by arithmetic rather than by a warning.
The two boundaries that hold
Where the record stops being useful
Now the gap in the gap. Run the four things that actually go wrong on a Nairobi–Eldoret run against what the record will tell you afterwards:
| What went wrong | Visible in the system | Reason recorded | Loss in shillings |
|---|---|---|---|
| Received short of what was dispatched | Yes | No | No |
| Consignment turned back before delivery | Yes | Yes | No |
| Quantity complete but goods damaged | No | No | No |
| Delivered to the wrong branch | Partly — configurable by you | No | No |
| Never arrived — still sitting in transit | Partly — configurable by you | No | No |
Built and maintained Configurable by you, not maintained by us Not built
Three findings in that table are worth stating in plain words. A shortfall carries no reason. A return has a reason field; a short receipt does not, so the most common failure records a number and no explanation. A shortfall carries no value. The transfers report totals shrinkage in units with no cost applied, so a report whose stated purpose includes shrinkage losses cannot tell you the loss in shillings — forty-three units, never KES 187,000. And nothing ages an in-transit transfer. The report counts what is in transit; no job asks why something dispatched eleven days ago has not been received, so a consignment that vanished stays quietly in transit indefinitely, out of both warehouses and off everybody's count.
There is also nothing about condition. The entire model is quantitative — a carton that arrives crushed arrives, as far as the system is concerned. That has to be handled by receiving it and then placing it on a quality hold, which does genuinely work and genuinely prevents the goods being sold, but it is a second deliberate act that nothing prompts.
Running transfers so a shortfall is answerable
-
Dispatch at the moment of loading, not at the end of the day
The dispatch timestamp and the named dispatcher are only evidence if they coincide with the physical act. Dispatching a morning's loads at 5pm produces a record that cannot distinguish between four lorries, which is exactly the distinction you will need.
-
Put the transporter, driver, vehicle and expected arrival in a custom field — and require them
Custom fields are available on transfers and can be made mandatory. Nothing in the product holds a transporter or a vehicle, so this is the only way "which transporter is short most often" becomes answerable. Four required fields at dispatch turn an anonymous journey into an attributable one.
-
Receive against the document, not against the delivery note
The receiver should count and enter the quantity received before comparing it to what was expected. Where the expected figure is visible first, the count drifts toward it — the same reason a blind count is more honest than a confirmed one.
-
Treat every shortfall as a claim with a named owner
Because no reason field exists on a short receipt, write the reason and the responsible party into the transfer notes, or into a required custom field, at the moment of receipt. A shortfall recorded without a name is a write-off that has not yet admitted what it is.
-
Value the shrinkage yourself, monthly
Export the transfers report, join it to item cost, and get one figure: shillings lost in transit this month. It is the only version of this number that will change anybody's behaviour, it belongs beside your other shrinkage figures, and it does not exist inside the report.
-
Decide in advance what a partial receipt means
Receiving short closes the transfer — the balance cannot be received later against the same document. So if goods genuinely follow on a second vehicle, receive only what arrived, raise a fresh transfer for the balance, and reference the original. Otherwise your shrinkage figure will be full of quantities that were never actually lost.
Scoring a transfer capability — yours or anyone's
Weight by how much money each one is standing in front of, not by how impressive it looks in a demonstration.
Dispatch is refused without sufficient stock
Make them prove it: Try to dispatch 100 when 60 are available. It should refuse, not warn.
Over-receipt is impossible
Make them prove it: Try to receive 110 against a dispatch of 100.
Batch and expiry identity survives the journey
Make them prove it: Transfer a batch with an expiry date and check the date at the destination.
The stock is in neither location while in transit
Make them prove it: Run a stock report at both warehouses mid-journey. The total should be down by the quantity, in exactly one place.
Dispatch and receipt are separately attributed
Make them prove it: Check that two different named users and two timestamps are stored.
A shortfall captures a reason and an owner
Make them prove it: Receive short and look for a required reason field.
Shrinkage is reported in money
Make them prove it: Open the transfer report and look for a shilling column.
An overdue in-transit transfer raises an alert
Make them prove it: Ask what happens on day ten of an unreceived dispatch.
Authorising a movement is separate from making it
Make them prove it: Ask whether one person can create and dispatch alone.
What AWRA OpsHub does today
- A genuine three-stage movement — pending, in transit, completed — with dispatched at / dispatched by and received at / received by stored separately, so both halves are attributed to named people.
- Dispatch is refused when source stock is insufficient, by arithmetic rather than a warning, and over-receipt is impossible — the received quantity is bounded by what was dispatched.
- Batch identity is preserved across the journey. The specific batches taken from the source are recorded on the transfer and restored at the destination, so an expiry date is not lost by moving warehouses. Both ends write traceability events.
- Partial receipt with the difference stored as shrinkage, and return to source with a required-in-practice reason for a consignment that turns back.
- A multi-item document. Lines share one transfer number with Dispatch All, Receive All and Return All actions, and lines may sit at different states — so a partly-dispatched consignment is representable.
- A stock transfers report in the report catalogue — received quantities, in-transit count and shrinkage quantity, with a date range and a status filter — plus a per-transfer PDF and custom fields on transfers.
- Stock balancing suggestions, which propose where stock should move based on what each location holds, rather than leaving the decision to whoever shouts.
- Edits are locked after dispatch. Only a pending transfer can be changed, so the quantity cannot be adjusted to match what turned up.
What it does not do
- No reason on a shortfall. A return has a reason field; a short receipt has only a number. The most frequent failure is the one with no explanation attached.
- Shrinkage is never valued. The transfers report sums shrinkage in units with no cost join, so a report that names shrinkage losses cannot state a loss in money. The monthly figure has to be produced by exporting and joining to cost.
- Nothing ages an in-transit transfer. No expected arrival date, no overdue alert, no job that asks why a dispatch from eleven days ago is unreceived. It simply stays in transit, in neither warehouse.
- No transporter, driver, vehicle or consignment reference. Nothing in the product holds these, so "which transporter is short most often" cannot be answered — see the transport invoice nobody can check for the wider version of that gap.
- No condition or damage capture. The model is quantities only; damaged-but-complete is invisible until somebody separately places the stock on hold.
- No approval separate from dispatch. The two are literally the same operation — an `approve` action exists in the API and calls dispatch directly — and creating, dispatching and receiving all sit under one permission. Anyone who can raise a transfer can send it and receive it.
- No custody by a person in transit. Stock is held by a location, and in transit it is held by no location, so the driver cannot be the custodian. The nearest workaround is a location per vehicle, which is how van stock is handled.
- A partial receipt closes the transfer. The balance cannot be received later against the same document; it needs a new transfer, and the original keeps a shrinkage figure that may not represent a real loss.
The balance to hold: the mechanics here are stronger than the category norm — refusal rather than warning, batch identity preserved, two attributed halves, edits locked after dispatch — and the accountability layer above them is thin. The system will tell you precisely that five units went missing between two named people on two known dates. It will not tell you why, whose it was, or what it cost, and it will never chase the lorry. Those three are custom fields, a monthly export and a habit. Set them up in the first week or the shrinkage figure becomes a number people learn to ignore.
The verdict
The gap between dispatch and receipt is not an accounting inconvenience to be smoothed over — it is the only place an inter-branch loss can be caught, and a system that pretends transfers are instantaneous guarantees the argument you are trying to avoid. Dispatch at the point of loading, require the transporter and vehicle as fields, count before looking at the expected figure, name an owner for every shortfall, and value the shrinkage monthly yourself. Then five missing cartons become a question with an answer, instead of two certain people and one unexplained number.
Frequently asked questions
Where is stock while it is in transit?
In neither warehouse. Dispatch removes it from the source and receipt adds it at the destination, and between the two the quantity sits on the transfer itself along with the batches it came from. This is the correct model and it has a consequence worth knowing: your total stock on hand genuinely drops during the journey, so a group-level stock valuation taken mid-transfer will be short by whatever is on the road. That is not an error, it is the truth about where your goods are.
Can I receive a transfer in two parts?
No — receiving closes the transfer, and the shortfall is recorded as shrinkage. If goods legitimately follow on a second vehicle, receive what arrived, raise a new transfer for the balance and reference the original in the notes. Getting this convention agreed early matters, because without it your shrinkage figure fills up with quantities that arrived two days late and were never lost at all.
How do I find out which transporter loses the most stock?
By capturing the transporter as a required custom field on the transfer, then exporting. There is no transporter, vehicle or driver anywhere in the product, so nothing links a shortfall to a haulier automatically. Four required fields at dispatch — transporter, driver, vehicle and expected arrival — cost nothing and are the difference between a pattern you can prove and a suspicion you cannot.
Does a transfer need approving before it is dispatched?
There is no separate approval — the approve action calls dispatch directly, and creating, dispatching and receiving are all covered by one permission. So a second pair of eyes on a stock movement is a workflow rule you build, not a permission you grant. Where transfers move real value between branches, that is worth building deliberately rather than assuming it is there.
What happens to batch numbers and expiry dates on transfer?
They survive. The batches drawn at the source are recorded on the transfer and the same batches are credited at the destination, with traceability events written at both ends. This matters more than it sounds: a system that re-receives transferred goods as a fresh batch resets the expiry clock, which is how out-of-date stock ends up sellable at a branch. Here the [FEFO position](/blog/fefo-vs-fifo) at the destination is the real one.
How do I handle goods that arrive damaged?
Receive the quantity that physically arrived, then place the damaged portion on a quality hold. Held stock genuinely cannot be issued or sold — the allocation queries filter on available status — so the control is real once you use it. What is missing is any prompt: the transfer model is quantities only and knows nothing about condition, so nothing reminds the receiver to raise the hold.
Should the branch or head office raise the transfer?
Whichever it is, be consistent, because the record cannot tell you afterwards who asked for it. A pull model — the branch requests, the source dispatches — generally produces better stock discipline, since the location that will hold the stock is the one that asked for it. Stock balancing suggestions are useful input to that conversation, proposing movements from what each location currently holds rather than from whoever complained most recently.
