A Complete Forecasting Guide for Oracle Manufacturing [ID 135018.

1] Modified 26-APR-2011 Type PROBLEM Status PUBLISHED This document was checked for relevance on 04-JAN-2008 Forecasting for Success: A Complete Forecasting Guide for Oracle Manufacturing Marc Slone Independent Consultant Introduction This paper will cover all aspects of forecasting in Oracle manufacturing, including setup of forecasts and forecast sets, demand classes, forecast consumption and planning bills of materials. It will also cover in detail the technical architecture of the forecasting module, discuss how to report on forecast data, and suggest useful Alerts. ***Checked for relevance on 26-APR2011*** Definitions A forecast is an estimate of anticipated customer demand on your companys inventory items. In Oracle, forecasts are defined within a three-level hierarchical structure. From most specific to most general, the three levels are forecast entries, forecasts, and forecast sets. A forecast entry is a specific expected product demand. A forecast entry must contain an item number, plus the date(s) and quantity of the expected demand. Related forecast entries are grouped into forecasts. A forecast may be defined for a specific customer, customer site, or other user-defined classification of demand, for example, a geographic region or customer type. The user-defined classifications of demand are called demand classes. A forecast set is a group of forecasts that are somehow related. For example, each of the forecasts in a particular forecast set may represent the forecast for a region. Forecast sets contain the parameters that govern forecast consumption. Forecast consumption is the process by which actual customer orders replace forecasted orders in theplanning process. A planning bill of material is an artificial grouping of items in bill of material format, which represents an entire product family. On a planning bill of material, rather than the BOM indicating the quantity per assembly of each component, it specifies a "planning percentage" representative of the forecasted percentage of demand for each component. The Planning Manager is a background process in Oracle Master Scheduling/MRP which is responsible for many of the performing many of the functions described in this paper, including forecast consumption and the open forecast interface process. To use any of these functions, insure that this process is running on your system by checking the Start Planning Manager form in Oracle Master Scheduling/MRP. For a complete description of the Planning Manager and how it works, consult my paper entitled Planning Manager Technical Workshop from the Fall 1996 OAUG Proceedings. Loading Forecast Data Oracle provides three methods to load forecast data into the database:

 Forecast Entries form (manual data entry) Open Forecast Interface Focus and Statistical forecast generation The first two options are used when the actual forecast dates and quantities are generated externally to Oracle, and your only requirement is to load the forecasts into Oracle. The third option can be used to generate the forecasts based on historical information, provided sufficient history exists in your Oracle Applications database. Forecast Entries form. The simplest way to load externally generated forecast data into Oracle is to use the Forecast Entries form to enter the data manually. On this form, you are first required to select the forecast into which the entries are to be placed, then proceed to enter the actual forecast entries. At the minimum, a forecast entry contains an item number, quantity, bucket type, and an effective date or range of dates. The bucket type works in conjunction with the dates as follows: Each forecast entry is valid for a particular period of time broken down into one of three forecast buckets: days, weeks, or periods. A daily forecast is valid only for the day or days specified by the forecast entry. When entering the forecast dates for a daily forecast, you are restricted to selecting workdays on the manufacturing calendar. A weekly forecast is valid for the entire week(s) for which it is defined. When entering the forecast dates for a weekly forecast, you are restricted to selecting only week start dates as defined by the manufacturing calendar. When using the standard five days on/two days off calendar, this means you will only be able to enter Mondays as the forecast start and/or end dates. Note that in this case the "end date" of the forecast entry actually signifies the first date in the last bucket covered by this forecast entry. Therefore if the end date is entered to be 12-JUL-99, this means that the forecast actually covers through the end of the week beginning on 12-JUL-99. This is equivalent to stating that the forecast is valid through 18-JUL-99. A period forecast is valid for the entire period(s) for which it is defined. When entering the forecast dates for a period forecast, you are restricted to selecting only period start dates as defined by the manufacturing calendar. Depending on the calendar type (regular calendar months, 4/4/5 week pattern, etc.), the period start dates may or may not correspond to calendar month start dates. The "end date" is the same as for the weekly forecast entry, so if the end date is entered to be 01-NOV-99, this means that the forecast entry actually covers through the end of the period beginning on 01-NOV-99. This is equivalent to stating that the forecast is valid through 30-NOV99. The forecasted quantity entered on the Forecast Entries form is a per bucket quantity. For example, if you specify 1,000 as the quantity on a forecast with bucket type "Weeks", you are stating that the anticipated demand for the given item will be 1,000 units per week for each week covered by the entered date range. Open Forecast Interface. The open forecast interface provides a way to import externally generated forecasts into Oracle. To use the open forecast interface, you must load the MRP_FORECAST_INTERFACE table with the forecast data to be imported. A complete description of how to use the open forecast interface is available in the Oracle Manufacturing Implementation Manual. A few of the key columns in the interface table include:

 INVENTORY_ITEM_ID, the forecasted item FORECAST_DESIGNATOR, the forecast into which the entry is to be placed BUCKET_TYPE, Days, Weeks, or Periods, indicated by 1, 2, or 3, respectively FORECAST_DATE, the start date of the forecast entry FORECAST_END_DATE, (optional) the end date of the forecast entry FORECAST_QUANTITY, the per bucket quantity of the forecast entry The Planning Manager polls this table for records to import, so there is no separate concurrent program to launch to perform the forecast import process. Focus and Statistical forecast generation. A third way to load forecast information is to have Oracle generate the forecasts based on historical information. Oracle Manufacturing provides two methods of forecast generation: focus forecasting and statistical forecasting. Note that both of these methods are only available if sufficient historical information is available in Oracle. If you have a new installation of Oracle then you will not have this history available. How focus forecasting works. In focus forecasting, Oracle uses five basic models to determine future demand requirements. It then uses each model to calculate the "forecast" for a previous bucket where the actual demand is already known. Then the results of each of the five models is compared with the actual demand from the prior bucket to see which method produced the most accurate "forecast" for that period.The method with the most accurate forecast is chosen to generate the next buckets forecast. In the following explanations of each model, assume March 1999 is the most recent period for which actual demand data exists, and that focus forecasting is being called upon to generate the forecast for April 1999. Focus forecasting will begin by using the five different models to produce a "forecast" for March 1999: Model I: This years forecast is equal to the actual demand from the same period last year. This model sets the March 1999 forecast equal to the actual demand from March 1998. This model requires a 12-month history of demand data and does not account for rates of growth or decline. Model II: This years forecast is equal to the actual demand from the same period last year, times the rate of change between the prior periods year over year. This model sets the March 1999 forecast equal to the actual demand from March 1998 multiplied by the ratio of the February 1999 demand to the February 1998 demand. This model requires a 13-month history of demand data and accounts for year over year growth or decline. Model III: This years forecast is equal to the actual demand from the prior period this year. This model sets the March 1999 forecast equal to the actual demand from February 1999. This model requires only one month of historical demand data, but does not account for growth or decline. Model IV: This years forecast is equal to the average actual demand from the two prior periods this year. This model sets the March 1999 forecast equal to the average of the actual demands from January and February 1999. This model requires two months of historical demand data and does not account for growth or decline. Model V: This years forecast is equal to the actual demand from the prior period this year, times the rate of change between the two prior periods this year. This model sets the March 1999

forecast equal to the actual demand from February 1999 multiplied by the ratio of the February 1999 demand to the January 1999 demand. This model requires two months of historical demand data and accounts for growth or decline between the two prior periods. Focus forecasting will calculate the March 1999 using each of these models for which sufficient demand history exists. For each model, the absolute difference between the "forecasted" quantity and the actual demand quantity is then divided by the actual demand quantity to determine the error percentage for that model. The model that produces the lowest error percentage is chosen and the April 1999 forecast is then generated using that model. Whenever new actual demand data is generated for current periods, the focus forecasting process can be re-run to update the next period's forecast. How to generate a focus forecast. First define a Forecast Rule using the Forecast Rules form, available in Oracle Inventory. Specify a name and description for the new forecast rule, and select Focus for the forecasting method option. When defining a forecast rule to use focus forecasting, the forecast rule only requires two other types of information: Bucket Type: Specify days, weeks, or periods to indicate the bucket type of forecast entries generated using this forecast rule. Include: Specify which of types of actual demand should be included when compiling the demand history for the items. Choices are sales order shipments, issues to WIP, miscellaneous issues, and inter-org transfers. Choose any and all types of demand that are appropriate for your inventory items. If you are planning on generating a new forecast using the forecast rule, define the new forecast. Otherwise you can use the forecast rule to generate additional forecast entries in an existing forecast. See "Define a forecast" in the Setting Up section. Now you can generate the focus forecast. Launch the Generate Forecast concurrent program, available in Oracle Inventory. The concurrent program accepts the following parameters: Forecast Name: Specify the name of the forecast into which you would like the generated entries placed. Forecast Rule: Specify the name of the forecast rule to use when generating the forecast entries. Selection: Specify All Inventory Items, Specific Inventory Item, or Specific Category to determine which inventory items are to have forecasts generated for them. Specific Item: Specify an item number here only if you chose Specific Inventory Item for the Selection parameter. Forecast entries will be generated only for this item. Specific Category Set: Specify a category set here only if you chose Specific Category for the Selection parameter. Specific Category: Specify a category combination here only if you chose Specific Category for the Selection parameter. All inventory items assigned to this category will be included. Overwrite: Specify All Entries, No, or Same Source Only to determine how the Generate Forecast

program handles any forecast entries which currently exist in the target forecast. Select All Entries to purge the target forecast before generating the new entries. Select No to add the new entries to any entries already belonging to the target forecast. Select Same Source Only to purge the target forecast of Start Date: Enter the first bucket for which a forecast entry should be generated. Cutoff Date: Enter the last bucket for which a forecast entry should be generated. Note that focus forecasting only produces a single-bucket forecast. In our example above, a forecast quantity for April 1999 is generated by the focus forecasting process. If the cutoff date is chosen to be later than April 1999, the April 1999 quantity is duplicated each period up to the cutoff date. How statistical forecasting works. In statistical forecasting, Oracle uses a mathematical model to determine future demand requirements. At its most basic level, this model uses much or all of the available historical demand data and uses an exponential smoothing function to average the demand together to produce the forecast. Oracle provides three ways to customize the exponential smoothing function to meet your specific needs. First is an alpha smoothing factor that gives relative weight to newer historical data versus older data. Alpha is a user-defined number between zero and one. A larger alpha value gives greater weight to newer forecast data. If the historical demand is relatively smooth, then changing the value of alpha will not make a significant difference in the statistical forecast that is generated. However, if the demand is not smooth, then choosing a larger alpha value will cause the generated forecast to track more closely the most recent demand data. In addition to the alpha smoothing factor, Oracle also provides for trend-enhanced and seasonenhanced options in statistical forecasting. These modifications to the exponential smoothing function can be used separately, or together to produce the trend and season-enhanced forecast. A trend-enhanced forecast starts with the exponential smoothing function described above, and adds a "trend index" which mirrors the current demand trend. A trend factor similar to the alpha smoothing factor is required, and similar to alpha, the larger the value for the trend factor, the greater weight is given to the current demand trends. A season-enhanced forecast is required when demand for particular items is highly seasonal in nature. In consumer products perhaps the demand is much higher during the last calendar quarter during the Christmas season, or perhaps certain other items demand peaks during summer, etc. To use season-enhanced forecasting, a seasonality index is entered for each calendar period to indicate how far above or below average is the demand for that particular period. When entering seasonality indices, consider the value 1 to be the period with "average" demand. Therefore, a value of 1.5 would indicate that the demand is 50% higher during that period. One important note is that the Generate Forecast program normalizes the seasonality indices before using them in the calculations. Therefore, if all seasonality indices are entered to be 2, then 2 is considered to be the "average" demand and no seasonal adjustments are made to the generated forecast. When demand is seasonal in nature and you wish to take trend into account as well, then the trend factor and the seasonality indices can both be used to generate the new forecast. How to generate a statistical forecast. As in focus forecasting, the first step to generate a

statistical forecast is to define a forecast rule. In addition to the two options required when defining a forecast rule to use focus forecasting, a forecast rule to use statistical forecasting requires entry of the statistical forecasting parameters discussed above: Maximum Past Periods: Specify the maximum number of periods of historical data Oracle should consider during the statistical forecasting process. Alpha Factor: Specify the smoothing factor, a value between 0 and 1, where larger values give more weight to recent historical data. Use Trend Model: Check this box to use the trend-enhanced forecast. Trend Factor: Specify the trend factor, a value between 0 and 1, where larger values give more weight to the recent demand trends. Use Seasonality Model: Check this box to use the season-enhanced forecast. Seasonality Factor: Specify the seasonality factor, a value between 0 and 1, where larger values give more weight to the recent seasonality factors. Seasonality Indices: Specify the seasonality indices for each period, to indicate how the demand in each period has historically compared to the "average" demand. After defining the forecast rule, launch the Generate Forecast program to generate the statistical forecast. This program is discussed in the preceding section for focus forecasting. Forecast Consumption Forecast consumption refers to the process of replacing forecasted demand with actual demand, as the actual demand is received. Communicating sales order demand to Oracle Manufacturing. When using Oracle Order Entry (OE) and Oracle Receivables (AR), the forecast consumption process is automated. Sales order and customer information is automatically transferred from OE to Oracle Inventory. At this point, Oracle Master Scheduling/MRP can read the sales order demand and consume the appropriate forecast entries according to the consumption parameters defined for each forecast set. When using an external order entry system, the sales order demand must be passed into Oracle Master Scheduling/MRP through the Open Demand Interface. For complete information on the Open Demand Interface, please consult the appropriate Oracle Manufacturing Implementation Manual for your release of the applications. When importing sales order demand through this interface, pay particular attention to the following three columns in the demand interface table: CUSTOMER_ID SHIP_TO_SITE_USE_ID BILL_TO_SITE_USE_ID The Oracle Manufacturing Implementation Manual lists these three columns as optional columns when importing sales order demand. However, to enable forecast consumption for this demand, these columns are mandatory. Any sales order demand that does not contain this information will not consume any forecast entries. If OE and AR are not installed on your system, then these numbers are not validated, and you should enter any value into these columns.

In addition to those three columns, if your forecasts are associated with demand classes, be sure to populate the DEMAND_CLASS along with the imported demand. How forecast consumption works. Three parameters govern how the Planning ManagIGN="JUY">The outlier update percent specifies how much of a given forecasts original (pre-consumption) quantity can be consumed by a single sales order. The backward consumption days and the forward consumption days tell the Planning Manager how many days backwards and forwards from the sales order schedule date it may look when locating forecast entries to consume. Whenever new sales order demand is introduced, the Planning Manager first attempts to find forecast entries with dates that exactly match the sales order schedule date: a daily forecast for the same day as the new sales order demand, or a weekly forecast for the week containing the date of the new sales order demand, or a period forecast for the period containing the date of the new sales order demand If a matching forecast entry is located, the Planning Manager decrements the forecast quantity by the amount of the demand quantity. If the demand quantity exceeds the forecast quantity, or if no matching forecast entry is found, then the forecast quantity is set to zero and the process continues. Next the Planning Manager moves backwards, up to the number of backward consumption days, until it finds enough quantity on forecast entries to satisfy the entire sales order demand. If the Planning Manager has moved as far back as the backward consumption days will allow, it moves forward, up to the forward consumption days limit. If the Planning Manager exhausts the entire "window" of possible forecast entries and some quantity of the demand still remains, the forecast is overconsumed. The Planning Manager creates a forecast entry in the forecast set, with a negative forecast quantity. These overconsumption entries are not considered during the planning process. What about demand classes? If the sales order demand contains a demand class, the Planning Manager first searches for forecast entries within forecasts defined for the same demand class. If the Planning Manager does not find sufficient entries to consume, it will then consume any entries within forecasts without a demand class. Technical Details Forecast sets, forecasts, and forecast entries are stored in these three tables: MRP_FORECAST_DESIGNATORS MRP_FORECAST_ITEMS MRP_FORECAST_DATES Another table is used to store the details of forecast consumption: MRP_FORECAST_UPDATES

The table MRP_FORECAST_DESIGNATORS contains the information pertaining to both forecast sets and forecasts. Each forecast will have one row in the table; the name of the forecast is stored in column FORECAST_DESIGNATOR, and the column FORECAST_SET will contain the name of the forecast set to which the forecast belongs. This table also contains the forecast consumption parameters discussed above, in the appropriate columns: DEMAND_CLASS FOREWARD_UPDATE_TIME_FENCE BACKWARD_UPDATE_TIME_FENCE (the previous two columns are actually the "forward consumption days" and "backward consumption days" parameters previously discussed) OUTLIER_UPDATE_PERCENTAGE CUSTOMER_ID SHIP_ID BILL_ID The table MRP_FORECAST_ITEMS contains a unique listing of each item belonging to each forecast. Therefore, an inventory item will have exactly one record in this table for each different forecast to which it belongs. MRP_FORECAST_DATES contains the actual forecast entries for a given forecast. The key forecast information is stored in the following columns: FORECAST_DESIGNATOR: This column, a foreign key reference to the table MRP_FORECAST_DESIGNATORS, will contain the name of the forecast for which the entry is defined. INVENTORY_ITEM_ID: This column, a foreign key reference to the table MTL_SYSTEM_ITEMS, contains the identifier of the item for which the entry is defined. BUCKET_TYPE: This column will contain a 1 for daily forecast entries, a 2 for weekly forecast entries, and a 3 for period forecast entries. This column will always contain a value. FORECAST_DATE: This column will contain the forecast start date and will always contain a value. RATE_END_DATE: This column is populated for multiple-bucket forecast entries, and contains the end date of the forecast. The column is validated exactly like the FORECAST_DATE column, so will contain only valid workdays, week start dates, or period start dates, for daily, weekly, or period forecast entries, respectively. ORIGINAL_FORECAST_QUANTITY: This column contains the quantity specified at the time the forecast entry is created. In the case of multiple bucket forecast entries, the number in this column reflects the per-bucket quantity. This value in this column is not changed during forecast consumption.

Please note that despite the "original" in the name of this column, the forecast quantity represented here may or may not actually represent the first quantity for which the entry was defined. If a forecast quantity is changed at any time after the forecast is first entered, the new quantity replaces the old quantity in this column. Please see Reporting on forecast data for more information. CURRENT_FORECAST_QUANTITY: This column contains the current (remaining) forecast quantity after consuming the entry with actual sales order demand. At entry time, this column contains the same value as ORIGINAL_FORECAST_QUANTITY. Once the forecast entry has been completely consumed by sales order demand, this column will be set to zero. One interesting point when considering how forecast entries are stored arises when considering the case of multiple bucket entries. Note that even in this case, only one record in the MRP_FORECAST_DATES table is created. As an example, consider a weekly forecast entry created for a 13-week period starting with the week of 26-APR-99 and ending with the week of 19-JUL-99, at a quantity of 1000 per week. At the time of entry, a single record in MRP_FORECAST_DATES is created with the following column values: FORECAST_DATE: 26-APR-99 RATE_END_DATE: 19-JUL-99 ORIGINAL_FORECAST_QUANTITY: 1000 CURRENT_FORECAST_QUANTITY: 1000 This single record in MRP_FORECAST_DATES actually represents thirteen different forecast entries and makes reporting on forecast data less than straightforward. Simply summing the forecast quantity for a particular item will understate the total quantity if multiple bucket forecast entries exist for an item. See the section Reporting On Forecast Data for more details. Now, assume that a sales order for this item is booked for quantity 250 for the week of 26-APR99. Remember that the forecast entry represents 13 different forecast entries, each weekly for a quantity of 1000. If the forecast consumption process simply updated the current forecast quantity on the record in MRP_FORECAST_DATES from 1000 to 750, then it would indicate that a sales order for 250 had been received in each of the 13 weeks covered by the forecast entry. Since this is clearly not the case, the forecast consumption process must break up the record into two separate records in MRP_FORECAST_DATES. It does this by first creating a new record in MRP_FORECAST_DATES with the following values: FORECAST_DATE: 26-APR-99 RATE_END_DATE: <blank> ORIGINAL_FORECAST_QUANTITY: 1000 CURRENT_FORECAST_QUANTITY: 750 The NULL value for RATE_END_DATE indicates that the forecast entry is valid only for the week indicated by FORECAST_DATE. It then updates the original record in MFD:

 FORECAST_DATE: 03-MAY-99 RATE_END_DATE: 19-JUL-99 ORIGINAL_FORECAST_QUANTITY: 1000 CURRENT_FORECAST_QUANTITY: 1000 Each time consumption takes place in a new time bucket, the forecast consumption process creates a new record in MFD, valid for that bucket only. Each time a forecast entry is consumed, the details for that consumption are stored in the following columns in MRP_FORECAST_UPDATES: TRANSACTION_ID Links back to MRP_FORECAST_DATES to indicate which forecast entry was consumed SALES_ORDER_SCHEDULE_DATE The scheduled ship date of the sales order that consumed the forecast FORECAST_UPDATE_DATE The date of the forecast entry that was consumed SALES_ORDER_QUANTITY The total quantity of the sales order UPDATE_QUANTITY The quantity of the forecast entry that was consumed by this sales order The table (owned by Oracle Inventory) that holds sales order demand is MTL_DEMAND. Forecast consumption is only one of the many ways this extremely important table is used. Here are the columns from this table which are relevant to forecast consumption only: UPDATED_FLAG Initially 1 to indicate that the Planning Manager has not yet processed this demand. Set to 2 after processing by Planning Manager. SHIP_TO_SITE_USE_ID BILL_TO_SITE_USE_ID CUSTOMER_ID These three columns must contain a value to enable forecast consumption. If OE and AR are installed, these will reference actual records in the customer master. If OE and AR are not installed and the demand was imported through the Open Demand Interface, these fields should contain any value (not validated). DEMAND_CLASS

