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.

13 LifeCycle Pricing Optimization

This chapter describes the Lifecycle Pricing Optimization (LPO).

Overview

LPO is used to determine the optimal pricing recommendations for promotions, markdowns or targeted offers. Promotions and markdowns are at the location level or a price zone. Targeted Offers can be specific to each customer and not just to a location. Pricing recommendations contain answers to the following questions: Which items? When (timing)? and How deep and Who (segments)? It caters to the retailers who are interested in only promotions and markdowns as well as targeted offers that are specific to each customer segment. In order to use targeted offers, the retailer must provide customer-linked sales transactions data; to use promotions and markdowns, the retailer does not necessarily have to provide customer-linked sales transaction data.

Certain aspects of promotions, markdowns, and targeted offers are important levers for managing the inventory over the life cycle of the product. The application helps in the following:

Bring inventory to the desired level, not just during the full-price selling period.
Maximize the total gross margin amount over the entire product life cycle.
Assess in-season performance.
Provide updated recommendations each week. This facilitates decision-making that is based on recent data, including new sales, inventory, price levels, planned promotions, and other relevant data.
Provide targeted price recommendations at the segment-level.

Figure 13-1 shows the conceptual flow of different components in LPO. Oracle Retail AI Foundation Cloud Service and Retail Insights Cloud Service is the core data foundation layer that consumes the retailer data. The forecasting analyzes and mines historical data (along with other data sources) using machine learning algorithms for developing a predictive model to provide the forecasting inputs to the Optimization Algorithm. The Optimization Algorithm obtains inputs such as objectives, budgets, and business rules from the UI, along with optimization parameters from AIF and the data warehouse. The algorithm analyzes the feasible price paths efficiently and generates price recommendations. These recommendations can be viewed in the LPO UI or can be exported to the price execution systems such as Price Management (PM) or Customer Engagement (CE). In addition, a feedback loop from the price execution systems can help the Forecasting component to determine how the offers are performing and adjust the next set of offers based on the sales performance or the response rate. LPO supports two kinds of runs, called “ad hoc runs” and “batch runs.” Batch runs are scheduled to run automatically at regular intervals (for example, every week). Each batch run, using latest sales data and inventory levels, updates the parameters and budgets and produces the price recommendations. An analyst can review the results and further accept, reject, or override the price recommendations for each item. Once the analyst finishes the review, the item’s recommendation status can be changed to Reviewed. A reviewed recommendation is sent to the buyer for approval. If the user with the buyer role likes the recommendations, that user can submit or approve the recommendation. At this point, the recommendation status is changed to Submitted or Approved. This indicates that the price

configures the application so that the batch runs complete successfully in a timely fashion and produce valid promotions, markdowns, and forecast recommendations that meet the retailer’s requirements. The main implementation tasks involve configuring the following:

The roles and permissions assigned to users.
The loading of retailer data.
The configuration parameters.
The demand parameters, such as seasonality and price effects, that are used to determine optimal promotion, markdown, and targeted recommendations.
The business rules that determine constraints that the application takes into account during the optimization process.

Project Planning

This section provides a high-level project planning for implementation by different buckets: functional, data interfaces, forecasting and optimization.

Functional

Understand the existing business requirements for pricing; and proposed process changes with LPO.
Verify the functionality that the customer would like to leverage from LPO and identify whether the customer can provide the necessary data.
Review and identify the business rules (and strategy sets) with the customer.
Identify the desired flex facts that the customer would like to see in the Manage Recommendation Screen.
Identify the desired reports for the customer.
Log and revisit any open requirements.
Users and user roles, data security/filtering.

Data Interfaces

Overview. Confirm the list of LPO interfaces to be loaded for the customer
Foundational Data. Decide on the business date and load the Calendar data. Plan for partitions.
Foundational Data. Decide on the merchandise and location hierarchy levels; map it to the levels in the LPO hierarchies.
Foundation Data. Identify the fields in each interface and identify or map to a source in the customer’s systems
Foundational Data. Convert history for sales transactions
Foundational Data. Convert history for inventory positions.
Foundational Data. Convert other positional data (costs, prices)
Foundational Data. Decide on whether to use Price Zones and load the price zone data.
Validation. Load a small sample of data (for example,1 month) to verify data is flowing in correctly. Use Innovation Workbench or Data Visualizer for verifications.
Full historical load. Plan for full load of history.
LPO Interfaces.

Forecasting Parameters

Setup. Create a forecast run type and relevant levels for forecast or recommendations
Setup. Create a forecast run(s) with as many configurations as needed.
Data Aggregation. Verify that the data aggregation is completed.
Parameters. Review the forecasting parameters.
Validation. Assess the forecast quality of the parameters and iterate on forecast runs as needed. Prepare comparison reports using Data Visualizer.

Optimization

Setup. Configure all the relevant parameters (for example, warehouse virtual allocation algorithm).
Setup. Verify the business rules and strategies.
Ad hoc run. Optimize an ad hoc run for optimization for selected merchandise or locations.
Validation. Review the recommendations and for the quality of the business rules and forecast parameters. Revisit the business rules and forecasting as necessary.
Ad hoc batch job. Execute an ad hoc batch job to verify the runs are executed successfully for all merchandise/locations.

Walkthrough

Most of the AIF Applications foundation data is pushed in two-step process. Any additional LPO-specific data is directly pushed into the AIF Apps tables.First, data is loaded using CSV and W_ interfaces via AIF DATA schedule in POM . Then, RADM_REFRESH_JOB must be run to refresh the table stats before any AIF job is run. Second, appropriate AIF jobs are used to push data into AIF application tables. At the time of implementation, the user will only use ADHOC jobs, not any batch jobs. Batch jobs (described in “POM Jobs”) are necessary to put the system on a batch schedule. Third, LPO-specific data (that is not available in AIF DATA interfaces) is directly pushed into the AIF applications.

The following sections assumes that the user has obtained access to POM. The POM UI URL is something like this: /POMJetUI. If the user cannot access the POM UI, contact the administrator to obtain the relevant access/user roles. In addition, the user must have access to Innovation Workbench and/or Data Visualizer in order to query or visualize the data in order to verify that the data loaded matches the desired expectations.

Another point to note is 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 applications provide database logging in a table called RSE_LOG_MSG. Logging can be enabled only with a service request from the client/implementation partner to the support team.

Although this walk-through provides all the necessary steps, the user may want to refer to the relevant section in this guide for more details (for example, the specific fields in an interface).

RAP foundation data (CSV and W_ interfaces)

These interfaces provide the foundation data for the AI Foundation. Execute and verify that all the RAP foundation data has been loaded. For details, refer to the Retail Analytics and Planning Implementation Guide.

For LPO, this includes:

1. Product Hierarchy . When Style, Style Color must be loaded, appropriate columns must be populated.

2. Location Hierarchy .

3. Price Zone Groups and Price Zones . It is not required to provide price zones for LPO, but if the user intends to do pricing by price zones, then these files are required. Price Zones are clusters of stores and Price Zone Groups allow the user to map a merchandise node or set of items to a Price Zone Group.

4. Sales . It is best to load at least 20 months of the data to obtain a good signal in the model training.

5. Inventory . It is a critical data element for LPO, for, without inventory, the LPO runs would fail.

6. Inventory Receipts . This data is used to identify when the item started selling. This data must be provided for LPO.

7. 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 interface if they are not going to use them: W_PARTY_PER_DS and W_RTL_CUSTSEG_DS.

8. Price and Cost . This data must contain the price and cost for every product and location combination that had a sale in the sales history. At least a record must be provided for TRAN_TYPE 0 for every product and location combination so that LPO can correctly identify the ticket price, the original price for the item, and the location. Note that this is the minimum required for this data. However, it is highly recommended that the entire price history for that item and location be provided. Otherwise, LPO will incorrectly capture the ticket price changes or regular price changes. It is understandable that some items from the beginning of the sales history will not have the entire price history.

9. Security . RAF files must be provided when the user wants to impose security or data filters for the LPO screens based on the merchandise and location nodes. The Manage LPO Recommendation user filter will not show any location or merchandise nodes that are not allowed for a particular user.

10. Product Images . The URLs for rendering product images in LPO screens can be provided.

11. Pricing Groups . If the user defines pricing groups such as Same Markdown Discount and so on, then they must be provided here for the batch LPO runs to pick up.

12. Flex Facts (or Custom Columns) . If the user wants to see custom columns in Manage LPO Recommendation, then these interfaces must be provided.

13. Before pushing any data into the AIF application, 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 the RAP foundation data elements is non-trivial and becomes more difficult if you distribute that data from the input data warehouse tables to other downstream systems before validating it.

AIF applications 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 applications. 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 dropdown list.

1. Product Hierarchy . The target table to check is RSE_PROD_HIER. When the user wants to load up to 9-level hierarchy (for example, fashion items with SBC ’ STYLE ’ STYLE/ COLOR ’ STYLE/COLOR/SIZE), then two configurations must be verified: LOAD_EXTENDED_PROD_HIER and PROD_ITEMUDA_SRC.

2. Location Hierarchy . The target table to check is RSE_LOC_HIER.

3. Price Zone Groups and Price Zones . The target tables to check are RSE_PRICE_ZONE, RSE_PRICE_ZONE_GRP, RSE_PRICE_ZONE_LOC, and RSE_PRICE_ZONE_PROD. The user must set the correct configuration level for the merchandise level that is mapped to a PRICE_ZONE_GROUP using this configuration in RSE_CONFIG: RSE_PZG_PROD_LEVEL.

4. Sales . The target table to check is RSE_SLS_TXN. This data will be further aggregated into multiple tables at different aggregate levels once the relevant aggregation jobs are executed. For LPO, this table must be populated: RSE_SLS_PR_LC_CS_WK. Returns aggregation will not be required if the user does not plan on using the returns functionality.

5. Inventory . The target table to check for weekly inventory position at leaf node levels is RSE_INV_PR_LC_WK_A. Note that the warehouse inventory positions are also loaded into this target table as warehouse is treated like a leaf node on the location hierarchy. The configurations in RSE_CONFIG to check are INV_SRC_RI, RSE_INV_QTY_BOH_FLG, RSE_INV_QTY_IN_TRANSIT_FLG, RSE_INV_QTY_ON_ORD_FLG, RSE_WHSE_INV_QTY_BOH_FLG, RSE_WHSE_INV_QTY_IN_TRANSIT_FLG, and RSE_WHSE_INV_QTY_ON_ORD_FLG.

6. Inventory Receipts . The target table to check for inventory receipts at the leaf node level is RSE_INV_HIST_PR_LC_WK. The configuration to check is INV_RC_DT_SRC_RI.

7. Customer Segments . The target table to check is RSE_CUSTSEG_HIER. It is required to execute the job to load customer segments (even when there is just a dummy segment).

8. Price and Cost . Before pushing the price cost data into AIF applications, the user must make sure that the weekly sales aggregation job has been executed and that the customer segments have been executed. The target table to check at leaf node levels is: RSE_PRICOST_PR_LC_WK.

9. Security . Target tables to check are RAF_FILTER_GROUP_MERCH, RAF_FILTER_GROUP_ORG, RAF_SEC_GROUP, RAF_SEC_USER, and RAF_SEC_USER_GROUP.

Direct loads to AIF applications

Some foundation data elements are loaded directly to AIF applications. Here is a description of some of the data elements that are used in LPO.

These files must be prepared into ORASE_WEEKLY_ADHOC.zip.

1. Prepare the relevant _stg.txt file. (Note that some large files will be compressed into _stg.txt.gz files.)

2. Zip all the staging files into an archive named ORASE_WEEKLY_ADHOC.zip.

3. Upload ORASE_WEEKLY_ADHOC.zip to Object Storage using the File Transfer Service (FTS).

Then run the RSE_MASTER_ADHOC with the appropriate parameter. See: https:// docs.oracle.com/en/industries/retail/retail-insights-cloud/21.0/rapog/mstr-dat-load-commondsgn-ovrvw.htm

1. Holidays . The target table to check is RSE_HOLIDAY. This is a direct load to AIF applications and is loaded through RSE_HOLIDAY_STG. Any validation errors during loading are provided in the RSE_HOLIDAY_BAD table. As mentioned before, the bad tables can be viewed using Innovation Workbench.

2. Warehouse Allocation Percentages . RSE_INV_WHSE_LC_PR_ALLOC_STG. The target table to check is RSE_INV_WHSE_LC_PR_ALLOC. This is a direct load to AIF applications. The configuration to check is RSE_PRO_WHSE_ALLOC_FLG, which must be set to N when the client is loading allocation percentages.

3. Product Attributes . Product attributes are not required for LPO; however, if the user wants to use them in the Manage OO Recommendation screen, then they must be provided directly to AIF applications. The target tables to check are RSE_PROD_ATTR_GRP_VALUE and RSE_PROD_ATTR_VALUE_XREF.

Forecasting

The next step is to create a forecast run type and run the model training to estimate the demand parameters. These steps are important to determine the appropriate aggregation levels for the next bucket, Optimization.

