| Oracle® Retail Size Profile Optimization Implementation Guide Release 14.1 E55738-01 |
|
 Previous |
 Next |
| Oracle® Retail Size Profile Optimization Implementation Guide Release 14.1 E55738-01 |
|
Previous |
Next |
This chapter provides information on the configuration changes that can be made for SPO. For some retailers, parts of the released version of the SPO configuration might fit perfectly. However, it is anticipated that changes are needed to make the SPO 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.
For information on the SPO configuration changes that can be made, see the following sections:
Figure 7-1 shows the CLND hierarchy in the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| YEAR | Year | Main | SSN |
| SSN | Half | Main | QRTR |
| QRTR | Quarter | Main | MNTH |
| MNTH | Month | Main | WEEK |
| WEEK | Week | Main | DAY |
| DAY | Day | Main | None |
| WOY | Week of Year | Alternate | WEEK |
The Calendar hierarchy represents time in all RPAS solutions. It is a required hierarchy. RPAS requires a dimension named day (Day). This level is not displayed in the solution. The Calender hierarchy is needed to store sales and inventory data. In the SPO configuration, they are defined along the week (Week) dimension.
Seasonality values may be stored at various levels along the Location and Product hierarchies; however, they are all stored along only one level of the Calendar hierarchy. In the SPO configuration, seasonality is defined along the week (Week) dimension.
A retailer implementation might store sales/inventory data along some other level on the Calendar hierarchy. However, this level should represent a core or primary calendar hierarchy level, rather than an alternate hierarchy dimension such as week-of-the-year that aggregate, non-sequential positions from the calendar.
Other than abiding by these constraints, a retailer implementation can structure the Calendar hierarchy in any way that best suits the retailer's functional needs. Dimensions other than day and week have been included in the SPO configuration for the purpose of illustration. They can be modified or removed without requiring changes to any other elements of the SPO configuration. Other dimensions and hierarchy branches may also be added without requiring changes to other elements of the SPO configuration.
Figure 7-2 shows the PROD hierarchy in the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| CMMP | Company | Main | DVSN |
| DVSN | Division | Main | PGRP |
| PGRP | Group | Main | DEPT |
| DEPT | Department | Main | CLSS |
| CLSS | Class | Main | SCLS |
| SCLS | Subclass | Main | SKUG |
| SKUG | Style | Main | SKUP |
| SKUP | Style/Color | Main | SKU |
| SKU | SKU | Main | None |
The Product hierarchy represents the retailer's merchandise (that is, merchandise that the retailer sells through its retail channels). SPO configuration requires the style/color and SKU levels in the hierarchy. SPO configuration uses the style/color level of this hierarchy extensively in workbook wizards, labeled intersections, rules, position queries, and measure values (Single Hier Select measures).
|
Note: Any changes to this hierarchy must be accompanied by changes to all the elements that employ the particular level that is being modified or removed. Adding levels or branches, or changing labels, should not require any changes to the SPO configuration. |
Figure 7-3 shows the LOC hierarchy in the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| COMP | Company | Main | CHN |
| CHN | Chain | Main | CHNL |
| CHNL | Channel | Main | AREA |
| AREA | Area | Main | RGN |
| RGN | Region | Main | DIST |
| DIST | District | Main | STR |
| STR | Store | Main | None |
The Location hierarchy represents the retailer's retail locations and their rollups.
Figure 7-4 shows the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| YSCD | Yearly Season Code | Main | SCD |
| SCD | Season Code | Main | ATCD |
| ATCD | Attribute Code | Main | None |
| BRND | SKU Grouping | Alternate | ATCD |
The ATTR hierarchy has the dimension of attribute code (ATCD) at its base with optional rollups to independent attribute dimensions. Season Code and sku grouping can be SKU attributes obtained from the retailer. The ATCD dimension will be a merged dimension between Season Code and sku grouping. The attribute code dimension is created by combining the Season Code and sku grouping dimensions into a single dimension. Each position in Attribute Code is a cross production of a position in Season Code and a position in sku grouping.
In this way, multiple retailer-defined attributes can be supported without exceeding the maximum number of measure dimensions. If more attribute dimensions are needed, the added attribute dimension must be the parent of ATCD dimension, and the positions of ATCD dimension must be the cross product of all of its parent dimensions.
The total number of positions in the ATCD dimension increases quickly as the number of attribute dimensions and sizes of the attributed dimensions increase. For example, two product attributes, brand and seasoncode are defined. If there are 7 brands and 2 seasoncodes, there will be 14 (7x2) positions of ATCD. Alternatively, if you have 5 attributes, each with 3 positions, there will be 243 (3x3x3x3x3) positions in ATCD.
Figure 7-5 shows the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| SLEN | Sub Size Range Length | Main | SIZN |
| SIZN | Sub Size Range | Main | SIZE |
| MSZN | Master Size Range | Alternate | SIZN |
| SIZE | Size | Main | None |
| MSIZ | Master Size | Alternate | SIZE |
Size dimension (SIZE) is the base dimension of the Size hierarchy in the SPO configuration. Size dimension rolls up to the sub size range dimension (SIZN) and the master size dimension (MSIZ). Sub size range rolls up to sub size range length (SLEN) and master size range (MSZN).
Size dimension has one-to-many map relationships between it and the SKU. This relationship is implemented as a string measure based on the SKU dimension holding the size external position names. This measure has to be loaded at domain build time and updated whenever there is a Product hierarchy change.
A measure ranks the sizes within a size range. For example, small is 1, medium is 2, large is 3, and extra-large is 4. This measure is based on size and needs to be updated when the size hierarchy is changed.
Figure 7-6 shows the SPO configuration.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| SZRL | Sub Size Range Length | Main | SZR |
| SZR | Sub Size Range | Main | None |
| MSZR | Master Size Range | Alternate | SZR |
The SIZR hierarchy is used for display purposes. SIZR defines the position query in the approve workbook so that only sizes under the same size range are displayed. It consists of sub size range, sub size range length, and master size range. It is relevant only in the workbook.
The base dimension in the hierarchy is sub size range duplicate (SZR). Sub size range duplicate rolls up to sub size range length duplicate (SZRL) and master size range (MSZR). The sub size range duplicate dimension is a copy of the sub size range dimension in the size hierarchy. The sub size range length duplicate dimension is a copy of the sub size range length dimension in the size hierarchy. The external position names have to be the same. The size range hierarchy needs to be in sync with the size hierarchy.
The sub size dimension can map to the sub size range duplicate dimension. This relationship is defined in a string measure based on the sub size dimension. The measure holds the sub size range external position names. This measure needs to be updated whenever there is a size hierarchy change.
Generation IDs are the numbered identifiers scenarios or slots that can be used for generating and storing size profiles. The positions are reused.
The GIDH hierarchy is used to save the size profile results from multiple runs. Generation ID (GID) is configured as a single dimension with the number of positions equal to the number of runs to be saved.
The valid range for the generation ID is 1 to 35. This allows for the creation of Generation IDs in the range G1 to G9 and GA to GZ.
The SPO configuration has three Generation IDs defined—G1, G2, and G3.
Escalation levels are the number of distinct aggregation levels at which size profiles are calculated and stored. The ELH hierarchy is used to group the escalation levels together. It is a single dimension hierarchy. The only dimension is Escalation Levels (ELVL). Most profile generation and post-processing parameters are based on ELVL.
The ELVL dimension corresponds to the escalation level metric in the SPO configuration. All the escalation level metrics, except XXL, should be a position along the escalation level dimension. XXL is only a metric in the RPAS Configuration Tools. It is used to compose a measure name. It has no representation in the configuration and should not be a position along the escalation level dimension.
The SPO configuration has 10 escalation levels defined. The external position names are L01, L02, …, L10. In the SPO configuration, up to L99 is supported.
Cluster IDs are the numbered identifiers for groupings, or clusters, of stores which use the same size profile. A Junk cluster ID is required for the hierarchy. This cluster ID is used for those hierarchy members who values are all NA in the source data.
There are eleven clusters defined in the GA SizeOpt configuration: clusters 1-10 and the Junk Cluster.
The prepack optimization module addresses the optimization of not only the number of units within a pack, but also the size ratios for each style-color within the pack. This enables the product to be tailored to the consumer selling patterns at each specific location.
For information on the prepack optimization configuration changes that can be made, see the following sections:
Pack hierarchy is used for exporting Pre-Pack results to Assortment Planning. Pack hierarchy (PCC) has only one dimension PACK (pkct). It stores the number of packs.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| PKCT | Pack | Main | None |
Complex Pack hierarchy represents the user-defined complex pack content. CPCK has only one dimension, Complex Pack (cpak). It stores the maximum number of possible complex packs. The maximum number can be defined using the configuration plug-in.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| CPAK | Complex Pack | Main | None |
Figure 7-7 shows the Prepack ID configuration. The PRPK hierarchy is used to export prepack configuration to AP.
During the domain build and patch time, the SPO prepack ID hierarchy is generated based on the maximum number of pack types and maximum number of deliveries.
When any of the preceding factors changes, the prepack ID hierarchy must be updated. Prepack optimization provides an executable file that must be run against a domain to generate prepack ID hierarchy files and prepack definition output files to AP or other external solutions. The exported prepack ID hierarchy file is generated based on the populated prepack definition results and optimization levels in the SPO domain. The exported prepack hierarchy files can be loaded into the SPO domain, but it is not used in the prepack optimization and thus it is not necessary.
Delivery Pack ID dimension (DPID) rolls up to the Generic Pack ID dimension (GPID), which in turn rolls up to the Prepack dimension (PACK), which is the root dimension.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| PACK | Prepack | Main | GPID |
| GPID | Generic Prepack ID | Main | DPID |
| DPID | Delivery Prepack ID | Main | None |
Prepack Type hierarchy represents the maximum number of possible complex pack types. The maximum number is set to 6; but it can be changed using the configuration plug-in.
PCKT has the Prepack Type (pkty) dimension.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| PKTY | Prepack Type | Main | None |
Optimization Level hierarchy represents a list of predefined prepack optimization levels. OPTL has only one dimension, Optimization Level (OLVL). This hierarchy is generated using the user-defined values in the configuration plug-in.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| OLVL | Optimization Level | Main | None |
Profile hierarchy represents the size profiles that is used to spread the demand at the style-color/store/week down to style-color/size/store/week. There are two positions along the profile dimension- clustered size profile and store size profile.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| PRFT | Profile Type | Main | None |
Data source hierarchy represents the input data that enables the solver to determine optimal prepack definition. In the GA configuration, two data source measures are available- planned receipts and last years sales. The implementer can change the data source measure labels and data source position labels through the inputs in plug-in.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| SRCT | Data Source Type | Main | None |
A product can have multiple deliveries during its life time. Delivery hierarchy represents the delivery schedules for a product. The maximum number of deliveries is specified by the user, in the plug-in. The delivery hierarchy and dimension are generated based on the user inputs.
| Name | Label | Hierarchy Type | Child |
|---|---|---|---|
| DELV | Delivery | Main | None |
