3 RDF CS Configuration

RDF CS is a forecasting solution that uses state-of-the-art modeling techniques to produce high quality forecasts with minimal human intervention.

RDF CS supports pre-processing, new item/store processing and forecast generation. To obtain good forecast results, the above features need to be configured to work together. RDF CS is highly configurable and extremely flexible. The preprocessing and forecast generation was handled on the science engine side. The new item, forecast adjustment and forecast approval was implemented on the RPAS side. To streamline RDF CS implementation and shorten implementation time on RPAS, several plug-ins are provided to work together with RPAS Configuration Tools. These plug-ins let users input configuration options through the GUI and automatically generate configuration solutions based on the RDF CS GA master template and user inputs. The configuration solutions generated by the plug-ins are New Item and RDF CS. The plug-ins auto-generate the hierarchies, measures, rules, workbook templates, taskflow and the Dashboard configuration file that are required by RDF CS to support the forecasting configuration entered in through the plug-in interface:

Table 3-1 Autogenerated Items from Plug-ins

Autogenerated Entity	Description
Hierarchies	The internal hierarchies required by the solution will be generated by the plug-in. Labeled Intersections are autogenerated.
Measures	All measures necessary to support the base solution will be created.
RPAS Rules	All Rule Sets, Rule Groups, and Rules to support the base solution will be created.
Workbook Templates	All pre-defined workbook templates to support the base solution will be created.
Taskflow	The taskflow will be auto generated based on the RDF CS template and the levels entered in the plug-in.
Dashboard Configuration file	The Dashboard configuration file is auto generated based on the dashboard levels and custom exceptions enter using the plug-in.
Batch Control file	The Batch Control file is auto generated.

RDF CS Batch Flow Process

Understanding the RDF CS batch flow process is important before starting RDF CS Configuration:

RDF CS has two major batch process:

• RDF CS Pre-forecast Batch

• RDF CS Post-forecast Batch

RDF CS Pre-forecast Batch

This batch process should run before running forecast generation in the science engine.

This batch process involves the following steps:

1. Import Hierarchy from RDX

2. Load RDF CS Internal Hierarchy

3. Import data from RDX

4. Load RDF CS specific data

5. Running New Item batch

6. Merge Forecasting parameters

7. Export Forecasting Parameters to RDX

RDF CS Post-forecast Batch

This batch process should run after running forecast generation in the science engine.

Note: RDF CS provides a mechanism to extend the GA batch process. Refer to Customizing the RDF Batch Process.

This batch process include the following steps:

1. Import system forecast from RDX tables

2. Adjust system forecast to generate adjusted forecast

3. Calculate attributes needed for Approval business rule-group

4. Generate approval business rule membership

5. Assign parameter values to sku/store based on approval rule membership

6. Run the approve exceptions.

7. Approval forecast and calculate the mask for unapproved item/store..

   Forecasts can be approved in three ways:

   • Manual - Nothing is approved in the batch process and you must go to the forecast review workbook to approve forecasts.

   • Automatic - All forecasts are approved by the system. RDF CS has defined several GA approval alerts that are available for the approval process.

   • Approval by Exception - Approves forecasts based on the user specified approve exception. With no exception, the forecast is approved. With an exception, the forecast is not approved. RDF CS provides four GA approve exceptions: forecast versus recent sales, forecast versus approved forecast, forecast versus last year sales, causal peak. Implementors can choose to disable these approval exceptions.

     Implementors can also define custom approval exceptions through the RDF CS plug-in to create additional approval exceptions. These exceptions are also produced before approval

8. Calculate eligibility for navigation tier. All item/store with valid forecast and unapproved will participate in navigation grouping.

9. Calculate attributes needed for navigation business rule group

10. Generate navigation business rule membership.

11. Assign navigation tier based on navigation business rule membership.

12. Calculate dashboard statistics

13. Export approved forecast to RDX

Implementation Process

The RDF CS GA configuration can be used out of the box to build the RDF CS domain. The GA configuration has RDF CS's point of view on how to configure a final level and how to configure business rule engine for approval and navigation.