1. Create the forecast run type at the desired recommendation levels for the offers. For example, the recommendation levels can be STYLE COLOR, PRICE ZONE, and WEEK. Once the correct run type has been created, then user can click Start Data Aggregation . The configurations to check are RSE_INV_WHSE_ACTIVITY_USE_FLG (this flag must be set to N as otherwise the aggregation time would increase dramatically. The user can turn this flag on when the batches have started), PMO_PROD_HIER_TYPE (for example, this would be 3 for using extended hierarchy), and PMO_AGGR_INVENTORY_DATA_FLG. The target tables to check are PMO_ACTIVITIES and PMO_CUM_SLS.

2. Create the forecast run corresponding to the forecast run type and change the settings as needed. The user can select Submit , which will start training the model.

3. Once the forecast run is complete, the parameters are generated. If the user is satisfied with the parameters, then the user must Approve Demand Parameters, Approve Base Demand and Forecast. Then the user must activate the forecast run type and map it to the application. (In this case, it is LPO.)

Optimization

Once the forecasting run is complete, the next step is to supply the data for optimization. This data must be supplied before the user can optimize the runs to generate recommendations. To load this data, the user must use the PRO_MASTER_ADHOC job with the appropriate flags as described here: https://docs.oracle.com/en/industries/retail/retail-insights-cloud/21.0/rapog/ mstr-dat-load-oo-dsgn-ovrvw.htm

1. Configurations . The following configurations must be set up appropriately to supply the data at the relevant levels as well as to generate recommendations: PRO_CUST_HIER_PROCESSING_LVL, PRO_OPT_LOC_REC_LVL, and PRO_LOC_HIER_PROCESSING_LVL (which must be the same as PRO_OPT_LOC_REC_LVL). When recommendations are to be set by price zones then this is set to the Company level. Values are PRO_OPT_MERCH_REC_LVL,

PRO_OPT_TIME_REC_LVL, PRO_PROD_HIER_PROCESSING_LVL (for example, class), PRO_PROD_HIER_RUN_SETUP_LVL (for example, dept), and PRO_PROD_HIER_TYPE (for example, 3 for extended hierarchy).

2. Season-related data . The target tables to check are PRO_SEASON, PRO_SEASON_PERIOD and PRO_SEASON_PRODUCT. It is not required to provide all historical seasons, as the optimization is concerned only with the ongoing seasons.

3. Business Rules . It is important that the rules are defined at the highest merchandise/ location/season levels so that all items always find a rule to use. The target table to check is PRO_OPTIMIZATION_RULES.

4. Price Ladder . The target tables to check are PRO_PRICE_LADDER and PRO_PRICE_LADDER_DTL.

5. Create LPO runs . The user can run the PRO_OPT_CREATE_RUNS_ADHOC_JOB with the FORCE option to create the LPO runs for all merchandise and location/price zones.

6. Optimize LPO runs . The user can run the PRO_OPT_ADHOC_JOB with the -batch option to optimize all the above created runs.

Manage LPO Recommendations

The results will be available for the user to review/approve/export once the optimization job is complete.

Batch

Once the user is satisfied with the recommendations, then the user can put the system on a batch schedule to run at regular time intervals. Refer to “POM Jobs” about how to enable/ disable the relevant jobs.

Security

LPOn supports both data-based and user role-based filtering or security. Data filtering informs the application regarding which merchandise and locations can be accessed by a particular user (for example, the user ‘tom’ can only access locations within US). The user role restricts or allows which UI actions can be performed by a particular user.

Data Filtering

Data filtering can be specified (and integrated wherever applicable) in a similar fashion as discussed in Chapter 4, “Manage Data Filtering” of Oracle Retail Merchandising Suite - Administration Guide (https://docs.oracle.com/cd/E79623_01/rms/pdf/192000/merchcsadmin.pdf). When a customer does not have Oracle Retail Merchandising Service, then the following interfaces can be leveraged to specify the user groups and users.

RAF_FILTER_GROUP_MERCH
RAF_FILTER_GROUP_ORG
RAF_SEC_GROUP
RAF_SEC_USER11. Pricing Groups. If the user to define pricing groups such as Same Markdown Discount, etc., then it must be provided here for batch LPO runs to pick up.12. Flex Facts (or Custom Columns). If the user desires to see custom
RAF_SEC_USER_GROUP

User Roles

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. Five roles are supported in this application:

Pricing Administrator
Pricing Manager
Pricing Analyst
Buyer
Targeted Offer Role

Data Input Requirements

This section provides information about setting up the data that the LPO application uses to generate optimal price recommendations, 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 LPO, in both the forecasting and optimization modules. The four types of hierarchies are Location Hierarchy, Merchandise Hierarchy, Calendar Hierarchy, and Customer Segments Hierarchy. Hierarchy data is required.

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 (order of columns does not have to be the same) in the corresponding file, such as PRODUCT.csv.ctx.

Location Hierarchy. An example of location hierarchy is: CHAIN ’ COUNTRY ’ REGION ’ DISTRICT ’ STORE. When the user wants to optimize by location hierarchy, then the run’s optimization level must match a node in the location hierarchy. For example, you can run the optimization at the District level. 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, and W_INT_ORG_D. These are all loaded using the ORGANIZATION.csv file.
Price Zone Group and Price Zones. LPO provides the user with the flexibility to group any set of stores as part of a price-zone and use it as the run setup level for optimization. A price-zone group contains the set of price-zones, and each price-zone contains the set of stores. Note that two price-zones with a price-zone group cannot have any overlapping stores within a price-zone group. An example of Price-zone Group (PZG) and Price-zones (PZ) is as follows: PZG-100, mapped to DEPT1 with PZ-101 = Stores 1 to 10, PZ-102 =Stores 11 to 20. PZG-200, mapped to DEPT2 with PZ-201= Stores 1 to 5. PZ-202 = Stores 6 to 10. PZ-203 = Stores 11 to 20. Note that in LPO, a price-zone cannot be defined above country-level since the currencies can be different. Further, the price-zone can be associated with a list of items. Different merchandise in a Department at a particular store can be part of different price zones. For example, women’s university apparel in all university-based stores is grouped into one price zone and the women’s non-university apparel belongs to another price-zone. If a price-zones are not defined or used, then the UI displays a default value of -1-WORLDWIDE.

Corresponding interfaces are W_RTL_CLSTR_GRP_DS, W_RTL_CLSTR_GRP_HDR_LC_DS, W_RTL_CLSTR_GRP_PRD_DS, W_RTL_CLSTR_HDR_DS. In C_ODI_PARAM, when the value for CLSTR_PROD_LEVEL is in (DEPT, CLS, SBC) then all MERCH_ID values map to the associated level in W_PROD_CAT_DH. On the other hand, in C_ODI_PARAM, when the value for CLSTR_PROD_LEVEL is in (ITEMLIST), then all MERCH_ID values map to an Item List ID in W_RTL_ITEM_GRP1_D. The later allows the retailer to provide any custom item lists to be mapped to a price zone.

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 LPO is used for fashion apparel, it is expected that the you will provide Style and Color through the relevant interfaces. However, if the retailer deals with merchandise such as electronics, that does not necessarily have style or color, the application will work but some of the UI functionality will not be helpful. For example, Custom Rule has the merchandise selectors Class, Subclass, and Style. If no styles are loaded, then the last selector will not be helpful. Further, in such a situation, the recommendation levels will be at SKU level, as other levels may not be meaningful.

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 in W_PRODUCT_ATTR_D table that are used:

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.

Here is what this looks like:

PROD_NUM	PRODUCT_ATTR13_N AME	PRODUCT_ATTR14_N AME	PRODUCT_ATTR15_N AME
STYLE_PROD_NUM	STYLE_PROD_NUM
STY/COL_PROD_NUM	STYLE_PROD_NUM	STY/COL_PROD_NUM
STY/COL/	STYLE_PROD_NUM	STY/COL_PROD_NUM	STY/COL/
SIZ_PROD_NUM			SIZ_PROD_NUM

Calendar Hierarchy. This is one of the core hierarchies. The retailer can specify the calendar depending on their business requirements (for example, fiscal calendar). The relevant interface for this is W_MCAL_PERIOD_D. loaded using CALENDAR.csv file.
Customer Segments Hierarchy. LPO supports pricing recommendations at the customer segment level. 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. Retailers can use customer segments for many purposes;

however, for LPO purposes, retailers can use one set of customer segments to determine forecasting parameters and optimal price recommendations.

Runs in the LPO can be set up to run at configured levels for location or price zone, merchandise, calendar, and customer levels.

Location Level. The run’s location processing level is configurable in RSE_CONFIG, and it is denoted as PRO_LOC_HIER_PROCESSING_LVL. For example, a typical level is Region. If the user specifies price-zones, then location level defaults to COUNTRY.
Merchandise Level. The run’s merchandise processing level is configurable in RSE_CONFIG, and it is denoted as PRO_PROD_HIER_PROCESSING_LVL. For example, a typical level is the Class level.
Calendar Level. The run’s calendar processing level is configurable in RSE_CONFIG, and it is denoted as PRO_CAL_HIER_PROCESSING_LVL. For example, a typical level is Week.
Customer Level. The run’s customer processing level is configurable in RSE_CONFIG, and it is denoted as PRO_CUST_HIER_PROCESSING_LVL. For example, a typical level is Segment or Chain (that is, segment-all).
Setup Level. The run is set up at a level higher than the run’s merchandise level. This is configurable in RSE_CONFIG, and it is denoted as
- PRO_PROD_HIER_RUN_SETUP_LVL. For example, a typical level is Department level.

In this guide, the typical processing levels are generally used as illustration. If necessary, further details will be used to clarify non-typical levels. These levels are also important for the forecasting module since it provides the relevant parameters at the appropriate levels so that it can be consumed by the optimization module. It is essential that the configuration levels be decided based on the business of the retailer at the time of implementation.

Hierarchies are assumed to be set up once for each season and can be revisited whenever it changes. It is expected that the hierarchies do not change from one week to next week within a year (or season). Since hierarchies are core foundational elements any change to hierarchies can be costly and must be planned accordingly. For example, if customer segments are redone, then the parameters must be recalculated. The retailer must plan for such changes as such changes cannot necessarily be completed in the normal weekly batch process or window.

Inventory Data

Required interface. Historical inventory data as well as daily inventory data can be specified through this interface: INVENTORY.csv (staging table W_RTL_INV_IT_LC_DY_FS) . In addition to the non-null fields, the minimum required data fields that used by LPO are:

INV_SOH_QTY - store on hand
INV_ON_ORD_QTY - on order inventory quantity
INV_IN_TRAN_QTY - in transit inventory quantity
INV_UNIT_RTL_AMT_LCL

It is also recommend populating some other core fields on the table if the data exists, such as the RTL and COST values:

INV_SOH_RTL_AMT_LCL - total retail value
INV_ON_ORD_RTL_AMT_LCL - total on-order value
INV_IN_TRAN_RTL_AMT_LCL - total in-transit value
INV_AVG_COST_AMT_LCL - weighted avg cost (WAC)
INV_UNIT_COST_AMT_LCL - current unit cost
INV_SOH_COST_AMT_LCL - total OH cost value
INV_ON_ORD_COST_AMT_LCL - total on order cost value
INV_IN_TRAN_COST_AMT_LCL - total in transit cost value
DOC_CURR_CODE - document currency of the record in the source system
LOC_CURR_CODE - local currency for the AIF data warehouse system
LOC_EXCHANGE_RATE - exchange rate (for BCF probably hard-coded to 1)

LPO also uses these two fields, which cannot be provided directly through the above interface. Instead, they are calculated based on inventory receipts data provided in RECEIPT.csv file (W_RTL_INVRC_IT_LC_DY_FS staging table).

LAST_INVRC_DT
FIRST_INVRC_DT

Once the inventory data is loaded, the user can configure which inventory components are to be used in LPO by setting the corresponding flags appropriately: RSE_INV_QTY_BOH_FLG, RSE_INV_QTY_ON_ORD_FLG, RSE_INV_QTY_IN_TRANSIT_FLG.

Price History Data

Required Interface. Historical price data as well daily price history can be loaded using PRICE.csv file (W_RTL_PRICE_IT_LC_DY_FS staging table). In addition to non-null fields, these are the core fields to populate:

PRICE_CHANGE_TRAN_TYPE. The PRICE_CHANGE_TRAN_TYPE is based on the RMS usage of the value in PRICE_HIST. For example, 0 = initial price, 2 = cost change, 4 = cost reg price, 8 = clearance price, 9 = promo price.
SELLING_UNIT_RTL_AMT_LCL
BASE_COST_AMT_LCL
DOC_CURR_CODE
LOC_CURR_CODE
LOC_EXCHANGE_RATE

Retail Code

Required Interface. Loaded using the CODES.csv file. LPO directly uses W_RTL_CODE_D values to drive the markdown results, for example, if LPO is generating a first markdown then the associated code/desc values for the first markdown that customer wants to see are obtained from this table. An example of this data is provided below.

Table 13-1 Sample Retail Code Data

CODE_ TYPE	CODE	CODE_ SEQ	CREAT ED_BY _ID	CHAN GED_B Y_ID	CREAT ED_ON _DT	CHAN GED_O N_DT	DELET E_FLG	DATAS OURC E_NUM _ID	ETL_P ROC_ WID	INTEG RATIO N_ID
MKDN	1	1	-1	-1	11/30/2 020 12:42:4 0 PM	11/30/2 020 12:42:4 0 PM	N	1	1	MKDN~ 1
	2	2	-1	-1	11/30/2 020 12:42:4 0 PM	11/30/2 020 12:42:4 0 PM	N	1	1	MKDN~ 2
	3	3	-1	-1	11/30/2 020 12:42:4 0 PM	11/30/2 020 12:42:4 0 PM	N	1	1	MKDN~ 3
	4	4	-1	-1	11/30/2 020 12:42:4 0 PM	11/30/2 020 12:42:4 0 PM	N	1	1	MKDN~ 4

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). LPO requires you to provide retailer’s historical sales data at the desired hierarchy levels. If you want to use the targeted offers, then you must provide the customer-linked transactions sales data. The retailer does not have to provide the data aggregated to the segment-level but must provide the customer ID and customer segment mapping as part of customer segment interface.

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. If the user wants to separate the returns from gross sales, then retailer is required to provide these two values separately.

