Forecasting for Success: A Complete Forecasting Guide for Oracle

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:

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-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:

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 13month 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 season-enhanced 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 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:

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 26APR-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-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