Stock and Goods Received

A transfer touches stock twice, and the two moments do different things. Getting them the wrong way round is the most expensive misunderstanding available here, because it decides whether a store thinks it can sell something.

Two moments, and both stores move at each one

Each step writes to both stores, in different stock types. The types are the whole story here, so they are worth reading carefully:

When the request is sent

Store	Stock type	Effect
sending	Reserved	+ requested — the goods are set aside
receiving	On order	+ requested — the goods are expected

Nobody's sellable stock changes. The units are still physically on the shelf at the sending store and still counted there; what changes is that they are now spoken for, which is what stops the same units being promised twice. At the receiving store nothing has arrived — the on-order figure says something is coming, not that it is here.

When the transfer is completed

Store	Stock type	Effect
sending	Sellable	− approved — the goods leave
sending	In transit	+ approved — they are on their way
sending	Reserved	released in full
receiving	On order	corrected to what actually shipped

Completion moves quantityApproved — the picked quantity — not the quantity originally asked for.

🛑 Completion does not add anything to the receiving store's sellable stock. The goods are in transit; the receiving store's on-order figure is corrected to the real quantity, but nothing becomes sellable there until the delivery is received — a separate step in a different service, see below.

This is deliberate: goods in a van are sellable nowhere, and a system that credited the destination on despatch would let a store sell stock that has not arrived.

If nothing could be picked

A pick can come back empty — the items were not on the shelf after all, and every line is picked at zero. The transfer still completes, and that is the correct outcome rather than a failure: it records that the request was answered and nothing was sent.

Both reservations unwind cleanly. The release is calculated from what is actually outstanding rather than from the picked quantity, so a zero pick releases the sending store's reserved units in full and takes the receiving store's on-order figure back to nothing. No stock is left stranded in either place, and no correction is needed.

⚠ A delivery is still created for the receiving store, with nothing on it. See below.

The receiving side is Goods Received

When a transfer completes, a delivery is created for the receiving store in Goods Received. Staff there take the goods in against that delivery exactly as they would a supplier delivery.

That is where the receiving store gets its stock, and where any discrepancy is settled:

Situation	Where it is handled
fewer units arrived than were sent	received short, in Goods Received
the goods were damaged in transit	recorded against the delivery, in Goods Received
the wrong item was picked	corrected on the delivery, in Goods Received

The transfer itself is not reopened for any of these. Once completed it is final; the correction lives on the delivery. So if you are reconciling two stores' balances, the pair to compare is transfer completed against delivery received — not the transfer alone.

Receiving is what closes the loop

Store	Stock type	Effect
receiving	Sellable	+ received — the goods are now on sale
sending	In transit	closed
receiving	On order	closed

The quantity that becomes sellable is the received quantity, not the shipped one. If four of the five despatched units arrive, four go on sale.

🛑 A short receipt does not balance, and that is deliberate. The in-transit and on-order figures close on what was shipped, while the receiving store is credited with what was received. Ship five, receive four, and the estate is one unit poorer — with no shrinkage or write-off recorded anywhere. Nothing is stuck and nothing needs correcting; the loss simply is not booked as a loss.

If your accounting needs that difference, derive it yourself: compare quantityApproved on the completed event against the received quantity on the Goods Received event for the same transfer. It is the pair worth reconciling if stock is going missing between stores, and no event will report it for you.

🛑 Stock movement depends on a tenant-level switch

Everything on this page describes what happens when stock processing is enabled for the tenant.

Store Transfer publishes its events either way — the transfer completes, the delivery is created, the events go out. But the stock ledger is written by Stock Transaction Processing, and it ingests movements from other Hii Retail services only while its master switch (Do enable PosLog processing) is on for that tenant. It is a tenant-wide setting, not a per-store one, and it gates goods received, stock counts and corrections in exactly the same way.

With it off, a transfer still works as a piece of paperwork — it is raised, picked, completed and received — and no reservation, in-transit or sellable figure moves at any point. If you are reconciling stock and finding no movements at all against a transfer that plainly completed, check this setting before looking for a defect.

What the stock movements look like

Both moments are published to Hii Retail's stock processing as transactions attributed to Store Transfer, so anything reading stock movements sees them with a document type naming this service and the transfer's id as the document id. Each line carries the transfer's line id, so a movement can always be traced back to the exact line that caused it.

The request-time movement carries the requested quantity; the completion-time movement carries the approved quantity. If a picker cut a line from six to four, those two movements disagree by design — the difference is the shortfall, not an error.

Values on the completed event

The completed event carries a unit price and currency per line, looked up at completion time from Hii Retail's stock valuation. This makes the event usable for the accounting side of an internal movement without a second call.

⚠ Price and currency can both be absent. If the valuation lookup finds no price for an item — or does not answer — the line is still published, with no price rather than a zero. Treat a missing price as "not known", never as "free": summing it as zero understates the value of the movement.

What Store Transfer does not decide

Store Transfer moves stock; it does not own the numbers.

• It does not set item cost — the value on the event is read from stock valuation, not calculated here.
• It does not decide whether an item may be transferred at all beyond it being known to the tenant. If your business rules restrict what can move between stores, enforce them before raising the transfer.
• It does not reconcile the two stores. The pairing of a completed transfer with its received delivery is done by whoever consumes both, using the transfer id that appears on each.