When the system is in production, the latest incremental sales data is obtained as part of the batch process.

Promotions

A historical and future planned promotions-related interface is optional. LPO allows the user to provide any promotions using the following interface: RSE_PLAN_PROMOTION_STG. This interface provides the retailer with the ability to specify the start and end dates of a promotion event and which merchandise or locations are part of the promotion. This information can help LPO in two ways: identify when the promotions have occurred in the past and learn which future planned promotions are similar to the ones in the past. In this interface, the retailer must specify name, when (time), which items, and how deep (for example, for a Father’s Day Sale, 20% off all merchandise in Mens division and across all stores).

Warehouse Inventory Allocation

The Warehouse Inventory Allocation interface is optional. The LPO user can provide the warehouse to store/online location mapping through this interface

(RSE_INV_WHSE_LC_PR_ALLOC_STG). In addition, the user can provide the allocation percentage for each item (that is, how much of warehouse inventory is allocated to the particular store/online location). The user can configure whether to include all components of warehouse inventory in the calculation: warehouse on order, warehouse in transit, warehouse on hand using the following flags: RSE_WHSE_INV_QTY_ON_ORD_FLG,

RSE_WHSE_INV_QTY_IN_TRANSIT_FLG, and RSE_WHSE_INV_QTY_BOH_FLG. If the user does not provide the allocation percentages, then LPO provides the user with ability to virtually allocate warehouse inventory using an in-built optimization algorithm. The optimization algorithm determines the allocation percentages based on the maximization of revenue across all warehouses. To turn on the warehouse virtual allocation algorithm, corresponding flag RSE_PRO_WHSE_ALLOC_FLG needs to be set to Y.

Competitor Prices

The Competitor Price interfaces, which are optional, are used to provide competitor prices. The two interfaces are W_RTL_COMP_PRICE_IT_LC_DY_FS and W_RTL_COMP_STORE_DS. The retailer can specify the price of an item at multiple competitors/locations and, depending on the configured option, either the minimum or the average of competitor prices is used for the optimization. Competitor prices are used to restrict the price recommendations to a certain percent range of the competitor price. For example, if the retailer wants to match the competitor’s promotion of 20 percent off but with some tolerance, then this interface allows the retailer to specify the competitor price through the interface. Tolerance is specified as a global parameter in RSE_CONFIG. Note that in this release, the product can support competitor prices only through an interface.

Product Attributes

The product attributes that are useful in LPO forecasting and in particular for targeted offers can be defined through this interface. Raw product attributes (for example, fabric, material, and so on) can be provided through this interface. Make sure the attribute values are as clean as possible. For example, COKE vs. COK vs. COEK must be normalized to COKE so that LPO does not interpret them as different attributes.

The retailer must use ATTR.csv and PROD_ATTR.csv files, which populates the table W_RTL_ITEM_GRP1_D, since it can support any number of attributes, such as BRAND, and the batch load process picks up the attributes added there automatically. The product attributes that are useful in LPO forecasting and in particular for targeted offers can be defined through this interface. Raw product attributes (for example, fabric, material, and so on) can be provided through this interface. Make sure the attribute values are as clean as possible. For example, COKE vs. COK vs. COEK must be normalized to COKE so that LPO does not interpret them as different attributes.

If the retailer wishes to load STYLE or COLOR as product attributes, then the W_RTL_ITEM_GRP1_D 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.

LPO supports grouping of product attribute values and it is required to load these additional interfaces: RSE_PROD_ATTR_GRP_VALUE_STG and RSE_PROD_ATTR_VALUE_XREF_STG. It is not required to group the attribute values. Consider the following examples:

Consider Brand attribute with values Adidas, Champion, Nike and Under Armour. Since we are not grouping any attribute values for attribute Brand, each value by itself will be a group.
Consider the Color attribute. There might be too many variants of the same color and thus it might be meaningful to group the color values. The first interface defines how many groups of colors would be there - for example, Trending, Casual, Professional. The second interfaces maps the actual attribute values to the groups - for example, Trending = {Flame Scarlet, Biscay Green}, Casual={Pink, Green}, Professional={Black, White, Grey}.
These interfaces can also help with normalization of attribute values. Consider an example when there are a lot of misspellings (for example, COEK vs. COK vs. COEK). The retailer can use this interface to normalize the attribute values and create one group called COKE.

Product Images Data

Product images that are available on a customer-hosted web server can be viewed In LPO via the Results screen. The PRODUCT.csv or W_RTL_PRODUCT_IMAGE_DS.dat interfaces contain a column called PRODUCT_IMAGE_ADDR, that can contain 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

The LPO application running in the cloud does not directly access these images, so there is no need to expose these images outside of the customer’s firewall. As long as the user of the LPO application has access to the URL while running the LPO application, then the user’s web browser will be able to resolve the URL and retrieve the images for display when they choose this option. The images must be in a file format that the web browser can display. Since the images shown in the UI are small, these images do not need to be high quality images. The size of the image files will affect the time it takes to render them.

Season

PRO_SEASON_STG is used to define the name of the season with the start and end dates. For example, Halloween Season is used to identify merchandise that sells for Halloween. If the retailer does not have any seasons, then the retailer can define one long season.

Season Periods

PRO_SEASON_PERIOD_STG defines which periods belong to the season and lets users define whether a promotion or a markdown is allowed in a particular period. This interface can include the promotion and markdown calendar information of the retailer.

Season Products

PRO_SEASON_PRODUCT_STG defines which products are associated with a season. This interface indicates which products are to be included in the optimization for recommendations.

Price Ladder

PRO_PRICE_LADDER_STG can be used to supply price ladders. It supports three types of price ladders: Price Point (denoted by type A), Percentage Off Ticket Price (denoted by PT), and Percentage Off Full or Original Price (denoted by PO). The LADDER_COUNT can be used to define the ladder for the first and/or subsequent markdowns or promotions. The Ladder_count=0 must always be defined and is used in optimization. Any non-zero ladder_count ladders (only type A) are used for post-processing of price recommendations. For example, Ladder_count=0 is ending with .99, and ladder_count=2 is ending with .98 and ladder_count=3 is ending with .97.

Currency

PRO_COUNTRY_LOCALE_STG can be used to define the currency based on the country. This allows the same instance to support multiple currencies. For example, US locations must generate price recommendations (and price-related metrics) in USD, and Canadian locations must generate price recommendations (and price-related metrics) in CAD. Budgets can be specified in one global currency and optimization runs can be in a different local currency based on PRO_COUNTRY_LOCALE_STG. In which case, budgets are converted based on exchange rates provided in W_EXCH_RATE_GS.

Holidays

RSE_HOLIDAY_STG can be used to define the holidays that are used by the retailer. Major holidays can cause additional traffic visiting the store or the web channel.

Pricing Product Groups

W_RTL_ITEM_GRP1_D (loaded using PROD_ATTR.csv) can be used to define the different pricing product groups that are used by the retailer. PRO_OPTIMIZATION_RULES_STG allows the retailer to specify the group types for each of the defined groups. For example, both these interfaces help retailer define which items comprise the group and that this group would need the same markdown discount. Such groups and corresponding constraints are picked up by batch optimization runs.

Budget

W_RTL_PLAN1_PROD1_LC1_T1_FS can be used to specify the budgets for markdowns and/or promotions used by the retailer. A budget can be fed in at the run’s merchandise setuplevel (for example, Division) or it can be fed in at the run’s merchandise processing-level (for example, Department). The interface allows the user to provide separate budgets or a combined budget for promotions and markdowns. The relevant fields from the interface are: slspr_rtl_amt (promotion budget), slscl_rtl_amt (clearance budget), loc_exchange_rate, mcal_wid, delete_flg, prod_dh_wid, org_dh_wid. On loc_exchange_rate, if the retailer operates in only one country, then it can be 1. However, it is possible that when a customer spans multiple countries, the planning budget can be in one global currency and when it is applied, it

can be in local currency. For example, to convert USD into GBP, set loc_exchange_rate as 1/0.75.

Strategy and Business Rules

PRO_OPTIMIZATION_RULE_STG allows the user to define business rules and associate them with a strategy set. This interface provides the following abilities for the user:

There will always be a DEFAULT_SET strategy that is reserved to be used by batch runs in production. Other strategy sets are available for the user to do what-if runs.
It is advised that retailers define all the business rules in the DEFAULT_SET strategy. It is not required that the user define complete set of rules again for a new strategy set. For example, an Aggressive Promotion Strategy set can define rules associated with promotions only. In such a case, the system will try to find the closest rule that is available in DEFAULT_SET when it is not available in the current strategy set.
In any strategy set, the user can define rules at any merchandise and location levels. Rules will be applied to the merchandise and location that are closest to it. The term “Closest” can be defined as follows: for a given product level, move up the location hierarchy first to find any applicable rule. For example, the user defines Min First Markdown as 10% at Banner- All locations level and 20% for Men’s Division-All locations.Then, merchandise in Men’s division receives the 20% Min First Markdown rule, and all other merchandise receives the 10% Min First Markdown rule for all locations.
Strategies can also be defined for price zone group (PZG) or price zone (PZ) level, when applicable. Note the following: (1) When the user wants to use PZG or PZ to specify rules, then the LOCATION_KEY must be -1 and LOCATION_HIER_LEVEL must be ALL. (2) When the user wants to specify a rule for all PZ Groups, then PZ GROUP = ALL (and PZ Key=-1). (3) When the user wants to specify a rule for all PZ within a PZG, then PZ GROUP must be specified (and PZ Key=-1). (4) When the user wants to specify a rule for a specific PZ , then PZ GROUP KEY = and PZ KEY must be specified. (5) When the user is not using PZG/PZ, then PZ GROUP KEY and PZ KEY must be -1.

Custom Columns

W_RTL_FLEXFACT1_FS can be used to add any custom column to the recommendations in the Manage Recommendation screen. Custom columns are picked up by batch runs at the time of their creation and assigned to the item and location. It supports up to ten numeric columns (for example, last year sales), twenty currency columns (for example, revenue till date), ten text columns (for example, supplier), five percentage columns (for example, sellthrough for last four weeks), and five date columns (for example, last markdown date).

External Forecast Adjustment

PRO_FCST_EXT_EFFECT_ADJ_STG is used to provide adjustments to the forecast. It may occasionally be possible that extraneous factors that are not visible to LPO can impact the forecast (for example, Covid-19). In such a case, this interface can be leveraged to provide such factors to impact the LPO forecast.

Configuration and Expected Levels for Interfaces

The expected levels for the interfaces are based on the configuration levels specified for the recommendation and optimization levels. There are five dimensions that are used to define these configurations: Customer (applicable only for targeted offers), Calendar, Merchandise, Location, and Price-zone. The optimization level determines the levels at which optimization is

performed. For example, Division and Region (it can also be a price-zone). The recommendation level determines at what levels recommendations must be generated. Typically, these are lower levels of merchandise and location than the optimization levels (for example, Style/Color and Region). Note that the Calendar dimension tells the system at which level recommendations are generated (for example, Weekly vs Daily). The customer dimension tells the system that customer segments are available to generate targeted offers. Promotions and Markdowns are not generated at the customer segment level. If price-zones are not used, then the Price-zone column will be -1. When price-zones are used, then both optimization and recommendation levels will be price-zone. In such a case, both the location configurations, PRO_LOC_HIER_PROCESSING_LVL and PRO_OPT_LOC_REC_LVL, must be set to COUNTRY.

Table 13-2 Configuration: Expected Levels

Data	Configuration Parameters	Customer Segment	Calendar	Merchandis e	Location	Price Zone
Optimization Level	Levels at which the optimization process is executed (Units of work)	PRO_CUST _HIER_PR OCESSING _LVL	PRO_CAL_ HIER_PRO CESSING_ LVL	PRO_PROD _HIER_PRO CESSING_L VL	PRO_LOC_ HIER_PRO CESSING_ LVL	-1 or PZ
Recommendatio n Level	Level at which the recommendatio n results are generated	PRO_OPT_ CUST_REC _LVL	PRO_OPT_ TIME_REC _LVL	PRO_OPT_ MERCH_RE C_LVL	PRO_OPT_ LOC_REC_ LVL	-1 or PZ

Depending on the above configuration levels, the interface levels expected are as follows:

Table 13-3 Interfaces: Expected Levels

