6 AIP-RPAS Configurations

The AIP-RPAS configurations listed in this chapter allow you to manipulate AIP to meet your business needs. The XML files, configuration files, and measures are applied to the replenishment processing to affect the plan that is produced.

shortfallStorePriorityMatrix.xml

The Shortfall Store Priority Matrix describes the order in which available inventory is allocated when an inventory shortfall occurs. The matrix is organized across two axes, Destination Types and Boundaries.

The Destination Types are the list of store priorities in the system plus a single entry for warehouses (because warehouses do not have priorities). The list of store priorities is configurable, but the default Destination Types are as follows:

Super High Priority Stores
High Priority Stores
Normal Priority Stores
All Warehouses

The boundaries in the Shortfall Store Priority Matrix are as follows:

CORT (Customer Orders over Review Time)
MSS (Minimum Sales Stock)
RP (Receipt Point)
RUTL (Receive Up To Level)
URP (Unconstrained Receipt Point)

The following is the default Shortfall Store Priority Matrix:

Default Shortfall Store Priority Matrix

Table 6-1 Default Shortfall Store Priority Matrix

	CORT	MSS	RP	RUTL	URP
Super High	1	4	7	8	9
High	2	5	10	11	12
Normal	3	6	13	14	15

The Shortfall Store Priority Matrix ranking is configurable. The configuration is specified using an XML file, shortfallStorePriorityMatrix.xml, that is formatted as shown in the following example:

Example: Shortfall Store Priority Matrix

<usage>
  <reconciliation-priority-matrix skuName="default">
    <boundary componentName="UserSpecifiedAllocation">
      <group id="1" priority="9" />
      <group id="2" priority="12" />
      <group id="3" priority="15" />
    </boundary>
    <boundary componentName="ReceiptUptoLevel">
      <group id="1" priority="8" />
      <group id="2" priority="11" />
      <group id="3" priority="14" />
    </boundary>
    <boundary componentName="ReceiptPoint">
      <group id="1" priority="7" />
      <group id="2" priority="10" />
      <group id="3" priority="13" />
    </boundary>
    <boundary componentName="MinimumSalesStock">
      <group id="1" priority="4" />
      <group id="2" priority="5" />
      <group id="3" priority="6" />
    </boundary>
    <boundary componentName="CustOrderOverReviewTime">
      <group id="1" priority="1" />
      <group id="2" priority="2" />
      <group id="3" priority="3" />
    </boundary>
  </reconciliation-priority-matrix>
</usage>
<reconciliation-priority-matrix>
    <boundary componentName="CustomerOrderOverReviewTime">
        <group id="1" priority="1"/>
        <group id="2" priority="2"/>
        <group id="3" priority="3"/>
    </boundary>
    <boundary componentName="WarehouseMinimumStock">
        <group id="0" priority="16"/>
    </boundary>
    <boundary componentName="MinimumSalesStock">
        <group id="0" priority="16"/>
        <group id="1" priority="4"/>
        <group id="2" priority="8"/>
        <group id="3" priority="9"/>
    </boundary>
    <boundary componentName="SupplyChainReceiptPoint">
        <group id="0" priority="17"/>
        <group id="1" priority="5"/>
        <group id="2" priority="10"/>
        <group id="3" priority="11"/>
    </boundary>
    <boundary componentName="SupplyChainReceiptUptoLevel">
        <group id="0" priority="18"/>
        <group id="1" priority="6"/>
        <group id="2" priority="12"/>
        <group id="3" priority="13"/>
    </boundary>
    <boundary componentName="UnconstrainedReceiptPlan">      <group id="1" priority="7"/>      <group id="2" priority="14"/>      <group id="3" priority="15"/>    </boundary>  </reconciliation-priority-matrix>

Within the XML file, the group ID corresponds to a destination priority, where 0 is reserved for All Warehouses. For example, the default destination priorities are 1 for Super High Priority Stores, 2 for High Priority Stores, and 3 for Normal Priority Stores. The componentName is the name of a numeric DataContainer that will contain the calculated allocation boundary data.

For each group, the allocation boundaries should only be prioritized in the following ascending order: CORT < MSS < RP < RUTL < URP. Since the allocation boundaries are cumulative, undesirable results can be generated if this order is not followed.

The matrix is customizable by SKU. The reconciliation-priority-matrix needs to be coped and the SKU written to the skuName argument. Any SKU that does not have its own matrix uses the default

It should also be noted that same priority numbers across multiple cells will not be supported in the current release. Each cell within the matrix should be assigned a unique priority number. Not doing so will result in erroneous results.

shortfallWarehousePriorityMatrix.xml

The Shortfall Warehouse Priority Matrix describes the order in which available inventory is allocated when an inventory shortfall occurs. The matrix is organized across two axes, Destination Types and Boundaries.

The Destination Types are a single entry for warehouses (because warehouses do not have priorities).

