Inventory Planning Optimization-Inventory Optimization

14 Inventory Planning Optimization-Inventory Optimization

This chapter describes the Inventory Planning Optimization-Inventory Optimization (IPO-IO).

Overview

Inventory Planning Optimization-Inventory Optimization (IPO-IO) determines the optimal time-phased replenishment plan which consists of the replenishment policies, that is the reorder point (RP) and receive up-to level (RUTL), and the recommended order quantity for PO and transfers at item/location/day level for the configurable planning horizon. The optimal plan is generated using simulation and optimization methods and considers inputs like supply chain network, replenishment attributes and business rules. Moreover, the optimization engine uses machine learning methods and simulation-based optimization to calculate the trade-offs between the service level and the inventory cost for different replenishment policies. The trade-off analysis is leveraged to generate the optimal replenishment policies for achieving a desired target service level. In addition to the replenishment plan, IPO-IO recommends optimal rebalancing transfers between stores to increase sell-through and to avoid markdowns. This type of recommendation can be turned off when not applicable (for example, for grocery categories).

The data-driven replenishment policies, PO/transfers, and rebalancing transfers are pushed to Oracle Retail Merchandising System (RMS) to execute purchase orders and transfers. Optionally, the retailer can choose to send only the replenishment policies to RMS and have the final order quantity and PO/transfers be calculated and generated in RMS.

IPO-IO leverages historical sales, inventory positions, replenishment attributes such as lead time and review schedule, business requirements such store priorities for shortfall reconciliation, and the demand forecast to generate the optimal time-phased replenishment plan. 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.

Inventory Planning Optimization-Inventory Optimization Runs

Types of Runs

IPO-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). By default, the batch runs are scheduled for daily execution. 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. IPO-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 will generate one or multiple type of recommendations depending on the type of analysis that are selected when creating the run from UI. For batch runs, the type of analysis is controlled by the following configurations in RSE_CONFIG.

IO_BATCH_RUN_TIME_PHASED_FLG: Y/N flag that indicates whether time phased simulation is performed as part of batch run. The default value is Y.

IO_BATCH_RUN_INV_REBAL_FLG: Y/N flag that indicates whether inventory rebalancing analysis is performed as part of batch run. The default value is N.

IO_BATCH_RUN_TRADEOFF_SIM_FLG: Y/N flag that indicates whether trade-off simulation is performed as part of batch run. The default value is N.

Time-Phased Planning

Time-phased planning is the main type of analysis that must run as part of the batch, so the replenishment policies and PO/transfers are generated daily. 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. For example, a run that is scheduled for a nightly batch on Sunday 01/08/2024 would generate optimal replenishment plan for item-locations that have a next review date of Monday 01/09/2024 in the retailer's replenishment system. This allows the end user to review and approve the policies and/or PO/transfers that were not auto-approved on Monday before they are pushed to the replenishment system for generating and executing orders.

Inventory Rebalancing

Inventory rebalancing can be enabled in as part of the batch if it’s relevant (for example for fashion retailers) and if there is a need to generate rebalancing recommendations daily. Alternatively, the rebalancing runs can be done as-hoc from UI when needed.

Trade-Off Analysis

The trade-off analysis is not a kind of process that needs to be run daily because the changes in sales patterns, replenishment rules and supply chain network are not that frequent. Therefore, the optimal trade-off curves are typically recommended to be updated quarterly or when there is a major change in one of the factors mentioned above.

Note:

It is strongly recommended not to enable the trade-off analysis for the batch runs. This can make the batch runtime long since the trade-off analysis performs extensive data processing and large-scale simulation.

Review/Approve Recommendations

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 Planning Optimization-Inventory Optimization UI Workflow

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

Run Overview: This is the dashboard for the IPO-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 IPO-IO UI Workflow

Description of "Figure 14-1 IPO-IO 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 IPO-IO 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 IPO-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 IPO-IO-specific data is directly pushed into the AIF.

