Transfer Data Requirements

Transfer data (TRANSFER.csv) is used to capture movement of inventory between two locations (warehouses or stores). Transfer transactions are sent at the time the transfer is initiated at the shipping location. Transfer transactions are used primarily in Planning applications and RI reporting.

Rule Explanation

Rule	Explanation
Transfer Types	Transfers are provided using a type code, with 3 specific codes supported: N – Normal transfers are physical movement of inventory between two locations that impacts the stock on hand B – Book transfers are financial movement of inventory in the system of record that doesn’t result in any physical movement, but still impacts the stock on hand I – Intercompany transfers involve inventory moved into or out of another location that is part of a different legal entity, and therefore the transfer is treated like a purchase transaction in the source system Most transfers are categorized as Normal (`N`) by default. All transfer types are sent to Planning but would be loaded into separate measures as needed based on the type. Because transfers and receipts are separate measures used for different purposes, there is no overlap despite having similar information in both files.
Transfer In vs. Transfer Out	The transfers file has two sets of measures for the unit/cost/retail value into the location and out of the location. Typically these values contain the same data, but since they are aggregated and displayed separately in the target systems, they are also separate on the input so you have full control over what goes into each measure. For example, a transfer in of 5 units to location 102 would also have a transfer out of 5 units leaving location 56 (on the same record).

Transfer Types

Transfers are provided using a type code, with 3 specific codes supported:

N – Normal transfers are physical movement of inventory between two locations that impacts the stock on hand
B – Book transfers are financial movement of inventory in the system of record that doesn’t result in any physical movement, but still impacts the stock on hand
I – Intercompany transfers involve inventory moved into or out of another location that is part of a different legal entity, and therefore the transfer is treated like a purchase transaction in the source system

Most transfers are categorized as Normal (N) by default. All transfer types are sent to Planning but would be loaded into separate measures as needed based on the type. Because transfers and receipts are separate measures used for different purposes, there is no overlap despite having similar information in both files.

Transfer In vs. Transfer Out

The transfers file has two sets of measures for the unit/cost/retail value into the location and out of the location. Typically these values contain the same data, but since they are aggregated and displayed separately in the target systems, they are also separate on the input so you have full control over what goes into each measure. For example, a transfer in of 5 units to location 102 would also have a transfer out of 5 units leaving location 56 (on the same record).

In most cases, you will be providing the same set of transfer columns for any application. These columns are listed below with additional usage notes.

Column Header	Usage
ITEM	Must be the transaction level item or SKU number and must have a record in the `PRODUCT.csv` file.
ORG_NUM	Must be the location number where the item inventory is being shipped to (i.e. the receiving location). Must have a record in `ORGANIZATION.csv` file.
DAY_DT	The date that the transfer was initiated on (NOT the date when it completes or is received). Transfers can occur on any date both in history and nightly batch files.
FROM_ORG_NUM	Must be the location number where the item inventory is being moved out of (that is, the shipping location). Must have a record in `ORGANIZATION.csv` file.
TSF_TYPE_CODE	The numerical code representing the transfer type, as described in the business rules for transfers earlier in this section. This is a part of the primary key, meaning you may have multiple records for the same item/location/from-location/date with different transfer type codes.
TSF_TO_LOC_QTY TSF_TO_LOC_COST_AMT_LCL TSF_TO_LOC_RTL_AMT_LCL	The units and total cost/retail values for the transfer relative to the “to” location (`ORG_NUM`). Will be separately aggregated and displayed in MFP.
TSF_FROM_LOC_QTY TSF_FROM_LOC_COST_AMT_LCL TSF_FROM_LOC_RTL_AMT_LCL	The units and total cost/retail values for the transfer relative to the “from” location (`FROM_ORG_NUM`). Will be separately aggregated and displayed in MFP.
LOC_CURR_CODE FROM_DOC_CURR_CODE FROM_LOC_CURR_CODE DOC_CURR_CODE	The currency codes linked to the cost and retail amounts on the transfer data. The values in these fields will control how the system converts the amount (such as `TSF_TO_LOC_COST_AMT_LCL`) and how the `EXCH_RATE.csv` file data will be used. If you are providing the data in the source currency from the store or warehouse location, then `DOC_CURR_CODE` will be the currency of the source location. If the data is already all on one currency, then `DOC_CURR_CODE` will be that currency code. `LOC_CURR_CODE` is the primary reporting currency you wish RAP applications to operate in, so it will generally be a single hard-coded value on all your data files. The `FROM` columns will be the same thing applied for the `FROM_ORG_NUM` location. Review the section on Exchange Rate dimension data for additional scenarios.