The boundaries in the Shortfall Warehouse Priority Matrix are as follows:

CORT (Customer Orders over Review Time)
MSS (Minimum Sales Stock)
RP (Receipt Point)
RUTL (Receive Up To Level)
URP (Unconstrained Receipt Point)

The following is the default Shortfall Warehouse Priority Matrix:

Default Shortfall Warehouse Priority Matrix

Table 6-2 Default Shortfall Warehouse Priority Matrix

	CORT	MSS	RP	RUTL
Warehouse	1	2	3	4

The Shortfall Warehouse Priority Matrix ranking is configurable. The configuration is specified using an XML file, shortfallWarehousePriorityMatrix.xml, that is formatted as shown in the following example:

Example: Shortfall Warehouse Priority Matrix

<usage>
  <reconciliation-priority-matrix skuName="default">
    <boundary componentName="ReceiptUptoLevel">
      <group id="0" priority="4" />
    </boundary>
    <boundary componentName="ReceiptPoint">
      <group id="0" priority="3" />
    </boundary>
    <boundary componentName="MinimumSalesStock">
      <group id="0" priority="2" />
    </boundary>
    <boundary componentName="CustOrderOverReviewTime">
      <group id="0" priority="1" />
    </boundary>
  </reconciliation-priority-matrix>
</usage>

Within the XML file, the group ID corresponds to a destination priority, where 0 is reserved for All Warehouses. The componentName is the name of a numeric DataContainer that will contain the calculated allocation boundary data.

For each group, the allocation boundaries should only be prioritized in the following ascending order: CORT < MSS < RP < RUTL. Since the allocation boundaries are cumulative, undesirable results can be generated if this order is not followed.

The matrix is customizable by SKU. The reconciliation-priority-matrix needs to be coped and the SKU written to the skuName argument. Any SKU that does not have its own matrix uses the default

surplusStorePriorityMatrix.xml

The Surplus Store Priority Matrix describes the order in which available inventory is allocated to stores when an inventory surplus occurs. This matrix is used when pushing only to stores. There are two surplus matrices, surplusStorePriorityMatrix and surplusWarehousePriorityMatrix, and which one is used for pushing depends on the valid destinations served by a supplier with a fixed purchase quantity or stockless warehouse. The matrix is organized across two axes, Destination Types and Boundaries. The Destination Types are the same as those in the shortfall version, but the Boundaries are different.

The two boundaries in the Surplus Priority Matrix are as follows:

Up To Upper Boundary
Above Upper Boundary

Table 6-3 Default Prioritized Store Surplus Priority Matrix

	Up To Upper Boundary	Above Upper Boundary
Super High	1	6
High	2	4
Normal	4	3

Table 6-4 Default Warehouse Destination Type Surplus Priority Matrix

	Up To Upper Boundary	Above Upper Boundary
All Destinations	1	2

When stepping through the Surplus Priority Matrix, the Upper Boundary is simply the appropriate Upper Boundary for the SKU and destination type. The Lower Boundary, on the other hand, is always assumed to be zero. This is because when pushing inventory to destinations, the inventory position of those destinations need not have reached any particular lower boundary because they cannot have ordered anything. Therefore, by treating the lower boundary as zero, it is possible to assess all destinations against the Upper Boundary, regardless of their inventory position.

This matrix is configurable through direct access to the database. However, the rule that must be observed is that, for any given Destination Type (consider this a row in the matrix), the boundaries must be addressed in increasing numerical order. There is no point in giving destinations a quantity Up to their Upper Boundary after giving them inventory Above their Upper Boundary. Note that, by definition, the Above the Upper Boundary cell has no upper numerical limit, and so as long as there are destinations associated with a particular row to which inventory can be sent, an Above Upper Boundary cell will always exhaust all remaining inventory.

The Surplus Priority Matrix ranking is configurable. The configuration is specified using an XML file, surplusStorePriorityMatrix.xml, that is formatted as shown:

Example: Surplus Priority Matrix

<usage>  <reconciliation-priority-matrix skuName="default">    <boundary componentName="Above Upper Boundary">      <group id="1" priority="6" />      <group id="2" priority="4" />      <group id="3" priority="3" />    </boundary>    <boundary componentName="Up To Upper Boundary">      <group id="1" priority="5" />      <group id="2" priority="2" />      <group id="3" priority="1" />    </boundary>  </reconciliation-priority-matrix></usage>

Within the XML file, the group ID corresponds to a destination grouping. The destination priorities should match the store priorities. For example, the default destination priorities are 1 for Super High Priority Stores, 2 for High Priority Stores, and 3 for Normal Priority Stores. The componentName is the name of a numeric DataContainer that contain the calculated allocation boundary data. The method currently has only one valid designation (fair-share) and should not be changed.

For each group, the allocation boundaries should only be prioritized in the following ascending order: Up To Upper Boundary < Above Upper Boundary. Since the allocation boundaries are cumulative, undesirable results can be generated if this order is not followed.

