Mirror of Oracle documentation
Converted for search and offline reading. Authoritative source: Oracle. Diagrams and some complex tables are simplified — check the PDF when in doubt.
17 Configuration
This chapter describes the major application configuration points, including:
-
User Interface Authentication and Authorization
-
User Management Configuration: Configuring Users and Roles
-
Configuration
-
Internationalization
-
Affinity Analysis Configurations
Note
Since AA is distinct from the other applications, much of what is described here is not applicable for AA. For clarity, AA implementation, configuration, operations and data model are described separately in Affinity Analysis..
User Interface Authentication and Authorization
Note
For more information, see Oracle Retail AI Foundation Cloud Services Administration Guide .
For authorization, the applications have been built with role-based access. Access to application user interface components is done by assigning application roles. Application roles are defined as part of the application and deployed as part of the installation process. Application roles are mapped to enterprise roles during initial environment provisioning. Enterprise roles exist as LDAP groups in OID. Refer to the Oracle Retail AI Foundation Cloud Service User Guide for the definition of standard user roles.
User Management Configuration: Configuring Users and Roles
This section provides detailed instructions on setting up enterprise-level user management using Oracle WebLogic 12c with Enterprise Manager. The user management configuration is handled using the WLS Console and the WLS Enterprise Manager (EM).
User Roles
The roles listed in Table 17-1 are required to update the configurations in the data management section of the application. For more information, see Oracle Retail AI Foundation Cloud Services Administration Guide .
Table 17-1 Data Management Configuration Roles
| Roles | Access to Application Configuration |
|---|---|
| ANALYTIC_EXPERT_JOB | CDT |
| ANALYTIC_EXPERT_JOB | DT |
| CLUSTERING_ADMINISTRATOR_JOB | AC |
| CUSTOMER_SEGMENT_ADMINISTRATOR_JOB | CS |
| RETURN_LOGISTICS_JOB | RL |
| SOCIAL_ANALYTICS_JOB | SA |
| PRICING_ADMINISTRATOR_JOB | PRO |
| MARKET_BASKET_ANALYSIS_JOB | MBI |
Configuration
This section provides details about application configurations that can be modified as part of a deployment. The list of configurations is limited to those settings that most likely need to be reviewed and adjusted before the applications are used. Some configuration points cannot be adjusted after initial setup, so a careful review of the configurations should be done. For a complete list of configurable values, see the complete list of configuration values in RSE_CONFIG.
Any installation configuration must be set before the application is initialized with data and used.
Note
Before beginning any advanced customization, you must consult with development.
RSE_CONFIG Table
The RSE_CONFIG table is a generic table that contains various application configurations. The DESCR column describes the configuration and provides any relevant information regarding what each specific configuration controls. The APPL_CODE column is a useful filter to organize the configurations by the application module.
The following application abbreviations are used:
-
CDT - Customer Decision Trees
-
CIS - Advanced Clustering
-
DT - Demand Transference
-
IO -Inventory Planning Optimization
-
MBA - Affinity Analysis
-
PMO - Forecasting
-
PRO - Offer Optimization
-
RL - Return Logistics
-
RSE - Retail Science Platform (generic configurations)
-
SA - Social Analytics
-
SPO - Size Profile Optimization
-
SO - Space Optimization
-
The PARAM_NAME is the name of the configuration.
-
The PARAM_VALUE is the value currently associated with the configuration.
-
The CONFIGURABLE_FLG column indicates whether the configuration is safe to change.
-
The UPDATEABLE_FLG column is used to control whether application code is able to update the configuration.
Note
Use caution when changing a value that the application code can update after the application has started to be used.
The RSE_CONFIG_CODE table is an extension table to the RSE_CONFIG table. It allows for overrides of certain configurations when an additional qualifier is present. All descriptions for the columns in RSE_CONFIG apply here as well. The additional column CONFIG_CODE allows overriding a value for a specific qualifier. Application code does not always support the use of these configurations, but Affinity Analysis, for example, uses this to set up configurations for different hierarchy levels.
Generic Configuration
The following is a list of configurations that can be adjusted. This list does not include internal configuration values. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘RSE’.
Table 17-2 Generic Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CAL_PERIOD_LEVEL | 4 | This is the calendar hierarchy level that is used to drive the processing (installation configuration). | Usually this value should be set to the Fiscal Week level of the Fiscal Calendar. The number 4 refers to the fourth level in RSE_HIER_LEVEL table. This cannot be adjusted after initial setup. |
Table 17-2 (Cont.) Generic Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CMGRP_HIER_TYPE | 1 | The hierarchy ID to use for the CM Group (installation configuration). | If an alternate hierarchy is to be used, then this configuration must specify that hierarchy type. Otherwise it must reflect the primary product hierarchy type. The value represented here relates to the ID in RSE_HIER_TYPE. This cannot be adjusted after initial setup. |
| CMGRP_LEVEL_ID | 5 | The hierarchy level ID that contains the level of the product hierarchy where the CM Group level exists (installation configuration). | Once the CMGRP_HIER_TYPE is configured, this level must be set to indicate the level of the hierarchy (RSE_HIER_LEVEL) that defines the categories. |
| PRIMARY_LANGUAGE_CO DE | EN | The name of the language code to use for all RSE data sourced from AIF data warehouse tables (installation configuration). | Data values stored in the database are not multi- language capable, and are not affected by the UI language settings, like the UI labels are. This setting must select the language code for which data should be shown in the UI. |
| RA_FISCAL_CAL_ID | 1240 | ID of the calendar to use from AIF data warehouse since it supports multiple calendars (installation configuration). | This value must match the ID of the desired fiscal calendar loaded into W_MCAL_PERIOD_DS.M CAL_CAL_WID. |
| CHAIN_LEVEL_DESC | CHAIN | The description to use for any top level hierarchy element when one must be manually created. | This description must be adjusted if a different description for the top level of the hierarchy is desired. |
| DEFAULT_LOCALE | en_US | The default locale to use for rendering elements that cannot support multiple locales. | Adjust this value so that it contains the correct LOCALE setting for most users of the application. |
| DISPLAY_DATE_FORMAT | Mon dd, yyyy | The default date mask to be used by UI. | Adjust this so that the format of dates can be displayed as desired. |
Table 17-2 (Cont.) Generic Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| FAKE_CUST_DAY_TXN_TH RESHOLD | 10 | The maximum daily transaction threshold to identify a fake customer. | This setting must be adjusted to the maximum number of daily transactions that a normal customer usually has. This allows all other customers with higher transactions counts to be excluded from processing. |
| UI_TZ | America/ New_York | Timezone for display. Must match SELECT tzname FROM V$TIMEZONE_NAMES. | This setting must be adjusted so that it contains a proper time zone setting indicating where most users run the UI. |
Advanced Clustering Configurations
The following is a list of configurations that can be adjusted for the Advanced Clustering application. This list does not include internal configuration values. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘CIS’.
Store Exclusion can be used to filter and identify which stores are to be excluded for Clustering. To enable this functionality, EXCLUDE_LOC_ATTR is set by specifying a SHORT_DB_NAME from the RSE_BUSINESS_OBJECT_ATTR_MD BOAM) table in RSE_CONFIG. This can be configured via the Control and Tactical Center. Locations in RSE_LOC_ATTR table with the BUSINESS_OBJECT_ATTR_MD_ID value similar to the ID of from BOAM table, which is configured in the config table, will be excluded.
For example, EXLUDE_LOC_ATTR of RSE_CONFIG is set to CFA_ATTRIB_2345 as its value. A check is performed to fetch the ID from the BOAM table that contains this SHORT_DB_NAME. This ID is then used to obtain all locations from the RSE_LOC_ATTR table. These locations are then flagged to be excluded from clustering.
Table 17-3 AC Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| PERF_CIS_APPROACH | CDT | The approach to use for performance-based clustering. Available options are CDT and DT. | If the CDT application is in use, then this configuration must be set to CDT, which will result in the use of attribute groups for product attribute clustering. Otherwise, it must be set to DT, which will result in the use of the top raw attribute values. This cannot be adjusted after initial setup. |
Table 17-3 (Cont.) AC Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| ATTR_NAME_SEPARATOR | - | The separator character(s) to use to separate the different components of the attribute names in CIS_TCRITERIA_ATTR. | Adjust this value if a different separator is desired in the UI for attribute names built from multiple values. This cannot be adjusted after initial setup. |
| CIS_CONTR_SLS_SRC_CO LUMN | SLS_AMT | Source column for contribution BI chart sales values. SLS_AMT, SLS_QTY, PROFIT_AMT are the allowable values. | Adjust this value as needed so that the BI shows contributions based on the desired sales column. |
| CIS_CONTR_X_SRC_COL UMN | SLS_AMT | Source column for the x axis of the contribution BI chart. SLS_AMT, SLS_QTY, PROFIT_AMT are the allowable values. | Adjust this value as needed so that the BI shows contributions based on the desired sales column. |
| CIS_CONTR_Y_SRC_COL UMN | SLS_QTY | Source column for the y axis of the contribution BI chart. SLS_AMT, SLS_QTY, PROFIT_AMT are the allowable values. | Adjust this value as needed so that the BI shows contributions based on the desired sales column. |
| CIS_DFT_PIVOT_LVL | 6 | Default pivot level to show in explore data. | This configuration indicates the lowest level of the organization hierarchy (see rse_hier_level) that should be shown in the Explore Data pivot table. A value of 6 allows store locations to be visible, but this can be adjusted to a higher level if this level of detail is not desired. |
| CIS_IDX_AVG_SRC_COLU MN | SLS_AMT | Name of the column to use for index-to-average BI calculations. SLS_AMT, SLS_QTY, PROFIT_AMT are the allowable values. | Adjust this value as needed so that the BI shows index to averages based on the desired sales column. |
| CIS_NUMERIC_DFT | 0 | Default attribute value for numeric. | This can be adjusted so that attributes without a value are displayed with the desired value. This cannot be adjusted after initial setup. |
| CIS_STRING_DFT | UNKNOWN | Default attribute value for string. | This can be adjusted so that attributes without a value are displayed with the desired value. This cannot be adjusted after initial setup. |
Table 17-3 (Cont.) AC Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CIS_VARIABILITY_IDX_SR C_COLUMN | SLS_AMT | Name of the column to use for variability index BI calculations. SLS_AMT, SLS_QTY, PROFIT_AMT are the allowable values. | Adjust this value as needed so that the BI shows variability indexes based on the desired sales column. |
| DEFAULT_NUM_ATTR_VAL UE | 15 | Constant for number of discrete values allowed for store attribute clustering. | Any attribute that has more than this number of distinct categorical values is not available for use as an attribute. |
| DEFAULT_STR_CATEGORI CAL_ATTR | UNKNOWN | Default string description for row added in cis_tcriteria_attr_type_val ue table for unmatched grouping. | This can be adjusted so that attributes without a value are displayed with the desired value. This cannot be adjusted after initial setup. |
| EXCLUDE_LOC_ATTR | CFA_ATTR5_234 5 | Contains the name of a SHORT_DB_NAME from RSE_BUSINESS_OBJEC T_ATTR_MD table that is used to exclude specific stores that are in RSE_LOC_ATTR to be excluded from AC processing. | Setting this configuration to NULL disables the Store Exclusion interface. |
| INSIGHT_BI_SALES_AMT_ MARGIN | N | Flag to show sales BI based on sales amount and margin. | Either INSIGHT_BI_SALES_AM T_MARGIN or INSIGHT_BI_SALES_AM T_UNIT can be assigned a Y so that the BI displays the BI using the desired columns. |
| INSIGHT_BI_SALES_AMT_ UNIT | Y | Flag to show sales BI based on sales amount and units | - |
| MAX_HIST_WEEK_CNT | 104 | The maximum number of weeks that must be selectable by the UI when processing historic data. | - |
| MAX_ITEMS_IN_GRAPH_C LUSTER_DETAIL | -1 | Maximum number of clusters to be displayed in cluster details graph. | A value of -1 results in an unlimited number of values. Adjust if necessary. |
| MAX_ITEMS_IN_GRAPH_C LUSTER_LIST | -1 | Maximum number of clusters to be displayed in cluster list graph. | A value of -1 results in an unlimited number of values. Adjust if necessary. |
| MNG_RUN_NO_WKS | 26 | Display run for past n weeks. | - |
Table 17-3 (Cont.) AC Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| PERF_ATTR_TOPN_COUN T | 3 | The number of attribute values to be used per product category for performance-based clustering. | If PERF_CIS_APPROACH configuration is DT, then this configuration will limit the number of attribute values to this number of values with the greatest sales. |
| PERF_NUM_WEEKS_FOR_ SLS_SHARE | 16 | The number of weeks to be used while calculating the sales share for the product attributes. | - |
| PERF_NUM_WEEKS_FOR_ TOPN_CALC | 16 | The number of weeks to be used while identifying the top_n_attributes | - |
| SELECT_ALL_MERCH_NO DES | N | Flag to identify if all (or only first) merchandise node(s) to be selected by default. | - |
| SUMM_CAL_ALL_LVL | N | Flag to identify whether performance summarization allowed at all available calendar levels. | - |
| SUMM_MERCH_ALL_LVL | N | Flag to identify whether performance summarization allowed at all available merchandise levels. | - |
Customer Decision Tree Configurations
The following is a list of configurations that can be adjusted the CDT application. This list does not include internal configuration values. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘CDT’. See Customer Decision Trees for more details.
Table 17-4 CDT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CDT_CAL_LEVEL_ID | 4 | The hierarchy level ID that contains the level of the calendar hierarchy that | Normally, this configuration must be the same value as the |
| CDT operates on (should | common | ||
| equate to Week - Installation configuration). | CAL_PERIOD_LEVEL configuration. |
Table 17-4 (Cont.) CDT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CDT_CMGRP_LEVEL_ID | 5 | The hierarchy level ID that contains the level of the product hierarchy that CDTs are created for (installation configuration). | Normally, this must be the same setting as the common CMGRP_LEVEL_ID configuration. |
| CDT_LOC_HIER_TYPE | 2 | The hierarchy ID to use for location (installation configuration). | This setting must be set to use either the trade area hierarchy type or the organization hierarchy type. |
| CDT_LOC_LEVEL_ID | 4 | The hierarchy level ID that contains the level of the location hierarchy that CDTs are created for (installation configuration). | If CDT_LOC_HIER_TYPE is set to trade area, this must be set to a value of 2. Otherwise, it must be set to the level of the organization hierarchy for which CDT output is desired. |
| CDT_PROD_HIER_TYPE | 1 | The hierarchy ID to use for the CM Group (installation configuration). | Normally, this setting must be the same value as the common CMGRP_HIER_TYPE configuration. It can either be the primary product hierarchy or an alternate product hierarchy. |
| CDT_CALC_RAW_ATTR_SI M | Y | Determines whether or not to execute Raw Attribute Value Similarities routines. | If the AIF data warehouse has been loaded with raw attributes, then this setting must be set to Y to enable calculation of raw attr similarities. |
| CDT_UI_DEF_CALC_PARE NT_SEGMENT_FLG | Y | UI default for the calculate only parent consumer segments flag. | - |
| CDT_UI_DEF_CALC_PARE NT_TRADE_AREA_FLG | N | UI default for calculate only parent trade areas flag. | - |
| CDT_UI_DEF_CDT_SCORE _HIST_CNT | 20 | UI default for the number of histogram buckets for the CDT scores histogram. | - |
| CDT_UI_DEF_DATA_FILTE R_HIST_CNT | 20 | UI default for the number of histogram buckets for the data filtering histograms. | - |
| CDT_UI_DEF_EXCLUDE_C UST_CNT | 1000 | UI default for minimum require customer counts for pruning process. | - |
| CDT_UI_DEF_EXCLUDE_M IN_SCORE | 0.25 | UI default for minimum CDT score required for the pruning process. | - |
Table 17-4 (Cont.) CDT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| CDT_UI_DEF_EXCLUDE_S KU_CNT | 10 | UI default for minimum number of SKUs for the pruning process. | - |
| CDT_UI_DEF_EXCLUDE_T REE_LEVEL_CNT | 2 | UI default for minimum number of levels of the tree for the pruning process. | - |
| CDT_UI_DEF_LOWEST_EX PANSION_LEVEL | 15 | UI default for lowest number of levels allowed for a tree. | - |
| CDT_UI_DEF_MAX_CUST_ AVG_DY_TXN | 100 | UI default for maximum number of times more than average a customer’s daily transaction count can be. | - |
| CDT_UI_DEF_MAX_MISS_ ATTR_CNT | 3 | UI default for maximum number of missing attributes a SKU can have | - |
| CDT_UI_DEF_MIN_ATTR_S KU_CNT | 5 | UI default for minimum number of SKUs assigned to an attribute, to be used by the process. | - |
| CDT_UI_DEF_MIN_ATTR_V ALUE_SKU_CNT | 5 | UI default for minimum number of SKUs assigned to an attribute value, to be used by the process. | - |
| CDT_UI_DEF_MIN_CUST_ TXN_CNT | 0.01 | UI default for minimum number of transactions required for a customer, as a percent of the average number. | - |
| CDT_UI_DEF_MIN_NODE_I TEM_CNT_PCT | 0.05 | UI default for the minimum percent of SKUs required for a node of the tree before it is considered a terminal node. | - |
| CDT_UI_DEF_MIN_SKU_T XN_CNT | 0.01 | UI default for minimum number of transactions required for a SKU, as a percent of the average number. | - |
| CDT_UI_DEF_PRUNING_HI ST_CNT | 20 | UI default for the number of histogram buckets for the pruning histograms. | - |
| CDT_XML_PRECISION | 4 | Default precision of weight field in CDT XML. | Adjust this to control the amount of precision in the generated CDT XML files. |
| HISTOGRAM_DEFAULT_BI N_APPROACH | C | The default histogram bin approach (C = Custom, W = Width) | - |
Table 17-4 (Cont.) CDT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| HISTOGRAM_DEFAULT_NU M_BINS | 7 | The default number of bins to display for CDT histograms | - |
| MAX_NUM_WEEKS_FOR_ SIMILARITY | 104 | The maximum number of weeks of sales transaction data to be used by the similarity process. This prevents the process from using too much data. | Adjust this to reduce the use of too much input data for the process. Enabling a high number of weeks will result in slower performance; however, it may be necessary if suitable data is not available in a smaller number of weeks. |
Demand Transference Configurations
The following is a list of configurations that can be adjusted for the DT application. This list does not include internal configuration values. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘DT’.
Table 17-5 DT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| AE_CALC_INT_LENGTH | 8 | The number of weeks to group together for in an interval for the AE calculation. | This setting must be adjusted according to the data quality and quantity available for a customer. Higher values improve performance; however, it limits the amount of data available to be processed. |
| ATTRIBUTE_LIST_SEPARA TOR | - | A separator to be used to display a list of attributes in Similarity Calculation screen. | - |
| CDT_SIMILARITY_AVAILAB LE | Y | Whether CDT similarity has been made available to DT. | If the CDT application is being used, this setting enables DT to use the similarities that CDT may have calculated. |
| DT_CAL_LEVEL_ID | 4 | The hierarchy level ID that contains the level of the calendar hierarchy that DT operates on (should equate to Week). | Normally, this configuration must be the same value as the common CAL_PERIOD_LEVEL configuration. |
| DT_CMGRP_LEVEL_ID | 5 | The hierarchy level ID that contains the level of the product hierarchy that DTs are created for. | Normally, this must be the same setting as the common CMGRP_LEVEL_ID configuration. |
Table 17-5 (Cont.) DT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| DT_LOC_HIER_TYPE | 2 | The hierarchy ID to use for location. | This must be adjusted to trade area hierarchy or be left at the default organization hierarchy. |
| DT_LOC_LEVEL_ID | 4 | The hierarchy level ID that contains the level of the location hierarchy that DTs are created for. | If DT_LOC_HIER_TYPE is set to trade area, this must be set to a value of 2. Otherwise, it must be set to the level of the organization hierarchy for which DT output is desired. |
| DT_MDL_AP_EXP_WKS_B ACK_END | 1 | The number of weeks back from the last date that range data has been loaded for (PR_LOC_STATUS_LAST _COMPLETED_WK) to end using for model apply export. | Adjust this and MDL_AP_EXP_WKS_BA CK_START to control which weeks should be used during data export. |
| DT_PROD_HIER_TYPE | 1 | The hierarchy ID to use for the CM Group. | Normally, this setting must be the same value as the common CMGRP_HIER_TYPE configuration. It can either be the primary product hierarchy or an alternate product hierarchy. |
| DT_REMOVE_REDUNDAN CY | N | If set to Y, then remove redundancy while calculating attribute-based similarities. | - |
| DT_SIM_DISPLAY_ROWNU M | 9999999 | The number of distinct similarity values to show in the UI pop-up. Setting to a high number effectively eliminates this limit. | - |
| GENERIC_SEPARATOR | A separator to be used to display a list of items, for example. SKU prod_ext_code name. | This value is used in the UI to separate lists of items. For example, when a list of attributes is shown in the UI, they will be delimited by this value. | |
| HISTOGRAM_DEFAULT_BI N_APPROACH | W | The default histogram bin approach (C = Custom, W = Width). | - |
| HISTOGRAM_DEFAULT_NU M_BINS | 7 | The default number of buckets in the contextual BIs. | - |
Table 17-5 (Cont.) DT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| MAX_NUM_WEEKS_FOR_ ATTR_WGT | 104 | The maximum number of weeks of input data to use for calculating attribute weights. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
| MAX_NUM_WEEKS_FOR_ AVG_SLS | 104 | The maximum number of weeks of input data to use for calculating the average sales. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
| MAX_NUM_WEEKS_FOR_ FILTERING | 104 | The maximum number of weeks of input data to use for data filtering. Setting this value lower than the other MAX_NUM_WEEKS_FO R* configurations overrides those other configurations. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
| MAX_NUM_WEEKS_FOR_ MDL_CALC | 104 | The maximum number of weeks that should be used during model build calculation. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
| MAX_NUM_WEEKS_FOR_ MDL_UPDT | 104 | The maximum number of weeks that should be used during model build update calculation. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
| MAX_NUM_WEEKS_FOR_ SIMILARITY | 104 | The maximum number of weeks of input data to use for calculating similarity. | Setting this value to a higher value allows the use of more weeks of data, which will slow performance; however, enables better results for categories with infrequent sales. |
Table 17-5 (Cont.) DT Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| MDL_AP_EXP_WKS_BACK _START | 4 | The number of weeks back from the last date that range data has been loaded for (PR_LOC_STATUS_LAST _COMPLETED_WK) to start using for model apply export. | Adjust this and DT_MDL_AP_EXP_WKS _BACK_END to control which weeks should be used during data export. |
| PRUNED_CATEGORIES_S EPARATOR | , | A separator to be used to display a list of pruned attributes in the Calculation screen. | - |
| UI_DEF_CALC_PARENT_C S_ONLY_FLG | N | The UI default for calculate only parent customer segments flag. | - |
| UI_DEF_CALC_PARENT_T A_ONLY_FLG | N | The UI default for calculate only parent trade areas flag. | - |
| UI_DEF_MAX_MISS_ATTR_ CNT | 3 | The maximum number of missing attributes for a SKU, before requiring it to be filtered from use. | - |
| UI_DEF_MIN_SKU_CNT | 10 | The UI default for minimum number of SKUs required for a segment/ store. | - |
| UI_DEF_MIN_SKU_TXN_LE N_PCT | 0.01 | The UI default for minimum SKU transaction length as a percentage of the CM Group average. | - |
| UI_DEF_MIN_TOT_SLS_UN IT_PCT | 0.01 | The UI default for minimum total sales units as a percentage of the CM group average. | - |
| WGT_CALC_INTERVAL_LE NGTH | 4 | The number of weeks to group into an interval that is then used to perform weight calculations with. | This setting can be adjusted according to the data quality and quantity available for a customer. Higher values improve performance; however, it limits the amount of data available to be processed. |
Returns Logistics Configurations
The following is a list of configurations that can be adjusted for the Returns Logistics process. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘RL’.
Table 17-6 Returns Logistics Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| RL_NUM_TOP_CATEGORI ES | 10 | The number of top selling categories for Returns Logistics to process. | - |
| RL_NO_OF_SIMULATION_ RUNS | 100 | The number of simulated forecast runs to perform. | - |
| RL_IN_SEASON_DEMAND _WEIGHT | 0.99 | The percentage of the in- season demand and returns rate to use. This is used to calculate the adjusted demand and returns rate. | - |
| RL_HISTORICAL_DEMAND _WEIGHT | .01 | The percentage of the historical demand and returns rate to use. This is used to calculate the adjusted demand and returns rate. | - |
| RL_GUR_TIMELIMIT | 60 | GUROBI parameter. Time limit. | - |
| RL_GUR_THREADS | 0 | GUROBI parameter. Number of allowed threads. | - |
| RL_PROCESSING_THREA DS | 0 | The number of threads to create for data processing. A value of 0 creates one thread for each machine processor. | - |
Affinity Analysis Configurations
The following is a list of configurations that can be adjusted for the AA application. This list does not include internal configuration values. All of these entries are adjusted by manipulating the corresponding rows in RSE_CONFIG where APPL_CODE=‘MBA’. Some of the configurations note that overrides are possible. When this is required, see the RSE_CONFIG_CODE configuration table and use the appropriate Hierarchy Level value as the PARAM_CODE to override the value for only that hierarchy level.
Table 17-7 AA Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| ARM_CS_HIER_LEVEL | SBC | The highest level of the hierarchy to run the process for. Valid values are: CLS, SBC. | - |
| ARM_CS_MAX_LIFT | 100 | The maximum lift required for an association rule. | - |
Table 17-7 (Cont.) AA Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| ARM_CS_MAX_RULE_CO UNT | 9999 | The maximum number of rules desired for association rules. | Affects the count of rules per set size. |
| ARM_CS_MAX_SET_SIZE | 2 | The maximum number of hierarchy members to include in an association rule. | Maximum allowed is 4, although a setting this high can negatively affect performance with some datasets. |
| ARM_CS_MIN_CONFIDEN CE | .05 | The minimum confidence required for an association rule. | - |
| ARM_CS_MIN_LIFT | .05 | The minimum lift required for an association rule. | - |
| ARM_CS_MIN_REV_CONF IDENCE | .05 | The minimum reverse confidence required for an association rule. | - |
| ARM_CS_MIN_SUPPORT | .001 | The minimum percentage of transactions require for an association rule. | - |
| ARM_CS_MIN_SUPPORT_ TXN_CNT | 1000 | The minimum number of sales transactions required for creating association rules. | - |
| ARM_CS_WEEK_CNT | 1 | The number of weeks that should be processed while calculating the association rules. | Only set this to more than 1 if there is a need to reprocess weeks that would have been processed in the prior batch window. |
| ARM_PH_MAX_LIFT | 100 | The maximum lift required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PH_MAX_RULE_CO UNT | 9999 | The maximum number of rules desired for association rules. | Affects the count of rules per set size. |
| ARM_PH_MAX_SET_SIZE | 2 | The maximum number of hierarchy members to include in an association rule. Override with PARAM_CODE of the hierarchy level name. | Maximum allowed is 4, although a setting this high can negatively affect performance with some datasets. |
| ARM_PH_MIN_CONFIDEN CE | .05 | The minimum confidence required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
Table 17-7 (Cont.) AA Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| ARM_PH_MIN_LIFT | .05 | The minimum lift required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PH_MIN_REV_CONF IDENCE | .05 | The minimum reverse confidence required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PH_MIN_SUPPORT | .001 | The minimum percentage of transactions require for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PH_MIN_SUPPORT_ TXN_CNT | 1000 | The minimum number of sales transactions required for creating association rules. | - |
| ARM_PH_TOP_LEVEL | CLS | The highest level of the hierarchy to run the process for. Valid values are: DEPT, CLS, SBC. | - |
| ARM_PH_WEEK_CNT | 1 | The number of weeks that should be processed while calculating the association rules. | Only set this to more than 1 if there is a need to reprocess weeks that would have been processed in the prior batch window. |
| ARM_PROMO_HIER_LEVE L | SBC | The highest level of the hierarchy to run the process for. Valid values are: CLS, SBC. | - |
| ARM_PROMO_MAX_LIFT | 100 | The maximum lift required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PROMO_MAX_RULE _COUNT | 9999 | The maximum number of rules desired for association rules. | Affects the count of rules per set size. |
| ARM_PROMO_MAX_SET_ SIZE | 2 | The maximum number of hierarchy members to include in an association rule. Override with PARAM_CODE of the hierarchy level name. | Maximum allowed is 4, although a setting this high can negatively affect performance with some datasets. |
| ARM_PROMO_MIN_CONFI DENCE | .05 | The minimum confidence required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
Table 17-7 (Cont.) AA Configurations
| Parameter Name | Example Value | Description | Notes |
|---|---|---|---|
| ARM_PROMO_MIN_LIFT | .05 | The minimum lift required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PROMO_MIN_REV_ CONFIDENCE | .05 | The minimum reverse confidence required for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PROMO_MIN_SUPP ORT | .001 | The minimum percentage of transactions require for an association rule. Override with PARAM_CODE of the hierarchy level name. | - |
| ARM_PROMO_MIN_SUPP ORT_TXN_CNT | 1000 | The minimum number of sales transactions required for creating association rules. | - |
| ARM_PROMO_WEEK_CNT | 1 | The number of weeks that should be processed while calculating the association rules. | Only set this to more than 1 if there is a need to reprocess weeks that would have been processed in the prior batch window. |
Resource Bundles
Oracle Retail AI Foundation Cloud Services comes packaged with resource bundles, files that contain text resources. These text resources appear throughout the application as instructions, messages, labels, errors. Retailers can customize the text resources to suit their requirement. The capability to change the text for a resource is provided through the Resource Bundles Section of Retail Home. For more information, see Oracle Retail Home Administration Guide .
Manage Notebooks
Different types of notifications are sent to specific groups of users for the tasks and jobs accomplished. Retail Home provides administrators with the ability to set up groups of user roles that must receive each type of notification. For more information, see Oracle Retail Home Administration Guide .
Configurations for Loading Fact Measures into AIF
This section covers the details of setup and configurations in the case where fact data is provided at an aggregated level, for example, where sales units data is provided at sku-storeweek level or any higher level such as department-region-week (as opposed to sales transaction).
Interfaces for Fact Measures
The following four interfaces allow for providing data at a maximum of four different intersections of merchandise, location, and calendar. For details about configurations and loading data via these interfaces, see the Oracle Retail Analytics and Planning Implementation Guide .
Table 17-8 Interfaces for Fact Measures
| Interface Name | Staging Table in Data Exchange (RDX) Layer | Target Table in AIF Data Warehouse |
|---|---|---|
| Fact Measures | W_PDS_ACTUALS_STG1 | W_RTL_FACT_PROD1_LC1_T1 _FS |
| W_PDS_ACTUALS_STG2 | W_RTL_FACT_PROD2_LC2_T2 _FS | |
| W_PDS_ACTUALS_STG3 | W_RTL_FACT_PROD3_LC3_T3 _FS | |
| W_PDS_ACTUALS_STG4 | W_RTL_FACT_PROD4_LC4_T4 _FS |
Configurations in AIF for Loading FACT Measures
The fact data can be at any intersection and can contain various measures, such as sales, inventory, shipment, and so on.. Since the intersections and measures vary across customers, it is important to configure AIF for each implementation based on the intersections and measures that are planned to be loaded. The following tables are used for specifying the intersections, measures, and mappings.
-
RSE_MD_CDA: This table contains SRC_ENTITY_NAME, SRC_COLUMN_NAME, and TGT_COLUMN_NAME. The SRC columns have the name of the FACT table and name of the column from that FACT table that are to be loaded into AIF. The TGT column has the name of target column in the AIF table where data will be written. The target table in AIF is called RSE_PR_LC_CAL_CDA. So RSE_MD_CDA has the mapping between FACT table/ columns and RSE_PR_LC_CAL_CDA columns. To make the setup easier, the configuration of metadata is done programmatically. AIF checks for columns that have data for at least one week in any of the four FACT tables. Based on that, the code populates RSE_MD_CDA. It uses the FACT column names to determine the data type for that column. In RSE_MD_CDA, there is a column for UI_DISPLAY_NAME that the user can optionally edit, using the System Configuration under Control & Tactical Center.
-
RSE_MD_FACT_COLUMN_MAP: This table contains the mapping between columns in RSE_PR_LC_CAL_CDA and the final target tables such as sales and inventory in AIF. This table has four columns for SOURCE_TABLE, SOURCE_COLUMN, TARGET_TABLE, and TARGET_COLUMN. The source columns have the names of FACT tables/columns. The target columns have the names of tables in AIF that must be populated based on the FACT data. For example, if the FACT measures are supposed to be used in PMO/ Forecasting, the mapping between the FACT table/column and the PMO_ACTIVITIES columns must be defined in RSE_MD_FACT_COLUMN_MAP. Another example is populating inventory and sales tables in AIF based on FACT measures. For a customer who wants to provide data at the aggregate level via a FACT measure, the mapping between the FACT tables and the sales/inventory tables in AIF must be defined in RSE_MD_FACT_COLUMN_MAP. It is important to insert the proper data for mapping into RSE_MD_FACT_COLUMN_MAP before loading data. The user can add mappings in RSE_MD_FACT_COLUMN_MAP, using the System Configurations Screen under Control & Tactical Center.
The following table provides some examples of configuring data in RSE_MD_FACT_COLUMN_MAP for the most common columns such as sales quantity and amount. These examples assume that the data is being provided via
W_RTL_FACT1_PROD1_LC1_T1_F and that the intersection is SKU/store/week. The exact mapping will vary by each implementation and will depend on which FACT interface(s) and which columns are used and what measure they represent.
Table 17-9 Examples of Configuring Data
| Domain | SOURCE_TABLE | SOURCE_COLUM N | TARGET_TABLE | TARGET_COLUM N |
|---|---|---|---|---|
| Sales | W_RTL_FACT1_P ROD1_LC1_T1_F | SLSRG_QTY | RSE_SLS_PR_LC _WK | SLS_QTY |
| W_RTL_FACT1_P ROD1_LC1_T1_F | SLSRG_RTL_AMT | RSE_SLS_PR_LC _WK | SLS_AMT | |
| W_RTL_FACT1_P ROD1_LC1_T1_F | SLSPR_QTY | RSE_SLS_PR_LC _WK | SLS_PR_QTY | |
| W_RTL_FACT1_P ROD1_LC1_T1_F | SLSPR_RTL_AMT | RSE_SLS_PR_LC _WK | SLS_PR_AMT | |
| W_RTL_FACT1_P ROD1_LC1_T1_F | SLSCL_QTY | RSE_SLS_PR_LC _WK | SLS_CLR_QTY | |
| Inventory | W_RTL_FACT1_P ROD1_LC1_T1_F | EOH_QTY | RSE_INV_PR_LC_ WK | INV_QTY_BOH |
POM Jobs
The following table shows the POM jobs that must be run to load data from FACT tables into AIF.
Table 17-10 POM Jobs
| JobName | Description | RMSBatch | ProcessName |
|---|---|---|---|
| RSE_AGGREGATE_ME TADATA_LOAD_ADHOC _JOB | Ad hoc job to load aggregate measure metadata from RA to RSE | rse_aggregate_metadat a_load.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_AGGREGATE_AC TUALS_LOAD_ADHOC _JOB | Ad hoc job to load aggregate measure actuals from RA to RSE | rse_aggregate_actuals_l oad.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_SLS_PR_LC_WK_ AGGR_MEAS_SETUP_ ADHOC_JOB | Ad hoc job for product at leaf level/location/week sales aggregate measure setup | rse_sls_pr_lc_wk_aggr_ meas_setup.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_SLS_PR_LC_WK_ AGGR_MEAS_PROCES S_ADHOC_JOB | Ad hoc job for product at leaf level/location/week sales aggregate measure process | rse_sls_pr_lc_wk_aggr_ meas_process.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_SLS_PH_LC_WK_ AGGR_MEAS_SETUP_ ADHOC_JOB | Ad hoc job for product at non-leaf level/location/ week sales aggregate measure setup | rse_sls_ph_lc_wk_aggr_ meas_setup.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_SLS_PH_LC_WK_ AGGR_MEAS_PROCES S_ADHOC_JOB | Ad hoc job for product at non-leaf level/location/ week sales aggregate measure process | rse_sls_ph_lc_wk_aggr_ meas_process.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
Table 17-10 (Cont.) POM Jobs
| JobName | Description | RMSBatch | ProcessName |
|---|---|---|---|
| RSE_INV_PR_LC_WK_ AGGR_MEAS_SETUP_ ADHOC_JOB | Ad hoc job for product at leaf level/location/week inventory aggregate measure setup | rse_inv_pr_lc_wk_aggr_ meas_setup.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
| RSE_INV_PR_LC_WK_ AGGR_MEAS_PROCES S_ADHOC_JOB | Ad hoc job for product at leaf level/location/week inventory aggregate measure process | rse_inv_pr_lc_wk_aggr_ meas_process.ksh | RSE_LOAD_AGGREGA TE_FACT_DATA_ADHO C_PROCESS |
Internationalization
The user interface supports multiple languages in a single instance, but the underlying database only supports a single language in an instance.
The database default language is selected at installation. Once set, there is no support for switching the database language. The application user interfaces adhere to the language setting for each user’s browser. For example, to change the language for the Firefox browser:
1. Select Tools from the menu bar.
2. Select Options.
3. Select Choose.
4. Select the language to add.
The following language are supported: English, German, Greek, Spanish, French, Croatian, Hungarian, Italian, Japanese, Korean, Dutch, Polish, Brazilian Portuguese, Russian, Swedish, Turkish, Simplified Chinese, and Traditional Chinese.
Configuration Updates
Use the Manage Configuration user interface screen in order to edit the values in the configuration tables. In order to access this screen, you must be assigned the role of ADMINISTRATOR_JOB. The tables you can edit within Manage Configuration depends upon which application roles you have been assigned, as described in Table 17-1.
Once you have accessed Manage Configuration, you select, from the configuration tables available to you, the table that you want to review and edit. Note that each configuration table allows specific actions. You may or may not be able to view the table, edit some or all of the columns, or add and delete rows.
Certain of the tables in Manage Configuration are not intended for configuration but instead are provided to display data that may be useful during implementation. For each application interface file, a table is available that contains any records that have failed the data validation rules. Such tables have an extension of BAD. For example, for the rse_prod_attr_grp_value_stg.txt interface, the data is loaded into a table named RSE_PROD_ATTR_GRP_VALUE_STG. The error table is named RSE_PROD_ATTR_GRP_VALUE_BAD.
You can see all the error tables for all the interfaces via Manage Configuration. When an error occurs with an interface, yo can review the BAD table to see what records failed validation and why. Each BAD table includes the following columns: ERROR_ROWID, ERROR_ID,
ERROR_DESCR, and ERROR_DT. The ERROR_ID is useful as a reference. The ERROR_DESCR provides a message to explain the validation error.
Configuration Tables
The following tables can be viewed in the Manage Configuration screen.
Table 17-11 Customer Decision Tree Configuration Tables
| Table Name | Description |
|---|---|
| CDT_EXCLUDE | Defines the various types of pruning filters that can be used to prevent a CDT from being used during the escalation phase of the CDT workflow. |
| CDT_FILTER | Defines the various types of data filters that can be used to filter sales transaction data used for the CDT calculation. |
| CDT_VERSION | Defines a version to collectively group together a batch of CDTs that have been created for a particular purpose. |
Table 17-12 Advanced Clustering and Customer Segmentation Configuration Tables
| Table Name | Description |
|---|---|
| CIS_ALGORITHM_ATTR | Defines the possible attributes for any algorithm. |
| CIS_BUSINESS_OBJECT | Hosts the list of applications that are registered and configured to use the clustering feature. |
| CIS_BUSSOBJ_OBJ_ALG_XR EF | This cross reference is provided so that you can use the same algorithm to generate different cluster objectives. The same algorithm can be used to generate customer clusters as well as store clusters. At the same time it is possible to list multiple algorithms that can be used to achieve a similar objective. |
| CIS_BUSSOBJ_TCRIT_HIER_ XREF | Specifies the possible hierarchy levels for each hierarchy type (merchandise and location) that are permitted for the combination of objective ID, business objective ID, and type criteria ID. |
| CIS_BUS_OBJ_HIER_DEPLO Y_XREF | Identifies the business object, objectives, product hierarchy types, and levels that can be selected for deployment. This ensures that only authorized types of clusters are exported to external systems (CMPO). |
| CIS_BUS_OBJ_NESTED_TCR ITERIA | Determines the possible child cluster types for a parent cluster. |
| CIS_BUS_OBJ_TCRITERIA_X REF | Specifies the possible cluster types that are permitted for the combination of objective ID and business objective ID. |
| CIS_BUS_OBJ_TCRIT_ALGO _ATTR | Defines possible attributes for any algorithm, business objective, objective, and criteria. |
| CIS_CLUSTER_OUTLIER_RU LE | Specifies the possible outlier rules for a type of criteria. |
| CIS_EFFECTIVE_PERIOD | Specifies the planning period information. |
| CIS_ODM_SETTINGS | Temporary storage for the data mining settings provided to ODM. You can store multiple runs of settings by using different mining functions and run IDs. To provide this data to ODM, you must write a view that provides the appropriate rows of data. |
| CIS_SALES_TYPE | Specifies the type of sales information - historical, forecasted, or planned. |
Table 17-12 (Cont.) Advanced Clustering and Customer Segmentation Configuration Tables
| Table Name | Description |
|---|---|
| CIS_SRC_ENTITY | Defines the different database views available for use in the various clustering implementations. These settings help control how the attributes are used throughout the system. |
| CIS_TCRITERIA_SRC_XREF | Cross reference to SRC_ENTITY_NAME and for the settings for Partitioning, Information for the SRC_ENTITY_NAME attributes. |
| CIS_TCRIT_SRC_TYPE_XRE F | Describes the xref of type_criteria and sales. |
| CIS_TYPE_CRITERIA | List of different clustering types and criteria that can be used to generate clusters. |
Table 17-13 Demand Transference Configuration Tables
| Table Name | Description |
|---|---|
| DT_EXCLUDE | Defines the different types of pruning filters available to prevent a DT result from being used during the escalation phase of the DT workflow. |
| DT_FILTER | Defines the different types of data filters used during the DT data filtering process. |
Table 17-14 Generic Configuration Tables
| Table Name | Description |
|---|---|
| RSE_AGGR_SRVC_CONFIG_ LEVELS | Defines the different hierarchy types and levels that must have aggregated data created as part of the hierarchy configuration. |
| RSE_BUSINESS_OBJECT_AT TR_MD | Defines the attributes for business objects and also provides relevant details about where from external table sources to obtain the data for this attribute. |
| RSE_BUSINESS_OBJECT_D B_SRC | Defines the source database objects for the attributes. |
| RSE_CONFIG | Provides configuration names and their values for the settings that can be changed and affect the operation of the software. |
| RSE_CONFIG_CODE | Provides configuration values for those configurations that can have different values, depending on how other values are configured. For example, if a configuration is required for a default error tolerance, but department 1 requires a different value, then a row here with a PARAM_CODE of 1 will enable a different value than the base configuration in RSE_CONFIG for just that department. |
| RSE_EMAIL_CFG_DISTR | Intersection table between the email configuration table and the email distribution list table used to resolve the many-to-many relationships. |
| RSE_EMAIL_DISTR_LIST | Provides the email distribution lists. |
| RSE_EMAIL_NOTIF_CFG | Defines the email messaging configuration. |
| RSE_EXP_GRP | Hosts the list of applications that are registered and configured to use the clustering application. |
| RSE_HIER_LEVEL | Defines the various levels for all the hierarchies. |
| RSE_HIER_TYPE | Defines the hierarchies that are available for use by the RSE applications. |
Table 17-14 (Cont.) Generic Configuration Tables
| Table Name | Description |
|---|---|
| RSE_LOAD_SRVC_CFG | Defines a data loader that can be executed through the data loading framework. |
| RSE_LOAD_VALDT_RULES_ CFG | Defines the validation rules that a data loader performs, along with some configurable options that impact rows that fail the validation. |
| RSE_PROC_TASK_TMPL | Defines the templates for processing tasks used by the applications. |
| RSE_PROC_TMPL | Defines the processing templates for asynchronous or synchronous invocable from Java applications. |
| RSE_SRVC_CONFIG | Defines all the database service routines that can be invoked through the database service framework in RSE. |
Email Notification Configuration
The RSE_EMAIL_CFG_DISTR, RSE_EMAIL_DISTR_LIST, and RSE_EMAIL_NOTIF_CFG tables listed in the tables in Configuration Tables can be used to enable email notifications for certain batch processes. The RSE_EMAIL_NOTIF_CFG table contains a list of processes that can generate an email notification. Configurations are available for loading interface files (PROCESS_TYPE=LOAD), as well as configurations for running the automated batch processes (PROCESS_TYPE=BATCH).
The RSE_EMAIL_DISTR_LIST table is used to define email distribution lists that should receive email notifications. If all email notifications are to be sent to the same email address, then a row with a DEFAULT_FLG=Y can be used so that the distribution list is used for all email notices.
If some processes require different email recipients, then additional distribution lists can be created for those in RSE_EMAIL_DISTR_LIST. Once created there, a record can be created in RSE_EMAIL_CFG_DISTR that links the distribution list with the email notification. Any email configuration without a specific entry in RSE_EMAIL_CFG_DISTR is sent to the default distribution list.
By default, all LOAD failures trigger an email notification with details about the load that failed. Additionally, all batch processes send an email notification when the entire batch process completes. This email indicates whether the batch process was successful or if a failure occurred.
In this guide
- Guide: AI Foundation Implementation Guide
- Previous: 16 Inventory Planning Optimization-Inventory Planning
- Next: 18 Attribute Processing
Related chapters
- 20 Batch Processing — AI Foundation Implementation Guide · shares
APPL_CODE,CONFIGURABLE_FLG,PARAM_CODE,RSE_CONFIG_CODE - 14 Control and Tactical Center — AI Foundation Implementation Guide · shares
ADHOC_JOB,APPL_CODE,PMO_ACTIVITIES,RSE_AGGREGATE_ACTUALS_LOAD_ADHOC_JOB - 4 AI Foundation Applications Standalone Processes — AI Foundation Operations Guide · shares
ADHOC_JOB,CIS_TCRITERIA_ATTR,FAKE_CUST_DAY_TXN_THRESHOLD,PERF_CIS_APPROACH