Setup and Configuration

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 RI 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. `C_ODI_PARAM_VW` is the name of the table shown in Control Center.
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 RI will be populated (and thus require partitioning).
C_MODULE_EXACT_TABLE	Table used to configure partition strategies for certain tables in RI, 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 `COLLECT_STATS_JOB`.
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 intraday cycles.
C_SOURCE_CDC	Table used to configure and monitor both historical and ongoing integration to Planning applications through the Retail Insights data warehouse.

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 MFP or RDF implementations.

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 load excessive calendar periods (for example, 2 years before start of history load) as it creates unnecessary data in dropdowns and task flows. Do not set `START_DT` to be in the middle of a fiscal year that is in your calendar file. If you pick a `START_DT` that is later than the earliest period in your file, then the `START_DT` must fall on day 1 of a fiscal year, or the data will be incorrect when loaded. 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 `START_DT` is well before the start of the Fiscal Calendar.
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. Example: If your Fiscal end period is currently January 2025, then you could set the Gregorian `END_DT` to `20260101`. This will end the system calendar on `20251231` (December 31, 2025), because the `END_DT` itself is not used. Ending on the last day of a year ensures there are no incomplete months in the calendar.
SIL_DAYDIMENSION	WEEK_START_DT_VAL	Starting day of the week for both Gregorian and Fiscal calendars (1 = Sunday, 2 = Monday). 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 `FEBRUARY`. This will be used to display month names in RI reporting on the fiscal calendar. Default = `JANUARY`
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=`RAP_DATA_HIST.zip`
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	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 ‘Y’ to enable RI to automatically generate item-level reclass records. Can only be used in a non-RMS implementation. Requires that full product files are sent every day, to detect when an item moves between hierarchy positions even if no other change occurred.
GLOBAL	RI_INT_ORG_DS_MANDATORY_IND	Set to ‘Y’ to require input data on the Organization hierarchy interface for the batch to run. This will prevent the batch from executing if the data files were not uploaded properly for a given day or the file was missing from the upload.
GLOBAL	RI_PROD_DS_MANDATORY_IND	Set to ‘Y’ to require input data on the Product hierarchy interface for the batch to run. This will prevent the batch from executing if the data files were not uploaded properly for a given day or the file was missing from the upload.
GLOBAL	RI_LAST_MKDN_HIST_IND	Set to ‘Y’ to enable the Price fact columns for PMO (`LST_MKDN_RTL_AMT_LCL`, `LST_MKDN_DT`) to be populated during history loads. This will impact performance of the loads and is disabled by default.
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. Default = 1 day.
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 ‘Y’.
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 ‘Y’.
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 ‘Y’.
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 ‘Y’.
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 ‘Y’.

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 Demand Forecasting configurations for specifying custom planning levels to be used in the integration between MFP/RDF and RI (when RI will be used for reporting). The default parameters align with MFP/RDF 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.

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 a 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 to INPROGRESS 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, 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	`Y` or `N` value (default value is `Y`). Extended hierarchy refers to a 9-level structure with style and style/color as extra levels above SKU. This is used only for specific applications such as RDF, AP, IO, and PMO/OO. If you are not using one of the listed applications or you don’t have styles and style/colors, then you can ignore this parameter (the extended hierarchy won’t be used even if generated).
RSE	EXTENDED_HIERARCHY_SRC	Value can be set as either `RMS` or `NON-RMS`. Default value is `NON-RMS`. If using RMFCS or RMS-sourced data, or you are loading RAP with data in RMS-like format, change this value to `RMS`. 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 `PRODUCT.csv` file). All interface samples use RMS-formatted data, so change this parameter to `RMS` if you are following those guidelines.
PMO	PMO_PROD_HIER_TYPE	The hierarchy ID to use for the Offer Optimization product and the Forecasting module. AIF applications have 2 product hierarchies: `1` = Basic 7-level hierarchy without styles or colors `3` = Extended 9-level hierarchy with style/color Default value is `3`. If the extended hierarchy is enabled and you are using one of the apps listed above on `LOAD_EXTENDED_PROD_HIER`, keep this value as `3`. If you are not using the extended hierarchy (such as for MFP-only implementations), change this value to `1`.
RSE	PROD_HIER_SLSTXN_HIER_LEVEL_ID	This parameter identifies the extended hierarchy level at which sales transactions are provided (`7`-Style, `8`-Style/color or `9`-Style/color/Size). It MUST match the extended hierarchy leaf level. Default value is `9`. If you are not using the extended hierarchy then ignore this parameter, it will not be used.
PMO	PMO_AGGR_INVENTORY_DATA_FLG	Specifies whether inventory data is present and if it should be used when aggregating activities data for PMO/OO and forecasting (only some forecast types use inventory). Set this value to `N` if inventory data is not loaded or not needed for forecasting (inventory data is not used for MFP forecasting but it is required for other applications like Offer Optimization, Inventory Optimization and Retail Demand Forecasting). Default value is `Y`.

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.