JD Edwards EnterpriseOne Integration with Oracle Demantra Demand Management

This chapter provides an overview of the Oracle Demantra Demand Management product and discusses how to configure Demantra Demand Management.

Understanding Oracle Demantra Demand Management

The Oracle Demantra Demand Management solution enables you to plan for and proactively respond to demand by sharing a one-number plan that aligns the organization across departments and users. Flexibility and business process automation support a wide range of daily operations with demand intelligence.

This solution is designed to support demand-driven planning. It is built on a flexible, multidimensional data architecture that gives users the ability to view analytic capabilities along any dimension and level of granularity. Every department can organize the data in hierarchies and units of measure, and each department can view its own up-to-date plans while sharing the same base data. Unlike conventional business intelligence tools that only let you view data, Oracle Demantra Demand Management enables you to read and edit data dynamically, with changes automatically split and rolled up or down appropriately, which we call live read-write capability. Top-down, bottom-up, and middle-out change analysis is supported. The unique middle-out capability enables managers change plans at their level of the organization that are automatically applied up and down the hierarchy.

Configuring Demantra Demand Management

Complete these customizations to integrate the Oracle Demantra Demand Management application with JD Edwards EnterpriseOne products:

• Specify the Oracle Demantra extract source folder.

• Configure the Oracle Demantra Demand Management levels.

• Configure the JD Edwards EnterpriseOne Upload Integration interface.

• Change system time.

• Set the Control System and Engine Max Sales dates.

• Set the date range for incremental extracts.

Specifying the Oracle Demantra Extract Source Folder

You must specify the physical location of the UBE extract source folder from which Oracle Demantra Demand Management retrieves the extract flat files. This folder should be in a shared file system visible from both JD Edwards EnterpriseOne and Oracle Demantra environments.

The recommended default location for the extract source folder is <Demantra_install_folder>\e1_integration\e1_files.

To modify the folder in which Oracle Demantra looks for these extracts, edit the create_integration_dir.sql file in the <Demantra_install_folder>\e1_integration directory.

Configuring the Oracle Demantra Demand Management Levels

Complete this procedure to enable the Item, Organization, and Site category code levels that you want to appear in Demand Management worksheets:

To configure the category code levels:

1. Log in to Oracle Demantra Business Modeler.

2. From the Configuration menu, select Configure Levels.

The Configure Levels dialog box appears.

3. Right-click the level you want, and select Open, General Properties.

4. In the General Properties dialog box, select Enabled from the Status drop-down list.

5. Click Finish.

6. Click Next until the Defaults dialog box appears.

7. Click Finish.

Configuring the EnterpriseOne Upload Integration Interface

You can configure the EnterpriseOne Upload integration interface to specify the path of the location where the forecast file will be generated. The default path for the forecast file is c:\e1_integration\e1_files\forecast.txt.

To specify the EnterpriseOne Upload output path:

1. Log in to the Business Modeler.

2. From the Tools menu, select Integration Interface.

3. In the Create/Modify Integration Interface dialog box, select the E1 Upload Integration Interface and click OK.

4. Click Next.

5. Double-click the Forecast Data profile.

The Data Profile Interface dialog box appears.

6. Click Next until the Data Profile Export Properties dialog box appears.

7. In the File Name field, click the browse button.

The Select File for Export dialog box appears.

8. Select the forecast that you want to export and then click Save.

9. Click the Finish button twice.

Changing System Time

Oracle Demantra products use a base time. All other time that appears in the system is an aggregation of this base time. The default time of the Demand Management application is weekly, beginning on Monday. the company may want to change the base time for one of these reasons:

• Start the week on a different day.

• Aggregate the week based on the ending day, not the beginning day.

• Select a daily or monthly base time.

To change the base time:

1. In the Business Modeler, open the Build Model window, and then open the data model Integration Template.

2. Click Next until the Time Bucket window appears.

3. Complete these 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 of the last day of the Gregorian month.

4. After the changes are saved, the data model should be upgraded, not rebuilt, using the Run Time Bucket option selected.

Note. If the time bucket is reconfigured, the time aggregation set for all worksheets is modified to match the new time aggregation. Review all used and embedded worksheets.

