Inventory Transfers: Moving Stock Across the Network
Buying goods is only the first step. Moving them from a central distribution center to a store, or rebalancing stock between two stores, requires meticulous orchestration. Dive into the RMS Transfer data model (TSFHEAD/TSFDETAIL) and learn how in-transit inventory is tracked and financially reconciled.
Retail supply chains are fluid. Goods rarely stay where they are initially received. A central Warehouse (Distribution Center) receives massive bulk shipments from suppliers, and then must push smaller quantities out to hundreds of stores (W2S Transfers). Sometimes, a store in Miami sells out of swimsuits while a store in Orlando has too many, requiring a Store-to-Store (S2S) transfer.
Oracle RMS tracks these movements using the Transfer module. This guide explores how transfers are modeled, how they impact the ITEM_LOC_SOH table at every stage, and the financial implications of losing goods in transit.
1. The Transfer Lifecycle
A Transfer in RMS is fundamentally similar to a Purchase Order, but instead of the supplier being an external vendor, the "supplier" is another location within your own network.
The lifecycle generally follows this path:
- Input (Worksheet): The transfer is created (manually or via Replenishment).
- Approved: The transfer is committed. The sending location is told to prepare the goods.
- Shipped: The sending location packs the goods onto a truck and sends an ASN (Advance Shipment Notice).
- Received: The receiving location offloads the truck and confirms the quantities.
- Closed: The transfer is finalized, and any discrepancies are reconciled.
2. Inventory Impact by Status
Unlike a standard PO where inventory just "appears" upon receipt, a transfer moves inventory between two internal locations. The ITEM_LOC_SOH table must balance perfectly across both locations at every step.
Step 1: Approved
When the transfer is approved:
- Sending Location:
TSF_RESERVED_QTYincreases. (The goods are still physically there, but cannot be sold). - Receiving Location:
IN_TRANSIT_QTYincreases. (The goods are expected to arrive).
Step 2: Shipped
When the goods are loaded onto the truck (Tran Code 30 is written):
- Sending Location:
STOCK_ON_HANDdecreases.TSF_RESERVED_QTYdecreases. (The goods have left the building). - Receiving Location:
IN_TRANSIT_QTYremains the same. The goods are literally in transit.
Step 3: Received
When the truck arrives and goods are scanned in (Tran Code 32 is written):
- Receiving Location:
IN_TRANSIT_QTYdecreases.STOCK_ON_HANDincreases.
The In-Transit Trap
If a truck is in an accident, or a store simply forgets to process the receiving transaction in the system, the inventory remains stuck in IN_TRANSIT_QTY forever. It sits on the company's balance sheet, but no one can physically sell it. Retailers must build aggressive exception reporting for "Stale In-Transit" transfers.
3. Freight and Handling Costs
When transferring goods from a central warehouse to a store, the warehouse incurs labor costs (picking/packing) and freight costs (trucking).
In advanced retail accounting setups, these internal costs can be added to the item's valuation at the destination store via Estimated Transfer Cost (ETC). This is very similar to how Estimated Landed Cost (ELC) works for Purchase Orders, but it applies to internal movements.
However, many retailers simply treat these as operational expenses (OPEX) and transfer the goods strictly at their Weighted Average Cost (WAC), writing a Tran Code 30 at the sending location's WAC and a Tran Code 32 at the receiving location's WAC.
4. Core Tables Reference
Transfer Header (TSFHEAD)
| Column | Type | Description |
|---|---|---|
TSF_NO | NUMBER(12) | The unique transfer identifier. |
FROM_LOC | NUMBER(10) | The sending location (origin). |
TO_LOC | NUMBER(10) | The receiving location (destination). |
STATUS | VARCHAR2(1) | 'I' (Input), 'A' (Approved), 'S' (Shipped), 'R' (Received), 'C' (Closed). |
CREATE_DATE | DATE | When the transfer was created. |
DELIVERY_DATE | DATE | When the goods are expected to arrive. |
5. SQL Deep Dives
Finding Stale In-Transit Transfers
This query finds transfers that were shipped more than 14 days ago but have not yet been fully received at the destination store. These represent lost inventory.
Checking Transfer Reservations at the Origin
Before an origin location ships a transfer, the inventory is locked up in TSF_RESERVED_QTY. This query shows how much inventory a warehouse has locked up for outbound store transfers.
6. Common Gotchas
Important Gotchas
- !
Approving transfers without enough stock. RMS will allow you to approve a transfer even if the sending location doesn't have enough
STOCK_ON_HAND(driving the available physical stock negative). This assumes stock is inbound to the warehouse before the truck leaves. However, if the inbound stock is delayed, the warehouse cannot fulfill the transfer, causing artificial stockouts at the destination stores. - !
Short-Shipments vs. Lost in Transit. If a store requests 10 units, but the warehouse only ships 8, the 2 un-shipped units should be cancelled so they don't remain in
IN_TRANSIT_QTY. Proper configuration of thetsf_closebatch is required to automatically clean up these discrepancies. - !
Inter-Company Transfers. If a transfer occurs between two locations that belong to different financial entities (e.g., Company A transfers to Company B), it's an Inter-Company transfer. This requires specialized GL mapping and markup/markdown Tran Codes because ownership of the asset is fundamentally changing hands.
7. Official Oracle Resources
For further reading, consult the official Oracle documentation:


