Moving stock between locations is not the same as editing its location label. Goods can leave one site before arriving at another, and the received quantity may differ. The system needs an accountable in-transit state.
Related service: CRM, ERP and web application development- 01Approve the transfer request.
- 02Dispatch the identified quantity.
- 03Show goods in transit.
- 04Record destination receipt.
- 05Resolve differences and close the transfer.
SECTION 01
Choose the stock state at each handoff
Decide who may request, dispatch and receive a transfer. The source team confirms what leaves; the destination confirms what arrives. The application can link these events, but it should not assume that recording dispatch proves receipt. Define how reservations behave while goods are moving.
Keep physical movements traceable through item, unit, locations and transfer reference. Database relationships and transaction boundaries are useful implementation tools for maintaining those connections. They do not decide your availability policy. Write whether in-transit stock can be promised to a future order and how that promise differs from stock already available for picking.
SECTION 02
Illustrative example: a split transfer arrives in two parts
Imagine a branch requests fifteen units. Ten leave in the first vehicle and five are sent later. The destination receives nine from the first shipment and raises a discrepancy. This is a hypothetical operational example, not a delivered logistics claim.
The transfer should show the two dispatches, the nine-unit receipt and the unresolved one-unit difference. It must not mark all fifteen as available at the branch or silently return the missing unit to the source. A reviewer decides the correction with evidence, preserving the relationship between the adjustment and the original movement.
SECTION 03
Prove the location totals and exception path
A first release may cover two locations, one stock category and manual confirmation at each end. Compare the current inventory product's transfer features before commissioning custom movement logic. Keep carrier tracking and route optimization outside this bounded workflow unless separately required and confirmed.
Test a partial dispatch, repeated receipt, wrong destination, cancellation before dispatch and attempted cancellation after goods have left. Reconcile source, transit and destination quantities together. Ask what happens if the connection fails after the receipt is saved but before confirmation appears. Staff need an identifiable completed operation and a safe retry path, not a second stock increase when they click again.
SECTION 04
Frequently asked questions
Can we simply change the warehouse field?
That loses the interval between dispatch and receipt and makes discrepancies difficult to explain. Use linked movement records for a transfer.
When is transferred stock available?
Define it in the inventory policy. Usually the destination needs a receipt or acceptance event before treating the goods as locally available.
How should missing units be corrected?
Record a reviewed discrepancy and an explicit adjustment or resolution. Do not alter the original dispatch or receipt without preserving its history.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database constraintsPostgreSQL
- Transaction isolationPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy