Mirror of Oracle documentation

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

12 Forecast Engine

Forecast Engine provides access to the tasks used to configure, prepare, and review forecasts in Oracle Retail AI Foundation Cloud Service. From the Forecast Engine landing page, you can manage forecast configurations and supporting master data, define forecasting strategies for new items and locations, and review, adjust, and approve generated forecasts.

Use Manage Forecast Configurations to create forecast run types, test forecast runs, manage configuration parameters, and map run types to the applications that consume the forecasts. A forecast run type acts as a template for forecast runs, while each forecast run is an instance of a particular run type.

Use Manage Master Data to maintain information that supports forecast generation, including sales plans and flexible groups. Sales plans support in-season Bayesian forecasting, while flexible groups provide merchandise and location groupings used when estimating forecast components such as seasonality and elasticity.

Use New Item Setup and New Location Setup to define how forecasts are generated when sufficient sales history is not available. For new items, you can select an appropriate substitution method and, where applicable, identify a like item or provide base demand. For new locations, you can assign a like location and an adjustment factor. See New Item Setup and New Location Setup.

Use Forecast Review to examine forecast components and historical demand, make permitted adjustments, and approve forecasts. The workspace supports grid, chart, and pivottable views and provides additional approval information for the selected product and location. Forecast Review describes the review and approval workflow.

Manage Forecast Configurations

This section describes the workflow and screens in Manage Forecast Configurations. With this functionality, you can set up and manage the forecast run types and forecast runs for different applications.

Forecast Run Type

The Forecast Run Type is the high-level template for forecast runs. Each run type has certain attributes that must be specified when the run type is being created. All configuration parameters default to the system default value when the run type is created. Use the Manage screen to modify the value of the configuration parameters for the run types.

Forecast Run

Forecast runs are created for a specific run type and are considered instances of the run type. The forecast run shares all the attributes of the run type and by default will have system default values for all configuration parameters. These parameters can be modified when a new run is being created in the Test screen.

Overview

The typical workflow for setting up run types, runs, and configuring the parameters is outlined in this section. Each step is described in detail in the sections that follow.

1. Create a run type in the Setup screen (train stop 1).

If the aggregation status of the run type is Not Started, start the aggregation.

2. Create a run in the Test screen (train stop 2) and override the configuration parameters as desired. Then submit the run.

3. Once the run is successfully completed, review the summary of outputs from the estimation process by clicking the Summary link next to the run. This feature is available only if the run uses the Life Cycle forecast method.

Note

You can create as many runs as desired. These are considered what-if runs and allow you to experiment with different values for configuration parameters and examine the impact on the estimated demand parameters.

4. Set the configuration parameters for the run type in the Manage screen (train stop 3). This will determine the values that should be used in all subsequent batch runs for the given run type.

At the end of the implementation process, activate the run type to indicate that the run type should be part of the weekly batch process. During the weekly batch, a new run is created for each active run type.

5. Create a mapping between the run type and the application using the Map screen (train stop 4).

Setup

In the Setup screen in train stop 1, shown below, you can see the overview table of the existing run types and create new run types. In addition to Run Type Name, Run Type Description, Created On, and Created By, the table shows the following information about the run type.