First, data is loaded, using CSV and W_ interfaces and jobs in the AIF DATA standalone schedule in POM.Then, RADM_REFRESH_JOB must be run to refresh the table statistics before any AIFApps job is run (though REFRESH_RADM_JOB is automatically executed as part of most ad hoc processes in AIF Data).
Second, appropriate AIF applications jobs are used to push data into AIF applications. 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.

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. In addition, analytic logs generated by the programs that run optimization can be found in RSE_ANALYTIC_LOG_MSG. More details are provided in the Troubleshooting section in this chapter.

RAP Foundation Data

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 IPO-IO, the following data is required:

Product Hierarchy (PRODUCT.csv). When Style, Style Color must be loaded, appropriate columns must be populated.
Location Hierarchy (ORGANIZATION.csv)
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. (INVENTORY.csv). For the time-phased planning, it is sufficient to have the latest inventory position (i.e., quantity of on-hand, on-order, in-transit, etc. for the latest day). For trade-off analysis, it is recommended to provide historical inventory which will be used for lost sales correction before performing simulation. If not provided, the trade-off analysis will be performed on the sales time series. While this is not ideal, for most categories the final trade-off curves are not too sensitive to the lost sales correction when the KPIs are measured at aggregate level.
Inventory Receipts. (RECEIPT.csv). This data is used to identifyt he first and last receipt at item/location level. It is used by IPO-IO to update the life cycle start date, which is being used to determine the life stage of the item/location based on the life cycle rules (for more details please refer to the Rules & Strategies chapter and the IPO-IO rules). So, the inventory receipt is optional in IPO-IO depending on what kind of rules are being set up and used. From forecasting standpoint, the inventory receipt 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. The AIF ad hoc jobs will create a dummy record when the source data is not provided, and it is not required for the client or implementer to provide these interfaces if they are not going to use them: W_PARTY_PER_DS and W_RTL_CUSTSEG_DS.
Price and Cost (PRICE.csv). This data is required for calculating some of the KPIs that are shown in IPO-IO screens. Moreover, price data must be provided for forecasting fashion items that are considered short life cycle.
Product Images. The URLs for rendering product images in IPO-IO screens can be provided.
Promotions (PROMOTION.csv). This is an optional data for IPO-IO. It is used in showing the promotion flag at item/location/day level in some of the UI charts. Moreover, promotions must be provided for forecasting fashion items that are considered short life cycle; otherwise, the forecast will not reflect the promotion effects and will be inaccurate.
Replenishment attributes (PROD_LOC_REPL.csv). This data is required for all type of runs and analysis in IPO-IO. The required attributes include but not limited to primary supplier/warehouse source, lead time and replenishment method. For more details, please refer to the RAP interface guide.
Review schedule (W_RTL_REPL_DAY_DS.dat). This data is required for all type of runs and analysis in IPO-IO.
Supplier (SUPPLIER.CSV). This data is required for all type of runs and analysis in IPO-IO.

The following data is optional and can be provided depending on the business use cases.

Distribution networks (REPL_DISTRO.csv)
Internal review cycles (REPL_REV_INT.csv)
Supplier review cycles (REPL_REV_SUP.csv)
Internal lead times (REPL_LT_INT.csv)
Supplier lead times (REPL_LT_SUP.csv)
Procurement networks (REPL_PROC.csv)
Internal order multiples (REPL_MULT_INT.csv)
Supplier order multiples (REPL_MULT_SUP.csv)
Rounding levels (REPL_ROUND.csv)
Scaling rules (W_RTL_REPL_SUP_DIM_DS.dat)

For example, if there is a need to define time-dimensioned replenishment attributes (e.g. longer lead time during holidays and shorter lead time at other times of the year), it will have to be provided using the REPL_LT_INT.csv and REPL_LT_SUP.csv. Another example is defining a warehouse-to-warehouse relationship in the supply chain network. For customers who use RMS, it will not be possible to have a source warehouse defined for a warehouse location. If there is a need to define such a link in the supply chain network, it will have to be provided using REPL_DISTRO.csv.

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. This can be done using Manage System Configurations (as described in Control and Tactical Center) and then selecting RSE_CONFIG from the drop-down list.

Inventory Planning Optimization-Inventory Optimization Data (IO_% Tables)

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

