General Integration Guidelines

A pre-made model supports out-of-the-box integration of the Oracle e-Business Suite or EnterpriseOne applications with the Oracle Demantra Demand Management application. This model contains necessary definitions to support both Oracle e-Business Suite and EnterpriseOne applications and uses many common building blocks. The Oracle e-Business Suite model serves as the core best practice for Oracle Demantra Demand Management integration. Where EnterpriseOne information is missing, e-Business Suite documentation applies

This chapter covers the following topics:

"Open With" Worksheets
Worksheet Filters
Changing System Time Resolution
Analytical Engine Guidelines
DM application default users
Controlling System and Engine Max Sales Dates

"Open With" Worksheets

"Open With" worksheets should be unfiltered. If you wish to show a filtered version of the worksheet, you will need to create a duplicate for "My Worksheets". If you place a filter on a worksheet to be used by "Open With", the "Open With" filter will be applied to the already filtered population which may not provide a result set. For example, if the worksheet is filtered to Member 1 of Level 1, and "Open With" is launched from Member 2 of Level 1, the result set will be null.

Worksheet Filters

The Demand Management worksheets have a default filter. This filter is to ensure that when first run in a large production environment, the worksheet will not attempt to run on the entire data population. The filter added is pointing to the default members of all levels configured as aggregation levels in the worksheet. When implementing, go into all the worksheets and their embedded worksheets, change the filters to match the business process and scope. Remember that very large worksheets are typically not representative of one user's business process and will typically be accompanied by degradation in performance.

Changing System Time Resolution

Demantra uses a base time resolution. All other time displayed in the system is an aggregation of this base time resolution. The default time of the Demand Management application is weekly beginning on Monday. There may be several business reasons to change this:

Starting your week on a different day.
Aggregating the week based on the ending day not the beginning day.
Daily or monthly base time.

To change the base time

Access the Business Modeler.
From the Data Model menu, choose Open Data Model.
Select the data model you want to modify and click next until the Time Bucket screen appears.
Complete the following fields:
- Time Bucket
- First Day of the Week
- Aggregation Method
Note: The day and month time unit do not designate the first day of the period. Months are assumed to begin on the first and end on the last day of the Gregorian month.
After your changes have been saved, the data model should be upgraded, not rebuilt using the Run Time Bucket option selected.

Note: If the time bucket is re-configured, the time aggregation set for all worksheets is modified to match the new time aggregation. A review of all used and embedded worksheets is strongly recommended.

Changing time resolution and engine parameters

Many engine parameters set for a weekly system do not comprise best-practice setting in a monthly and daily system. A good source of default values can be found in init_params_0_daily and init_params_0_monthly tables. It is recommended that you review engine parameters and change time relevant parameters if you change the time bucket setting.

Parameter MetricsPeriod defines the length of history for which accuracy is calculated as an engine output. Default for weekly system is 26. A monthly system is set to 24 while a daily system is set to 60.

Analytical Engine Guidelines

The batch engine generates a new forecast for a system-wide population or a line of business. It uses distributed processing, analyzes very large amounts of data at night and on the weekends when users are not logged into the system. By contrast, the simulation engine is used to generate or regenerate a forecast for a very specific population subset. Simulations can be run on an as needed basis, and several users may run simulations concurrently. Due to the large amount of processing used by the batch engine and the fact that it typically regenerates the entire forecast, the batch and simulation engine are not enabled to run at the same time.

The analytic engine outputs several accuracy metrics when running the batch engine. They are:

MAPE
BIAS
MRE
RMSE
And a number of historical observations used to calculate these metrics.

The length of history serving as a basis for the first 4 metrics is set by INIT_PARAMS_0 parameter MetricsPeriod.This parameter defines the number of periods of history, starting with the last and moving backward when calculating the accuracy metrics. Since the accuracy metrics are based on comparison of a back-cast with history they can serve as indicators of likely accuracy but are not best practice calculations. Best practice calculations should be based on comparison of an archived forecast with actual history as it becomes available. These metrics are stored on table MDP_MATRIX and are generated by the engine at the level a node is forecast.This implies that nodes not receiving a forecast will not have these numbers and all MDP_MATRIX combinations under a specific node will have the same engine metric values.

Additional out-of-sample error calculations can be done using a stand alone error calculation process. For more details refer to Out of Sample Error Calculations.

DM application default users

The DM application is pre-configured with template users. These are necessary to allow system administrator access as well as set up the default process workflows and notifications.


User name	Password	Permission Level	Description
dm	dm	System Manager	Demand Management component owner. User necessary to add or delete users from component. Owns all DM workflows.
Analyst1	analyst1	Power	Typical system day-to-day user
Analyst2	analyst2	Power	Typical system day-to-day user
Analyst3	analyst3	Power	Typical system day-to-day user
Analyst4	analyst4	Power	Typical system day-to-day user
Analyst5	analyst5	Power	Typical system day-to-day user
Admin1	admin1	Power	Typical system administrator. Will typically oversee download and upload process and should be notified of any issues
Manager1	manager1	Power	Manager of analysts. Notified when exceptions occur in forecast approval process

Controlling System and Engine Max Sales Dates

When loading future dates in the EP_LOAD process, it is important to populate a control parameter to determine how you would like the end of history populated. The control parameter can be found in the Business Modeler and is called MaxSalesGen.

Populating MaxSalesGen

Access the Business Modeler.
From the Parameters menu and choose System Parameter.
Click the System tab and scro down until you find the MaxSalesGen parameter.
For the MaxSalesGen parameter, enter the value you want. Some considerations:
- Null. Leaving the parameter blank causes the system to continue to behave as it does today. The last date loaded into the system is compared to the current last system date, and the latest of the two set is the last date of history. It is recommended in cases where only historical dates are being loaded.
- Sysdate. Entering Sysdate as the parameter causes the last date of history to be based on the period containing today's date (date in the DB server). In a weekly system with weeks beginning Monday, if run on February 16, 2007, the last date of history is set to the previous Monday February 12, 2007. For a monthly system run on the same date, the end of history is set to February 1, 2007. This option is good for a production environment where the system date should match the current date while allowing future information to be loaded.
- 01-01-1900 00:00:00. Setting the parameter to this value sets the end of history to the last date in the sales_data table where the actual_quantity column>0. For very large systems, this could add time to loading availability. It is critical that the data used to drive the engine be stored in the actual_quantity column.
- Any date other than 01-01-1900 00:00:00. Any other date will cause the last date of history to be based on the entered date. In a weekly system with weeks beginning Monday, if the date entered is January 16, 2007, the last date of history would be set to the previous Monday January 15, 2007. For a monthly system run with the same parameter setting, the end of history would be set to January 1, 2007. This option is ideal for testing systems where the desired end of history date does not match the executed date. This allows users full control on dates assigned as end of history and beginning of forecast.
Note: All dates must be entered in the MM-DD-YYY 00:00:00 format.