Oracle Retail AI Foundation Cloud Services Implementation Guide Release 22.2.301.0 F59895-02 |
|
![]() Previous |
![]() Next |
This chapter describes the Promotion and Markdown Optimization and Offer Optimization Cloud Services. In general, throughout the document the term "Offer Optimization" is used to refer to these two combined services. However, when a specific functionality is only available in one of these services, the complete service name is used.
Offer Optimization (OO) 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)? Promotion and Markdown Optimization caters to the retailers who are interested in only promotions and markdowns. Offer Optimization not only provides promotions and markdowns but also 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 12-1 shows the conceptual flow of different components in Offer Optimization. Oracle Retail AI Foundation Platform Cloud Service and Retail Insights Cloud Service Suite is the core data foundation layer that consumes the retailer data. Offer Optimization 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 RI. The algorithm analyzes the feasible price paths efficiently and generates price recommendations. These recommendations can be viewed in the Offer Optimization 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 OO 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. OO 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 recommendations will be sent to an export interface as well as to a price execution system such as RPM with the respective statuses.
An optimization can be carried out at the configured processing (or run) location or the price-zone, merchandise level, and calendar level. The user can configure the optimization to use either the price-zone or a node in the location hierarchy (but not both in the same instance). Once the optimization is complete, the recommendations can be generated at a lower level than the processing level (called recommendation levels for merchandise level and location or price-zone level). The location and merchandise level can be any level in the location hierarchy and merchandise hierarchy, respectively. Alternatively, price-zone can be used to define a set of stores (and/or online locations) and items. An example of a price zone is women's apparel in all university-based stores grouped into one price-zone. The usual levels for the run are Region or Price-zone, Department, and Week, and for the recommendation, the levels are Region or Price-zone and Style/Color or SKU (Style/Color/Size). If Targeted Offers is available, then the recommendations will also be generated at the Customer-Segment level, along with location or price-zone and merchandise level. The Promotions and Markdowns are always at the location or price-zone and merchandise level.
The optimization is set up as follows:
Optimization is done at the run's merchandise and location setup levels. For example, if the run merchandise and location levels are Department and Region, then each optimization job is at the Department-Region level.
Inventory is rolled to the desired recommendation level for merchandise. Further, the inventory is aggregated across all the locations to the run's location level.
Price recommendations are generated at the configured recommendation levels for merchandise, location or price-zone, and calendar level and the customer segment level.
For example, if the run location level is Price-zone, the run merchandise level is Department, the run calendar level is Week, and the recommendation level for merchandise is Style/Color, then the promotion and markdown recommendations are generated at Price-zone, Style/Color, Week and Price-zone, Style/Color, Week and Customer Segment for Targeted Offers.
Figure 12-2 shows an overview of the OO UI workflow, which consists of the following:
Overview. This is the dashboard for the OO runs. In this tab, you can see a list of all existing runs, along with details that describe each run. The list includes runs created by other users, which you can open in read-only mode. You can create a run, copy a run, open a run, or delete a run. The runs overview has three components, Search, Run Status Tiles, and the Table of Runs.
You can click an existing run or create a new run. Each run is opened in a run tab. The title of the run tab displays "Offer Optimization: <Run ID>". This is the main tab where you can specify the business rules and goals for the run. It provides a series of three stages that you progress through in order to set up, run, and analyze the results of the optimization run.
Setup. Used to pick a season, location or price zone and department. It is also used to select the objectives and specify the budgets.
Rules. Used to view or change business rules.
Results. Used to view results and accept, reject, or override recommendations, and recalculate.
Forecasting. These screens provide the user with the ability to review the way in which different components of forecast (for example, baseline, seasonality) affect the price recommendation for an item.
Manage Recommendations. This screen is used to accept, reject, or override and recalculate recommendations. It also allows the user to review, submit, or approve recommendations so that they can be sent to a price execution system. In production, this screen is the starting point and is used most regularly, since the user can send recommendations from batch runs for execution or visit forecasting screens to review how item forecast looks, and finally, decide whether to create a new ad hoc run.
Figure 12-2 Offer Optimization UI Workflow
The goal of the implementation is to set up and configure an instance to generate optimal price recommendations that satisfy the retailer's business requirements. The implementation 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.
This section provides a high-level project planning for implementation by different buckets: functional, data interfaces, forecasting and optimization.
Understand the existing business requirements for pricing; and proposed process changes with OO.
Verify the functionality that the customer would like to leverage from OO 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.
Overview. Confirm the list of OO 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 OO 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.
Offer Optimization Interfaces.
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.
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.
Most of the AIF Platform's foundation data is pushed in two-step process. Any additional OO-specific data is directly pushed into the AIF Platform. First, data is loaded, using CSV and W_ interfaces, into Retail Analytics Platform Foundation Data, using appropriate jobs. 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. 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, OO-specific data (that is not available in RI interfaces) is directly pushed into the RSP.
The following sections assumes that the user has obtained access to POM. The POM UI URL is something like this: <host>/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 RSP provides database logging in a table called RSE_LOG_MSG. Logging can be enabled only with a service request from the client/implementation partner to the support team.
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 Retail Science Platform. Execute and verify that all the RAP foundation data has been loaded. For details, the RAP Implementation Guide: https://docs.oracle.com/en/industries/retail/retail-analytics-platform/21.0/rapig/data-load-init-batch-proc.htm#data-load-init-batch-proc-F30BF774.
For Offer Optimization, this includes:
Product Hierarchy. When Style, Style Color must be loaded, appropriate columns must be populated.
Location Hierarchy.
Price Zone Groups and Price Zones. It is not required to provide price zones for OO, 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.
Sales. It is best to load at least 20 months of the data to obtain a good signal in the model training.
Inventory. It is a critical data element for OO, for, without inventory, the OO runs would fail.
Inventory Receipts. This data is used to identify when the item started selling. This data must be provided for OO.
Customer Segments. Even when the retailer is not planning to load or use customer segments, a dummy record. is required. RI provides the ability to insert a dummy record, and it is not required for the client or implementator to provide these interfaces: W_PARTY_PER_DS and W_RTL_CUSTSEG_DS.
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 OO 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, OO 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.
Security. RAF files must be provided when the user wants to impose security or data filters for the OO screens based on the merchandise and location nodes. The Manage OO Recommendation user filter will not show any location or merchandise nodes that are not allowed for a particular user.
Product Images. The URLs for rendering product images in OO screens can be provided.
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 OO runs to pick up.
Flex Facts (or Custom Columns). If the user wants to see custom columns in Manage OO Recommendation, then these interfaces must be provided.
Before pushing any data into the Science engine, it is critical to make sure RAP foundation data is accurate and verified. Verification can be done through Data Visualizer or through the Innovation Workbench. Re-loading some of the RAP foundation data elements is non-trivial as it will require an SR to reset/truncate some of the target tables.
RSP foundation data (RSE_% tables)
Once the interface configuration is complete and the RAP Foundation data has been verified, the user can push the data from RAP into RSP. As mentioned before, once database logging has been enabled, users can check for any errors and the progress of the process in RSE_LOG_MSG. Before running the RSE_MASTER_ADHOC with appropriate flags to execute the following jobs, the user must set the correct values for configuration parameters in RSE_CONFIG. This can be done using Manage System Configurations (as described in Control and Tactical Center) and then selecting RSE_CONFIG from the drop-down list.
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.
Location Hierarchy. The target table to check is RSE_LOC_HIER.
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.
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 OO, 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.
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.
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.
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).
Price and Cost. Before pushing the price cost data into RSP, 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.
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 RSP
Some foundation data elements are loaded directly to RSE. Here is a description of some of the data elements that are used in OO.
These files must be prepared into ORASE_WEEKLY_ADHOC.zip.
Prepare the relevant _stg.txt file. (Note that some large files will be compressed into _stg.txt.gz files.)
Zip all the staging files into an archive named ORASE_WEEKLY_ADHOC.zip.
Upload ORASE_WEEKLY_ADHOC.zip to the SFTP site and copy the COMPLETE file to the COMMAND directory.
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-common-dsgn-ovrvw.htm
Holidays. The target table to check is RSE_HOLIDAY. This is a direct load to RSP 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.
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 RSP. The configuration to check is RSE_PRO_WHSE_ALLOC_FLG, which must be set to N when the client is loading allocation percentages.
Product Attributes. Product attributes are not required for OO; however, if the user wants to use them in the Manage OO Recommendation screen, then they must be provided directly to RSP. 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.
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.
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.
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 Offer Optimization.)
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
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).
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.
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.
Price Ladder. The target tables to check are PRO_PRICE_LADDER and PRO_PRICE_LADDER_DTL.
Create OO runs. The user can run the PRO_OPT_CREATE_RUNS_ADHOC_JOB with the FORCE option to create the OO runs for all merchandise and location/price zones.
Optimize OO runs. The user can run the PRO_OPT_ADHOC_JOB with the -batch option to optimize all the above created runs.
Manage OO 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.
Offer Optimization 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 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/merchcs-admin.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 OO runs to pick up.12. Flex Facts (or Custom Columns). If the user desires to see custom
RAF_SEC_USER_GROUP
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
This section provides information about setting up the data that the Offer Optimization 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.
Hierarchies are part of the core data elements that are used in Offer Optimization, 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 W_% interfaces have numerous columns and thus, it is possible to define which columns will be populated in the interface by specifying the column headers (order of columns does not have to be the same) in the corresponding W_%.ctx file.
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_DS, W_INT_ORG_DHS, W_INT_ORG_DS.
Price Zone Group and Price Zones. OO 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 OO, 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 Offer Optimization 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_DS interface, while the levels between CHAIN and Subclass are provided via W_PROD_CAT_DHS interface. In addition, there must be consistency among the levels provided when using an extended hierarchy. W_PRODUCT_ATTR_DS, is used to indicate the relationship between Style, Style/Color, and Style/Color/Size for an extended hierarchy. If the retailer wants to use an extended merchandise hierarchy, then the retailer must populate this interface.
Here are the specific fields:
PRODUCT_ATTR13_NAME = PROD_NUM for the Style (for example, 0000190086820900)
PRODUCT_ATTR14_NAME = PROD_NUM for the Style/Color (for example, 190086834203)
PRODUCT_ATTR15_NAME = PROD_NUM for the Style/Color/Size (for example, 1975699). The value of PROD_NUMs is the same as the value in the W_PRODUCT_DS.PROD_NUM interface.
Here is what this looks like:
PROD_NUM | PRODUCT_ATTR13_NAME | PRODUCT_ATTR14_NAME | PRODUCT_ATTR15_NAME |
---|---|---|---|
STYLE_PROD_NUM | STYLE_PROD_NUM | ||
STY/COL_PROD_NUM | STYLE_PROD_NUM | STY/COL_PROD_NUM | |
STY/COL/SIZ_PROD_NUM | STYLE_PROD_NUM | STY/COL_PROD_NUM | STY/COL/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_DS.
Customer Segments Hierarchy. Offer Optimization 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 OO purposes, retailers can use one set of customer segments to determine forecasting parameters and optimal price recommendations.
Runs in the Offer Optimization 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.
Required interface. Historical inventory data as well as daily inventory data can be specified through this interface: W_RTL_INV_IT_LC_DY_FS. In addition to the non-null fields, the minimum required data fields that used by OO 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
LOC_CURR_CODE - local currency for the RI system
LOC_EXCHANGE_RATE - exchange rate (for BCF probably hard-coded to 1)
OO also uses these two fields, which cannot be provided directly through the above interface. However, they are calculated based on inventory receipts data provided in W_RTL_INVRC_IT_LC_DY_FS.
LAST_INVRC_DT
FIRST_INVRC_DT
Once the inventory data is loaded, the user can configure which inventory components are to be used in OO by setting the corresponding flags appropriately: RSE_INV_QTY_BOH_FLG, RSE_INV_QTY_ON_ORD_FLG, RSE_INV_QTY_IN_TRANSIT_FLG.
Required Interface. Historical price data as well daily price history can be loaded W_RTL_PRICE_IT_LC_DY_FS. 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, 4 = cost change, 8 = clearance price, 9 = promo price.
SELLING_UNIT_RTL_AMT_LCL
BASE_COST_AMT_LCL
DOC_CURR_CODE
LOC_CURR_CODE
LOC_EXCHANGE_RATE
Required Interface. OO directly uses W_RTL_CODE_DS values to drive the markdown results, e.g. if OO 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 12-1 Sample Retail Code Data
CODE_TYPE | CODE | CODE_SEQ | CREATED_BY_ID | CHANGED_BY_ID | CREATED_ON_DT | CHANGED_ON_DT | DELETE_FLG | DATASOURCE_NUM_ID | ETL_PROC_WID | INTEGRATION_ID |
---|---|---|---|---|---|---|---|---|---|---|
MKDN |
1 |
1 |
-1 |
-1 |
11/30/2020 12:42:40 PM |
11/30/2020 12:42:40 PM |
N |
1 |
1 |
MKDN~1 |
2 |
2 |
-1 |
-1 |
11/30/2020 12:42:40 PM |
11/30/2020 12:42:40 PM |
N |
1 |
1 |
MKDN~2 |
|
3 |
3 |
-1 |
-1 |
11/30/2020 12:42:40 PM |
11/30/2020 12:42:40 PM |
N |
1 |
1 |
MKDN~3 |
|
4 |
4 |
-1 |
-1 |
11/30/2020 12:42:40 PM |
11/30/2020 12:42:40 PM |
N |
1 |
1 |
MKDN~4 |
Retail Sales data is a required interface and is provided through W_RTL_SLS_TRX_IT_LC_DY_FS. OO 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.
A historical and future planned promotions-related interface is optional. OO 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 OO 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).
The Warehouse Inventory Allocation interface is optional. The OO 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 OO 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.
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.
The product attributes that are useful in OO 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 OO does not interpret them as different attributes.
The retailer must use W_RTL_ITEM_GRP1_DS, 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 OO 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 OO 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_DS interface is used to provide style and color attributes for the different products, using a value in PROD_GRP_TYPE of either STYLE or COLOR. The actual values for the Styles and Colors are provided in columns FLEX_ATTRIB_2_CHAR and FLEX_ATTRIB_4_CHAR using values that represent the ID for the Style (for example, 1234), and a description for the Style (for example, Loose Fit). The columns FLEX_ATTRIB_3_CHAR and FLEX_ATTRIB_10_CHAR contain the appropriate designation for STYLE or COLOR.
OO 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 that are available on a customer-hosted web server can be viewed In OO via the Results screen. The W_RTL_PRODUCT_IMAGE_DS.dat interface contains 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 OO 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 OO application has access to the URL while running the OO 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.
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.
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.
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.
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, where as ladder_count=2 is ending with .98 and ladder_count=3 is ending with .97.
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.
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.
W_RTL_ITEM_GRP1_DS 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.
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 setup-level (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.
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.
W_RTL_FLEXFACT_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, sell-through for last four weeks), and five date columns (for example, last markdown date).
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 OO can impact the forecast (for example, Covid-19). In such a case, this interface can be leveraged to provide such factors to impact the OO forecast.
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 12-2 Configuration: Expected Levels
Data | Configuration Parameters | Customer Segment | Calendar | Merchandise | Location | Price Zone |
---|---|---|---|---|---|---|
Optimization Level |
Levels at which the optimization process is executed (Units of work) |
PRO_CUST_HIER_PROCESSING_LVL |
PRO_CAL_HIER_PROCESSING_LVL |
PRO_PROD_HIER_PROCESSING_LVL |
PRO_LOC_HIER_PROCESSING_LVL |
-1 or PZ |
Recommendation Level |
Level at which the recommendation results are generated |
PRO_OPT_CUST_REC_LVL |
PRO_OPT_TIME_REC_LVL |
PRO_OPT_MERCH_REC_LVL |
PRO_OPT_LOC_REC_LVL |
-1 or PZ |
Depending on the above configuration levels, the interface levels expected are as follows:
Table 12-3 Interfaces: Expected Levels
Data | Interface Name | Notes | Customer | Calendar | Merchandise | Location | Price Zone |
---|---|---|---|---|---|---|---|
Season |
PRO_SEASON_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 |
Season Period |
PRO_SEASON_PERIOD_STG |
Periods (e.g., weeks) within a season where the PRO_PROD_HIER_PROCESSING_LVL (e.g., CLASS) is active |
N/A |
PRO_CAL_HIER_PROCESSING_LVL Date range could span multiple calendar units (i.e. Multiple weeks) |
PRO_PROD_HIER_PROCESSING_LVL or any hierarchy level higher |
PRO_LOC_ HIER_ PROCESSING_ LVL or any other higher hierarchy level |
-1 or PZ |
Season Product |
PRO_SEASON_PRODUCT_STG |
Products that must be included in given selling seasons |
N/A |
PRO_CAL_HIER_PROCESSING_LVL Date range can span multiple calendar units (i.e. Multiple weeks) |
PRO_OPT_MERCH_REC_LVL |
PRO_OPT_LOC_REC_LVL |
-1 or PZ |
Price Ladder |
PRO_PRICE_LADDER_STG |
Product price ladder |
N/A |
N/A |
PRO_PROD_HIER_PROCESS-ING_LVL or any higher |
PRO_LOC_HIER_PROCESSING_LVL |
-1 or PZ |
Country Locale |
PRO_COUNTRY_LOCALE_STG |
Defines the specific locale for the location. Provided at the COUNTRY level |
N/A |
N/A |
N/A |
PRO_LOC_HIER_PROCESSING_LVL or any hierarchy level higher |
N/A |
Planned Promotion |
RSE_PLAN_PROMOTION_STG |
Planned promotion at PRO_PROD_HIER_PROCESSING_LVL (e.g., CLASS) |
N/A |
PRO_CAL_HIER_PROCESSING_LVL Date range could span multiple calendar units (i.e. Multiple weeks) |
PRO_PROD_HIER_PROCESS-ING_LVL |
PRO_LOC_ HIER_ PROCESSING_ LVL |
-1 or PZ |
Holidays |
RSE_HOLIDAY_STG |
Major holidays |
N/A |
Date when the holiday is observed |
Any level in merchandise hierarchy |
Any level in location hierarchy |
N/A |
Strategy and Business Rules |
PRO_OPTIMIZATION_RULE_STG |
Business rules and associated strategies |
N/A |
N/A |
Any level in merchandise hierarchy |
Any level in location hierarchy |
N/A |
Table 12-4 Expected Levels for Optional* Interfaces
Data | Interface Name | Notes | Customer | Calendar | Merchandise | Location | Price Zone |
---|---|---|---|---|---|---|---|
Inventory |
RSE_INV_PR_LC_WK_A_STG |
Inventory available at the start of the period (e.g., week). Inventory is aggregated to the PRO_LOC_HIER_PROCESSING_LVL (e.g., Price Zone) |
N/A |
Week |
SKU level (Style/Color/Size) |
Store |
N/A |
Price Cost |
RSE_PRICOST_PR_LC_WK_STG |
Price cost for the time period (e.g., week) |
N/A |
Week |
SKU level (Style/Color/Size) |
Store |
N/A |
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)
Additional configuration parameters must be set to integrate OO with Retail Pricing Cloud Service. See the list of parameters shown in Table 12-5. In addition, the RPM username and password must be added under the credential store for Merchandise RPM 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.
Setting up the Configuration Parameters for Integration with Retail Pricing Cloud Service
Table 12-5 Configuration Parameters for Integration with Retail Pricing CS
Parameter Name | Parameter Value | Dexcription |
---|---|---|
PRO_MERCH_RPM_FLG |
N |
Flag to identify whether to publish markdown recommendations to RPM. |
PRO_MERCH_RPM_HOSTNAME |
URL host name to publish recommendations to RPM. This must be same as CN name in the certificate. |
|
PRO_MERCH_RPM_CONTEXT_ROOT |
RpmRestService/services/private |
Context root of the RPM webservice url. |
PRO_MERCH_RPM_CLEARANCE_PATH |
clearance/induction |
Path of the webservice, e.g., clearance/induction. |
PRO_MERCH_RPM_PORT |
443 |
Port number to publish recommendations to RPM. |
PRO_MERCH_RPM_HTTP_PROXY_HOSTNAME |
Proxy host name to publish recommendations to RPM. |
|
PRO_MERCH_RPM_HTTP_PROXY_PORT |
HTTP proxy port number to publish recommendations to RPM. |
|
PRO_MERCH_RPM_HTTPS_PROXY_PORT |
HTTPS proxy port number to publish recommendations to RPM. |
|
PRO_MERCH_RPM_VERSION |
19.0 |
RPM version to use for publishing customer segment to relate (format 16.0). |
PRO_MERCH_RPM_USE_HTTPS |
Y |
Flag to identify whether to publish markdown recommendations to RPM over HTTPS. |
PRO_MERCH_RPM_PROMOTION_PATH |
promotion |
Path of the RPCS webservice for promotions. |
Figure 12-3 Setting up the RPM Access in the Credential Store
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_CAL_HIER_ETL_START_JOB
RSE_PROD_HIER_ETL_START_JOB
RSE_LOC_HIER_ETL_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_LOC_HIER_ETL_END_JOB
RSE_FISCAL_MAIN_LOAD_JOB
RSE_CAL_HIER_ETL_END_JOB
RSE_PROD_HIER_LOAD_JOB
RSE_PROD_TC_LOAD_JOB
RSE_PROD_DH_LOAD_JOB
RSE_PROD_GROUP_LOAD_JOB
RSE_PROD_HIER_ETL_END_JOB
RSE_CM_GRP_HIER_LOAD_START_JOB
RSE_PRICE_ZONE_LOAD_START_JOB
RSE_PROD_ATTR_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_CM_GRP_HIER_LOAD_END_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_PROD_ATTR_LOAD_END_JOB
RSE_SLS_START_START_JOB
RSE_USER_DATA_FILTER_START_JOB
RSE_LIKE_LOC_LOAD_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_LIKE_LOC_LOAD_END_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_LOAD_START_JOB
PMO_ACTIVITY_STG_JOB
PMO_ACTIVITY_LOAD_JOB
PMO_ACTIVITY_LOAD_END_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
Offer optimization 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 re-estimated on a regular basis as part of batch process) to determine the demand and generate the forecast.
Offer optimization 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 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.
The following sections describe the details of the settings in each stage..
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.
Preprocessing. Filters the historical data and makes the first determination of item eligibility.
Elasticity. Determines the price elasticity for markdowns and promotions.
Seasonality. Estimates seasonality trends and identifies partitions with reliable seasonality.
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.
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.
The data preparation stage defines the aggregation levels on merchandise, location, customer-segment, 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.
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 12-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.PMO_LOC_HIER_TYPE |
2 |
1 - 15 |
Customer Segment Hierarchy Type ID: ID corresponding to the customer segment hierarchy used for aggregation of sales, inventory, and returns data.PMO_CUST_SEG_HIER_TYPE |
4 |
1 - 15 |
Calendar Hierarchy Type ID: ID corresponding to the calendar used for aggregation of sales, inventory, and returns data.PMO_FISCAL_CAL_HIER_TYPE |
11 |
1 - 15 |
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. PMO_KEEP_TEMP_TABLES |
N |
Y/N |
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 12-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. Usually this is Company/Banner if there are multiple banners within the company. PMO_MIN_LOC_HIER_PROCESSING_LVL |
2 |
1 - 9 |
Promotion processing level - Location: Choose the 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 |
2 |
1 - 6 |
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 Country-Banner 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.
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.
Table 12-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 12-8 Data Filters Week Level
Filter Name and Description | Default Value | Range of Values |
---|---|---|
Store count greater than 0. Used to filter activities with null or zero store count. IWF_STORE_GTR_ZERO |
N |
Y/N |
SKU store count greater than 0. Used to filter activities with null or zero sku store count. IWF_SKU_STORE_GTR_ZERO |
N |
N/Y |
Inventory data present. Used to indicate that the 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 |
Y |
N/Y |
Sales unit threshold. Used to filter sales data records with sales units below threshold values. IWF_SALES_UNIT_THRESHOLD |
1 |
Greater than or equal to 1. |
Inventory threshold. Used to filter sales data records with inventory units below threshold values. IWF_INV_THRESHOLD |
1 |
Greater than or equal to 0. |
Use store count for Inventory threshold. Defines the 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 |
N |
Y/N |
Threshold combination. Use AND/OR combination for Sales unit threshold and Inventory threshold.IWF_FILTER_COMBO |
AND |
AND/OR |
Life cycle sell thru %. The item start and end dates are calculated using percentage sell through. The start date is the date when Life cycle sell through % (Start) is reached. The end date is the date when Life cycle sell through % (End) is reached. Life cycle sell through % (Start) is expressed relative to 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 |
Start: 2.0 End: 2.0 |
Start: greater than or equal to 0; less than or equal to 50. End: greater than or equal to 0; less than or equal to 50. |
Relative price. Relative price thresholds are used to filter out item weeks with a ratio of sales price to maximum ticket price that fall outside the specified range for the start date and the end date. IWF_LOW_RELATIVE_PRICE and IWF_HIGH_RELATIVE_PRICE |
Start: 0.2 End: 1.0 |
Start: greater than 0. End: greater than the start value. |
These filters are used to exclude all the weekly records from a Merchandise-Location-Customer segment partition at the aggregation level, for partitions with values that do not meet the requirement specified for each filter, as described below.
Table 12-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. IF_MIN_SEASON_WEEKS |
6 |
Greater than 0. |
Minimum sales units. The total number of units sold must be at least this value. IF_MIN_SALES_UNITS |
10 |
Greater than 0. |
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.) IF_FRACTION_ELIGIBLE_WEEK |
0.6 |
Greater than 0.0; less than or equal to 1.0. |
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
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.
Table 12-10 Data Filters Weekly
Filter Name and Description | Default Value | Range of Values |
---|---|---|
Relative price. Used to filter out item-weeks with a ratio of sales price to maximum ticket price that falls outside the specified range. WDF_RELPRICE_LOW and WDF_RELPRICE_HIGH |
Low: 0.2 High: 1.0 |
Low > = 0; High > low value |
Relative inventory. The upper and lower bounds for the value for inventory relative to maximum inventory. WDF_PCTSALES_LOW and WDF_PCTSALES_HIGH |
Low: 0.2 High: 1.0 |
Greater than or equal to 0. Low > = 0 High > low value |
Range filter. Used to eliminate unreliable data using start date and end date for the period. Both the start date and the end date are Null by default. A Null value means that the field is not used in the filter. One or both of the fields can have a value of Null. If both of the fields are Null, then the data is not filtered. WDF_RANGEFILTER_MINCALWK and WDF_RANGEFILTER_MAXCALWK |
Start date: Null End date: Null |
- |
Select the merchandise and location levels for which parameter estimation should calculate demand parameters. Parameter estimation calculates demand parameters for the partitions of the levels that are the cross-products of all the levels you select. The highest level is set based on PMO_MIN_LOC_HIER_PROCESSING_LVL (typically, Banner) and PMO_MIN_PROD_HIER_PROCESSING_LVL (typically, Department). The lowest level is set based on the aggregation levels that the user selects while creating the forecast run types. In Manage Forecast Configurations, the user can select from the list of levels that are between the highest and lowest levels.
The parameters described below are used to identify markdowns in the aggregated weekly sales data. During a markdown window, the application is interested in a drop in prices from the preceding window to the following window. During a promotion, the application is looking for similar prices during the preceding and following window but a drop in prices during the promotion window. Similar parameters are used to identify Promotions as well.
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 12-11 Markdown Parameters
Name and Description | Default Value | Range of Values |
---|---|---|
Time Window MKDN_TIMEWINDOW_PRECEEDING and MKDN_TIMEWINDOW_FOLLOWING |
Preceding: 2 Following: 2 |
1–3 1–3 |
Eligible Weeks MKDN_ELIGWKS_PREC and MKDN_ELIGWKS_FOLL |
Preceding: 2 Following: 2 |
1–3 1–3 |
Maximum Deviation MKDN_MAXDVT_PRECEEDING and MKDN_MAXDVT_FOLLOWING |
Preceding: 0.1 Following: 0.1 |
0–1 0–1 |
Min Markdown Depth MKDN_MINMKDN_DEPTH |
0.1 |
0–1 |
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 |
For identifying promotions, a few additional parameters are defined below in addition to Time window, Eligible weeks, and maximum deviation, which are defined above.
Min Promotion depth is the drop in average sales price during the week of promotion compared to preceding/following 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 promotion.Time window defines the weeks before promotion, during promotions, and after the promotion. 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. Time window that satisfies all the promotion parameter settings is classified as a promotion window.Promotion depth = 1- (Avg. Price during promotion weeks/ Avg. price during preceding and following weeks). Time Window - Promo duration: Duration of the promotion event, this is set to 1 for 1-week promotion. Max deviation - Preceding/Following: Avg. price deviation across preceding and following weeks must be less than this threshold. This ensures that the sales price is similar in the weeks before and after the promotion.
Table 12-12 Promotion Parameters
Name and Description | Default Value | Range of Values |
---|---|---|
Time Window PRWK1_TIMEWINDOW_PRECEEDING, PRWK1_TIMEWINDOW_FOLLOWING and PRWK1_TIMEWINDOW_PROMOWEEKS |
Preceding: 1 Following: 1 Promo Duration: 1 |
1–3 1–3 1 |
Eligible Weeks PRWK1_ELIGWKS_PREC and PRWK1_ELIGWKS_FOLL |
Preceding: 1 Following: 1 |
1–3 1–3 |
Maximum Deviation PRWK1_MAXDVT_PRECEEDING, PRWK1_MAXDVT_FOLLOWING and PRWK1_MAXDVT_PRECFOLLOW |
Preceding: 0.1 Following: 0.1 Preceding/Following: 0.1 |
0–1 0–1 0–1 |
Min Promotion Depth PRWK1_MINPROMO_DEPTH |
0.1 |
0–1 |
Promotion duration parameter is set to 2 for identifying two week promotions. Promotion parameters for one week and two week promotions can be set to different values.
Table 12-13 Promotion Two Weeks
Name and Description | Default Value | Range of Values |
---|---|---|
Time Window PRWK2_TIMEWINDOW_PRECEEDING, PRWK2_TIMEWINDOW_FOLLOWING and PRWK2_TIMEWINDOW_PROMOWEEKS |
Preceding: 1 Following: 1 Promo Duration: 2 |
1–3 1–3 2 |
Eligible Weeks PRWK2_ELIGWKS_PREC and PRWK2_ELIGWKS_FOLL |
Preceding: 1 Following: 1 |
1–3 1–3 |
Maximum Deviation PRWK2_MAXDVT_PRECEEDING, PRWK2_MAXDVT_FOLLOWING and PRWK2_MAXDVT_PRECFOLLOW |
Preceding: 0.1 Following: 0.1 Preceding/Following: 0.1 |
0–1 0–1 0–1 |
Min Promotion Depth PRWK2_MINPROMO_DEPTH |
0.1 |
0–1 |
Determine the partitions with reliable elasticity values.
Table 12-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. RS_OUTLIER_THRESHOLD |
0.05 |
0–0.05 |
Eligible items threshold - Elasticity RS_ELIGIBLEITEMS_THRESHOLD |
25 |
Greater than 1. |
Std. Error threshold RS_STDERROR_THRESHOLD |
0.3 |
0–1 |
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 12-15 Transformation
Name and Description | Default Value | Range of Values |
---|---|---|
Transform Percentile - Low TRANSPERCENTILE_LOW |
0.1 |
0–1 |
Transform Percentile - High TRANSPERCENTILE_HIGH |
0.9 |
0–1 |
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. ELASTICITYRANGE_MAX |
2.8 |
Greater than elasticity range–min. |
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
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 12-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. BASIC_CURVE |
Y |
True or FalseY/N |
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. |
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 12-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. KEEP_TOP_LEVEL_CURVES |
Y |
Y/N |
Prune curves with missing dates. Pruning of basic curves with missing dates is permitted. PRUNE_CURVES_MISSING_DATES |
Y |
Y/N |
Eligible items threshold. Partitions with fewer numbers of eligible items than the threshold value are removed. Eligibility is defined during preprocessing. |
5 |
Greater than or equal to 0.0. |
Average weekly sales threshold. Partitions with average weekly sales below the threshold are removed. Weekly sales are the sum of all sales for all activities for a given week. AVG_WK_SALES_THRESHOLD |
25 |
Greater than or equal to o. |
Raw seasonality length threshold. Curves can be discarded when the number of weeks from the first 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 |
10 |
Greater than or equal to 0. |
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 12-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. PROM_LIFT_BASELINE_TYPE |
Linear |
Linear, Min, or Max. |
Outlier percentile.Very high lift values are flagged. PROM_LIFT_OUTLIER_PERCENTILE |
0.05 |
0–1 |
Lift value -High. Lift values flagged as outliers are capped to outlier percentile lift value. PROM_LIFT_HIGH |
Y |
Y/N |
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. PROM_LIFT_MIN_VALUE |
1.05 |
Greater than or equal to 1. |
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. Offer Optimization typically expects the parameters at the lowest level of estimation. For example, Offer Optimization expects the demand parameters at Class-Store 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.
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 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 12-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 |
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-Location-Customer Segment level every week. This information, along with the returns parameters and sales forecast, is used to generate the returns forecast.
Table 12-20 Returns Metrics
Name and Description | Default Value | Range of Values |
---|---|---|
Merchandise level 1. The top most 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_THSLD |
0.5 |
> 0.3 |
Data sufficiency threshold. Row count: 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_THSLD |
500 |
>100 |
The following multiplicative demand model is used as follows:
Demand = Base demand* Seasonality *Price effect* Promotion Traffic Lift*Store 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 in-season sales data to generate a demand forecast. Demand forecast values along with historical parameters are sent to Offer Optimization 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 12-21 Demand Forecasting
Name and Description | Default Value | Range of Values |
---|---|---|
Merchandise level -Store Weights. The 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 |
6 |
1 - 9 |
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. OPTPARAM_PCT_SLS_THRESHOLD |
2% |
0%–5% |
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. BD_PERIOD_LEN |
4 |
0–6 |
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 strate-gy. 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 |
Store weights - Duration of data. Number of weeks of data used for calculation of store weights.BD_SW_SLS_LEN_WKS |
13 |
13 - 52 |
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. OO 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 OO 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 12-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 |
50 |
80 |
180 |
||
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
This section describes the business rules that are available and the science behind the optimization algorithms used in the Offer Optimization 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.
The implementation of Offer Optimization 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 OO 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 12-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. |
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_SETUP_LVL |
4 |
The merchandise hierarchy level at which PRO will setup/create RUNs. |
PRO_PROD_HIER_PROCESSING_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_PROCESSING_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. |
PRO_TR_NO_TOUCH_AFTER_LANDING |
0 |
Default no touch after landing (2 weeks). |
PRO_TR_LENGTH_OF_PROMOTIONS |
0.6 |
Default length of promotion as a percentage of the whole season. |
PRO_TR_MAX_LENGTH_OF_PROMOTION |
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_LIFE |
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_MAX_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_DISC_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. |
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_BETWEEN_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_SEASON |
0.15 |
Default percentage of sell-through for each individual product at end of regular periods. |
PRO_ST_END_CLEARANCE_SEASON |
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_TIME |
2 |
Default return lead time in weeks (time when the return happens after the pur-chase 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. |
PRO_BASE_INITIAL_BUDGET |
9999999 |
Initial Budget for Base Scenarios. |
PRO_SEAS_CURVE_WEEKS_SWITCH |
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_SEGMENT |
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_FLG |
Y |
Y/N Indicator. Identifies if the absolute calendar must be used for Temporal Rules. |
PRO_USE_LIFECYCLE_FATIGUE |
N |
Y/N Indicator. Identifies if the life cycle fatigue must be enabled or not. |
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 12-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, which tells the optimization that this constraint does not have to be met. Optimization will try to satisfy this constraint, and, if it cannot, it will not return an infeasible or no solution.
To provide a sense of the complexity of the optimization, here is a sample of the trade-offs that are analyzed.
Is it better to provide a promotion early in the life or wait until later in life to mark down? Will conducting in a promotion now help me given a shallower markdown at a later point in life?
There are planned promotions scheduled at different points in time. Can these promotions be used and figure out whether an item needs further promotions or markdowns?
Is providing a promotion at a particular week useful? Will it help meet the sell-through target? Will it increase revenue?
There are customer segments with different response to price cuts. How can targeted offer provide a promotion that will entice the customer in customer segment A?
Does providing a promotion or markdown or targeted offer for an item cause a conflict with the imposed business rules? For example, a user might determine that the item cannot be given more than 30% discount.
Forecasting is applied in the optimization using the demand parameters supplied. Suppose the user wants to generate weekly price recommendations. Depending on the day of the week when markdown is effective, forecasting is adjusted using daily weights to reflect that there are two prices in effect for that week. The same logic applies for promotions as well.
The objective function specified by the user plays a major role in determining which solutions are considered best. For example, if the user specifies the objective function as maximize profit margin, then the algorithm will look for solutions that are superior on profit margin and not necessarily on the other KPIs such as revenue and sales volume. Sometimes, understanding why an item got such a price recommendation might be as trivial as looking at the objective function contribution of that particular item to the objective function.
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.
OO supports a variety of constraints, and it is essential for the user to understand the purpose and role of each constraint in the optimization.