Data	Interface Name	Notes	Customer	Calendar	Merchandis e	Location	Price Zone
Season	PRO_SEA SON_STG	Range of time periods (e.g., weeks) for the season. This has to match the calendar hierarchy loaded	N/A	N/A	N/A	N/A	N/A

Table 13-3 (Cont.) Interfaces: Expected Levels

Data	Interface Name	Notes	Customer	Calendar	Merchandis e	Location	Price Zone
Season Period	PRO_SEA SON_PERI OD_STG	Periods (e.g., weeks) within a season where the PRO_PRO D_HIER_P ROCESSIN G_LVL (e.g., CLASS) is active	N/A	PRO_CAL_ HIER_PRO CESSING_ LVL Date range could span multiple calendar units (i.e. Multiple weeks)	PRO_PROD _HIER_PRO CESSING_L VL or any hierarchy level higher	PRO_LOC _ HIER_ PROCESSI NG_ LVL or any other higher hierarchy level	-1 or PZ
Season Product	PRO_SEA SON_PRO DUCT_ST G	Products that must be included in given selling seasons	N/A	PRO_CAL_ HIER_PRO CESSING_ LVL Date range can span multiple calendar units (i.e. Multiple weeks)	PRO_OPT_ MERCH_RE C_LVL	PRO_OPT _LOC_RE C_LVL	-1 or PZ
Price Ladder	PRO_PRIC E_LADDE R_STG	Product price ladder	N/A	N/A	PRO_PROD _HIER_PRO CESS- ING_LVL or any higher	PRO_LOC _HIER_PR OCESSIN G_LVL	-1 or PZ
Country Locale	PRO_COU NTRY_LO CALE_ST G	Defines the specific locale for the location. Provided at the COUNTRY level	N/A	N/A	N/A	PRO_LOC _HIER_PR OCESSIN G_LVL or any hierarchy level higher	N/A
Planned Promotion	RSE_PLA N_PROMO TION_STG	Planned promotion at PRO_PRO D_HIER_P ROCESSIN G_LVL (e.g., CLASS)	N/A	PRO_CAL_ HIER_PRO CESSING_ LVL Date range could span multiple calendar units (i.e. Multiple weeks)	PRO_PROD _HIER_PRO CESS- ING_LVL	PRO_LOC _ HIER_ PROCESSI NG_ LVL	-1 or PZ
Holidays	RSE_HOLI DAY_STG	Major holidays	N/A	Date when the holiday is observed	Any level in merchandise hierarchy	Any level in location hierarchy	N/A

Table 13-3 (Cont.) Interfaces: Expected Levels

Data	Interface Name	Notes	Customer	Calendar	Merchandis e	Location	Price Zone
Strategy and	PRO_OPTI MIZATION	Business rules and	N/A	N/A	Any level in merchandise	Any level in location	N/A
Business	_RULE_ST	associated			hierarchy	hierarchy
Rules	G	strategies

Table 13-4 Expected Levels for Optional Interfaces*

Data	Interface Name	Notes	Customer	Calendar	Merchandis e	Location	Price Zone
Inventory	RSE_INV_ PR_LC_W K_A_STG	Inventory available at the start of the period (e.g., week). Inventory is aggregated to the PRO_LOC _HIER_PR OCESSIN G_LVL (e.g., Price Zone)	N/A	Week	SKU level (Style/Color/ Size)	Store	N/A
Price Cost	RSE_PRIC OST_PR_L C_WK_ST G	Price cost for the time period (e.g., week)	N/A	Week	SKU level (Style/Color/ Size)	Store	N/A

Optional* Interfaces

The interfaces specified in this section are not required and are available to handle special retailer situations. When the retailer provides the data through the interfaces tagged as ‘required’, then the system automatically uses the primary interfaces.

Inventory (RSE_INV_PR_LC_WK_A_STG)
Price Cost (RSE_PRICOST_PR_LC_WK_STG)

Integration with Retail Pricing Cloud Service

Additional configuration parameters must be set to integrate LPO with Retail Pricing Cloud Service. See the list of parameters shown in Table 13-5. In addition, the Pricing CS username and password must be added under the credential store for Merchandise Pricing CS Access. You can modify these values using the UI screen for Control and Tactical Center → Manage Credential Stores. Control and Tactical Center is available under the task menu.

POM Jobs

This section describes the batch jobs provided in the POM. Use this information to set up appropriate jobs for the regular batch process. Batch jobs do not expect any user input, and parameters are set to default values. Jobs are listed here by the functional area:

Foundation jobs that load product hierarchy, location hierarchy, calendar, product attributes, price zones, specify merchandise and location base user data filters (or security) are:

ORASE_START_BATCH_JOB
ORASE_START_BATCH_REFRESH_RESTR_JOB
ORASE_START_BATCH_SET_ACTIVE_JOB
ORASE_START_BATCH_END_JOB
RSE_WEEKLY_INPUT_FILES_START_JOB
WEEKLY_INPUT_FILES_WAIT_JOB
WEEKLY_INPUT_FILES_VAL_JOB
WEEKLY_INPUT_FILES_COPY_JOB
RSE_WEEKLY_INPUT_FILES_END_JOB
RSE_DIMENSION_LOAD_START_END_JOB
RSE_DIMENSION_LOAD_START_START_JOB
RSE_REGULAR_MAIN_LOAD_JOB
RSE_LOC_SRC_XREF_LOAD_JOB
RSE_PROD_SRC_XREF_LOAD_JOB
RSE_LOC_HIER_LOAD_JOB
RSE_LOC_HIER_TC_LOAD_JOB
RSE_LOC_HIER_DH_LOAD_JOB
RSE_FISCAL_MAIN_LOAD_JOB
RSE_PROD_HIER_LOAD_JOB
RSE_PROD_TC_LOAD_JOB
RSE_PROD_DH_LOAD_JOB
RSE_PROD_GROUP_LOAD_JOB
RSE_PRICE_ZONE_LOAD_START_JOB
RSE_PRICE_ZONE_GRP_LOAD_JOB
RSE_PROD_ATTR_GRP_VALUE_STG_JOB
RSE_PRICE_ZONE_LOAD_JOB
RSE_PROD_ATTR_GRP_VALUE_LOAD_JOB
RSE_PRICE_ZONE_LOAD_END_JOB
RSE_PROD_ATTR_VALUE_XREF_STG_JOB
RSE_DIMENSION_LOAD_END_START_JOB
RSE_PROD_ATTR_VALUE_XREF_LOAD_JOB
RSE_DIMENSION_LOAD_END_END_JOB
RSE_SLS_START_START_JOB
• RSE_USER_DATA_FILTER_START_JOB
RSE_SLS_START_END_JOB
RSE_SLS_TXN_START_JOB
• RSE_USER_DATA_FILTER_LOAD_JOB
RSE_LIKE_LOC_STG_JOB
• RSE_USER_DATA_FILTER_END_JOB
RSE_LIKE_LOC_LOAD_JOB
• RSE_SLS_TXN_SETUP_JOB
RSE_SLS_TXN_PROCESS_JOB
RSE_SLS_TXN_END_JOB
RSE_WKLY_DAILY_PROFILE_AGGR_PROCESS_JOB
RSE_WKLY_DAILY_PROFILE_AGGR_START_JOB
RSE_WKLY_SLS_CUST_SEG_START_
RSE_WKLY_SLS_START_JOB
RSE_WKLY_SLS_SEG_SETUP_JOB
RSE_WKLY_SLS_SETUP_JOB
• RSE_WKLY_SLS_PROCESS_JOB • RSE_WKLY_SLS_SEG_PROCESS_JOB
RSE_WKLY_SLS_END_JOB
• RSE_WKLY_AGGR_SLS_START_JOB
RSE_WKLY_AGGR_SLS_END_JOB
RSE_WKLY_DAILY_PROFILE_AGGR_END_JOB
RSE_WKLY_SLS_CUST_SEG_END_JOB
• RSE_SLS_END_START_JOB • RSE_SLS_END_END_JOB
RSE_INV_LOAD_START_JOB
RSE_PRICE_LOAD_START_JOB
• RSE_INV_PR_LC_WK_STG_JOB�
RSE_PRICOST_PR_LC_WK_STG_JOB
• RSE_PRICOST_PR_LC_WK_LOAD_JOB • RSE_PRICOST_PR_LC_WK_SETUP_JOB
RSE_PRICOST_PR_LC_WK_PROCESS_JOB
RSE_PRICE_LOAD_END_JOB
RSE_INV_PR_LC_WK_LOAD_JOB
RSE_INV_PR_LC_WK_SETUP_JOB
RSE_INV_PR_LC_WK_PROCESS_JOB
RSE_INV_LOAD_END_JOB
ORASE_END_START_JOB
ORASE_END_RUN_DATE_UPDT_JOB
ORASE_END_END_JOB

Estimation and forecasting jobs that perform parameter estimation and generate forecast are:

PRO_BASELINE_LOAD_START_JOB
PRO_FCST_EXT_EFF_ADJ_START_JOB
PRO_BASELINE_STG_JOB
PRO_FCST_EXT_EFF_ADJ_STG_JOB
PRO_PLAN_PROMOTION_LIFT_STG_JOB
PRO_BASELINE_LOAD_JOB
PRO_DOW_PROF_START_JOB
PRO_FCST_EXT_EFF_ADJ_LOAD_JOB
PRO_BASELINE_LOAD_END_JOB
PRO_DOW_PROF_STG_JOB
PRO_DOW_PROF_LOAD_JOB
PRO_DOW_PROF_END_JOB
PRO_FCST_EXT_EFF_ADJ_END_JOB
PRO_LIFECYCLE_FATIGUE_LOAD_START_JOB
PRO_MODEL_DATES_LOAD_START_JOB
PRO_LIFECYCLE_FATIGUE_STG_JOB
PRO_MODEL_DATES_STG_JOB
PRO_LIFECYCLE_FATIGUE_LOAD_JOB
PRO_MODEL_DATES_LOAD_JOB
PRO_LIFECYCLE_FATIGUE_LOAD_END_JOB
PRO_MODEL_DATES_LOAD_END_JOB
PRO_PLAN_PROMOTION_LIFT_LOAD_JOB
PRO_SEASONALITY_STG_JOB
RSE_HOLIDAY_LOAD_START_JOB
RSE_PLAN_PROMO_LOAD_START_JOB
RSE_HOLIDAY_LOAD_STG_JOB
RSE_HOLIDAY_LOAD_JOB
RSE_HOLIDAY_LOAD_END_JOB
RSE_PLAN_PROMO_STG_JOB
RSE_PLAN_PROMO_LOAD_JOB
RSE_PLAN_PROMO_LOAD_END_JOB
PMO_HOLIDAY_LOAD_START_JOB
PMO_HOLIDAY_LOAD_JOB
PMO_HOLIDAY_LOAD_END_JOB
PRO_SEASONALITY_LOAD_JOB
PMO_ACTIVITY_STG_JOB
PMO_ACTIVITY_LOAD_JOB
PMO_RUN_EXEC_START_JOB
PMO_CREATE_BATCH_RUN_JOB
PMO_RUN_EXEC_SETUP_JOB
PMO_RUN_EXEC_PROCESS_JOB
PMO_CUMUL_SLS_START_JOB
PMO_CUMUL_SLS_SETUP_JOB
RSE_PUBLISH_FCST_PARAMETER_START_JOB
PMO_CUMUL_SLS_PROCESS_JOB
RSE_PUBLISH_FCST_PARAMETER_MODEL_DATE_JOB
PMO_CUMUL_SLS_END_JOB
RSE_MODEL_START_START_JOB
RSE_MODEL_START_CALC_JOB
RSE_PUBLISH_FCST_PARAMETER_SPREAD_DOWN_JOB
RSE_PUBLISH_FCST_PARAMETER_SEAS_CURVE_JOB
RSE_PUBLISH_FCST_PARAMETER_END_JOB
RSE_MODEL_START_END_JOB
PMO_RUN_EXEC_END_JOB
RSE_FCST_BATCH_RUN_START_JOB
RSE_CREATE_FCST_BATCH_RUN_JOB
RSE_FCST_BATCH_PROCESS_JOB
RSE_FCST_BATCH_RUN_END_JOB

Optimization jobs that load business rules and other related data are:

PRO_COUNTRY_LOCALE_START_JOB
PRO_OPT_RULE_START_JOB
PRO_PLAN_PROMOTION_LOAD_START_JOB
PRO_PROD_LOC_CDA_LOAD_START_JOB
PRO_COUNTRY_LOCALE_STG_JOB
PRO_OPT_RULE_STG_JOB
PRO_COUNTRY_LOCALE_LOAD_JOB
PRO_OPT_RULE_LOAD_JOB
PRO_PROD_LOC_CDA_LOAD_JOB
PRO_COUNTRY_LOCALE_END_JOB
PRO_SEASON_LOAD_START_JOB
PRO_OPT_RULE_END_JOB
PRO_PLAN_PROMOTION_LOAD_JOB
PRO_SEASON_STG_JOB
PRO_PLAN_PROMOTION_LOAD_END_JOB
PRO_SEASON_PRODUCT_STG_JOB
PRO_SEASON_PERIOD_STG_JOB
PRO_SEASON_CURR_OPT_METRIC_STG_JOB
PRO_SEASON_PROD_MKDN_EDT_STG_JOB
PRO_SEASON_LOAD_JOB
PRO_SEASON_PRODUCT_LOAD_JOB
RSE_BUDGET_START_JOB
RSE_BUDGET_ALLOC_SETUP_JOB
RSE_BUDGET_ALLOC_PROCESS_JOB
RSE_BUDGET_END_JOB
PRO_SEASON_PERIOD_LOAD_JOB
PRO_SEASON_CURR_OPT_METRIC_LOAD_JOB
PRO_SEASON_CURR_OPT_METRIC_SETUP_JOB
PRO_SEASON_PROD_MKDN_EDT_LOAD_JOB
PRO_SEASON_LOAD_END_JOB
• PRO_PROD_LOC_CDA_LOAD_END_JOB
PRO_PRICE_LOAD_START_JOB
• RSE_WHSE_INV_ALLOC_LOAD_START_JOB
PRO_PRICE_LOAD_SETUP_JOB
• RSE_WHSE_INV_ALLOC_STG_JOB • PRO_PRICE_ELASTICITY_STG_JOB • PRO_PRICE_LADDER_STG_JOB • PRO_PRICE_LOAD_PROCESS_JOB • PRO_PRICE_ELASTICITY_LOAD_JOB • PRO_PRICE_LADDER_LOAD_JOB • PRO_PRICE_LOAD_END_JOB
RSE_WHSE_INV_ALLOC_LOAD_JOB
• RSE_WHSE_INV_ALLOC_PROCESS_JOB • RSE_WHSE_INV_ALLOC_LOAD_END_JOB
PRO_INVENTORY_LOAD_START_JOB
PRO_INVENTORY_LOAD_SETUP_JOB
PRO_INVENTORY_LOAD_PROCESS_JOB
PRO_INVENTORY_LOAD_END_JOB
PRO_OPT_START_JOB
PRO_OPT_CREATE_RUNS_JOB
PRO_OPT_JOB
PRO_OPT_END_JOB
PRO_SEASON_CURR_OPT_METRIC_PROCESS_JOB

Export and innovation workbench jobs that export the recommendations as well as grant permissions for objects in IW are:

RSE_IW_GRANT_START_JOB
RSE_IW_GRANT_JOB
RSE_IW_GRANT_END_JOB
RSE_EXPORT_START_START_JOB
RSE_EXPORT_START_END_JOB
PRO_EXPORT_START_JOB
RSE_EXPORT_PREP_START_JOB
PRO_EXPORT_PRICE_RECOM_JOB
RSE_DAILY_BATCH_EXPORT_PREP_JOB
PRO_EXPORT_RUN_RECOM_OPT_RESULT_JOB
RSE_WEEKLY_BATCH_EXPORT_PREP_JOB
PRO_EXPORT_RUN_TO_RESULT_JOB
RSE_EXPORT_END_START_JOB
RSE_QUARTERLY_BATCH_EXPORT_PREP_JOB
PRO_TO_EXPORT_PRICE_RECOM_JOB
RSE_EXPORT_END_END_JOB
RSE_EXPORT_PREP_END_JOB
PRO_EXPORT_END_JOB
RSE_POST_EXPORT_DAILY_START_JOB
RSE_POST_EXPORT_WEEKLY_START_JOB
RSE_POST_EXPORT_DAILY_RESET_JOB
RSE_POST_EXPORT_WEEKLY_RESET_JOB
RSE_POST_EXPORT_DAILY_ZIP_JOB
RSE_POST_EXPORT_WEEKLY_ZIP_JOB
RSE_POST_EXPORT_WEEKLY_COPY_JOB
RSE_POST_EXPORT_WEEKLY_FTP_JOB
RSE_POST_EXPORT_WEEKLY_END_JOB
RSE_POST_EXPORT_DAILY_COPY_JOB
RSE_POST_EXPORT_DAILY_FTP_JOB
RSE_POST_EXPORT_DAILY_END_JOB

Forecasting Science

LPO forecasting has two modules, parameter estimation and demand forecasting. Parameter estimation uses the historical data to determine the seasonality, markdown 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 reestimated on a regular basis as part of batch process) to determine the demand and generate the forecast.

LPO forecasting supports the following features:

Separate elasticity values for promotions and markdowns
Customer segment level parameter values for seasonality, elasticity, and traffic lift for promotion and holidays
The weather effects from historical data period can be incorporated into the estimation of parameters to remove the bias introduces by weather on forecasted sales.
The ability to execute the following analysis:
- Day of the week and time of the day profiles
- Returns analysis

For both parameter estimation and demand forecasting stages, you can set up runs and configure various settings using the Manage Forecast Configurations functionality under Strategy & Policy Management. Based on the configuration settings, a batch job is used to initially estimate the parameters and then update them 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.

Parameter Estimation

Parameter estimation consists of the following stages. Each stage has a series of configurable parameters and the corresponding default values. Modify the default values appropriately for each retailer. You can modify these settings using the Manage Forecast Configurations functionality under Strategy & Policy Management.

Overview of the Parameter Estimation Stages

The following sections describe the details of the settings in each stage.

1. Data preparation. Defines the levels to which data is aggregated on merchandise, location, customer segment, and time dimensions and the duration of the data used for parameter estimation.

2. Preprocessing. Filters the historical data and makes the first determination of item eligibility.

3. Elasticity. Determines the price elasticity for markdowns and promotions.

4. Seasonality. Estimates seasonality trends and identifies partitions with reliable seasonality.

5. Promotion lift. Estimates the traffic lift during promotion and holiday events. Corrects the seasonality curves to remove the traffic lift from promotion and holiday events.

6. Output. Generates parameter files in the format required by demand forecasting and offer optimization.

The parameter estimation stage generates markdown elasticity, promotion elasticity, seasonality and promotion lift values. Together they are referred to as demand parameters.

Parameter estimation requires at least 20 months of data. These requirements exist for the following reasons.

The data from the beginning 4-6 weeks of the historical period must be removed from the data analysis so that the items that have truly started selling after the beginning of historical data period can be identified.
The full life cycle data is required for all fashion/seasonal merchandise introduced during a fiscal year in order to estimate the seasonality curve for merchandise starting in every fiscal month. The least amount of data required is one year plus the typical season length of the merchandise.

Data Preparation

The data preparation stage defines the aggregation levels on merchandise, location, customersegment, calendar dimensions, and duration of the data used for parameter estimation.

In addition to the above, configuration of the hierarchy level at which promotion data is processed is completed here.

Data Aggregation

Sales data, inventory data, and returns data are aggregated on the following dimensions: Merchandise, Location, Price Zone (if available), Customer Segment (if available), and Calendar. The hierarchy type ID corresponding to each dimension is configured using the following parameters in the RSE_CONFIG table. Use the Manage System Configurations functionality to set the appropriate ID for each dimension.

The level of aggregation for each dimension can be configured while setting up the forecast run types in Manage Forecast Configurations. In addition, while creating a run type, the user can indicate whether Price Zone and Customer Segment should be used as additional dimensions in the aggregation process.

Merchandise (PMO_PROD_HIER_TYPE). Multiple hierarchy types are available for Merchandise, Product, and Extended Product hierarchies. Choose the ID corresponding to the appropriate product hierarchy. Typically, data is aggregated to Style/ Style-Color level on the merchandise hierarchy. Select the appropriate merchandise level when setting up the forecast run type in Mange Forecast Configurations.
Location (PMO_LOC_HIER_TYPE). Multiple hierarchy types are available for location, for example, Location Hierarchy and Trade Area Hierarchy. Choose the ID corresponding to the appropriate location hierarchy. Typically, data is aggregated to Store Cluster/Price Zone level. Choose the appropriate level. Select the appropriate location level when setting up the forecast run type in Manage Forecast Configurations.
Customer Segment (PMO_CUST_SEG_HIER_TYPE). Choose the hierarchy type ID associated with the customer segment. By default, customer segment data is aggregated at two levels, by individual customer segments and Segment-All, which includes all the segments. The user does not have the option to select the aggregation level by customer segment.
Calendar (PMO_FISCAL_CAL_HIER_TYPE). Choose the hierarchy type ID associated with the Calendar hierarchy.

Table 13-6 Data Aggregation

Setting Name and Description	Default Value	Range of Values
Merchandise Hierarchy Type ID: ID corresponding to the merchandise hierarchy used for aggregation of sales, inventory, and returns data. PMO_PROD_HIER_TYPE	3	1 - 15
Location Hierarchy Type ID: ID corresponding to the location hierarchy used for aggregation of sales, inventory, and returns data.	2	1 - 15
PMO_LOC_HIER_TYPE
Customer Segment Hierarchy Type ID: ID corresponding to the customer segment hierarchy used for aggregation of sales, inventory, and returns data.	4	1 - 15
PMO_CUST_SEG_HIER_TYPE
Calendar Hierarchy Type ID: ID corresponding to the calendar used for aggregation of sales, inventory, and returns data.	11	1 - 15
PMO_FISCAL_CAL_HIER_TYPE
Merchandise Level: Level in the merchandise hierarchy at which data is aggregated for sales, inventory, and returns. Typically, data is aggregated to STYLE-COLOR. Choose the appropriate level when setting up the forecast run type in Manage Forecast Configurations.	8	1 - 9
Location Level: Level in the location hierarchy at which data is aggregated for sales, inventory, and returns. Typically, data is aggregated to STORE CLUSTER. Choose the appropriate level when setting up the forecast run type in Manage Forecast Configurations.	5	1 - 6
Calendar Level: Level in the calendar hierarchy at which data is aggregated for sales, inventory, and returns. Choose the appropriate level when setting up the forecast run type in Manage Forecast Configurations.	4	1 - 5
Keep temporary tables: Turn this setting on to retain the intermediate tables generated during the parameter estimation process.	N	Y/N
PMO_KEEP_TEMP_TABLES

Promotion Data Processing Level

Promotions data can be present at various levels in the merchandise and location hierarchy. Choose the level at which promotions are defined for estimating traffic lift values. For estimating traffic lifts, we consider major events which drive significant traffic across the chain. For example: there events are defined at country-banner level.

Table 13-7 Hierarchy Levels Selection

Setting Name and Description	Default Value	Range of Values
Promotion processing level Merchandise. Choose the ID corresponding to the merchandise level at which traffic driving promotions are defined.	2	1 - 9
Usually this is Company/Banner if there are multiple banners within the company.
PMO_MIN_LOC_HIER_PROCESSING_LVL
Promotion processing level - Location: Choose the	2	1 - 6
ID corresponding to the location level at which traffic driving promotions are defined. Usually this is Chain/Country level.
PMO_MIN_PROD_HIER_PROCESSING_LVL

Data Validation

Once the data preparation stage is complete, prepare data validation report and review it with the customer to confirm the data loaded matches with their expectations. Include the following in the data validation report.

Summary of merchandise, location, customer segment, calendar hierarchies
Sales units and amount by year at Chain and Division levels
Summary metrics by Department-Price zone
Sales, Inventory and Product count trends by Fiscal week and Fiscal year at CountryBanner level
For the following data fields Ticket price, sales price, Item cost, Sales units, Sales amount, Inventory
- Search for negative and null values
- Significant percent of records with either negative or null values. Flag for review with customer.

Validating data with the customer is key to identifying potential data related problems early on. Investigate any potential data issues and work with the customer to resolve them. This ensures that the following stages are using the appropriate data.

Preprocessing

The Preprocessing stage filters the historical data to produce a subset of data that produces reliable demand parameters. The Preprocessing stage applies filters at the partition and week level. It performs the initial pruning of bad activity data. It does the first stage of determining eligibility and calculates certain values that can later be used in the calculation of elasticity and seasonality parameters. You can modify the configuration settings for the preprocessing stage using the Manage Forecast Configurations functionality under Strategy & Policy Management.

Data Filters Week Level

Table 13-8 shows the various week level filters used in the Preprocessing stage. These filters are used to remove individual weekly records of data that do not meet the requirement defined as specified for each filter.

Table 13-8 Data Filters Week Level

Filter Name and Description Default Value Range of Values Store count greater than 0. Used to filter activities N Y/N with null or zero store count. IWF_STORE_GTR_ZERO SKU store count greater than 0. Used to filter N N/Y activities with null or zero sku store count. IWF_SKU_STORE_GTR_ZERO Inventory data present. Used to indicate that the Y N/Y inventory data is available and reliable. If inventory data is available and reliable, then Preprocessing will use inventory data for filtering and other calculations. If inventory data is not available or unreliable, then it is ignored. IWF_INV_DATA_PRESENT Sales unit threshold. Used to filter sales data 1 Greater than or equal to records with sales units below threshold values. 1. IWF_SALES_UNIT_THRESHOLD Inventory threshold. Used to filter sales data 1 Greater than or equal to records with inventory units below threshold values. 0. IWF_INV_THRESHOLD Use store count for Inventory threshold. Defines the N Y/N criteria used for inventory threshold. Setting to Y will use Store count with inventory as inventory threshold criteria instead of actual inventory value. IWF_SKU_STORE_COUNT Threshold combination. Use AND/OR combination AND AND/OR for Sales unit threshold and Inventory threshold.IWF_FILTER_COMBO Life cycle sell thru %. The item start and end dates Start: 2.0 Start: greater than or are calculated using percentage sell through. The End: 2.0 equal to 0; less than or start date is the date when Life cycle sell through % equal to 50. (Start) is reached. The end date is the date when End: greater than or Life cycle sell through % (End) is reached. Life equal to 0; less than or cycle sell through % (Start) is expressed relative to equal to 50. 0% so entering 2 means that the start date is when 2% of total sales has been achieved. Life cycle sell through % (End) is expressed relative to 100% so entering 2 means that the end date is when (100-2)% i.e., 98%, of total sales has been achieved. IWF_LOW_LCYCLE_SELL_PCT and IWF_HIGH_LCYCLE_SELL_PCT Relative price. Relative price thresholds are used to Start: 0.2 Start: greater than 0. filter out item weeks with a ratio of sales price to End: 1.0 End: greater than the maximum ticket price that fall outside the specified start value. range for the start date and the end date. IWF_LOW_RELATIVE_PRICE and IWF_HIGH_RELATIVE_PRICE