Many engine parameters set for a weekly system do not represent a best-practice setting in a monthly and daily system. You will find a good source of default values in the init_params_0_daily and init_params_0_monthly tables. Review engine parameters and change relevant time parameters if you change the time bucket setting.

The value in the Parameter Metrics Period field defines the length of history for which accuracy is calculated as an engine output. The default value for the weekly system is 26. A monthly system is set to 24, and a daily system is set to 60..

Setting Control System and Engine Max Sales Dates

When loading future dates in the EP_LOAD process, you should populate a control parameter to determine how you want the end of history populated. You will find the control parameter, which is called MaxSalesGen, in the Business Modeler.

To populate the MaxSalesGen parameter:

1. Access the Business Modeler.

2. From the Parameters menu, select System Parameter.

3. Click the System tab and scroll down until you find the MaxSalesGen parameter.

4. Enter a value for the MaxSalesGen parameter, for example:

• 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 settings is the last date of history. This value is recommended for cases in which only historical dates are 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). If you run the process on February 16, 2007, in a weekly system with weeks beginning on Monday, the last date of history is set to the previous Monday, which is February 12, 2007. For a monthly system run on the same date, the end of history is set to February 1, 2007. This value is recommended for a production environment in which 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 value could add time to loading availability. The data used to drive the engine must be stored in the actual_quantity column.

• Any date other than 01-01-1900 00:00:00. Entering 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, then 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 selection is ideal for testing systems in which the desired end-of-history date does not match the executed date. This selection allows users full control of dates that are assigned as end of history and beginning of forecast.

Note. All dates must be entered in the MM-DD-YYY 00:00:00 format.

Setting the Date Range for Incremental Extracts

JD Edwards EnterpriseOne sales order information can be extracted in full or incrementally. For incremental extracts, a parameter is set in the R34A400_incr.xml file that defines, from today's date, how many days backward and forward to go to generate the date range to be extracted. Within the Business Modeler, set the Integration1E1DaysLoaded parameter to match that used by the R34A400_incr.xml file.

To set the Integration1E1DaysLoaded parameter:

1. Access the Business Modeler.

2. Select System Parameters, and then System. The System Parameters window appears.

For example, in a weekly system with weeks beginning Monday, if the extract execution date is January 31, 2007, and the R34A400_incr.xml parameters are –28 and +7, then the parameter Integration1E1DaysLoaded should be set to 28. This setting will extract all orders with a requested ship date between January 3, 2007, and February 7, 2007. When this information is turned into weeks beginning on Monday in the Oracle Demantra products, these weeks will receive information:

• January 1 to 7

• January 8 to 14

• January 15 to 21

• January 22 to 28

• January 29 to February 5

Since the data extracted for the week beginning January 1 contains information only from January 3, it is an incomplete week and may cause incomplete weekly data to be loaded. The integration process references the parameter Integration1E1DaysLoaded and truncates the week of January 1 from the load, thereby loading information only from January 8 on.

During implementation, it is not realistic to try and modify the R34A400_incr.xml parameters before every data load. The configuration should attempt to capture the narrowest range of dates which likely captures 99.9 percent of all orders. Since a large gap may occur between an order being requested and its actual shipment, this range greatly depends on the business practices associated with the implementation. Set the parameter Integration1E1DaysLoaded to a number that is smaller than or equal to the first date range parameter in the R34A400_incr.xml. The current default value is set to 3000 to capture the entire date range suitable for a full load, as well as any testing scenarios.

Actual settings vary by business, but they should be driven by these considerations:

• What is the likelihood that an order will be shipped 1, 2, 3... periods late?

• What is the largest delay ever experienced between an order placement and its shipment?

• How critical is the capture of all orders?

• How long a time interval is available for the data extract?

The answers to the previous questions enable you to set a reasonable business-oriented date range. Use these initial settings:

• Daily system: –2 and 0 to capture a full two weeks.

• Weekly system: –41 and 0 to capture a full fiscal month of five weeks, regardless of weekday run.

• Monthly system: –4 and 0 to capture a full quarter, regardless of month day run.