The demand class of the sales order. Reporting on Forecast Data Due to the nature with which forecast entries are stored in the database, generating custom reports on forecast data is not a trivial exercise. For example, recall the multiple-week forecast discussed in the previous section: FORECAST_DATE: 26-APR-99 RATE_END_DATE: 19-JUL-99 ORIGINAL_FORECAST_QUANTITY: 1000 CURRENT_FORECAST_QUANTITY: 1000 Remember that this forecast entry is a single record in the table MRP_FORECAST_DATES. This record actually represents thirteen separate forecast entries, each valid for a specific week, with a forecasted quantity of 1000 for that week. Any report that includes the entire date range covered by this forecast entry should show a total forecasted quantity of 13,000. Consider a simple custom report that shows the forecasted quantity for a specific item in a user entered date range. A simple SELECT statement, which would compute the sum of the column ORIGINAL_FORECAST_QUANTITY for the given date range, would certainly understate the forecasted quantity for this entry. Since there is only one record in the table for this entry, the sum would only total 1000. Also, what if the report date range included only part of the period of time covered by the forecast entry? One technique I have employed for many custom reports involving forecast data involves a custom database packaged procedure that acts a sort of "pre-processor." This stored procedure is invoked in the BEFORE REPORT trigger of any custom report which requires forecast data. Simply put, the stored procedure "explodes" the forecast into separate entries per bucket and stores the records in a temporary table, which is then queried by the report. Another stored procedure in the package is invoked in the AFTER REPORT trigger which purges the data from the temporary table. The basic premise of the procedure is to loop through all appropriate forecast entries in MRP_FORECAST_DATES, and for each record in the table, apply the following logic: If RATE_END_DATE for the record is NULL, this forecast entry is defined only for one bucket, so insert this record directly into the temporary table. If RATE_END_DATE is NOT NULL, this forecast entry is defined for multiple buckets. The procedure then determines the number of buckets covered between the FORECAST_DATE and RATE_END_DATE, and inserts an equal number of single-bucket records into the temporary table for reporting. Each record inserted into the temporary table would have a FORECAST_DATE appropriate for the individual bucket that it covers. In the example given at the beginning of this section, the procedure would insert 13 records into the temporary table, as follows: (record 1)

FORECAST_DATE: 26-APR-99 ORIGINAL_FORECAST_QUANTITY: 1000 (record 2) FORECAST_DATE: 03-MAY-99 ORIGINAL_FORECAST_QUANTITY: 1000 . . . (record 12) FORECAST_DATE: 12-JUL-99 ORIGINAL_FORECAST_QUANTITY: 1000 (record 13) FORECAST_DATE: 19-JUL-99 ORIGINAL_FORECAST_QUANTITY: 1000 After this procedure is complete, designing any type of custom forecasting report is quite simple. The report can then bucket and present the data in a variety of ways. One useful custom forecast report involves computing the accuracy of previous period forecasts. The forecast error can be computed in any number of generally accepted ways, the most common of which may be the mean absolute deviation, or MAD. To produce the MAD for a forecast, take the average of the absolute values of the difference between the forecast for a period and the actual demand for that period. Absolute values are used so that positive and negative forecast errors do not offset each other. Alerts A very useful Alert relating to forecasting comes pre-installed with Oracle. This alert is designed to trigger when the Planning Manager overconsumes a forecast for a forecasted item. This occurs when the total sales order demand during a given period exceeds the total forecast during that period, as governed by the consumption rules for the forecast set. By default, this alert is installed but not enabled. In addition, certain modifications to this alert can be used to make the alert even more effective. One enhancement to this alert is to modify the alert so that the planner of the item in question is notified whenever the overconsumption occurs. When Planners are defined on the Define Planners form in Oracle Inventory, an electronic mail address is associated with each planner code. The alert can easily use the electronic mail address specified for the planner to send the planner an e-mail each time one of that planners items is o Show Related Information Related Products

* More Applications > Value Chain Planning > Supply Chain Planning > Oracle Materials Requirement Planning Keywords CUTOFF DATE; DEMAND CLASSES; FORECAST; MANUFACTURING; MRP_FORECAST_DATES; MRP_FORECAST_DESIGNATORS; PLANNING PERCENTAGE; SALES ORDER Back to topBack to top Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement Rate this document Article Rating Rate this document Excellent Good Poor Did this document help you? Yes No Just browsing How easy was it to find this document? Very easy Somewhat easy Not easy Comments Provide feedback for this article. Please use 'Contact Us' for other feedback. Important Note: this feedback may be anonymously visible to other customers until processed by Oracle Support. Cancel