Skip to main content

Store Transfer

Store Transfer moves stock from one store to another inside a single tenant. One store raises a request, the other picks and sends it, and the stock leaves one balance and arrives in the other — with the goods tracked the whole way rather than simply disappearing from one store and reappearing in the next stock count.

A store transfer in one morning. The Uppsala store runs low on Baked Beans 400g and asks the Stockholm store for 6 tins. Stockholm finds only 4 on its shelf, picks them on a handset and sends them. Uppsala takes the delivery in through Goods Received, and 3 tins arrive.

It is an internal movement. Nothing here involves a supplier, a purchase order, or a customer.

Who operates this​

The work happens in the store, on a handset, done by staff. Extenda supplies the client — the Hii Retail Inventory app — so a customer does not have to build one.

The two stores use different parts of that app, and this is worth getting straight before reading any further:

  • the receiving store works in the app's Store Transfer screens — raise a transfer, add items, send the request, and later receive the goods in Goods Received;
  • the sending store never opens those screens. Its work arrives as a picking job in the app's Click and Collect module, alongside customer orders, and is done there.

The receiving store's half of that is ordinary REST against the Store Transfer API, so a customer who wants to raise transfers from their own system instead of from the app can:

ActionEndpoint
List transfers for a storeGET /business-units/{businessUnitId}/store-transfers
Read one transfer and its linesGET /business-units/{businessUnitId}/store-transfers/{storeTransferId}
Raise a transfer (with its lines)POST /business-units/{businessUnitId}/store-transfers:with-lines
Add or change a linePUT /business-units/{businessUnitId}/store-transfers/{storeTransferId}/lines
Send the request to the other storePOST /business-units/{businessUnitId}/store-transfers/{storeTransferId}:send-request

See the API for the full list and the request shapes.

What the receiving store's staff see in the Inventory app. On Review request, the route reads From Stockholm to Uppsala, with Baked Beans 400g at 6, and Send request sends it: the app raises the transfer with its lines, waits until the transfer reads back, and then sends the request. Later the Transfer request screen shows the completed transfer with Requested 6 and Picked 4 for the line.

The sending half is not something a store does through this API. Picking is driven from Click and Collect and the transfer completes when the pick finishes, so there is no step for store staff in between. A customer who replaces the picking app with their own system does complete transfers over REST — see Completing from your own system.

🛑 You send work in and subscribe to what comes back — you do not drive the operator's actions. Picking is done by a person holding a handset in the sending store. An integration raises transfers and reacts to the events; it does not tell the picker what to do next.

Where Store Transfer sits. The receiving store raises the transfer in the Inventory app, or your system does it through the API, and sends the request. Store Transfer publishes store-transfer-requested, and the transfer becomes a picking job in Click and Collect at the sending store. When the pick finishes, Store Transfer completes the transfer and publishes store-transfer-completed: Stock Transaction Processing moves the stock, Goods Received creates a delivery for the receiving store, and your systems can subscribe to both events.

The two roles​

A transfer always names two business units, and which one you are decides what you can do:

RoleFieldWhat this store does
Receiving storetoBusinessUnitIdraises the transfer, adds the lines, sends the request, and later receives the goods
Sending storefromBusinessUnitIdpicks the goods in Click and Collect, adjusting quantities to what it can actually supply. Finishing the pick completes the transfer

⚠ Either store may create the transfer, but the later steps are not interchangeable. The business unit in the URL must be one of the two, and for a create it may be either. After that the roles diverge: only the receiving store can send the request or delete the draft, and only the sending store can complete it. A store that raises a transfer to push stock away therefore cannot send it itself — the receiving store has to. See Lifecycle for the full matrix.

If you want to…​

…then read
understand the states and who may move themLifecycle
know how the goods actually get pickedPicking
see what happens to stock, and where the receiving side comes fromStock and Goods Received
call the serviceThe API
subscribe to what the service publishesEvents

What most integrations get wrong​

  1. Treating the API as synchronous. Every write returns 202 Accepted and is applied a moment later. Reading straight back can return the state you had before your own call. See the API.
  2. Assuming the requested quantity is the transferred quantity. The sending store adjusts to what it can supply. The number that moves stock is quantityApproved, not quantityRequested.
  3. Expecting the receiving store to confirm arrival here. It does not — receiving happens in Goods Received, against a delivery this service causes to be created. See Stock and Goods Received.
  4. Subscribing to one event. There are two, and the first one is the one that tells you a transfer is coming. See Events.