Forecasting in Oracle Inventory

Vindaloo Systems White Paper – Forecasting
Doc ref: ORCL-AUS-FORECAST-11I
Page 1
ORACLE APPLICATIONS DISCUSSION PAPER–
FORECASTING
AUTHOR: VINDALOO SYSTEMS
VERSION: ISSUE I
VERSION DATE: MONDAY, 10 JUNE 2003
DOC. REF.: ORCL-AUS-FORECAST -11I

Page 2
DDDOOOCCCUUUMMMEEENNNTTT CCCOOONNNTTTRRROOOLLL
CCCHHHAAANNNGGGEEE RRREEECCCOOORRRDDD
Date Author Version Change Reference
10-Jun-2003 Vindaloo Systems Draft 1a No previous version
06-Jun-2004 Vindaloo Systems Issue 1 Changes for Internal
discussion
RRREEEVVVIIIEEEWWWEEERRRSSS
Name Position
Vindaloo Systems
DDDIIISSSTTTRRRIIIBBBUUUTTTIIIOOONNN
Approved versions of this document (i.e., where the Version is ISSUE rather than DRAFT) have
been distributed to the following:
Name Location/Title
Master Copy Vindaloo Systems Library
Grant Wild Vindaloo Systems
Consulting Director
All reviewers (see Reviewers table above)
NOTE To Holders:
If you receive an electronic copy of this document and print it out, you should write your name on
the front cover (for document control purposes).
If you receive a hard copy of this document, please write your name on the front cover (for
document control purposes).

Page 3
CCCOOONNNTTTEEENNNTTTSSS
DOCUMENT CONTROL................................................................................................................. 2
Change Record............................................................................................................................................... 2
Reviewers....................................................................................................................................................... 2
Distribution .................................................................................................................................................... 2
CONTENTS..................................................................................................................................... 3
INTRODUCTION ............................................................................................................................. 5
DEFINITIONS.................................................................................................................................. 6
LOADING FORECAST DATA ........................................................................................................ 7
Forecast Entries form.................................................................................................................................... 7
Open Forecast Interface................................................................................................................................. 7
Focus and Statistical forecast generation. ..................................................................................................... 8
How focus forecasting works........................................................................................................................ 8
How to generate a focus forecast .................................................................................................................. 9
How statistical forecasting works................................................................................................................ 10
How to generate a statistical forecast.......................................................................................................... 11
FORECAST CONSUMPTION....................................................................................................... 12
Communicating sales order demand to Oracle Manufacturing.................................................................. 12
How forecast consumption works............................................................................................................... 12
What about demand classes?....................................................................................................................... 13
TECHNICAL DETAILS ................................................................................................................. 14
REPORTING ON FORECAST DATA........................................................................................... 18
ALERTS ........................................................................................................................................ 20

Page 4

Page 5
IIINNNTTTRRROOODDDUUUCCCTTTIIIOOONNN
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.

Page 6
DDDEEEFFFIIINNNIIITTTIIIOOONNNSSS
A forecast is an estimate of anticipated customer demand on your company s 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.

Page 7
LLLOOOAAADDDIIINNNGGG FFFOOORRREEECCCAAASSSTTT
DDDAAATTTAAA
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.
FFFOOORRREEECCCAAASSSTTT EEENNNTTTRRRIIIEEESSS FFFOOORRRMMM...
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-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.
OOOPPPEEENNN FFFOOORRREEECCCAAASSSTTT IIINNNTTTEEERRRFFFAAACCCEEE...

Page 8
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.
FFFOOOCCCUUUSSS AAANNNDDD SSSTTTAAATTTIIISSSTTTIIICCCAAALLL FFFOOORRREEECCCAAASSSTTT GGGEEENNNEEERRRAAATTTIIIOOONNN...
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.
HHHOOOWWW FFFOOOCCCUUUSSS FFFOOORRREEECCCAAASSSTTTIIINNNGGG WWWOOORRRKKKSSS.
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 bucket’s 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

Page 9
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.
HHHOOOWWW TTTOOO GGGEEENNNEEERRRAAATTTEEE AAA FFFOOOCCCUUUSSS FFFOOORRREEECCCAAASSSTTT
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.

Page 10
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.
HHHOOOWWW SSSTTTAAATTTIIISSSTTTIIICCCAAALLL FFFOOORRREEECCCAAASSSTTTIIINNNGGG WWWOOORRRKKKSSS...
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.

Page 11
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.
HHHOOOWWW TTTOOO GGGEEENNNEEERRRAAATTTEEE AAA SSSTTTAAATTTIIISSSTTTIIICCCAAALLL FFFOOORRREEECCCAAASSSTTT...
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.

Page 12
FFFOOORRREEECCCAAASSSTTT
CCCOOONNNSSSUUUMMMPPPTTTIIIOOONNN
Forecast consumption refers to the process of replacing forecasted demand with actual demand,
as the actual demand is received.
CCCOOOMMMMMMUUUNNNIIICCCAAATTTIIINNNGGG SSSAAALLLEEESSS OOORRRDDDEEERRR DDDEEEMMMAAANNNDDD TTTOOO OOORRRAAACCCLLLEEE MMMAAANNNUUUFFFAAACCCTTTUUURRRIIINNNGGG...
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.
HHHOOOWWW FFFOOORRREEECCCAAASSSTTT CCCOOONNNSSSUUUMMMPPPTTTIIIOOONNN WWWOOORRRKKKSSS.
Three parameters govern how the Planning Manager consumes forecasts with sales order
demand.
The outlier update percent specifies how much of a given forecast s 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

Page 13
• 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.
WWWHHHAAATTT AAABBBOOOUUUTTT DDDEEEMMMAAANNNDDD CCCLLLAAASSSSSSEEESSS???
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.

Page 14
TTTEEECCCHHHNNNIIICCCAAALLL DDDEEETTTAAAIIILLLSSS
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.

Page 15
• 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-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:

Page 16
• RATE_END_DATE: <blank>
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
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

Page 17
• 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.

Page 18
RRREEEPPPOOORRRTTTIIINNNGGG OOONNN
FFFOOORRREEECCCAAASSSTTT DDDAAATTTAAA
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:
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

Page 19
ORIGINAL_FORECAST_QUANTITY: 1000
(record 2)
FORECAST_DATE: 03-MAY-99
.
.
.
(record 12)
FORECAST_DATE: 12-JUL-99
(record 13)
FORECAST_DATE: 19-JUL-99
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.

Page 20
AAALLLEEERRRTTTSSS
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 planner s items is overconsumed.
.

Forecasting in Oracle Inventory

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Forecasting in Oracle Inventory

Similar to Forecasting in Oracle Inventory (20)

More from Baker Khader Abdallah, PMP

More from Baker Khader Abdallah, PMP (20)

Recently uploaded

Recently uploaded (20)

Forecasting in Oracle Inventory