Data Filtering and Conversions

In addition to simply aggregating the incoming fact data from item/location/date to item/location/week level, it is also important to understand what the data warehouse is doing with the data as it moves from the input files to the outbound interfaces. The table below summarizes the transformations and business logic applied to shared data warehouse facts used by RAP applications.

Table 6-2 Foundation Data Transformations

Transformation	Explanation
Currency Conversion	As part of the nightly batch, AIF DATA jobs will use exchange rate information to convert all incoming data from the source currency to the primary business currency. All data sent to downstream applications is in the primary currency. The data model maintains separate columns for both local and primary currency amounts for RI and AIF usage.
Tax Handling	The data model includes non-US taxes, such as VAT, in the sales retail amounts based on the indicators set up in the source system (such as Sales Audit) and in the data extraction jobs (RDE). When sending the sales data to Planning and AI Foundation, the default sales values may include VAT and only specific VAT-exclusive fields will remove it. You may optionally remove VAT from all data using configuration changes.
Transaction Date Usage	All fact data coming into the system includes a transaction date on the record. AIF DATA jobs aggregate from day to week level using transaction dates and does not alter or re-assign any records to different dates from what is provided. Transaction data in the past will be added to their historical week in the aggregates, no matter how far back it is dated.
Pack Item Handling	Downstream applications are currently only interested in the component item level, so AIF DATA will not send any fact data for pack items to other applications. Pack item sales must be spread to the component item level and loaded into the Sales Pack interface if this data is required for AI Foundation or Planning. All inventory, purchase order, and transaction data must be loaded at the component item level only.
Stockholding Locations	Inventory data for Planning is only exported for stockholding locations. A store indicated as a non-stockholding location on the location dimension will not be included in outbound inventory data. Physical warehouses which are not stockholding (because you use virtual warehouses) will also not be included.
Warehouse Types	Planning solutions assume that virtual warehouses are used as the stockholding locations for the business, and physical warehouses will be non-stockholding. For this reason, virtual warehouses are used to integrate data from the data warehouse to Planning, and no data is sent for the physical warehouses (except to indicate on each virtual WH the ID and name of the associated physical WH). If you don’t use virtual WHs, you can mark your physical WHs as virtual for the purposes of integration.
Future On Order	Planning applications require a forward-looking view of purchase orders based on the OTB EOW Date. The data warehouse accepts the actual purchase order details on the interfaces but will then transform the on-order amounts to be future-dated using the provided OTB EOW Dates. Orders which are past the OTB date will be included in the first EOW date, they will never be in the past.
Include On Order	Purchase Order data is limited by the Include On Order Flag on the Order Head interface. A value of N will not be included in the calculations for Planning.
Orderable Items	Purchase Order data is limited by the Orderable Flag on the Product interface. A value of N will not be included in the calculations for Planning.
Sellable Items	Regular non-pack items must be flagged as sellable to be interfaced to Planning as they do not want non-sellable item data in PDS at this time. This does not apply to pack items, which may be sellable or non-sellable because non-sellable pack items are often used for replenishment in IPO.
Inventory Adjustment Types	The system accepts 3 types of inventory adjustments using the codes 22, 23, and 41. For Planning, only the first two codes are exported. Code 22 relates to Shrink and code 23 relates to Non-Shrink.
Inventory Receipt Types	The system accepts 3 types of inventory receipts using the codes 20, 44~T, and 44~A. For Planning, all codes are sent but the 44s are summed together. Code 20 relates to purchase order receipts. Code 44 relates to Transfer receipts and Allocation receipts. Only code 20 is used by MFP in the GA solution.
Inventory Transfer Types	The system accepts 3 types of transfers using the codes N, B, and I (normal, book, and intercompany). All three types are sent to planning along with the type codes.