Beruflich Dokumente
Kultur Dokumente
Manufacturing
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.
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:
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-JUL99, 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-NOV-99.
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:
: 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 outlierupdate 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:
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.
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-APR-99. 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