The matrix is customizable by SKU. The reconciliation-priority-matrix needs to be coped and the SKU written to the skuName argument. Any SKU that does not have its own matrix uses the default.

Measures

The measures in the following sections are applied to the replenishment processing to affect the plan.

aip_env_rpas.sh

In addition to the infrastructure-type environment variables listed in Chapter 4, "System Configuration," the aip_env_rpas.sh script contains implementation parameters that the business must customize. The values assigned to the variables in the Implementation Parameters section of aip_env_rpas.sh are assigned as values to selected AIP-RPAS measures during execution of the set_implementation_parms.sh script--which is run from aip_batch.sh when the first time parameter is True.

See Chapter 18, "First Day of AIP," for details on running the AIP batch with the first time parameter set to True.

Table 6-5 contains a description of the variables in aip_env_rpas.sh that correspond to the Implementation Parameters for AIP-RPAS.

Table 6-5 Implementation Parameters for aip_env_rpas.sh

Implementation Parameters	Default Values	Description
AUTOMATIC_WAREHOUSE_PROFILE_ASSIGNMENT	0	This measure controls the execution of the automatic warehouse profile assignment logic. If set to 2- Disabled, the logic will not execute and you are responsible for manually assigning new SKUs to warehouse profiles. If set to 1 - Supplier, the system will search for a warehouse profile that was created for one of the SKU's suppliers and assign the new SKU to it. If set to 0 - Class, the system will look for the warehouse profile that has been designated as the default profile for the SKU's class (Class to Profile Assignment) and assign the new SKU to it. This measure should be set to Class or Disabled when AUTOMATIC_WAREHOUSE_PROFILE_CREATION is False.
AUTOMATIC_WAREHOUSE_PROFILE_CREATION	FALSE	Controls the execution of the automatic warehouse profile creation logic. If set to False, the logic will not execute and warehouse profiles will not be automatically created. You are responsible for manually creating warehouse profiles. If set to True, one warehouse profile is created for each new supplier. This parameter should be True if AUTOMATIC_WAREHOUSE_PROFILE_ASSIGNMENT is set to 1- Supplier. Otherwise, this parameter should be False. Valid values are True and False.
CSC_AND_STORE_DIRECT_STRING	CS_ST	This is the supplier ship-to value that indicates the supplier ships to both CSC warehouses and stores. Because the Supplier Ship-to values are also sent to AIP on Oracle, the codes and table constraints in both systems must remain consistent. This parameter will be used to initialize the RPAS measure: dmx_cscdir.
CSC_STORE_FORMAT_STRING	1002	This string contains the store format of the stores that receive their SKUs from the warehouse when the supplier of the SKU can supply both the stores and the warehouses. This setting is used when the batch tries to automatically set the Store Source value for a new SKU. When the selected supplier of the SKU has a Supplier Ship-to value equal to the value in dmx_cscdir, this indicates that the supplier can ship to either CSC warehouses or directly to stores. To determine which store source to select (the supplier or warehouse) the store format of each store that the SKU is on-supply at is compared to the store format listed in this measure. If the store's format matches, then the store's default CSC warehouse is saved as the source for the SKU/store. This means that the supplier will provide the SKU to the warehouse and the warehouse will provide the SKU to the store. This parameter will be used to initialize the RPAS measure: dmx_cscstrfmt.
CYCLE_START_DATE	20000102	The date in YYYYMMDD format, that denotes the start date for counting day of fortnight and day of four-week period positions. This variable can be customized if you are not using AIP-Oracle.
DEFAULT_PLANNING_HORIZON	35	This variable is used as a default store planning horizon for DM. This parameter will be used to initialize the RPAS measure: dm0_defplnhzn.
POST_PROMOTION_SUBSTITUTION_FLAG	FALSE	The Post Promotion Substitution Flag determines whether promotional items should be substituted after their promotional date. This parameter will be used to initialize the RPAS measure: dmx_pstpmsflg.
PROMOTIONAL_VARIANT_FORECAST_AS_STANDARD	FALSE	The promotional variant Forecast as Standard Flag is a system parameter. It defaults to False. The user can change this parameter to True or False depending on the forecast system used. For RDF, it remains True. Because this parameter has a default value of False, the demand of a standard SKU will not automatically transfer to a promotional variant product during a promotional event in AIP. In order to facilitate transferring the demand from standard to promotional product, users need to manually change the value to True and then run the set_implementation_parameters.sh script for the update to take effect. It is important to note that the `set_implementation_parameters` script is not typically run during a patch or upgrade install, so users will need to run it separately in that case.
SPECIAL_ORDER_CYCLE	PRFWS	The dmx_speocy measure contains the default Order Cycle identifier. This order cycle is used by default when automatically generating profiles and order groups. This should not be changed unless the AIP Oracle PL/SQL is customized to use the new Order Cycle code and the order cycle exists in the AIP Oracle database. The order cycle lengths and lead times are not defined in AIP-RPAS at implementation time. The order cycle lengths and lead times are defined in AIP Oracle at implementation time and will be loaded into AIP-RPAS before the first full run of DM Batch. PRFWS - Used when automatically creating new Warehouse Profiles.
STORE_ONLY_STRING	STR	This string contains the Supplier Ship-to code that represents Stores Only. This code is used when attempting to automatically set the store source value for a new SKU. Because the Supplier Ship-to values are also sent to AIP on Oracle, the codes and table constraints in both systems must remain consistent. This parameter will be used to initialize the RPAS measure: dmx_storeonly.
SUPPLIER_ORDER_MULTIPLE_ALGORITHM	1	This flag determines whether you will manually enter ordering parameters for the entire supply chain or whether the supplier's value for Pallet Multiple and Order Multiple will be spread through the supply chain. If the value is 1, the two parameters listed above must be defined for both supplier-to-warehouse and warehouse-to-warehouse combinations of the supply chain. If the value is 0, the two parameters listed above need only be defined for the top tier of the supply chain--supplier-to-warehouse combinations. An algorithm will run as part of DM Batch to set the values for the inner tiers of the supply chain equal to the value of the top tier. Note that any warehouse-to-warehouse combinations that are either system-generated by DM Automated Maintenance or user-generated will be overwritten in the RPAS measure. This parameter will be used to initialize the RPAS measure: dmx_somalg.
WAREHOUSE_TYPE_GSS	XD_GS	The value of this variable is a string that is used to represent warehouses that are Deconsolidation Centers. This parameter will be used to initialize the RPAS measure: IpWhTypGSSI.
WAREHOUSE_TYPE_RDC	CS_RG	The value of this variable is a string that is used to represent warehouses that are Regional Distribution Centers. This parameter will be used to initialize the RPAS measure: IpWhTypRDCI.
WAREHOUSE_TYPE_XDK	XD_RG	The value of this variable is a string that is used to represent warehouses that are Cross docks. This parameter will be used to initialize the RPAS measure: IpWhTypXDKI.
YEARS_FUTURE_IN_CALENDAR	2	This parameter is used by the RMS-AIP Transformation script, aipt_clnd.ksh, to create the calendar hierarchy load file, clnd.csv.dat, from the RMS calendar extract file. This parameter defines the number of years of future days that will be put into clnd.csv.dat.
YEARS_HISTORY_IN_CALENDAR	1	This parameter is used by the RMS-AIP Transformation script, aipt_clnd.ksh, to create the calendar hierarchy load file, clnd.csv.dat, from the RMS calendar extract file. This parameter defines the number of years of historical days that will be put into clnd.csv.dat.

