Picture a company with a main warehouse and two shops. On Monday, a shop runs low on a popular item and asks the warehouse to send twelve units. The warehouse picks them, loads a van, and the van leaves on Tuesday morning. They arrive Wednesday. Now the question: on Tuesday afternoon, where are those twelve units?
In many simple systems the honest answer is "nowhere". They have already left the warehouse count, but have not yet arrived in the shop count. Or the opposite: someone edited both numbers on Monday, and the shop's system claims stock that is still sitting in a van. Either way, somebody trusts a number that is not true.
Stock is per place, not one big number
The first change a business needs is to stop thinking of stock as one total. A single "stock of product X: 85" is almost never what you want to know. You want to know how many are at the main warehouse, how many in each shop, how many are set aside for orders, and how many are on the way.
That means the system stores a quantity for every combination of product and location. A location can be a warehouse, a branch, a van, or a shelf inside a warehouse. The total is something the system calculates by adding the places up, not something anyone types in. Once you have that, questions that were guesses become answers: which shop has too much of this item, which one has none, and could one supply the other.
A transfer is a process, not a click
The reason a transfer is not an instant move is simple: it takes time, and things can happen along the way. Boxes can be damaged. The van can deliver fewer units than the paperwork says. The receiving shop may not look at the delivery until the next day.
A reliable system treats a transfer as a short life cycle with a few states. Names vary, but the usual ones are:
- Requested: the branch asks for stock. Nothing has moved yet.
- Approved or prepared: someone at the sending location confirms and picks the items.
- Shipped: the items have left. They are removed from the sending location and now belong to the transfer.
- Received: the destination confirms what actually arrived, and the stock is added there.
- Closed, or with differences: if the quantities do not match, the difference is recorded and explained, not hidden.
The state in the middle is the important one. While the goods are shipped but not received, they are "in transit": they are not available to sell at the sending location, and not yet available to sell at the destination. Giving that stock its own place in the system means the total stays correct, and nobody sells something that is in a van.
Differences are normal; hiding them is the problem
Sooner or later the quantity shipped will differ from the quantity received. The cause could be a counting mistake, damage, or something lost. If the system lets the receiver simply type the number that arrived, the difference vanishes and nobody knows whether to investigate.
A better design keeps both numbers: what was shipped, what was received, and the gap. The gap needs a reason and an owner. Over a few months, the pattern of gaps will tell you things a total never would, such as a route that loses more than others, or a branch where receiving is always rushed.
The questions the owner actually asks
Beyond day-to-day work, a multi-location system should answer a few things quickly:
- What is available to sell right now at each location, and what is the company-wide total?
- What is in transit, from where to where, and since when?
- Which transfers have been waiting for approval or receipt for too long?
- Which locations repeatedly run out of the same items, suggesting a better minimum level?
- Can a branch see only its own stock, or can it see others' too, and who decides?
The last question is about permissions and matters more than it looks. A shop employee may need to see that the warehouse has stock, without being able to change the warehouse's count. A good system separates seeing from changing, per role and per location.
Where off-the-shelf systems stop fitting
Many standard products handle multiple locations in the basics and then get awkward on the details of your operation: transfers that go through a regional hub, branches that also serve as pickup points, a van route that makes five stops, or stock that must be moved to a quarantine area before being sellable. These are the cases where a custom system models your actual flow, instead of forcing your team to invent a workaround.
That does not mean you need custom software for two shelves in two rooms. It means that when the transfers are a real part of how you operate, it is worth writing down the life cycle above and checking whether your current tool can follow it.
A practical first step
Trace the last three transfers you made, from request to arrival. For each one, write down what the system showed on each day. If at any moment the stock was missing from every location, or counted twice, you have found the gap that a proper in-transit state fixes. Then list the locations you have and who should be able to see and change each one. That short document is the foundation for the whole design.