Partition Filters

These filters are used to exclude all the weekly records from a Merchandise-LocationCustomer segment partition at the aggregation level, for partitions with values that do not meet the requirement specified for each filter, as described below.

Table 13-9 Partition Filters

Filter Name and Description	Default Value	Range of Values
Minimum number of eligible weeks. Aa certain number of weeks are necessary in order to determine item eligibility. IF_MIN_ELIGIBLE_WEEKS	6	Greater than 0.
Minimum season (weeks). A certain season length (the number of weeks between the first and last activity) is required in order to determine item eligibility.	6	Greater than 0.
IF_MIN_SEASON_WEEKS
Minimum sales units. The total number of units sold must be at least this value.	10	Greater than 0.
IF_MIN_SALES_UNITS
Fraction of eligible weeks. The percentage of eligible weeks, expressed as a fraction of the season length. The season length is the number of weeks between the start and end dates. (See Life cycle sell thru % above.)	0.6	Greater than 0.0; less than or equal to 1.0.
IF_FRACTION_ELIGIBLE_WEEK

Elasticity

The Elasticity stage determines the promotion and markdown elasticity values at the selected levels in the merchandise and location hierarchy. For a given merchandise and location hierarchy level, this stage also determines the elasticity value by customer segment. You can modify the configuration settings for the elasticity stage using the Manage Forecast Configurations functionality under Strategy & Policy Management.

In this stage, parameters must be set for

Additional data filtering to reduce the noise in the elasticity estimation
Merchandise and location hierarchy levels for which parameters are estimated
Identifying markdowns weeks
Identifying promotion weeks
Reliability thresholds for elasticity estimation
Transformation of elasticity values

Data Filters Weekly

Additional data filters are applied during the estimation of elasticity. These filters are used to reduce the noise from very deep price cuts or price cuts towards the end of life. An option is also available to the limit the data used for elasticity estimation.

Time window defines the weeks before and after the markdown. The preceding weeks value is the number of weeks before the markdown occurred. The following weeks value is the number of weeks after the markdown and includes the week of the markdown. A week is a calendar week. A time window that satisfies all the markdown parameter settings is classified as a markdown window.

Minimum eligible weeks is the minimum of the actual number of weeks in the Time Window that have data. The Time Window is in calendar weeks, and not every calendar week actually has sales data. So the actual number of weeks with data that are within the Time Window can actually be smaller than the Time Window.

Maximum deviation is the deviation of the sales price in the weeks before and after the markdown. Provides stability on the variance.

Min Markdown depth is the drop in average sales price from preceding weeks to the following weeks is higher than this threshold value. Markdown depth = 1- (Avg Price following weeks/Avg Price preceding weeks). In other words, this parameter controls how much of a price decrease is required in order for the price decrease to count as a markdown.

Table 13-11 Markdown Parameters

Name and Description	Default Value	Range of Values
Time Window	Preceding: 2	1–3
MKDN_TIMEWINDOW_PRECEEDING and MKDN_TIMEWINDOW_FOLLOWING	Following: 2	1–3
Eligible Weeks	Preceding: 2	1–3
MKDN_ELIGWKS_PREC and MKDN_ELIGWKS_FOLL	Following: 2	1–3
Maximum Deviation	Preceding: 0.1	0–1
MKDN_MAXDVT_PRECEEDING and MKDN_MAXDVT_FOLLOWING	Following: 0.1	0–1
Min Markdown Depth	0.1	0–1
MKDN_MINMKDN_DEPTH
Use Ticket Price: Both Ticket price and sales price values from the preceding and following weeks satisfy min markdown depth criteria. USE_TICKET_PRICE	N	Y/N

Promotion One Week

For identifying promotions, a few additional parameters are defined below in addition to Time window, Eligible weeks, and maximum deviation, which are defined above.

~~ee)~~

Table 13-13 Promotion Two Weeks

Name and Description	Default Value	Range of Values
Time Window	Preceding: 1	1–3
PRWK2_TIMEWINDOW_PRECEEDING,	Following: 1	1–3
PRWK2_TIMEWINDOW_FOLLOWING and PRWK2_TIMEWINDOW_PROMOWEEKS	Promo Duration: 2	2
Eligible Weeks	Preceding: 1	1–3
PRWK2_ELIGWKS_PREC and PRWK2_ELIGWKS_FOLL	Following: 1	1–3
Maximum Deviation	Preceding: 0.1	0–1
PRWK2_MAXDVT_PRECEEDING,	Following: 0.1	0–1
PRWK2_MAXDVT_FOLLOWING and PRWK2_MAXDVT_PRECFOLLOW	Preceding/Following: 0.1	0–1
Min Promotion Depth	0.1	0–1
PRWK2_MINPROMO_DEPTH

Reliability Settings

Determine the partitions with reliable elasticity values.

Table 13-14 Reliability Settings

Name and Description	Default Value	Range of Values
Outlier threshold. Percentile threshold for removing outlier data points from elasticity estimation. Eg., Threshold is set to X%, Top X Percentile and Bottom X percentile sales ratio and price ratio data points are excluded from elasticity estimation.	0.05	0–0.05
RS_OUTLIER_THRESHOLD
Eligible items threshold - Elasticity	25	Greater than 1.
RS_ELIGIBLEITEMS_THRESHOLD
Std. Error threshold	0.3	0–1
RS_STDERROR_THRESHOLD

Transformation

Transform the elasticity values obtained after the pruning based on reliability to cap the very low or very high elasticity values. The transformation settings also enable the user to shift the elasticity values to a desired range.

Table 13-15 Transformation

Name and Description	Default Value	Range of Values
Transform Percentile - Low	0.1	0–1
TRANSPERCENTILE_LOW
Transform Percentile - High	0.9	0–1
TRANSPERCENTILE_HIGH

Table 13-15 (Cont.) Transformation

Name and Description	Default Value	Range of Values
Elasticity range - Min: Select a value closer to the transform percentile - Low and higher than 1.2 ELASTICITYRANGE_MIN	1.3	Greater than 1.
Elasticity range - Max: Select a value closer to the transform percentile - high.	2.8	Greater than elasticity range–min.
ELASTICITYRANGE_MAX

Seasonality

The Seasonality stage determines the seasonality values at the selected levels in the merchandise and location hierarchy. For a given merchandise and location hierarchy level, this stage also determines the seasonality value by customer segment. You can modify the configuration settings for the seasonality stage using the Manage Forecast Configuration functionality under Strategy & Policy Management.

In this stage, parameters must be set for

Seasonality curve set up
Reliability filters

Seasonality Curve Setup.

The Seasonality Curve Setup stage determines the season codes used for building seasonality curves, length of the seasonality curve, item count threshold, padding curve weight, and seasonality coverage of the final curves.

Season codes create additional partitioning in the dataset by introducing a time dimension. This stage can be used to partition seasonality curves by fiscal start month, fiscal start week, for example, Partition the Class-Store cluster-Customer segment data based on the merchandise time of introduction. Group merchandise based on the fiscal month of the start date. This ensures items starting in the same month receive the same season code. Weekly curves are useful for modeling short life cycle merchandise, while monthly curves are useful for medium to long life cycle curves.

Length of the seasonality curve: Seasonality curves are generated for 52 weeks. They can also be generated for longer duration if the merchandise life cycle length is longer. This also increases the duration of historical data required to prepare the seasonality curves.

Actual sales for a given merchandise-location-customer segment-Start month can be present for less than 52 weeks. To generate a curve for the entire 52 weeks duration, a padding curve is used.

Padding curve: The padding seasonality curve is determined by creating a basic curve for the highest merchandise/location partition. The final seasonality curve is calculated as weight * padding curve + (1 - weight) * seasonality curve.

Table 13-16 Seasonality Curve Setup

Name and Description	Default Value	Range of Values
Curve Type. Determines the duration of time partition based on fiscal week or fiscal month. CURVE_TYPE	Monthly	Monthly or Weekly
Basic Curve. Basic curves are generated by ignoring the partitioning on time dimension for a given merchandise-location-customer segment partition.	Y	True or FalseY/N
BASIC_CURVE
Seasonality curve length. Determines the length of the final seasonality curves for regular (non-basic) season codes. The length from the start determines how many weeks after the start date are in the curve. SEASON_CURVE_LENGTH	52	Greater than or equal to 6.
Eligible items threshold. The minimum number of items that a Merchandise Hierarchy/Location Hierarchy/Customer Segment/Season Code partition must contain so that Raw-AP can produce a seasonality curve for the partition. ELIGIBLE_ITEM_THRESHOLD	5	Greater than or equal to 1.
Padding curve weight. The value used in determining the final seasonality curve. PADDING_CURVE_WEIGHT	0.4	Greater than 0.0; less than 1.0.
Basic curve start week. First week of the basic curve. This is represented as number of weeks from the most recent week with data. Should be greater than 52 and less than number of weeks of historical data.	57	52 - 80
Seasonality Coverage. First Fiscal year SEASON_COVERAGE_FIRST_FY	Latest fiscal year with historical data	Greater than or equal to 2020
Seasonality coverage. Last fiscal year SEASON_COVERAGE_LAST_FY	Latest fiscal year with historical data + 2.	Greater than or equal to 2020.

Reliability Filters

The filters in this stage are used to identify reliable seasonality curves based on the number of items in the partition, average sales volume, and season length threshold.

Table 13-17 Reliability Filters

Name and Description	Default Value	Range of Values
Keep top level curves. All the highest level curves are kept, regardless of threshold values.	Y	Y/N
KEEP_TOP_LEVEL_CURVES
Prune curves with missing dates. Pruning of basic curves with missing dates is permitted.	Y	Y/N
PRUNE_CURVES_MISSING_DATES

Table 13-17 (Cont.) Reliability Filters

Name and Description Default Value Range of Values Eligible items threshold. Partitions with fewer 5 Greater than or equal to numbers of eligible items than the threshold value 0.0. are removed. Eligibility is defined during preprocessing. Average weekly sales threshold. Partitions with 25 Greater than or equal to average weekly sales below the threshold are o. removed. Weekly sales are the sum of all sales for all activities for a given week. AVG_WK_SALES_THRESHOLD Raw seasonality length threshold. Curves can be 10 Greater than or equal to discarded when the number of weeks from the first 0. non-zero seasonality value to the last non-zero seasonality value is less than the threshold. In the seasonality stage, it is possible that many seasonality values of zero have been added to the curves. Note that basic season codes have a length of 53, so picking a value greater than 53 will prune out any basic season codes. Seasonality curves before padding are referred to as raw seasonality curves. RAW_SEASONALITY_LEN_THRESHOLD

Promotion

The promotion stage determines the traffic lift value associated with promotions and holiday events at the selected levels in the merchandise and location hierarchy. For a given merchandise and location hierarchy level, this stage also determines the promotion lift value by customer segment. A list of holidays and promotions, along with event start date and end date, is sent as a data feed.

In this stage, parameters must be set for determining the baseline to be used for estimation of lift values, Outlier threshold, min lift value. and max lift value. You can modify the configuration settings for the promotion stage using the Manage Forecast Configurations functionality under Strategy & Policy Management.

Table 13-18 Promotion

Name and Description	Default Value	Range of Values
Baseline. The baseline type determines how to smooth the seasonality curve. If you select the linear option, parameter estimation looks at event effective start date and event effective end date and draws a straight line between them. Effective start date is the weekend prior to the event start date and effective end date is the second weekend after the event end date.	Linear	Linear, Min, or Max.
PROM_LIFT_BASELINE_TYPE
Outlier percentile. Very high lift values are flagged.	0.05	0–1
PROM_LIFT_OUTLIER_PERCENTILE

Table 13-18 (Cont.) Promotion

Name and Description	Default Value	Range of Values
Lift value -High. Lift values flagged as outliers are capped to outlier percentile lift value.	Y	Y/N
PROM_LIFT_HIGH
Lift value-min. Sets the threshold for min lift value. Any promotions with lift value lower than this threshold are not assigned any lift value.	1.05	Greater than or equal to 1.
PROM_LIFT_MIN_VALUE

Output and Review of Parameters

The Propagation and Parameter Export to Target stages do not have separate settings. The Propagation stage populates the seasonality curves for all the years from the Seasonality coverage first fiscal year to the Seasonality coverage last fiscal year.

