14 Inventory Optimization

This chapter describes the Oracle Retail AI Foundation Inventory Optimization Cloud Service.

Overview

Inventory Optimization (IO) determines the optimal replenishment policies, reorder point (RP), and receive up-to level (RUTL), at the item/location level for both store and warehouse locations. The optimization engine uses simulation-based optimization and machine learning methods to calculate the trade-offs between the service level and the inventory cost, and the trade-off analysis is leveraged to generate the optimal replenishment policies for achieving a desired target service level. These data-driven policies are pushed to Oracle Retail Merchandising System (RMS) to generate and execute purchase orders and transfers. To provide full visibility, the replenishment policies are also used within IO to calculate optimal transfers and purchase orders. In addition, IO recommends optimal rebalancing transfers between stores to increase sell-through and to avoid markdowns. This type of strategy can be turned off when not applicable (for example, for grocery categories).

IO leverages historical sales and inventory, business requirements such as lead time and review schedule, and the demand forecast to optimize the replenishment policies. The demand forecast that is generated by the forecast engine within AI Foundation considers different factors such as price effect, holidays, and promotions, and variation across customer segments.

The conceptual flow of different components in IO is as follows. AIF/RI is the core data foundation layer that consumes the retailer data, including merchandise and location hierarchy and historical sales and inventory. The IO algorithm obtains inputs such as replenishment strategies and objectives from the UI and from the strategy rules interface that can be used for specifying strategies that are not supported in the UI, along with replenishment attributes such as lead time, review schedule, and presentation stock from AIF/RI. The other key input to IO is the demand forecast, which is generated and provided by the AIF forecast engine.

The simulation-based optimization and machine learning algorithms in IO analyze historical data and different future demand scenarios to calculate the trade-offs between service level and inventory cost and generate optimal replenishment policies (that is, the Re-order Point (RP) and the Receive up-to Level (RUTL) for each item-location). These optimal policies, along with data for inventory positions and replenishment attributes such as minimum order quantity, are leveraged to determine the recommended transfers and purchase orders (PO). The optimal replenishment policies as well as the recommended transfers and purchase orders can be viewed in the IO UI. The replenishment policies that are auto-approved or are approved by the user will be exported to the retailer's replenishment system, such as RMS, to generate and execute orders. The user can also review and submit the transfers and purchase orders within IO. In this release, the recommendations for purchase orders and replenishment transfers (warehouse-to-store and warehouse-to-warehouse) are not integrated with the retailer's order execution system and primarily provide information about the time phase view of orders. The submitted recommendations will not be pushed to other systems.

The IO optimization algorithm also analyzes various rebalancing transfers efficiently and generates optimal transfers that are in line with the retailer's objective, such as minimizing total transfer costs and maximizing sell-through. The recommended rebalancing transfers can be reviewed and edited in the IO UI. The replenishment policies that are auto-approved or are approved by the user will be exported to the retailer's order management system, such as RMS or any external system, to generate and execute orders. If the rebalancing transfers are submitted within IO, they will be exported to the retailer's replenishment system for final approval by the user and then execution.

Inventory Optimization Runs

IO supports two kinds of runs: user runs and batch runs. Batch runs are scheduled to run automatically at regular intervals (for example, weekly or daily). User runs are typically created by the user to do what-if analysis and/or to override the recommendations generated by the latest batch run. IO runs generate recommendations at the item-location level. The items that are included in a run can be selected by specifying one, a multiple, or all of the nodes at a higher merchandise level, such as department. This level is configurable. Similarly, the locations that are to be included in a run can be selected by specifying one, a multiple, or all of the nodes at a higher location level, such as area. This level is configurable.

Each run, using the latest sales data and inventory levels, updates the replenishment policies and PO/transfer recommendations. The number of item-locations that are processed in each run can vary, based on the retailer's review schedule. During each run, only the item-locations that are due for review for replenishment on the next day are processed and their replenishment policies are updated. For example, a run that is scheduled for a nightly batch on Sunday 01/08/2023 would process and update the policies for item-locations that have a next review date of Monday 01/09/2023 in the retailer's replenishment system. This allows the user to review and approve the policies that were not auto-approved on Monday before they are pushed to the replenishment system for generating and executing orders.

An analyst can review the results of runs and approve the replenishment policies for each item-location. In addition, the analyst can change the target service level strategy for the item-location or at higher levels of merchandise-location based upon the cost-service level trade-offs. Changes in service level strategies will take effect from the next batch run onwards. The user can also review the PO and transfers and change the order quantity, submit the recommended order, or approve the recommended order. Submitted recommended orders are exported to the order execution system in worksheet mode and require final approval by the end user within the order execution system. Approved recommendations are exported to the order execution system in final approved mode and are executed on the order date. In this release, the approve action is available only for rebalancing transfers and for replenishment policies.

Inventory Optimization UI Workflow

Figure 14-1 shows an overview of the IO UI workflow, which consists of the following:

Run Overview: This is the dashboard for the IO runs. In this tab, the user can see a list of all existing runs, along with details that describe each run. Runs have four different statuses: Setup, In Progress, Successful, and Failed.

From the run overview table, the user can create a run, copy a run, open a run, or delete a run. When the user clicks on a successful run, it is opened in a new tab with three sub-tabs to show replenishment policies, rebalancing transfers, and PO and transfers, as well as a sub-tab to show the summary of inputs of the run. For a failed run, only the input summary sub-tab is displayed. To create a run, the user must specify the run scope and strategy. As part of the run scope, the user specifies the areas and departments for the run and the type of analysis to be performed. As part of run strategy, the user can specify the business rules.
Recommendations: This is the main screen where the user can view, override, and submit/approve different types of recommendations. This screen shows the approved/submitted recommendations across all runs and the ready for review recommendations from the most recent run. This screen consists of five sections.
- Overview–A calendar view that shows the summary of different types of recommendations and provides a link for the user to open and view the details of recommendations for each date.
- Replenishment Policies–Used to review and approve replenishment policies and to set service level strategies.
- Rebalancing Transfers–Used to review, override, and submit/approve rebalancing recommendations.
- PO/Transfers–Used to review, override, and submit recommended PO and transfers. These include warehouse/supplier to store and warehouse/supplier to warehouse.
- Validation Exception–When the user overrides the recommended order quantity for rebalancing, PO, or transfers, the overridden value may exceed the available supply at the origin or may be more or less than the quantity required at the destination. In the validation exception section, the user can see these types of warnings and revert the override if desired.
Inventory Overview–Used to view the inventory levels and the historical trend of the inventory at the item-location level.
Forecast Overview–Used to view the demand forecast of the item-locations and the historical trend of sales across all customers as well as for each customer segment.

Figure 14-1 Inventory Optimization UI Workflow

Description of ''Figure 14-1 Inventory Optimization UI Workflow''

The following sections explain the main implementation tasks that involve configuring the following:

The roles and permissions assigned to users.
The loading of retailer data.
The configuration parameters.
The business rules that determine constraints that the application takes into account during the optimization process.

Security

User roles are used to set up application user accounts through Oracle Identity Management (OIM). See Oracle Retail AI Foundation Cloud Services Administration Guide for details. The following roles are required.

ADMINISTRATOR_JOB in order to access the Control & Tactical Center
INVENTORY_ANALYST_JOB in order to access the Inventory Optimization application.

In addition to above roles, verify the following:

Access to Innovation Workbench and/or Data Visualizer: This is necessary in order to query or visualize the data and verify that the data loaded matches the desired expectations.
Access to POM to execute ad-hoc and batch jobs: The POM UI URL is something like <host>/POMJetUI. If the user cannot access the POM UI, contact the administrator to obtain the relevant access/user roles.

Data Load Requirements

This section provides information about setting up the data that the IO application uses, including guidelines regarding the expectations for the data element requested and where it is used. Information about these files can be found in Oracle Retail Insights Cloud Service Suite/Oracle Retail Analytics and Planning Cloud Services Data Interface.

Most of the AI Foundation Cloud Services (AIF) data is pushed in two-step process. Any additional IO-specific data is directly pushed into the AIF.

