Planning Solver

Planning Solver Overview

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.

Planning Method

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.

Unconstrained and Constrained Plans

You can run rapid plans that are:

Key Features

The Planning Solver plans:

It does not plan these situations:

Plan Options

Release to Execution System

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

Planning Solver Logic

If you know some basics of how the planning solver works, you can better understand its actions.

Feature Comparison

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

Plan Options Comparison

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

Item Attributes

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

Items to Plan

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:

Planned Items: Specifies the types of items that the planning engine should plan in a particular plan run:

The largest possible item list is a plan where you select:

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.

Phantoms

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

Unconstrained Planning

For unconstrained planning Oracle Rapid Planning uses these entities and methods.

Item-organization item attribute Planning 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:

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:

These are lead time notes:

Flow Manufacturing

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:

Creates planned orders for flow items:

To model a flow line rate:

Daily Bucketing

Oracle Rapid Planning buckets these entities by day.

Resource and supplier capacity. It:

Demands and supplies. It does not assign a timestamp

Available resource capacity:

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:

Large resource requirements:

Order and Resource Firming

You can firm supplies in these ways.

Planned orders; you can:

Non-firm work in process job:

Non-firm purchase order:

Scheduling Firm Supplies

The planning solver does not change the suggested due date or quantity of a firm supply.

When the supply is firm the planning solver:

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.

Scheduling Non-firm Supplies

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:

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

Creating Supplies

The planning solver does not create planned orders if:

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

Order Release

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:

Purchase requisitions:

Internal requisitions:

Rescheduled work orders:

Reschedule or cancellation of purchase requisitions:

Reschedule or cancellation of purchase orders:

Reschedule or cancellations of internal requisitions:

Planned Order Auto Release

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:

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:

This is how the release time fence works:

This is how the planning solver decides whether or not to auto release:

During the auto release process, the planning solver:

Other auto release considerations are:

Safety Stock Lead Time

The planning solver calculates safety stock lead time if the value of profile option MSC Use Safety Lead Time is Yes.

The calculation is:

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:

The planning solver:

Modeling Safety Stock

Oracle Rapid Planning provides two methods of modeling safety stock:

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

Modeling Safety Stock Based on Quantity

In order to calculate safety stock by quantity, Oracle Rapid Planning performs two tasks. It:

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:

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

the picture is described in the document text

Average Daily Demand is computed as an Average over the Planning Horizon.

Compute Safety Stock Percent:

the picture is described in the document text

The safety stock lead time (SSLT) that the engine will be using in its computations is the weighted average shown above:

the picture is described in the document text

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:

To calculate safety stock using quantity, this plan options must be set to Use Safety Stock Quantity.

the picture is described in the document text

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:

  1. Item Attribute Safety Stock Percent

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

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:

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:

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.

Quantity Based Safety Stock Planning

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:

  1. User-defined Safety Stock Quantities and safety stock from Oracle Inventory. Item safety stock method is Non-MRP Planned.

  2. Safety Stock Quantities calculated by Oracle Rapid Planning as a percent of future demand. Item safety stock method is MRP Planned Percent.

  3. Safety Stock Quantities fed into Oracle Rapid Planning from Inventory Optimization. Item safety stock method is MRP Planned Percent.

Introduction to Safety Stock Based on Quantity

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:

the picture is described in the document text

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:

  1. Plan Safety Stock on D1. Available Qty on D1 = 0

  2. Plan Demand on D4 based on Available (excluding SS). Since LT = 4 days, the earliest satisfaction date = D5

  3. Plan Demand on D4 based on Available (including Safety Stock). Satisfaction Date = D4

Safety Stock Set-ups

Oracle Rapid Planning uses the plan option Safety Stock Planning Method and the item attributes Safety Stock Method using the following decision chart:

the picture is described in the document text

User-defined Safety Stock Quantities at the Item Level

The safety stock quantities are then collected and used in Oracle Rapid Planning.

Safety Stock Quantity Generated in Oracle Inventory at the Item Level

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:

c. The bucket days serve as a rolling window, based on working days in the organization manufacturing calendar.

the picture is described in the document text

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:

  1. 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.

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

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:

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:

the picture is described in the document text

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

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:

You will be able to edit the Raw Target Safety Stock only if the item's safety stock method attribute is Non-MRP Planned.

Pegging

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:

Alternate Supplies

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:

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:

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.

Incremental Planning

Use incremental planning for hot demands. Incremental planning does not re-snapshot planning data.

The incremental plan freezes all:

The planning solver only changes plan output to:

If there are multiple hot demands, the planning solver plans by:

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.

Simulation Sets

When you replan, the planning solver does not write snapshot data over your manual changes in the simulation set.

