2 Setup and Configuration
The Setup and Configuration chapter provides parameters and steps for setting up a new Retail Analytics and Planning cloud environment. While the platform comprises many application modules (some of which you may not use), there are certain common processes and settings that are shared across all of them. It is critical to check and update these core settings before moving on to later implementation steps, as they will define many system-wide behaviors that could be difficult to change once you've started loading data into the platform.
Configuration Overview
A high-level outline of the setup process is provided below to describe the activities to be performed in this chapter.
Table 2-1 RAP Configuration Overview
Activity | Description |
---|---|
Learn the configuration tools |
The Retail Analytics and Planning has many tools available to support an implementation, such as Retail Home, POM, and APEX. Knowing how to use these tools is an important first step in the process. Review the Implementation Tools chapter for details. |
Verify Object Storage connectivity |
Generate access tokens for interacting with Object Storage and test the connection, as it is required for all file movement into and out of the Oracle cloud. Review the Implementation Tools chapter for details. |
Configure the system calendar |
Update the parameters that define the type and characteristics of your business calendar, such as the start and end dates RAP will use to define calendar generation. |
Configure the system languages |
Update the master list of supported languages that need to be present in addition to your primary language, such as the need for seeing data in both English and French. |
Configure history retention policies |
Certain data tables in Retail Insights that are leveraged by other applications on the platform have a history retention period after which some data may be erased. |
Configure application-specific settings |
All applications in the Retail Analytics and Planning have their own settings which must be reviewed before starting an implementation of those modules. |
Platform Configurations
This section provides a list of initial setup and configuration steps to be taken as soon as you are ready to start a new implementation of the Retail Analytics and Planning and have the cloud environments provisioned and generally available.
Several configuration tables in the RAP database should be reviewed before processing any data. A list of these tables is below, along with an explanation of their primary uses. The way to apply changes to these tables is through the Control & Tactical Center, as described in the section on Control & Tactical Center. The sections following this one provide the detailed configuration settings for each table listed below.
Table 2-2 Platform Configuration Table Overview
Table | Usage |
---|---|
C_ODI_PARAM (C_ODI_PARAM_VW) |
Table used to configure all Oracle Data Integrator (ODI) batch programs as well as
many Retail Insights and AI Foundation load properties. |
W_LANGUAGES_G |
Table used to define all languages that need to be supported in the database for translatable data (primarily for Retail Insights and AI Foundation Cloud Services). |
C_MODULE_ARTIFACT |
Table used for database table partitioning setup. Defines which functional areas within the data warehouse will be populated (and thus require partitioning). |
C_MODULE_EXACT_TABLE |
Table used to configure partition strategies for certain tables in the data warehouse, including the Plan fact used for loading plans and budgets to RI/AI Foundation. |
C_MODULE_DBSTATS |
Table used to configure the ad hoc manual stats collection program |
C_HIST_LOAD_STATUS |
Table used to configure historical data loads, configure certain ad hoc batch processes, and monitor the results of those jobs after each run. |
C_HIST_FILES_LOAD_STATUS |
Table used to track multiple zip files that are uploaded with sequence numbers in order to process them automatically through ad hoc flows. |
C_SOURCE_CDC |
Table used to configure and monitor both historical and ongoing integration to Planning applications through the Retail Insights data warehouse. |
C_DML_AUDIT_LOG |
Audit table used to track updates to the |
C_ODI_PARAM Initialization
The first table requiring updates is C_ODI_PARAM
because your system calendar is populated using the ODI
programs. This table is displayed as C_ODI_PARAM_VW
on the Manage System Configurations screen in the Control & Tactical Center. The following settings must be updated prior to using the platform. These settings
are required even if your project only includes Planning implementations. Changes to these settings are tracked using the
audit table C_DML_AUDIT_LOG
.
Table 2-3 C_ODI_PARAM Initial Settings
Scenario Name | Param Name | Configuration Guidance |
---|---|---|
SIL_DAYDIMENSION |
START_DT |
Start date for generating the Gregorian calendar (this is different from the fiscal calendar). Set 12+ months before the start of the planned fiscal calendar to provide adequate space for adjustments to the fiscal calendar starting period. Do not set Example: If your first Fiscal start date is in February 2020, then it would be fine to
start the Gregorian calendar on 20190101. Starting from the first day of a year ensures there
are no incomplete months in the Gregorian calendar. Note that If you are loading the calendar directly from Merchandising, refer to section Using RDE for Calendar Setup (Gen 2 Architecture). |
SIL_DAYDIMENSION |
END_DT |
End date for generating
the Gregorian calendar (this is different from the fiscal calendar), non-inclusive. Set 6-12 months beyond the expected end
of the fiscal calendar to ensure the final year of that calendar does not extend beyond the available dates. The Example: If your Fiscal end period is currently January 2025, then
you could set the Gregorian |
SIL_DAYDIMENSION |
WEEK_START_DT_VAL |
Starting day of the week for both Gregorian and Fiscal calendars (1 = Sunday, 2 = Monday, and so on through 7 = Saturday). The default calendar setup uses a Sunday-to-Saturday week. |
GLOBAL |
START_OF_YEAR_MONTH |
The name of the Gregorian month associated
with the first fiscal period in your business calendar. For example, if your fiscal year starts 06-FEB-22 then set this to Default = |
GLOBAL |
RI_OPTIONALLY_ENCLOSED_BY |
Note: This parameter is deprecated in the new RAP architecture and was replaced by CTX file parameters. Set a character to use for wrapping text strings in data files, such as a quotation mark ("), to allow column delimiters to occur within the strings without causing any failures in the load process. The recommended value is " |
GLOBAL |
CURRENCY_CODE |
Set the default currency code used when loading CSV-based fact data files if none are provided on the files themselves. Defaults to ‘USD’. |
GLOBAL |
HIST_ZIP_FILE |
Change the default name for the ZIP file package used by the history file load process. Default= |
GLOBAL |
LANGUAGE_CODE |
Default language code used by the system to load data. Do not change unless your source systems are using a non-English primary language in their database and datasets. Default=EN |
GLOBAL |
RI_PART_DDL_CNT_LIMIT |
The maximum number of partitions to create during the initial setup run. The average initial setup of the calendar may need 50k-150k partitions. The recommended value is 500000 (meaning max 500k partitions) |
GLOBAL |
RI_INV_HIST_DAYS |
The number of days to retain a zero-balance record on inventory positions. Excessive retention of zero balances can cause batch performance issues due to high data volumes. But dropping the records too soon may be detrimental to your business reporting or analytical processes if you make use of zero-balance information. Default=91 days. |
GLOBAL |
RA_INV_WAC_IND |
Controls the RDE inventory cost calculation. When set to Y, it will use Weighted Average Cost (WAC) as the item cost for all items. When set to N, it will dynamically load Merchandising valuation methods set per department or item and apply them, choosing from average cost, unit cost, or retail-based cost. |
GLOBAL |
RA_INV_TAX_IND |
Controls the RDE retail calculation and removal of tax amounts from retail valuation of stock on hand and on-order amounts. When set to N, only simple VAT (SVAT) calculations are supported and taxes are included in the values. When set to Y, the system dynamically loads Merchandising global tax and VAT information and applies it by item/location to remove taxes. |
GLOBAL |
RA_SLS_TAX_IND |
Controls the RDE retail calculation and removal of tax amounts from retail valuation of sales amounts. When set to N, it is generally VAT-inclusive on the Retail amounts (but not profit amounts, which never include VAT). When set to Y, the system dynamically loads Merchandising VAT information and applies it by item/location to remove VAT taxes from all sales retail and discount amounts. |
GLOBAL |
RI_CLOSED_PO_HIST_DAYS |
The number of days to retain closed purchase orders on the daily positional snapshots. Closed purchase orders may be important for reporting or analytical processes, but typically are not needed as they do not impact your open on-order calculations. Default=30 days. |
GLOBAL |
RI_GEN_PROD_RECLASS_IND |
Set to |
GLOBAL |
RI_INT_ORG_DS_MANDATORY_IND |
Set to |
GLOBAL |
RI_PROD_DS_MANDATORY_IND |
Set to |
GLOBAL |
RI_LAST_MKDN_HIST_IND |
Set to |
GLOBAL |
RI_ITEM_REUSE_IND |
Enable or disable the ability to re-use
item numbers over time to represent entirely new items. Also enables retention of existing items for a number of days, so
that if an item drops and reappears quickly, it is not considered a new item and will continue to use the existing records.
Set to Default = N |
GLOBAL |
RI_ITEM_REUSE_AFTER_DAYS |
The number of days between when an item is deleted and when it’s allowed to appear as a new item having the same ID. This will trigger the old version of the item to be archived in the data warehouse using an alternate key, so the new version of the item is treated as completely new. For example, setting this to 5 days means that an item can be dropped/deleted and after 5 days, when the same items comes again it will be treated as a brand new item. If the item re-appears in the data before 5 days has passed, it will be treated as the same item as before and the existing item data remains active. Default = 0 |
GLOBAL |
ITEM_PARENT_DIFF_SEPARATOR |
Set the field separator used when
constructing the Default = _ |
GLOBAL |
PDS_PROD_INCLUDE_ITEM_ID |
Control whether item identifiers
are included in the PDS product labels or not. When set to a value of |
GLOBAL |
PDS_EXPORT_DAILY_ONORD |
Determines whether the |
SIL_RETAILINVPOSITIONFACT |
INV_FULL_LOAD_IND |
Control the Inventory
Position fact load behavior. When set to |
SIL_RETAILPOONORDERFACT |
PO_FULL_LOAD_IND |
Control the Purchase Order
fact load behavior. When set to |
SIL_RETAIL_COHEADDIMENSION |
RI_MIS_COHEAD_REQ_IND |
Seed missing customer
order (CO) head IDs from sales fact to CO Dimension. If you are providing customer order IDs on your sales history load, make
sure to set this to |
SIL_RETAILCOLINEDIMENSION |
RI_MIS_COLINE_REQ_IND |
Seed missing customer
order (CO) line IDs from sales fact to CO Dimension. If you are providing customer order line IDs on your sales history load,
make sure to set this to |
SIL_EMPLOYEEDIMENSION |
RI_MIS_CASHIER_REQ_IND |
Seed missing Cashier
IDs from sales fact to Employee dimension. If you are providing employee IDs on your sales history load, make sure to set
this to |
SIL_RETAILCUSTOMERDIMENSION |
RI_MIS_CUSTOMER_REQ_IND |
Seed missing
customer IDs from sales fact to Customer dimension. If you are providing customer IDs on your sales history load, make sure
to set this to |
SIL_RETAILPROMODIMENSION |
RI_MIS_PROMO_REQ_IND |
Seed missing promotions
from the sales promo fact to the Promotion dimension. If you are providing promotion IDs on your sales history load and not
providing a Promotion file, make sure to set this to |
The following key decisions must be made during this initial configuration phase and the proper flags updated in C_ODI_PARAM:
-
Item Number Re-Use – If you expect the same item numbers to be re-used over time to represent new items, then you must update
RI_ITEM_REUSE_IND
toY
andRI_ITEM_REUSE_AF TER_DAYS
to a value >=1. Even if you are not sure how item re-use will occur, it’s better to enable these initially and change them later as needed. -
Tax Handling – Both for historical and ongoing data, you must decide how tax will be handled in fact data (will tax amounts be included or excluded in retail values, what kind of tax calculations may be applied when extracting history data, and so on). You may or may not need any configurations updated depending on your RDE usage.
-
Full vs Incremental Positional Loads – In nightly batches, the core positional fact loads (Purchase Orders and Inventory Positions) support two methods of loading data: full snapshots and incremental updates. You must decide which of these methods you will use and set
INV_FULL_LOAD_IND
andPO_FULL_LOAD_IND
accordingly. Incremental updates are preferred, as they result in lower data volumes and faster nightly batch performance; but not all source systems support incremental extracts.
If you are using RDE to integrate with Merchandising, pay special attention to the global tax and WAC configurations, as these control complex calculations that will change how your data comes into RAP. These options should not be changed once you enable the integrations because of the impact to the daily data. For example, a large European retailer with presence in multiple VAT countries may want the following options:
-
RA_INV_WAC_IND = N
- This will dynamically calculate inventory cost using all three Merchandising cost methods instead of just using WAC -
RA_INV_TAX_IND = Y
- This will enable the removal of tax amounts from retail values so inventory and PO reporting is VAT-exclusive -
RA_SLS_TAX_IND = Y
- This will enable the removal of tax amounts from retail values so sales reporting is VAT-exclusive
Retail Insights contains many additional configurations in the C_ODI_PARAM
table that are not necessary
for platform initialization, but may be needed for your project. This includes Merchandise Financial Planning and IPOCS-Demand
Forecasting configurations for specifying custom planning levels to be used in the integration between MFP/IPO and RI (when
RI will be used for reporting). The default parameters align with MFP/IPO default plan outputs, but if you are customizing
them to use a different base intersection, then you must also update those values in C_ODI_PARAM
. Refer to
the Retail Insights Implementation Guide for complete details on Planning Configurations.
W_LANGUAGES_G Initialization
The W_LANGUAGES_G
table controls all the languages supported in the translatable database data. This
applies to areas such as product names, location names, attribute values, season/phase descriptions, and other text-based
descriptors. Additional languages are used mainly by Retail Insights, which supports displaying data in multiple languages
in reporting and analytics. It is required to delete all languages from this table that will not be used because every language
code in this table will have records generated for it in some interfaces, creating unnecessary data that can impact system
performance. Starting with version 23.1.201.0, new environments will only be created with the ‘US’ language code in place;
but if you are on an earlier version then you must manually delete all other entries that will not be used.
For example, product names will automatically have database records initialized for every supported language in this configuration
table, even if the data you are providing does not contain any of those languages. This creates significant amounts of
data in your product descriptions table, which may not serve any real purpose for your implementation. If you are only
using a single primary language, then you can safely delete all but one row from W_LANGUAGES_G
. The default
row to preserve is the one with a language code of US
which is used for American English.
C_MODULE_ARTIFACT Initialization
The C_MODULE_ARTIFACT
table is used by the database to configure table partitioning. Many tables
in the platform are partitioned based on the business calendar (usually by calendar date or fiscal week) and this partitioning
must be performed immediately after the business calendar is loaded. You should perform this step regardless of which application
modules you are implementing, because all foundation data passes through this architecture.
Before running partitioning procedures, you must validate this table has all rows set to ACTIVE_FLG=Y
and PARTITION_FLG=Y
with the exception of W_RTL_PLANFC*
tables (PLANFC module) and SLSPRFC module,
which should not be partitioned at this time and must have flag values of N
instead.
You also must choose whether you are planning to load the Planning facts (such as W_RTL_PLAN1_PROD1_LC1_T1_FS
) for plan/budget data in RI or AI Foundation. If you are not using the table right away, you should also disable the PLAN
modules, like PLAN1. You can revisit this setup later to perform additional partitioning as needed.
C_MODULE_EXACT_TABLE Initialization
The C_MODULE_EXACT_TABLE
table is used for defining flexible partitioning strategies on certain tables.
Most data in this table can be left as-is, but you must update this table if you plan to load Planning or Budget information
into the W_RTL_PLAN1_PROD1_LC1_T1_FS
interface. The partition level must align with the data level of your
plan (day or week). To configure the plan partitions, you must update the table C_MODULE_EXACT_TABLE
where MODULE_CODE = PLAN1
. Modify the columns PARTITION_COLUMN_TYPE
and PARTITION_INTERVAL
to be one of the following values:
-
If your input data will be at Day level, set both columns to
DY
-
If your input data will be at Week level, set both columns to
WK
You must then enable the partitioning process in C_MODULE_ARTIFACT
by locating the row for MODULE_CODE=PLAN1
and setting ACTIVE_FLG=Y
and PARTITION_FLG=Y
. If your plan data will extend into the future,
you must also change PARTITION_FUTURE_PERIOD
to the number of future months that need partitions built (for
example, use a value of 6M
to partition 6 months into the future).
C_HIST_LOAD_STATUS
The C_HIST_LOAD_STATUS
table is used to track the progress of historical loads of data, primarily inventory
position and pricing facts. You should edit the following fields on this table based on your implementation needs:
-
HIST_LOAD_LAST_DATE
– Specifies the planned final date for the end of your historical loads (for example, the end of the 2-year period you plan to load into RAP). The history load programs will assume that you are providing each week of inventory in sequence from earliest to latest and process the data in that order. -
ENABLED_IND
– Turns on or off a specific table load for historical data. Most of the tables in these processes are only required for Retail Insights, and the rest can be disabled to improve performance. Set to a value of N to disable a table load. -
MAX_COMPLETED_DATE
– The load programs use this to keep track of the last loaded week of data. It does not allow you to reload this week or any prior week, so if you are trying to start over again after purging some history, you must also reset this field. -
HIST_LOAD_STATUS
– The load programs uses this to track the status of each step in the load process. If your program gets stuck on invalid records change this field back toINPROGRESS
before re-running the job. If you are restarting a load after erasing history data, then you need to clear this field of any values.
If you are implementing Retail Insights, then enable all INV and PRICE modules in the table (set ENABLED_IND
to Y
). If you are only implementing AI Foundation or Planning application modules, then the following history
tables should be enabled; all others should be disabled (set ENABLED_IND
to N
).
-
W_RTL_PRICE_IT_LC_DY_F
-
W_RTL_PRICE_IT_LC_DY_HIST_TMP
-
W_RTL_INV_IT_LC_DY_F
-
W_RTL_INV_IT_LC_WK_A
-
W_RTL_INV_IT_LC_DY_HIST_TMP
After enabling your desired history load tables, update the value of HIST_LOAD_LAST_DATE
on all rows you
enabled. Set the date equal to the final date of history to be loaded. This can be changed later if you need to set the date
further out into the future.
As you load data files for one or more weeks of history per run, the value of MAX_COMPLETED_DATE
and HIST_LOAD_STATUS
automatically update to reflect the progress you have made. If you need to restart the process
(for example, you have loaded test data and need to start over with production data) these two columns must first be cleared
of all data from the Control Center before beginning the history load again.
C_SOURCE_CDC
The C_SOURCE_CDC
table is used for changed data capture (CDC) parameters for the integrations between
the Retail Insights data warehouse and the Planning application schemas. In general, this table is updated automatically as
batches are run. However, it is important to know when you may need to modify these values.
For most interfaces, the table will initially have no records. The first time an integration batch program runs, it will
take all the data from the source table and move it to the export table. It will then create a C_SOURCE_CDC
record for the target table name, with a value for LAST_MIN_DATE
and LAST_MAX_DATE
matching
the timeframe extracted. On the next run, it will look at LAST_MAX_DATE
as the new minimum extract date and
pulls data greater than that date from the source table. If you are performing history loads for tables, such as Sales Transactions,
you may need to change these dates if you have to re-send data to Planning for past periods.
Specifically for positional data (at this time only Inventory Position), the usage is not quite the same. Positional data
will always send the current end-of-week values to Planning, it does not look at historical weeks as part of the normal batch
process. A separate historical inventory integration program is provided in an ad hoc process, which will allow you to send
a range of weeks where LAST_MIN_DATE
is the start of the history you wish to send, and LAST_MAX_DATE
is the final date of history before normal batches take it forward. It is common to load inventory from end to end in isolation
as it is a data-intensive and time-consuming process to gather, load, and validate inventory positions for multiple years
of history.
W_GLOBAL_CURR_G
The W_GLOBAL_CURR_G table is used by Retail Insights to support up to three additional currencies in reporting and aggregation (other fields above 3 are not used at this time). RI pre-populates global currency fields in all aggregation tables based on the specified currency codes. The desired codes are added to one row in this table and must align with the Exchange Rates data provided separately. This table is available from the Control & Tactical Center and is not a required configuration for any project unless you wish to report on additional currencies in Retail Insights.
Example data to be inserted to this table:
DATASOURCE_NUM_ID | TENANT_ID | GLOBAL1_CURR_CODE | GLOBAL2_CURR_CODE | GLOBAL3_CURR_CODE | GLOBAL1_RATE_TYPE | GLOBAL2_RATE_TYPE | GLOBAL3_RATE_TYPE | DEFAULT_LOC_RATE_TYPE |
---|---|---|---|---|---|---|---|---|
1 |
DEFAULT |
INR |
AED |
PEN |
Corporate |
Corporate |
Corporate |
Corporate |
Application Configurations
In addition to the platform configurations defined above, each application on the platform has its own system and runtime options that need to be reviewed and updated. The information below will guide you to the appropriate content for each application’s configuration options.
Retail Insights
Retail Insights has a significant number of configurations, primarily in the C_ODI_PARAM_VW
table in the
Control Center, which controls batch processes and reporting behaviors throughout the application. If you are implementing
Retail Insights as part of your project, review the “Setup and Configuration” chapter of the Retail Insights Implementation
Guide.
AI Foundation Cloud Services and Forecasting
Each AI Foundation application has parameters that are specific to the batch processing, data movement, algorithms, and user interfaces of those modules. These configurations are stored in several database tables available through the Control & Tactical Center. If you are implementing any AI Foundation applications as part of your project, review the Retail AI Foundation Cloud Services Implementation Guide.
If you are implementing any planning application (Merchandise Financial Planning, IPOCS-Demand Forecasting, or Assortment Planning), then you are required to configure and use the Forecasting module in the AI Foundation application interface. This requires initial configurations to select forecast parameters, as well as post-data load configurations to select forecast data levels and perform testing of the chosen algorithm. For basic information about Forecasting and what the AI Foundation application functionality can support, refer to the “Manage Forecast Configurations” section in the AI Foundation User Guide.
To configure the forecast process for Planning, use the Manage System Configurations screen in the Control Center to review and modify the configurations in RSE_CONFIG. These values can be set up now, but you cannot complete the rest of the forecasting process until your foundation data has been loaded into AI Foundation.
Appl Code | Parameter Name | Description |
---|---|---|
RSE |
LOAD_EXTENDED_PROD_HIER |
|
RSE |
EXTENDED_HIERARCHY_SRC |
Value can be set
as either Data loaded using
the RAP foundation CSV files can be provided in either an RMS or non-RMS format, but RMS format is preferred (as detailed
later in this document for the |
PMO |
PMO_PROD_HIER_TYPE |
The hierarchy ID to use for the Lifecycle Pricing Optimization product and the Forecasting module. AIF applications have 2 product hierarchies:
Default value is |
RSE |
PROD_HIER_SLSTXN_HIER_LEVEL_ID |
This parameter
identifies the extended hierarchy level at which sales transactions are provided ( |
PMO |
PMO_AGGR_INVENTORY_DATA_FLG |
Specifies whether inventory data is present and if it should be used when aggregating activities data for LPO and forecasting (only some forecast types use inventory). Set this value to |
Planning Platform
Planning Applications such as MFP (Merchandise Financial Planning) can be set up using the Planning Platform (RPASCE). It allows customers to use a Standard GA template version or configurable planning solution versions. Refer to the Planning application-specific Implementation Guides for more details about these options.