First, data is loaded, using CSV and W_ interfaces, into Retail Insights Cloud Service (RI), using appropriate Retail Analytics & Planning (RAP) jobs. Then, RADM_REFRESH_JOB must be run to refresh the table statistics before any AIF job is run (though REFRESH_RADM_JOB is automatically executed as part of most ad hoc processes in RI).
Second, appropriate AIF jobs are used to push data into AIF. At the time of implementation, the user will only use ADHOC jobs, not any batch jobs. Batch jobs (described in "POM Jobs") are necessary to put the system on a batch schedule.
Third, IO-specific data (that is not available in RI interfaces) is directly pushed into the AIF.

Note that some of the jobs require relevant configuration parameters to be specified with client-specific values. If incorrect configuration values are used, a job may run without errors, but will not produce the desired data in the target tables. If the client or implementation team wants to view the progress of the job or any errors in order to file an SR, then AIF provides database logging in a table called RSE_LOG_MSG. Logging can be enabled only with a service request from the client/implementation partner to the support team.

RAP Foundation Data (CSV and W_ interfaces)

These interfaces provide the foundation data for the AI Foundation Cloud Services. First, the user must execute and verify that all the RAP foundation data has been loaded. For details, the RAP Implementation Guide can be accessed at:

https://docs.oracle.com/en/industries/retail/retail-analytics-platform/21.0/rapig/data-load-init-batchproc.htm#data-load-init-batch-proc-F30BF774

For Inventory Optimization, the following data is required:

Product Hierarchy. When Style, Style Color must be loaded, appropriate columns must be populated.
Location Hierarchy
Sales. It is recommended to load at least 24 months of historical data to obtain a good signal in the model training and a reliable parameter estimation for the demand forecasting.
Inventory. It is a critical data element for IO and for demand forecasting of fashion items that are considered short life cycle.
Inventory Receipts. This data is used to identify when the item started selling. This data must be provided for forecasting fashion items that are considered short life cycle.
Customer Segments. Even when the retailer is not planning to load or use customer segments, a dummy record is required. RI provides the ability to insert a dummy record, and it is not required for the client or implementer to provide these interfaces: W_PARTY_PER_DS and W_RTL_CUSTSEG_DS.
Price and Cost. This data is required for demand forecasting and for calculating some of the KPIs that are shown in IO screens.
Product Images. The URLs for rendering product images in IO screens can be provided.

Before pushing any data into the AIF, it is critical to make sure RAP foundation data is accurate and verified. Verification can be done through Data Visualizer or through the Innovation Workbench. Re-loading some of the RAP foundation data elements is non-trivial as it will require an SR to reset/truncate some of the target tables.

RSP Foundation Data (RSE_% Tables)

Once the interface configuration is complete and the RAP Foundation data has been verified, the user can push the data from RAP into AIF. As mentioned before, once database logging has been enabled, users can check for any errors and the progress of the process in RSE_LOG_MSG. Before running the RSE_MASTER_ADHOC with appropriate flags to execute the following jobs, the user must set the correct values for configuration parameters in RSE_CONFIG.

Inventory Optimization Data (IO_% Tables)

Once RSE_MASTER_ADHOC is successfully run, data can be loaded to IO tables by running the IO_MASTER_ADHOC.

Data Input Requirements

This section describes the data requirements.

Hierarchy Data

Hierarchies are part of the core data elements that are used in Inventory Optimization, in both the forecasting and optimization modules. The four types of hierarchies are Location Hierarchy, Merchandise Hierarchy, Calendar Hierarchy, and Customer Segments Hierarchy. Most of the W_% interfaces have numerous columns and thus, it is possible to define which columns will be populated in the interface by specifying the column headers (the order of columns does not have to be the same) in the corresponding W_%.ctx file.

Location Hierarchy

Here is an example of a location hierarchy: CHAIN ' COUNTRY ' REGION ' DISTRICT ' STORE. The run's scope level must match a node in the location hierarchy. For example, you can specify the run scope at the Area level and include one, multiple, or all areas in the run. Batch runs by default include all values of the scope level (for example, all areas). Note that the E-com channel can be defined as part of the location hierarchy. Relevant interfaces are: W_INT_ORG_ATTR_DS, W_INT_ORG_DHS, W_INT_ORG_DS.

Merchandise Hierarchy

