One stock number across several shops: what actually breaks

One stock number holds together in one shop and breaks in the second, and it breaks in a single place: the movement between locations. Every other movement — a sale, a receipt, a return — has both ends in the same building, which is why it survives. A transfer has two ends in different buildings, and the system either models that honestly or the number drifts. The rule that prevents most of the damage is short: every movement has a source and a destination, and the van is a location.

Why does one number break as soon as there are two shops?

Because a transfer gets recorded as two events that are not the same event. On the sending side it looks like a sale or an issue: stock leaves, the count goes down. On the receiving side it looks like a purchase: stock arrives, the count goes up. Between those two records sits a gap — the time the goods spend in a van, a depot, or a courier's hands — and nothing owns the stock during that gap.

So stock that left but has not arrived is invisible: the sending shop believes it is sold, the receiving shop believes it was never sent, somebody re-orders, and the goods arrive twice. A week later the sending shop counts a shortage. Both are counting correctly.

Who owns an item in transit?

The van owns it. So does the depot, and the courier, and the corner of the shop where returned cartons wait to be checked. Each of those is a location in the model, with a balance, and stock sitting in one of them is neither at the source nor at the destination.

Event	Leaves	Arrives
Sale to a customer	Shop shelf	Customer, gone
Transfer between shops	Shop A	In transit, then Shop B
Delivery refused	In transit	Shop A, to be checked
Damage found at the depot	Depot	Written off, with a reason

The middle column being a real location is the whole trick. Once in-transit has a balance you can answer three questions: what is on the road, what has been on it too long, and which shop is short because its goods are in a van outside.

What does a slow connection do to the number?

A shop with an unreliable line does not stop selling. It writes on paper, or it keeps working in an application that has lost the server, and the movements queue up. Two failures follow.

The first is latency: the number at head office is stale, which is tolerable if everyone knows by how much. The second is conflict: two shops each sell the last unit while offline, and both sales are legitimate when they happen. When the queues sync, one has to fail — and the moment to decide how it fails is before it happens, not in front of the customer.

The usual resolution is to let a shop sell what it physically holds and treat the central number as a forecast, not a promise. That is a business decision worth saying out loud. What does not work is a system that silently drops the loser; the shop discovers it at the counter.

How do you stop two shops selling the same unit?

Separate the number the system shows from the number a shop may promise:

• On hand is what is physically in that location, counted or recorded.
• Reserved is committed to an order that has not shipped.
• Available is on hand minus reserved, and it is the only number a salesperson should be allowed to sell against.
• Allocated is a soft claim: head office says these units are for this shop, and they stay in the central warehouse until they move.

Most overselling comes from showing on hand and letting people do the arithmetic. Reservations need an expiry, or an abandoned basket holds stock for ever.

Should each shop set its own price?

It can, and often should, but the price list has to belong to the location rather than be a global constant. Two consequences follow.

Transfers then have a value, and someone must say which: cost, or the receiving shop's price. Pick one and write it down, because the valuation of every shop depends on it, and changing method mid-year makes two months incomparable.

The second is stuck stock. A shop whose price is too high for its neighbourhood sells slowly, and the stock sits there while another shop runs out. Without a transfer routine — a weekly look at what has not moved — the network holds the same slow item everywhere.

What order do you fix this in?

1. Make locations explicit. Every shelf, depot, van and returns corner is a location with a balance. If you have three warehouses, "warehouse" is not a location.
2. Make every movement a two-ended record. Source, destination, quantity, who, when. No movement with one end missing.
3. Give in-transit a location of its own. Transfers then have a visible middle, and goods in the van can be counted, chased and lost on purpose rather than by accident.
4. Separate on hand from available. Show available, and give reservations an expiry.
5. Decide the offline conflict rule, and write it down. Who wins, and what the losing shop is told.
6. Add one report per location that a manager reads weekly. Not a dashboard: on hand, in transit in, in transit out, and what has not moved in a month.
7. Only then tune prices per location. Pricing a network you cannot see is guessing with money.

Where this goes wrong

• The transfer is recorded as a sale and a purchase. It balances the total and destroys the trail; nobody can tell a real sale from an internal move, so revenue is overstated and the network's stock is a coincidence.
• In-transit is not modelled, so it is adjusted away. Each month ends with a correction entry that hides the van.
• Reservations never expire. Available drifts to zero while the shelves are full.
• Each shop keeps its own spreadsheet. It is the single-shop failure multiplied by the number of locations.
• The courier's custody is invisible. Goods handed to a driver are neither in the shop nor lost, and a claim against the courier cannot be supported.

What this does not cover

This is about keeping one number honest across locations, not about transport economics: it does not cover how delivery is priced, which routes are worth running, or courier contracts. It does not cover forecasting or replenishment — reorder points are a separate model and need this one to be correct first. And it assumes the shops connect often enough to reconcile daily; a network offline for days at a time needs a different design, with a clear rule about which location is authoritative when the link returns.

We build the movement ledger and the location model that hold one number across several shops, with in-transit visible and every transfer owned at both ends.