Moving Stock Between Locations: Dispatched Is Not Yet Received

When stock leaves one of your locations, it should not instantly appear as received at another. A multi-location app needs to show what departed, what is still traveling and what the receiving team actually confirmed. Otherwise an apparently balanced company total can hide a missing delivery.

This guide concerns transfers between your operating locations. It does not determine ownership, transport liability, insurance or accounting valuation. Those rules need appropriate review separately.

Give the journey two ends

Start with the sending location, intended destination, product and quantity. Link dispatch and receipt to the same transfer reference, but let each team record its own event. A planned movement is not evidence that someone loaded the vehicle.

The Odoo 19 inter-warehouse guide gives a concrete example: replenishment creates a delivery order at the supplying warehouse and a receipt at the shop. Goods traveling between them sit in an inter-warehouse transit location. This supports separating departure from arrival, not a promise that every custom app already reconciles discrepancies.

For your requirements, decide what confirms dispatch and who can acknowledge receipt. If one person works at both locations, keep the events distinguishable anyway. Entering both in advance defeats the purpose.

Keep traveling stock visible without claiming it is on the shelf

A transit view should identify the transfer, quantity dispatched, quantity received and unresolved remainder. Staff need to find the sending and receiving records without comparing unrelated spreadsheets.

Use a fictional example: ten units leave the central store and eight arrive at a branch. The remaining two need an explicit unresolved position. Do not quietly add ten to the branch, delete the difference or label the whole transfer complete because the first parcel arrived.

Agree whether traveling goods may be promised to customers and how that promise is described. Expected availability is not confirmed local stock. This article does not choose your reservation policy; it asks that the transfer screen not obscure the distinction.

Investigate a discrepancy before correcting it

A shortage may mean a later parcel, an incorrect dispatch count or an unresolved loss. Record the observation first and assign follow-up rather than making the software invent a cause. An unexpected extra item needs review too.

Specify a linked correction process. If the sender corrects the dispatched quantity after the receiver has confirmed arrival, both teams should see what changed and why. Corrections must not turn a physically received item into unexplained negative transit stock.

Cancellation also depends on the journey. Before departure it may cancel a plan. After departure it needs a reviewed disposition for the goods, possibly a linked return movement. A cancel button must not pretend the vehicle came back.

Accept the paired workflow, not just a transfer list

Ask for a demonstration with two fictional locations. Dispatch a shipment, receive part of it and show the remainder still unresolved. Receive the rest later, then inspect the final history. Repeat receipt confirmation and verify it cannot silently add the same units twice.

Also test the wrong destination, an extra received unit and cancellation after dispatch. Give each exception an owner and a visible next step. Include these outcomes in the acceptance criteria, not merely a requirement for a green status badge.

Bring a blank transfer note and your discrepancy process to a stock-workflow discussion. The useful feature is a traceable journey between two locations, not a shortcut that changes two stock totals at once.