Other Planning Functions

Oracle Rapid Planning works with these functions in the same manner as Oracle Advanced Supply Chain Planning:

Bottleneck Resource Planning

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.

There are no bottleneck resource groups.

End Item Substitution

The planning solver works with only these features of end item substitution. See Oracle Advanced Supply Chain Planning Implementation and User’s Guide.

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:

You can always use partial substitution supplies to satisfy end demands. The planning solver does not use customer-specific end item substitution rules.

Supplier Capacity

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:

Planning Time Fence

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:

Past Due Orders

If a scheduled receipt has a suggested due date in the past (earlier than the plan date), the Planning Solver

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:

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:

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.

Clear to Build

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:

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:

Attributes and Options

You set these clear to build item attributes in the simulation set:

The planning solver uses the pegging information to calculate these attributes for each make order:

For example:

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:

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:

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

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:

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:

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:

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.

Configure to Order

Oracle Rapid Planning plans these configurations:

It can source the model components:

Scenarios

Oracle Rapid Planning works with:

You can use forecasts from:

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:

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.

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.

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.

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.

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.

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.

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.

Scenarios: Global Forecasting

Oracle Rapid Planning creates supply for single-instance, global forecasts for standard items:

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:

If you set child items of the model to Consume:

For child items of the model other than mandatory components, Oracle Rapid Planning:

For mandatory component children of the model, Oracle Rapid Planning:

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:

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:

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:

Use the Plan Input views to make these changes.

Demand Schedules

You can select these forecasts as demand schedules:

For organization-specific configure to order forecasts, use either:

For global configure to order forecasts, you import them at these levels:

Set both of these profile options in the master organization:

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:

For global forecasts, the planning solver:

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:

The planning solver uses the:

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

Publish Sales Order Changes

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:

Default Order Sizing

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:

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:

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:

Resources and Planning Unit of Work: Splitting Resource Requirements

This is how the planning solver splits resource requirements across daily buckets:

For example:

Resources and Planning Unit of Work: Consuming Resource Availability

This example shows how the planning solver consumes resources with daily buckets.

Resource availability:

Routing:

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

Demand

This diagram shows that the planning solver schedules these planned orders:

the picture is described in the document text

For the planned order for quantity 32, the planning solver could schedule the operations on the same day:

For the planned order for quantity 32, the planning solver could schedule the operations on different contiguous days:

For the planned order for quantity 32, the planning solver could schedule the operations on different non-contiguous days:

For the planned order for quantity 4, the planning solver could schedule the operations on the same day:

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:

Fixed Days Supply

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:

Processing

It sets the first FDS date on the latest of the:

To set the other FDS dates, it:

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:

It may either:

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:

In these cases, you may see:

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:

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:

When you set both safety stock lead time and fixed days supply for an item, the planning solver:

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:

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:

For example:

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:

The planning solver issues exception message Days of Supply Exceeds Fixed Days Supply.

Sourcing Splits

The planning solver splits sourcing of:

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.

Pull-ins, Upsides, and Order Priorities

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

Oracle Rapid Planning solution adheres to the following logic:

  1. Your list of orders is prioritized from the highest to the lowest.

  2. The orders are planned, one at a time, starting with the highest priority order.

  3. 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.

  4. After planning an order, that plan is locked before selecting the next order in priority list.

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

  1. 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

  2. The application then determines the highest priority of a pull-in and marks all pull-in orders.

  3. 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.

  4. 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.

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

  1. Release Orders: Users should have the ability to release the Planning results to the source Order Management system.

  2. 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.

  3. 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.

  4. 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.

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

Item Attributes for Pull-ins and Upsides

Two item attributes in Oracle Rapid Planning to support pull-ins and upsides:

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:

When you click Load Transaction Data Using Self Service Loads, the Load Data Files window appears.

the picture is described in the document text

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:

An example of an Upside and a Pull-in created using the Revised Demand Date and Revised Demand Priority fields is shown below:

the picture is described in the document text

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.

Identifying Pull-ins and Upsides

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.

Examples of Pull-ins and Upsides

The examples in this section are based on the following assumptions:

  1. This logic applies to both Forecasts and Sales Order demand streams

  2. 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.

  3. 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. 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. 5. The pegging information displayed when planning with Due Date and with Revised Demand Date can be different.

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

A typical workflow describing the user actions in creating a pull-in or an upside is shown below:

the picture is described in the document text

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.

  1. 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

  2. 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

  3. 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

  4. Given the prioritization, the demand prioritization is as shown below:

    the picture is described in the document text

    Oracle Rapid Planning uses the above prioritization scheme in planning the customer demand.

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

  6. 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.

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