Transfer orders between stores: shipping, receiving, and the in-transit gap

Store operations · 7 min read

Moving stock from one store to another looks simple — box it, drive it, shelve it. In Business Central the move is two postings with a gap between them: a shipment at the sending store and a receipt at the receiving store. During that gap the stock belongs to neither shelf. It sits in an in-transit location, accounted for but unavailable for sale anywhere. Most transfer problems are gap problems: stock that was shipped and never received, or a gap nobody was watching.

What a transfer order actually does

A transfer order moves inventory between locations. The prerequisites are not optional: locations and transfer routes must be set up before a transfer order can post, and transfer orders cannot be used for blank locations. Posting works in two halves. Post > Ship at the sending location takes the quantity out of that store; the items are then in transit between the locations according to the transfer route. Post > Receive at the destination brings the quantity in. One detail drives the whole receiving discipline: once shipped, the transfer order lines are the same as when they were shipped and cannot be edited. The receiving store cannot quietly fix a wrong quantity on the order — it receives what was shipped, or the shipment itself has to be corrected.

In LS Central stores, transfers also live in Store Inventory, which manages inventory processes — including Transfer — in a single store worksheet. Store Inventory runs on LS Retail's own tables rather than the standard Business Central tables, which LS documents as making processing easier and faster and avoiding locking problems. Whichever surface staff use, the underlying transfer order and its two postings are the same.

In-transit vs direct transfer

Business Central can also post a transfer as a direct transfer, with no in-transit location: shipment and receipt process simultaneously. Which mode fits depends on whether the gap is real. Microsoft's comparison of the modes:

The decision framework is physical, not technical. If the goods spend real time on a truck, in a van, or waiting for a pickup — any move where the sending store has let go and the receiving store does not yet have the stock — use an in-transit transfer, because that is the truth of where the stock is, and the in-transit location is what holds its cost in the meantime. If the two locations are close enough that shipment and receipt genuinely happen in the same moment, a direct transfer is the honest, simpler record. What never works is using direct transfer for a slow move to save a posting step: the receiving store shows stock it does not have, and can sell it.

Set up the route before the first order

1. Create the in-transit location. Set up a dedicated location and turn on Use as In-Transit Location on its location card. That flag changes its behaviour: the location cannot store items and is not included in normal quantity calculations — it exists only to hold stock (and its cost) while it moves.
2. Build the transfer route. Define the transfer route matrix: which locations can transfer from, and to which locations. If the In-Transit Code, Shipping Agent Code and Shipping Agent Service are filled in on the Trans. Route Spec. page, they are copied onto transfer orders automatically. The shipping agent service also drives dates: the receipt date at the destination is calculated by adding the service's shipping time to the shipment date.
3. Add the transit location to Inventory Posting Setup for every inventory posting group in use. Skipping this is a known hard failure: posting the transfer order errors out.
4. Test with one small order end to end — create, ship, receive — before the route carries a real stock move.

Ship, wait, receive: the working procedure

1. Create the order. Search for Transfer Orders, create the order, and set the from-location and to-location. Fill the lines manually, with Select items for several items at once, Get Bin Content to pick from a specific bin at the sending location, or Get Receipt Lines for stock that just arrived there.
2. Pick and count at the sending store, then ship. Count what physically goes in the box against the lines before posting — after the shipment posts, the lines are locked. Post with Post > Ship. The stock is now in transit: gone from the sender, not yet at the receiver.
3. Watch the gap. Until the receipt posts, the quantity lives in the in-transit location. An order that stays shipped-not-received is stock the business owns but no store can sell — treat ageing in-transit orders as a daily exception list, not a surprise to find at count time.
4. Receive at the destination. When the goods arrive, count them against the shipped lines first, then Post > Receive. The lines received are exactly the lines shipped; a physical shortage is not fixed by editing the order, because it cannot be edited — it is handled by correcting the shipment or by the count process once the facts are established.
5. Handle volume sanely. Several orders can be posted together from the Transfer Orders list with Post Batch — choosing Ship or Receive for in-transit orders — and batch posting can be scheduled, for example through the job queue, instead of blocking staff during trading hours.

Clearing a stuck transfer

When a transfer will not close, work it in this order. First, establish where the stock physically is: still at the sender, on the road, or already shelved at the receiver with the receipt never posted. If the goods are at the receiver, post the receipt — the gap was paperwork, not stock. If the shipment itself was wrong — a quantity keyed incorrectly at the sending store — and the shipment has not been received, use Undo Shipment on the Posted Transfer Shipment: it creates corrective lines, reduces Quantity Shipped, increases Qty. to Ship, and marks the lines as corrections. Then reopen the transfer order, enter the correct quantity, and post it again. Undo is a shipment tool, not a receipt tool: it is available precisely because the receipt has not happened yet. Finally, remember the planning side-effect: a transfer line is both demand at the sending location and supply at the receiving one, so a stuck transfer distorts availability at both ends until it is cleared — one more reason the in-transit list needs an owner. Stuck transfers also surface as phantom differences when either store counts; check the in-transit location before posting count differences. (See stock counting and physical inventory.)

What success looks like

• The in-transit location contains only stock that is genuinely moving, and every order in it has a recent shipment date.
• Every shipped order reaches a posted receipt; the shipped-not-received list is empty or actively chased.
• Item ledger entries for a completed in-transit transfer show the full path: out of the sending store, into and out of in-transit, into the receiving store.
• Receiving stores count against shipped lines before posting the receipt, and shortages are corrected at the shipment, not edited away.

FAQ

Can the receiving store change a quantity on the transfer order? No. After the shipment posts, the lines are the same as when shipped and cannot be edited. Correct the shipment with Undo Shipment (while it is unreceived), or receive what shipped and resolve the physical difference through the count process.

When is direct transfer the right choice? When shipment and receipt truly happen at the same moment — locations close enough that there is no meaningful time on the road. If goods spend hours or days in transit, the in-transit mode is the accurate record.

Posting fails on a new route. First check? The Inventory Posting Setup: the in-transit location must be set up there for every inventory posting group used, or posting the transfer order fails with an error.