An example of merchandise hierarchy is as follows: CHAIN 'COMPANY/BANNER 'DIVISION ' DEPARTMENT 'CLASS ' SUBCLASS ' STYLE 'COLOR ' SIZE (SKU). There can be up to nine levels in the merchandise hierarchy. When Inventory Optimization is used for fashion apparel, it is expected that Style and Color are provided through the relevant interfaces. The STYLE, COLOR and SIZE SKUs are expected to be provided in the W_PRODUCT_DS interface, while the levels between CHAIN and Subclass are provided via W_PROD_CAT_DHS interface. In addition, there must be consistency among the levels provided when using an extended hierarchy. W_PRODUCT_ATTR_DS is used to indicate the relationship between Style, Style/Color, and Style/Color/Size for an extended hierarchy. If the retailer wants to use an extended merchandise hierarchy, then the retailer must populate this interface. Here are the specific fields:

- PRODUCT_ATTR13_NAME = PROD_NUM for the Style (for example, 0000190086820900)

- PRODUCT_ATTR14_NAME = PROD_NUM for the Style/Color (for example, 190086834203)

- PRODUCT_ATTR15_NAME = PROD_NUM for the Style/Color/Size (for example, 1975699). The value of PROD_NUMs is the same as the value in the W_PRODUCT_DS.PROD_NUM interface.

Calendar Hierarchy

This is one of the core hierarchies. A retailer can specify the calendar depending on that retailer's business requirements (for example, fiscal calendar). The relevant interface for this is W_MCAL_PERIOD_DS.

Customer Segments Hierarchy

The AIF forecast engine in IO supports demand forecasting at the customer segment level. This is leveraged by the optimization algorithm to recommend customer-aware rebalancing transfers. To use this functionality, the retailer must load customer segments. The relevant interfaces to supply this data are: W_RTL_CUSTSEG_DS and W_RTL_CUST_CUSTSEG_DS.

Runs in IO can be set up to run at configured levels for location and merchandise.

Location Level. The location level of a run's scope is configurable in RSE_CONFIG, and it is denoted as IO_LOC_HIER_FILTER_LVL. For example, a typical level is Area.
Merchandise Level. The merchandise level of a run's scope is configurable in RSE_CONFIG, and it is denoted as IO_PROD_HIER_FILTER_LVL. For example, a typical level is Department.
Calendar Level. The calendar processing level is configurable in RSE_CONFIG, and it is denoted as IO_CAL_HIER_PROCESSING_LVL. For example, a typical level is Day.

Retail Sales Data

Retail Sales data is a required interface and is provided through W_RTL_SLS_TRX_IT_LC_DY_FS. IO requires the retailer's historical sales data at the SKU-Store-Day level. When the system is in production, the latest incremental sales data is obtained as part of the batch process.

Inventory Data

Historical inventory data is a required at two levels: the historical weekly inventory at sku-location level and the inventory at sku-location for the latest day. The latest weekly inventory data is obtained as part of the weekly batch process. The daily inventory data for the latest day is obtained through the daily batch process. In both interfaces, various components of inventory, including on-hand, on-order, back-order, and so on, are required. Historical weekly inventory data as well as daily inventory data can be specified through this interface: W_RTL_INV_IT_LC_DY_FS.

Product Attributes

Product attributes are not required for IO, but they are useful for the demand forecasting, and can be used for demand forecasting of new items. Product attributes must use W_RTL_ITEM_GRP1_DS since it can support any number of attributes.

If the retailer wishes to load STYLE or COLOR as product attributes, then the W_RTL_ITEM_GRP1_DS interface is used to provide style and color attributes for the different products, using a value in PROD_GRP_TYPE of either STYLE or COLOR. The actual values for the Styles and Colors are provided in columns FLEX_ATTRIB_2_CHAR and FLEX_ATTRIB_4_CHAR using values that represent the ID for the Style (for example, 1234), and a description for the Style (for example, Loose Fit). The columns FLEX_ATTRIB_3_CHAR and FLEX_ATTRIB_10_CHAR contain the appropriate designation for STYLE or COLOR.

Product Images

