You send twelve boxes from the main shop to the second one. The van leaves at ten. It arrives, eventually. Somebody unpacks it, or somebody means to and gets busy.
In most retail systems this whole thing is one click. You pick the products, you pick the destination, you press Transfer, and the stock instantly leaves one branch and appears in the other. Clean. Immediate. And wrong for the entire period the goods are actually on the road.
The cost of the instant transfer
For those two days, your system says the stock is at the second branch. Reality says it is in a van.
Most of the time this causes nothing worse than mild confusion. The problems start at the edges, and the edges are where money is lost:
Somebody sells it. The second branch’s system says they have four bottles of something. A customer wants one. The cashier sells it, because the screen said it was there. It was not there. Now you have a customer waiting for stock that is in a van and a stock level that has gone negative or, worse, silently to zero with a sale attached.
Nobody knows to look for it. Three weeks later the second branch counts and is short by two boxes. Are they missing? Were they ever sent? Did somebody at the first branch pick the wrong items? There is nothing to check against, because as far as the system is concerned the goods arrived the moment they left.
The shortfall becomes a stock adjustment. Which is to say: it becomes a write-off with a shrug attached. Somebody types “count correction” and the two boxes leave your books with no explanation of where they went, and no record connecting them to a specific journey between two specific shops on a specific day.
That last one is the real damage. You have converted a logistics problem, which has a cause you could find, into an inventory problem, which is just a number getting smaller.
The honest version
A transfer needs two separate acts, performed by two different people at two different times.
Send. The stock leaves the source branch now. Somebody at that end picked it, packed it and put it on a van, and their shelf really is emptier.
Receive. The stock arrives at the destination. Somebody at that end opened the boxes and counted what was in them.
In between, the goods belong to the transfer itself. Not to either branch. A row in a list, with a number on it, that says: sixteen units left the main branch on Tuesday and have not been booked in anywhere.
That state — call it in transit — is the whole point of the design. It is not an intermediate technicality. It is the thing that turns “we seem to be short” into “the transfer from Tuesday was never received”.
Receiving what actually turned up
The second half matters as much as the first, and it is where most implementations get lazy.
Receiving is not a confirmation button. It is a count. Twelve boxes were sent; eleven arrived; you receive eleven. The transfer does not close — it stays in transit with one box outstanding, because the twelfth might be in the front of the van, or at the other shop, or on a shelf somebody put it on.
Receive in parts. Stock that comes in two vans gets received twice. There is no reason to make somebody wait until everything has arrived before booking in what they can see.
Never receive more than was sent. Obvious, and worth enforcing, because the moment you can receive fourteen of twelve you have invented two units of stock and your total inventory is wrong company-wide.
Closing short is a deliberate act. When it becomes clear the last box is not coming, somebody closes the transfer with a written reason. Not a stock adjustment somewhere else — a note on this transfer, naming this journey.
Here is the part that surprises people: closing short requires no stock movement at all. The source branch already lost the units when they were sent. The destination never gained them. Both branches’ counts are already correct. The only thing missing was the explanation, and that is exactly what gets recorded.
Recalling a transfer
Sometimes the van comes back. A recall puts the stock back on the source branch’s shelf as a proper movement — visible in the ledger, not a silent reversal.
But once anything has been received, recall must be blocked. At that point the goods are split across two branches and pretending the transfer never happened would make both counts wrong. The only honest ending available is a short close.
What this looks like day to day
The main branch sends four lines to the second branch on a Tuesday. It shows as in transit. Anyone can see it.
Thursday, the second branch receives three lines in full and one line one short. The transfer stays in transit with one unit outstanding. It is still visible, still attributable, still somebody’s job.
The following week, the manager closes it short: “One box did not arrive. Driver notified.” That sentence is now attached to that transfer forever, and if the same driver or the same route produces three more of those, you will know — because each one is a record, not a number that quietly got smaller.
The general principle
The instant transfer is one example of a broader design mistake: modelling what you wish were true instead of what is true.
Goods take time to move. Money takes time to clear. People count things and get them wrong. Software that pretends otherwise is easier to write and produces a set of books that quietly diverges from the shop.
The gap between sent and received is not an inconvenience the software failed to hide. It is the shape of the real thing, and it is what makes a van full of stock something you can look at rather than something you find out about at the next count.