Oracle® Retail Demand Forecasting Cloud Service Implementation Guide Release 23.1.101.0 for Windows F76812-02 |
|
Previous |
Next |
RDF is part of the Retail Analytics Platform (RAP) and imports the forecast generated by the Retail Science Engine (RSE). The RDF application is tailored towards the workflow of a Forecast Analyst. Whereas the data scientist would interact with the RSE UI to set low level forecast tuning parameters. The following sections describe the overall implementation flow and whether it is configured on the RDF side or RSE side.
The following information must be considered before configuring Demand Forecasting Cloud Service:
Before implementing RDF Cloud Service, an implementor should first answer the following questions listed in Table 2-1
Table 2-1 Configuration Considerations and Applications
Consideration | Applications |
---|---|
Is my forecasted item Long Lifecycle (LLC) or Short Lifecycle (SLC)? |
RSE |
What is the purpose of my forecast? To drive replenishment, allocation, or others? |
|
Are there any promotions that impact my forecast? If yes, how can I define the promotions? |
RSE |
Based on the purpose of my forecasting, which level should the forecast be generated on (sku/stor/week)? How many escalation levels are needed for the forecasting? Which level should the forecast be exported to? |
RDF, RSE |
What data is available to use for forecasting: rsal, psal, csal, Promotions, or Price? |
|
What kind of preprocessing is needed: Outage, Outlier, Depromote, or Deseasonalize Smooth? |
RSE |
How do I want to handle New Items? Is there any product attribute information? |
RDF |
Do I want to integrate RDF Cloud Service with other Applications? |
RDF, RSE |
If I want to use grouping in my escalation levels, how do I group my item/stores? |
RDF, RSE |
Do I need to generate daily forecast, and/or both weekly and daily forecasts? |
RDF, RSE |
Do I have a foundation system to provide foundation (hierarchy) data? |
Depending on the answers to the previous questions, the implementor can use the RDF Cloud Service plug-in to generate RDF Cloud Service configurations. For details about how to generate RDF Cloud Service configuration, refer to Chapter 3, "RDF CS Configuration". The generated RDF Cloud Service configuration can be customized to satisfy client specific requirement. For details about how to customize RDF Cloud Service configuration, refer to Chapter 4, "RDF Cloud Service Extensibility".
Note: In order to implement planning applications on RAP, you should ensure their foundation data such as Product and Organization hierarchies, align with RMF CS (Merchandising Systems) so thatthe foundation and transactional data can be used by all applications in RAP. They can have additional alternate dimensions than available in RMF CS (Merchandising Systems), if it is needed for their planning solution. Customers can use the flex fields available in RAP Foundation files to interface this additional data. Also, if multiple planning applications like MFP, AP CS, or RDF reside in the same PDS, then the common hierarchies should have the same dimension names to share the data interfaced from RAP. However additional non-shared dimensions can be present in each application. |
There are four type of hierarchies in RDF Cloud Service:
This is the foundation data to build any RPAS solution. Demand Forecasting Cloud Service requires the standard three hierarchy files, Calendar, Product, and Location. Additional sets of hierarchy files specific to different solutions may also be needed. The standard hierarchy files for Calendar, Product, Location and Product Attributes need to be loaded into the RI interface. Refer to the Data Requirements section in the Oracle Retail Analytics Platform Implementation Guide.
Note: The following format only shows the hierarchy structure used by RDF. The file to be loaded needs to conform to the RI interface. The user provides standard RPAS hierarchy files. |
For information on the hierarchy files, see the following sections:
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
DAY | Day | Main | None |
WEEK | Week | Main | DAY |
MNTH | Month | Main | WEEK |
QRTR | Quarter | Main | MNTH |
HALF | Half | Main | QRTR |
YEAR | Year | Main | HALF |
DOW | DAY OF WEEK | Alternate | DAY |
WOYR | Week of Year | Alternate | WEEK |
STDB | STD/BTA | UDA | WEEK |
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
SKU | Item | Main | None |
SKUP | Style/Color | Main | SKU |
SKUG | Style | Main | SKUP |
SCLS | Sub-Category | Main | SKUG |
CLSS | Category | Main | SCLS |
DEPT | Department | Main | CLSS |
PGRP | Group | Main | DEPT |
DVSN | Division | Main | PGRP |
CMPP | Company | Main | DVSN |
VNDR | Vendor | ALT | SKU |
PAT1 | Prod Attribute 1 | UDA | SKU |
PAT2 | Prod Attribute 2 | UDA | SKU |
STA1 | Style UDA 1 | UDA | SKUG |
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
STOR | Location | Main | None |
DSTR | District | Main | STOR |
REGN | Region | Main | DSTR |
CHNL | Area | Main | REGN |
CHAN | Chain | Main | CHNL |
COMP | Company | Main | CHAN |
SFMT | Store Format | Alternate | STOR |
STCL | Store Class | Alternate | STOR |
SAT1 | Store Attribute 1 | UDA | SAT1 |
SAT2 | Store Attribute 2 | UDA | SAT2 |
The product attributes hierarchy represents attributes associated with products. These attributes are used to group products within categories.
This hierarchy is intended to capture all product attributes for all product types. The attributes are then assigned to individual products. This assignment is used to calculate similarity scores between items.
The retailer needs to load the Product Attributes into the RI interface. Refer to the Attribute Files section of the Oracle Retail Analytics Platform Implementation Guide.
In RDF, the Product Attribute hierarchy structure is described in this section.
Name | Label | Hierarchy Type | Aggs |
---|---|---|---|
PATV | Prod Attribute Value | Main | None |
PATT | Prod Attribute | Main | PATV |
The following table describes the fields in this file.
Field | Description |
---|---|
Prod Attribute Value | The various values that an attribute might have. For example, the package type attribute might take the values bag, box, or convenience. |
Prod Attribute | The name of a product attribute, such as brand, family type, flavor, grain, package type, size, or temperature. |
The implementor or retailer can update these RDF Cloud Service hierarchy files. The GA RDF Cloud Service package contains these hierarchy files.
For information on the hierarchy files, see the following sections:
These hierarchies can be classified into two categories:
Hierarchies that are configured in Retail Science and RDF:
Hierarchies that are configured only in RDF:
The group hierarchy is an internal application-specific hierarchy to divide item/stores into different grouping to use during parameter estimation and forecasting. You can customize this hierarchy during implementation and use the GA dataset hierarchy as a reference. Users can add or change how many groups are allowed in the domain through modifying the group hierarchy data file.
File name: grph.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Description |
---|---|
GRPD | This is the grouping to use during estimation and forecast. |
Example:
111,Time Series Group 111 112,Time Series Group 112 113,Time Series Group 113 114,Time Series Group 114 115,Time Series Group 115
This is attribute hierarchy used in the Business Rule Engine functionality. Note that this is different from the PATR (Product Attribute) hierarchy. This hierarchy file is a hybrid between user-loaded attributes and RDF GA calculated attributes generated by the plug-in. Refer to the Appendix: RDF CS Business Rule Engine for detailed information on Business Rule Engine.
File name: atth.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
ATTD | Attribute | Main | None |
ATDT | Attribute Data Type | Alternate | ATTD |
ATSC | Attribute Source | Main | ATTD |
ATST | Attribute Source Type | Main | ATSC |
ATTP | Attribute Type | Alternate | ATTD |
Example:
attd,attd_label,atdt,atdt_label,atsc,atsc_label,atst,atst_label,attp,attp_labelbrand,Brand,3,String,ldprdattstr01,loaded Product Attribute 01,load,Loaded Attribute,prod,Product Attributeregn,Region,3,String,regn,region of location Hierarchy,hier,Hierarchy Attribute,loc,Location Attribute
This hierarchy structure is used to associate Business Rules within a Business Rule Group in the Business Rule Engine functionality. The GA hierarchy file loads five placeholder Business Rules per Rule Group. The implementor can customize this file, based on the maximum number of rules the retailer would like to define per Business Rule Group. Refer to the Appendix: RDF CS Business Rule Engine for detailed information on Business Rule Engine.
File name: rulh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
RULD | Business Rule | Main | None |
RULG | Business Rule Group | Main | RULD |
Example:
ruld,ruld_label,rulg,rulg_labelr001,Rule 1,g001,Rule Group 1r002,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
This is the Condition hierarchy used to organize the strategies (conditions) in defining a business rule. Refer to the Appendix: RDF CS Business Rule Engine for detailed information on Business Rule Engine.
File name: conh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
COND | Rule Condition | Main | None |
Example:
cond,cond_labelcond01, condition 01cond02, condition 02cond03, condition 03cond04, condition 04
This hierarchy contains the Group Sets used for the Grouping functionality. It is configured in RSE and needs to be imported from Retail Science.
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
GLVL | Group Level | Main | None |
Example:
glvl,glvl_labelsrate01,clss/regn/week for Rate of Sales level 1ptier01,scls/chnl/week for Price Tier level
This hierarchy represents the offer/promo fields. If promo has been enabled in Retail Science this hierarchy will be imported during the batch. Refer to the Chapter 5, "RAP Integration" for detailed information. If promo is not enabled in Retail Science, then the retailer can upload the GA offer hierarchy file. Note that the offer hierarchy needs to be populated for the Forecast Review workbook to build.
File name: offh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
offd | Offer | Main | None |
prmd | Promo | Main | offd |
camd | Campaign | Main | prmd |
offa | Offer Alias | ALT | offd |
cama | Campaign Alias | ALT | camd |
This hierarchy represents the reward type that can be associated per offer. If promo has been enabled in Retail Science this hierarchy will be imported during the batch.Refer to the Chapter 5, "RAP Integration" for detailed information. This hierarchy is needed to build the Offer Analysis workbook. This workbook is useful only if promo is enabled.
File name: rdth.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
rdtp | Reward Type | Main | None |
The RDF Cloud Service plug-in generates this hierarchy files based on the RDF Cloud Service configuration:
This hierarchy file defines the Business Rule Group Types associated with a Final Level. Please refer to the RDF Business Rule Engine Appendix of this guide for detailed information on Business Rule Engine.
File name: flvh.hdr.csv.dat
File format: comma-separated values file
The following table describes the fields in this file.
Name | Label | Hierarchy Type | Parent |
---|---|---|---|
RGTP | Business Rule Group Type | Main | None |
FLVL | Final Level | Main | RGTP |
Example:
rgtp,rgtp_label,flvl,flvl_labelaprv01,approve 01,01,01 Weekly Units Forecastnavi01,navigation 01,01,01 Weekly Units Forecast
The PROR and LOCR internal hierarchies are mirrored hierarchies of the PROD and LOC hierarchies. They are also referred as PROD RHS and LOC RHS. In the RPAS Cloud Edition versions 19.0 and later, PROR and LOCR are considered as virtual hierarchies. Refer to the Oracle Retail Predictive Application Server Cloud Edition Configuration Tools User Guide for information on Virtual Hierarchies.
Since these hierarchies are virtual, you do not have to load the hierarchy files. All of the other operations remain the same. You can register measures on PROR and LOCR and include them in workbooks.
Notes about these virtual hierarchies:
PROR and LOCR hierarchies have been marked as virtual in the GA configuration.
We cannot define security dimension on a virtual hierarchy or make them translatable.
Virtual hierarchies cannot have user defined dimensions.
If a retailer is upgrading from a pre-19.0 RDF version, then RDF will automatically mark them as virtual and conform to the virtual hierarchy requirements.
A detailed data set is required to use the capabilities of RDF Cloud Service to its fullest. Some of the data required is relatively easy to obtain, for example, information about sales. To simplify the data integration, all measure files are configured to be loaded as one measure per file. Each measure's data must be present in a separate file and the file name must be the same as the measure name with the .csv.ovr
extension. All files must be in csv format. During the initial domain build, all data files marked as required are needed with historical data to build the domain.
Because many RPAS measure names and intersections are dynamically generated by RDF Cloud Service plug-in. Tokens will be used to represent the RDF Cloud Service level names. The labeled intersection were also listed for measure intersection
Table 2-2 lists the Token names.
Table 2-2 Token Names
Token Name | Description |
---|---|
_CF_ |
Forecast Final Level Name, such as 07 |
#LLC_frcst_L_# |
Forecast final level intersection generated by plug-in based on user specified plug-in input parameters |
#LLC_frcstTS_L_# |
Forecast final level timeseries intersection = LLC final level intersection – clnd dim generated by plug-in based on user specified plug-in input parameters |
#LLC_seascurve_L_# |
Forecast level intersection – clnddim + woyr generated by plug-in based on user specified plug-in input parameters |
#SLS_INTX# |
Sales History intersection. This labeled intersection is user defined |
#SLSNC_INTX# |
Sales History intersection -clnd dim This labeled intersection is user defined |
#NIT_ATT_WGT# |
Attribute weight intersection, generated by plug-in based on user specified plug-in input parameters |
#NIT_SKU_ATT# |
Product attribute intersection, generated by plug-in based on user specified plug-in input parameters |
#NIT_SKUSTR_INTX# |
New Item assignment intersection, generated by plug-in based on user specified plug-in input parameters |
#PRESLS_INTX# |
Forecast Preprocessing data source input intersection |
Table 2-3 lists the measure names and descriptions. The measure field descriptions include:
Module Used
This field explains which solution is using the file. The possible values can be: All, New Item, and Forecast.
Required or Optional Required
This field means the data is necessary. Optional means that during data load and, if not loaded, certain functionality which uses those measures cannot be used. All administration measures are marked as Optional for data load, since those can be directly set in the Admin workbooks as well.
Load Frequency
This specifies the suggested frequency for the data load. It uses the following values:
W - Weekly
A - Anytime as needed or when the values change in source system; it can be weekly, monthly, quarterly, or yearly
Data Source
This specifies the typical data source to get that measure data:
RI - Oracle Retail Insights or equivalent Data Warehouse solutions
Admin - Data can be set by Administrator based on customer data referencing sample data in GA domain.
RDF, IPCS - Oracle Retail Planning Cloud Service or equivalent. Can be readily loaded from RMS or derived from data loaded from RMS.
ORASE - Oracle Retail Advanced Science. Those are the derived measure files extracted from ORASE integration files.
RMS - Oracle Retail Merchandising System or equivalent. Can be readily loaded from RMS or derived from data loaded from RMS.
3P - Third-party data aggregator such as Nielsen or Symphony IRI.
Load Intersection
Most of the time, the load intersection of the measure is the same as the base intersection of the measure. When the field is empty, the load intersection is the same as base intersection.
Table 2-3 RPAS Measure Names and Intersections
Measure Name | Measure Description | Base Intersection | Measure Type | Module Used | Required or Optional | Load Frequency | Data Source | Load Intersection |
---|---|---|---|---|---|---|---|---|
rsal |
Regular Sales |
#SLS_INTX# |
Real |
all |
Required |
Weekly |
RMS/RI |
#DAYSLS_INTX# |
psal |
Promotion Sales |
#SLS_INTX# |
Real |
all |
Required |
Weekly |
RMS/RI |
#DAYSLS_INTX# |
csal |
Clearance Sales |
#SLS_INTX# |
Real |
all |
Required |
Weekly |
RMS/RI |
#DAYSLS_INTX# |
ldactivefcstitem |
Active Forecast Item Indicator |
#SLSNC_INTX# |
Boolean |
all |
Optional |
Weekly |
||
outlierind_CF_ |
Loaded OutLier Indicator |
#PRESLS_INTX# |
Boolean |
Preprocess |
Optional |
Weekly |
||
outageind_CF_ |
Loaded Outage Indicator |
#PRESLS_INTX# |
Boolean |
Preprocess |
Optional |
Weekly |
||
prdattT |
Product Attribute |
#NIT_SKU_ATT# |
String |
New Item |
Optional |
Weekly |
RMS/RI |
|
nitdattwgt |
Attribute Weight |
#NIT_ATT_WGT# |
Real |
New Item |
Optional |
Weekly |
||
nitfcststovr |
New Item Forecast Start Date |
#NIT_SKUSTR_ INTX# |
Date |
New Item |
Optional |
Weekly |
||
nisros |
New Item Base Rate of Sales |
#NIT_SKUSTR_ INTX# |
Real |
New Item |
Optional |
Weekly |
||
likeitemexmask |
Like Item Exclusion Mask |
#NIT_SKUSTR_ INTX# |
Boolean |
New Item |
Optional |
Weekly |
||
promoaggprof_ CF_ |
Promotion Aggregation profile for Forecast |
User provided during configuration time (Promo Aggprof Intx) |
Real |
LLC |
Optional |
Weekly/ Anytime |
||
basespreadprof_ CF_ |
Profile to spread forecast from week to day |
User provided during configuration time (Baseline Spread Prof Intx) |
Real |
LLC |
Optional |
Weekly/ Anytime |
||
The following measure can be edited in RDF Cloud Service workbooks. It can also be loaded if a data file is provided. |
||||||||
grpassignpos_CF_ |
TimeSeries Grouping membership for LLC. It shall contain group dimension position names. |
#llc_frcstTS_L_# |
String |
LLC |
Optional |
Weekly/ Anytime |
It is recommended that you have at least two full years of historical data for long life cycle forecasting and one full year of historical data for short life cycle forecasting.
Data is loaded into RDF Cloud Service using the Online Administration Tools, which in turn use standard RPAS utilities. For more information on loading and extracting data using Online Administration Tools, see the Oracle Retail Demand Forecasting Cloud Service Administration Guide
RDF Cloud Service is pre-configured to support the display of images for items and product attributes in the Forecast Review and New Item workbooks. Table 2-4 lists the dimension attribute measures used to load images.
Table 2-4 Labeled Intersections
Measure | Hierarchy | Dimension |
---|---|---|
skuimage |
PROD |
sku |
skupimage |
PROD |
skup |
skugimage |
PROD |
skug |
skurimage |
PROR |
skur |
skprimage |
PROR |
skpr |
skgrimage |
PROR |
skgr |
patvimage |
PATR |
patv |
pattimage |
PATR |
patt |
The Content Server exposes the client's image files placed into a particular directory as HTTP URLs. The images must be defined in the load file in an xml format. The images are available at:
http://{content server url}/imgfetch/{sub directory if defined}
The first field represents the SKU ID followed by the required image location. At a minimum, a thumb size image file must be loaded to show in the pivot table. However, both the thumb and full size images can be loaded.
10000010,"<image id=""main"" label=""Front View"">\<url size=""thumb"">http://msp00alq.us.oracle.com:9001/contentserver/imgfetch/sku_10000010_main_thumb.jpg</url></image>"
10000010,"<image id=""main"" label=""Front View"">\ <url size=""thumb"">http://msp00alq.us.oracle.com:9001/contentserver/imgfetch/sku_10000010_main_thumb.jpg</url> <url size=""full"">http://msp00alq.us.oracle.com:9001/contentserver/imgfetch/ sku_10000010_main_full.jpg</url></image>"
RDF Cloud Service is part of the Retail Analytics Platform (RAP). The foundation data needs to be loaded into the RI data interface. Any hierarchy or data specific for RDF can be loaded via the File Transfer Service (FTS).
To define workbook template security, the system administrator grants individual users, or user groups, access to specific workbook templates. Granting access to workbook templates provides users the ability to create, modify, save, and commit workbooks for the assigned workbook templates. Users are typically assigned to groups based on their user application (or solution) role. Users in the same group can be given access to workbook templates that belong to that group alone. Users can be assigned to more than one group and granted workbook template access without belonging to the user group that typically uses a specific workbook template. Workbook access is either denied, read-only, or full access. Read-only access allows a user to create a workbook for the template, but the user cannot edit any values or commit the workbook. The read-only workbook can be refreshed.
For more information on security, see the Oracle Retail Predictive Application Server Cloud Edition Administration Guide. For more information on data security in a cloud environment, see the Hosting Policy documents for the cloud solution.
Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market.
Oracle Retail applications have been internationalized to support multiple languages.
The RPAS platform supports associated solution extensions and solution templates.
A solution extension includes a collection of code and generally available configurations. Typically, solution extensions are implemented by a retailer with minimal configuration.
A solution template does not include code. A solution template is most typically implemented as a retailer configuration.
Oracle Retail releases the translations of the RPAS server and client, as well as strings from the solution extensions.
Translations of the solution templates are released. All templates have the ability to support multi-byte characters.
For more information on internationalization, see the Oracle Retail Predictive Application Server Cloud Edition Administration Guide.
Translations are available for RDF Cloud Service for the following languages:
English (United States, Great Britain, Canada, Australia)
Chinese (Simplified)
Chinese (Traditional)
Croatian
Dutch
French
German
Greek
Hungarian
Italian
Japanese
Korean
Polish
Portuguese (Brazilian)
Russian
Spanish
Swedish
Turkish
Note: For information about adding languages for the first time or for translation information in general, see the Oracle Retail Predictive Application Server Cloud Edition Administration. |