RDF CS implementors can modify the RDF CS GA configuration to meet the retailer's business needs. RDF CS supports two means to achieve this:

• Configuring the solutions using the plug-ins

• Extensibility of the configuration

This chapter explains how to configure the various solutions using the plug-ins. Extensibility of the configuration is described in Chapter 4, "RDF Cloud Service Extensibility". Although there is a separate plug-in for New Item and RDF CS solutions, from the Config Tools UI, we only see two plug-in dialogs – Forecast Common and RDF CS. This simplifies the configuration process for the implementor.

Set Up Common Configuration Details

From the Configuration Tools toolbar, select the Automation menu and then from the Forecast Common option, select Specify Configuration Details.

Figure 3-1 Configuration Tools: Forecast Common

Figure 3-2 Select Common Input

In this step we specify the common input to both New Item and RDF CS.

The product attribute measure to be used in the RDF CS and New Item solutions has to be specified in the Common Plug-in. The product attribute measure stores the attribute position name and not the attribute label.

Labeled Intersections

The labeled intersections listed in Table 3-2 must be defined before running the RDF CS plug-ins. The plug-in validation will ensure that the required labeled intersections are defined.

Table 3-2 Labeled Intersections

Labeled Intersection	Definition	Description	Measures Defined
SLS_INTX	sku/stor/week	Sales intersection	pos, rsal, psal, csal
DAYSLS_INTX	sku/stor/day	Sales intersection at day (load intersection)	Can be used as load intersection for sales coming in at day level
SLSNC_INTX	sku/stor	Sales intersection without calendar	ldactivefcstitem, flagllc
SKUSTOROFFR_INTX	sku/stor/offd	Offer sales intersection	Offersls
SKUSTORWEEK_INTX	Sku/stor/week	Event calendar	Eventclnd, prcdiscclnd
Condmeasvalintx1	Clss	Condition value measure	Condmeasvalnum1, Condmeasvalstr1, Cconmeasvaldat1
Condmeasvalintx2	Dept/regn	Condition value measure	Condmeasvalnum2, Condmeasvalstr2, Condmeasvaldat2
Condmeasvalintx3	Clss/regn	Condition value measure	Condmeasvalnum3
Condmeasvalintx4	Dept/regn	Condition value measure	Condmeasvalnum4
Condmeasvalintx5	Dept	Condition value measure	Condmeasvalnum5
Condmeasvalintx6	Regn	Condition value measure	Condmeasvalnum6

Labeled Intersection Use Cases

Labeled intersections listed in Table 3-2 can be defined based on the retailers business needs. SLS_INTX is the labeled intersection for the incoming sales measures (pos, rsal, psal, csal).

Common Solutions

Open an RDF CS GA configuration to see the common modules. This solution should not be modified by the implementor and are considered as non-touch solutions. This solution defines input/output measures for the whole RDF CS project. The content created in this module will not be modified by the plug-ins. The measures created in these modules are external measures for the plug-ins, and they will serve as inputs to plug-ins. Although this module are not generated by plug-in, It will be overridden in RDF CS Configuration Automation Script. Any modification by the implementor will be ignored.

Common Solution

In RDF CS GA, the common solution is used to register measures related to sales, offers and product attribute inputs/outputs to:

• New Item

• RDF CS Solutions

Note: For the common solution, an implementor can only modify the labeled intersection definition that changes the measure intersection in common.

Set up the New Item Solution

The New Item module is designed to support the forecast for new item/store. RDF CS provides three approaches to forecast new item/store:

Forecast Approach	Description
Like Item	The forecast is created based on the forecast of Like Items. The Like Items can be selected manually, and the choices are entered in the User Selected Like Items measure. The task can also be automated if attributes are available. RDF CS then suggests one Like Item in the system recommended Like Item measure. The forecast for the New Item is given by: Base demand new item = base demand like item * Adjustment Factor The forecast for the New Item is calculated as: Forecast at time t = base demand new item * seasonality at time t (coming from escalation level) * promo and price effects (coming from pooling level)
Base Rate of Demand	RDF CS calculates the escalated base rate of demand. 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 (coming from pooling level)
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. Forecast at time t = base demand new item * seasonality at time t (coming from escalation level) * promo and price effects (coming from pooling level)

The New Item module provides tools to support the automatic and manual assignment of like item/store to new item/store. If the user can provide product attribute information, the new item can be automatically identified and provided a like item recommendation. If no product attribute information is available, the user has to assign like items manually. New store mapping is always done manually.

Configure New Item Solution

Perform the following steps to generate a New Item solution:

1. From the Configuration Tools toolbar, select the Automation menu and then, from the RDF CS option, select Specify Parameters.

   Figure 3-3 Configuration Tools: New Item

   
   

2. From the Like Item Parameters utility, specify the properties for the New Item plug-in. Refer to Editing New Item Parameters for details.

   Figure 3-4 Like Item Parameters

   
   

3. Click OK once editing is finished.

Editing New Item Parameters

Table 3-3 lists the New Item parameters available for editing.

Table 3-3 New Item Parameters

Parameter	Description
New Item Data Source	Sales data used to generate forecast for New item/store.
Product Map	This field specifies the range of the like item available to a new item. If the field is populated with clss, it means that only existing items under the same class as the new item are available as like item candidate. The Similarity Score calculation should only be performed between the new item and existing items with in the class.
Attribute Weight Location	Allows you to specify which location level that the attribute weight used in similarity score calculation will be based on. The attribute weight measure intersection is to be on product Map/attribute-weight-loc/patt. In GA, it is clss/chan/patt.
New Store Level	This field specifies the product level on which like store is assigned to new store. If the field is selected as scls, it means that the like store assignment can be different per subclass.

Configuring the RDF CS Solution

In RDF CS, the Demand Model to generate the forecast is:

Demand = Base Demand * Seasonality * Promo Effects * Price Effects

This is the basic model used to forecast short lifecycle and long lifecycle items. However the approach to calculate each of these components might differ.

Forecast information is often required for items at the lowest levels in a hierarchy. Problems can arise when historic sales data for these items is too sparse and too noisy to identify clear selling patterns. In such cases, calculating the seasonality curves and effects at a higher level in the hierarchy based on an escalation path, would generate a reliable forecast. The science UI provides a mechanism to define the final levels and escalation levels; and the associated parameters for each level. The default escalation path is the order in which the escalation levels are used also defined in the science UI. Users can also edit default escalation path, override the escalation path at the final level intersection from the science UI. In RDF CS plug-in, implementor need to define the final levels. The final levels specified in RDF CS plug-in must match the final levels defined in the science UI.

The RDF CS solution can be configured using the final level tab in the RDF CS plug-in UI:

Table 3-4 RDF CS Plug-in UI Tabs

Tabs	Description
Final Level	Define and configure final levels

Generate RDF CS Solutions

Perform the following steps to generate an RDF CS solution:

1. From the Configuration Tools toolbar, select the Automation menu and then, from the RDF CS option, select Specify Parameters. The following steps outline the process for configuring RDF CS forecast levels.

   Figure 3-5 Configuration Tools: RDF CS

   
   

2. 1. Select the final level tab to configure the various parameters for Final Levels.

3. Configure a final forecast level:

   From the Forecasting Parameters utility, click the F icon. A new final level is added, and it is assigned the next available level number. Specify the properties for the final level. See Editing Forecast Level Parameters for details.

   
   

   Note: To remove a final level, select the forecast level and then click the X icon. Deleting a final level removes all of its associated parameters.

   
   

   Figure 3-6 Final Forecast Level

   
   

Edit Final Level Forecast Level Parameters

Table 3-5 lists all of the Final Level Forecast Level parameters.

Table 3-5 Final Level Forecast Level Parameters

