| Oracle® Retail Assortment Planning Implementation Guide Release 14.1 E55310-01 |
|
 Previous |
This chapter provides information on the configuration changes that can be made for AP. For some retailers, parts of the released version of the AP configuration might fit perfectly. However, it is anticipated that changes are needed to make the AP configuration match the organization of the retailer.
Hierarchies are limited to the determination of hierarchy aspects that pertain directly to dimensions, attributes, facts, and escalation. Due to RPAS limitations on intersection, distinct hierarchies must exist for the construction of all intersections to support all facts. No more than one dimension from any hierarchy can exist in a measure intersection. Some dimension, position ID, and position Label must match what is configured in the GA solution, otherwise, it needs to be updated to match the hierarchies. See the Oracle Retail Predictive Application Server Configuration Tools User Guide for details on how to use the configuration tool.
For information on the configuration changes that can be made, see the following sections:
Table 9-1 shows the structure of the Calendar hierarchy in the AP configuration.
Table 9-1 Calendar Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
day |
Day |
Main |
|
week |
Week |
Main |
|
mnth |
Month |
Main |
|
ssn |
Half |
Main |
|
year |
Year |
Main |
|
woy |
Week of Year |
Alternate |
The Calendar hierarchy represents the time in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.
Assortment Planning requires the Day, Week, and WOY dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for Day, Week, and WOY. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.
Table 9-2 shows the structure of the Assortment hierarchy in the AP configuration.
The Assortment Hierarchy is a vital part of the Assortment Planning process that represents the planning periods (grouping of weeks). This hierarchy is maintained within Assortment Planning and is not interfaced from other systems. The system administrator should maintain this file and load it when required. Looks no longer being used should be purged from the hierarchy and new Looks required for planning should be added. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements and purging information.
Assortment Planning requires the dimensions Look and Look Group. The recommendation is to not change the dimension ID (RPAS Name) for Look and Look Group. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.
Table 9-3 shows the Product hierarchy in the AP configuration.
Table 9-3 Product Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
sku |
Style-Color |
Main |
|
skug |
Style |
Main |
|
scls |
Subclass |
Main |
|
clss |
Class |
Main |
|
dept |
Department |
Main |
|
pgrp |
Group |
Main |
The Product hierarchy represents the retail items in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.
Assortment Planning requires the Style-Color, Style, and Subclass dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for sku, skug, and scls. Other dimensions and hierarchy branches could be added, without changes re quired to other elements of the Assortment Planning configuration.
Table 9-4 shows the Cluster hierarchy in the AP configuration.
Table 9-4 Cluster Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
clus |
Cluster |
Main |
|
clst |
Cluster Parent |
Main |
|
chn2 |
Cluster Group/ |
Main |
|
szgp |
Space Group |
Alternate |
The Cluster Hierarchy is required to support the GA clustering workbook which provides the process to cluster stores based on performance and store attributes. It is recommended to not alter the cluster hierarchy, as every dimension is important in the overall Assortment Planning configuration logic. The dimension labels can be changed if required.
The clrh.csv.dat file also must be kept as is in the GA solution. This ensures the correct workings of Store Clustering.
|
Note: It is important for the Cluster Group/Channel (chn2) dimension to have a position ID/Label to match the position ID/Label of the Location hierarchy Channel (chnl). That is, 1,Brick & Mortar; 4,Direct. This is critical for mapping the data between the cluster hierarchy and location hierarchy. The Batch_GB rule group is hard-coded to use the Cluster Group/Channel label. If the label is changed from the GA cluster hierarchy, the rules in this rule group must be updated. |
Table 9-5 shows the Location hierarchy in the AP configuration.
Table 9-5 Location Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
str |
PoC |
Main |
|
rgn |
Region |
Main |
|
chn2 |
Channel |
Main |
The Location hierarchy represents the retailer Point of Commerce used in all RPAS solutions. This is a standard hierarchy interface required in all RPAS solutions. The file has the extension of hdr.csv.dat. Header extension allows you to have more columns in the file, but RPAS will load only the appropriate dimensions required in the solution. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the hierarchy load file format requirements.
Assortment Planning requires the Store and Channel dimensions, which have been hard-coded in the calc logic in the rules. The recommendation is to not change the dimension ID (RPAS Name) for str and chnl. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.
Table 9-6 shows the Product Attribute hierarchy in the AP configuration.
Table 9-6 Product Attribute Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
attr |
Product Attribute |
Main |
|
attg |
Product Attribute Group |
Main |
The Product Attribute hierarchy represents all the attributes associated to items. This enables the solution to provide the breakdown view of the plan by key attributes. This hierarchy is maintained within Assortment Planning. The configuration expects the following attributes to exist with the exact label of Silhouette, Fabric, Brand, and Embellishment. These attribute labels are hard-coded in the BW_Set_calc and
Shop_List_calc rule groups. If these labels need to change, the configuration needs to be updated to reflect the new labels.
The security dimension is set for Subclass. This can change to a higher or lower level if required by the business, however, the recommendation is to maintain at the Subclass level because most of the logic, within the GA configuration, is users having specific ownership of subclasses. See the Oracle Retail Predictive Application Server Administration Guide for the Fusion Client for details on the User Security workbook.
Table 9-7 shows the PoC Attribute hierarchy in the AP configuration.
Table 9-7 PoC Attribute Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
stra |
PoC Attribute |
Main |
|
strg |
PoC Attribute Group |
Main |
The Point of Commerce Attribute hierarchy represents all the attributes associated to the Point of Commerce. This enables clustering by attributes associated to each Point of Commerce. This hierarchy is maintained within Assortment Planning. The configuration expects all the attributes defined in the satt.csv.dat file. These attribute labels are hard-coded in the AP_Setup_calc rule group. If these labels need to change, the configuration needs to be updated to reflect the new labels.
Table 9-8 shows the Color Attribute hierarchy in the AP configuration.
Table 9-8 Color Attribute Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
stra |
PoC Attribute |
Main |
|
strg |
PoC Attribute Group |
Main |
The Color Attribute hierarchy represents all the colors available for retailer items. This hierarchy is maintained within Assortment Planning. Both dimensions are used in the multiple calc rules, which means it should not be updated.
Table 9-9 shows the Consumer Segment hierarchy in the AP configuration.
The Consumer Segment hierarchy represents all the colors available for retailer items. This hierarchy is maintained within Assortment Planning. Both dimensions are used in the multiple calc rules, which means it should not be updated.
Table 9-10 shows the Picklist Position hierarchy in the AP configuration.
Table 9-10 Picklist Position (POS1) Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
ppos |
Picklist Position |
Main |
The Picklist Position (POS1) hierarchy is required in the solution to allow the user to define the product attribute values associated to each attribute. This hierarchy is maintained within Assortment Planning. The number of positions should be based on the maximum number of values required by an attribute. This dimension is used in multiple rule groups. Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration; but for this hierarchy, this would not be required.
Table 9-11 shows the Picklist Position hierarchy in the AP configuration.
Table 9-11 Picklist Position (POS2) Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
ppo2 |
Picklist Position |
Main |
The Picklist Position (POS2) hierarchy is required in the solution to allow the user to define the product attribute values associated to each attribute. This hierarchy is maintained within Assortment Planning. The number of positions should be based on the maximum number of values required by an attribute. This dimension is used in multiple rule groups. Other dimensions and hierarchy branches could be added without changes required to other elements of the Assortment Planning configuration; but for this hierarchy, this would not be required.
Table 9-12 shows the Picklist Position hierarchy in the AP configuration.
Table 9-12 Picklist Position (POS3) Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
ppo3 |
Picklist Position |
Main |
The Picklist Position (POS3) hierarchy is required in the solution to allow the user to define the PoC attribute values associated to each attribute. This hierarchy is maintained within Assortment Planning. The number of positions must be 8. This hierarchy and file must be used, as is, in the GA solution, which is created to work with the Cluster Hierarchy positions.
Table 9-13 shows the Fulfillment hierarchy in the AP configuration.
Table 9-13 Fulfillment Hierarchy
| RPAS Name | Label | Hierarchy Type |
|---|---|---|
|
ffch |
Child Fulfillment Option |
Main |
|
ffgr |
Parent Fulfillment Type |
Main |
The Fulfillment hierarchy represents the different types of fulfillment options. This hierarchy is maintained within Assortment Planning, however it needs to correspond to the fulfillment options available for data integration. The Sales, Gross Margin, and Customer Return data are expected to be loaded per the fulfillment option (at ffch level). Other dimensions and hierarchy branches could be added, without changes required to other elements of the Assortment Planning configuration.
Table 9-14 shows the Slot hierarchy in the AP configuration.
The Slot hierarchy hierarchy is used solely to support the time-phased view of the wedge. For this view, slot groups correspond to looks and slots represent style-colors offered as part of the look over time. Depending on the number of looks included in an assortment and the number of style-colors in each look, additional slot group and/or slot positions may need to be added to this hierarchy over time.
The algorithm that generates the time-phased view of the wedge depends on the two-tier structure of the hierarchy. Adding or removing levels will likely render the time-phased view of the wedge algorithm inoperable.
The Size and Pack hierarchies are interfaced from SPO. It should not change as it is defined in the GA solution.
