Mirror of Oracle documentation

Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.

15 Inventory Planning Optimization

This chapter describes the Inventory Planning Optimization (IPO).

Overview

Inventory Planning Optimization (IPO) 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 purchase order (PO), transfer and allocations 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 leverages historical sales, inventory positions, replenishment attributes such as lead time and review schedule, business requirements such as 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 Runs

Types of Runs

IPO 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 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_TIME_PHASED_OPT_PO_TSF_FLG: Y/N flag to indicate whether the time phased optimization should generate the PO/Tsf recommendations. Default value is Y. (When the value is N, only the replenishment policies is generated.)

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. If the implementation scope is to generate replenishment policies only, set IO_TIME_PHASED_OPT_PO_TSF_FLG to N.

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.

Inventory Planning Optimization UI Workflow

The IPO UI workflow consists of the following:

• Manage recommendations:

  • Replenishment: Provides a calendar view of different recommendations and a separate view for each type of recommendations: Replenishment Policy, Rebalancing Transfers, PO and Transfers.

  • Allocation: Provides a view of initial and cross-dock allocations and details of each allocation.

  • Inventory Plan: Provides a time-phased view of different inventory plan metrics and alerts. Also, allows user to change strategy and perform what-if analysis.

• Overview:

  • Run Overview: Provides summary of inputs and outputs of batch and ad-hoc runs. 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.

• Create Run: User can create ad-hoc runs and specify the run scope and the strategy that will be used to determine the business rules for the run.

• Forecast Overview: Provides a view of forecast at SKU/location/customer segment level.

• Inventory Overview: provides a view of the stock levels and the historical trend of the inventory at the item-location level.

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 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 /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 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-specific data is directly pushed into the AIF.

1. 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).

2. 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 clientspecific 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, 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 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 rules). So, the inventory receipt is optional in IPO 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 IPOIO.

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 Data (IO_% Tables)

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

Data Input Requirements

This section provides information about setting up the data that the IPO 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, 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 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 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 skulocation 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, 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 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 15-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 15-1 Global Configuration Parameters

APPL CODE	Parameter Name	Parameter Value	Description
RSE	EXTENDED_HIERARCHY_S RC	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.

Table 15-1 (Cont.) Global Configuration Parameters

APPL CODE	Parameter Name	Parameter Value	Description
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_D ATA_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	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	.	This value will be automatically updated to latest daily inventory date by ETL process. It should not be modified manually.
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.

Table 15-1 (Cont.) Global Configuration Parameters

APPL CODE	Parameter Name	Parameter Value	Description
IO	IO_PROD_HIER_FILTER_LV L	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_PAR AMS	N	Indicates whether net new parameters in a batch should be auto-approved. Default to N (No).
IO	IO_BATCH_RUN_INV_REBA L_FLG	N	Y/N flag that indicates whether inventory rebalancing analysis is performed as part of batch run.
IO	IO_BATCH_RUN_PO_TNSF R_RECOMM_FLG	Y	Y/N flag that indicates whether PO transfer recommendation is performed as part of batch run.
IO	IO_BATCH_RUN_TIME_PHA SED_FLG	Y	Y/N flag that indicates whether time phased simulation is performed as part of batch run.
IO	IO_BATCH_RUN_TRADEOF F_SIM_FLG	N	Y/N flag that indicates whether trade-off simulation is performed as part of batch run.
IO	IO_CAL_HIER_PROCESSIN G_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_HORIZO N	14	Number of periods in the future for which the time phased plan is generated.

Table 15-1 (Cont.) Global Configuration Parameters

APPL CODE	Parameter Name Parameter Value	Description
IO	IO_ENABLE_NTIER_INTER FACE_FLG N	Indicates source of data to populate IO_REPL_ATTR_PROD_LOC _EXP (Y,N,X). Possible values are: Y (data loaded from RI interfaces for replenishment attributes and review schedule (typically coming from RMS). In addition, data loaded into IO_FINAL_RULE for each run from N-tier replenishment interfaces. The former always take precedence over the latter); N (data loaded into IO_REPL_ATTR_PROD_LOC _EXP and IO_FINAL_RULE solely from RI interfaces for replenishment attributes and review schedule); X (data loaded into IO_REPL_ATTR_PROD_LOC _EXP and IO_FINAL_RULE solely through N-tier interfaces). In all cases, any rule that is set up in Rules and Strategies will override the interfaced data.

IPO Integration 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 with RMS. The configuration parameters that must be set for integration of replenishment policies and rebalancing transfers are listed in Table 15-2 and Table 15-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 15-1 and Figure 15-2. 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 15-2 Configuration Parameters for Integration of Replenishment Policies with RMS

Parameter Name	Parameter Value	Description
IO_MERCH_RMS_CONTEXT_R OOT	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_SERVI CE_TYPE	OAUTH	Used in determining whether to use OAuth or basic authentication for IPO-IO RMS integration.

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

Parameter Name	Parameter Value	Description
IO_REBAL_TRANSF_MERCH_R MS_FLG	Y	Flag to identify whether to publish rebalancing transfers to RMS.
IO_REBAL_TRANSF_MERCH_R MS_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_POR T	443 This value must be set based on the client environment.	Port number to publish rebalancing transfers to RMS
IO_REBAL_TRANSF_RMS_SER VICE_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 15-1 and Figure 15-2 show adding a username and password for the credential store.

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.