The Images URL can be provided through W_RTL_PRODUCT_IMAGE_DS.dat interface. This interface has a column called PRODUCT_IMAGE_ADDR that contains the full URL to an image of the product. This URL must be in the following format: http[s]://servername[:port]/location/filename.extension

For example:

PRODUCT_IMAGE_NAME = imagename.png
PRODUCT_IMAGE_ADDR = http://hostname/url/imagename.png
PRODUCT_IMAGE_DESC= Short description of the image

Replenishment Attributes

Replenishment attributes such as lead time, review time, presentation stock, and so on, are required for any sku-location that is expected to be processed by IO to generate an optimal replenishment policy. These attributes must be provided at sku-location level through W_INVENTORY_PRODUCT_ATTR_DS:

Price and Cost

Price and cost data at the end of the week for each item-location is required. This data can be loaded through RI. Alternatively, a retailer can directly load price and cost data to AIF using the W_RTL_PRICE_IT_LC_DY_FRI interface. Alternatively, a retailer can directly load price and cost data to AIF using the RSE_PRICOST_PR_LC_WK_STG interface.

Season

Data for the name of the season along with start and end dates can be provided through IO_SEASON_STG. If the retailer does not have any seasons, then the retailer can define one long season.

Global Configurations

Table 14-1 shows the configurations that must be provided at the time of implementation. These configurations can be modified in RSE_CONFIG table using the Manage System Configuration screen under Control & Tactical Center in the AIF dashboard.

Table 14-1 Global Configuration Parameters

APPL CODE	Parameter Name	Parameter Value	Description
RSE	EXTENDED_HIERARCHY_SRC	Default value is NON-RMS.	Data source providing extended hierarchy data RMS/NON-RMS.
RSE	LOAD_EXTENDED_PROD_HIER	Default value is Y. If the prod-uct hierarchy data had 9 levels, keep this value as Y. If it has 7 levels, change this value to N.	Y/N Value. This parameter is used by the product hierarchy ETL to know if the extended product hi-erarchy is needed.
PMO	PMO_PROD_HIER_TYPE	Default value is 3. If the prod-uct hierarchy data has 9 levels (i.e. it has extended hierar-chy), keep this value as 3. If it has 7 levels, change this value to 1.	The hierarchy id to use for the product (Installation configuration).
PMO	PMO_AGGR_INVENTORY_DATA_FLG	Default value is Y. Set this value to N if inventory data is not loaded (inventory data is not required for MFP forecasting but it is required for other applications like Offer Optimization, Inventory Optimization and Retail Demand Forecasting).	Specifies if inventory data is pre-sent and if it should be used when aggregating activities data.
RSE	PROD_HIER_SLSTXN_HIER_LEVEL_ID	Default value is 9.	This parameter identifies the hierarchy level at which sales transactions are provided (7-Style, 8-Style/color or 9 Style/color/Size). It MUST match the extended hierarchy leaf level.
IO	INV_REBALANCE_FLG	Y	Indicates whether inventory re-balancing analysis should be per-formed in batch runs. Also the inventory rebalancing section in the UI create run screen will be shown or hidden based on this flag. Must be Y or N.
IO	IO_CURRENT_DATE	A Dummy Date that represents the Current Date for the Inventory Optimization process.	This date is to be used for Dev/Test/Demo purposes because of our use of Historical Data. Date format YYYYMMDD. In production environment and for go live set this value to NULL.
IO	IO_PROD_HIER_TYPE	Default value is 3. If the product hierarchy data has 9 levels (i.e. it has extended hierarchy), keep this value as 3. If it has 7 levels, change this value to 1.	Hierarchy Type Identifier for the Product/Merchandise Hierarchy Type.
IO	IO_REBAL_DEF_REGION	usastates	Specifies the default region in the rebalancing details map view
IO	IO_LOC_HIER_FILTER_LVL	3	Level Identifier for the level of the Location Hierarchy at which IO runs can be set up.
IO	IO_PROD_HIER_FILTER_LVL	4	Level Identifier for the level of the Product Hierarchy at which IO runs can be set up.
IO	IO_ALLOCATION_BUFFER_DAYS	7	The number of days before selling start date that the initial shipment must be received. This is used for initial allocation recommendations.
IO	IO_AUTO_APPR_NEW_PARAMS	N	Indicates whether net new pa-rameters in a batch should be au-to-approved. Default to N (No).
IO	IO_AUTO_APPR_THRESHOLD_PCT	0.2	The threshold percentage change of Reorder Point (RP) and Receive Up To Limit (RUTL) between batches that is acceptable for au-to-approval of the parameters.
IO	IO_BATCH_RUN_INV_REBAL_FLG	N	Y/N flag that indicates whether inventory rebalancing analysis is performed as part of batch run.
IO	IO_BATCH_RUN_PO_TNSFR_RECOMM_FLG	Y	Y/N flag that indicates whether po transfer recommendation is performed as part of batch run.
IO	IO_BATCH_RUN_TIME_PHASED_FLG	Y	Y/N flag that indicates whether time phased simulation is performed as part of batch run.
IO	IO_BATCH_RUN_TRADEOFF_SIM_FLG	N	Y/N flag that indicates whether trade-off simulation is performed as part of batch run.
IO	IO_CAL_HIER_PROCESSING_LVL	4	Level Identifier for the level of the Calendar Hierarchy at which we process Inventory. Default 4 is to process at Week Level.
IO	IO_TIME_PHASED_HORIZON	14	Number of periods in the future for which the time phased plan is generated.

