12 Inventory Optimization

This chapter describes the Oracle Retail Inventory Optimization Cloud Service.

Overview

Inventory Optimization (IO) is used to understand the trade-offs between the service level and the inventory cost and to help retailers set strategies for the safety stock or the service level. These data-driven strategies are translated into item-location replenishment policies that are pushed to replenishment systems, such as Oracle Retail Merchandising System (RMS), Oracle Retail Advanced Inventory Planning (AIP), or any external system, to generate and execute orders. 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 generate the trade-off curves and calculate the optimal replenishment policies. (The embedded forecast engine in IO provides the demand forecast and the returns forecast. The forecast can also be provided by an external forecast system.) The demand forecast takes into account different factors such as demand transference, variation across customer segments, holidays and promotions, and returns (primarily for fashion and hardline categories).

The conceptual flow of different components in IO is as follows. ORASE/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 ORASE/RI. (See "Optional Interfaces.") The other key input to IO is the demand forecast, which is either generated and provided by the embedded forecast engine or provided by an external forecasting system.

The simulation and optimization 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, AIP, or any external system, 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. So 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 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 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 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 06/28/2020 would process and update the policies for item-locations that have a next review date of Monday 06/29/2020 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 12-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 type 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 needed at the destination. In the validation exception section, the user can see these kind 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 12-1 Inventory Optimization UI Workflow

Description of ''Figure 12-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 Advanced Science Cloud Services Administration Guide for details. The following roles are supported in this application:

• Inventory Analyst

Data Input 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 Advanced Science Cloud Services Data Interface.

Hierarchy Data

Hierarchies are part of the core data elements that are used in IO. The four types of hierarchies are Location Hierarchy, Merchandise Hierarchy, Calendar Hierarchy, and Customer Segments Hierarchy. Hierarchy data is required.

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.

Merchandise Hierarchy

Here is an example of a merchandise hierarchy: CHAIN ' COMPANY/BANNER 'DIVISION ' DEPARTMENT 'CLASS ' SUBCLASS ' STYLE ' COLOR ' SIZE (SKU). For some merchandise, the hierarchy might look different; for example, merchandise such as electronics does not necessarily have style or color.

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

Customer Segments Hierarchy

The embedded forecasting 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.

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

Retail Sales Data

A retailer's sales data is a required interface. IO requires the retailer's historical sales data at the SKU-Store-Day level.

Note that the sales returns are handled in the same interface. The returns data identifies the original location where the item was purchased and when it was purchased. This information is useful in returns analysis and in calculating the returns parameters that are used by the optimization algorithm in determining rebalancing recommendations.

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.

Product Attributes

Product attributes interfaces have two components. In the first, the interface expects that Style and Color are loaded as product attributes. W_PROD_ATTR_DS is used for image locations as well as supporting the extended hierarchy (that is, Style and Color). If the retailer wants to use extended merchandise hierarchy, then the retailer must populate these interfaces.

Product attributes such as brand and color can be provided through the second interface, W_RTL_ITEM_GRP1_DS.

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 can be provided at sku-location level through RI. Alternatively, attributes can be loaded at higher levels of merchandise and location, or at sku-location-group level, using the following interfaces in IO:

• IO_REPL_ATTR_PROD_LOC_GR_STG. This interface can be used to provide replenishment attributes at higher levels of merchandise and location hierarchies or at sku-store group level. For example, attributes can be provided at the subclass-region level.

• IO_REPL_ATTR_PROD_LOC_EXP_STG. This is an optional interface to provide exceptions for replenishment attributes at the sku-store level.

• IO_REPL_ATTR_PROD_WH_GR_STG. This interface can be used to provide replenishment attributes for warehouses at higher levels of merchandise hierarchy or at the sku-warehouse group level.

• IO_REPL_ATTR_PROD_WH_EXP_STG. This is an optional interface to provide exceptions for replenishment attributes at the sku-warehouse level.

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

Optional Interfaces

The interfaces specified in this section are optional if retailer chooses not to use additional features in IO (such as rebalancing transfers and warehouse-to-warehouse transfers).

Shipping costs and upcharges for store-to-store transfers (IO_SHIPPING_COST_STG). This is required data in order for IO to optimize and recommend rebalancing transfers (store-to-store transfers). For retailers who do not want do use this feature, this data is not required.

Non-receiving dates at location level (IO_NON_RCV_DATES_LOC_STG). This interface can be used to provide the dates at which a location (store or warehouse) does not accept deliveries (for example, certain local holidays).

