| Oracle® Retail Demand Forecasting Cloud Service Implementation Guide Release 23.1.101.0 for Windows F76812-02 |
|
 Previous |
 Next |
| Oracle® Retail Demand Forecasting Cloud Service Implementation Guide Release 23.1.101.0 for Windows F76812-02 |
|
Previous |
Next |
Oracle Retail has designed the Business Rule Engine (BRE) to help RDF CS users set up business strategies to manage parameters used in the forecast approval and navigation processes. Parameters include alert thresholds, alert calculation window, as well as navigation criteria. These parameters can be set up manually in the Forecast Setup workbook at the global, intermediate and final levels (override). With the Business Rule Engine, the parameter values at final level can be dynamically adjusted based on business strategy. No patching of the environment is required.
For example, a business strategy can be to set the alert error threshold to 10% for all item/store combos with average sales larger than 10 units per week. For item/store with average sales less than 10 units per week, the threshold can be relaxed to 20%. This way high sellers have a tighter error threshold because they are more important for the business. RDF CS users may want to review their forecasts more rigorously. In this approach, the parameter values were assigned to item/stores based on business strategy regardless of their hierarchy positions.
In this appendix, several components of the RDF CS Business Rule Engine are introduced:
There are several RDF CS internal hierarchies involved in the RDF CS BRE:
Business Rule Attribute
Rule-Condition
Business-Rule
Final-levels
These hierarchies are required to be configured from innermost to outermost in the order previously listed. In RDF CS GA config, the hierarchy order is configured properly. Implementors can start from RDF CS GA config so that they do not have configure the hierarchy order themselves. But if they start from other configurations, they need to make sure the hierarchy order is correct.
The Business Rule Attribute hierarchy in BRE is different from current product attribute or location attribute hierarchy in RDF CS/MFP CS. It is a combination of product attribute, location attribute and prod/loc attribute. These attributes will be used in BRE to associate different prod/locs to different business strategy. The attribute data types can be string, numeric or date. The attribute values can come from 11 difference sources:
Attribute from product hierarchy, such as scls, clss, dept.
Attribute from location hierarchy, such as region, store format
Loaded product attribute, such as fabric, color. (This may be a subset of the product attribute hierarchy. implementor should only include product attributes that are to be used in business rule groups)
Loaded location attribute, such as store open date. (This may be a subset of the location attribute hierarchy. implementor should only include location attributes that are to be used in business rule groups)
Loaded prod/loc attribute, such as lead time
Calculated GA product attribute, such as number of stores carrying a sku
Calculated GA location attribute, such as number of skus sold in a store.
Calculated GA prod/loc attribute, such as historical average sales, historical relative standard deviation of sales.
Calculated custom product attribute, defined by implementor
Calculated custom location attribute, defined by implementor
Calculated custom prod/loc attribute, defined by implementor
Because the attribute value could come from such a diverse sources, it will be very inefficient to keep a centralized measure to store the attribute values. RDF CS takes a distributed approach on storing the attribute values. The attribute value in 1 and 2 are part of hierarchy and no separate storage is needed.
For each final level, the loaded attributes can be stored in nine measures:
All measures based on sku/attd (string, numeric, date)
All measures based on stor/attd (string, numeric, date)
All measures based on sku/stor/attd (string, numeric, date)
For each final level, the GA calculated attributes can also be stored in the same nine measures as loaded. The GA calculated attributes were stored in different measures from the loaded attributes for performance reason.
RDF CS batch is responsible for populating the GA calculated attributes. If additional calculated attributes are needed, the implementor can write custom rules to calculate them and populate the nine measures per final level that are reserved for custom calculated attributes. In total, 27 measures per final level will be created by RDF CS for attribute value storage as shown in Table B-1.
These measures can be divided based on data type, measure intersections and how they are populated. RDF CS special expressions have built in logic to perform attribute value lookup based on business rule attribute hierarchy info and the previously listed measures. (_CF_ in the table is a token of the final level name)
Table B-1 Measures per Final Level
| Measure Name | Data Type | Intersection | Stored Attribute Type |
|---|---|---|---|
|
Ldprdattstr_CF_ |
String |
Prod/attribute |
loaded |
|
Ldlocattstr_CF_ |
String |
Loc/attribute |
loaded |
|
Ldprdlocattstr_CF_ |
String |
Prod/loc/attribute |
loaded |
|
Ldprdattnum_CF_ |
Real |
Prod/attribute |
loaded |
|
Ldlocattnum_CF_ |
Real |
Loc/attribute |
loaded |
|
Ldprdlocattnum_CF_ |
Real |
Prod/loc/attribute |
loaded |
|
Ldprdattdat_CF_ |
Date |
Prod/attribute |
loaded |
|
Ldlocattdat_CF_ |
Date |
Loc/attribute |
loaded |
|
Ldprdlocattdat_CF_ |
Date |
Prod/loc/attribute |
loaded |
|
clcprdattstr_CF_ |
String |
Prod/attribute |
GA calculated |
|
clclocattstr_CF |
String |
Loc/attribute |
GA calculated |
|
clcprdlocattstr_CF_ |
String |
Prod/loc/attribute |
GA calculated |
|
clcprdattnum_CF_ |
Real |
Prod/attribute |
GA calculated |
|
clclocattnum_CF_ |
Real |
Loc/attribute |
GA calculated |
|
clcprdlocattnum_CF_ |
Real |
Prod/loc/attribute |
GA calculated |
|
clcprdattdat_CF_ |
Date |
Prod/attribute |
GA calculated |
|
clclocattdat_CF_ |
Date |
Loc/attribute |
GA calculated |
|
clcprdlocattdat_CF_ |
Date |
Prod/loc/attribute |
GA calculated |
|
csclcprdattstr_CF_ |
String |
Prod/attribute |
Custom Calculated |
|
csclclocattstr_CF_ |
String |
Loc/attribute |
Custom Calculated |
|
csclcprdlocattstr_CF_ |
String |
Prod/loc/attribute |
Custom Calculated |
|
csclcprdattnum_CF_ |
Real |
Prod/attribute |
Custom Calculated |
|
csclclocattnum_CF_ |
Real |
Loc/attribute |
Custom Calculated |
|
csclcprdlocattnum_CF_ |
Real |
Prod/loc/attribute |
Custom Calculated |
|
csclcprdattdat_CF_ |
Date |
Prod/attribute |
Custom Calculated |
|
csclclocattdat_CF_ |
Date |
Loc/attribute |
Custom Calculated |
|
csclcprdlocattdat_CF_ |
Date |
Prod/loc/attribute |
Custom Calculated |
All attributes from 1 to 5 and from 9 to 11 can be defined by implementor. An implementor can decided what prod/loc dimension and prod/loc attribute to be included in the attribute dimension. The GA calculated attribute are automatically appended to the business rule attribute hierarchy.
Right now, RDF CS supports the GA calculated attributes listed in:
Table B-2 GA Calculated Attributes
| GA calculate Attribute | Label | Intersection | Data Type | Stored Measure | Notes |
|---|---|---|---|---|---|
|
locs4prod_CF_ |
Number of Locations Carrying Current Product _CF_ |
Loc/Attribute |
numeric |
clclocattnum_CF_ |
|
|
prods4loc_CF_ |
Number of Products Carried in Current Location _CF_ |
Prod/Attribute |
numeric |
clcprdattnum_CF_ |
|
|
recentavgsls_CF_ |
Recent Average Sales _CF_ |
Prod/loc/Attribute |
numeric |
clcprdlocattnum_CF_ |
|
|
histavgsls_CF_ |
Historic Average Sales _CF_ |
Prod/loc/Attribute |
numeric |
clcprdlocattnum_CF_ |
|
|
navifin_CF_ |
Navigation Variance _CF_ |
Prod/loc/Attribute |
numeric |
clcprdlocattnum_CF_ |
Used in navigation tier |
|
histrlstd_CF_ |
Historic Sales Coefficient Of Variation _CF_ |
Prod/loc/Attribute |
numeric |
clcprdlocattnum_CF_ |
Other than GA attributes, the implementor is responsible for creating and maintaining all custom attributes no matter if loaded or calculated.
RDF CS designed the attribute hierarchy to capture this complex information. There are five dimensions: attribute, attribute source, attribute data type, attribute type and attribute category. Figure B-1 displays the dimensions in the attribute hierarchy.
Attribute dimension: Examples are: scls, clss, dstr,regn, brand, color, size, planned life length, store assortment, recentavgsls01, recentavgsls02.
Attribute source dimension: Indicates the source of the attribute values. This can be either from a dimension in the prod hierarchy, a dimension in the location hierarchy, or measures. The position name along this dimensions is either a dimension name or a measure name.
Attribute data type dimension: Indicates the type of values for an attribute. It can be string, numeric or date. Use the value of RPAS Measure data type.
Attribute type dimension: Indicates if an attribute is a hierarchy attribute, loaded attribute or calculated attribute.
Attribute intx dimension: Indicates the hierarchies/dimensions involved in obtaining the attribute value. These can be prod, loc, or prod/loc.
During domain build/patch, RDF CS automatically generates a business rule attribute hierarchy file with GA attributes positions appended to the end of the Business Rule Attribute Hierarchy File.
Example B-1 is an example of the Business Rule Attribute Hierarchy file.
Example B-1 Business Rule Attribute Hierarchy File
attd,attd_label,atdt,atdt_label,atsc,atsc_label,atst,atst_label,attp,attp_label scls,subclass,3,string,scls,subclass of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute clss,class,3,string,clss,class of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute dept,Departmet,3,string,dept,department of product Hierarchy,hier,Hierarchy Attributes,prod,Product Attribute vndr,Vendor,3,string,vndr,vendor of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute regn,region,3,string,regn,region of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute chnl,Area,3,string,chnl,area of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute sfmt,Store Format,3,string,sfmt,store format of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute brand,Brand,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute itemstatus,Item Status,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute collar,Collar,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute color,Color,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute fabric,Fabric,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute neckline,Neckline,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute pattern,Pattern,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute storopendt,Store Open Date,4,date,ldlocattdat01,loaded Location Attribute 01,load,Loaded Attribute,loc,Location Attribute leadtime,Lead time,2,real,ldprdlocattnum01,Loaded Product/Location Attribute 01,load,Loaded Attribute,prod/loc,Product/Location Attribute
If there are two final levels in the RDF CS configuration, the business rule attribute hierarchy file will look like Example B-2:
Example B-2 Business Rule Attribute Hierarchy File with Two Final Levels in the RDF CS Configuration
attd,attd_label,atdt,atdt_label,atsc,atsc_label,atst,atst_label,attp,attp_label scls,subclass,3,string,scls,subclass of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute clss,class,3,string,clss,class of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute dept,Departmet,3,string,dept,department of product Hierarchy,hier,Hierarchy Attributes,prod,Product Attribute vndr,Vendor,3,string,vndr,vendor of product Hierarchy,hier,Hierarchy Attribute,prod,Product Attribute regn,region,3,string,regn,region of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute chnl,Area,3,string,chnl,area of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute sfmt,Store Format,3,string,sfmt,store format of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute brand,Brand,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute itemstatus,Item Status,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute collar,Collar,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute color,Color,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute fabric,Fabric,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute neckline,Neckline,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute pattern,Pattern,3,string,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attribute storopendt,Store Open Date,4,date,ldlocattdat01,loaded Location Attribute 01,load,Loaded Attribute,loc,Location Attribute leadtime,Lead time,2,real,ldprdlocattnum01,Loaded Product/Location Attribute 01,load,Loaded Attribute,prod/loc,Product/Location Attribute locs4prod01,Number of Locations Carrying Current Product 01,2,Real,clcprdattnum01,Calculated GA Prod Numeric Attribute 01,gacalc,GA Calculated Attribute,prod,Product Attribute prods4loc01,Number of Products Carried in Current Location 01,2,Real,clclocattnum01,Calculated GA Location Numeric Attribute 01,gacalc,GA Calculated Attribute,loc,Location Attribute recentavgsls01,Recent Average Sales 01,2,Real,clcprdlocattnum01,Calculated GA Prod/loc Numeric Attribute 01,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute histavgsls01,Historic Average Sales 01,2,Real,clcprdlocattnum01,Calculated GA Prod/loc Numeric Attribute 01,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute navifin01,Navigation Variance 01,2,Real,clcprdlocattnum01,Calculated GA Prod/loc Numeric Attribute 01,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute histrlstd01,Historic Sales Coefficient Of Variation 01,2,Real,clcprdlocattnum01,Calculated GA Prod/loc Numeric Attribute 01,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute locs4prod02,Number of Locations Carrying Current Product 02,2,Real,clcprdattnum02,Calculated GA Prod Numeric Attribute 02,gacalc,GA Calculated Attribute,prod,Product Attribute prods4loc02,Number of Products Carried in Current Location 02,2,Real,clclocattnum02,Calculated GA Location Numeric Attribute 02,gacalc,GA Calculated Attribute,loc,Location Attribute recentavgsls02,Recent Average Sales 02,2,Real,clcprdlocattnum02,Calculated GA Prod/loc Numeric Attribute 02,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute histavgsls02,Historic Average Sales 02,2,Real,clcprdlocattnum02,Calculated GA Prod/loc Numeric Attribute 02,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute navifin02,Navigation Variance 02,2,Real,clcprdlocattnum02,Calculated GA Prod/loc Numeric Attribute 02,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute histrlstd02,Historic Sales Coefficient Of Variation 02,2,Real,clcprdlocattnum02,Calculated GA Prod/loc Numeric Attribute 02,gacalc,GA Calculated Attribute,prod/loc,Product/Location Attribute
This hierarchy only has one dimension: condition. It is used to organize the strategies used in defining a business rule. In the RDF CS GA configuration, there are four available conditions. The implementor can modify the number of positions they want along the condition dimension by changing the condition hierarchy load file.
Example B-3 is an example of the Condition Hierarchy file.
There are two dimensions: rule and rule-group. Rule rolls up to rule group. This hierarchy should have an order that is after the condition hierarchy but before Prod/loc.
Example B-4 is an example of the Business Rule Hierarchy.
Example B-4 Business Rule Hierarchy
ruld,ruld_label,rulg,rulg_label r001,Rule 1,g001,Rule Group 1 r002,Rule 2,g001,Rule Group 1 r003,Rule 3,g001,Rule Group 1 r004,Rule 4,g001,Rule Group 1 r005,Rule 5,g001,Rule Group 1 r006,Rule 6,g002,Rule Group 2 r007,Rule 7,g002,Rule Group 2 r008,Rule 8,g002,Rule Group 2 r009,Rule 9,g002,Rule Group 2
This hierarchy file is generated by the RDF CS plug-in instead of being user provided. There are two dimensions: rule group-type and final level. rule group-type rolls up to final level. There are two GA rule group types per final level, approve and navigation. The implementor can specify additional custom rule groups type through the RDF CS plug-in. Each final level can have its own custom rule group type. The Rule Group-type hierarchy data file will be generated at domain build/patch time.
An example of rule group type hierarchy file generated from a RDF CS configuration with two final levels:
Example B-4 is an example of the Business Rule Hierarchy.
Example B-5 Rule Group Type Hierarchy File Generated from a RDF CS Configuration with Two Final Levels
rgtp,rgtp_label,flvl,flvl_label aprv01,approve 01,01,01 Weekly Units Forecast navi01,navigation 01,01,01 Weekly Units Forecast cust101,cust rule group,01,01 Weekly Units Forecast aprv02,approve 02,02,02 Daily Units Forecast navi02,navigation 02,02,02 Daily Units Forecast
The rule/rule group dimensions together with condition dimension and rule group type are used to implement business strategies. It is extremely flexible and powerful. The following describes how to set it up using the current RDF CS GA configuration as an example.
For example: RDF CS GA configuration has one final level and thus two GA rule group type:
Approval—Approval is a rule group type for business strategy related to exception parameters used to approve the forecasts.
Navigation—Navigation is a rule group type for business strategy related to navigation in the Forecast Review workbook. These two rule group types are built in the RDF CS rule group types per final level.
To set up the business strategy for approval, the implementor need to set up rule group and rules using the following steps.
Set up rule group to rule group type association.
Open the Business Rule Group Administration workbook. In the Rule Group Info View, the implementor can assign:
A rule group type for a generic rule group and enter a rule group description.
In the example, each department, Beverage, men's shoes and Missy have its own rule group for approval and navigation.
Priority for a rule group.
Priority lower bound and upper bound is meant to assign a range of priority for rules within a rule group. An implementor can assign several rule groups to approval but only set up rules for one of them. In that case, only enable the one rule group that is needed. This helps with performance.
Set up active attributes per rule group.
In the 2.Rule Group Active Attribute View, enable active attributes per rule group. In the example, class, high priority item, historic average sales, historic sales coefficient of variance (relative standard deviation) and recent average sales were enabled for the approval rule groups.
Brand was only enabled for Men's shoes and Missy. Brand may be an important attribute for fashion items. High Priority item is used to flag key items in the business. The rest of enabled attributes is more related to sales pattern.
During rule setup and later calculation, only the value of active attributes will be looked up. RDF CS limits or selects active attributes for certain merchandise to ease the manual selection when you are setting up the rule. Also, having only relevant attributes helps performance.
Set up rule group scope.
There is one Rule Group Scope view per final level. Since a rule group is assigned to a rule group type in STEP 1 and a rule group type rolls up to a final level, there is a position query on the worksheet to display only the related rule group per worksheet. In the Rule Group Scope Worksheet, an implementor can set up the prod/location that a particular rule group is associated with. The rule group scope can be set up at the intermediate parameter intersection of the final level. In this example, each rule group is only enabled for the department it is associated with. The worksheet base intersection is on scls/region/rule-group. It is rolled up to dept/all-location/rule-group.
Create the Business Rule Setup workbook.
There is one Business Rule Setup workbook per final level. During the wizard of the Business Rule Setup, a user is limited to select only one rule group type. A user can only set up business rules for one rule group type within one workbook. Remember the options are Approval and Navigation, as well as any of the custom types that were set up.
Suppose you select the approval in the rule group type wizard which builds the Build Rule Setup workbook for approval. Implementors can set up rule description, rule priority and enable rules on the 1.Rule Enable View.
In this example, three business rules are set up for each approval rule group. Each rule corresponds to one business strategy.
The rules are:
Key item
High volume
Low volume
You can define the criteria that associate different item/stores to each rule later. If an item/store is associated with multiple business rules, the rule priority is used to establish the precedence. The rules with lower priority will have higher precedence. The assigned rule priority must be within the range of priority upper bound and priority lower bound set up in the Rule Group Administration workbook.
Set up the Business Rule Condition in the Rule Condition Set up View.
The rule criteria is set up in a measure based on business rule/condition. RDF CS GA’s condition dimension has four positions. It allows four conditions to be specified for a business rule. Implementors can modify the condition hierarchy file to allow more or less conditions per business rule.
Example 1
In this example, Beverage's Approval rule group has three rules:
Key item
High volume
Low volume
The key item are the item/store with HighPriority Item 01 ==1.
The high volume items are item/store combos satisfying (recent average sales 01>=200) && (historic average sales 01 >=100). If an item/store satisfying both key item condition and high volume items conditions, it will be associated with both Rules.
The low volume items are (recent average sales 01 <20)
Example 2
The Men's shoes –Approval rule group also has three rules:
Key item
High volume
Low volume
The key items are the item/store combos with (HighPriority Item 01 ==1 && class match 1312Casual).
The high volume items are the item/stores with recent average sales 01 >= condition Measure Value numeric 1
Note how the recent average sales 01 are not compared to a static value to decide high sellers. For maximum flexibility, the values to be compared to are stored in a measure, which can have multiple values.
The low volume items are the item/stores with recent average sales 01 <2
Differences
Beverage and Shoes were items with different sales pattern (grocery versus fashion). They would have different criteria. Condition measure value numeric 1 is RDF CS GA provided numeric measure based on class.
Implementors can set the values either through data load or rules. It allows the same condition to be used with different parameter values for items in different class. This conceptually similar to Example 2 regarding high sellers in Men's Shoes.
Condition Value Measures
RDF CS GA provides 10 condition value measures like Condition measure value numeric 1 out of the box. Six numeric measures, two string measures and two date measures. The implementor can specify which condition value measures can be available for selection per rule group type in the Rule Setup workbook through the RDF CS plug-in. The intersection of these 10 measures can be modified through changing labeled intersection in the configuration. These measures are listed in Table B-3.
Table B-3 Condition Value Measures
| Measure Name | Measure Label | Measure Type | Intersection |
|---|---|---|---|
|
condmeasvalnum1 |
Condition Measure Value numeric 1 |
real |
#condmeasvalintx1# |
|
condmeasvalnum2 |
Condition Measure Value numeric 3 |
real |
#condmeasvalintx2# |
|
condmeasvalnum3 |
Condition Measure Value numeric 3 |
real |
#condmeasvalintx3# |
|
condmeasvalnum4 |
Condition Measure Value numeric 4 |
real |
#condmeasvalintx4# |
|
condmeasvalnum5 |
Condition Measure Value numeric 5 |
real |
#condmeasvalintx5# |
|
condmeasvalnum6 |
Condition Measure Value numeric 6 |
real |
#condmeasvalintx6# |
|
condmeasvalstr1 |
Condition Measure Value String 1 |
string |
#condmeasvalintx1# |
|
condmeasvalstr2 |
Condition Measure Value String 2 |
string |
#condmeasvalintx2# |
|
condmeasvaldat1 |
Condition Measure Value Date 1 |
date |
#condmeasvalintx1# |
|
condmeasvaldat2 |
Condition Measure Value Date 2 |
date |
#condmeasvalintx2# |
Run the custom menu of validate Rule Setup and Assign Membership.
These actions will assign each item/store to business rules according to the conditions and rule group scope. Tune the conditions until the rule membership results are satisfying.
Set up the parameters associated with each business rule.
RDF CS GA has five parameters associated with the approval rule groups: the approve method and all the GA alert parameters. The GA alert parameters were average sales threshold. Calculation periods, error threshold and causal peak factor. In this example, approval method and error threshold were different by business rule.
The default approval method (defappmth01) can be Recent Sales versus Forecast. This is a commonly used approve alert. It is useful for both grocery and fashion.
The manual approve method can be assigned to key items in all approval rule groups. That means user would like to review all key item forecasts before approving them.
For high volume grocery item like beverage, last year sales versus forecast is selected as the approve alert.
For high volume items, lower error threshold is used in the approval alert calculation because higher forecast accuracy is expected from higher volume.
For parameters like approve method, RDF CS has a three-tier to allow user to specify its value. Default, Intermediate and Final. The default is a scalar measure. The intermediate is specified at subclass/region in RDF CS GA. The final is at sku_stor. For approval method, the default can be set as Recent Sales versus Forecast. The intermediate level can be left as no override. For item/stores that are associated with key item, will have the approval method at final (appmthovr01) automatically populated with Manual. For beverage item/stores that are associated with high volume, will have the approval method at final (appmthovr01) automatically populated with last year sale versus forecast.
The same applies to error threshold. The error threshold for item/store associated with High volume and low volume rules will be populated automatically with what is set for these parameter in the rule. When running RDF CS batch, default, intermediate and final parameters are merged to obtain the parameters fed into approval logic. If an item/store satisfying both key item condition and high volume items conditions, it will be associated with both Rules. When assigning parameters to the item/store, the rule with lowest priority number will take precedence.
In the current RDF CS batch flow, frcst_post consists of the following steps:
The system forecast is imported from RDX tables,
Adjust the system forecast to generate adjusted forecast.
Calculate attributes needed for Approval rule-group
Generate approval rule membership
Assign parameter values to sku/store based on rule membership
Run the approve alerts
Approval forecast and calculate the mask for unapproved item/store.
Calculate eligibility for navigation tier. All item/store with valid forecast and unapproved will participate in navigation grouping.
Calculate attributes needed for navigation rule groups
Generate navigation rule membership.
Assign navigation tier based on navigation rule membership.
From the previous flow, there are two important differences between approval and navigation.
Eligibility
First the item/stores that are eligible to be assigned to approval and navigation rules are very different. All item/stores that have a forecast are eligible to be assigned to approval rules. However, only the unapproved item/stores that have a forecast are eligible to be assigned to navigation rules.
An item/store can be unapproved for two reasons:
Its approval method is Manual.
Its approval method is an approve alert and the alert was triggered.
Attributes
Second the attributes used for approval and navigation rule groups are different. In RDF CS GA, the most important attribute used in the navigation rule group is the navigation variance.
The navigation variance is a GA calculated attribute. When calculating the approval alerts, we flag item/stores that were violated the approval business rule. For instance, an item/store is set to be approved using the forecast versus recent sales rule.
The threshold is 10%, meaning that a deviation of less than 10% is acceptable and the item/store is approved. However, the deviation is 15% - which becomes the navigation variance, so the item/store will go into the calculation of the navigation tiers. A navigation variance is calculated for every GA alert except for the max Sales Peak versus Frcsted Peak Factor. The reason is that all but this alert has variance calculated as percentage, while this one compares units.
A custom approve exception's variance is also included in the calculation.
To set up business rules for navigation perform the following steps.
|
Note: Steps 1-3 are the same as in How to Set Up Business Strategy for Approval and different for Steps 4-7. |
Same as How to Set Up Business Strategy for Approval Step 1.
Same as How to Set Up Business Strategy for Approval Step 2.
Same as How to Set Up Business Strategy for Approval Step 3.
Create the Business Rule Setup workbook.
Select navigation in the rule group type wizard to build the Rule Setup workbook for navigation. Implementors can set up rule description, rule priority and enable rules on the 1.Rule Enable View.
In this example, four business rules are set up for each navigation rule group. Each rule corresponds to one navigation tier. The number of navigation tier is defined in RDF CS plug-in input.
The rules are:
Urgent
Required
Optional
Informational
You can define the criteria that associate different item/stores to each rule later. If an item/store is associated with multiple business rules, the rule priority is used to establish the precedence. The rules with lower priority number will have higher precedence. The assigned rule priority must be within the range of priority upper bound and priority lower bound set up in the Rule Group Administration workbook.
Set up the business rule condition in the 2 Rule Condition Set up Worksheet.
The rule criteria is set up in a measure based on business rule/condition. RDF CS implementors can define the number of navigation tier and their labels through the RDF CS plug-in.
Example
In this example, Beverage's navigation rule group has four rules.
Urgent is defined as HighPriority Item 01 ==1
Urgent is for the most important item/store. Their approval method is manual, they must be reviewed and manually approved.
Required is defined as Navigation Variance 01>=0.45
Required is for the item/stores with highest variance between forecast and recent sales. They are more important to be reviewed than the ones with lower variance.
Optional is defined as Navigation Variance 01>=0.35
Required is for the item/stores with variance between 0.45 and 0.35. They are less urgent to be reviewed than Required
Informational is defined as Navigation Variance 01>0
Informational is for all the item/stores with variance between 0.35 and 0. They have lowest priority to be reviewed.
Run custom menus to validate Rule Setup and Assign Membership. These actions will assign each item/store to every business rule according to the conditions and rule group scope. Tune the conditions until the rule membership results are satisfying.
Set up the parameters associated with each business rule. RDF CS GA has Navigation Bucket as the only one parameter associated with the navigation rule groups.
The pick list for Navigation Bucket measure is created by RDF CS plug-in based on user inputted number of navigation tier and tier labels. Just assign the right navigation tier to the right rule. Commit the workbook.
During RDF CS batch, the Navigation Bucket's value will be assigned to the item/stores based on navigation rule membership and rule priority. The navigation buckets at sku/store are stored in a measure named navibuckets01.
The Forecast Review workbook has built in logic to create workbook alerts using navibuckets01. One workbook alert is created for each navigation tier. These workbook alerts are guiding users to review and approve item/stores in order of their importance, as well as by how much they have violated the approval business rules.
So far we have described about what RDF CS GA provides with the rule engine. It is fairly straightforward for implementors to add new business rule attributes and add their own business rule definitions for approval or navigation.
Suppose an implementor is perfectly happy with using RDF CS's default, intermediate and final setting of approve method and alert parameters and would want to totally bypass the rule based assignment for all or most of their items. The following needs to be set up:
Set runrulgeligga_CF_ to false. This will disable the GA generation of eligible mask for approve rule memberships (rulgeligmask_CF_).
Implement hook_populate_aprvrulg_eligiblemask_CF_ as a custom batch step to set rulgeligmask_CF_ to what the implementor desired.
Suppose an implementor would like to configure different navigation rules using custom calculation of navigation variance and custom attributes. The implementor can implement the hook_navi_attb_CF_ as a custom batch step.
Implementors should perform the following steps to add a custom rule group type.
In the RDF CS plug-in, from the final level attributes table, click within the business rule group type cell. A dialog displays a business rule group type table.
Click P to add a new Business Rule Group Type.
Type in a Rule Group Type Name and Label. The name is used as position name along Rule Group Type dimension so make sure it satisfies RPAS requirement for position names. The name need to be unique among all rule group type position names.
Assign parameters associated with the rule group type by clicking on the cell of user specified parameters. Another dialog allows implementors to add or remove parameters.
The Select Measures box in the My Business Rule Group Type View displays all GA parameter measures. Most of these measures were forecasting parameter at final. Any custom measure with intersection = forecast intersection without clnd dimension and have a valid db is available for selection too. For each selected measure, a measure at the business rule is created and added to the parameter for <rule group type> worksheet for user input.
Click within the condition value cell to open the dialog that lets you 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 intersection higher than forecast intersection without clnd dimension and have a valid db. The selected measures are used to construct the picklist for condition value (measure) in the Rule Setup workbook.
After the RDF CS configuration is regenerated, a parameter for <rule group type> worksheet is added to the Rule Setup workbook for that final level. You can set up rule groups and rules following the same process as approval and navigation.
|
Note: These steps also need a customized batch control file. |
Write custom rules to populate eligmask_RGT_ measure. _RGT_ is a token for the position name of the custom rule group type. Eligmask_RGT_ is a GA created Boolean measure that is based on forecast intersection without clnd dimension. It should be true for prod/loc that is eligible to assign to the business rules belong to the _RGT_ rule group type.
Write custom rules to populate rulgeligmask_CF_. rulgeligmask_CF_ is a boolean measure based on prod/loc/rule-group. The expression can be like the following:
rulgeligmask_CF_=if(RgrpMask_CF_,if(rgrptype=="_RGT_",eligmask_RGT_,false),false)
Run pregenrulemem and genrulemem_CF_ rule group
Call pmlookup_RGT_ rule group to assign parameter values based on business rule membership.
