The planning solver is the engine that performs the planning process.
Since it emphasizes quickly solving issues and quickly processing simulations, its results may not be the same as those from Oracle Advanced Supply Chain Planning.
Many supply chain planning problems are prioritized supply-demand matching problems. The Planning Solver plans order by order based strictly on their priority sequence. You can see the rationale for why the Planning Solver planned a demand in a certain way by looking at how it planned higher priority demands.
Once the Planning Solver has planned an order, it locks the resources and material used from other orders. It rarely disturbs the plan for a higher priority order in the service of a lower priority order.
The Planning Solver attempts to minimize plan nervousness; small changes in input data should not cause large changes to output.
You can run rapid plans that are:
Unconstrained: Assumes unlimited capacity
Constrained – enforce capacity constraints: Capacity constraints take precedence over demand due dates
The Planning Solver plans:
Alternates: Bills of material, components, and resources
Effectivities: Component, process
End item substitution
Order modifiers, including rounding control
Safety stock: Time-based, only safety lead time
Coproducts and by-products
Firming
Planning time fence
Calendars: Manufacturing, shipping, carrier
Supplier capacity consideration
It does not plan these situations:
Hub and spoke planning
Minimum transfer quantity (MTQ)
Aggregate resources
Sequence dependent setups
Shelf life
Before solving a plan, you set plan options.
There are some plan options that default from profile options.
You or the planning solver can release planned orders for make, buy, and transfer to the Oracle e-Business Suite source instance. The release process creates new purchase requisitions or work in process jobs. You or the planning solver can release reschedules for work in process jobs, purchase requisitions and purchase orders
If you know some basics of how the planning solver works, you can better understand its actions.
These are planning solver features that Oracle Rapid Planning shares with the Oracle Advanced Supply Chain Planning engine. For more information on the features, see Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
Collections
Forecast Consumption: Organization specific forecasts
Forecast Spreading
Forecast Consumption: Item substitution
Overwrite Options: All or None only
Demand Priority Rules
Planned Item Selection: Similar to plan type
Sourcing Rules, Bills of Distribution, Assignment Sets
Sourcing Effectivity
Sourcing Ranks
Supplier Capacity
Supplier Calendars
Supplier Order Modifiers
Supplier Specific Lead-time
Alternate Resources
Simultaneous Resources
Maximum Assigned Units
Lot Based Resources
Lead-time and Planning Time Fence
Safety Stock: Item attribute percent only. Calculate safety stock lead-time (SSLT) from SS % item attribute. Schedule each supply earlier by the SSLT value
Calendars: Shipping, Receiving, and Supplier Capacity
Scheduled Receipts: Non-standard Oracle Work in Process jobs
Exception Messages: Oracle Rapid Planning exception messages are different from Oracle Advanced Supply Chain exception messages.
Release Planned Orders
Unconstrained Planning
Item Constraints: Bill of Material Effectivity
Engineering Change Orders
Alternate Bills of Material and Routing
Substitute Components
By-products
Order Modifiers
Resource Constraints: Routing Effectivity
Alternate Routings
Routing Operation Yield
Resource Capacity
Resource Workday Calendar
Resource Efficiency and Utilization: Daily buckets
Firm Work Orders
Phantom Routings
Routing Effectivity
Co-products
Flow Manufacturing
End Item Substitution
Substitute Components
Alternate BOM/Routing
Alternate Resources
Alternate Sources
These are planning solver features enabled by plan options that Oracle Rapid Planning shares with the Oracle Advanced Supply Chain Planning engine. For more information on the features, see Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
Plan Item Type
Planned Items
Material Scheduling Method: Operation start date only
End Item Substitution Set
Assignment Set
Simulation Set
Demand Priority Rule
Overwrite: All or None only
Demand Time Fence Control
Planning Time Fence Control
Enable Forecast Spreading
Consume by Forecast Bucket
Explode Forecast
Backward Days
Forward Days
Plan Horizon
Daily Buckets
Organization
Sub-inventory Netting
Demand Schedule: Name, Description, and Type
These are item attributes that the planning solver uses. For more information on the features, see Oracle Inventory User’s Guide and Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
Planner
Make or Buy
Safety Stock Percent
Minimum Order Quantity
Maximum Order Quantity
Fixed Order Quantity
Fixed Lot Multiplier
Planning Method
Create Supply
Round Order Quantities
Shrinkage Rate
Planning Time Fence
Planning Time Fence Days
Demand Time Fence
Demand Time Fence Days
Release Time Fence
Release Time Fence Days
DRP Planned
Preprocessing Leadtime
Processing Leadtime
Post-processing Leadtime
Fixed Leadtime
Variable Leadtime
Use Approved Supplier
New Selling Price
Selling Price
Standard Cost
Target Safety Stock Override
There are two plan options that determine the items that are included in the plan.
Planned Item Type: For Oracle Rapid Planning plans, this option is the same as Plan Type for Oracle Advanced Supply Chain Planning plans:
MPS Planned: Include items with Planning Method of MPS Planned and MPS/MPP Planned
MPP Planned: Include items with Planning Method of MPP Planned , MPS/MPP Planned, and MRP/MPP Planned
MRP Planned: Include all planned items, that is, include all items unless Planning Method is Not Planned
Distribution Planned: Include all items that are Distribution Planned. There is no separate distribution planning logic in Oracle Rapid Planning.
Planned Items: Specifies the types of items that the planning engine should plan in a particular plan run:
All Planned Items
Demand Schedule items only: Only plan items that have demands. If the demand schedule includes substitute items, the planning solver plans them. If plan option Include Sales Orders is selected, include only sales orders against those items found in demand schedules.
Demand Schedule and WIP components
Demand Schedule Items and all sales orders: Plan all items that have demands as well as all items that have sales orders against them.
Demand Schedule Items, WIP components and all sales orders
The largest possible item list is a plan where you select:
Planned Item Type: MRP Planned
Planned Items: All Planned Items
Oracle Rapid Planning does not use Oracle Advanced Supply Chain Planning plan option Critical Component. Use a simulation set and update item attribute Planning Method.
Oracle Rapid Planning plans phantom assemblies in the same way that it plans standard items.
You cannot release planned orders for phantom assemblies.
Oracle Rapid Planning does not use profile option MSC: New Planner Backward Compatibility
For unconstrained planning Oracle Rapid Planning uses these entities and methods.
Item-organization item attribute Planning Time Fence:
It does not set any planned order Suggested Due Dates earlier than Planning Time Fence Date.
It uses Due Date to determine if the supply is earlier than, later than, or on Planning Time Fence Date.
It firms work orders and operations with the time fence.
Demand Time Fence and Release Time Fence
Firm flags on supplies
Does not select alternates
Order modifiers
Overloads resource and supplier capacity: Backwards schedules resources and does not schedule them early or before the plan run date.
Issues exceptions for resource capacity overload , supplier capacity overload, lead-time, sales order and forecast at risk due to a material shortage and sales order and forecast at risk due to a resource shortage.
Date calculations the same as in Oracle Advanced Supply Chain Planning. See Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
Compression:
Make orders: For schedule and reschedule of WIP jobs and planned orders for make items, the first several operations of the make order can be compressed, and the operation start dates and end dates equal the planning run date. Compression begins at the first operation; each successive operation is compressed to no duration until there is sufficient lead time for the remaining operations to complete using the resource duration.
Buy orders and transfer orders: For schedule and reschedule purchase orders, purchase requisitions and planned orders for purchased items, the compression occurs in the order pre-processing lead-time, then processing lead-time, and then post-processing lead-time.
Lead times for make supplies by using the routing resource requirements and the maximum available hours per day for a resource. Each resource lead time is calculated as:
Lead time = [ (Resource Usage) / (maxAssignedUnits * maxDailyResourceHrs) ]
where:
maxDailyResourceHrs = Maximum hrs per resource in a day from estimated order start to order due date
Estimated Order Start = Order Due Date – [Fixed LT + (Variable LT*Qty)]
Order Due Date is the same as demand due date
Order due date and order start date are valid working days from mfg org calendar.
Resource usage = Order Qty * Usage per item from the routing (except for a lot based resource, do not multiply by order quantity )
maxAssignedUnits is the maximum assigned units from the routing
These are lead time notes:
If there are simultaneous resources, it bases the lead time is based on the longest lead time resource.
If fixed and variable lead times are blank, the estimated order start is the plan start date
This is how Oracle Rapid Planning works with flow manufacturing items.
Identifies flow manufacturing items by their flow routing.
Collects flow schedules.
Treats flow schedules as firm:
Explodes the component demand
Explodes the Resource requirements
Ignores the Flow Line requirement
Creates planned orders for flow items:
They have order type Flow Schedule
They are constrained with respect to the resources. It ignores the flow line capacity and line rate
They are constrained with respect to the components
To model a flow line rate:
Leave current resources unconstrained
Add a dummy line rate resource with the line rate and then
Use a simulation set to constrain the dummy line rate resource
Oracle Rapid Planning buckets these entities by day.
Resource and supplier capacity. It:
Is a strategic planning tool that wants to minimize planning solver processing time
Does not do detailed shop floor scheduling and does not schedule resources down to the minute.
Demands and supplies. It does not assign a timestamp
Available resource capacity:
If a make order is scheduled that uses 8 hours of capacity on Day 1 and 1 hour of capacity on Day 2, the planning solver does not assign a particular hour for the resource requirement on either Day 1 or Day 2
The planning solver assumes that resource capacity availability in a daily bucket is continuous.
Work in process job completion dates. The job completion date is typically in the last daily bucket where the final activity consumes resource capacity but can be later in some cases. These are the scheduling rules:
A single resource activity is typically scheduled within a single daily bucket. The resource activity can be scheduled in two contiguous daily buckets with some resource usage on each day. However, a single resource activity is never scheduled in non-contiguous daily buckets.
A single resource requirement for two hours or less is scheduled in a single daily bucket.
In a single operation, two or more resources are always scheduled contiguously. That is, there are never daily gaps in the scheduled resources for a single operation.
Two operations can be scheduled with gaps more than one day between the operations.
If the planning solver cannot bucket all of the resource usage into a daily buckets, it creates multiple planned orders for scheduling flexibility.
Large resource requirements:
If resource requirements are more than one day for a single resource, the planning solver expands the resource capacity bucket and spreads the resource requirement over several days.
The plan information shows the start date and the end date of the resource requirement and also shows the resource usage on each day. The start date and end date of the resource requirement may not match the resource usage precisely due to the estimation of lead time.
It schedules resources within an operation contiguously
It does not necessarily schedule operations contiguously
It can schedule resource requirements more than two hours over contiguous daily buckets
If it must bucket some resource requirements into larger than daily buckets, it can still use daily buckets for the other resource requirements on the routing.
You can firm supplies in these ways.
Planned orders; you can:
Firm the supply and enter a new date and a new quantity
For a make at order, select and firm an alternate bill of material and routing combination. If you do not re-run the plan after this change, a release of the planned order only creates the order header
For a buy from order, select and firm an alternate source.
Select and firm a substitute component.
Non-firm work in process job:
You can firm the supply and enter a new end date. Re-run the plan to have the planning solver recalculate the resource and component requirements in the next plan run.
If you firm a work in process job in the source, the planning solver does not change its resource and component requirements
Non-firm purchase order:
Firm the supply and enter a new date and a new quantity
The planning uses Suggested Due Date unless you enter New Date. The planning solver then sets the Suggested Due Date to the New Date and reschedules all related activities.
The planning solver does not change the suggested due date or quantity of a firm supply.
When the supply is firm the planning solver:
Cannot change resource schedules
Can overload resource or supplier capacity
The planning solver first processes firm work orders and firm planned make orders against the highest priority demands. It does this without regard to the demand priorities. However, it never makes a demand late by using a firm order.
After it processes firm work orders, then it schedules supplies for demands by priority using non-firm work orders and planned orders.
If a supply is firm, the planning solver treats all upstream supplies as pegged to a firm and they are not allowed to be late. This means that these orders can be compressed in the same manner as unconstrained planning. This does not apply to supplies that are firmed because of the planning time fence.
To schedule non-firm supplies, the planning solver uses the same idea as scheduling firm supplies but also considers supplies that are after the demand due date.
This is the process:
The planning solver uses non-firm supplies and does not change the suggested due date order of work in process supplies needlessly
It continues to use non-firm supplies until it has selected all of them.
For non-firm supplies that are later than the demand date, the planning solver tries to reschedule them in to meet the demand on time. It does not select alternate resources, substitute components, or alternate bill of material and routing combinations for work in process supplies.
If this is not possible for a supply, the planning solver creates planned orders to meet the demand on time.
If this is not possible for a supply, the planning solver creates planned orders as close to the demand date as possible. If a planned order date is the same as a scheduled receipt and there is available capacity for the existing supply, it uses the scheduled receipt for the lower priority demand as well, even though the supply may be late.
To specify your preferences for work order vs. planned order pegging, you can use Oracle Rapid Planning item attribute No planned orders before WIP window in simulation sets.
The default value is 10.
Work orders outside of this window do not affect planned order creation.
In this number of days from plan start date, the planning solver does not create planned orders that are due earlier than work orders are due.
It tries to reschedule in the work orders first, then uses planned orders outside this window if work order reschedules will meet the demand late.
The planning solver right-justifies non-firm orders to the right to minimize excess. It does this only if they are outside of the range you specify in item-organization attribute Acceptable Early Days.
The planning solver does not create planned orders if:
There is no available resource capacity or material capacity during the planning horizon
The plan horizon is shorter then the lead times, planned orders are not created
Oracle Advanced Supply Chain Planning creates planned orders at the end of the plan horizon due to constraints during the plan horizon. The Oracle Rapid Planning solver generates exception message Demand Quantity not Satisfied and does not create planned orders at the end of the plan
If the planning solver cannot create a complete supply for a demand, it sets its material satisfied date to the day after the end of the planning horizon
When you release planned orders to the execution system, this is the information that Oracle Rapid Planning passes.
It auto-releases planned orders within the release time fence.
Work orders:
Job details with start date and end date timestamps of 23:59:59
Resource details with resource scheduled start date and resource scheduled end date timestamps of 23:59:59
Resource usage
Resource hours
Primary or alternate bill of material and routing combination selection
Primary or substitute component selection
Primary or alternate resources selection
Purchase requisitions:
Selected supplier, supplier site, and ship method
Suggested Due Date timestamp of 23:59:59
Internal requisitions:
Selected source organization and ship method
Order Date timestamp of 23:59:59
Rescheduled work orders:
End date
If the plan determined the work order start date, all the remaining information in the order is new
Reschedule or cancellation of purchase requisitions:
Order number
Order Date timestamp of 23:59:59
Reschedule or cancellation of purchase orders:
Order number
Order Date timestamp of 23:59:59
Reschedule or cancellations of internal requisitions:
Order number
Order Date timestamp of 23:59:59
You can instruct the planning solver to automatically start the release of planned orders, reschedules, and sales orders (auto release). After the plan completes, it starts a concurrent process to automatically release planned orders.
The planning solver releases planned orders and reschedules that:
Occur in a plan that you run with a snapshot phase
Are for items that have a value in item-organization attribute Release Time Fence. You set Release Time Fence in days.
Have dates in their destination organization on the plan start date that are within their items’ release time fence.
Have Action set to Release
Can be released manually: For example, it excludes orders for phantom items
When you run a plan with snapshot and want to use auto release, set these plan options on the Main tab. Their default value is clear or null:
Enable Auto Release
If you select Enable Auto Release, enable Auto Release Reschedules
This is how the release time fence works:
You set Release Time Fence in days. The planning solver calculates the release time fence as this many days after the plan start date. For example, if Release Time Fence is 3, the release time fence date is day 4 of the plan horizon [plan start date, day 1 + 3 days].
The planning solver releases orders that have dates before the release time fence date. In this example, it releases orders in days 1, 2, and 3. But, if you run the plan exactly at 00:00:00, it also releases orders that have dates on the release time fence date,
This is how the planning solver decides whether or not to auto release:
Planned order: Suggested start date is before (or on) the release time fence date
Reschedule out: Old order start date is before (or on) the release time fence date
Reschedule in: Suggested start date is before (or on) release time fence date
Cancel: Suggested start date is before (or on) the release time fence date
During the auto release process, the planning solver:
Does not let you view the plan
Changes the release status of each eligible order to Released
Updates the quantity in process of each eligible order with the released quantity
Saves the plan to the database
Starts a concurrent process immediately after it finishes to release eligible orders to the e-Business Suite execution products. This process may start concurrent processes Create Releases, Requisition Import, and WIP Mass Load
Lets you view the plan
Other auto release considerations are:
Later simulations see the released orders as firm scheduled receipts.
After a later replan without snapshot, those released orders remain as firm plan orders and marked as released. After a later replan with snapshot, the Planning Solver ignores them as it replans the supply and demand situation using the latest collected data.
The planning solver calculates safety stock lead time if the value of profile option MSC Use Safety Lead Time is Yes.
The calculation is:
Item attribute Safety Stock Percent / 100
Rounded up to the next integer
The planning solver uses the safety stock lead time to create supplies that are a number of days earlier than the actual demand. The process is to try to schedule the supply:
Early by the safety stock lead time
If this is not possible, halfway between the safety stock lead time and the demand due date
If this is not possible, on the demand due date
The planning solver:
Only uses workdays
Never reschedules earlier that the planning time fence
Applies safety stock lead time when scheduling components that are MRP Planned and have a safety stock percent
Schedules using safety stock lead time of the end item substituted and the substitute components
Does not schedule safety stock lead time for co-products and by-products
Oracle Rapid Planning provides two methods of modeling safety stock:
Lead time
Quantity
Modeling Safety Stock Based on Lead Time
Oracle Rapid Planning models safety stock to buffer against unexpected demands using safety lead time. It uses the following item attributes to model
Safety Stock method: This must be set to MRP PLANNED PERCENT for Oracle Rapid Planning to consider safety stock requirements
Safety Stock Percent: This is a value field that must be populated
Safety Stock Lead Time (SSLT) is an internal field. It is an integer value, which is calculated as Safety Stock Percent / 100. During planning, Oracle Rapid Planning creates supplies that are SSLT days earlier than the actual demand due date. For example, if a demand is on Day 12 and SSLT = 5, then the supply is created with a suggested due date = day 7, assuming there are no non-working days.
The plan option MSC: Rapid Planning Use Safety Lead Time enables this logic. The possible valid values for the plan option are:
YES: Compute SSLT for items with Safety Stock Method = MRP Planned Percent and Safety Stock Percent not null
NO: Do not compute SSLT
Modeling Safety Stock Based on Quantity
In order to calculate safety stock by quantity, Oracle Rapid Planning performs two tasks. It:
Converts Safety Stock Percent to Safety Stock Quantity
Converts Safety Stock Quantity to Safety Stock Percent
To complete these conversions, the assumptions associated with the current safety stock logic hold.
Converting Safety Stock Percent to Safety Stock Quantity
The Oracle Rapid Planning engine uses Safety Stock Percent as an input in handling safety stock requirements. This value can be converted to quantity so that it can then be displayed in the user interface. The following steps describe the conversion logic that is used by the application:
Compute Safety Stock Lead Time (SSLT)
SSLT = SafetyStockPercent/100
Derived safety Stock Quantity (DSSQ)
DSSQ = SSLTxAverage DailyDemandd
where the Average Daily Demand is computed as an Average divided by the Planning Horizon
Note: SSLT can be a fractional value.
An example of the conversion logic follows:
Safety Stock Percent = 100
Demands over a 7 day horizon are: 20, 28, 50, 33, 38, 19, and 28
Safety Stock Lead Time (SSLT) = 100/100 = 1 day
Average Daily Demand over the planning horizon = (20+28+50+33+38+19+28)/7 = 30.85
Derived Safety Stock Quantity (DSSQ) = 1 * 30.85 = 30.85 units
Converting Safety Stock Quantity to Safety Stock Percent
Oracle Rapid Planning has the ability to read in time phased safety stock quantity as an input. However, this quantity must be converted to SSLT since the engine supports only SSLT.
The steps below show the logic that is used to convert a time phased quantity based safety stock to a single SSLT value that the engine uses in its safety stock computation:
Time Phased Safety Stock Quantity (SSQi) is an input; where i refers to the occurrence in the time period.
Compute Safety Stock Lead Time (SSLTi):
Average Daily Demand is computed as an Average over the Planning Horizon.
Compute Safety Stock Percent:
The safety stock lead time (SSLT) that the engine will be using in its computations is the weighted average shown above:
The derived safety stock quantity (DSSQ) will be computed using SSLT.
Note: SSLT can be a fractional value.
To calculate safety stock, there is a new plan option, Safety Stock Lead Time Method. This plan option has three possible settings:
Do not compute safety stock
User Safety Stock Percent
Use Safety Stock Quantity
To calculate safety stock using quantity, this plan options must be set to Use Safety Stock Quantity.
Two examples of calculating safety stock quantity are given below.
Example 1
The demands over a 7 day horizon are: 20, 28, 50, 33, 38, 19, and 28. Assume a constant safety stock quantity over the horizon of 5 units.
Average Daily Demand over the planning horizon = 30.85
Safety Stock Lead Time (SSLT) = 5/30.85 = 0.16 days
Safety Stock Percent = 16
Derived Safety Stock Quantity (DSSQ) = 0.16 * 30.85 = 4.94 units
Example 2
Average Daily Demand over the planning horizon = 27.86
Safety Stock Lead Time is computed as 4/27.86 = 0.14 days and 6/27.86 = 0.22 days for 4 and 6 units safety stock quantities respectively
Safety Stock Lead Time (SSLT) computed as weighted average = (0.14 * 3 + 0.22 * 4)/7 = 0.186
Derived Safety Stock Quantity (DSSQ) = 0.186 * 27.86 = 5.18 units
Note: When determining safety stock by SSLT, SSLT is a rounded down integer value. When determining safety stock by quantity, SSLT is used as a positive number. Fractional values of up to two decimal values are permissible. When the engine plans, it considers SSLT as a positive number.
Component Safety Stock
Safety stocks are also computed for components. The calculation of Safety Stock Lead Time for components requires component item demands which are not available as input (from snapshot) like an end item demand. Demands for components are calculated during planning and therefore safety stocks for end items are only considered during the first planning run.
At the end of the first planning run components items demands are available. They are updated for subsequent planning runs. SSLT for component demands is available after the first planning run and is considered in subsequent planning runs. There will always be a lag on component safety stock consideration because in each planning run, the component items demands generated from previous planning runs, are considered. In addition, component items demands are generated using the satisfied quantity of the parent end item
Safety Stock Input
The Safety Stock input is fed into and defined by Oracle Rapid Planning in one of two ways:
Item Attribute Safety Stock Percent
Time Phase Safety Stock Quantity
For the input to be fed into Oracle Rapid Planning successfully, Safety Stock Method must be set to MRP PLANNED PERCENT.
1. Safety Stock Input Defined by Item Attribute Safety Stock Percent
When Oracle Rapid Planning defines safety stock by Item Attribute Safety Stock Percent, the engine performs the following functions:
Takes Safety Stock Percent as input
Computes Safety Stock Lead Time (SSLT)
Schedules orders by buffering for Safety Stock using SSLT
Note: In this case, the SSLT used is a positive number. A fractional value is permissible.
Computes Derived Safety Stock (DSSQ)
Note: In this case, the SSLT used is a positive number. A fractional value is permissible.
The user interface displays the Derived Safety Stock in Material Plan, as computed by the engine in the steps in the example above.
Note: If Target Safety Stock Quantity is specified, it will not be displayed in this scenario.
2. Safety stock Input Defined as a Time Phased Safety Stock Quantity
When Oracle Rapid Planning defines safety stock as a time phased safety stock quantity, the engine performs the following functions:
Takes Safety Stock Quantity as input. This is the Target Safety StocK.
Computes Safety Stock Lead Time as a weighted average (SSLT)
Computes Safety Stock Percent. Populates this as the Item attribute value
Schedules orders by buffering for Safety Stock using SSLT
Note: In this case, the SSLT used is a positive number. A fractional value is permissible.
Computed Derived Safety Stock (DSSQ).
Note: In this case, the SSLT used is a positive number. A fractional value is permissible.
The user interface displays both Target Safety Stock and Derived Safety Stock quantities in Material Plan, as computed by the engine in the steps above.
Some points to note are:
There are no drilldowns from Target Safety Stock and Derived Safety Stock rows.
Target Safety Stock Quantity is displayed only if plan option Safety Stock Lead Time Method is set to “Use Safety Stock Quantity”.
Target Safety Stock Quantity displayed at the Week or Period level is the value of the last day within that Week or Period.
Target Safety Stock Quantity and Derived Safety Stock Quantity are not editable in the material pan view.
If the item attribute Target Safety Stock Override is populated in the Item Details screens, it updates the Target Safety Stock row in the Material Plan view.
In order to understand your inventory position more comprehensively, Oracle Rapid Planning supports the following methods of planning safety stock in addition to using Safety Lead Time:
User-defined Safety Stock Quantities and safety stock from Oracle Inventory. Item safety stock method is Non-MRP Planned.
Safety Stock Quantities calculated by Oracle Rapid Planning as a percent of future demand. Item safety stock method is MRP Planned Percent.
Safety Stock Quantities fed into Oracle Rapid Planning from Inventory Optimization. Item safety stock method is MRP Planned Percent.
Planning safety stock, based on quantity, starts by planning all safety stock demands across the supply chain prior to planning all other real demands. This allows the Rapid Planning engine to consume any transient safety stock by demands that occur after the fall in the safety stock level. This logic ensures that that there will be no excess inventory due to transient safety stocks. The diagram below and the example that follows illustrate this behavior:
Example:
Lead time = 5 days
D1 | D2 | D3 | D4 | D5 | |
Sales Orders | 10 | ||||
Safety Stock | 20 | 20 | 20 | 20 | 20 |
Onhand | 20 | ||||
Planned Order | 10 | ||||
Available (excluding Safety Stock Quantity) | 0 | 0 | 0 | -10 | 0 |
Available (including Safety Stock Quantity) | 20 | 20 | 20 | 20 | 20 |
Using the numbers in the table above, planning follows the sequence:
Plan Safety Stock on D1. Available Qty on D1 = 0
Plan Demand on D4 based on Available (excluding SS). Since LT = 4 days, the earliest satisfaction date = D5
Plan Demand on D4 based on Available (including Safety Stock). Satisfaction Date = D4
Oracle Rapid Planning uses the plan option Safety Stock Planning Method and the item attributes Safety Stock Method using the following decision chart:
User-defined Safety Stock Quantities at the Item Level
Safety Stock Method = Non-MRP Planned
User entered Safety Stock Quantities (Oracle Inventory > Planning > Safety Stocks)
The safety stock quantities are then collected and used in Oracle Rapid Planning.
Safety Stock Quantity Generated in Oracle Inventory at the Item Level
Safety Stock Method = MRP Planned %
Safety Stock Bucket Days = user defined value
Safety Stock Percent = user defined value
These item attributes are collected and the safety stock quantities are calculated in Oracle Rapid Planning using the following logic:
a. Calculate the daily gross requirements for every item in the supply chain. Daily gross requirements is the independent demand + dependent demand.
b. For every day, Day-n, calculate the sum of gross requirements for the safety stock demand window. Note that all days are working days based on the organization's manufacturing calendar. The demand window is derived as follows:
Start Date of the window = Day-n + m days
where m = Safety Stock Bucket Start Offset Days. This is based on a new profile option, MSC: Safety Stock Bucket Start Offset Days. This profile option is also available as a plan option.
Both Day n and m days are working days based on the organization’s manufacturing calendar.
The start date of the safety stock bucket is offset from the current day. This allows Rapid Planning to ignore the impacts of high near term demand which may occur due to high backlog demand.
End Date of the window = Start Date of the window + n days
where n = Safety Stock Bucket Days (Item Attribute)
c. The bucket days serve as a rolling window, based on working days in the organization manufacturing calendar.
Safety stock is (Sum of gross requirements for Bucket Days working days * Percent) / (100 * Bucket Days).
Calculate safety stock as follows where:
Working week = 5 days
Bucket Days = 5
Safety Stock Percent = 100
Note: Safety stock is not calculated on non-working days.
Safety stock on D1 = (Average daily Gross Requirements in bucket days from D1) *(SS % / 100)
= [ (10 + 10 + 20 + 20 + 20) / 5 ] * 1.0
= 16
Safety stock on D21 = (Average daily Gross Requirements in bucket days from D1) * (SS % / 100)
= [ (10 + 20 + 20 + 20 + 20) / 5] * 1.0
= 18
and so on.
Because Rapid Planning is a day-level planning tool, the safety stock level is a target, which is satisfied by the end of the day.
Since component dependent demand is not readily available in the initial bootstrap run of a plan, due to the choices of the alternate BOMs or substitute components that the plan has not yet made, this example uses the following logic to calculate the dependent demand:
In the initial bootstrap run of the plan, the dependent demand for the purpose of calculating the gross requirements is based on the primary BOM. The primary components use an unconstrained MRP explosion using Fixed and Variable lead times.
For all subsequent runs, the dependent demand is based on the previous run and the choices of alternate BOMs and substitute components made in that run.
In both scenarios, the Total Demand used for Safety Stock Calculation is available along with Safety Stock Quantity in the material plan.
Safety Stock Quantity Input to Oracle Rapid Planning from Inventory Optimization
For Rapid Planning plans, if you want to account for the variability in demand and lead times in their supply chain, you can specify any Inventory Optimization Plan in the demand schedules area of Plan Options. For such items, the Safety Stock Method = MRP Planned % and will be part of the Inventory Optimization plan.
A Rapid Planning plan can be made up of a combination of items from any of the following groups:
MRP Planned%
Some of the items have their safety stocks calculated in an Inventory Plan (demand schedule)
Some of the items have their safety stocks calculated in Oracle Rapid Planning
If an item of this category (SS Method = MRP Planned %) is coming from an Inventory Optimization plan as a demand schedule , then the IO generated safety stock takes precedence and the other safety stock attributes, that is safety stock percent, are not considered. Rapid Planning does not calculate the safety stock for that tem.
Non-MRP Planned
Some of the items have user-defined safety stock quantities.
Some of the items have safety stock quantities generated in Oracle Inventory.
Plan Option for Safety Stock Planning
The current plan option in the advanced options section, Safety Stock Lead Time Method, which configures safety stock planning method, is changed to Safety Stock Planning Method. It has the following values:
Do not plan Safety Stock
Use Safety Stock Quantities
Use Safety Stock Lead Time from Safety Stock Percent
There will no longer be Safety Stock Lead Time using Safety Stock.
Safety Stock Smoothing
In some cases, you may want to reduce the fluctuations in safety stock in the plan but do not want to directly use the raw safety stock numbers that come out of either of the above mechanisms such as an IO plan, generated in Oracle Inventory or user-defined. The following profile options are available so you can control if and how the smoothing occurs. For example:
MSC: Safety stock change interval (Days): The number of working days in the interval for smoothing.
MSC: Smoothing method to calculate Safety stock within Change interval: Starting from plan horizon, in every interval, the raw safety stock quantities are smoothed. The result is always rounded up to nearest integer. Valid values are Min, Max, and Average.
MSC: Apply Safety Stock Change interval to non MRP Planned Safety Stock: Valid values are Yes and No. If it is set to No, smoothing occurs only when the item has the safety stock method set to 'MRP Planned %’, that is, when Rapid Planning calculates the safety stock quantities or when they are fed in from IO.
MSC: Maximum Percentage variation in safety stock values: This decides how the smoothing occurs from one interval to the next. For example, using the table above,
In the 2nd interval, Interval = 5 days
Safety stock after smoothing within the interval using Min option = 10
Safety stock after smoothing across intervals using Max % of 25% = 12
MSC: Minimum Percentage variation in safety stock values: This option indicates the minimum required percentage that triggers an interval to have a different safety stock qty. For example:
Safety stock (after smoothing) in Interval (1) = 20
Safety stock (after smoothing) in Interval (2) = 25
Min % variation in SS stock values profile = 50%
In this example, since the Interval (2) is below the Min % (Interval (1) + 50% = 30), the plan further smoothes the safety stock by not triggering any change between these two intervals and moves to next interval. The result is:
Safety stock (after smoothing) in Interval (1) = 20
Safety stock (after smoothing) in Interval (2) = 20
Safety Stock Pegging
Rapid Planning does not generate actual demand entries for Safety Stock requirements. Therefore, there is no pegging created for the supplies that are used to satisfy the safety stock requirements. However, the safety stock will consume the inventory buffer like any other demand and the plan will ensure that there is enough supply for it, subject to other demands being met.
Simulation of Item Attributes
You can edit the following item attributes in both simulation sets and in Plan for simulation, what-if analysis. When you change these attributes in Plan, it takes effect without running the plan with a snapshot
Safety Stock Method
Safety Stock Bucket Days
Safety Stock Percent
The standard mass edit operations are available for these attributes.
Material Plan
The following measures are currently available in Material Plan. The changes to measures are as follows:
Target Safety Stock: This will represent the time-phased Safety Stock Quantities that are considered as "input" to Rapid Planning after smoothing. You can edit the Target Safety Stock only if the item's safety stock method attribute is Non-MRP Planned.
Raw Target Safety Stock: This is the Target Safety Stock prior to smoothing.
You can edit the following in material plan
Item-Org-Day: Simple update. No allocations
Item-Org-Week: Applies to all Days in that week
Item-Org-Period: Applies to all Days in that period
You will be able to edit the Raw Target Safety Stock only if the item's safety stock method attribute is Non-MRP Planned.
The planning solver uses basic FIFO (first in first out) pegging. It does not consider Oracle Advanced Supply Chain Planning pegging profile options. See Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
For all demands and supplies, it:
Pegs demands to supplies day by day. It does not sort each day's supplies and demands.
Pegs demands using the material available date. It calculates the material available date as it schedules supplies to satisfy each demand.
When there are no more supplies or demands on one day, it uses supplies or demands from the next day
At the end of the planning horizon, it posts un-pegged supplies to excess.
The planning solver considers all alternates as supplies to meet demands.
The search path is depth first and then breadth. During the search, the planning solver may find partial quantities and then continue the search for the remaining quantity required to meet the demand. It uses partial quantities only if they satisfy the order modifiers.
This is the search order.
The primary source is searched first based on the sourcing rules:
First use on hand, then in receiving, then scheduled receipts
Check each source all the way down the supply chain for supply availability before considering the next lower ranked source
Search each alternate source at all levels before moving on to the next alternate source
The sourcing rule primary source is the rank 1 source with the highest % allocation. The planning solver searches all rank 1 sources with allocation percents before rank 2 sources.
If multiple rank 1 sources have the same allocation percents, then the engine selects one to search first.
If there is make source on the search path:
First, search the primary bill of material and routing combination using any substitute components and alternate resources
Then, search each alternative successive bill of material and routing combination using any substitute components and alternate resources. Search alternates in bill of material rank order.
The planning solver continues searching alternate sources until it considers all of them.
Search for the first substitute item using its complete search path.
Continue searching for each successive substitute item using its complete search path.
If the demand cannot be met on time, re-search and attempt to minimize the supply lateness. Use an alternate source may be used to create a late supply if the primary source supply date is after the alternate source supply date.
Use incremental planning for hot demands. Incremental planning does not re-snapshot planning data.
The incremental plan freezes all:
Supplies
Planned orders
Resource capacity consumption
Supplier capacity consumption
Pegging relationships
The planning solver only changes plan output to:
Create and reshuffle supplies to meet the hot demand and determine when you can meet it
Recalculate all exception messages
If there are multiple hot demands, the planning solver plans by:
Highest demand priority
Then by earliest due date
Then by lowest quantity
If the incremental plan output is not satisfactory, run a replan; do not run multiple incremental planning runs. If you run incremental planning, run plan launch either with or without snapshot.
When you replan, the planning solver does not write snapshot data over your manual changes in the simulation set.
Oracle Rapid Planning works with these functions in the same manner as Oracle Advanced Supply Chain Planning:
Internal Requisitions and Internal Sales Orders: In Rapid Planning Workbench, internal sales orders display as sales orders.
Supplier Capacity
Lot Expiration: Oracle Rapid Planning does not issue exception messages and it does not track onhand for expiration.
All resources default as bottleneck resources. You must clear the flags manually.
In simulation sets, you can select a bottleneck flag for resources in constrained planning.
Selected: The planning solver schedules resources to avoid overloads. It may schedule resource requirements early due to resource capacity loads or the planned order late because of resource capacity loads.
Cleared: The planning solver calculates resources requirements and notes resource duration. It can overload resources and issues exception messages. It schedules the resource requirement as needed and never early because of resource capacity loads. The planned order is never late because of resource capacity loads but can be late because of uncompressed resource duration.
There are no bottleneck resource groups.
The planning solver works with only these features of end item substitution. See Oracle Advanced Supply Chain Planning Implementation and User’s Guide.
One-directional
Two-directional
Inference
Planning attributes: If a plan specifies a substitution set, the planning solver uses it You must use a substitution set for end item substitution.
The planning solver does not use these profile options but behaves as if they are set to these values:
MSO: Choice of supply for substitution: All supplies
MSO: Disable Inference of Item Substitution Relationship: Yes.
MSC: Choice of Items for which to Create Supplies in a Substitute Relationship: Follow Item Attributes
MSO: Use Effectivity Dates to Infer End Item Substitute Priority: No
You can always use partial substitution supplies to satisfy end demands. The planning solver does not use customer-specific end item substitution rules.
If the purchase order promise date is not available, the planning solver uses purchase order need by date to consume supplier capacity.
It accumulates supplier capacity at the beginning of each day. Plans launched during the day will not accumulate supplier capacity until the next day
The planning solver behaves like this if supplier capacity is missing from the advanced supplier list:
No supplier capacity entries: Supplier capacity is infinite
Supplier capacities have gaps: During gaps, supplier capacity is zero
Future supplier capacity is missing: After the last defined supplier capacity, it is infinite
Beginning supplier capacity is missing: Before the first defined supplier capacity, it is zero
The planning solver uses the planning time fence date.
In unconstrained plans, it does not set any planned order suggested due dates earlier than the planning time fence date. It can schedule all other dates before the planning time fence date.
In constrained plans, it schedules planned orders depending on supply type:
Make supplies: It does not set any planned order suggested due dates earlier than the planning time fence date.
Buy supplies: It does not set any planned order dock dates earlier than the planning time fence date
Transfer supplies: It does not set any planned order start dates at the receiving organization earlier than the planning time fence date
Past Due Orders
If a scheduled receipt has a suggested due date in the past (earlier than the plan date), the Planning Solver
For purchase requisition and purchase order, always reschedules it out regardless of whether its item has a planning time fence.
For job, always firms it.
Natural Time Fence
A natural time fence is a planning time fence date that the Planning Solver calculates based on an item’s scheduled receipts, as opposed to calculating it from a fixed number of weeks that you enter for the item. The Planning Solver uses the later of the calculated dates as the value for Planning Time Fence Date.
To instruct the Planning Solver to use natural time fences as the planning time fence for an item, you must:
Select item attribute Planning Time Fence Control
Set plan options on the Advanced tab
If you select Create Time Fence, you instruct the Planning Solver to create a natural time fence for items at the due date of the latest firm discrete job, purchase order, flow schedule, or shipment. If you run the plan without the snapshot process, it still calculates a natural time fence. For example:
The calculation of Planning Time Fence Date based on item attribute PTF Days is day 10. The latest scheduled receipt for the item is a job with due date of day 15. The plan uses planning Time Fence Date of day 15.
The calculation of Planning Time Fence Date based on item attribute PTF Days is day 10. The latest scheduled receipt for the item is a job with due date of day 5. The plan uses planning Time Fence Date of day 10.
If you select Firm Planned Order Time Fence, you instruct the Planning Solver to create a natural time fence for items at the due date of the latest firm planned order..
If you select Firm Internal Requisition Time Fence, you instruct the Planning Solver to create a natural time fence for items at the due date of the latest firm internal requisition
If you select more than one of these plan options, you instruct the Planning Solver to create a natural time fence for items at the due date of the latest due date of all the supplies that are covered by your plan option selections.
You cannot see the natural time fence date but you see that an item has used the natural time fence if its Planning Time Fence Date is different from a date calculated using item attribute PTF Days.
Use clear to build if you need to know whether you can start orders for make items.
If you understand which make orders have delay risks due to the lack of component availability, you can:
Expedite component supplies
Readjust and resequence planned production to expedite clear to build metrics of important orders
An order is clear to build if all its components peg to on-hand. If some of its components peg to scheduled receipts, for example purchase order, planned order, transfer order, it is not clear to build.
The planning solver can determine clear to build for:
Planned orders
Discrete jobs – unreleased
Discrete jobs – released: Set profile option Released WIP Jobs: Consider in Clear to Build to Yes.
Attributes and Options
You set these clear to build item attributes in the simulation set:
Consider in Clear to Build: Determines whether the planning solver calculates clear to build for this item-organization. The default is No.
Calculate Clear to Build: Determines whether the planning solver calculates clear to build in this plan. The default is No.
Clear to Build Horizon: The horizon where the planning solver calculates clear to build KPI metrics. This attribute does not affect when it calculates clear to build for orders, but only the time period that it assembles KPIs. The default is the plan horizon.
The planning solver uses the pegging information to calculate these attributes for each make order:
Clear to Build: Yes if all its components are completely available in on hand.
Clear to Build Component Availability %: The percentage of components of the make order, that are completely available on hand.
Ready to Build %: The percentage of the order that you could start now, based on the most constrained component. For this to have a value, all components must at least partially peg to on hand.
Clear to Build Date: The date that the order should be clear to build. It is the date that the latest component material should arrive in on hand. The planning solver uses, for make planned orders, The due date; for buy orders, the dock date plus postprocessing time; and for transfer orders, the receipt date plus postprocessing time.
For example:
A make order for quantity 100 uses three components
Component A usage = 1, need for this order 100
Component B usage = 2, need for this order 200
Component C usage = 3, need for this order 300
Component A pegged to on hand = 20, quantity 80 scheduled to arrive in on hand on June 14
Component B pegged to on hand = 20, quantity 180 scheduled to arrive in on hand on June 30
Component C pegged to on hand = 40, quantity 260 scheduled to arrive in on hand on June 14
Clear to Build = No [all components are not completely available in on hand]
Clear to Build Component Availability % = 0 [no components are completely available in on hand]
Ready to Build % = 10 [you can start 10 units of the make order, this consumes 10 units of A, 20 units of B, and 30 units of C; (10 units ready to build / 100 order quantity) * 100]
Clear to Build date = June 30 [component B is the latest to arrive in on hand]
Clear to Build Across Multiple Levels
When a higher-level make order pegs to a lower-level make order that is clear to build, the planning server operates as if the lower-level assembly is already available in on hand.
In this example, the planned order for:
SA123 is clear to build: Its components CM1 and CM2 both peg to on hand
AS66311 is clear to build: Its component CM3 pegs to on hand. Its component SA123 pegs to on hand because it is a clear to build order.
Item | Description | Order Type | Requested Date | Due Date | Order Quantity | Pegged Quantity | Clear to Build | Clear to Build Component Availability |
---|---|---|---|---|---|---|---|---|
AS66311 | End Item | Sales order | Day 20 | - | 100 | - | - | - |
. AS66311 | End Item | Planned order | - | Day 20 | 100 | 100 | Yes | 100 |
. . SA123 | Sub assembly | Planned order | - | Day 18 | 100 | 100 | Yes | 100 |
. . . CM1 | Subassembly component | On hand | - | - | - | 100 | - | - |
. . . CM2 | Sub assembly component | On hand | - | - | - | 100 | - | - |
. . CM3 | End item component | On hand | - | - | - | 100 | - | - |
In this example, the planned order for:
SA123 is clear to build: Its components CM1 and CM2 both peg to on hand
AS66311 is not clear to build: Its component CM3 pegs to purchase order. Its component SA123 pegs to on hand because it is a clear to build order
Item | Description | Order Type | Requested Date | Due Date | Order Quantity | Pegged Quantity | Clear to Build | Clear to Build Component Availability |
---|---|---|---|---|---|---|---|---|
AS66311 | End Item | Sales order | Day 20 | - | 100 | - | - | - |
. AS66311 | End Item | Planned order | - | Day 20 | 100 | 100 | No | 80 |
. . SA123 | Sub assembly | Planned order | - | Day 18 | 80 | 80 | Yes | 100 |
. . . CM1 | Subassembly component | On hand | - | - | - | 80 | - | - |
. . . CM2 | Sub assembly component | On hand | - | - | - | 80 | - | - |
. . CM3 | End item component | Purchase ordder | - | - | - | 20 | - | - |
Using Clear to Build Information in the Supply/Demand View
You can use the Supply/Demand view to
View the clear to build attributes: Clear to Build, Clear to Build Date, Clear to Build Component Availability %, Ready to Build %
Search on the clear to build attributes
View the order status: For example, Unreleased or Released
You cannot update the clear to build attributes.
Using Clear to Build KPIs
These are the clear to build KPI metrics. Some are available to Oracle Advanced Planning Command Center:
Clear to Build Orders (%)
Clear to Build Component Availability %
Ready to Build %
Top Shortage Components
Top Shortage Suppliers
See Base Metrics.
Clear to Build Simulations
Use clear to build simulations to try potentially more desirable allocation of on-hand to competing make orders. You do this by:
Identifying critical make orders that need to be expedited for clear to build
Prioritizing them
Deprioritizing other make orders
Prioritizing and deprioritizing planned orders
Deprioritizing sales orders
Clear to Build Simulations: Identifying Critical Make Orders
In the Supply/Demand view, filter for your key sales orders to identify whether there is any risk associated with replenishing them. Use filters such as:
Revenue
Scheduled Ship Date/Due Date
Customer
Ship-From Organization
Item
Use action View Pegged Make Order Supplies. This shows the make orders that peg to the key sales orders and their clear to build attributes.
Select the orders of concern, and use action Clear to Build Workbench.
Clear to Build Simulations: Prioritizing Make Orders
To prioritize make orders that you want to be clear to build, select Clear to Build priority.
This instructs the planning solver to allocate on-hand supply to these orders with priority during the next plan run.
If there is not enough on-hand to satisfy all of the priority clear to build orders, the planning solver allocates it in order of order due date.
Clear to Build Simulations: Deprioritizing Make Orders
To deprioritize make orders, select your key make orders, and click View Order contentions.
View the display of contenders—other make orders that are contending for the on hand of the components of your key make orders. The process displays the contenders in the order of the most improvement offered to the key make orders.
Use component allocation to decide which orders to deprioritize.
Select Deprioritize from Clear to Build.
Clear to Build Simulations: Prioritizing and Deprioritizing Planned Orders
If you prioritize a firm planned order, the planning solver uses its date, even if there will not be on hand to satisfy its components. It may issue lead time compression and overload exception messages as a result.
If you deprioritize a firm planned order, it retains its firmness and date, and the planning solver may issue exception messages as a result.
If you prioritize a planned order, it becomes a firm planned order.
If you deprioritize a planned order, the planning solver loses that information when it recreated planned orders in the next run.
Clear to Build Simulations: Priority Flag Retention
During each run of a plan, the planning solver keeps the clear to build priority and de-priority flags for discrete jobs and firm planned orders.
Oracle Rapid Planning plans these configurations:
Assemble to order
Pick to order
It can source the model components:
All from the same organization
From multiple organizations within a single instance
Scenarios
Oracle Rapid Planning works with:
Exploded configure to order forecasts as demand
Model forecasts that it explodes as demand
Global forecasting
You can use forecasts from:
Oracle Demantra
Oracle Demand Planning
Oracle E-Business Suite
Oracle Rapid Planning always includes sales orders and always uses them to consume forecasts.
Scenarios: Pre-Exploded Model Forecasts as Demand
Oracle Rapid Planning creates supply for pre-exploded, organization-specific forecasts for assemble to order models that include option class and option forecasts:
Sales orders consume the forecasts
Models can be either single or multi-level
It sources their subassemblies and components using sourcing rules
Oracle Rapid Planning creates supply for pre-exploded, organization-specific forecasts for pick to order model forecasts that include options, items, and ATO model forecasts.
Sales orders consume the forecasts
It does not source their subassemblies and components because pick to order model forecasts do not pass to Oracle Rapid Planning.
Oracle Rapid Planning creates supply for pre-exploded, single-instance, global forecasts for assemble to order models that include option classes and options across multiple organizations.
Sales orders consume the forecasts
It sources them using sourcing rules and supply availability, either percentage-based or region-based
It sources their subassemblies and components using sourcing rules at the local organization and planning percentages of each component. For forecasts form Oracle Demantra, it passes the final planning percentage.
Oracle Rapid Planning creates supply for pre-exploded, single-instance, global forecasts for pick to order models that include options, items, and ATO model forecasts.
Sales orders consume the forecasts
It does not source their subassemblies and components because pick to order model forecasts do not pass to Oracle Rapid Planning.
Scenarios: Model Forecasts as Demand for Explosion
Oracle Rapid Planning explodes and creates supply for organization-specific, assemble to order model forecasts to the options, option classes and mandatory components.
Sales orders consume the forecasts
It uses the planning bill of material percentages to explode the model forecasts to each level.
It sources their subassemblies and components using sourcing rules
Oracle Rapid Planning explodes and creates supply for organization-specific pick to order model forecasts that include options, items, and assemble to order model forecasts.
Sales orders consume the forecasts
Pick to order model forecasts do not pass to Oracle Rapid Planning
You can pass organization-specific pick to order forecasts that are exploded one level down
Oracle Rapid Planning explodes and creates supply for single-instance, global forecasts for assemble to order models that include option classes and options across multiple organizations.
Sales orders consume the forecasts
It sources them using sourcing rules and supply availability, either percentage-based or region-based
It sources their subassemblies and components using sourcing rules at the local organization and planning percentages of each component.
Oracle Rapid Planning explodes and creates supply for single-instance, global forecasts for pick to order models that include options, items, and ATO model forecasts across multiple organizations.
Sales orders consume the forecasts
It sources them using sourcing rules and supply availability, either percentage-based or region-based
It sources their subassemblies and components using sourcing rules at the local organization and planning percentages of each component
Scenarios: Global Forecasting
Oracle Rapid Planning creates supply for single-instance, global forecasts for standard items:
Sales orders consume the forecasts
It sources them using sourcing rules and supply availability, either percentage-based or region-based
The planning solver distributes forecasts with no constraints. It uses planning percentages and rank 1 sourcing rules.
For assemble to order model forecasts the planning engine in all cases distributes the global forecast based on sourcing rules and planning percentages to meet the model forecast on time.
For global forecast offsetting during forecast explosion, the planning solver only uses only the processing lead times defined in the item validation organization. Oracle Rapid Planning only accounts for fixed and variable lead times when it processes sales orders.
Item Attribute Forecast Consumption for Pre-exploded Forecasts
For the model, set to Consume or Consume & Derive. Oracle recommends that you set to Consume and Derive.
For child items of the model other than mandatory components, Oracle Rapid Planning:
Recommends that you set to Consume and Derive for Oracle Demantra and Oracle Demand Planning pre-exploded forecasts
Includes forecasts for ATO Models, PTO Models, Option Classes, Options and Mandatory Components (optional).
Performs forecast consumption
Does not peg forecast demand to the model planned order
If you set child items of the model to Consume:
Oracle Demantra and Oracle Demand Planning do not calculate exploded demand
Oracle Rapid Planning does not create exploded demand from parents
For child items of the model other than mandatory components, Oracle Rapid Planning:
Requires that you set to Consume and Derive for Oracle Demantra and Oracle Demand Planning pre-exploded forecasts
Includes forecasts for ATO Models, PTO Models, Option Classes, Options and Mandatory Components.
Performs forecast consumption
Does not peg forecast demand to the model planned order
For mandatory component children of the model, Oracle Rapid Planning:
Recommends that you set to None
Calculates exploded demand
Pegs planned order demand to the model planned order
Item Attribute Forecast Consumption for Forecast Explosion
For the model, set to Consume or Consume & Derive. Oracle recommends that you set to Consume and Derive.
For child items of the model other than mandatory components, Oracle Rapid Planning:
Recommends that you set to Consume and Derive for Oracle Demantra and Oracle Demand Planning forecasts
Explodes forecasts to assemble to order models, option classes, options and mandatory components
Performs forecast consumption
Does not peg forecast demand to the model planned order
If you set child items of the model to Consume, Oracle Rapid Planning does not create exploded demand from parents.
For mandatory component children of the model, Oracle Rapid Planning:
Recommends that you set to None
Calculates exploded demand
Pegs planned order demand to the model planned order
Select plan option Explode Forecast.
If you are using Oracle Demantra, set profile option MSD_DEM: Calculate Planning Percentages and do not change it after the initial download.
If you are using Oracle Demand Planning, set profile option MSD: Calculate Planning Percentage
Bills of Material
For models, you can:
Add models, option classes, and items to model and option class bills of material that you have already defined ion the source instance
Edit Planning Percent for model and option class bills of material
Edit flag Optional for model and option class bills of material
Use the Plan Input views to make these changes.
Demand Schedules
You can select these forecasts as demand schedules:
Organization-specific configure to order
Global configure to order: If you have multi-level, multi-organization assemble to order models, Oracle recommends that you use these for proper forecast consumption
For organization-specific configure to order forecasts, use either:
Pick to order forecasts that contain assemble to order model, option class, and option level forecasts and mandatory components Oracle Demantra does not pass pick to order model forecasts, only its options, items, and assemble to order models
Assemble to order forecasts that contain model, option class and option level forecasts
For global configure to order forecasts, you import them at these levels:
Global (Item)
Organization
Customer
Customer site
Zone
Customer zone
Set both of these profile options in the master organization:
Define the item validation organization using the profile option OE: Item Validation Organization.
Maintain a common bill of material in the Oracle Order Management validation organization and identify that organization in profile option MSC: Organization containing generic BOM for forecast explosion.
After forecast explosion, Oracle Rapid Planning sources global forecasts to organizations in an unconstrained manner based on sourcing rules and planning percentages. It plans based on ship date at the shipping organization and does not attend to constraints in receiving calendars.
Mandatory Components
If you pre-explode assemble to order forecasts, you do not need to pass forecasts for mandatory components because Oracle Rapid Planning calculates them from their parents, after it consumes the parents.
For pre-exploded pick to order models, include pre-exploded forecasts for mandatory components.
Forecast Explosion
To instruct Oracle Rapid Planning to explode configure to order forecasts, select plan option Explode. It explodes forecasts, then it consumes the forecasts.
Forecast Consumption
Set plan option Ship to consumption level. The process consumes forecast entries that have the same Ship To value as it.
For consumption by demand class:
If a sales order has a demand class, the process consumes a forecast that has the same demand class.
If a forecast does not have a demand class, the process uses its organization demand class.
If a sales order does not have a demand class, the process uses its organization’s warehouse demand class.
If you consume by demand class and have forecasts without demand classes, set profile option MSC: Rapid Planning Consume Forecast with No Demand Class.
For global forecasts, the planning solver:
Aggregates all sales orders to the level that you want to consume.
Ignores the organizations on the sales order lines
Consumes global forecasts by sales orders in inventory organizations with reference to a ship to entity, for example, zone, customer site, and demand class
Distributes forecasts and sales orders to organizations that may have a different demand classes than the ones on the sales orders and may have a different demand classes than the ones that it used for consumption.
Sourcing Rules
Oracle Rapid Planning uses sourcing rules for a configuration first, then for the model, then for the sourcing hierarchy.
For global forecasts, use the profile option MRP: ATP Assignment Set to indicate the assignment set name for use with Oracle Global Order Promising. The planning solver also uses this profile option to determine sources when configuring a model sales order.
Configuration Forecasts
If you build standard configurations to forecasts, and make forecasts both for the model and the configuration, make them customer-specific forecasts. Reduce the model forecasts and their component forecasts by the amount of the configuration forecasts.
The planning solver first consumes forecasts with sales orders for the configured item, then with forecasts for the base model.
Purchased Models
If you purchase assemble to order models and configurations, you can use the Suppliers page > Supplier site to see the constraints for the models and configurations.
You can constrain the purchased configuration by providing the aggregate capacity for the supplier – supplier site to build the base model.
Also, view metrics:
Supplier capacity utilization %
Supplier Capacity
Supplier requirements
The planning solver uses the:
Approved supplier list capacity for the assemble to order models, not the supplier capacity for any of its configuration items.
Approved supplier list order modifiers and lead times for the configuration items
Option Dependent Resources
The planning solver treats option dependent resources in model routings as 100% loaded.
This may result in the resource appearing overloaded. Consider making these resources non-bottleneck resources.
Simulation
You can firm and update forecasts for models and configurations and their option classes, options, mandatory components.
However, if you drive a plan with pre-exploded forecasts from Oracle Demantra, there are no pick to order models and option classes for update..
You can release sales order changes to Oracle Order Management. If the sales order is not firmed, you can change Material Available Date and the end item substitute.
The planning solver schedules sales orders using the scheduled sales order ship date, it does not use the scheduled sales order arrival date. It does not suggest alternate ship methods to improve the scheduled arrival date and it does not . RP does not recalculate the transit lead time from organization to customer site. It does not schedule sales orders with schedule method of arrival type.
Oracle Rapid Planning does not update the source organization for sales orders with:
Assemble to order models
Pick to order models and their components, options, and assemble to order models. The planning solver does not change the source organization selected in Oracle Order Management as scheduled by available to promise. Sales order lines for components of pick to order models and kits do not receive any release recommendations.
Use default order sizing if you want to create manageable manufacturing order sizes that are both efficient for scheduling resource usage and are efficient to produce.
Order sizes that are too small create shop floor inefficiencies while order sizes that are too large are difficult to schedule, can cause supplies to be late for demands and usually leave significant amounts of unconsumed resource capacity.
To invoke default order sizing, you specify a planning unit of work--a few hours, a shift, a day, or a larger time bucket.
Planning Unit of Work
Planning Unit of Work is an item-organization attribute that you specify in hours
Oracle Rapid Planning uses planning unit of work to determine the order size. Order size is how many units you can produce within the planning unit of work time.
For example:
Since the planning solver considers daily capacities, you can decide that it should create planned orders with quantity equal to one production day. In other words, because Oracle Rapid Planning only considers daily capacities, then Oracle Rapid Planning should create units of work that take a full production day.
If you want long production runs, set the planning unit of work, for example, to two to three days or two to three weeks duration.
The planning solver uses planning unit of work for constrained planning; for unconstrained planning, it uses lead time. It uses planning unit of work to fix the lead time for planned orders so it can quickly arrive at a feasible daily schedule.
Planning Unit of Work Size
The planning unit of work order size is the number of units of an item that you can produce during the planning unit of work time. The planning solver calculates it for each primary and alternate routing by dividing the planning unit of work by the routing lead time. If you use rounding control, the calculation rounds the planning unit of work order size up.
If you have not defined a Planning Unit of Work, then Oracle Rapid Planning uses order size quantities that can be produced in a day, depending on resource and material availability.
Resources and Planning Unit of Work
The planning solver:
Applies planning unit of work
Splits resource requirements
Consumes resource requirements
Resources and Planning Unit of Work: Applying Planning Unit of Work
The planning solver backward schedules the resource requirements from the job end time.
The planning solver uses the operation lead time for each operation if resources are available within the time that the lead time covers. For example, if the lead time is 10 hours with 8 hour per day shifts, the lead time spans two days. If the resource requirement is 10 hours using a single assigned unit, then resource capacity usage each day can be anything from 2 to 8 hours.
If the planning solver has to move the operation to an earlier day, it schedules to reflect the resource usage on that day. For example:
There is four hours of available capacity in the second day of the operation
The planning solver schedules four hours on the second day
The planning solver schedules six hours on the previous day
Resources and Planning Unit of Work: Splitting Resource Requirements
This is how the planning solver splits resource requirements across daily buckets:
For resource requirements of two hours or less, it can split them over two contiguous daily buckets. It searches for a bucket with at least two hours available capacity and schedules the remainder of the resource requirement in a contiguous bucket.
For resource requirements more than two hours, it schedules them in a daily bucket
For example:
The resource requirement is 4 hours
The planning solver looks for a bucket that has at least 2 hours (half the requirement).
It finds 3.5 hours in a daily bucket
It looks in the daily bucket before and after to find the remaining 0.5 hour.
Resources and Planning Unit of Work: Consuming Resource Availability
This example shows how the planning solver consumes resources with daily buckets.
Resource availability:
Resource A: 8 hours per day
Resource B: 8 hours per day
Routing:
Operation 1: Uses resource A; resource requirement = 0.25 hour
Operation 2: Uses resource B; resource requirement = 0.25 hour
Lead time = 0.5 hour [0.25 + 0.25]
Planning unit of work = 16 hours
Planning unit of work order size = 32 [16 / 0.5], you can produce 32 units in 16 hours
For any planned order quantity from 1 to 32 units, total lead time = 16 hours
Operation 1 lead time = 8 hours
Operation 2 lead time = 8 hours
Demand
Quantity: 60 units
Due date: Day 8
This diagram shows that the planning solver schedules these planned orders:
Quantity = 20 units, days 1 and 2, lead time = 16 hours
Quantity = 8 units, days 5 and 6, lead time = 16 hours
Quantity = 32 units, days 7 and 8, lead time = 16 hours
For the planned order for quantity 32, the planning solver could schedule the operations on the same day:
Day 8: Operation 1, 8 hours consumed [32 * 0.25]
Day 8: Operation 2, 8 hours consumed
For the planned order for quantity 32, the planning solver could schedule the operations on different contiguous days:
Day 7: Operation 1, 8 hours consumed
Day 8: Operation 2, 8 hours consumed
For the planned order for quantity 32, the planning solver could schedule the operations on different non-contiguous days:
Day 6: Operation 1. 8 hours consumed
Day 8: Operation 2, 8 hours consumed
For the planned order for quantity 4, the planning solver could schedule the operations on the same day:
Day 8: Operation 1, 1 hour consumed [4 * 0.25]
Day 8: Operation 2, 1 hour consumed
Order Modifiers
The planning solver uses these rules to decide planned order sizes when there are conflicts between planning unit of work size and order modifiers:
If fixed days supply is higher than the planning unit of work size, use fixed days supply.
If fixed lot multiplier is higher than the planning unit of work size, use fixed lot multiplier.
If minimum order quantity is higher than the planning unit of work size, use minimum order quantity.
If maximum order quantity is lower than the planning unit of work size, use maximum order quantity.
If there is a fixed order quantity, use it.
The planning solver estimates fixed points (FDS dates) on the planning timeline. It creates and resizes supply orders on these days as it processes demands in priority order.
For unconstrained plans, it calculates fixed days supply for all items where you set a fixed days supply
For constrained plans, it calculates fixed days supply for buy items where you set a fixed days supply that have either:
Sourcing rules assigned to the item with only buy from sourcing. If the sourcing rules assigned to an item have buy from and also make at or transfer from, the planning solver does not calculate fixed days supply.
No sourcing rules assigned to the item, but make/buy code of buy.
Processing
It sets the first FDS date on the latest of the:
Plan start date
Planning time fence + 1 day. It cannot create FDS dates earlier than a planning time fence.
Latest scheduled receipt + Fixed Days Supply: For work orders, it uses Old Due Date.
To set the other FDS dates, it:
Starts with the first FDS date
Spaces FDS dates according to Fixed Days Supply
The time between two FDS days is the FDS window.
The planning solver may have to adjust the length of the first FDS window when it needs to respond to a zero or negative projected available balance by:
Rescheduling the latest scheduled receipt
Creating supply before the first FDS date
It may either:
Move the first FDS date
Create earlier FDS dates, if moving the first FDS date results in more than two FDS days of supply on the moved FDS date
It does not change the length of the other FDS windows.
The planning solver creates supply only on FDS dates.
The planning solver may have to:
Finally reschedule a scheduled receipt after it creates planned orders
Work with a firm scheduled receipt
In these cases, you may see:
A scheduled receipt and a planned order in an FDS window
The planned order due before the scheduled receipt
The planning solver does not violate capacity constraints in a Constrained-Enforce capacity constraints plan. To deal with a need to create supply where you have unavailable capacity, it uses this process:
Looks to the previous FDS dates to create a build ahead quantity
Looks to the next FDS dates that have available capacity in their FDS windows
After the planning solver creates planned orders on the FDS dates, it resizes them to accommodate fixed lot multiple, then minimum order quantity, then maximum order quantity.
When you have sourcing splits, the planning solver:
Does not split a planned order on an FDS date
Alternates sources on the FDS dates and attempts to keep the split percentages close to your percentages
Issues exception messages for sourcing split violations
When you set both safety stock lead time and fixed days supply for an item, the planning solver:
Calculates fixed days supply
Does not calculate safety stock
Views
You can set Fixed Days Supply in a simulation set and see it in the Items view.
You can view Days of Supply and Average Days of Supply in the Material Plan view.
Days of Supply is:
Calculate available supply for today: Projected available balance of the previous day + The supply available today
Begin with the available supply of today, subtract from it the daily demands on each of the following days, until you've used up all of the supply
Use that number of days as the days of supply for today
For the first day of the FDS window, the planning solver uses 0 for projected available balance.
On a non-workday, its fixed days supply is the same as the fixed days supply of the day before.
For example:
Demand quantity days 5 to 15: 150 each day
Projected available balance on day 4: 0
Supply quantity on day 5: 500
Supply quantity available on day 5: 500 [0 + 500]
Remaining supply day 5: 350 [500 - 150]
Remaining supply day 6: 200 [350 - 150]
Remaining supply day 7: 50 [200 - 150]
Remaining supply day 8: -100 [50 - 150], used up all the supply from day 5
Days of supply: 4 [day 5, day 6, day 7, and day 8]
For example:
The FDS window is five days
The demand is quantity 100 on each of the five days
On day 1, there is a planned order for quantity 500
At the end of day 1, there is demand quantity remaining of 400 and there are four days left in the period
At the end of day 1, the projected available balance is 400
Days of Supply = 4 [400 / (400 / 4) = 400 / 100]
Average Days of Supply is
Projected Available Balance / (The sum of demand in Average Days of Supply Calculation Window (Days) / The number of days in Average Days of Supply Calculation Window (Days))
Average Days of Supply Calculation Window (Days) is an item attribute and you can include it in a simulation set.
For example:
Average Days of Supply Calculation Window (Days) is 5
The Average Days of Supply on day 4 is (Projected available balance on day 4 / Average daily demand from day 4 to day 8)
The Average Days of Supply on day 20 is (Projected available balance on day 20 / Average daily demand from day 20 to day 24)
The planning solver issues exception message Days of Supply Exceeds Fixed Days Supply.
The planning solver splits sourcing of:
All sourcing types
Rank 1 sources
Within a time window
Setting Up
Create or verify sourcing percentages and ranks in the Advanced Supply Chain Planning sourcing rules and assign them to entities assignment sets.
Divide the planning horizon into windows. Within each window, the planning solver splits the supply according to the sourcing percentages. If the cumulative quantities in a window do not match the sourcing percentages, it may issue an exception message. Set profile option MSO: Sourcing Allocation Window. Use Plan Options view, Advanced tab.
Set a tolerance percentage between the sourcing percentages and the actual percentages in a window. If the difference between them is more than the tolerance, the planning solver issues a Sourcing split percentage violated exception message. Set profile option MSC: Sourcing Variance Tolerance. Use Plan Options view, Advanced tab.
Set the start date where the collections starts to accumulate sourcing history. The planning engine uses this information to make sourcing decisions. Use profile option MSC: Start Date Offset for Sourcing History (in months) in Advanced Supply Chain Planning profile options.
Instruct the planning solver to process the sourcing splits. Use Plan Options view, Main tab, Enforce Sourcing Splits field.
Processing
In constrained plans, the planning solver favors capacity or due date constraints over the soft constraint of sourcing splits.
The planning solver uses only sources with rank 1.
When you copy these sorts of plans from Advanced Supply Chain Planning, select plan option Enforce Sourcing Constraints.
Analyzing
You can see Source, Rank, and Sourcing % in the Supply Chain Bill view. Click Exceptions to see the Sourcing split percentage violated exception message.
This section outlines the process and logic though which Oracle Rapid Planning respects Pull-ins, Upsides, and Order Priorities. It specifies the mechanism by which users can simulate Pull-ins and Upsides and analyze their impact on Planning, while respecting the Order Priorities that are set either by the user or computed by an offline demand prioritization scheme.
This feature ensures that Rapid Planning meets multiple needs of an enterprise, while not compromising its fast simulations, performance and efficiency
This section is divided into the following topics:
Planning Logic Recap for Oracle Rapid Planning
Planning Logic for Pull-ins and Upsides
New Item Attributes
New Exception Messages
Identifying Pull-ins and Upsides
Examples of Pull-ins and Upsides
Planning Logic Recap for Oracle Rapid Planning
Oracle Rapid Planning solution adheres to the following logic:
Your list of orders is prioritized from the highest to the lowest.
The orders are planned, one at a time, starting with the highest priority order.
The sequence for each order is to:
Ensure supply is available upstream to meet the Order Due Date.
If this is not possible, try to find supply by building ahead ensuring lead times are respected.
If this is also not possible, then try to find supply while minimizing Order lateness.
After planning an order, that plan is locked before selecting the next order in priority list.
When planning all the Orders in the priority list, use FIFO logic to peg demands to supplies by sorting demands in increasing order of demand satisfaction date.
The objective of the Pull-in logic may be described as follows: If a demand is Pulled-in and it succeeds per its priority then no issues but If the Pull-ins fail, that is, the Planning logic did not find any supply on the revised Order Due Dates, then the logic should revert to the pre Pull-in due dates. In case of Upsides, if it fails, it will be recorded as a shorted order.
Planning Logic for Pull-ins and Upsides
The planning logic for pull-ins and upsides is as follows:
The application considers both orders that are split and those that are not split when prioritizing the list of orders. Each order must have:
Firm date
Firm Quantity
Priority (Priority may also be referred to as Primary Order Priority)
Revised Demand Date
Revised Demand Priority
The application then determines the highest priority of a pull-in and marks all pull-in orders.
All orders with a priority greater than the priority determined in Step 2 are then planned using Firm Date and Firm Quantity. The on-hand profile resulting from this run dictates how much pull-ins and upsides can be planned:
An excess-on-hand at the end indicates the amount of upside that can be planned.
A temporary excess at a specific period indicates the amount of pull-in that can be planned during that period.
The orders that can be planned are planned, starting with the highest priority as determined in Step 2 to the lowest priority or until the supply is exhausted.
If an order to be planned is pulled-in, then:
Unplan the primary order, keeping track of the Date of Fulfillment for that order
Note: The entire order is pulled-in. Partial pull-ins are not supported.
Plan the pull-in order on the Revised Demand Date with the Firm Quantity.
If Step b fails, then try to build ahead by searching for Firm Quantity between Revised Demand Date and Plan Current but ensuring lead times are respected.
If Step c also fails, then try to find supply to minimize lateness. You can do this by searching for supply between Revised Demand Date and Date of Fulfillment for Firm Quantity.
Note: On-hand profile from Step 3 is used when searching for supply.
Once planning is complete, using FIFO logic, demands are pegged to supplies by sorting the demands in increasing order of demand satisfaction date. However, in case of partial pull-ins, the partially pulled-in quantity and the date on which it was satisfied are also used in the sorting logic.
Note: Make sure a temporary negative On-hand is not created.
Note the following points:
Release Orders: Users should have the ability to release the Planning results to the source Order Management system.
Launch Re-plan with Re-fresh Snapshot: As discussed above, Pull-in and Upsides logic is primarily for simulation purposes. The data is saved to the memory only. If users launch re-plan with re-fresh snapshot, the changes made to the Plan will be lost.
Late Demand Analysis: Late Demand Analysis is performed as part of the planning logic to determine reasons on why an Order was not satisfied on the due date. Some reasons may include upstream constraints (resource, capacity, etc.). During planning of Pull-ins and Upsides, if any of these orders fail, that is if the order is unable to be satisfied on the desired due date, the late demand analysis logic should be invoked so that users can better understand which constraint (material, supplier or resource) is the root cause. Understanding the root cause will help users take necessary actions to alleviate the constraint.
Pegging: As described in the Planning logic, pegging is a post-process done after planning wherein demand is pegged to supplies using FIFO logic within a planning bucket. However, in case of demands being partially satisfied in each bucket, the partial quantities and their satisfaction dates are also used in the pegging logic thereby ensuring plan quality is not compromised. The supply demand view where the pegging logic is displayed will display the partial consumptions from different buckets.
Save Plan: On Planning with Pull-ins and Upsides, if the user likes the results he can save the plan using the “Save Plan” feature. Saving a Plan will save the current version of the Rapid Planning Plan to the database. This is similar to the current feature and has no impact on this enhancement.
Exception Messages for Pull-ins and Upsides
Four new exceptions messages, two for sales orders and two for forecasts, are introduce to address lateness of a pull-in order and quantity of pull-in satisfied on the revised demand date. They are:
Late Replenishment for a Pull-in Sales Order: This exception message is flagged when the planning logic detects that supplies for a sales order line are due later than the sales order line’s Revised Demand Date.
Late Replenishment for a Pull-in Forecast: This exception message is flagged when the planning logic detects that supplies for a forecast are due later than the forecast’s Revised Demand Date.
Sales Orders Pulled-in: This message is flagged for all Sales Orders that have the Revised Demand Date populated. It indicates:
Quantity that has been satisfied by the Revised Demand Date
Quantity that has been satisfied by the Demand Date
Forecasts Pulled-in: This message is flagged for all Forecasts that have the Revised Demand Date populated. It indicates:
Quantity that has been satisfied by the Revised Demand Date
Quantity that has been satisfied by the Demand Date
Item Attributes for Pull-ins and Upsides
Two item attributes in Oracle Rapid Planning to support pull-ins and upsides:
Revised Demand Date: This is a date field that indicates the due date of the Pull-in Order. A pull-in is created on a demand line if this field is populated
Revised Demand Priority: This field determines the priority of the pull-in that is populated in the Revised Demand Date field. The value in this field is typically less than the Firm Date.
The two new attributes are enabled in both Search and Advanced Search functions in all Rapid Planning Views to aid you in performing searches by Revised Demand Date and Revised Demand Priority in addition to the already supported entities. This helps in the analysis of Pull-in and Upside orders.
Both attributes have the following characteristics:
They are nullable fields with no default values.
They are editable.
You can Mass Update these attributes using the mass update framework. This needs to be enabled in the supply demand view.
They are populated using the existing custom self-service load feature:
Role: Advanced Planning Administrator
Drill path: Navigator>Collections: Oracle System> Load Transaction Data Using Self Service Loads
When you click Load Transaction Data Using Self Service Loads, the Load Data Files window appears.
On this screen you can point to the file that contains the attributes that need to be uploaded. Each upload of this file replaces all the data that currently exists in the system.
You can use the Download Template link to obtain the format that is required to uploading attributes. The names of the attribute template files are:
demandforecast.dat for forecasts
salesorder.dat for sales
An example of an Upside and a Pull-in created using the Revised Demand Date and Revised Demand Priority fields is shown below:
In the above example, order numbers WMT-1011, XYZ-1011 and XYZ-1212 have either been pulled-in or have an upside. Order numbers WMT-1011 and XYZ-1011 are pulled-in. Notice the Revised Demand Date and Revised Demand Priority for these orders. Upside is planned for Order number XYZ-1212 by creating a new manual demand.
To make sure that Oracle Rapid Planning respects the Order Priorities that were set by the user or by an offline process, it is important to identify the Pull-ins and Upsides.
In Oracle Rapid Planning, upsides are defined as a new demand line with type Manual Demand. The priority assigned to this order, its due date, and quantity defines where it is planned in the order sequence
A Pull-in is created on a demand line if the Revised Demand Date is populated. The priority of the Pull-in is populated in the field Revised Demand Priority. The Revised Demand Date should typically by less than the Firm Date. If the Revised Demand Date is greater than the Firm date then it is a Pull-out which is possible but this is not normal.
In the example shown the previous section on the new item attributes, note the partial pull-in, fully pull-in and upside in the results. The explanations use the information from that example.
Explanation 1
Order Number WMT-1011 is partially pulled-in as shown below:
Firm Date = 18-Feb-09 and Firm Quantity = 1200; Priority = 2
Revised Demand Date = 04-Feb-09 and Revised Demand Priority = 6
Revised Demand Date is less then Firm Date hence the order is pulled-in. The amount pulled-in is 1200 and will be planned with Revised Demand Priority 6.
Explanation 2
Order Number XYZ-1011 is pulled in fully as shown below:
Firm Date = 11-Feb-09 and Firm Quantity = 700, Priority = 4
Revised Demand Date is less then Firm Date hence the order is pulled-in. The amount pulled-in is 700 (entire quantity) and planned with Revised Demand Priority 7.
Explanation 3
Order Number XYZ-1212 has an upside a shown below:
Firm Date = 25-Feb-09 and Firm Quantity = 2000 with Priority = 5
Manual Demand created with Firm Date = 25-Feb-09 and Firm Quantity = 1500 with Revised Demand Priority = 8
The manual demand is an upside planned with the lowest priority, in this case 8.
In this case, 2000 units of the Order will be planned with the priority of a regular sales order while 1500 units will be planned with priority of a Manual Demand as an Upside. The due date for both demand lines is the same.
The examples in this section are based on the following assumptions:
This logic applies to both Forecasts and Sales Order demand streams
Pull-in and Upsides information is fed to Rapid Planning in one of the two ways:
From the back end: Pull-in date and Upside quantity along with the associated priority against a demand line are populated and fed into Rapid Planning through a supported integration scheme.
Manually created in the Supply-Demand view: User manually populates the relevant fields creating the Pull-in and/or Upside.
Priority against a Pull-in is specified in two ways
Computed by an external Process: An offline demand prioritization scheme supports logic that can be based on custom rules to compute the Pull-in or Upside priority.
Manual: You can create or update Pull-ins or Upsides in the Supply-Demand view. In this case, you input the priority for Pull-ins and Upsides.
4. Upsides defined for demand lines that are received in Rapid Planning from the back end come in as a new demand line with order type set to manual demand.
5. The pegging information displayed when planning with Due Date and with Revised Demand Date can be different.
6. In this document, Firm Date refers to Demand Date (due date of the demand line) and Firm Quantity refers to the Quantity of the demand line.
7. If the Revised Demand Date is populated, the behavior is as follows:
Demand Date is copied into the Firm Date
Quantity is copied into the Firm Quantity fields
Firm date and Firm quantity fields will not be editable.
Users will be able to edit the Revised Demand Date and Revised Demand Priority fields.
This behavior applies to both Firm and un-Firm demand lines.
Solution Components
The solution consists of the following components:
Assumptions in the model (see below)
New attributes added to the Order Attribute table and the mechanism to load them
Ability to identify the pull-in and/or upside date and quantity .
Ability to Plan respecting the Pull-in and/or Upside date and quantity and its priority.
Impacts on Existing Rapid Planning Feature.
A typical workflow describing the user actions in creating a pull-in or an upside is shown below:
In this example, four customers are competing for supply from a common hard disk vendor. For simplicity, assume the production lead times are zero. Demands are due at the start of the week. Step one to five determine the weekly customer demands.
The demand priority (customer, pull-in, and upsides) is as shown below:
Customer | Priority |
CUST-A | 1 |
CUST-M | 2 |
CUST-C | 3 |
CUST-M Pull-in | 4 |
CUST-C Pull-in | 5 |
CUST-A Upside | 6 |
Last week’s customer requested demands are as shown below:
Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Total | |
CUST-A | 500 | 500 | 500 | 500 | 2000 | 4000 |
CUST-M | 200 | 200 | 200 | 1200 | 1200 | 2000 |
CUST-C | 500 | 300 | 700 | 100 | 200 | 1800 |
The incoming supply picture for the hard drive HDD1 is as shown below:
Weeks 1 | Week 2 | Week 3 | Week 4 | Week 5 | Total | |
HDD-1 | 1200 | 1700 | 1800 | 1500 | 1600 | 7800 |
Given the prioritization, the demand prioritization is as shown below:
Oracle Rapid Planning uses the above prioritization scheme in planning the customer demand.
Based on Oracle Rapid Planning’s Planning logic, the weekly customer demands are planned. A temporary excess in bold in the tablet below:
Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | |
Supply | 1200 | 1700 | 1800 | 1500 | 1600 |
Buffer Balance | 1200 | 2900 | 4700 | 6200 | 7800 |
CUST-A | 500 | ||||
700 | 2400 | 4200 | 5700 | 7300 | |
500 | |||||
700 | 1900 | 3700 | 5200 | 6800 | |
500 | |||||
700 | 1900 | 3200 | 4700 | 6300 | |
500 | |||||
700 | 1900 | 3200 | 4200 | 5800 | |
2000 | |||||
700 | 1900 | 3200 | 4200 | 3800 | |
CUST-M | 200 | ||||
500 | 1700 | 3000 | 4000 | 3600 | |
200 | |||||
500 | 1500 | 2800 | 3800 | 3400 | |
200 | |||||
500 | 1500 | 2600 | 3600 | 3200 | |
1200 | |||||
500 | 1500 | 2600 | 2400 | 2000 | |
200 | |||||
500 | 1500 | 2600 | 2400 | 1800 | |
CUST-C | 500 | ||||
0 | 1000 | 2100 | 1900 | 1300 | |
300 | |||||
0 | 700 | 1800 | 1600 | 1000 | |
700 | |||||
0 | 700 | 1100 | 900 | 300 | |
100 | |||||
0 | 700 | 1100 | 800 | 200 | |
200 | |||||
Temporary excess is in bold. | 0 | 700 | 1100 | 800 | 0 |
The current week’s demands are revised with upsides and pull-ins.
Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Total | |
CUST-A | 500 | 500 | 500 | 500 | 3500 | 5500 |
CUST-M | 200 | 1400 | 200 | 0 | 200 | 2000 |
CUST-C | 500 | 1000 | 0 | 100 | 200 | 1800 |
Based on the chart above, there is an upside of 1500 units in Week 5 for Customer-A. Customers M and C have a Pull-in of 1200 units in Week 2 and 700 units in Week 3 respectively.
Normally, Rapid Planning is able to plan for the revised demands for this week, as shown in Step 6, because it has the temporary excess, (see Steps 5 and 6). If it can't plan the upsides and pull-ins from this week's revised demand, it goes back to the plan and reverts to the solution shown in in Step 5, which does not consider the revised commits.