Non-receiving dates at location type level (IO_NON_RCV_DATES_LOC_TYPE_STG). This interface can be used to provide the dates at which all locations of a certain type (that is, all stores or all warehouses) do not accept deliveries (for example, national holidays such as Christmas day).

Non-receiving days at the location level (IO_NON_RCV_DAYS_LOC_STG). This interface can be used to provide the days of week on which a location (stores or warehouses) does not accept deliveries.

Target split ratio at the warehouse level (IO_WH_SPLIT_TGT_STG). This interface can be used to provide the target split ratio between source warehouses for a given warehouse. This data is used when generating recommendations for warehouse-to-warehouse transfers. This data is required in order for IO to optimize and recommend warehouse-to-warehouse transfers. For retailers who do not want do use this feature, this data is optional.

Target split ratio at the product-warehouse level (IO_WH_SPLIT_TGT_EXCP_STG). This interface can be used to provide exceptions at the product level for the target split ratios that are provided in IO_WH_SPLIT_TGT_EXCP_STG. This is an optional interface to provide exceptions.

Original and current plan for inventory budget, This data is required for calculating the open-to-but cost that is estimated and presented in the UI for PO and transfer recommendations. This data can be provided through the RI interface (W_RTL_PLAN1_PROD1_LC1_T1_F).

Strategy rules (IO_STRATEGY_RULE_STG). Some of the strategy rules for replenishment and rebalancing can be defined in the UI. An illustration is the specification of the sku-locations that must be excluded from optimization (for example, slow moving items or items towards the end of their life cycle). There are additional strategy rules that can only be defined using the IO_STRATEGY_RULE interface. An example of such rules is the specification of products and/or locations that must be excluded from rebalancing transfers. Table 12-1 and Table 12-2 show all supported strategy rules and example of how to set them.When a rule is defined in the Create Run screen, it is effective for that run only. When the rules are defined using the interface, they will be effective for all batch runs until the rules are removed from the interface. For What-if runs, these rules are shown in the UI by default. The user can remove/edit them before submitting the run.

Table 12-1 Supported Strategy Rules

Rule Name	Description
IO_REPL_FLG	Y/N Indicator. Identifies if inventory should be replenished.
IO_REBAL_TO_LOC_FLG	Y/N Indicator. Identifies if rebalancing should be recommended TO certain locations or locations with certain attributes.
IO_REBAL_FROM_LOC_FLG	Y/N Indicator. Identifies if rebalancing should be recommended FROM certain locations or locations with certain attributes.
IO_REBAL_PROD_FLG	Y/N Indicator. Identifies if rebalancing should be recommended for certain products or products with certain attributes

Table 12-2 Strategy Rules Examples

EX. #	RULE_NAME	SEASON_NAME	PROD_EXT_KEY	PROD_HIER_LEVEL	LOC_EXT_KEY	LOC_HIER_LEVEL	RULE_VALUE	BUSINESS_OBJECT_1_MD_NAME	ATTR_1_SHORT_DB_NAME	ATTR_1_VALUE	BUSINESS_OBJECT_2_MD_NAME	ATTR_2_SHORT_DB_NAME	ATTR_2_VALUE
1	IO_REPL_FLG	Summer 2020	160	Dept	204	Area	N	PRODUCT	BRAND	Wonder	PRODUCT	COLOR	Basic Colors
2	IO_REBAL_TO_LOC_FLG	Summer 2020			2044	Region	N
3	IO_REBAL_FROM_LOC_FLG	Summer 2020	92297 95532	SKU	9990 1011	Location	N
4	IO_REBAL_PROD_FLG	Summer 2020	1824	Class			N

Example Details

Example 1: sku/stores that belong to Department 160 and Area 204 and have Brand 'Wonder' and Color 'Basic Colors' should not be included in the replenishment optimization process in the batch runs during Summer 2020.

Example 2: There should not be any recommendations for rebalancing transfers TO locations that are in Region 2044.

Example 3: There should not be any recommendations for rebalancing transfers for SKU 9229795532 FROM location 99901011.

Example 4: There should not be any recommendations for rebalancing transfers for products that belong to Class 1824, irrespective of origin and destination stores.

Global Configurations

Table 12-3 shows the configurations that must be provided at the time of implementation. These configurations can be modified in RSE_CONFIG table for APPL_CODE ='IO' through the Data Management screen in the ORASE dashboard.

Table 12-3 Global Configuration Parameters