Inventory Optimization Integration with RMS

Figure 14-4 shows the conceptual diagram for the integration of IO with RMS. When a sku-store is set up in RMS for replenishment, if the optimization flag in RMS is set to Y, the optimal replenishment policies for that sku-store is sent back to RMS via Web Service integration.

Additional configuration parameters must be set to integrate IO with RMS. The configuration parameters that must be set for integration of replenishment policies and rebalancing transfers are listed in Table 14-2 and Table 14-3, respectively.

In addition, the RMS username and password must be added under the credential store for Merchandise RMS Access. You can modify these values using the UI screen for Data Management -> Manage Credential Store, as shown in Figure 14-2 and Figure 14-3. Data Management screen is available under the task menu in the main dashboard.

The replenishment policies and rebalancing transfers that are pushed to RMS can be viewed in io_repl_param_export_vw and io_rebalance_export_vw, respectively.

Table 14-2 Configuration Parameters for Integration of Replenishment Policies with RMS

Parameter Name	Parameter Value	Description
IO_MERCH_RMS_CONTEXT_ROOT	RmsReSTServices/services/private This value must be set based on the client environment.	Context root of the RMS Restservice url.
IO_MERCH_RMS_FLG	Y	Flag to identify whether to publish replenishment parameter to RMS.
IO_MERCH_RMS_HOSTNAME	msp00aay.us.oracle.com This value must be set based on the client environment.	URL host name to publish replenishment parameter to RMS. This must be same as CN name in the certificate.
IO_MERCH_RMS_PORT	8002 This value must be set based on the client environment.	Port number to publish replenishment parameter to RMS.
IO_MERCH_RMS_REPL_PATH	inventory/replenishment/createReplSched	Path of the Restservice e.g., inventory/replenishment/createReplSched.
IO_MERCH_RMS_VERSION	16.0 This value must be set based on the client environment.	RMS Version to use for publishing replenishment parameter to RMS (format 16.0).
IO_MERCH_RMS_AUTH_SERVICE_TYPE	OAUTH	Used in determining whether to use OAuth or basic authentication for IO RMS integration.

Table 14-3 Configuration Parameters for Integration of Rebalancing Transfers with RMS

Parameter Name	Parameter Value	Description
IO_REBAL_TRANSF_MERCH_RMS_FLG	Y	Flag to identify whether to publish rebalancing transfers to RMS.
IO_REBAL_TRANSF_MERCH_RMS_HOSTNAME	msp00aay.us.oracle.com This value must be set based on the client environment.	URL host name to publish rebalancing transfers to RMS. This must be same as CN name in the certificate.
IO_REBAL_TRANSF_RMS_PORT	443 This value must be set based on the client environment.	Port number to publish rebalancing transfers to RMS
IO_REBAL_TRANSF_RMS_SERVICE_VERSION	v1 This value must be set based on the client environment.	Transfer Management Service Version to use for publishing rebalancing transfers to RMS (format v1).
IO_TRAN_NUM_LOWER_LIMIT	9000000000	Lower range dedicated to the ID for store-to-store transfers that are generated in IO and sent to RMS.

