Documente Academic
Documente Profesional
Documente Cultură
MRP logic
An Oracle White Paper
February, 2003
Balancing Demand & Supply: A Brief Guide to MRP logic
ABSTRACT
The purpose of material planning is to balance material supply to demand by simulating the future.
Whenever, the user runs a Material Requirements Plan, the planning engine performs a requirements explosion.
Through this process the engine takes a quick but detailed look at the existing sources of demand and supply. It looks at
the dates when make or buy items are required, the dates when these items are due into inventory and suggests the
dates when additional quantities need to be procured or produced to ensure that the requirements are met in terms of
quantity and time.
How the planning engine performs this task is beyond the scope of this paper. The purpose this paper intends to fulfil is
to analyse and explain the outcome, which the planning process generates every time a material plan is run. The paper
interprets how the changes we make to the planning environment affect the outcome and helps us understand why
planning responds the way it does to these changes.
The Planning Detail Report (MRRDPR) is the chosen tool we would be using extensively to study and analyse the
behaviour of the planning engine. This report is written in Pro*C and its output reflects comprehensively, the outcome of
any Material Plan run.
This paper is intended for an audience familiar with the planning process, and involved in creating and executing MPS
and MRP plans in discrete manufacturing. The content of this paper is arranged in a manner so as to take the audience
through a guided tour of the discrete planning process. The journey begins with the creation of demand (independent
demand) and watching the demand percolate down the bill of material. We would then be introducing sources of
scheduled receipts first at the assembly level and then at the component level and analyse the impact of doing so.
There are in essence seven sources of scheduled receipts – discrete jobs, purchase requisitions, purchase orders,
purchase orders in receiving, internal (purchase) requisitions, intransit shipments and intransit receipts (i.e. intransit
shipments in receiving). To avoid repetition, we shall not be using the last three. With the aid of the first four, we shall
be covering the salient points that would help us develop the level of understanding that we have set out to achieve.
However, it must be noted that this paper does not claim to be an exhaustive study on the material planning process as
it is virtually impossible to cover the entire expanse of the material planning subject in the course of a single paper.
The planning process begins with a driving schedule that has item numbers, quantities and due dates. For a master
production schedule (MPS) plan, the driving schedule is a master demand schedule (MDS). The MDS forms the
consolidated source of independent demand. For a distribution requirements plan (DRP) and a material requirements
plan (MRP), the driving schedule is either a master demand schedule or a master production schedule. In this paper we
shall begin our tests with an MDS and use it to drive our MRP run.
Oracle Manufacturing supports two scheduling methods for discrete manufacturing – detailed scheduling and
dynamic lead-time offsetting. Detailed scheduling is the most precise scheduling method in Oracle Manufacturing. It
helps schedule jobs to the minute based on detailed resource availability and usages. This method is employed by
Oracle Work In Process and by Oracle Bills of Material. Oracle Planning uses dynamic lead-time offsetting. Through
this scheduling algorithm, the system calculates the start date of an order based on order quantity, lead times, and the
workday calendar. It is essentially a given date plus or minus the number of workdays. To appreciate the dynamic lead-
time offsetting concept, we need to familiarise ourselves with a few lead time components that apply to buy and make
items. These are displayed in Fig 1 below. It is to be noted that all lead time components are calculated and
stored in days (even if the resource usages are measured in hours).
Preprocessing Lead Time is the time required to release a purchased order or a job from the time the requirement is
acknowledged. This has to be manually entered in the item definition form for buy items and for make items (if
required).
Processing Lead Time is the time required to procure or manufacture an item. This has to be manually entered in the
item definition form for a buy item. For a make item, Oracle Bills of Material calculates the same when you run the
Calculate Manufacturing Lead Times GUI program. This program calculates the Fixed Lead Time and the Variable
Lead Time for make items and populates the values in the item definition form. Assuming a Lead Time Lot Size of 1,
the value populated into the fixed and variable lead time fields is calculated as follows:
Fixed Lead Time = Sum of the Usages of the Lot Based Resources in the item’s primary
Routing (calculated in days).
Variable Lead Time = Sum of the Usages of the Item Based Resources in the item’s primary
Routing (calculated in days).
This calculation applies only to those resources that have the Schedule flag set to ‘Yes’ and that have a UOM that
belongs to the same UOM Class as the UOM entered in the profile option BOM: Hour UOM. For example, in the Vision
instance, this profile has a (UOM) value HR for hours. So, the scheduling algorithm will pick up all resources that have a
UOM defined as HR or any other UOM that belongs to the UOM Class to which HR belongs.
Once the algorithm calculates the fixed and the variable lead times it calculates the Cumulative Manufacturing Lead
Time for the make item by adding the fixed and the variable lead times, and rounding the result to the next whole
number.
Cumulative Manufacturing Lead Time is the total time required to make an item if you have all raw materials in stock
but have to make all subassemblies level by level. This value is then populated into the Processing lead time field in
the item definition form. However, when executing the material plan the system does not pick up this processing lead
time value for the make item. The system uses the following lead time formula to schedule the plan dates for make
items.
Planned order lead time (Lead Time Offset)
= Fixed Lead Time + (order quantity * Variable Lead Time)
It is the time that the shop floor needs to produce the order.This is the formula that we will be referring to again and
again when interpreting the outcome of the MRP.
Postprocessing Lead Time is the time required to make a purchased item available in inventory from the time it is
received at the dock. This may include the margin we keep for inspection, quality testing, material handling etc. This
applies only to buy items and is not relevant for make items. For buy items you have to manually enter this value in the
item definition form.
Now that all the individual lead time component values are in place, it is time to run the Rollup Cumulative Lead
Times GUI program. This concurrent program populates the field Cumulative Total in the item definition form.
Cumulative Total Lead Time is the total time required to make an item if no inventory exists and you have to order all
the raw materials and make all subassemblies level by level.
For buy items:
Cumulative Total Lead Time = Preprocessing Lead time + Processing Lead Time
+ Postprocessing Lead Time
This is the formula we shall be referring to most frequently when analysing how Planning schedules buy items.
The setup we shall perform in this paper will help illustrate how these formulae work.
Start Date for Make Items = Due Date – Lead time Offset
= Due Date – [Fixed Lead Time + (order quantity * Variable Lead Time)]
Order Date for Make Items = Start Date – Preprocessing Lead Time
Due Date for Buy Items = Dock Date + Postprocessing Lead time
A point to note here is that the Dock Date for a purchase order or a purchase requisition is picked up from the Need By
date entered against that order or requisition.
Start Date for Buy Items = Dock date – Processing Lead Time
Order Date for Buy Items = Start Date – Preprocessing Lead Time
CREATING A SETUP
To recreate a planning scenario, we need to establish a basic setup on which to build our foundation for the test cases.
What if Resources are assigned to shifts - A Special Note on (5): Here, I have
assumed that the resources are available on a 24-hour basis. Although I would be using
the results of this setup (as created in (5)) in the test cases that follow, it is worth noting
that a more realistic scenario may demand that resources be available in specific shifts,
neither before nor after. Initially, the lead time offset algorithm of Oracle Planning used to
consider workday and workday exception information from the organization calendar, but
would ignore shift and shift exception information. In essence, the lead time calculation
program would consider 24 hours per shift regardless of the shifts specified for the
resources in a department. This picture has been rectified in Bug 2014692. The
fix introduced through this bug ensures that the lead time calculation takes into account
shift timings (if shifts are attached to “Scheduled” resources) and the gaps between the
shifts. To demonstrate this, we shall be creating two supplementary setups (5.1) and (5.2)
within step (5). Steps (5.1) and (5.2) are not to be linked to the setup of step (5), but
should only be viewed in a parallel perspective.
Therefore, Cumulative Manufacturing Lead Time (FinG) = 0.3 + 0.125 = 0.425 day
which is rounded to the next whole number that is 1.
Hence, Cumulative Manufacturing Lead Time = 1 day.
This implies that if Pur1 and Pur2 were already available in Inventory, it would require a period of 1 day
to manufacture the assembly FinG, provided the resources are available 24 Hours.
This value is populated into the Processing Lead Time field.
Hence, Processing Lead Time = 1 day.
We shall need these figures to interpret the scheduling suggested by MRP for item FinG, later in this paper.
A Special Note for the setup created in steps (5.1) and (5.2):
If you run the Calculate Manufacturing Lead Times GUI for Item = FinG for the setup in (5.1) or for the setup in
(5.2), you will find that both these cases result in the following calculations:
Fixed = 0.9
Variable = 0.375
This is because as per the fix in Bug 2014692, the lead time calculation program has to consider that each
resource is available for a 8-hour (which is the shift duration) period per day.
Therefore,
Fixed Lead Time = Sum(Lot Based Resource Usage) = Res1 + Res3
= 4.8HR/Lot + 2.4HR/Lot
= (4.8HR/Lot)/(8HR/day) + (2.4HR/Lot)/(8HR/day)
= 0.6 day + 0.3 day = 0.9 day
Variable Lead Time = Sum(Item Based Resource Usage) = Res2 + Res4
= 1HR/Item + 2HR/Item
= (1HR/Item)/(8HR/day) + (2HR/Item)/(8HR/day)
= 0.125 day + 0.25 day = 0.375 day
Processing Lead time (for FinG) = 2 day (the sum of fixed and variable lead times rounded to the next whole
number).
This implies that if Pur1 and Pur2 were already available in Inventory, it would require a period of 2
days to manufacture the assembly FinG, given that the resources are available for an 8-Hour period
(shift) per day.
Conclusion: Whether resources are assigned to specific shifts or available on a 24 hour basis, the ultimate
impact would be on the calculation of the Fixed and the Variable Lead Time components. If resources are
available only in specific shifts, then the Fixed and Variable Lead times are likely to have higher values (as
shown above) than when resources are available 24 hours, which in turn would raise the span of the Lead Time
Offset. Thus the Lead Time Offset formula will ensure that planning comes up with realistic suggested dates
keeping the restricted availability of the resources into consideration.
However, as already pointed out in (5), for the test cases that follow, we shall stick to our original
values of Fixed = 0.3 and Variable = 0.125.
(11) Before you launch the plan, you need to ensure that the Planning Manager is active.
Material Planning: Setup > Planning Manager. The “Active” checkbox should be checked.
If it is not, then you need to click on the “Start” button to launch the Planning Manager.
Material Planning: MRP > Launch
Launch MRP_FinG
In the Launch MRP Parameters form we find the following values as defaulting
Anchor Date = 10-Feb-2003
Plan Horizon = 12-Aug-2003
Where do these dates default from?
These dates appear based on the value of the profile option MRP:Cutoff Date Offset
Months. The default value for this is 6. This implies a planning horizon of 6 months.
Anchor Date reflects the first working day of the week (as per the organization calendar)
in which the plan is being launched. Since the plan was being launched on 10-Feb-2003
which was a Monday, the same became the Anchor Date. If you relaunch this plan on any
day within this week, the Anchor Date would continue to display the default value of 10-
Feb-2003. The Plan Horizon date is calculated at a space of 6 months from the Anchor
Date. If you change the profile option value to 3 and then proceed to launch the plan, you
would get the following result: Anchor Date = 10-Feb-2003 and Plan Horizon = 10-May-
2003 - a spacing of 3 months. In the time phasing for the Plan Horizon, there is no
distinction made by the system between workdays and non-workdays.
Note: The organization calendar defined for organization M3 in the Vision database is
Vision01. This calendar has a 5-day week starting with Monday. This is why, when we run
the plan, in the Horizontal Listing section of the Planning Detail Report output, we would
find weekly buckets listed by the dates on the Mondays in each week, e.g., 10-Feb-2003,
17-Feb-2003, 24-Feb-2003, and so on.
(12) Now run the Planning Detail Report for item FinG only.
Material Planning: Reports
Accept the defaults in the report parameters screen. Enter FinG in the Item From and To
fields. Throughout this paper, when we run this report, our only intervention in the report
parameters screen would be to enter the item number(s).
When the report executes successfully, you would note that the header contains the
values of some specific item parameters that are of significance to the planning process.
The Plan Date appears on the top right indicating the date the plan was run. Nettable
Inventory, Non-nettable Inventory and Receiving Inventory show the current supply status
for item FinG.
Note: Annual Projected Demand = 249. This figure was arrived at through the following
formula: Annual Projected Demand =
(Demand for Planning Horizon) * (365/length of Planning Horizon)
= 125 * (365/183) = 249 (rounded).
Demand for Planning Horizon = Sum total of gross requirement in the planning horizon,
which in our case works out to 125. How? This is explained in the next paragraph.
Length of planning horizon = Plan Horizon date – Anchor Date
= 12-Aug-2003 – 10-Feb-2003 = 183 days.
The output also shows a Shrinkage Rate of 0.20 and Planning Time Fence Date of 11-
Feb-03. In Inventory: Items > Organization Items > (T) MPS/MRP Planning, the Planning
Time Fence was kept as User-Defined with 1 days (default value) for FinG. Since the plan
date is 10-Feb-2003, we get 11-Feb-2003 as the planning time fence date. This paper
would not delve into time fences as that is a topic that has been adequately documented.
Note: We had manually entered demand for quantity = 100 for 12-Apr-2003 in our MDS.
However, since we had defined a Shrinkage Rate of 0.20 in the item definition form for
FinG, planning calculates a Gross Requirement = Demand/(1 – Shrinkage Rate)
= 100/(1 – 0.2) = 125, which is what we see here. In our case, this is the sole demand for
the planning horizon for FinG. So, the system suggests Planned Orders for 125 units of
FinG since we have zero inventory for FinG.
Note: We had manually entered demand for quantity = 100 for 12-Apr-2003 in our MDS.
However, since 12-Apr-2003 (Saturday) is a non-workday as per the organization
calendar (which is Vision01 for org M3, in the Vision instance), the demand has been
“shifted” to the nearest workday in the same week i.e. Friday, 11-Apr-2003. However, the
additional demand generated by the introduction of the shrinkage rate appears (on the
same date) as a Demand Type of “Planned order scrap”. This throws some light on what
shrinkage stands for. Shrinkage Rate reflects an anticipated loss of the item during
its manufacture or procurement. This leads to an inflation of demand and order
quantities to account for this expected loss.
As expected, planning suggests planned order quantity for 125 units of FinG on 11-Apr-
2003.
Note: Since, FinG has Preprocessing Lead Time = 0, we will find that planned order Start
Date = Order Date for FinG. But, we find that Due Date – Start Date
= 11-Apr-2003 – 20-Mar-2003 = 16 workdays. Why?
Due Date – Start Date = Lead Time Offset
= Fixed Lead Time + (order quantity * Variable Lead Time)
= 0.3 + (125 * 0.125) = 15.925 days = 16 days (rounded)
(13) Now run the Planning Detail Report for Pur1 and Pur2.
For Pur1, we notice that the Lead Time component values are displayed along with the
20% Safety Stock factor.
The gross requirement for Pur1 falls in the weekly bucket of 17-Mar-2003. We shall
shortly see why that is so. The demand for 125 units of Pur1 derives from the demand for
125 units of FinG.
Note: Planning has calculated safety stock of 5 units for Pur1. The following is the
formula planning uses to do this.
Safety Stock = (Gross Requirement/Safety Stock Bucket Days) * Safety Stock%
= (125/5) * 20% = 5
In discrete material planning, a day that has no gross requirement has its safety stock
calculated as the previous day’s safety stock. This is why for all buckets subsequent to
the 17-Mar-2003 bucket we see the 5 units of safety stock carried forward.
A word on the Projected rows. The Projected rows represent the projected inventory
balance at the end of the period. There are two types.
Current Projected On Hand represents the projected inventory balance at the end of the
period with no planning process suggestions. It is calculated as follows:
Current Projected On Hand = (Quantity on Hand + Scheduled Receipts)
- Gross Requirements
= (0 + 0) – 125 = -125
Projected Available represents inventory balance or stock on hand. The values given for
a specific period represent the projected inventory balance at the end of the period with
the planning process suggestions included. If the item has safety stock defined, the
planning process arranges for Projected Available to be the safety stock quantity (as
has happened in our case); otherwise the planning process arranges for Projected
Available to be zero. It is calculated as follows.
Projected Available = (Quantity on Hand + Scheduled Receipts + Planned Orders)
- Gross Requirements
In this case, since we have a safety stock calculation of 5 units, this will become our
Projected Available (at the end of the week starting 17-Mar-2003). Substituting the
available values we get: 5 = (0 + 0 + Planned Orders) – 125, which means planning
needs to suggest Planned Order for 130 units.
This is the demand scenario for Pur1. In (12) we saw that planning suggests Order Date
and Start Date for the Planned Order for FinG on 20-Mar-2003. This explains why the
Demand Date for Pur1 is scheduled as 20-Mar-2003. As a consequence, the demand for
125 units of Pur1 appears in the Horizontal plan under the weekly bucket starting 17-Mar-
2003.
This shows the scheduling of the suggested Planned Order for Pur1.
Note: In keeping with the Demand Date for Pur1, the Planned Order Due Date for Pur1
has been fixed as 20-Mar-2003. But we now come across a new parameter –
Compression Days, which works out to 15 days. To understand more about
Compression Days, we need to focus on a fundamental tenet of the Dynamic Lead Time
Offsetting algorithm. Oracle Planning does not schedule into the past. When the
calculated start date precedes the system date, Oracle Planning uses the system
date for the start date (In contrast, Oracle Work in Process schedules into the past in
these cases). Thus in Oracle Planning, the lead time offset algorithm, compresses jobs to
start on the current date (system date), if the calculated start date would be in the past.
Therefore, in our case, the Suggested Order Date for the Planned Order has to be
the system date i.e. 10-Feb-2003. So, we now have dates at the two ends as fixed. Now
let us recall the lead time components as defined for Pur1 and compare these with the
distance between the dates.
As per planning:
Suggested Due Date – Suggested Dock Date = 20-Mar-2003 – 04-Mar-2003
= 12 workdays
As defined for the item:
Postprocessing Lead Time (= Due Date – Dock Date) = 12 days.
So there is no compression in this time segment.
As per planning:
Suggested Dock Date – Suggested Start Date = 04-Mar-2003 – 10-Feb-2003
= 16 workdays
As defined for the item:
Processing Lead Time (= Dock Date – Start Date) = 30 days.
So, compression = (30 – 16) days = 14 days.
As per planning:
Suggested Start Date – Suggested Order Date = 10-Feb-2003 – 10-Feb-2003
= 0 workdays
As defined for the item:
Preprocessing Lead Time (= Start Date – Order Date) = 1 day.
So, compression = (1 – 0) days = 1 day.
Therefore, Compression Days = (14 + 1) days = 15 days.
Note: The gross requirement for Pur2 is calculated as 156 and not 125. This is because
we had introduced a Yield of 0.8 for component Pur2 in the bill of material for FinG. So, if
FinG has a demand of 125, planning will calculate the demand for Pur2 as 125/(0.8) =
156.3 = 156 (rounded).
Thus we find that shrinkage and yield are essentially parameters to instruct the planning
process to overplan supply for an anticipated loss in the manufacturing process.
Just as for Pur1, Pur2 too has a Demand Date of 20-Mar-2003, keeping in view the Order
and Start Date of the Planned Order for FinG.
So planning suggests a Due Date for Pur2 to match its Demand Date. The Order Date
can be no less than the system date of 10-Feb-2003. so, as expected there is a
compression introduced by this scheduling. The same can be verified based on the
Compression Days calculation we performed for Pur1 above.
The released discrete job becomes a source of supply for the final assembly FinG. As
such, planning treats it as a scheduled receipt.
Note: The job is scheduled (by Work In Process) to be completed on 09-Mar-2003 which
happens to be a Sunday and hence a non-workday as per the organization calendar.
Therefore, as seen earlier in (12), the scheduled receipt has been “shifted” to the nearest
workday in the same week i.e. Monday, 10-Mar-2003. This is why the Current Scheduled
Receipts shows 15 units in the 10-Mar-2003 bucket. Based on the formula we had spelt
out in (13), the current Projected On Hand works out to 15. But the actual demand arises
in the 07-Apr-2003 bucket. Therefore planning will suggest a “reschedule out” of the job to
this bucket. Planned Order quantity suggested would be reduced by the amount of the job
MRP Net Quantity. We had a demand for 125. Now, with a scheduled receipt of 15, the
planned order quantity drops to 125 – 15 = 110. But planning arrives at the same result
with a slightly different logic. This is how planning resolves this scenario. There is an
expected receipt of 15 units through the discrete job. Looking at the shrinkage rate,
planning estimates that 20% of these 15 units will be lost in production. 20% of 15 = 3.
This leaves a net supply from the job of (15 – 3) units = 12 units. Since we have a total
demand of 100 and supply of 12, we have a net requirement of 100 – 12 = 88 units. Now,
if planning is to suggest a planned order of 88 units it must consider that 20% of this
quantity will also be lost to shrinkage. Therefore, planning will suggest a planned order
quantity = 88/(1 – 0.2) = 110 units. Therefore, if we have a shrinkage rate of 0.2, planning
essentially assumes that 20% of any current discrete job and 20% of any suggested
planned order will be lost to shrinkage.
Let us review the gross requirement scenario. On the lines of the planning logic explained
above, there is the original MDS Demand for 100 units.
Note: When we have a shrinkage rate for the assembly, planning uses the following
formula to calculate total demand:
Total Demand = Original Demand + Discrete Job shrinkage
+ Planned Order shrinkage
= Original Demand + (Job Quantity * Shrinkage Rate)
+ (Planned Order Quantity * Shrinkage Rate)
= 100 + (15 * 0.2) + (110 * 0.2) = 100 + 3 + 22 = 125.
These three components of total demand appear above as:
Discrete job scrap (or Discrete Job shrinkage) = 3 units
Planned order scrap (or Planned Order shrinkage) = 22 units
Manual MDS (our Original Demand) = 100 units.
(15) Now rerun the Planning Detail Report for Pur1 and Pur2.
The Horizontal Listing for Pur1 now shows a demand for 20 units for the discrete job in
the 07-Apr-2003 bucket. This is in keeping with the Reschedule out action of the job by
planning, as seen in (14) above. The job was a scheduled receipt for FinG, scheduled for
11-Apr-2003. It now becomes a source of demand for Pur1 (and so too for Pur2).
Note: There are a number of important points to note here.
Start Quantity versus MRP Net Quantity: With respect to the discrete job, planning had
considered the MRP Net Quantity of 15 for FinG. However, for the components Pur1 and
Pur2, planning picks up the job Start Quantity of 20. This is the intended behaviour. The
component requirements are always based on the job Start Quantity. The assembly
supply is always based on the MRP Net Quantity. The reasons for the Start and Net
Quantity being different are typically, either to reflect a yield loss of the assembly (e.g. due
to destructive testing of x% of the job quantity) or to reflect a different usage for some of
the assembly (e.g. 5 units of the assembly are to be diverted for a trade exhibition, so do
not count towards on-hand inventory, rather put them into a non nettable subinventory). In
both cases, we have to plan to go through the manufacturing process for 100% of the
Start Quantity (20 in our example) even though we only expect that a smaller number (15
in our example) will find their way into a nettable subinventory.
Safety Stock calculation: For the 07-Apr-2003 bucket, the Safety Stock = 1. Going by
the Safety Sock formula in (13):
Safety Stock = (20/5) * 20% = 0.8 = 1 (rounded).
Projected Available calculation: The Safety Stock of 1 becomes the Projected Available
for the 07-Apr-2003 bucket.
Planned Order calculation: Let us refer the formula for Projected Available from (13).
Projected Available = (Quantity on Hand + Scheduled Receipts + Planned Orders)
- Gross Requirements
= (Projected Available for the previous period + Planned Orders)
- Gross Requirements
Substituting the values known to us, in the above formula:
1 = (5 + Planned Orders) – 20, which gives Planned Orders = 16.
The discrete job start Quantity reflects as demand for Pur1 over and above the initial
Planned Order demand for 110.
Besides, the 16 units of Planned Order for the discrete job demand, the gross
requirement for 110 units of Pur1 translates into a 115 units Planned Order suggestion by
incorporating the 5 units of safety stock.
The Horizontal Listing for Pur2, shows the discrete job demand of 20 inflated by a yield
factor of 0.8.
(16) Now perform a Miscellaneous Receipt of 10 units each of Pur1 and Pur2 into the Stores
subinventory (which is a nettable subinventory). Relaunch MRP_FinG. Once the plan
completes successfully, run the Planning Detail Report for Pur1 and Pur2.
For Pur1, Nettable Inventory increases to 10. The same happens to Pur2 as well.
The Projected Available becomes 10, and the Planned Order quantity drops from the
previous figure of 115 to 105. The same happens to Pur2 as well.
(17) Now perform a WIP component issue of 10 units each for Pur1 and Pur2 to the job number 39486. Then
complete 8 units of FinG and scrap 2 units. Now relaunch MRP_FinG. Once the plan completes successfully,
rerun the Planning Detail Report for FinG.
The completed quantity of 8 units of FinG appears as Nettable Inventory for FinG.
Note: Quantities completed into Inventory are no longer considered by planning as scheduled receipt. They
appear as Projected Available and Current Projected On Hand, since they increase the on hand stock.
Therefore, the scheduled receipt quantity reduces to MRP Net quantity – quantity completed to inventory –
quantity scrapped
= 15 – 8 – 2 = 5. This quantity of 5 units appears as Current Scheduled Receipts in the 10-Mar-2003 bucket,
since the actual job completion date is 09-Mar-2003. However, as planning had suggested that the job due date
be rescheduled out to 11-Apr-2003, the 5 units of job quantity appear as Scheduled Receipt in the 07-Apr-2003
bucket.
But, why does the Gross Requirement in the 07-Apr-2003 bucket reduce to 123 from the previous figure
of 125? Let us review the gross requirement break-up to get a better understanding.
Recall the concept of total demand as explained in (14).
Total Demand = Original Demand + Discrete Job shrinkage
+ Planned Order shrinkage
= Original Demand + (Job Quantity * Shrinkage Rate)
+ (Planned Order Quantity * Shrinkage Rate)
= 100 + (5 * 0.2) + (110 * 0.2) = 100 + 1 + 22 = 123.
Here, for FinG the Job (Scheduled Receipt) Quantity has changed from 15 to 5.
(18) Now run the Planning Detail Report for Pur1 and Pur2.
There is a slight change to be noted in the Horizontal Listing for Pur1. There is a demand
for 10 units of Pur1. This figure comes from job Start Quantity – quantity completed –
quantity scrapped = 20 – 8 – 2 = 10. However, for Pur2, this figure will be 25 – 8 – 2 = 15.
This is because, as seen in (15), the job demand of 20 units had been inflated to 25 units
during planning for Pur2 due to the 0.8 yield factor.
Now, relaunch MRP_FinG. Once the plan completes successfully, run the Planning Detail
Report for Pur1 and Pur2.
The Horizontal Listing for Pur1 shows that the purchase requisition quantity of 6 appears
as Scheduled Receipt. The same applies to Pur1.
Note: The Purchase Requisition Need By Date becomes the Current Dock Date for
planning. The same rule applies to Purchase Orders as well. Thereafter, the Current
Due Date of 18-Mar-2003 is arrived at by forward scheduling by the Postprocessing Lead
Time of 12 workdays from the Dock Date.
But the Compression Days calculation here is slightly different from our previous
examples, because we do not have the Order Date and the Start Date in this case.
This is how it works here.
Suggested Due Date - Suggested Dock Date = 21-Mar-2003 – 05-Mar-2003 = 12
workdays which matches with Pur1's Postprocessing Lead Time of 12 days. So we have
zero compression in this time segment.
This plan was run on 11-Feb-2003.
So from the Plan date (11-Feb-2003) to Suggested Dock Date (05-Mar-2003) would be
Preprocessing Lead Time + Processing Lead Time = 1 + 30 = 31 days.
However, Suggested Dock Date – 11-Feb-2003 = 05-Mar-2003 – 11-Feb-2003
= 16 workdays.
Therefore, required compression for Pur1 = (31 – 16) days = 15 days.
(20) Now, Autocreate a purchase order of quantity = 6, for each of Pur1 and Pur2 from the requisition created in
(19). Note the purchase order number created (PO #1773). Open the PO and set the Ship To field to M3-Dallas.
Approve the PO. Again, as in the case of a purchase requisition, a PO must be in Approved status and must
have the ship to location set to the location corresponding to the Inventory organization from which the plan is
being launched. Otherwise, planning will not be able to “see” the PO.
Now relaunch MRP_FinG. Once the plan completes successfully, run the Planning Detail Report for Pur1 and
Pur2.
As seen in the horizontal plan for Pur1, the PO quantity of 6 appears as Scheduled Receipt. The same applies
to Pur2 as well.
The logic here, for calculation of Compression Days is the same as that explained in (19).
(21) Now perform a receipt on PO number 1773. For Pur1 and Pur2, Destination Type = Receiving, Routing =
Standard Receipt. Receive 4 units each of Pur1 and Pur2. Save your work. Thus, 4 units each of Pur1 and Pur2
are received into the dock.
Relaunch MRP_FinG. Once the plan completes successfully, run the Planning Detail Report for Pur1 and Pur2.
For Pur1, the Receiving Inventory shows as 4. The same would apply to Pur2.
We now have two sets of scheduled receipts, but there is a difference.
The 4 units received into the dock, are treated by planning as Purchase Orders In Receiving which is still a form
of scheduled receipt but are treated differently from the 2 units of Pur1 in the PO that are yet to be received.
The 4 units are included in Projected Available in the bucket for 24-Feb-2003, because the Expected Release
Date of
27-Feb-2003 for these 4 units falls in that bucket.
Note: How is the Expected Release Date being calculated here?
Purchase Orders in receiving denote stock, which is in the Dock and is waiting to be released to Inventory.
Planning would estimate that this should take time equal to the Postprocessing Lead Time, which is 12 days for
Pur1.
Now, Receipt Date = 11-Feb-2003.
Receipt date + 12 workdays = 11-Feb-2003 + 12 workdays = 27-Feb-2003
= Expected Date of Release.
(22) From the Receiving Transactions form, perform a receipt into Destination = Inventory. Note the receipt number
(#2044). Receive all the 4 units each of Pur1 and Pur2 into Stores subinventory. Save your work. Check the
Stores subinventory, to ensure that the on hand quantity has increased for Pur1 and Pur2.
Now relaunch MRP_FinG. Once the plan completes successfully, run the Planning Detail Report for Pur1 and
Pur2.
The 4 units of Pur1 have “moved” from Receiving Inventory to Nettable Inventory.
The 4 units are now counted as on hand stock and therefore treated as Projected Available. They are available
from the date on which they were received i.e. 11-Feb-2003 which falls in the 10-Feb-2003 weekly bucket. The
same applies to Pur2.
CONCLUSION
Oracle Planning uses the dynamic lead time offset algorithm for scheduling which uses the order
quantity, lead time offset and the organization’s workday calendar. This algorithm picks up
workday and workday exception information from the calendar. The lead time offset is calculated
using the fixed lead time, variable lead time and the order quantity. For a make item, the fixed and
variable lead times are calculated by Oracle Bills Of Material through the Calculate Manufacturing
Lead Times GUI program. This calculation sums up the usage values of resources (from the
item’s routing), that have the Scheduled flag set to ‘Yes’ and have a UOM that belongs to the
same UOM Class as the UOM defined in the profile option BOM:Hour UOM. The fix introduced
in Bug 2014692 ensures that the manufacturing lead time calculation program would consider the
shift duration when calculating the fixed and variable lead times, if the resources are assigned to
specific shifts.
The lead time offset algorithm in Oracle Planning, compresses jobs to start on the current date
(system date), if the calculated start date would be in the past. This leads to the creation of
Compression Days in the planning output.
The value in the profile option MRP:Cutoff Date Offset Months determines the length of the
Planning horizon in months. The start and end dates for this horizon are visible in the fields
Anchor Date and Plan Horizon in the Launch MRP Parameters form. The plan horizon span does
not distinguish workdays from non-workdays.
Shrinkage Rate and Yield are parameters defined for items to instruct the planning process to
overplan supply for an anticipated loss in the manufacturing process. Shrinkage Rate operates at
the assembly level and impacts the components down the bill of material. Yield operates at the
component level. When using shrinkage, the total demand for the item is arrived at by taking into
account the discrete job shrinkage as well as the planned order shrinkage. Planning can also be
used to calculate and plan safety stock for a component or assembly.
Planning may suggest rescheduling in or out (from the original date) of a source for scheduled
receipt depending on when requirement is due. In the context of a discrete job, planning considers
the MRP Net Quantity as supply for the assembly. The component requirements are derived
based on the job Start Quantity.
ACKNOWLEDGEMENT
Saumit Mandal CPIM, is a Senior Support Analyst and a BDE for Core Manufacturing at Oracle’s
India Support Center, Bangalore.
White Paper: Blancing Demand & Supply: A Brief Guide to MRP logic
February, 2003
Author: Saumit Mandal CPIM
Contributing Authors: N/A
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com