The Parameter Export to Target stage populates the parameters at the lowest level of estimation selected in the appropriate output tables. LPO typically expects the parameters at the lowest level of estimation. For example, LPO expects the demand parameters at ClassStore cluster level. Use escalation to fill in the parameters missing at Class-Store level. The Output stage escalates on location hierarchy first and then on merchandise hierarchy.

Run the parameter estimation by starting the batch process during the implementation phase. Details on the batch processing are covered in “Batch Processing”. Perform the following checks after each stage in the parameter estimation is complete.

Elasticity (pmo_elasticity_parameters)

Histogram of elasticity values, promotion vs. markdown: Distribution of elasticity values follows the expected trend. Typically follow a normal distribution around the median elasticity value.
Elasticity escalation: Percentage of partitions receiving elasticity values from higher level.

Seasonality (pmo_seasonality_parameters; pmo_seasonality_curve_tbl)

Review number of partitions impacted by reliability filters:
Visually check the top-level seasonality curves
Seasonality escalation: Percentage of partitions receiving elasticity values from higher levels.

Promotion lift (pmo_promtion_lift)

Plot histogram of promotion lift values by event and compare across segments.

Day Level and Returns Metrics

This section covers the settings used for determining day of the week profiles, time of the day profiles, return rate, and average time to return.

Day of the Week Profiles

Day of the week profiles determine the relative sales strength across various days in a given week. These profiles are used to spread the forecasted demand to the day level. In order to

capture the variation across merchandise, location, segment, and calendar dimension, the configuration on each of the four dimensions is supported. In the current version, you can choose two configurable levels for estimating day of the week profiles. Level 1 corresponds to the estimation level at which profiles are calculated, and Level 2 profiles correspond to the escalated profiles. They are only used when profiles are not available at the estimation level.

Table 13-19 Day of the Week Profiles

Name and Description	Default Value	Range of Values
Merchandise level. ID corresponding to the merchandise level at which day of the week profiles are calculated. Usually at DEPARTMENT or higher. RSE_PMO_DLYPROF_MH_LVL_SQC1	4	1 - 9
Location level. ID corresponding to the location level at which day of the week profiles are calculated. Usually STORE CLUSTER or higher. RSE_PMO_DLYPROF_LH_LVL_SQC1	4	1 - 6
Merchandise level. Merchandise level - Escalated: ID corresponding to the higher merchandise level at which day of the week profiles are calculated. Usually at Division or higher. RSE_PMO_DLYPROF_MH_LVL_SQC2	3	1 - 3
Location level. Location level - Escalated: ID corresponding to the higher location level at which day of the week profiles are calculated. Usually Region or higher. RSE_PMO_DLYPROF_LH_LVL_SQC2	3	1 - 3
Min week. Calendar hierarchy ID corresponding to the oldest week used for day of the week profile calculation. PMO_DLYPROF_MIN_WK	User determined
Max Week. Calendar hierarchy id corresponding to the latest week used for day of the week profile calculation.PMO_DLYPROF_MAX_WK	User determined
Week count threshold. Partitions with data for less than the week count threshold are excluded from day of the week profile calculation. PMO_DLYPROF_WK_CNT_THLD	2	> 1
Sales threshold. Total sales from the merchandise, location, segment and calendar partition must be higher than this threshold value for the partition to be eligible for estimation of day of the week profile. PMO_DLYPROF_TOT_SLS_THLD	1000	Greater than 100.
Output level - Merchandise. Day of the week profiles are generated at this merchandise level for export. Any missing levels are filled using the higher level profiles.	4	1 - 9
Output level - Location. Merchandise: Day of the week profiles are generated at this location level for export. Any missing levels are filled using the higher level profiles.	4	1 - 6

Returns Metrics

For returns parameter estimation, the data is divided into two parts, one for building the model and the other for testing the model. Usually, one full year is used to build the model, and at least 13 weeks are used for testing the model. The most recent data corresponding to the build and test durations is used for returns modeling from the available data. Returns are modeled at various locations in the merchandise hierarchy, typically, Class, Department, and Division. For each of the merchandise levels, modeling is done for both customer segment and segment all levels on the customer segment dimension and at the data aggregation level on the location dimension. After applying the reliability filters, the missing parameters at the lowest merchandise level - location: data aggregation level - customer segment level are filled by escalation.

The return rate is estimated at the data aggregation level for the Merchandise-LocationCustomer Segment level every week. This information, along with the returns parameters and sales forecast, is used to generate the returns forecast.

Table 13-20 Returns Metrics

Name and Description	Default Value	Range of Values
Merchandise level 1. The topmost merchandise level used for returns parameters. Typically Division or Banner. Choose the merchandise hierarchy ID corresponding to this level. PMO_RETURN_PART_MH_LVL1	2	1 - 6
Merchandise level 2. The intermediate merchandise level used for returns parameters. Typically Department. Choose the merchandise hierarchy ID corresponding to this level.PMO_RETURN_PART_MH_LVL2	4	1 - 6
Customer segment level 1 Merchandise level 2. The lowest merchandise level used for returns parameters. Typically Class. Choose the merchandise hierarchy ID corresponding to this level.PMO_RETURN_PART_MH_LVL3	5	1 - 6
Duration of data for Build. Number of weeks of data to be used for building the model. PMO_RETURN_BUILD_MODEL_WKS	52	52 - 80
Duration of data for Test: Number of weeks of data to be used for testing the model. Most recent weeks are used for testing the model. PMO_RETURN_TEST_MODEL_WKS	13	13 - 26
Sales threshold. Merchandise-Location-Customer segment partitions with total sales lower than the threshold are excluded from returns parameter estimation. PMO_RETURN_LOW_SALES_THRESHOLD	10	> 10
Model fit threshold. Merchandise-Location- Customer segment partitions with adjusted r square value lower than the threshold are pruned. This eliminates partitions where the model fit is poor. PMO_RETURN_RELIABLE_ADJST_R_SQR_THS LD	0.5	> 0.3

Table 13-20 (Cont.) Returns Metrics

Name and Description	Default Value	Range of Values
Data sufficiency threshold. Row count:	500	>100
Merchandise-Location-Customer segment partitions: Total with data less than the row count threshold are excluded from returns parameter estimation.
PMO_RETURN_RELIABLE_ROW_COUNT_THSL D

Demand Forecasting

The following multiplicative demand model is used as follows:

Demand = Base demand* Seasonality Price effect Promotion Traffic LiftStore count Other Effects

Base demand is updated in season every week at the Optimization recommendation level, for example, Style Color-Store cluster-Customer segment level. Demand forecasting leverages the parameters estimated from historical data and in-season sales data to generate a demand forecast. Elasticity for determining price effect is assigned using merchandise and location hierarchy. For assigning seasonality curve and promotion lift, the start date is required to determine the right partition on time dimension in addition to merchandise and location hierarchy. Demand forecasting set up involves configuration for start date and demand strategy.

Demand forecasting stage leverages the parameters estimated from historical data and inseason sales data to generate a demand forecast. Demand forecast values along with historical parameters are sent to LPO for generating optimal price recommendations and targeted offers.

In this stage, the following parameters must be set by the user to determine the model start date, season code and demand model settings. For all the parameters prefixed with RSE, you can modify the values in the RSE_CONFIG table using Manage System Configurations. For other parameters, use the Manage Forecast Configurations functionality under Strategy & Policy Management to modify parameters for Base Demand estimation.

Note that the merchandise/location/calendar hierarchy types do not need to be set for base demand separately, as they will be the same as the values set for PMO_PROD_HIER_TYPE, PMO_LOC_HIER_TYPE, and PMO_FISCAL_CAL_HIER_TYPE. In addition, the merchandise/ location/calendar levels for base demand estimation do not need to be set separately, as they will be the same as the aggregation levels that are selected when creating a run type (AGGR_PROD_HIER_LEVEL, AGGR_LOC_HIER_LEVEL, and AGGR_CAL_HIER_LEVEL).

Table 13-21 Demand Forecasting

Name and Description	Default Value	Range of Values
Merchandise level -Store Weights. The	6	1 - 9
merchandise level at which store weights are calculated. Choose the ID corresponding to the merchandise level, typically at Sub
Class.RSE_BD_SW_PROD_HIER_LEVEL

Table 13-21 (Cont.) Demand Forecasting

Name and Description	Default Value	Range of Values
Start date - sell thru %. The earliest week ending date when a Style-Color - Store Cluster combination (data aggregation level used for generating forecast and price recommendations) achieves 2% sell thru is used to determine its start date. The start date is used to determine the seasonality curve assigned to a style color - store cluster combination.	2%	0%–5%
OPTPARAM_PCT_SLS_THRESHOLD
Start date - max weeks from first sale. After the first sale date if the 2% sell thru is not achieved before this threshold then first sale date + max weeks from first sale is used to define the start date. OPTPARAM_WEEK_LIMIT	3	1–5
Seasonality - Max weeks from start. This setting is used to switch from a fashion curve to a basic curve if an item lives longer than expected. OPTPARAM_SEAS_CURVE_THRESHOLD	42	Greater than 35.
Demand Interval. Number of in-season weeks to be used for demand forecast-ing.0 implies the use of entire history from current season to generate the demand forecast.	4	0–6
BD_PERIOD_LEN
Demand Interval - Poisson. Number of in-season weeks to be used for demand forecasting using Poisson demand strategy.0 implies use entire history from current season to generate the demand forecast. BD_POISSON_WKS	0	0 - 6
Alpha: Poisson. Smoothing parameter used for Poisson demand strategy. This parameter determines how quickly the weights decay for past weeks in-season data. BD_POISSON_PARAM	0.5	0–1
Demand Interval - Log Linear. Number of in-season weeks to be used for demand forecasting using Log linear demand strategy.0 implies use entire history from current season to generate the demand forecast. BD_EST_LOG_LINEAR	4	0 - 6
Alpha - Log Linear. Smoothing parameter used for Log Linear demand strategy. This parameter determines how quickly the weights decay for past weeks in-season data. BD_LOG_LINEAR_PARAM	0.7	0 - 1
Base demand - Sales units Threshold. Threshold used for determining the base demand strategy to use for an item. Items with sales lower than the threshold will use Poisson demand strategy other item will use log linear demand strategy. BD_LL_SLS_THRESH_QTY	20	15 - 30
Base demand - weeks used for Threshold. Number of weeks of data used for calculating the Base demand - Sales units threshold.BD_AE_SLS_LEN_WKS	4	1 - 5

Table 13-21 (Cont.) Demand Forecasting

Name and Description	Default Value	Range of Values
Store weights - Duration of data. Number of weeks	13	13 - 52
of data used for calculation of store
weights.BD_SW_SLS_LEN_WKS

New Stores

Retailers regularly open or close stores in different markets. The base demand forecasting process above accounts for stores that are operational. However, sometimes, retailers plan for new stores and would like the forecasting process to account for the additional increase (or decrease) in demand that will be generated due to the planned store opening (or closure). For example, a retailer might be planning to open a new store ten weeks in the future and would like to account for this in the demand forecasting process. LPO provides this functionality in which the retailer must provide a like store through the RSE_LIKE_LOC_STG interface. Once this mapping is provided, the LPO forecasting module adjusts the demand accordingly and the optimization considers the additional increase (or decrease) in demand for the new store (or closed store). Once the new store is operational, the sister store sales potential is discarded and it switches to the store’s base demand forecasting process. This functionality helps retailers appropriately forecast demand based on planned store openings or closures. The following two examples illustrate the functionality.

Example 1: Sales at the Beginning of Week 2

Table 13-22 Sales at the Beginning of Week 2

Store	Week 1	Week 2	Week 3	Week 4	Week 5	Total Season
Store 1	100	120	100	120	100	540
Store 2	100	120	100	120	100	540
Store 3			Opens	50	80	180
			50
Store 4		Opens 40	50	60	80	230
Total Sales	200	280	300	350	360	1490

Example 2: Sales at the Beginning of Week 4

Table 13-23 Sales at the Beginning of Week 4

Store	Week 1	Week 2	Week 3	Week 4	Week 5	Total Season
Store 1	150	150	140	140	140	720
Store 2	100	120	100	120	100	540
Store 3			Opened	100	160	360
			100

Table 13-23 (Cont.) Sales at the Beginning of Week 4

Store	Week 1	Week 2	Week 3	Week 4	Week 5	Total
						Season
Store 4		Opened	50	60	80	230
		40
Total Sales	250	310	390	420	480	1810

Optimization Science

This section describes the business rules that are available and the science behind the optimization algorithms used in the LPO application. It does not provide all the details of the algorithm. However, it does provide some guidance so that you can troubleshoot and resolve issues quickly during an implementation.

Business Rules

The implementation ofLPO is determined by a retailer’s individual business requirements. A complete and accurate configuration of business rules is essential to the accuracy and success of the recommendations and forecasts.

Some of the business requirements or rules include:

The retailer’s pricing strategy for promotions, markdowns, and targeted offers. Does the retailer want to maximize the revenue or profit margin?
The level of the merchandise hierarchy and of the location hierarchy at which the sales data will be provided.
The day of the week that markdowns are effective. Typical start and end date for promotions during a week.
Whether markdowns are effective on the same day or different days for all departments.
Whether promotions, budget, and distribution center data will be included in the data feed.
How eligible items (items to be processed by LPO in a given week) are defined (for example, if an item exists in the most recent sales data feed and has a threshold number of units on hand).
The kinds of inventory that must be considered by the batch process for optimization.