Data Input Requirements

This section provides information about setting up the data that the IPO-IO application uses, including guidelines on 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.

Hierarchy Data

Hierarchies are part of the core data elements that are used in IPO-IO, 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 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 file, such as PRODUCT.csv.

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_D, W_INT_ORG_DH, W_INT_ORG_D. These are all loaded using the ORGANIZATION.csv file.

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 IPO-IO is used for fashion apparel, it is expected that Style and Color be provided through the relevant interfaces.

The STYLE, COLOR and SIZE SKUs are expected to be provided in the W_PRODUCT_D interface, while the levels between CHAIN and Subclass are provided via W_PROD_CAT_DH interface. In addition, there must be consistency among the levels provided when using an extended hierarchy. W_PRODUCT_ATTR_D, is used to indicate the relationship between Style, Style/Color, and Style/Color/Size for an extended hierarchy. All of these tables will be populated when providing a PRODUCT.csv file as a foundation file input. 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_D, loaded using CALENDAR.csv file.

Customer Segments Hierarchy

The AIF forecast engine in IPO-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 IPO-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.

Retail Sales Data

Retail Sales data is a required interface and is provided through SALES.csv file (W_RTL_SLS_TRX_IT_LC_DY_FS staging table). IPO-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 INVENTORY.csv (staging table W_RTL_INV_IT_LC_DY_FS).

Product Attributes

Product attributes are not required for IPO-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 IPO-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 with the PRICE.csv file through AIF Data jobs into the data warehouse, which places the data in the W_RTL_PRICE_IT_LC_DY table for AIF applications to consume. 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 Apps using the RSE_PRICOST_PR_LC_WK_STG interface, which uses the rse_pricost_pr_lc_wk_stg.txt interface file..

Season

Data for the name of the season along with start and end dates can be provided through IO_SEASON_STG table (which is directly loaded to AIF applicationss) or SEASON.csv (which flows through the AIF data warehouse along with other foundation files). If the retailer does not have any seasons, then the retailer can define one long season that encompasses their entire calendar.

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 hierarchy is needed.
PMO	PMO_PROD_HIER_TYPE	Default value is 3. If the product 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 Lifecycle Pricing Optimization, Inventory Planning Optimization-Inventory Optimization and IPO-Demand Forecasting).	Specifies if inventory data is present 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 rebalancing 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 Planning Optimization-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 IPO-IO runs can be set up.
IO	IO_PROD_HIER_FILTER_LVL	4	Level Identifier for the level of the Product Hierarchy at which IPO-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 parameters in a batch should be auto-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 auto-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.

IPO-IO Integration with RMS

Figure 14-4 shows the conceptual diagram for the integration of IPO-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 IPO-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 IPO-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 IPO-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 IPO-IO Integration with RMS

Description of "Figure 14-4 IPO-IO Integration with RMS"

Forecast Engine Setup for IPO-IO

The forecast engine that generates demand forecast and feeds into the IPO-IO 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 IPO-IO.

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 IPO-IO.
Make sure proper POM jobs (listed in Batch and Ad-Hoc Jobs for IPO-DF Forecasting in the Control & Tactical Center chapter) are enabled so the forecast is generated via batch jobs.

Batch and Ad Hoc Jobs for IPO-IO

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

Table 14-4 Batch and Ad Hoc Jobs for IPO-IO

JobName	Description	RmsBatch	Parameters
RSE_MASTER_ADHOC_AIF_JOB The 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 IPO-IO are listed below this table.
IO_MASTER_ADHOC_AIF_JOB	Run IPO-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 IPO-IO	rse_rul_eng_io_load.ksh
IO_CREATE_BATCH_RUN_ADHOC_JOB	IPO-IO batch run creation ad hoc job	io_create_batch_run.ksh
IO_RUN_ANALYTICS_ADHOC_JOB	IPO-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 IPO-IO (-j)	Optional. It's needed for loading IPO-IO rules that are defined in Rules & Strategies into IPO-IO.
Buyer, allocation, purchase order and transfer ETLs (-H)	Optional If 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.