Parameter Name	Parameter Value	Description
DEFAULT_APPL_USER	IO_BATCH_USR	User identifier to be used for batch activities that require user tracking
IO_CAL_HIER_TYPE	11	Hierarchy type identifier for the Calendar Hierarchy Type.
IO_CAL_HIER_PROCESSING_LVL	4	Level identifier for the level of the Calendar Hierarchy at which inventory is processed. Default value is 4 to process at the Week level.
IO_PROD_HIER_TYPE	3	Hierarchy type identifier for the Product/Merchandise Hierarchy Type.
IO_PROD_HIER_PROCESSING_LVL	9	Level identifier for the level of the Product Hierarchy at which process inventory is processed Default value is 9 to process at the SKU level.
IO_LOC_HIER_TYPE	2	Hierarchy Type identifier for the Location Hierarchy Type.
IO_LOC_HIER_PROCESSING_LVL	6	Level identifier for the level of the Location Hierarchy at which inventory is processed. Default value of 6 to process at the Store level.
IO_PROD_HIER_FILTER_LVL	4	Level identifier for the level of the Product Hierarchy that determines the run scope. IO runs are created and executed for one or multiple nodes at this level.
IO_LOC_HIER_FILTER_LVL	3	Level identifier for the level of the Location Hierarchy that determines the run scope. IO runs are created and executed for one or multiple nodes at this level.
IO_ALLOCATION_BUFFER_DAYS	7	The number of days before the selling start date that the initial shipment must be received.
IO_LIFE_CYCLE_THRESH_WEEKS	26	The number of weeks used as a threshold to determine whether a sku-store is considered seasonal and thus considered for initial warehouse to store allocation.
IO_NO_REPLEN_PERIOD	4	Initial no replenishment period (NRP): the number of weeks at the beginning of the season where the product should not be considered for replenishment.
IO_DESIRED_REPLEN_FREQ	3	Desired replenishment frequency (DRF): the average number of weeks between any two consecutive replenishments. Replenishment may happen more or less frequently.
IO_REVIEW_FREQ	1	Review Frequency or Review Time (RT): how often the sku/locations are reviewed for re-generating replenishment parameters and calculating order quantities. This will be same as the batch frequency.
IO_OPTIMIZATION_HORIZON	45	Number of days in the future for which store needs are calculated. Used for orders sourced from warehouses and suppliers with long lead times so that they can be estimated and planned in time.
LOC_FILTER_END_LEVEL_ID	6	Last location level ID whose corresponding filter appears in the location filter drop-down menus.
LOC_FILTER_START_LEVEL_ID	3	First location level ID whose corresponding filter appears in the location filter drop-down menus.
MERCH_FILTER_END_LEVEL_ID	9	Last merchandise level ID whose corresponding filter appears in the merchandise filter drop-downs menus.
MERCH_FILTER_START_LEVEL_ID	5	First merchandise level ID whose corresponding filter appears in the merchandise filter drop-down menus.
IO_RETURNS_ENABLED	Y	Allows application to show or hide return columns displayed in the UI based on whether or not returns are enabled.
IO_CUSTSEG_CHAIN	66	The customer segment associated with Chain.
REPL_ATTR_LOC_LVL_ID	5	Location level shown for replenishment attributes. This level should be in sync with the replenishment attributes level received by the customer.
REPL_ATTR_PROD_LVL_ID	6	Product level shown for replenishment attributes. This level should be in sync with the replenishment attributes level received by the customer.
DEFAULT_TGT_SRVC_VAL	0.8	Default target service level to be used if no target service level is provided for a given item/location by the customer.
DEFAULT_START_SRVC_LVL	90	Service level in percentage terms.Indicates the starting service level considered in the simulations for trade-off analysis.
REPL_INCRMT_SRVC_LVL	1	Increase the service level by this unit in the replenishment parameter calculation.
SIMULATION_ITERATIONS	10	Number of times the simulation is executed for calculating the replenishment parameters with random demand.
INV_REBALANCE_FLG	Y	Indicates whether inventory rebalancing analysis should be performed in batch runs. The inventory rebalancing section in the UI create run screen will be shown or hidden based on this flag. Must be Y or N.
NO_STORE_REBALANCE_PERIOD	4	The number of weeks at the beginning of the season where store balancing is not allowed.
MAX_TGT_SRVC_VAL	99	The Max Target Service level that must be considered in the replenishment parameter calculation.
IO_LOW_SELL_THRESHOLD	3	The number of inventory units sold per week below which an item is considered to be a low seller.
IO_PD_STD_DEV_THRESHOLD	0.1	Used in determining whether to use the Poisson distribution. Poisson distribution is used when the standard deviation of the aggregate forecast is within a certain threshold (IO_PD_STD_DEV_THRESHOLD) of the square root of aggregate forecast and the aggregate forecast is less than IO_LOW_SELL_THRESHOLD.Aggregate forecast is calculated for the period of lead time plus review time.
IO_REBAL_DEF_REGION	usastates	Specifies the default region in the rebalancing details map view.
IO_OTB_PROD_LVL	5	The merchandise hierarchy level at which IO calculates the PO cost considering W_RTL_PLAN1_PROD1_LC1_T1_F has these levels.
IO_OTB_LOC_LVL	4	The Location hierarchy level at which IO calculates the PO cost considering W_RTL_PLAN1_PROD1_LC1_T1_F has these levels.
IO_AUTO_APPR_THRESHOLD_PCT	0.2	The threshold percentage change of the Reorder Point (RP) and Receive Up To Limit (RUTL) between batches that is acceptable for auto-approval of the parameters.
IO_AUTO_APPR_NEW_PARAMS	N	Indicates whether or not net new parameters in a batch should be auto-approved. Default to N (No).