Figure 14-2 and Figure 14-3 show adding a username and password for the credential store.

Figure 14-2 Selecting the Credential Store

Description of ''Figure 14-2 Selecting the Credential Store''

Figure 14-3 Adding the Username and Password for the Credential Store

Description of ''Figure 14-3 Adding the Username and Password for the Credential Store''

Figure 14-4 Inventory Optimization Integration with RMS

Description of ''Figure 14-4 Inventory Optimization Integration with RMS''

Forecast Engine Setup for IO

The forecast engine that generates demand forecast and feeds into the Inventory Optimization consists of two modules: parameter estimation and demand forecasting. Parameter estimation uses the historical data to determine the parameters, including seasonality, price elasticity, promotion elasticity, and promotion lift (or holiday lift) values. Demand forecasting leverages the parameters estimated from historical data and in-season sales data (the base demand is re-estimated on a regular basis as part of batch process) to determine the demand and generate the forecast.

To set up the parameter estimation and forecast runs and configure various settings, you can use the Manage Forecast Configurations functionality under Strategy & Policy Management. Based on the configuration settings, parameter estimation can be executed through the UI to initially estimate the parameters and then updated at specified intervals to reflect the latest sales trends. Similarly, a weekly batch job is used to generate demand forecasts every week after the weekly data has been updated.

For details regarding setting up run types and runs and configuring parameters, refer to the Control and Tactical Center chapter in the implementation guide.

Here are the points to take into consideration when setting up forecast runs types for inventory optimization.

Forecast level: data must be aggregated at the lowest level (Sku/store/week level) and the option for spreading the forecast to day level must be enabled when setting up the run type. If customer segment data is available and is desired to be used as additional dimension in the forecast, enable the option for customer segments.
Forecast method: if the items are fashion/short life cycle, select Causal-Short Life Cycle. If items are basic items which live for at least 16 weeks and often longer, select Causal-Long Life Cycle.
Forecast measure: select Total Gross Sales Units.
Spread Forecast to Day level: must be enabled.
Spread Profile Level: Spread profile can be provided through rse_fcst_spread_profile_stg.txt. If the spread profile is not available, leave the profile level selection empty. In such case, a default uniform profile will be applied for spreading forecast from week to day level.
Run the data aggregation in the Setup train stop.
Once the aggregation is complete, use Test train stop to create an ad-hoc run. Select Run estimation and base demand and enable Run forecast. Once the run is successfully complete, if desired, you can review the results using Innovation Workbench.
Use the Manage train stop to activate the run type and override the configurations for the run type if desired. In addition, turn on auto-approve batch runs.
Use Map train stop to map the run type to Inventory Optimization.
Make sure proper POM jobs (listed in Batch and Ad-Hoc Jobs for RDF Forecasting in the Control & Tactical Center chapter) are enabled so the forecast is generated via batch jobs.

Batch and Ad Hoc Jobs for IO

The following jobs with mentioned options must be executed to load required data for IO and forecast engine.

Table 14-4 Batch and Ad Hoc Jobs for IO

