Oracle Retail17 min readBy Priyanshu Pandey

Transfers: Moving Stock Across the Network

A deep dive into Oracle RMS Transfers. Learn how TSFHEAD and TSFDETAIL orchestrate the movement of inventory from Warehouse-to-Store (W2S) and Store-to-Store (S2S), including approval workflows, in-transit accounting, and receiving.

Phase 5 · Inventory Management · Oracle RMS Series

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.

17 min read📅August 8, 2026✍️Priyanshu Pandey📚Oracle RMS Series

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:

  1. Input (Worksheet): The transfer is created (manually or via Replenishment).
  2. Approved: The transfer is committed. The sending location is told to prepare the goods.
  3. Shipped: The sending location packs the goods onto a truck and sends an ASN (Advance Shipment Notice).
  4. Received: The receiving location offloads the truck and confirms the quantities.
  5. 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_QTY increases. (The goods are still physically there, but cannot be sold).
  • Receiving Location: IN_TRANSIT_QTY increases. (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_HAND decreases. TSF_RESERVED_QTY decreases. (The goods have left the building).
  • Receiving Location: IN_TRANSIT_QTY remains 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_QTY decreases. STOCK_ON_HAND increases.
🚨

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

TSFHEAD
The header record. Contains the origin location, destination location, and current status.
TSFDETAIL
The line-level details. Contains the items, quantities requested, shipped, and received.
ITEM_LOC_SOH
The inventory table that tracks TSF_RESERVED_QTY and IN_TRANSIT_QTY during the transfer.

Transfer Header (TSFHEAD)

ColumnTypeDescription
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
DATEWhen the transfer was created.
DELIVERY_DATE
DATEWhen 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.

Identify missing truck deliveries
sql
SELECT 
    th.tsf_no,
    th.from_loc,
    th.to_loc,
    td.item,
    td.tsf_qty AS requested_qty,
    td.ship_qty AS shipped_qty,
    td.received_qty,
    (td.ship_qty - NVL(td.received_qty, 0)) AS missing_in_transit_qty
FROM tsfhead th
JOIN tsfdetail td ON th.tsf_no = td.tsf_no
WHERE th.status IN ('S', 'A') -- Shipped or partially received
  AND th.delivery_date < SYSDATE - 14 -- More than 2 weeks overdue
  AND (td.ship_qty - NVL(td.received_qty, 0)) > 0
ORDER BY th.delivery_date ASC;

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.

Check outbound reservations
sql
SELECT 
    ils.item,
    ils.loc AS origin_warehouse,
    ils.stock_on_hand,
    ils.tsf_reserved_qty,
    (ils.stock_on_hand - ils.tsf_reserved_qty - ils.non_sellable_qty) AS free_available_stock
FROM item_loc_soh ils
WHERE ils.loc = 100 -- Warehouse 100
  AND ils.tsf_reserved_qty > 0;

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 the tsf_close batch 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:

RetailCoder
All systems operational
v1.0 Live

RC:OMS

Multi-channel order management with double-entry inventory ledger. Amazon, Flipkart, Shopify, WooCommerce — one source of truth.

Launch demo →
v1.0 Live

RC:Storefront

Self-hosted headless e-commerce. Your server, your data, zero transaction fees. Native RC:OMS inventory sync.

Visit Storefront →
Pipeline

RC:Pulse

AI-powered retail analytics and demand forecasting — built natively on top of your RC:OMS and Storefront data.

Request early access →
Built in India 🇮🇳  ·  Architected by Priyanshu PandeyTalk to an engineer →