Inventory Optimization Integration with RMS

Figure 12-4 shows the conceptual diagram for the integration of IO with RMS. When a sku-store is set up in RMS for replenishment, it must be set to the Dynamic method if it is expected to be processed by IO for generating optimal replenishment policy. Once the replenishment attributes data is loaded into IO, the sku-stores that use the Dynamic replenishment method are flagged to be optimized based on their review schedule. Note that this flag is permanent and cannot be overwritten by subsequent feeds of replenishment attributes data. In order to exclude a sku-store from the optimization process in IO, the user must set the deactivate date accordingly in RMS. Alternatively, the sku-store can be assigned a no-replenishment rule using the IO_STRATEGY_RULE_STG interface.

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 12-4 and Table 12-5, 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 12-2 and Figure 12-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 12-4 Configuration Parameters for Integration of Replenishment Policies with RMS

Parameter Name	Parameter Value	Description
IO_MERCH_RMS_CONTEXT_ROOT	RmsReSTServices/services/private	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	URL host name to publish replenishment parameter to RMS. This should be same as CN name in the certificate.
IO_MERCH_RMS_PORT	8002	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	RMS Version to use for publishing replenishment parameter to RMS (format 16.0).

Table 12-5 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	URL host name to publish rebalancing transfers to RMS. This should be same as CN name in the certificate.
IO_REBAL_TRANSF_RMS_PORT	443	Port number to publish rebalancing transfers to RMS
IO_REBAL_TRANSF_RMS_SERVICE_VERSION	v1	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 12-2 and Figure 12-3 show adding a username and password for the credential store.

Figure 12-2 Selecting the Credential Store

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

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

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

Figure 12-4 Inventory Optimization Integration with RMS

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

FAQs

This section contains frequently asked questions and their answers.

General

Here are some answers to typical questions of a general nature.

What is the output of the IO replenishment policy optimization? Which methods are used to determine the optimal policies?

There are two outputs:

• The replenishment parameters (the reorder point and receive-upto-level) for each sku/store. In this release, IO supports the forecast-based method with self-tuning. This method assumes Normal demand distribution for high sellers and Poisson demand distribution for slow sellers. The proper distribution for each sku-store is determined based on the historical rate of sales and variations and the configurable thresholds. The replenishment parameters are initialized by calculating the safety stock using the formula of the Normal or Poisson distribution, and based on the demand forecast over the period of lead time, review time, and inventory selling days. After the system starts generating and applying the parameters, the self-tuning algorithm estimates the lost sales and average service level and calculates metrics such as the average OH inventory and the back-cast accuracy. Using this in-season information that is recalculated daily/weekly, the parameters are continuously tuned to ensure that the deviation from the target service level is minimized while keeping the inventory level as low as possible.

• Trade-off analysis of different replenishment policies. The output of this analysis is a trade-off curve that shows how the performance metrics (like average inventory cost and lost revenue) change for different policies (for example for different target service levels). This output shows the cost-revenue trade-off and helps user set strategies in terms of target service level (for each sku-store or at higher level, for example for each class-store).

Is it computing the final RP and RUTL or providing parameters to existing methods (for example, Dynamic, Time-supply)?

It is computing the final RP and RUTL.

Does IO consider expiring dates when taking decisions on moving-transferring stock?