then Type Drserten | exe | ace Somrce * = ~ | Forecast Method * |cniesart Pree Fa| eee |ee!Regutsrand PromotionGens | = | (Miecniciny Troe Location * | Normal Locusion Hieearctey =] scp —_no Ferecast Lest: Meschonaing * [ spe coor =] Faescant Lev Lecason * Femme 7 Sorat Fonecoun te Dy tevel | - |e Sgrend Prats Lav - Merchandng ” [« = | Sorend Ferecane‘eeccamen ts 6 Levee foo| ‘Setoncer othiteric Sora meetPrtemdaned no caledanetgsead pote [coomeascroe[a = =] [= | Location ia! fer spend pete | oa)

Forecast Measure

This determines the measure that will be used as input by the forecasting algorithm. The final forecast will be generated for this measure. For the Sales & Promo and Life Cycle methods, the supported measures are total gross sales units, total net sales units, and regular & promotion gross sales units. For the Automatic Exponential Smoothing method, the forecast can be generated for other measures such as clearance sales, other sales, and returns.

Number of Historical Weeks for Options Activities Aggregation

This determines the number of weeks to be used by the Options Forecast. If the Options Forecast is selected, all settings below are not available.

Customer Segment

Select Forecast by Customer Segments to generate the forecast by the merchandise/location/ segment. If you turn on the switch, you must also click the button next to it in order to select one or multiple customer segments. It is recommended that you only select the segments that you want the forecast to be generated for (that is, un-select inactive segments) as this will make the data aggregation and forecast generation processes more efficient. Forecast by Customer Segment is applicable only for the Life Cycle method.

Price Zone Group

Select the Forecast by Price Zone to generate the forecast by merchandise/price zone. If you turn on the switch you must also click the button next to it in order to select one or multiple price zone groups. It is recommended that you only select the price zone groups that you want the forecast to be generated for (that is, un-select inactive price zone groups) as this will make the data aggregation and forecast generation processes more efficient. Forecast by price zone is applicable for the Life Cycle and Hierarchical Bayesian methods.

Hierarchy Type - Merchandise/Location/Calendar

Select the hierarchy type you want to use for this run type. For instance, for the merchandise and product hierarchies the default choices in the drop-down list are Normal Hierarchy and Extended Hierarchy. If an alternative hierarchy is created it will also appear as a possible selection. Depending on the selection, the choices for the merchandise and location forecast levels are dynamically updated.

Forecast Level- Merchandise/Location/Calendar

Select the intersection that you want the forecast to be generated at. This will also determine the level at which sales data will be aggregated and flow through the various stages of forecasting. If you turn on the Forecast by Price Zone, the location level defaults to a level at the top of the location hierarchy. (This level is configurable and is determined by PMO_MIN_LOC_HIER_PROCESSING_LVL in the RSE_CONFIG table in the Manage System Configuration screen.)

Spread Profile Level - Merchandise/Location/Calendar

You can turn on the switch for the Spread Forecast to Day level only if the Forecast Level – Calendar is Week. Select the Spread Forecast Level for Merchandise/Location/Calendar only after turning on the switch for the Spread Forecast to Day level.

Spread Forecast to SKU Level

If the run type is defined to generate the forecast at the style-color/location/week intersection, this allows the option to spread the forecast from style-color to style-color-size, or SKU. Next are the setup settings.

Source of Spread Profile

There are two possible sources for the spread profile. First, you can use an approved profile, that has been generated and interfaced from the size profile optimization solution. Second, you can use the calculated profile that is generated in AIF using the following settings.

Recent Historic Weeks Considered to Calculate Spread Profile

This setting controls how many historical weeks of the preprocessed baseline demand should be used to generate the profile.

Location Level for Spread Profile

Here you can specify a location level to allow the sizes to be different by location. For instance, if you choose region, all stores inside a region will have the same profile.

The profile can be generated weekly, or quarterly using POM jobs, or on demand, using the Calculate Size Profile option in the Manage screen.

Data Aggregation

After you create a run type, you can see the aggregation status in the run type overview table. If the new run type has the same merchandise-location-calendar intersection as an existing run type, the aggregation status will be shown as complete as soon as you create the new run type because the data aggregation at that intersection has already been completed. This is applicable only for the run types that do not have a price zone dimension. For the run types that do have a price zone dimension, data aggregation must be done for each run type separately.

If any run type has an aggregation status of Not Started, click the Start Data Aggregation button above the run type overview table. This opens a pop-up where you can see a list of run types for which the aggregation process has not yet started, as shown in the next section..

You can select one or multiple run types from the top and/or bottom section in the pop-up and click Submit to start data aggregation. The Cumulative Aggregation process will be started once the aggregation process is submitted. It is only applicable for run types with forecast method Life Cycle.

Add Multiple Run Types

Click on the Add Multiple Run Types button. It will open a tab with a table consisting of available templates to create multiple run types at a time, as shown below. If the Enable column button is turned on and Process Flag column is null, then the corresponding row will be considered for creating run type. Click on the Create Run Types button to create multiple run types.

Click on + icon to add new process IDs to the table, as shown below. Select rows from the table and click on X icon to delete process IDs. User can also edit parameters within each row if Process Flag is null. Click the Save button to save the changes.

To start the aggregation process for the run types that have price zone dimension, select the run types from the following list.

Actions VY View Vv + Ths x Sy a VY BG Detach Approve Demand Parameters Approve Base Demand and Forecast ID Forecast Run Name Name Status Estimation Results Estimation Summary Status Summary Status Status Estimation Run! Estimation Complete - New New Item Handling 1159s Run 1159 Complete - Parameter Export to Target Parameter Export to Target Export to Target to Target Target ti) Summary Completed Parameter Expor Expor Comoleted

The view contains the following measures:

Measure	Description
Depromote Adjustment	This measure displays the units that were removed from the historical sales, because they were caused by the lift in demand due to one or more offers.
Outage Adjustment	This measure displays the units that were added to the historical sales, because they were caused by the artificial drop in demand due to stockouts.
Outlier Adjustment	This measure displays the units that were added to the historical sales, because they were caused by the artificial drop in demand due unusual events, like human error, or extreme bottle water sales during a hurricane.
Outage Indicator	This measure is either loaded or calculated by the rules in the custom menu. It is used during the pre- processing run that corrects sales for lost sales.
Promotion Indicator	This measure is usually calculated as theorof all available offers that are active for a Product/ Location/calendar combination. It is used during the preprocessing run that removes promotional sales.
Baseline Demand	This measure represents the demand that was sold at a location without the influence of any outside factor.
Historical Discount	This measure displays the units that were removed from the historical sales, because they were caused by the lift in demand due to one or more offers. When the Historical Discount or Historical Event measures are not blank, it is likely that the Promotion Indicator is On, and the Depromote Adjustment will also have a non-zero value.
Historical Event	When the Historical Discount or Historical Event measures are not blank, it is likely that the Promotion Indicator is On, and the Depromote Adjustment will also have a non-zero value.
Outlier Indicator	This measure is either loaded or calculated by the rules in the custom menu. It is used during the pre- processing run that corrects the sales for outliers.
Raw Sales	This measure is loaded and it represents the historical sales at a Product/Location/calendar period level. It is different from demand because it may be constrained by stockouts, outliers, weather, and so on.
Promo Demand	This measure represents the demand – including promotion and offer data that was sold at a Product/Location/calendar. If configured properly, the stockout and outliers impact is removed.
User Override	After reviewing all the above measures, this is the place to override the demand at the Product/ Location/calendar level. This can be useful for special cases (introduction of key items) as well as extreme situations when entire departments were hurt by natural events, like a pandemic.

• Last Approved Forecast vs Current Forecast

• Last Year Sales vs Forecast

• Recent Sales vs Forecast

These three are designed to compare the baseline forecast with various flavors of baseline sales. The following is designed to check the promo impact on demand:

• Max Sales vs Forecasted Peak

There are a few settings for the approval alerts:

• Approval alerts can be enabled or disabled.

• Only calculate the alerts for sales larger than a threshold.

• Determine the number of periods for which the errors are calculated.

• Decide what errors are acceptable based on the Error Threshold. For item/store combinations with errors less than the threshold, the forecasts are approved.

Once the approval process was run using the approval alerts, some time series are approved while the others are not. The non-approved time series are prioritized using the navigation alerts. In this section, you can define how many priority buckets you want to define and give them some meaningful labels. The time series are assigned to navigation buckets based on how large the calculated error was during the approval process.

A set of labels commonly used are:

• Urgent

• Required

• Optional

• Informational

Time series are assigned to navigation alerts according to the navigation threshold:

• if error > threshold 1 > Urgent

• if threshold 1 > error > threshold 2 > Required

• if threshold 2 > error > threshold 3 > Optional

• if threshold 3 > error > threshold 4 > Informational

The number of navigation tiers needs to match the number of labels and number of thresholds.

The adjustment method allows the forecast adjustments to persist, or if they should be overwritten by subsequent forecast runs. The options are:

• No Adjustment : No adjustment is made to the system-generated forecast.

• Keep Last Forecast: If any adjustments were done to the forecast in the previous runs, they are reflected in the Adjusted Forecast measure. In this use case, the total forecast is retained.

• Keep Last Baseline : If any adjustments were done in the Adjusted Baseline in the previous runs, they are retained. In this use case, the system calculated peaks are applied on the Adjusted Baseline.

• Keep Last Peak : If any adjustments were done in the Adjusted Peak measure in the previous runs, they are retained. In this use case, the adjusted peaks are applied on the system-calculated baseline.

| Scope | Life Cycle Optimize History Attribute Weights Incrementality Sales Potential Review

Approve Demand Parameters

Select a row and click the Approve Demand Parameters button above the table to approve the estimation runs. You can approve demand parameters only for the runs where the estimation is complete. You can approve another run to replace the previously approved run. Once a run is approved, the Estimation Run column in the below table displays Approved next to the estimation run name. Only one estimation run per run type can remain approved at any point in time. The demand parameters generated by the approved run will be used in weekly forecast batch runs.

Approve Base Demand and Forecast

Select a row and click the Approve Demand and Forecast button above the table to approve base demand and forecast runs. Approve Base Demand and Forecast operation can be performed for the runs that has an approved estimation run and are in base demand complete or forecast generation complete status. Once a run is approved, the Forecast Run Name column in the below table displays Approved besides the forecast run name. Multiple forecast runs per run type can remain approved.

Manage

In the Manage screen in train stop 3 you can set the value of configuration parameters for the run type. These values will be used when creating and executing batch runs for each run type. In this screen, you can also activate or inactivate run types by selecting a row and clicking the Activate button above the table. Active run types become part of the weekly batch process, and a new batch run is created and executed for each active run type. For each active run type, once the batch run is approved, the output of the batch run will be exported to and consumed by the applications that are mapped to that run type. In order to auto-approve the batch runs, select a row and click on Manage Auto-approve . For the Life Cycle run type, the start date calculation can be disabled or enabled by clicking the Disable Life Cycle Start Date Calculation or Enable Life Cycle Start Date Calculation button, respectively.

To review and override the value of configuration parameters for a run type, select a row and click Edit Configuration Parameters above the table. This button will display as View Configuration Parameters if the run type is in active status. The Edit configuration pop-up is similar to the Create Run pop-up that is used to create forecast runs and has a tab for each stage of estimation and forecast. In each tab, you can do one of the following, as shown below.

• Set the values of all configuration parameters in that stage, based on the system default for the run type. To do this, select System Default from the drop-down menu and click Apply .

• Set the values of all configuration parameters in that stage based on the values that were previously set in one of the what-if runs. To do this, select the desired run from the dropdown menu and click Apply .

• Override the value of a certain configuration parameter. To do this, select a row and click the Edit icon above the table.

A configuration setting that is available in train stop 3 and is not available in train stop 2 is the Item Supersession option. Enabling Item Supersession activates the interface and the demand calculation. See the Oracle Retail AI Foundation Cloud Service Implementation Guide for details. Making it available in the Manage train stop as opposed to the run type creation, makes it more flexible, allowing to enable/disable the functionality, for any desired forecast run.

RUN FOT_RUN FINALIZED MODEL SETTINGS HDR_ID TYPEIO _MODEL _NAME _FILE AMSE MAE AVG_ERROR MEDIAN ERROR ERROR_WGT |II 1558 ; 241 N ASE_UUC_PL_TMPSRSE_LUC_PL_SETTSO000001555 O74 O55 Oar O22 : 030 | 1440 241 ¥ RSE_LUC_PL_TMPSRSE_LUC_PL_SETTSO000001440 O79 O55 O65 O18 034 3303 20M RSE_LUCPL_TMPSRSE_LIC PLSETTSOOONGUISOS PLSETTSOOONGUISOS ooo on o o e200 ALN RSE_LUC_PL_TMPSRSE_LUC PL SETTSOOOOONNE2 | 1s00 241 N RSE_LLCPL_TMPSRSE_LLC_PLSETTSOO00001E00PL_TMPSRSE_LLC_PLSETTSOO00001E00 o.74 O55 aay 22 o30 | 743 341 /N RSE_LLCPL_TMPSRPLPL_TMPSRPLPL S ETTSOO00001743E_LLCE_LLC

Actions “ = View F

Measure

System Baseline

System Peak

System Forecast Adjusted Baseline

Adjusted Peak

Adjusted Forecast

Approved Baseline

Approved Peak

Approved Forecast

Approved Cumint Approved System Baseline Approved System Peak Approved system Forecast Baseline Demand

Promo Demand

Approval Information

What-lf

If you want the adjusted forecast to become the official forecast, you must Approve the forecast. Approval copies the Adjusted Baseline values into the Approved Forecast measure.

The selected parameter values are retained and used the next time the forecast batch is run.

The adjustable parameters affect both:

• Base demand - the overall magnitude of the forecast.

• Seasonality - the shape and seasonal pattern of the forecast.

Baseline What-If can be performed at either the Item/Store level or an aggregate level.

The level at which the What-If simulation is performed is determined by the intersection currently displayed in the main Forecast Results grid. This intersection is controlled by the Top Filter settings.

The following are the measures in the What-If view

What-If : This Boolean measures specifies if the user can perform What-if. If it is unchecked, no What-if is triggered.

To perform What-if you need to select at least one of the following measures:

• What-If Seasonality Level

• What-If Base Demand Method

• What-If Base Demand History Length

If the What-if flag is on, you can run it by clicking What-if Baseline .

What-if Seasonality Level: This measure lets you specify a certain escalation level from which the seasonality curve will be used during What-if.

What-if Base Demand Method: This measure lets you override the forecast method for the base demand to be used during What-if.

The choices are all the methods available for base demand in the forecast setup task.

What-If Base Demand History Length : This measure lets you specify the number of weeks used to calculate the base demand during What-if.

What-if Seasonality Level Requested: This measure displays the requested seasonality level.

This can be different from the What-if Seasonality Level Picked, because the requested level

What-if Seasonality Level Picked: This measure displays the picked seasonality level.

This can be different from the What-if Seasonality Level Requested, because the requested level may be pruned. In this case escalation is performed to pick the next intersection

What-if Base Demand Method Requested: This measure displays the requested base demand method.

This can be different from the What-if Base Demand Method Picked.

For instance, if the requested method is Pick Best, the method picked will show the actual winner of the Auto Baseline competition.

What-if Base Demand Method Picked: This measure displays the picked base demand method.

This can be different from the What-if Base Demand Method Requested.

For instance, if the requested method is Pick Best, the method picked will show the actual winner of the Auto Baseline competition, like Holt.

What-if Base Demand History Length Requested: This measure displays the requested history length to calculate base demand

What-If Base Demand History Length Picked : This measure displays the actual number of weeks used to calculate the base demand

System Seasonality Level Picked : This measure displays the escalation level used in generating the system forecast.

System Base Demand Method Requested: This measure displays the requested base demand method to generate the system forecast.

This can be different from the System Base Demand Method Picked.

For instance, if the requested method is Pick Best, the method picked will show the actual winner of the Auto Baseline competition.

System Base Demand Method Picked : This measure displays the picked base demand method when generating the system forecast.

This can be different from the System Base Demand Method Requested.

For instance, if the requested method is Pick Best, the method picked will show the actual winner of the Auto Baseline competition, like Holt.

System Base Demand History Length Requested : This measure displays the requested number of weeks used to calculate base demand when generating the system forecast.

System Base Demand History Length Picked: This measure displays the actual number of weeks used to calculate base demand when generating the system forecast.

You can also perform What-if for promotions and price in the Forecast Review workspace. This information is setup and reviewed in the main grid of the workspace.

The promo What-If workflow is as follows:

1. Modify the What-If Discount and/or What-If Event values for the desired forecast weeks.

2. Click What-If Promo to generate a new promotional forecast.

3. Review the results in the What-If Peak measure in the Forecast Results grid.

4. Repeat steps 1 to 3 as many times as necessary until you are satisfied with the results.

5. When you are satisfied with the simulated forecast, click Copy to Adjusted Peak to copy the What-If Peak values into the Adjusted Peak measure.

The following action buttons are added to the workspace:

• What-If Baseline : generates forecast with the parameter changes.

• Copy to Adjusted Baseline : copies values from What-If Baseline into Adjusted Baseline.

• What-If Promo : clicking this button triggers the what-if promo call.

• Copy to Adjusted Peak : copies the values in the What-If Promo measure to the Adjusted Peak measure.

• Like Item : The forecast is created using the base demand of a Like Item. The Like Item is selected in the User Selected Like Item measure. The forecast of the New Item is given by:

Base demand New Item = base demand Like Item * Adjustment Factor

Forecast at time t = base demand New Item * seasonality at time t (coming from escalation level) * promo and price effects

• Base Rate of Demand : We need to calculate the base rate of demand of the escalation level. The forecast for the new item is given by:

Forecast at time t = base rate of demand (coming from escalation level) * seasonality at time t (coming from escalation level) * promo and price effects

• User Input : This method is very similar to Base Rate of Demand, with the difference that you have to manually specify a base rate of demand. The forecast is then generated using the same formula as for Base Rate of Demand.

User Provided Base Demand

If the User Input substitution method was selected, you have to enter the base rate of demand that is going to be used for the New Item when generating the forecast.

Forecast Startdate Override

This is a very important measure because it identifies an item as being new. It can be loaded if the information can be interfaced from another system. If not available, you can manually set it.

Approve Date

This measure displays the date when the Like Item recommendation was approved by clicking the Approve button.

Adjustment Factor

The only demand component needed to generate forecast for New Items is base demand. If the Like Item substitution method is selected, the adjustment factor specifies what percent of a Like Item’s base demand will be copied to the New Item.

Approved Like Item

This measure is relevant if you selected the Like Item substitution method. If you go through the process to set up the New Item, and use the System Recommended Like Item or override by selecting another Like Item from the User Selected Like Item list, the Approval Flag is checked. Running the Approve New Items custom menu populates this measure.

System Recommended Like Item

This measure is relevant if you selected the Like item substitution method. Your environment needs to have item attributes and attributes weights, so similarities between new and existing items are calculated. In this case, the potential Like Items are sorted by their similarity scores, and the item with the highest score is displayed as the system recommendation.

Note how the Like Items are not displaying just the item label. First, you see a percentage. This represents how similar the Like Items are to the New Items. A value closer to 100% means high similarity. The second value shows the average demand of the Like Item. This is useful in selecting a Like Item, because it is an indication of forecast magnitude. This value is recalculated to reflect the latest data point, so what you see here may be outdated by a week. Finally, the third element is the item label. Note that if there is no logic to calculate similarities, you need to select the like item manually.

The New Item Statistics view contains the following measures:

• Workflow Message Count : This measure displays the count of the Workflow Message measure in the Select and Approve view. The workflow messages are guiding you in the New Item setup process. If the count is zero, you have set up correctly all New Items. The count corresponds to the number of New Item/store combinations that you still have to finish setting up.

• Store Count : This measure displays the number of stores that a New Items has been set up for.

In addition to these workspaces, there are some general settings that can be accessed through Manage Forecast Configurations in the run setup under the New Item Basic Parameters tab.

To create a new mapping, click the + (plus) icon above the table in Map screen. Select an application and one or more run types (based on what the application allows) and click Save . To delete a mapping, select a row and click the X icon above the table.

New Item Forecast

In this view, you can review the forecast of the new item, change new item strategies, and immediately see the impact in the forecast.

The measures that can be edited to trigger what if are:

• Substitute method

Depending on the selection, the user needs to provide additional information, such as user provided base demand or user selected like item.

After editing and clicking Save, the Approve Flag measure is set to true. When the Approve Flag is true, it means that all settings are validated, and the user can either approve the selection, or run What-If. To run What-If, the user needs to manually set the What-If measure to true for the locations the user desires. At this point, the analyst can perform what-if by clicking the Forecast New Items button.

Once the what-if was run, the what-if flag will turn to false, and the Approve stays true. The user can either approve the changes, by clicking the Approve button, or can perform further what-if runs. By not approving any changes, the user will retain the initial setup.

1. Make changes to the New Item Forecast Strategy for one or more locations, then click Save .

2. Ensure the Approval Flag is enabled.

3. For each location where the Approval Flag is set to True , manually enable What-If .

4. On the main grid, click Forecast New Items .

5. The What-If measure is disabled while the forecast is being generated.

6. Review the forecast results in the bottom drawer.

7. Perform What-If adjustments as many times as needed until you are satisfied with the forecast.

8. Once you are satisfied with the forecast, click Approve New Items .

The measures in the New Item Forecast view are:

• New Item Forecast : this is the initial forecast created.

• User Forecast : this is the result of the latest What-if run.

The two versions of the forecast can be viewed in the grid OR in a chart.

---

In this guide

• Guide: AI Foundation User Guide
• Previous: 11 Control and Tactical Center
• Next: 13 Forecasting Methods in AIF