IpRoLocTypeI

Replenishment Optimization Location Types

This measure specifies which location types are considered when extracting data for RO. By default this measure is set to 0 for Stores. The valid values for this measure are:

0 - Stores
1 - Warehouses
2 - Stores and Warehouses

This measure can also be edited by inserting it into an analysis workbook. This measure value should be limited to just those location types that are optimized in the optimization system and replenished in AIP.

Modifying Measure Base Intersections Using Configuration Tools

Using the RPAS Configuration Tools, the base intersection of the following measures can be modified.

Note:

The data file containing the data must match the configured measure intersection.

Measure	Description	Valid Configuration
IpFctWkPrfD	Week to Day Demand Forecast Percentage Default	All Products/Chain/Day-Of-Week Company/Chain/Day-Of-Week Division/Chain/Day-Of-Week Department/Chain/Day-Of-Week Class/Chain/Day-Of-Week Subclass/Chain/Day-Of-Week
IpFctWkPrfE	Week to Day Demand Forecast Percentage Override	Subclass/Chain/Day-of-Week

Import Configuration Files

Missing data files can corrupt downstream data and cause errors that are difficult to interpret and trace to the root. Therefore, validation of the received import files must be performed prior to running any batch calculations or loading any files with dependencies. A set of configuration files are used to validate that all required files are present before proceeding to load them.

The configuration files provide a complete list of hierarchy and measure data that can be loaded. If a client chooses to load additional data rather than have the user enter it, the client can add the file to the appropriate configuration file so that its presence in the AIP-RPAS import directory is validated.
- The configuration files can be modified to specify whether a file is required or optional.
- A file is considered required if its presence is essential for the batch run. A missing required file will cause batch to halt. A required file must be present, even if it is zero (0) byte, which indicates that the extracting worked correctly but there was no data to extract.
- A file is considered optional if the batch will not halt when the file is not present. No zero (0) byte file is required. A file can only be deemed optional if it provides data that is not required by the replenishment batch modules, is not required by AIP Online, and there are no required files that are dependent on it.
- Additionally, if the same data can be entered in a workbook before the batch run, the loaded data can also be considered optional.
- Optional files do not have to be loaded, or they can be loaded weekly or less frequently depending on the file/purpose.

The configuration files for validation are:

earlyfiles.config
latefiles.config
forecastdata_from_external.config

After the presence of all required files has been validated, a number of files are run through a stocking point prefix-adding script as well as a binary executable called interutil. These processes perform a myriad of formatting tasks, including splitting files, adding S, V or W prefixes to Stores, Suppliers, and Warehouses respectively, and transforming RMS-sourced files from RMS SKU to AIP SKU or SKU-pack size. The list of files containing measure data that are reformatted by interutil is determined by a second set of configuration files.

The configuration files can be modified to prevent interutil from being run for files that are in AIP-RPAS loadable format.
Only files containing measure data are listed in the configuration files. Hierarchy files must be provided in the predetermined format.

Note:

The Oracle Retail Advanced Inventory Planning Operations Guide and Chapter 9, "RMS Integration and Data Mapping" of this guide, should be reviewed for file format and file output from interutil before modifying the contents of the configuration files.

The interutil configuration files are:

dm_rms_measures.config
srp_rms_measures.config
wrp_rms_measures.config

Table 6-6 provides information about each of the loadable data files mentioned in the configuration files.

Table 6-6 Loadable Data Files

Value Name	File Name	Description of Value and Purpose for Loading	Early, Late-precritical, or Late (critical)
Ad (advertisement) Hierarchy	had.txt	Used for viewing Ad information and filtering workbook wizard selections based on Ad information.	Early
Ad/Rollout Notes	ipadrltntsi.txt	Notes to the Planner about advertisements, new SKU rollout, or any other pertinent information needed for planning. Notes can be entered/changed in workbooks as well.	Early
Customer Orders	sr0_co_.txt	Contains a total order quantity of a SKU that has been committed to customers. Customer Orders are treated as additional need above and beyond forecasted need.	Early
Daily Forecast	sr0_frclvl1_[1..n].txt	The daily forecast is optional for three reasons: Both a daily and weekly forecasts are not required. One can be provided and not the other (depending on system configuration). An updated forecast is typically not reproduced daily, and therefore is not required daily. A forecast is not required if using replenishment methods that use historical sales.	Late-precritical
Daily Forecast Standard Deviation	sr0_fcterrlvl1.txt	Standard Deviation of the daily forecast.	Late-precritical
Daily Sales	sr0_dayslsld.txt	Daily Sales are used in store replenishment to calculate Today's Projected Inventory position when a Current Inventory Feed is not available. If daily sales are also unavailable, then another calculation alternative is used.	Early
Daily Short Code Sales	sr0_dyscsls.txt	This value represents the number of units that were sold as a Markdown yesterday. This value is used for calculating High Dissipation alerts.	Late
Default Warehouse	default_wh.txt	Used to automatically assign the STORE SOURCE. If not provided, the Default Warehouse CSC might be used. Otherwise, the store source will not be automatically assigned when the store's source is determined to be the default warehouse (based on the SKU's supplier/ship-to value).	Early
Default Warehouse CSC	default_wh.txt	Used to automatically assign the STORE SOURCE. If not provided, the Default Warehouse might be used. Otherwise, the store source will not be automatically assigned when the store's source is determined to be the default CSC warehouse (based on the SKU's supplier/ship-to value).	Early
Direct Supplier Flag	dmx_dirspl.txt	This flag indicates whether the Supplier is able to supply stores directly or not. This prevents the system from allowing certain supply-chain setups.	Early
Discontinuation Date	dmx_dscdt_.txt	Flags SKU-packs as discontinued. Used to automatically de-range SKU-pack sizes and automatically re-assign ordering pack sizes.	Early
Expected Write-off	sr0_expwrtoff.txt	Represents the quantity of stock expected to be thrown out for any reason (spoilage, breakage) on a given day. Expected Write-offs override calculated expected spoilage.	Early
Historical Lost Sales	sr0_hstls_.txt	Used in Alert Calculations.	Early
Inbound Capacity Cases for Reporting	ipibcpcco.txt	Inbound capacity in cases at a warehouse. Used for OBIEE Reporting.	Early
Interval Hierarchy	intv.txt	This is used when loading the Poisson Distribution Lookup table. This is required if Poisson will be used as a replenishment method.	Early
Inventory Adjustments	sr0_invadj.txt	This value contains the total of all Inventory Adjustments made yesterday for the SKU at a particular store. This value can be used for resolving alerts. This value can be positive or negative since it represents net adjustments. Some of net adjustments can be negative (inventory decreases).	Late
Off Sale Dates	dm0_ofseffdt_.txt	Contains Store, SKU, Off Sale Dates. Determines the date that the SKU will no longer be sold at the store. This value is used in determining the off-supply date that determines when AIP will no longer replenish the SKU at the store. If this file value is blank, the system will use the SYSTEM_HIGH_DATE (infinity) as the off-sale date.	Early
On Sale Dates	dm0_onseffdt_.txt	Contains Store, SKU, On Sale Dates. Determines when the SKU will be sold at the store. This value is used in determining the on-supply date that determines when AIP will begin to replenish the SKU at the store.	Early
Outbound Capacity Cases for Reporting	ipobcpcco.txt	Outbound capacity in cases at a warehouse. Used for OBIEE Reporting.	Early
Pack Type	dmx_pcktyp.txt	Defines a single pack type for each SKU-pack size. Pack Type is used in the Automation to set Location Orderable Unit, Order Multiple, and store ordering pack sizes (store/store format pack size). Automation will not be able to assign a value if the pack type is not defined for SKU-pack sizes.	Early
Poisson Distribution Table	srx_poidst.txt	Poisson Distribution Table.	Early
Pre-Priced Status	dmx_pprsts.txt	Used to substitute a pre-priced item in place of a standard item during a promotion. The Default status of a SKU is False or Not Pre-priced.	Early
Product Life (shelf life)	sr0_prdlfe.txt	Indicates the number of days a product can sit in the store before is spoils. This value should only be set for short-life items that are at high risk of waste due to spoilage.	Late