Final Level Parameters	Description
Level Name	The level name is the system-assigned level number when a forecast level is created. This is a read-only parameter.
Level Label	The level label is the level description that will be viewed by the user once the domain is created. Level labels may not exceed 40 characters. The level labels must be the same as the external name used for forecast level for science UI
Preprocess Intx	The intersection that sales will be preprocessed. If a final level 's forecast intersection is sku/str/week. Its preprocessing intx is also at sku/stor/week. If a final level's forecast intersection is at sku/stor/day, Its preprocessing intx is also at sku/stor/week. Sales history at day is usually too sparse to perform efficient preprocessing.
Forecast Intersection	This defines the level at which forecast will be generated. Usually the final level forecast intersection will be at week. In case of daily causal final level, the effects will be calculated at week level and the forecast will be spread from week to day.
Intermediate Parameter Intx	This define the level at which forecast parameter can be setup. RDF CS allows parameters to be set up at three level, at default (scalar measure), at intermediate (measure at intermediate parameter intx specified here), at final (measure at forecast intersectuin without calendar).
Dashboard Intersection	This define the lowest level at which forecast and sales statistics can be reviewed in dashboard. implementor need to be very careful with the selection of intersection. If it is too low, dashboard workbook will run into performance issue. If it is too high, user loss visibility to details.
Alert Count Update	This field indicates if the navigation alert in forecast approved should be wiped out if an alerted sku/store ’s forecast is approved. Default is true. That means the navigation alerted item/store numbers will be reduced as user reviewed the forecast and approved it.
Promo Agg Profile Intersection	This defines the intersection of the Promo Aggregation Profile measure. It is used only for Daily Promotions, to aggregate promotions defined at day up to the week.
Baseline Spread Profile	This defines the intersection of the Baseline Spread profile measure. It is used only for Daily Causal to spread the baseline forecast from week to day level.
Max Horizon	Defines the maximum number of weeks of forecast length.
My Exception	This parameter provides a mechanism for the implementor to configure custom approval exceptions and enable/disable GA provided approval exceptions. These exceptions will be used during the batch for Forecast approvals and is also seen in the dashboard exception profile as a separate tile. The implementor can enter the labels for the exception and the secondary measure such as variance measure. Note that the implementor is responsible to configure the rule/rule group (based on the exception definition) to populate the boolean measure (and variance measure) for the My Exception.

Configure My Exception

This parameter provides a mechanism for the implementor to configure custom approval exceptions and enable or disable GA provided approval exceptions. These exceptions are used during the batch for Forecast approvals and are also seen in the dashboard exception profile as a separate tile. The implementor can enter the labels for the exception and the secondary measure such as variance measure.

Note that the implementor is responsible to configure the rule or rule group (based on the exception definition) to populate the boolean measure (and variance measure) for My Exception.

To add or remove custom exception, perform the following steps.

1. Click within a cell of the My Exception table to open a dialog as shown in Figure 3-7. The dialog displays a table with the columns:

   • Label - Displays the exception label name (read only)

   • Exception Metric Label - Displays the exception metric label name (read only)

   • Enable - Allows you to enable or disable GA provided exceptions

2. Click P to create additional rows for custom approval exceptions. implementors can enter labels and exception metric labels in the new custom exception. Click X to delete the custom exception.

   Figure 3-7 Add New Custom Exceptions

   
   

Configure My Business Rule Group Type

Click within a My Business Rule Group Type cell to configure the business rule group types. Business Rule Group Type is a RDF CS internal dimension that is part of the Final Level Hierarchy. The Final Level hierarchy file is generated by an RDF CS plug-in. There are two dimensions: rulegroup-type and final level.The dimension, rulegroup-type rolls up to the final level dimension. There are two GA rulegroup types per final level, Approve and Navigation.

You can specify additional custom rulegroup types using the RDF CS plug-in. Each final level can have its own custom rulegroup type. The Final Level hierarchy data file is generated at domain build/patch time.

The business rule group type table is created with two default rows. The Name and Build-in Parameters are read only. Aprv01 is for approval. It is a rule group type designed for approval process.

The built-in Parameters are:

• Approve method at final

• Alert window at final

• Alert error threshold at final

The rule group type, navi01, is designed for tiered navigation in Forecast Review workbook.