It is essential that considerable time be spent on understanding the business rules so that the global defaults can be populated in RSE_CONFIG with APPL_CODE =‘PRO’ and so most of the departments will not require further tweaking of the batch runs or for ad hoc runs. The configuration that must be created in conjunction with the business requirements are:

Table 13-24 Business Rules

PARAM_NAME	PARAM_VALUE	DESCR
DEFAULT_APPL_USER	OO_BATCH_USR	User identifier to be used for batch activities that require user tracking.

Table 13-24 (Cont.) Business Rules

PARAM_NAME	PARAM_VALUE	DESCR
PRO_PROD_HIER_TYPE	3	The hierarchy ID to use for the product (Installation configuration).
PRO_LOC_HIER_TYPE	2	The hierarchy ID to use for the location (Installation configuration).
PRO_CAL_HIER_TYPE	11	The hierarchy ID to use for the calendar (Installation configuration).
PRO_CUSTSEG_HIER_TYPE	4	The hierarchy ID to use for the customer segments (Installation configuration).
PRO_CAL_HIER_PROCESSING _LVL	4	The calendar hierarchy level at which PRO will define RUNs for optimization.
PRO_PROD_HIER_RUN_SETU P_LVL	4	The merchandise hierarchy level at which PRO will setup/create RUNs.
PRO_PROD_HIER_PROCESSIN G_LVL	5	The merchandise hierarchy level at which PRO will optimize RUNs.
PRO_LOC_HIER_PROCESSING _LVL	2	The location hierarchy level at which PRO will define RUNs for optimization.
PRO_CUST_HIER_PROCESSIN G_LVL	2	Default customer segment level at which PRO will define RUNs for optimization.
PRO_OPT_LOC_REC_LVL	2	Default location level at which price recommendations will be generated.
PRO_OPT_CUST_REC_LVL	1	Default customer segment level at which price recommendations will be generated (whole population).
PRO_OPT_TIME_REC_LVL	4	Default calendar level at which price recommendations will be generated (week).
PRO_OPT_MERCH_REC_LVL	9	Default merchandise level at which price recommendations will be generated (STYLE-COLOR).
PRO_OPT_MECH_REC	NONE	Default targeted offer mechanics for which price recommendations will be generated.
PRO_OPT_MKTG_REC	NONE	Default targeted offer marketing aspect for which price recommendations will be generated.
PRO_SALVAGE_VALUE	0	Salvage value is the value of the product after the season ends. default value is 0.

Table 13-24 (Cont.) Business Rules

PARAM_NAME	PARAM_VALUE	DESCR
PRO_TR_NO_TOUCH_AFTER_ LANDING	0	Default no touch after landing (2 weeks).
PRO_TR_LENGTH_OF_PROMO TIONS	0.6	Default length of promotion as a percentage of the whole season.
PRO_TR_MAX_LENGTH_OF_P ROMOTION	1	Default maximum length (weeks) of a promotion.
PRO_TR_LENGTH_OF_MKDN	0.4	Default length of markdown as a percentage of the whole season.
PRO_TR_NO_TOUCH_END_LIF E	0	Default no touch at the end of life (1.5 weeks).
PRO_PR_FIRST_PROMO_MIN_ DISC_PCT	0	Default minimum discount percentage for the first promotion.
PRO_PR_FIRST_PROMO_MAX _DISC_PCT	1	Default maximum discount percentage for the first promotion.
PRO_PR_OTHER_PROMO_MIN _DISC_PCT	0	Default minimum discount percentage for promotions other than the first one.
PRO_PR_OTHER_PROMO_MA X_DISC_PCT	1	Default maximum discount percentage for promotions other than the first one.
PRO_PR_MIN_TIME_BETWEEN _PROMOS	1	Default minimum time separation between any two consecutive promotions (1 week).
PRO_PR_PROMO_START_DAY	MONDAY	Day of the week promotions start
PRO_PR_PROMO_END_DAY	SUNDAY	Day of the week promotions end
PRO_PR_DAY1_WGT	0.14	Promotion weight for day 1 of the week
PRO_PR_DAY2_WGT	0.14	Promotion weight for day 2 of the week
PRO_PR_DAY3_WGT	0.14	Promotion weight for day 3 of the week
PRO_PR_DAY4_WGT	0.14	Promotion weight for day 4 of the week
PRO_PR_DAY5_WGT	0.14	Promotion weight for day 5 of the week
PRO_PR_DAY6_WGT	0.15	Promotion weight for day 6 of the week
PRO_PR_DAY7_WGT	0.15	Promotion weight for day 7 of the week
PRO_MR_FIRST_MKDN_MIN_D ISC_PCT	0	Default minimum discount percentage for the first markdown.
PRO_MR_FIRST_MKDN_MAX_ DISC_PCT	1	Default maximum discount percentage for the first markdown.

Table 13-24 (Cont.) Business Rules

PARAM_NAME	PARAM_VALUE	DESCR
PRO_MR_OTHER_MKDN_MIN_ DISC_PCT	0	Default minimum discount percentage for markdowns other than the first one.
PRO_MR_OTHER_MKDN_MAX _DISC_PCT	1	Default maximum discount percentage for markdowns other than the first one.
PRO_MR_MIN_TIME_BETWEE N_MKDN	1	Default minimum time separation between any two consecutive markdowns (1 week).
PRO_MR_MKDN_START_DAY	MONDAY	Day of the week markdown start
PRO_MR_MKDN_END_DAY	SUNDAY	Day of the week markdown end
PRO_MR_DAY1_WGT	0.14	Markdown weight for day 1 of the week
PRO_MR_DAY2_WGT	0.14	Markdown weight for day 2 of the week
PRO_MR_DAY3_WGT	0.14	Markdown weight for day 3 of the week
PRO_MR_DAY4_WGT	0.14	Markdown weight for day 4 of the week
PRO_MR_DAY5_WGT	0.14	Markdown weight for day 5 of the week
PRO_MR_DAY6_WGT	0.15	Markdown weight for day 6 of the week
PRO_MR_DAY7_WGT	0.15	Markdown weight for day 7 of the week
PRO_ST_END_REGULAR_SEA SON	0.15	Default percentage of sell- through for each individual product at end of regular periods.
PRO_ST_END_CLEARANCE_S EASON	0.85	Default percentage of sell- through for each individual product at end of clearance season.
PRO_ST_TGT_TYPE	HARD	Default sell-through target type for each individual product.
PRO_ST_HARD_TGT_FLG	Y	Default value for sell-through hard target flag.
PRO_DFLT_RETURN_PCT	0.01	Default percentage of sales returned.
PRO_DFLT_RETURN_LEAD_TI ME	2	Default return lead time in weeks (time when the return happens after the purchase is made).
PRO_PR_MIN_COST	Y	Promotions recommendations cannot be lower than the cost of the product.
PRO_MR_MIN_COST	Y	Markdown recommendations cannot be lower than the cost of the product.

Table 13-24 (Cont.) Business Rules

PARAM_NAME	PARAM_VALUE	DESCR
PRO_BASE_INITIAL_BUDGET	9999999	Initial Budget for Base Scenarios.
PRO_SEAS_CURVE_WEEKS_S WITCH	42	Seasonality Curve.
PRO_OFFERMAX	3	Maximum number of offers for segment in a given time period.
PRO_LOWRR	0.20	threshold value used to pick at least one low redemption rate offer for a segment and given time period.
PRO_HIGHRR	0.80	High Redemption Rate. This is a threshold value used to pick at least one high redemption offer for a given segment and given time period.
PRO_MAX_OFFERS_PER_SEG MENT	3	This is the number of top offers that will be selected per customer_segment/class.
PRO_INV_QTY_BOH	Y	Specifies if the inventory on hand must be included into the total inventory.
PRO_INV_QTY_ON_ORD	Y	Specifies if the inventory on order must be included into the total inventory.
PRO_INV_QTY_IN_TRANSIT	Y	Specifies if the inventory in transit must be included into the total inventory.
PRO_USE_ABSOLUTE_CAL_FL G	Y	Y/N Indicator. Identifies if the absolute calendar must be used for Temporal Rules.
PRO_USE_LIFECYCLE_FATIGU E	N	Y/N Indicator. Identifies if the life cycle fatigue must be enabled or not.

Optimization Algorithm Overview

The optimization algorithm analyzes trade-offs between a set of available price paths and picks the best price path. It then informs the user when to promote, how deep to promote, when to mark down, how deep to mark down, when to provide a targeted offer, and how deep the targeted offer must be. Note that the Targeted Offers are aligned to be in the same period when the promotion occurs.

The algorithm uses sophisticated mathematical modeling techniques to analyze all possible solutions to generate the best possible solution. The optimization algorithm is provided an objective (for example, maximize total revenue over all items in the season), business rules or restrictions, and the demand parameters for a particular item. The algorithm analyzes the trade-offs between all possible solutions (see Figure 13-6) and picks the solution that provides the best value for the objective. All the restrictions imposed by the user are treated as required; that is, all possible solutions must satisfy that particular criterion. The only constraint that can be enforced as soft is the sell-through target constraint. The user can make this constraint soft,

Constraints

If the objective function focuses on the best possible solution, then constraints work in the opposite direction, by restricting the set of possible solutions. For example, if the objective function says to select the most profitable discount for an item A, a constraint on item A may say it is not possible to have more than certain discount percentage.

Optimization enforces all constraints as required; that is, it finds all the solutions that satisfy all the constraints that are specified by the user. Sometimes, inadvertently, the user might specify conflicting constraints that can result in no solution or unexpected solutions. Often, a resolution can be found by just understanding the implications of individual constraints. More often than not, the user must analyze the interplay between two or more constraints to understand the solution. PRO_RUN_SANITY_CHECK_RSE_VW contains information on the errors/alerts/ warnings generated.

LPO supports a variety of constraints, and it is essential for the user to understand the purpose and role of each constraint in the optimization.

In this guide

Guide: AI Foundation Implementation Guide
Previous: 12 Pre-Pack Optimization
Next: 14 Control and Tactical Center

14 Control and Tactical Center — AI Foundation Implementation Guide · shares APPL_CODE, BASE_COST_AMT_LCL, DOC_CURR_CODE, INV_IN_TRAN_QTY
15 Inventory Planning Optimization — AI Foundation Implementation Guide · shares FLEX_ATTRIB_10_CHAR, FLEX_ATTRIB_2_CHAR, FLEX_ATTRIB_3_CHAR, FLEX_ATTRIB_4_CHAR
B Appendix: Promotion and Markdown - Pricing Optimization Rules — Lifecycle Pricing Optimization User Guide · shares PRO_MR_FIRST_MKDN_MAX_DISC_PCT, PRO_MR_MIN_COST, PRO_MR_MIN_TIME_BETWEEN_MKDN, PRO_MR_MKDN_START_DAY
Markdown - What-If Run — Lifecycle Pricing Optimization User Guide · shares DEFAULT_SET, PRO_OPTIMIZATION_RULES_STG, PRO_PROD_HIER_PROCESSING_LVL, PRO_SEASON_PERIOD_STG
2 AI Foundation Data Standalone Processes — AI Foundation Operations Guide · shares C_ODI_PARAM, INV_SOH_QTY, LAST_INVRC_DT, RAF_FILTER_GROUP_MERCH
6 Metrics — Retail Insights Cloud Service User Guide · shares C_ODI_PARAM, PMO_ACTIVITIES, W_RTL_PLAN1_PROD1_LC1_T1_FS

Oracle Retail Knowledge Base

Explorer

13 LifeCycle Pricing Optimization

13 LifeCycle Pricing Optimization

Overview

Project Planning

Functional

Data Interfaces

Forecasting Parameters

Optimization

Walkthrough

RAP foundation data (CSV and W_ interfaces)

AIF applications foundation data (RSE_% tables)

Direct loads to AIF applications

Forecasting

Optimization

Manage LPO Recommendations

Batch

Security

Data Filtering

User Roles

Data Input Requirements

Hierarchy Data

Inventory Data

Price History Data

Retail Code

Retail Sales Data

Promotions

Warehouse Inventory Allocation

Competitor Prices

Product Attributes

Product Images Data

Season

Season Periods

Season Products

Price Ladder

Currency

Holidays

Pricing Product Groups

Budget

Strategy and Business Rules

Custom Columns

External Forecast Adjustment

Configuration and Expected Levels for Interfaces

Optional* Interfaces

Integration with Retail Pricing Cloud Service

POM Jobs

Forecasting Science

Parameter Estimation

Overview of the Parameter Estimation Stages

Data Preparation

Data Aggregation

Table 13-6 Data Aggregation

Promotion Data Processing Level

Data Validation

Preprocessing

Data Filters Week Level

Table 13-8 Data Filters Week Level

Partition Filters

Elasticity

Data Filters Weekly

Promotion One Week

Reliability Settings

Transformation

Seasonality

Seasonality Curve Setup.

Reliability Filters

Promotion

Output and Review of Parameters

Day Level and Returns Metrics

Day of the Week Profiles

Returns Metrics

Demand Forecasting

New Stores

Optimization Science

Business Rules

Table 13-24 (Cont.) Business Rules

Table 13-24 (Cont.) Business Rules

Optimization Algorithm Overview

Constraints