• 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.

• 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

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

Table 15-4 Batch and Ad Hoc Jobs for IPO

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.

Table 15-4 (Cont.) Batch and Ad Hoc Jobs for IPO

JobName Description RmsBatch Parameters IO_MASTER_ADHOC_ Run IPO-IO master io_master.ksh You can run this with AIF_JOB script 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_LOA Load job for warehouses io_warehouse_load.ksh D_START_JOBIO_WAR EHOUSE_LOAD_JOBIO WAREHOUSE_LOAD END_JOB IO_SEASON_LOAD_ST Load job for seasons io_season_load.ksh ART_JOBIO_SEASON_ LOAD_STG_JOBIO_SE ASON_LOAD_COPY_J OBIO_SEASON_LOAD_ STG_CNE_JOBIO_SEA SON_LOAD_JOBIO_SE ASON_LOAD_END_JO B RSE_RULES_TO_IO_L Job to load RSE rules to rse_rul_eng_io_load.ksh OAD_START_JOBRSE_ IPO-IO RULES_TO_IO_LOAD_J OBRSE_RULES_TO_IO LOAD_END_JOB IO_CREATE_BATCH_R IPO-IO batch run io_create_batch_run.ksh UN_ADHOC_JOB creation ad hoc job IO_RUN_ANALYTICS_A IPO-IO analytics run ad io_run_analytics.ksh DHOC_JOB hoc job IO_PUBLISH_MERCH Publish job for pushing io_publish_merch_RMS. RMS_START_JOBIO_P replenishment paramkshio_publish_rebal_tran UBLISH_MERCH_RMS eters and Rebalancing sfer.ksh _JOBIO_PUBLISH_REB transfers to RMS AL_RMS_JOBIO_PUBLI SH_MERCH_RMS_END _JOB

Parameters for running RSE_MASTER_ADHOC_AIF_JOB

Table 15-5 Parameters for running RSE_MASTER_ADHOC_AIF_JOB

Data (-) 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)

Table 15-5 (Cont.) Parameters for running RSE_MASTER_ADHOC_AIF_JOB

Data (-)	Notes
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 product/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 engine to apply the proper forecast method ac-cording to the life cycle of the item.

Parameters for running IO_MASTER_ADHOC_AIF_JOB

Table 15-6 Parameters for running IO_MASTER_ADHOC_AIF_JOB

Data (-)	Notes
Replenishment Attributes at Product/Location or Group level (-a)	Source: w_inventory_product_attr_d
Supply chain for Distribution Networks (-C)	Source: REPL_DISTRO.csv. See the RAP Foundation Data section for more details
Review cycles (-S)	Source: REPL_REV_INT.csv. See the RAP Foundation Data section for more details.
Lead times (-L) )	Source: REPL_LT_INT.csv. See the RAP Foundation Data section for more details.
Supply chain for Procurement Networks (-P)	Source: REPL_PROC.csv. See the RAP Foundation Data section for more details.
Supplier Lead times (-T)	Source: REPL_LT_SUP.csv. See the RAP Foundation Data section for more details.
Internal Order Multiples (-M)	Source: REPL_MULT_INT.csv. See the RAP Foundation Data section for more details.
Supplier Order Multiples (-m)	Source: REPL_MULT_SUP.csv. See the RAP Foundation Data section for more details.
Rounding Levels (-l)	Source: REPL_ROUND.csv. See the RAP Foundation Data section for more details.
Load rules from IO table to rules engine (-I)	Source: IO_STRATEGY_RULE
Load N-tier interface data to rules engine (-N) )	Source: the 8 REPL_* interfaces. See the RAP Foundation Data section for more details.
Location Priority Groups (-G)	Source: io_loc_priority_grp_stg.txt

---

In this guide

• Guide: AI Foundation Implementation Guide
• Previous: 14 Control and Tactical Center
• Next: 16 Inventory Planning Optimization-Inventory Planning

Related chapters

• 13 LifeCycle Pricing Optimization — AI Foundation Implementation Guide · shares FLEX_ATTRIB_10_CHAR, FLEX_ATTRIB_2_CHAR, FLEX_ATTRIB_3_CHAR, FLEX_ATTRIB_4_CHAR
• 10 Size Profiles — AI Foundation Implementation Guide · shares DHOC_JOB, EXTENDED_HIERARCHY_SRC, LOAD_EXTENDED_PROD_HIER, PRODUCT_ATTR13_NAME
• 5 AI Foundation Data Standalone Process Flows — AI Foundation Operations Guide · shares REPL_DISTRO, REPL_LT_INT, REPL_LT_SUP, REPL_MULT_INT
• 2 AI Foundation Data Standalone Processes — AI Foundation Operations Guide · shares PROD_LOC_REPL, REPL_DISTRO, REPL_LT_INT, REPL_REV_INT
• 1 Inventory Planning Optimization — Inventory Planning Optimization User Guide · shares ADMINISTRATOR_JOB, INVENTORY_ANALYST_JOB
• 5 Dimensions and Attributes — Retail Insights Cloud Service User Guide · shares W_INT_ORG_ATTR_D, W_PARTY_PER_DS