Click P to add more custom rule group types. The name need to be unique across all final levels and thus it is good practice to append level number at the end. Click X to remove custom rule group types.

User specified Parameters per rule group type can be specified by an implementor if additional parameters need to be included. The parameters are associated with business rule group type so that the values for a certain sku/store can be assigned to a set of value for a business rule which the sku/store belongs.

Click within the cell of user specified parameters to open the dialog that allows you to add or remove parameters. The Select Measures box in Figure 3-8 displays all GA parameter measures. Most of these measures are forecasting parameter at final. Any custom measures with intersection = forecast intersection without the clnd dimension and have a valid db will be available for selection too. For each selected measure, a measure at business rule is created and added to the parameter for <rule group type> worksheet for user input.

Figure 3-8 Select User Specified Parameters

Click within the condition value cell to open the dialog that allows you to select the condition value measures to be used. The measures available for selection are the ten condition measures GA provides and any custom non-boolean measure that have an intersection higher than forecast intersection without the clnd dimension and have a valid db. The selected measure are used to construct the picklist for condition value (measure) in the Rule Setup workbook.

Figure 3-9 Select Condition Value Measures

Configure Navigation Tiers

Navigation in the Forecast Review workbook is now tiered. You can decide how many tiers and what is the rule to associate a sku/stores to a tier. There is a corresponding workbook alert associated with each tier. By switching between workbook alerts, you can jump between sku/stores with a different priority to be approved.

Click within the navigation-tier cell to display the dialog that allows you to add or delete a tier.

Click P to add more tiers. implementors can enter the label of the tier and indicate if a time-phase workbook alert is enabled or disabled.

Click X to remove tiers.

For each tier, a workbook alert at prod/loc is created in the Forecast Review workbook. If time-phased is enabled, an additional workbook alert at prod/loc/clnd is created in the Forecast Review workbook.

Figure 3-10 Select Navigation Tiers

RPAS Rolling Calendar

RDF CS has enabled an RPAS Rolling Calendar feature for Forecast Review workbook templates. Refer to the Oracle Retail Predictive Application Server Cloud Edition Configuration Tools User Guide for more details.

In essence this allows us to define a calendar window based on RPAS_TODAY. The main use case for this feature is for auto workbook builds, where in the calendar window advances based on RPAS_TODAY.

Figure 3-11 Rolling Calendar

Out of the four rolling calendar range measures, only the Minimum Future has been set to the Alert Calculation window. This is set during the forecast batch.

The Minimum Past defaults to 0, which means it is not required to pull in any week prior to TODAY.

The Maximum Past and Maximum Future are also not set and will default to the current Calendar pre-range.

Note: The rolling calendar feature is not extensible and implementors cannot edit the rolling calendar range measures.

Translation Process in RDF CS

As part of the domain build or patch process, RDF CS loads the GA translation files (which includes RPAS and taskflow files).

RDF CS then loads any custom translations that you may have placed on the OBJECT STORAGE in the INCOMING_FTP_PATH/translation directory.

During the patch, RDF CS also loads previously uploaded translation files.

For details, refer to the Internationalization chapter in the Oracle Retail Predictive Application Server Cloud Edition Administration Guide.

Note: As part of configuration or extensibility, if the implementor changes the labels of the RDF CS level in the plug-in, RDF CS generates the corresponding English (and non-english_us) translations in the r_msglabel measure and loads it. For locale specific translations, it is the implementor's responsibility to upload the correct translation files.

Since the RDF CS level labels are appended to the worksheet labels, the implementor should upload the new labels.

Perform the following steps to access the position names to create the locale specific file:

1. Make sure the browser locale is English - United States

2. From the OAT configure batch task, go to the Translation Task and then, Download All Translations.

3. The r_msglabel.csv.ovr file contains the English labels as updated by the implementor in the RDF CS plug-in.

4. This file can serve as an example to create the locale specific r_msglabel file.

5. The locale specific file can contain only the records with the updated labels.

6. Revert the browser language to the original locale.

7. Upload the locale specific r_msglabel.csv.ovr file using the Translation Task .

   Figure 3-12 Translation Tasks