RDF Detail Alert (for Store)	sr0_rdfdtdmsk.txt	Optional flag to load into AIP from forecasting system, indicating there is an issue resolving in AIP, the planning app, instead of the forecasting app.	Late-precritical
RDF Detail Alert (for Warehouse)	iprdfdtdaltv.txt	Optional flag to load into AIP from the forecasting system for resolving in AIP, the planning app, instead of the forecasting application.	Late-precritical
RDF Detail Alert Count	sr0_rdfdtdcnt.txt	Count of all RDF Detail alerts generated for a SKU/store.	Late-precritical
Run Overstock Alert Flag	sr0_ovrstkflg.txt	Indicates whether or not the store is to be included in Overstock Alert calculation.	Early
Sister Store	sister_store.txt	Defines a like store for a New Store. When the file is provided along with a future store open date, the system will copy the supply-chain of the existing store to the new store.	Early
Sister Warehouse	sister_wh.txt	Defines a like warehouse for a New Warehouse. When the file is provided along with a future warehouse open date, the system will copy the supply-chain of the existing warehouse to the new warehouse.	Early
SKU Hierarchy (Product Hierarchy)	item.txt	Contains all SKUs that should exist in AIP. All files that contain a SKU intersection are dependent upon this file. SKUs begin to age when not present/loaded from this file. If not yet purged, the age of a SKU is reset if it is later re-loaded.	Early
SKU Retail Price	srx_prdrpr.txt	SKU Retail Price interfaced through an external system or custom RMS.	Early
SPQ Order Commit Quantity	ipodcmti.txt	This is the quantity that has been committed to be ordered/purchased from the supplier in a particular week. The nature of the commitment is defined in the SPQ commitment type. This value can be entered manually in a workbook or loaded.	Early
Store Ad End Date	ipadendi.txt	Defines the end date of a Store Ad.	Early
Store Ad Start Date	ipadstai.txt	Defines the start date of a Store Ad.	Early
Store Adjusted Sales	sr0_adjsls.txt	Can be used in User Specified Allocations for Allocation on Rule Based Index.	Early
Store Ads - Grand Opening	sr0_ad_go_.txt	Determines which SKU/store/day has grand opening ads.	Early
Store Ads - Inserts	sr0_ad_irt.txt	Indicates inserts ads exist for the listed SKU/Store/Day.	Early
Store Ads - Others	sr0_ad_oth.txt	Indicates ads classified as other non-standard ads exist for the listed SKU/Store/Day.	Early
Store Ads - Run On Press	sr0_ad_rop.txt	Indicates an ad has been run as a result of extra Press for the listed SKU/Store/Day.	Early
Store Ads (advertisements)	sr0_ad_.txt	Information to be viewed in the Workbooks. Flags whether a SKU/store is included in any ads.	Early
Store Average Weekly Rate of Sale	sr0_avgrosld_.txt	Used to calculate the total Average Weekly Rate of Sales across all stores served by a warehouse. The value is used when the warehouse replenishment method is Factor ARS.	Early
Store Current Inventory	sr0_curinv_1.txt	The quantity of inventory at the store that is available to meet immediate demand.	Late
Store Hierarchy	loc.txt	Contains all Stores that should exist in AIP. All files that contain a Store intersection are dependent upon this file. Stores begin to age when not present/loaded from this file. If not yet purged, the age of a Store is reset if it is later re-loaded.	Early
Store In-transit Quantity	sr0_it_.txt	In-transit quantities represent those orders that have physically shipped to the destination.	Late
Store Known Demand	sr0_knowndemand.txt	Used in place of forecasted demand if loaded.	Early
Store Loaded Safety Stock	sr0_ss_ld_.txt	Safety Stock for Loaded Safety Stock Dynamic replenishment method.	Early
Store On-order Quantity	sr0_oo_.txt	On-order Quantity represents those orders that have been run, but as of yet there is no information regarding their physical shipment to the destination.	Late
Store Open Date	sister_store.txt	Defines the date that a new store is opening. This date is used along with the Sister Store data to perform a copy of the existing Store's supply-chain to the new store. This value is also used for Walking Store Lead Time automation.	Early
Store Replenishment Subtype Code	sr0_rplsubcde.txt	This is for informational purposes only. It provides the planner with more detailed information about how the SKU is replenished at the store.	Early
Store Replenishment Type Code	sr0_rplcde.txt	This is for informational purposes only. It provides the planner with information about how the SKU is replenished at the store.	Early
Store Trading Days	sr0_tdgday.txt	Used to calculate the In-Scope indicator for Alerts. Typically, a day will not be counted or considered during alert calculations if it is not a trading day (for example, the business is not Open). By default, all days are trading days.	Early
Supplier Hierarchy	splr.txt	Contains all Suppliers that should exist in AIP. All files that contain a Supplier intersection are dependent upon this file. Suppliers begin to age when not present/loaded from this file. If not yet purged, the age of a Supplier is reset if it is later re-loaded.	Early
Supplier Ship-to	dmx_shpto.txt	Provides a code that maps the supplier to the types of locations that it ships products to. The ship-to mappings (configured in a table) are used to automatically set up the supply-chain. If missing, Automation will be unable to automatically set up the supply chain for the new Supplier and its new SKUs.	Early
Supplier/SKU-pack size Associations	dmx_prdspllks.txt	Defines which SKU-pack sizes are available from each Supplier.	Early
Total Store Average Rate of Sales	ipavgrtslsi.txt	Can be calculated by summing the values in sr0_avgrosld_ for each store that is served by the warehouse or loaded outright. It is used when the warehouse replenishment method is Factor ARS.	Early
Value Added Product Association	dmx_vadprdasc.txt	Used to substitute pre-priced/added value items for standard items during a promotion. This file contains the parent child relationship between the SKUs.	Early
Warehouse Current Inventory	wr1_curinv.txt	The quantity of inventory at the warehouse that is available to meet immediate demand. This file is required. A 0-byte empty file can be provided in place of actual values if inventory positions at the warehouse are not available. Replenishment will then fall into the contingency processing for missing warehouse inventory positions.	Late
Warehouse Hierarchy	whse.txt	Contains all stockholding Warehouses that should exist in AIP. All files that contain a Warehouse intersection are dependent upon this file. Warehouses begin to age when not present/loaded from this file. If not yet purged, the age of a Warehouse is reset if it is later re-loaded.	Early
Warehouse Historical Weekly Sales	ipslsi.txt	Historic Weekly Sales are used in the Sales Week Range and Average Weekly Sales replenishment methods. The value will be used when warehouse replenishment method is set to either of these methods.	Early
Warehouse Holdback Quantity	iphldbckqtyi.txt	A quantity of inventory at the warehouse that should be held in reserve.	Early
Warehouse Holding Capacity	ipwhhldcpci.txt	Used for Network Group Alert calculations.	Early
Warehouse Independent ARS	ipiavgrtslsi.txt	Represents the externally loaded Average Rate of Sale (ARS) assigned to the warehouse.	Early
Warehouse In-transit Qty	wr1_it_.txt	In-transit quantities represent those orders that have physically shipped to the destination. If no on-order quantity exists, it is assumed to be 0. This file is required. A 0-byte empty file can be provided if running Store-only replenishment without reconciliation.	Late
Warehouse Loaded Safety Stock	ipldssi.txt	Required if the Loaded Safety Stock replenishment method will be used for warehouse replenishment.	Early
Warehouse On-order Qty	wr1_oo_.txt	On-order Quantity represents those orders that have been run, but as of yet there is no information regarding their physical shipment to the destination. If no on-order quantity exists, it is assumed to be 0. This file is required. A 0-byte empty file can be provided in place of actual values if running Store-only replenishment without reconciliation.	Late
WH Allocations In The Well	wr1_aiw.txt	Future allocations out of the warehouse from an external system not accounted for in inventory figures. This file is required. A 0-byte file can be provided in place of actual values.	Late
WH Transfers in the Well	wr1_tiw.txt	Outstanding transfers out of the warehouse from an external system not accounted for in inventory figures. This file is required. A 0-byte file can be provided in place of actual values.	Late
Warehouse Replenishment Sub-type Code	iprplstcdi.txt	Information to be viewed in the Workbooks. Indicates how the SKU is replenished at the warehouse.	Early
Warehouse Replenishment Type Code	iprpltcdi.txt	Information to be viewed in the Workbooks. Indicates how the SKU is replenished at the warehouse.	Early
Warehouse Total Held Stock	ipttlhlstki.txt	Total quantity of unavailable stock held at the warehouse. This quantity is for informational purposes only. It is assumed to have been subtracted out of the Current Inventory position provided.	Early
Warehouse Type	wh_type.txt	This warehouse attribute is used for virtually all into-warehouse automation. It is also used in the WRP Company Level Inventory Analysis Worksheet, which, if used, displays end-of-week inventory against specific warehouse types. This data should be set to required if into-warehouse Automation is desired.	Early
Waste Adjustments	sr0_wstadj.txt	This value contains the total of all Waste Adjustments made yesterday for the SKU at a particular store. This value can be used for calculating High Dissipation alerts. This value is expected to be negative because waste decreases inventory.	Late
Week to Day Forecast Percentage Default	ipfctwkprfd.txt	Used to spread weekly forecasts to a daily level. This file is needed when using weekly forecasts.	Early
Week to Day Forecast Percentage Exception	ipfctwkprfe.txt	Used to spread weekly forecasts to a daily level. This file is only needed if an exception to the default is needed.	Early
Weekly Base Sales Forecast	sr0_wkbsf_ld.txt	A base line forecast at the weekly level that does not include promotions. Used in calculated Presentation Stock.	Late-precritical
Weekly Forecast	sr0_frclvl2_[1..n].txt	The weekly forecast is optional for three reasons. Both a daily and weekly forecast are not required. One can be provided and not the other (depending on system configuration). An updated forecast is typically not reproduced daily and is therefore not required daily. A forecast is not required if using replenishment methods that use historical sales.	Late-precritical
Weekly Forecast Standard Deviation	sr0_fcterrlvl2.txt	Standard Deviation of the weekly forecast.	Late-precritical