JobName	Description	RmsBatch	Parameters
RSE_MASTER_ADHOC_AIF_JOBThe batch job is	Run RSE master script	rse_master.ksh	You can run this with parameter '-A' which will run all data loads. You can also provide parameters to load certain data only. These parameters can be found in the AIF Operations Guide. The parameters that are relevant for IO are listed below this table.
IO_MASTER_ADHOC_AIF_JOB	Run IO master script	io_master.ksh	You can run this with parameter '-A' which will run all data loads. Alternatively, you can specify specific parameters to load certain data. List of parameters are listed below this table
IO_WAREHOUSE_LOAD_START_JOBIO_WAREHOUSE_LOAD_JOBIO_WAREHOUSE_LOAD_END_JOB	Load job for warehouses	io_warehouse_load.ksh
IO_SEASON_LOAD_START_JOBIO_SEASON_LOAD_STG_JOBIO_SEASON_LOAD_COPY_JOBIO_SEASON_LOAD_STG_CNE_JOBIO_SEASON_LOAD_JOBIO_SEASON_LOAD_END_JOB	Load job for seasons	io_season_load.ksh
RSE_RULES_TO_IO_LOAD_START_JOBRSE_RULES_TO_IO_LOAD_JOBRSE_RULES_TO_IO_LOAD_END_JOB	Job to load RSE rules to IO	rse_rul_eng_io_load.ksh
IO_CREATE_BATCH_RUN_ADHOC_JOB	IO batch run creation ad hoc job	io_create_batch_run.ksh
IO_RUN_ANALYTICS_ADHOC_JOB	IO analytics run ad hoc job	io_run_analytics.ksh
IO_PUBLISH_MERCH_RMS_START_JOBIO_PUBLISH_MERCH_RMS_JOBIO_PUBLISH_REBAL_RMS_JOBIO_PUBLISH_MERCH_RMS_END_JOB	Publish job for pushing replenishment param-eters and Rebalancing transfers to RMS	io_publish_merch_RMS.kshio_publish_rebal_transfer.ksh

Parameters for running RSE_MASTER_ADHOC_AIF_JOB

Table 14-5 Parameters for running RSE_MASTER_ADHOC_AIF_JOB

Data (-<parameter>)	Notes
RSE Product Hierarchy ETL (including CM Groups Hierarchy) (-p)
RSE Location Hierarchy ETL (-l)
Trade Area alternate hierarchy (-t)
RSE Calendar Hierarchy ETL (-d)
RSE Promotion Hierarchy ETL (-r)	Required if client has promotion data that they want to use in forecasting
RSE Customer Segment Hierarchy ETL (-g)
RSE Product Attributes (-P)
Location attributes (-L)
Like Location / Product data load (-K)	Required if client wants to use like location and/or like product in forecasting
Holiday load (-h)
Inventory data load (-i)
Sales transaction data (-x)
Weekly Aggregate Sales data (Load or Calc) (-w)
Aggregate Sales data processing (-a)
Price and Cost data load (-C)
UDA Load (-u)
Weekly Return transactions (-T)
Weekly Return Aggregation (-e)
Weekly Sales Return Price Consolidation (-S)
Promotion data load (-n)
Daily data load (-D)
Supplier, supplier item, daily supplier cost and supplier inventory management ETLs (-U)	w_party_org_d, w_party_attr_d, w_rtl_it_supplier_dsupplier inventory management is optional data for order scaling rules, which are sourced from w_rtl_repl_sup_mgmt_d
Seasons, phases and related items ETL (-N)
Load rules engine data to IO (-j)	Optional. It's needed for loading IO rules that are defined in Rules & Strategies into IO.
Buyer, allocation, purchase order and transfer ETLs (-H)	OptionalIf provided it can be used for value assessment to compare optimized history with actual history
load forecast spread profiles (-M)	Optional. Source: rse_fcst_spread_profile_stg.txtIt's needed for spreading week level forecast to day level. If not provided, a uniform profile will be applied.
Load life cycle classification data (-V)	Optional Source: rse_fcst_life_cycle_clsf_stg.txtThis allows user to classify product/locations as being short or long life cycle. By default, all prod-uct/location combinations are considered to have the life cycle classification which is indicated by DFLT_LIFE_CYCLE in RSE_CONFIG. Exceptions to DFLT_LIFE_CYCLE can be provided through rse_fcst_life_cycle_clsf_stg.txt and loaded by running this job. This information is forecast en-gine to apply the proper forecast method ac-cording to the life cycle of the item.

Parameters for running IO_MASTER_ADHOC_AIF_JOB

Table 14-6 Parameters for running IO_MASTER_ADHOC_AIF_JOB

Data (-<parameter>)	Notes
Warehouses (-W)	Source: w_int_org_attr_d
Replenishment Attributes at Product/Location or Group level (-a)	Source: w_inventory_product_attr_d
Seasons (-s)	Source: io_season_stg.txtData for the name of the season along with start and end dates can be provided through io_season_stg.txt. If the retailer does not have any seasons, then the retailer can define one long season.