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 Checklist

A high-level outline of the setup process is provided below to describe the activities to be performed in this chapter. Perform these steps in the order listed and do not skip them, as they are critical to implementing all Analytics and Planning applications. These steps highlight the minimum required activities to use your applications.

Table 2-1 RAP Configuration Checklist

Step	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.
Access the Control & Tactical Center	The Manage System Configurations UI inside the Control & Tactical Center is where you will set and update all system configurations for AI Foundation data and applications. Verify that you can access the screen and review the list of configuration tables.
Update the AIF data settings in the C_ODI_PARAM table	From the Manage System Configurations UI, locate the `C_ODI_PARAM` table. Update all of the parameters highlighted in the C_ODI_PARAM Initialization section to align with your implementation plan.
Configure the system languages	From the Manage System Configurations UI, update the `W_LANGUAGES_G` table and the associated `LANGUAGE_CODE` parameter in `C_ODI_PARAM` to align with your primary language code.
Configure core AIF application settings	From the Manage System Configurations UI, locate the `RSE_CONFIG` table. Update all of the parameters highlighted in the Application Configurations section to align with your implementation plan.
Review and update all other optional system settings	The AIF data warehouse has many optional configurations, such as the `W_GLOBAL_CURR_G` table, which you may want for your project. Do not proceed with the rest of your implementation until you have thoroughly reviewed and updated the other parameters in this chapter as needed.

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 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 `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 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.
W_GLOBAL_CURR_G	Table used to configure optional currencies that should be supported in Retail Insights reports, in addition to the primary and local currencies captured on the individual transaction records.
C_DML_AUDIT_LOG	Audit table used to track updates to the `C_ODI_PARAM` table by users from APEX or Control Center.

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 `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. 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 `END_DT` will be automatically updated based on subsequent loads of `CALENDAR.csv` to ensure the `END_DT` is never earlier than the last date in the file. 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, 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 `FEBRUARY`. This will be used to display month names in RI reporting on the fiscal calendar. Default = `JANUARY`
GLOBAL	CURRENCY_CODE	Set the default currency code used when loading CSV-based fact data files if none are provided in 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_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	PO_PACK_LEVEL_IND	Controls the RDE purchase order item level. When set to `Y`, extracts purchase orders from MFCS at pack item level. When set to `N`, pack items are converted to their components. Default value is `N`, meaning that all PO data is extracted at component item level and packs are split into their components. This setting may be updated for Inventory Planning & Optimization (IPO) projects where pack items will be allocated or transferred at pack level.
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 AIF foundation loads to automatically generate item-level reclass records from your hierarchy data. From version 24 onwards, this is the default method to handle reclasses. Requires that the product file in the nightly batch include any reclass changes so the system can detect when an item moves between hierarchy positions even if no other change occurred. Default = `Y`.
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 LPO (`LST_MKDN_RTL_AMT_LCL`, `LST_MKDN_DT`, `LST_PROMO_RTL_AMT_LCL`, `LST_PROMO_DT`) to be populated during history loads. This will impact performance of the loads and is disabled by default.
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 `Y` to enable. If this is not enabled, items that are dropped from the product interface are immediately closed and deactivated and cannot be re-opened. 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	RI_LOC_CLOSE_AFTER_DAYS	The number of days a location record will be kept active after it has been dropped from the inbound interfaces such as `ORGANIZATION.csv`. After the number of days is passed, the location will be closed, marked inactive, and may not be re-added to the file again. Default = 0
SIL_RETAILINVPOSITIONFACT	INV_FULL_LOAD_IND	Control the Inventory Position fact load behavior. When set to `N` it uses the incremental update behavior where it requires just the changes to inventory to be posted, including zeros. When set to `Y`, it assumes full nightly snapshots are being loaded and automatically zeroes out all inventory positions not sent for that load. Default = `N`.
SIL_RETAILPOONORDERFACT	PO_FULL_LOAD_IND	Control the Purchase Order fact load behavior. When set to `N` it uses the incremental update behavior where it requires just the changes to POs the be posted, including zeros. When set to `Y`, it assumes full nightly snapshots are being loaded and automatically zeroes out all POs not sent for that load. Default = `N`.
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`.

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 to Y and RI_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 and PO_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. New environments will only be created with the US language code in place. If your application users will not be using English as their primary language, then you will need to delete the default record and add a new row having both the LANGUAGE_CODE and SRC_LANGUAGE_CODE as your primary language code. This newly added language code must also be updated on the C_ODI_PARAM parameter LANGUAGE_CODE. If using Merchandising Foundation Cloud Service, then you must also align these settings with the primary language code of that application.

If you add more than one language code to W_LANGUAGES_G, translatable data like product names will automatically have database records created for every supported language in the configuration table, even if the data you are providing is not translated into those languages. This creates significant amounts of data in your translation lookup tables, which may not serve any real purpose for your implementation. For this reason, it is best to only have the primary language record in W_LANGUAGES_G unless you will have users that switch between multiple languages and you will also be providing data in multiple languages.

C_MODULE_ARTIFACT Initialization

Note:

In version 25, manual partitioning steps have been deprecated and replaced by automated partitioning. The automated partitioning that runs in history load processes such HIST_INV_LOAD_ADHOC does not rely on the ACTIVE_FLG or PARTITION_FLG values set below, it will perform partitioning even if the flag value is N. However, manual partition jobs such as those in the CREATE_PARTITION_ADHOC process do rely on these flags, so it is still necessary to review these configurations at the start of a new implementation project.

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 require this setup step before you start loading data. You should perform this step regardless of which application modules you are implementing, because all foundation data passes through this architecture. Partitions will be automatically generated at runtime. For example, when you load sales transaction history, the fact load will create partitions to hold the incoming data based on the configurations in this table.

Before you run any jobs to load data into RAP, you must validate this table has all rows set to ACTIVE_FLG=Y and PARTITION_FLG=Y with the exception of the SLSPRFC module, which should not be partitioned at this time and must have flag values of N instead. Additionally, you must validate the date set on column PARTITION_HISTORY_DATE is sufficient for your planned range of history data. The value of PARTITION_HISTORY_DATE must fall within the planned range of your fiscal calendar, but earlier than the first day of historical data you plan to load. For example, if your fiscal calendar starts in the year 2020 but you don’t intend to load data until 2022, then you could select 2021-01-01 as the value of PARTITION_HISTORY_DATE on all rows. The partitioning steps of some data load programs will fail if the PARTITION_HISTORY_DATE is set earlier than the start of your calendar or later than the data you are loading.

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 may 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 as specified in C_ODI_PARAM (DAY or WEEK). To manually setup this table, 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

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).

There is a support utility available to automate these updates. Use the function call below to setup the configurations for any flexible plan or fact table to be either DAY or WEEK level. Existing partitions will be dropped and all data purged in order to reconfigure the interface.

BEGIN
RI_SUPPORT_UTIL.CONFIGURE_CAL_LEVEL_FOR_TABLE(p_table_name => 'W_RTL_PLAN1_PROD1_LC1_T1_F', p_cal_level => 'WEEK');
END;

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, 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	`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 AP, IPO, and LPO. 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 Lifecycle Pricing 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 LPO 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 Lifecycle Pricing Optimization and Inventory Planning Optimization). 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.