Moving Integration Data Source from RMS to a Non-RMS External System

AIP is configurable to allow some files whose default source is RMS to be sourced instead from a Non-RMS External System. The following instructions detail the procedure for adjusting the configuration files to support this change of source.

Prerequisites for Moving the Source Application of an RMS Data Feed

The data feed must be one of the inventory data feeds that arrives late from RMS, as listed in wrp_rms_measures.config or srp_rms_measures.config file, as well as the latefiles.config file. These files are located in the following directory of the domain:
```
$AIPDOMAIN/interface/config/external/latefiles.config
$AIPDOMAIN/interface/config/rms/srp_rms_measures.config
$AIPDOMAIN/interface/config/rms/wrp_rms_measures.config
```
The data feed must now be formatted in RPAS-loadable format. No processing will be performed to translate RMS SKU to AIP SKU or to add stocking-point prefixes. However, the data can still be split into multiple pieces (for Store Current Inventory, namely sr0_curinv).

Note:
For the RPAS measure loadable formats of the inventory data feeds, see "File Format Including Mapping to AIP-RPAS Measure Format"
The data feed is still considered to be a late arrival.

Setup

Add the data feed to the measdata_from_external.config configuration file. It is located is in the following directory of the domain:

$AIPDOMAIN/interface/config/external/measdata_from_external.config
Remove the data feed from srp_rms_measures.config or wrp_rms_measures.config. Also remove the data feed from inv_meas_ntier_prefix.config. These configuration files are located in the following directories of the domain:

$AIPDOMAIN/interface/config/rms/srp_rms_measures.config

$AIPDOMAIN/interface/config/rms/wrp_rms_measures.config

$AIPDOMAIN/interface/config/rms/meas/inv_meas_ntier_prefix.config

Process

After the early files (as listed in earlyfiles.config) are placed into the domain, run the appropriate aip_batch processes, as normal, to process external data.

Note:

process_external_data.sh will not process any file that has been moved from RMS to External source, as the feed is still considered late.

Additionally, load_non_rms_external.sh will not load the moved feed, as it is not in the $INTERFACE_EXTERNAL_DIR directory yet.

After the late files (as listed in latefiles.config) are placed into the domain (in the $INTERFACE_RMS_DIR directory), run the appropriate aip_batch steps, as normal, to process inventory data.

Note:

process_inventory_data.sh will consolidate the current inventory data feeds as prescribed in the script, regardless of whether they are RMS-sourced or non-RMS-sourced. However, process_inventory_data.sh will not process any moved feed by adding stocking point prefixes or conversion from RMS SKU to AIP SKU/SKU-pack size, as the feed is no longer listed in the appropriate configuration files as in Step 2 in "Setup".

Finally, load_replenishment_measures.sh will not load the moved feed, for the same reason.

Note:

All non-RMS external late files are moved and loaded without manual client intervention by way of the logic added to process_inventory_data.sh and load_non_rms_files.sh as called by load_replenishment_measures.sh. The script, process_inventory_data.sh, moves the files to the correct spot for external processing, and the script, load_non_rms_files.sh, loads the files.