It takes into account the deactivate date that is set in RMS, and it stops the replenishment process for the sku-store after that date. It also takes into account the end of the life cycle in the embedded forecasting, resulting in slower or no replenishment towards the end of the life cycle.

What does on-hand represent (for example, total or available)?

It refers to the available in stock quantity.

How are the re-balancing recommendations being optimized?

The re-balancing transfers are generated by optimizing one or a multiple of the following three objectives (based on user input):

• Minimize the total cost (the sum of the up-charges for a store-to-store transfer). Inventory is moved from supply stores to demand stores with the minimum cost possible.

• Maximize total unit sales. Stores that have a higher demand forecast for the remaining weeks of the life cycle are given a higher priority to receive demand from supply stores. This is achieved while keeping the shipping cost within a threshold (for example, ten percent) of the minimum shipping cost.

• Maximize unit sales for key customer segment. The key segment is identified based on the average price paid for the sku-parent (that is, Style). Stores that have a higher demand forecast for the remaining weeks of life cycle for the key segment are given a higher priority to receive demand from supply stores. This is achieved while keeping the shipping cost within a threshold (for example, ten percent) of the minimum shipping cost.

Optimizing the second and third objective may result in a much larger total cost. In order to control the total cost, the second and third objectives are optimized while keeping the total cost within a configurable threshold (for example, ten percent) of the minimum achievable cost.

Workflow

Here are some answers to typical questions about workflow.

How is the IO process initiated for a given item-location? How can they be easily excluded from the process (for example, slow-movers and/or intentionally on simple/constant replenishment)?

Once an item-location is set up for replenishment in RMS, the replenishment parameters data is sent to IO through RI. In order for a sku-store to be processed by IO, the replenishment method must be set to Dynamic. If the ACTIVATE_DATE and DEACTIVATE_DATE are null, the sku-store is processed by IO regardless of the date. If ACTIVATE_DATE and DEACTIVATE_DATE are provided, the sku-store is processed if the current date is between ACTIVATE_DATE and DEACTIVATE_DATE. To exclude a sku-store, the user can define a no-replenishment rule for the product/location (also by attributes) through the UI or the rules interface. Alternatively, the DEACTIVATE_DATE must be modified accordingly in RMS.

How does IO interact with RMS?

The steps are as follows:

Note: This process will work for RMS customers on the cloud and for on-premise customers on RMS v19.0. For on-premise customers with an earlier version of RMS, partners must perform customization to integrate with IO.

1. Customer sets up v for replenishment in RMS. To trigger the IO process, the replenishment method must be set to Dynamic. This signals to IO that the v must be processed by IO. Data for replenishment attributes such as lead time, presentation/demo stock, activate/deactivate date, and so on, flows into IO.

2. IO runs simulation and optimization to generate trade-off curves and recommended replenishment policies.

3. IO runs the auto-approval logic to auto-approve any replenishment policy that passes the criteria for auto-approval. Auto-approved policies are sent to RMS for execution (that is, generating transfers and purchase orders).

4. In the IO UI, the user can review and approve any replenishment policies that were not auto approved. After being approved by the user, they are sent to RMS for execution.

5. In the IO UI, the user can view the trade-off curves and change the replenishment strategy (service level) at the sku-store or the aggregate level. The changes will be taken into account by IO for future runs.

Forecasting

Here are some answers to typical questions about forecasting.

What forecast algorithms are available?

A combination of ML and causal forecast model for sales forecast and returns forecast are available.

Are casual forecasts considered?

Yes. Parameters for price elasticity, seasonality, events, and so on are estimated and applied to the base demand to generate the forecast. Base demand is updated weekly in-season based on the latest sales information. The parameters are estimated from historical data and are updated periodically. In case of external effects (such as social or weather), the parameters are expected to be provided by customer through an interface.

What future events are taken into consideration regarding forecast impacts?

Future promotions are taken into consideration. The promotions must be provided through an interface by the customer.Future price changes are taken into consideration, if they are provided through an interface by the customer. If the customer also buys and implements Offer Optimization, the optimal price changes will be generated by OO and fed into IO.Other inputs such as weather or social effects are taken into consideration, if the effects (that is, multipliers) are provided by the customer.

How is the RDF forecast incorporated into the process?

If a customer chooses to use the RDF forecast, the embedded forecasting will not be used. Instead, the RDF forecast flows into IO (through RI) and RDF forecast is used in all calculations. The returns forecast will still be done within IO and will be used to adjust the forecast received from RDF.