This chapter covers the following topics:
This section describes features that help you select a plan type that best satisfies your business requirements. You can choose to run a global supply chain plan or a subset plan to suit your supply chain environment or single organization environment, respectively. You can also select constrained, unconstrained, or optimized plan class based on business objectives such as maximizing inventory turns, on time delivery, and plan profit. Lastly, you can specify aggregation levels to view plans at varying levels of detail.
Oracle ASCP can generate planned orders for an entire supply chain within a single multi-organization supply chain plan. This is illustrated below with a sample supply chain; see alsoSample Supply Chain) andSample Bill of Material:
In this sample supply chain, SF1 and SF2 are subassembly facilities, AF1 is a final assembly facility, DC1 and DC2 are distribution centers, C1, C2, C3 and C4 are customers and S1, S2, S3 and S4 are suppliers.
A single plan of the entire supply chain has the following inputs:
Demand quantity (forecast + actual sales orders) for A01 at DC1 for each of the time buckets in the planning horizon. This is captured in a Master Demand Schedule (MDS) for DC1.
Demand quantity for A01 at DC2 for each of the time buckets in the planning horizon. This is captured in an MDS for DC2.
The plan output contains planned order quantities, start dates, and completion dates for A01 and all of its components and subcomponents.
To run a global supply chain plan, the following prerequisites are required:
Each planned organization must be set up on the source instance.
Collection programs must be directed to collect data from the transactional instance of each planned organization.
Items to be planned must be enabled in each organization that can produce (or distribute) the item. During item setup, items can be enabled in all organizations or only in specific organizations.
Routings and/or Bills of Resource for each planned item must exist or be enabled in each organization that is planned centrally.
Suppliers and sourcing rules must be enabled in all relevant organizations.
The single-plan approach is advantageous for the following reasons:
Least planning effort. Fewer plans need to be generated; fewer planning servers need to be deployed and maintained.
Data consistency. Without the single-plan ability, requirements must be repeatedly transferred upstream within the supply chain to each successive supplier facility. Each transfer presents an opportunity for miscommunication or data loss.
Global optimization. Intelligent trade-offs between the performance of individual facilities (as measured by, for example, plan profit) can be made because Oracle ASCP optimizes the supply chain planned orders as a whole.
Minimum communication lag:
The effects of decisions made at the highest level of the supply chain are immediately visible at the lowest level of the supply chain. If individual facility plans are used, there is at least a one planning-run duration lag between the receipt of requirements at a facility and the passing of the dependent requirements to the facility's suppliers. Moreover, this lag is often much greater due to differences in working hours between upstream and downstream facilities (for example, if the facilities are in different time zones). Also, the planning cycles of upstream and downstream facilities may not be synchronized (for example, customer facility AF1 runs its plan on Monday, while supplier facility SF1 runs its plan on Sunday). This results in even longer communication lags.
The overall effect of plan communication lag is to make the supply chain less responsive to meeting changes in customer demand.
You can have multiple supply chain plans. Before you launch a plan for the first time you must name it.
In addition to creating a plans by creation, you can create a new plan by copying information from one plan to it. Do this if you want to:
Save the results of a particular plan run before you re-run the plan
Begin using a new plan name with the results of the latest run of another plan.
Create a new plan with the same plan options as an existing plan
From the Navigator, choose Supply Chain Plan > Names.
The Supply Chain Names window appears.
This table describes the fields and options.
Object | Description |
---|---|
Name | Define a plan name. |
Description | Define a plan description. |
ATP | If this is selected, this plan will be used for availability check. If the plan is used as a 24 x 7 ATP plan, the planning process may never switch to a new version of the plan from the copied plan after the original plan has completed successfully ; consider setting profile options MSC: Action Allowed on ATP 24 x 7 Plan While Running and MSC: ATP Synchronization Downtime (minutes). |
Production | If this is selected, this is a product plan. Planned orders will be automatically released within their release time fence. |
Notifications | If this is selected, exception message notifications for the plan are enabled. |
Plan Type | Valid values are Manufacturing Plan, Production Plan, and Master Plan. This setting interacts with the Planning Method item attribute to determine which subset of the items that pass the condition imposed by the Planned Items parameter are planned. Please see Choosing a Plan Type for further details. |
Save your work.
Select Plan Options for the Plan Options window.
Continue setting plan options and parameters.
Use the copy plan function to make a copy of an existing plan.
If memory bases planner flat files do not exist, Copy Plan process completes with the warning - WARNING: The copy plan operation completed successfully. However, some auxiliary data files could not be copied. Therefore, you will not be able to run online planner. You can re-launch the plan from the Navigator.
From the Supply Chain Names window, select a plan, then click Copy Plan for the Copy Plan window.
In Plan Name and Plan Description, enter information for the new plan.
Select or clear ATP, Production, and Notification as you would if you are creating a new plan om the Plan Names form.
Plan Type defaults to the plan type of the source plan and you cannot change it if you want to copy all plan information.
You can copy only the plan options from one plan to another of a different plan type. To do so, select Copy Plan Options Only and select Plan Type for the new plan.
Enter an Inactive Date for the new plan.
Click OK.
Save your work.
There are some situations in which it makes sense to plan a portion of the supply chain separately, outside of the overall supply chain MPP plan.
Suppose that subassembly plant SF1 (Figure: Sample Supply Chain), which makes M12 (Figure: Sample Bill of Material), contains very expensive capital equipment. SF1 is the overall supply chain constraint, so every minute that its resources are utilized brings extra profits to the enterprise. Resource utilization is the most important objective for SF1. For the supply chain as a whole, however, due to rapid product life cycles and a fickle market, inventory turns might be the most important objective. In this situation you could run a two-stage planning process.
An MRP for organization SF1 with resource utilization as the objective to generate planned orders for M11, M22, B31, and B21 (the portion required at SF1).
A MPP for organizations DC1, DC2, AF1, SF1, and SF2 with the above MRP as a supply schedule with inventory turns as the objective to generate planned orders for A01, M12, B13, B23, and B21 (the portion required at SF2).
Suppose that item B21, a subcomponent of item M11 (Figure: Sample Bill of Material), has volatile pricing. In lieu of implementing the default planned orders in facility SF1 that a global MPP would generate for M11 and its subcomponents (B21), one could plan the supply chain as follows:
MPP plan for organizations DC1, DC2, AF1, and SF2 to generate planned orders for A01, M12, B13, M22, and M11.
Load the MPP as a demand schedule into a Master Production Schedule (MPS) for organization SF1. Dependent demand for M11 is derived from the planned orders for A01.
Run the MPS.
Manually adjust the planned orders for M11 in the MPS (for example, to pull ahead the orders for M11 in order to take advantage of a time-sensitive special promotion on B21).
Run an MRP for organization SF1 with the adjusted MPS as input to create planned orders for M11 components and subcomponents (B21 in this case).
The one-step supply chain planning capability of Oracle ASCP presumes either the installation of ASCP as part of an enterprise-wide implementation of Oracle Applications, or the existence of collection programs to pull cross-supply chain transaction data from various Oracle Applications instances or from legacy systems. Cross-supply chain data must be accessible to build the net change snapshot used by Oracle ASCP to generate planned orders.
This may not be the case. For example, one or more facilities in the supply chain perform planning and/or transaction processing on legacy systems not yet integrated to Oracle ASCP via some sort of collection program. In this situation, the renegade facilities must be scheduled outside the global MPP plan according to the same steps as used in Scenario 2 above.
The two principal pitfalls of subset planning (as opposed to global, single-plan supply chain planning) are:
Local optimization as opposed to global optimization
Plan infeasibility due to supply chain interdependencies
The first pitfall is the fact that plans that optimize individual facilities may not be compatible with the optimum global supply chain plan. Take the case of the two distribution centers DC1 and DC2 in Figure 5-1: Sample Supply Chain The way to maximize on-time delivery for DC1 is to allocate all production from AF1 to DC1. The same logic holds for DC2. The global optimum solution, which would be missed via subset planning, comes from some allocation of AF1 output to both DC1 and DC2.
A simple example of supply chain interdependency is Supplier S3 in Figure 5-1: Sample Supply Chain. This supplier supplies item B21 to both subassembly facilities SF1 and SF2. Individual plans run for SF1 and SF2 could not recognize the shared capacity at supplier S3 and could not evaluate, if the combined SF1 and SF2 demands for B21 are too high, how best to allocate the B21 to SF1 and SF2. In such a situation the SF1 and SF2 individual plans would be infeasible, but would not even generate any exception notices to alert the planners.
In general, resource and material capacity are most efficiently utilized in a global supply chain planning environment where planning distributes production requirements across multiple organizations. However, the choice of global supply chain versus subset planning should depend on a number of factors including:
Physical proximity of the organizations being planned: If planned organizations are geographically dispersed, it is generally more difficult to fulfill demand in one region from a plant or distribution center far away because of transportation costs and longer lead-times. Note, however, that the costs associated with fulfilling demand from remote plants can be modeled in planning. Planning can then optimize production allocation across plants to meet the objectives that have been set. For example, if balancing resource loads is the primary objective of a multi-organization plan, planning will distribute production across plants to meet that objective.
Commonality of the items produced: If you have multiple organizations that produce similar products, global supply chain planning is beneficial because planning can consider factors like material and resource availability, material costs, and resource costs to create an optimal supply chain plan.
Commonality of the supply base: Similar to producing common items, organizations sharing suppliers are good candidates for global supply chain planning because supply can be optimally distributed across plants depending on each plan's production requirements. Global supply chain planning will ensure that supplier capacity is most effectively used to meet end customer demand and to minimize inventory.
Linkage among plants: If production at one plant must be coordinated with production at other plants, global supply chain planning should be used. For example, if Plant A provides subassemblies to Plant B (Plant A is a feeder plant), both plants should be planned together.
Corporate structure:The internal organizational structure of a corporation is also a major determinate of the planning method used. If there are clear organizational boundaries between divisions, global supply chain planning is difficult to implement.
The table below summarizes the factors to consider when deciding whether to run a global supply chain or subset plan.
Factor | Global Supply Chain Planning | Subset Planning |
---|---|---|
Physical proximity | Close Physical Proximity | Distant Physical Proximity |
Commonality of items produced | High Commonality | Low Commonality |
Commonality of supply base | High Commonality | Low Commonality |
Linkage among plants | Tight Linkage Among Plants | Loose Linkage Among Plants |
Corporate structure | Centralized Corporate Structure | Decentralized Corporate Structure |
Oracle Advanced Supply Chain Planning provides you with the option of using demands from all planned orders during hub and spoke planning. When you use your plans as demand schedules to other plans, the planning engine considers all planned orders in the source plan as demands and explodes down the bills of material creating demands for the lower level components.
Hub and spoke planning uses a multi-plan approach where you can plan across the supply chain at the top level and then release planned orders to a lower level manufacturing plan for all MRP planned items. The top level plan includes only end items or end items with critical sub-assemblies, and typically only the final assembly plants. The lower level plan (MRP) is at the component level and includes the final assembly plants and the component manufacturing plants. Hub and spoke planning is a commonly used term for this type of subset planning.
Hub and spoke planning allows you to plan and release the top level plans for a small subset of items. It also provides easier recognition of critical components based on bottleneck resources.
In a multi-planning setup with a two plan process, the top level plans are always either MPS or MPP, and the lower level plan is the MRP.
MRP is the best choice for the lower level plan, as the MRP plans all items for any planning method except Not Planned. This reduces the risk of missing an item due to an incorrect planning method selection.
Note: Avoid setting item attributes to one of the joint planning methods (MRP/MPP Planned or MPS/MPP Planned) as this can lead to unintended results. For example, if an item is marked MRP/MPP and the item is in the MPP, then the MRP does not replan it. If you use the joint planning method settings, you need to take extra care during testing to insure that you get the intended results.
You can use the two plan process when you need to segment the planned items into two groups to support multiple planning groups. For example, the production planners of your company want to plan the top level items and sub-assemblies. The buyers and MRP planners want to see the demands for their MRP planned items based on an approved production schedule from the production planners. In addition, there is a difference in frequency that each plan is run. The production is run once or twice a week while the MRP is run every night. In such a scenario, you can employ a two plan process.
The top level plan, an MPP for example:
Has independent demands including MDS, forecasts, and sales orders.
Plans all MPP, MPS/MPP, MRP/MPP planned items.
Plans critical components that are MRP planned items marked as critical components
Releases orders as required, either manually or auto-release, for MPP, MPS/MPP or MRP/MPP items.
Planners manually review, adjust, and release orders as needed by the shop floor.
The planned orders and reschedules are visible to the MRP after the MRP is launched. Therefore, the planners do not have to release them until needed by the shop floor.
The lower level plan, the MRP:
Has independent demands for MRP planned items, including MDS's, forecasts and sales orders.
Note: Avoid adding independent demands for MPP or MPS planned items to the MRP. MRP does not re-plan these demands.
Has the MPP or MPS as a demand schedule and the Interplant check box is not selected.
This brings into the MRP, the independent demands and supplies for all MPP or MPS planned items with components that are MRP planned items.
The MRP explodes downwards from the MPP or MPS supplies including planned orders, creating demands for MRP planned items.
Plans all MRP items and any other planned items that are not planned by the MPP or MPS plans.
Items that are sandwiched between two MPP or two MPS items are designated as MRP planned by MRP and are re-planned by MRP.
You may encounter a number of inconsistencies with sandwich items. It is recommended that you avoid sandwiched items as this condition can lead to unintended results. For example, if a sandwiched item has a primary and alternate bills of material, the MPP might select the alternate bills of material and the MRP might select the primary bill of material. The two plans may then plan different components of the sandwiched item. You can face a similar situation with respect to primary and substitute components of the sandwich item.
If you add demands for the sandwich item to the MRP, some planned orders in the MRP are pushed out of the planning horizon because of insufficient supply for the MPS part in the MRP. Therefore, if an item is sandwiched, you need to include all demands in the MPS.
For MRP constraint options, if you select:
Enforce Capacity Constraints (ECC), the planned orders in the MRP can be late for the demands from the MPP or MPS.
Enforce Demand Due Dates (EDD), the planned orders in the MRP are not late for demands from the MPP or MPS.
If the MPP arrives at planned supplies and reschedules based on objectives, constraints, pegging, and demand priorities visible in the MPP, the MRP does not change these planned supplies and reschedules. The MRP has different objectives, constraints, pegging and priorities and does not have adequate data to accurately replan MPP planned supplies.
The MRP considers resource capacity consumed by planned orders in the MPP or MPS. If resources are shared by items in both the MPP and MRP or in the MPS and the MRP, then the resource capacity consumed by the MPP or MPS items is considered by the MRP and only the remaining resource capacity is available to the MRP planned items. The MPP or MPS resource usages are not rescheduled by the MRP.
Note: Oracle Advanced Supply Chain Planning uses the date of the resource requirements. Therefore, orders that come in the middle of a weekly or period bucket in the demand or supply schedule are available in the destination plan on the actual schedule date and not at the beginning of the bucket.
When you run an MPS plan with the critical components option selected, the planning engine plans for:
MPS and MPS/MPP planned items
MRP and MPP planned Items that are critical components of MPS and MPS/MPP Planned items.
The plan is constrained by resource requirements for critical components if resource requirements are selected as a constraint.
The plan is also constrained by the supplier capacities for critical components if supplier capacity is selected as a constraint.
The plan may also be constrained by the purchasing lead-times of the critical components if you select the Enforce Purchasing Lead-times option.
If the plan options items selection is set to Demand Schedule items, then the MRP planned items that are not a critical component of an item in the Demand Schedule are not included. For example, item C is MRP planned and is only a critical component of Item X. If Item X is not a planned item for the MPS, then neither is Item C.
All components in the paths of critical components or between the critical components and end items.
This means that other MPS or MPP items are pulled into the MPS and planned because they have common critical components with the MPS planned items selected.
For example, item C is MRP planned and is a critical component of item X and item Y. Item X is on the demand schedule of the MPS. The planning engine plans item Y in the MPS because it is on the path of the critical component Item C.
In this case, item Y is treated as a critical component and not as an MPS planned item. For example, work orders for Item Y cannot be released from the MPS.
In case of a MPP or MPS plan with Include critical components option selected and bottleneck resource group:
Any item with a bottleneck resource on the routing is planned as a critical component
All MRP planned items that use any resource in the bottleneck resource group are planned as critical components
If you select the plan options Include critical components and bottleneck resources, then the plan itself determines what the critical components are based on the resources in the bottleneck resource group. You do not need to individually mark items as critical components.
The planning engine calculates the requirements in the following manner:
The plan is constrained only by the capacity of bottleneck resources when planning resource requirements.
The resource durations for non-constraining resources are calculated for the proper offsetting of requirements. The resource loads for non-constraining resources are calculated and resource overloads exceptions are generated.
MPP or MPS item supplies planned in a production or master plan with respect to bottleneck resources can be released.
Select the Inventory responsibility.
Navigate to Items > Organization Items > MPS/MRP Planning tab.
Select the Critical Component check box.
Set the critical component item attribute at the organization level or globally for all organizations depending on whether the item attribute is set to the organization level or the global level.
The planning engine can also infer from the bottleneck resource group whether or not an item is a critical component. You can opt to not mark any item as a critical component as critical components are selected based on the resources in your bottleneck resource group.
Navigate to Plan Options > Main tab.
Select the Include Critical Components check box.
When a MPP or MPS plan with critical components is used as a demand schedule for an MRP:
The critical components are planned in the MRP.
The supply due dates for critical components in the MRP plan can be different from the ones in the MPP plan because:
The MRP plan constraint options are different
Additional constraints at the lower levels cause the critical components to be late or early.
Changes in delivery dates of the critical components do not change dates on planned orders from the MPS for all MPS items. The planning engine always treats these orders as firm.
The planned orders for critical components in the MPS are ignored by the MRP.
The planned orders for critical components in the MRP can be released.
Set up the following profile options:
MSC: Allow Release of Planned Orders from Demand Schedule Plan
MSO: Use Collections Start Time
For more details, see Appendix A: Profile Options.
Define critical components.
For more details, see: To define critical components.
Define a MPP or MPS as the top level plan.
Launch the MPP or MPS plan.
If you make any changes to the results of the hub plan that impact resources, run online or batch replan against the hub plan before feeding it to the spoke plan.
In the spoke plan, navigate to Plan Options > Organizations tab.
Select the top level plan as a demand schedule for the lower level plan, the MRP.
Clear the Interplant check box.
Launch the MRP plan.
Navigate to Workbench > Supply/Demand window.
View the supply or demand that is fed from the MPP/MPS plan demand schedule.
The Item From Source Plan check box is selected for all supplies or demands that arrive from an MPS or MPP.
This section provides a few examples to illustrate the relation between the Interplant plan option and hub and spoke planning:
Single organization MPP as a demand schedule to an MRP with Interplant not Checked
Single organization MPP with critical components as a demand schedule to an MRP
Multi organization MPP with critical components as a demand schedule to an MRP
In all the examples provided in this section, you can change MPP to MPS everywhere to receive identical results.
Assume that a single organization uses a MPP and an MRP. The MPP is a demand schedule to the MRP and the Interplant option is not selected. The MRP does not plan the MPP or MPS planned supplies:
Figure Single organization MPP illustrates the following:
Sandwiched items: Item F is sandwiched between items D and J.
Item E is MRP/MPP planned or uses a joint planning method.
The MPP constrained planning rules are:
Items A, B, E, D, F, and J are planned by the MPP
Items C, H, I, G and K are not planned by the MPP and are not visible in the MPP.
When the MPP is a demand schedule to the MRP, the MRP constrained planning rules are:
Items A, B, E, D, and J are not planned again by the MRP but the planned orders for items A, E, D, J are visible in the MRP.
Item F, which is the sandwiched MRP planned item, is re-planned by the MRP.
The planned order demand for items C, F, H, I G, and K is visible in the MRP. These items are planned in the MRP.
Explanation:
Item E, which is MRP/MPP planned, is treated like MPP planned items. If Item B is MRP/MPP and Item E is MPP, there is no difference in the plan results as both are still planned like any other MPP planned item.
If independent demands are fed to the MRP for any MPP planned item, then these are displayed in the MRP as Unmet Demand. The MRP does not create new supplies for any items planned by the MPP.
If new demands are fed to the MRP for the sandwiched item F, the total demand for item F in the MRP will exceed the total demand for item F in the MPP. Therefore, the supply of its component item J will be insufficient for the total demand found in the MRP. The MRP cannot plan additional supplies of Item J. Therefore, some item F supplies will be pushed to the end of the planning horizon.
Assume that a single organization uses a MPP and an MRP. The MPP is fed as a demand schedule to the MRP and the Interplant option is not selected.
Single organization MPP with critical components
Figure Single organization MPP with critical components illustrates the following:
MPP planned items include 1, A, D, K, and M.
Item G is MRP planned but it is treated as MPP planned by the MPP because it is sandwiched between MPP planned Items. It is re-planned by the MRP.
MRP planned items include B, C, E, F, G, H, I, J, L, N, O, P, Q, and R.
Three MRP planned items C, F, and R are marked as critical components. These are constraints to the MPP plan. Planned orders from the MPP are not passed to the MRP for these three items.
Item B is MRP planned and not a critical component but is treated as a critical component because it is above another critical component. Planned orders from the MPP are not passed to the MRP for Item B.
The MPP has both released supplies and planned order supplies for all MPP planned items. These are passed to the MRP as independent demands and supplies whenever they have an MRP planned item below them.
In the MRP Supply Demand view, the following information is displayed:
Plan Method | Item | Firm | From Source Plan | Order Type | Days Late | Qty/ Rate | Sugg Start Date | Sugg Due Date | Demand Satisfied Date | Need By Date | Action |
---|---|---|---|---|---|---|---|---|---|---|---|
MPP | 1 | Yes | Sales Order | 1 | -1 | 3-Jan-03 | 4-Jan-03 | ||||
MPP | 1 | Firm | Yes | MPP Planned Order | 4-Jan-03 | 4-Jan-03 | 3-Jan-03 | Always None | |||
MPP | A | Yes | Planned Order Demand | -1 | -1 | 3-Jan-03 | 4-Jan-03 | None | |||
MPP | A | Firm | Yes | MPP Planned Order | -3 | 1 | 2-Jan-03 | 4-Jan-03 | 3-Jan-03 | Always None | |
MRP | E | Planned Order Demand | -3 | -1 | 2-Jan-03 | 5-Jan-03 | None | ||||
MRP | E | Planned Order | 1 | 4-Jan-03 | 5-Jan-03 | 2-Jan-03 | Release | ||||
MRP | C | Planned Order Demand | 1 | -1 | 2-Jan-03 | 1-Jan-03 | None | ||||
MRP | C | Planned Order | 1 | 1-Jan-03 | 1-Jan-03 | 2-Jan-03 | Release | ||||
MPP | D | Yes | Planned Order Demand | -1 | -1 | 1-Jan-03 | 2-Jan-03 | None | |||
MPP | D | Firm | Yes | MPP Planned Order | 0 | 1 | 1-Jan-03 | 2-Jan-03 | 1-Jan-03 | Always None | |
MRP | H | Planned Order Demand | 0 | -1 | 1-Jan-03 | 1-Jan-03 | None | ||||
H | Planned Order | 1 | 1-Jan-03 | 1-Jan-03 | 1-Jan-03 | Release | |||||
MPP | K | Firm | Yes | Planned Order Demand | 0 | -1 | 20-Dec-02 | 20-Dec-02 | None | ||
MPP | K | Firm | Yes | Discrete Job | -36 | 1 | 15-Dec-02 | 20-Dec-02 | 20-Dec-02 | Always None | |
MRP | L | Discrete Job Demand | -36 | -1 | 15-Dec-02 | 21-Jan-03 | None | ||||
MRP | L | Planned Order | 1 | 21-Jan-03 | 21-Jan-03 | 15-Dec-02 | Release | ||||
MRP | N | Discrete Job Demand | -1 | -1 | 18-Dec-02 | 19-Dec-02 | None | ||||
MRP | N | Planned Order | 1 | 19-Dec-02 | 19-Dec-02 | 18-Dec-02 | Release | ||||
MPP | M | Yes | Planned Order Demand | 0 | -1 | 17-Dec-02 | 17-Dec-02 | None | |||
MPP | M | Firm | Yes | Planned Order | 0 | 1 | 15-Dec-02 | 17-Dec-02 | 17-Dec-02 | Always None | |
MRP | Q | Planned Order Demand | 0 | -1 | 15-Dec-02 | 15-Dec-02 | None | ||||
MRP | Q | Planned Order | 1 | 10-Dec-02 | 15-Dec-02 | 15-Dec-02 | Release |
Explanation:
MPP planned orders can or cannot be released from the MRP, depending on the value of the profile option MSC: Allow MRP Release of Planned Orders from Demand Schedule Plan.
Item 1 also appears in the MRP Supply/Demand form but the pegging ends with the Item A supply.
Days Late information is brought over from the MPP. This is the calculated value found in the MPP for the demand.
Order number is either the MPP Plan Name or, if this is the end item demand in the MPP, the planning engine displays the order number found in the MPP for the end item demand. If the customer and customer site for the end item demand is available in the MPP, this is also passed to the MRP for the end item demand.
The planning engine provides the order start date and all operation start dates from the MPP to MRP. This drives the due date for MRP components if the Operation Start Date scheduling method is selected.
The Need By Date for a planned order from the MPP is always the suggested due date of the MPP Schedule Demand.
Item C is MRP planned and is a critical component. The MRP creates the planned orders and these can be released from the MRP. The planned orders created for item C in the MPP are not visible in the MRP.
The example displays a planned order scheduled early because of capacity constraints.
A supply for item K is 36 days late. From the supply chain bills of material, it is clear that the item A supply will also late. However, the MPP Planned Order Demand for item A is not changed to reflect this. In the MRP, the days late is noted for the next higher level MPP planned items but the days late is not pushed up the supply chain bills of material to higher levels of MPP Planned Items.
The MPP planned order dates for item M are not changed even though item M is not needed at these dates because the supplies for Item K are 36 days late.
The days late information for the MPP supply are based on the lower level supplies that are pegged to it.
The rows marked as Yes in the From Source Plan column indicate that the demand and supply rows are from the demand schedule plan, either an MPS or a MPP.
Assume that the MPP plans for four organizations D2, M2, S1, and M1.
Figure Multi organization MPP illustrates that the interorganization transfers, which are possible between the four organizations are:
Org D2 item A is transferred from M2
Org M2 item L is transferred from M1
Org M2 item E is transferred from M2
The MPP has a demand schedule for item 1. The MPP is fed to an MRP as a demand schedule four times, once for each org D2, M1, M2, and S2.
The MPP plans the following items:
Org D2: Items 1 and A
Org M2: Items A,B, E. B is only planned as a critical component.
Org M1: No items
Org S1: Items E, F, G and I. I is only planned as a critical component.
The MPP is fed as a demand schedule to the MRP. You can arrive at two results based on the Interplant check box selection:
The MRP shows MPP planned supplies for all MPP planned items. In the MRP, you can see:
Org D2: Nothing
Org M2:
MPP planned make orders for item A
MPP planned transfer orders for item E from S1
MRP planned orders for Items B, C, and D
MRP planned transfer orders for item L from M1
Org M1:
Nothing from the MPP
MRP planned orders for items L, M, and N
Org S1:
MPP planned orders items E, F, and G
MRP planned orders for items H and I
In the MRP, the interplant check box is selected for the MPS or MPP demand schedule. The only planned orders from the MPP or MPS that appear in the MRP are interplant transfers. The purpose of feeding the demand schedule with Interplant option selected is to pick up the interplant demands and then let the MRP plan all supplies within an organization. The supplies are all pegged to the interplant transfer demands, which are again seen as firm with respect to the MRP. No dates and times are changed for the interplant transfer demands.
Oracle Advanced Supply Chain Planning provides you with master scheduling capabilities to perform aggregate production planning using product family items.
Forecasting and planning at the product family level allows you to anticipate and resolve resource loading issues and subsequently helps you to recommend appropriate levels of procurement at the right times.
You can also perform aggregate production planning using product family items if you want to segregate production planning (for level loading against resource constraints) and materials planning (for driving procurement) into separate job functions.
Oracle does not recommend placing an assemble-to-order model as a member of a product family.
Oracle Advanced Supply Chain Planning provides you the following features for master scheduling:
Planned orders for product family items in an MPS plan are usually firm due to the following reasons:
The orders are firmed during level loading
The profile option MSC: MPS Auto-Firm Planned Orders is set to Yes
Oracle Advanced Supply Chain Planning allows you to eliminate the firmed planned orders within a defined time fence from subsequent batch replans. When you set the Reduce MPS option, firm planned orders that fall within the Reduce MPS time fence are automatically dropped at the time of the next plan run. This helps you in avoiding overstatement of material and resource requirements.
Note: In case of standard items, the demand time fence, the process of releasing a planned order, and collecting the Work In Process job reduces and relieves the planned orders. However, product family items are only reference items with respect to execution and are never released. Therefore, these items do not follow the mechanism used by standard items.
Define the product family item.
For more details, see section: Creating a Product Family in Oracle Bills of Material User's Guide.
Select the Inventory responsibility.
Navigate to Items > Organization Items > MPS/MRP Planning tab.
Set the Reduce MPS option to one of the following:
None - The order quantities of the MPS item supply are not reduced.
Past Due - When the supply due date is past due, the order quantities on the MPS supply entries are reduced to zero
Demand Time Fence - When the supply is within the demand time fence, the order quantities on the MPS supply entries are reduced to zero
Planning Time Fence - When the supply is within the planning time fence, the order quantities on the MPS supply entries are reduced to zero
It is recommended that you use the Past Due option for reducing MPS and enable Demand Time Fence for items that are exploded and derived in planning.
Set the Reduce MPS option.
Run a production plan for the MPS item.
Level load and firm the planned orders.
Re-run production plan at a later date.
Verify that firmed planned orders are dropped based on the Reduce MPS time fence.
During planning, Oracle Advanced Supply Chain Planning considers the following derived dependent demands as production forecasts:
Member items that are part of a product family item
Option class and option items that are part of a model item
The planning engine applies demand time fence control to the production forecast. This ensures a correct demand picture for the member items, option class and option items.
Select the Inventory responsibility.
Navigate to Items > Organization Items > MPS/MRP Planning tab.
Set the Forecast Control as None for the member items, option class, or option items.
The planning engine explodes the requirements for these items based on the parent forecast or demand.
Optionally, define the Demand Time Fence for member items to enable demand time fence control.
For more details, see section: MPS/MRP Planning Attribute Group in Oracle Inventory User's Guide.
Verify that the derived demand is available as production forecast.
If Demand Time Fence is enabled, the planning engine uses the member item demand time fence.
Navigate to the Horizontal Plan window to view the dependent demand.
When you need to ship product family member items from multiple shipping locations, Oracle Advanced Supply Chain Planning generates recommendations for shipping locations based on capacity and current supply conditions and allows you to distribute forecasts to the specific shipping locations. Using this option, you can decide, which internal organizations to source from at the product family level in the production plan.
Select Advanced Supply Chain Planner responsibility.
Navigate to Sourcing > Assignment set.
The Sourcing Rule / Bill of Distribution Assignments window appears.
Assign sourcing rules to product family items.
For more details on assigning sourcing rules, see Setting Up the Supply Chain,
Oracle Advanced Supply Chain Planning uses the global sourcing rules from the assignment set defined in Step 3 to distribute forecast using global forecasting rules.
For more details on global forecasting, see Chapter 6: Supply Chain Modeling, section: Global Forecasting.
It is often desirable to master schedule only end items, taking into consideration material availability of critical components and the capacity of key bottleneck resources. You can specify certain components as critical components, and resources as bottleneck resources to constrain an MPS or MPP plan even though the components are actually planned in MRP.
Select the Inventory responsibility.
Navigate to Items > Organization Items > MPS/MRP Planning tab.
Select the critical component check box.
The planning engine can infer from the bottleneck resource group whether or not an item is a critical component.
For more details, see section: MPS/MRP Planning Attribute Group in Oracle Inventory User's Guide.
Select the Inventory responsibility.
Define the Bottleneck Resource Group in the Resource Groups Lookups form.
Assign the Bottleneck Resource Group to the appropriate department resources in the Department Resources form.
For more details, see Oracle Bills of Material User's Guide.
Specify the Bottleneck Resource Group in Plan Options > Constraint tab.
If you plan using a bottleneck resource group, the planning engine schedules all resources but schedules resources in the bottleneck resource group differently than it schedules resources not in the bottleneck resource group.
For resources in the bottleneck resource group, it performs the usual detailed scheduling referring to the constraint planning options that you selected.
For resources not in the bottleneck resource group, it schedules activities and operations:
When needed
Based on the required duration (Resource usage / Assigned units)
Without regard to resource capacity. If its actions overload resource capacity, it issues Resource overloaded exception messages.
Without regard to the plan option Resource Constraints.
If the plan is:
Enforce capacity constraints, the planning engine may schedule the supply late because of the duration and issue Resource constraint exception messages.
Enforce demand due dates, the planning engine may compress the duration so that the supply completes on time, when it reaches the planning horizon start time, and when it reaches the planning time fence. As it compresses duration, it increases assigned units.
Oracle Advanced Supply Chain Planning allows you to view the product family item details that include member item rolled up information in the Horizontal Plan window.
For more details, see Chapter 10: Planner Workbench, section: Product Family and Member Item Drill Down.
Pegging traces supply information for an item to its corresponding end demand details.
For more details, see Chapter 10: Planner Workbench, section: Forecast and Production Forecast Pegging.
In Oracle ASCP you can launch three type of plans:
Production Plan
Manufacturing Plan
Master Plan
Each creates time-phased planned orders that satisfy independent and dependent demand while seeking to respect material and resource constraints.
A choice of plan types lets you tailor the degree of subset planning that is performed for the supply chain: from a single, global supply chain plan down to manually adjusted plans for each item in each organization of the supply chain.
MPS plans support the following functionality:
You can select routings for a production plan while scheduling resources.
For production plans that have routings, you can view the Gantt chart in the Planner Workbench.
To do this, the three types of plans need to be used in conjunction with the MRP Planning Type item attribute that is set for each item. Possible values for this attribute are:
MRP Planning
MPS Planning
MRP/MPP Planned
MPS/MPP Planned
MPP Planned
In addition, plan option Main tab, Planned Items specifies the types of items that the planning engine should plan in a particular plan run. Choices are:
All Planned Items
Demand Schedule Items and all sales orders: Plan all items that have demands as well as all items that have sales orders against them.
Supply Schedule Items only
Demand and supply schedule Items
Demand Schedule and WIP components
Demand Schedule items only: Only plan items that have demands If plan option Include Sales Orders is selected (Organizations tab), include only sales orders against those items.
Demand Schedule Items, WIP components and all sales orders
Sign on with the Manufacturing and Distribution Manager responsibility.
From the Navigator window, choose Inventory > Items > Master Items.
Sign on with the Manufacturing and Distribution Manager responsibility.
From the Navigator window, choose Inventory > Items > Organization Items.
Each type of plan includes or ignores an item for planning depending on the setting of its MRP Planning Type attribute. The discussion below focuses on the principal ways in which plan type (Master, Production, or Manufacturing) can be used in conjunction with MRP Planning Type item attribute values (MRP Planning, MPS Planning, MPP Planned, MRP/MPP Planned, MPS/MPP Planned).
There is a logical equivalence between the different planning types as shown by the fact that the following plans, applied to the sample supply chain (Sample Supply Chain) and BOM (Sample Bill of Material), yield identical planned orders across the supply chain. In the BOMs illustrated in these figures, the values in parentheses indicate the setting of the MRP Planning Type item attribute.
The usefulness of the different types of plans comes in when subset planning is used. Suppose, for example, that subset plan M12 and all its components and subcomponents are used. Some reasons for needing to do so are discussed above.
Run a Master plan to generate planned orders for all items except for the components and subcomponents of M12 (Sample Bill of Material):
This combination of plan type and MRP Planning Type item attribute values creates cross-supply chain planned orders for A01, M11, B13, B21, and M12 and omits M22, B23, B31.
Use the Master plan as a demand schedule for a Production plan run. This generates planned orders M12.
Manually modify the MPS for M12 as necessary.
Note: With Oracle ASCP, this step is less frequently necessary than before. This is because the finite-capacity planning performed by Oracle ASCP takes resource and material availability into account, and therefore eliminates much of the need to manually smooth production via an MPS.
Run a Manufacturing plan, using the Production plan as an input demand schedule. This generates planned orders for M12, M22, B23 and B31 (Sample Bill of Material).
Oracle ASCP allows for the following options for generating plans.
Unconstrained
Resource Constrained
Material Constrained
Material and Resource Constrained
Optimized
Before discussing these options in the table below, please take note of the following key concepts.
Oracle ASCP lets you prioritize how you enforce Capacity Constraints or Demand Due Dates. Whichever constraint takes precedence over the other is the hard constraint; the other is the soft constraint. You must choose one and only one type of constraint.
If you choose to enforce Demand Due Dates (setting Demand Due Dates as a hard constraint), then primary resources are used and loaded to capacity to satisfy demand due dates. The system also evaluates alternate resources if additional capacity is required. If there is insufficient capacity to meet demand due dates, the primary resource is overloaded. The choice of whether to use an alternate resource or overload capacity depends on cost considerations if optimization is selected. Oracle ASCP returns exception messages if capacity is overloaded.
If you choose to enforce Capacity Constraints (setting Capacity Constraints as a hard constraint), then resources are loaded to their limit to satisfy demand (if required). Unsatisfied demand is pushed into the future. In this case, Oracle ASCP returns late replenishment exception messages.
Oracle ASCP allows for multiple levels of optimization in generating plans. These are described in the table below along with the situations under which each would be most useful.
The scope of optimization levels is summarized in the table below:
Optimization Level | Scope |
---|---|
Non-optimized (unconstrained, resource constrained, material constrained, material and resource constrained) (Optimized option unchecked which applies to the entire planning horizon) |
Local settings that can be applied to temporal subsets of an overall supply chain plan. These simply dictate which types of constraints (material and resource) are obeyed in which portions of the plan. The planned orders for the Resource Constrained, Material Constrained and Material and Resource Constrained time portions of the plan are generated via a fast heuristic. The planned orders for the Unconstrained time portion of the supply chain plan are always generated using traditional MRP type logic. |
Optimized (Optimized option checked which applies to the entire planning horizon) |
Global setting that applies to the entire supply chain plan. The planned orders for the resource constrained, material constrained and material and resource constrained time portions of the plan are generated via a linear programming planning algorithm which explicitly optimizes objectives that are important to the user. |
The planning engine operates in phases. Each phase performs different planning tasks.
You can choose a planning mode to guide the planning engine in the planning process. Each planning mode executes a different set of planning phases.
Planning Engine Phases
This table explains the planning engine phases.
Planning Engine Phase | Description |
---|---|
Optimization phase | - Linear-programming based - Selects alternate sources, processes bills of material and routings, substitute items and components, and alternate resources |
Order modifier phase | - Modifies output of optimization phase so that order modifiers are respected - Calculates pegging |
Planning phase | - Nets available supply and scheduled receipts against demand to calculate planned orders - Applies order modifiers - Calculates pegging - Enforces date effectivities: Bills of material and routings, sourcing rules, process validity rules, and end item substitution rules) |
Scheduling phase | - Reschedules supplies to respect material, resource, lead-time, and calendar constraints - Refines alternate resource selection if necessary - Schedules supplies to the minute |
Planning Modes
You select the planning mode for a plan as you specify the instructions for the planning engine (plan options). This table explains the planning phases that the planning engine performs each planning mode.
Planning Mode | Planning Engine Phases |
---|---|
Unconstrained: Planning phase | Planning phase |
Constrained (Classic): | - Planning phase - Scheduling phase |
Constrained (Classic) with Decision Rules: | - Optimization phase - Planning phase - Scheduling phase |
Constrained (Without Detailed Scheduling): | - Optimization phase - Order modifier phase |
Constrained (With Detailed Scheduling): | - Optimization phase - Order modifier phase - Scheduling phase |
Optimized: | - Optimization phase - Planning phase - Scheduling phase |
The planning modes Constrained (Without Detailed Scheduling) and Constrained (With Detailed Scheduling) are available only when the value of profile option MSC: Enable Advanced Constraints is Yes
Evaluation of Planning Modes
If you want to plan to infinite capacity, choose Unconstrained planning mode.
If you want to constrain the plan according to capacity constraints or due dates, choose from:
A constrained planning mode—Constrained (Classic), Constrained (Classic) with Decision Rules, Constrained (Without Detailed Scheduling), and Constrained (With Detailed Scheduling) planning mode
Optimized planning mode
If you want the planning process automatically to select alternates considering full relative cost data, choose Optimized planning mode.
If you want the planning process automatically to select alternates considering only the rankings of alternates (sources, bills of material/routings, resources, substitute components, end item substitutes) and not relative cost data for alternates, choose from
Constrained (Classic) with Decision Rules planning mode
Constrained (Without Detailed Scheduling) planning mode
Constrained (With Detailed Scheduling) planning mode
Before you use these alternate options, set profile options:
MSC: Enable Advanced Constraints
MSO: Order Modifier Maximum Searching Depth
Oracle suggests that the Constrained (Without Detailed Scheduling) and Constrained (With Detailed Scheduling) planning modes provide superior solution quality to the Constrained (Classic) with Decision Rules planning mode. The superior quality results from planned order generation with respect to order modifiers, capacity, and lead-time constraints at the same time. This results in more accurate offloading from primary to:
Alternate resources when order modifiers are present
Alternate sources to minimize demand lateness
Substitute components to minimize demand lateness
These diagrams show some solution differences between the Constrained (Classic) mode and the Constrained (With/Without Detailed Scheduling) modes.
If day-level planning information is acceptable and you prefer to have the planning results as quickly as possible, choose Constrained (Without Detailed Scheduling) planning mode. Oracle suggests that this planning mode generally takes less time to process than the detailed scheduling planning modes—Constrained (Classic) with Decision Rules and Constrained (With Detailed Scheduling).
If you need detailed scheduling to the minute and can wait for longer processing times than Constrained (Without Detailed Scheduling) planning mode, choose from:
Constrained (Classic) with Decision Rules planning mode: Oracle suggests that this planning mode generally takes less time to process than the Constrained (With Detailed Scheduling) planning mode.
Constrained (With Detailed Scheduling) planning mode: Oracle suggests that this planning mode takes longer to process than the Constrained (Classic) with Decision Rules planning mode but provides superior solution quality.
This section describes how to set plan options. The plan options appear in the following tabbed regions:
Main
Aggregation
Organizations
Constraints
Optimization
Decision Rules
To access the plan options do either of the following:
Go directly from the Navigator
Access the Plan Names form, select a plan, and click Plan Options.
This table describes the fields and options.
Object | Description |
---|---|
Planned Items | This parameter and the Plan Type field in the Supply Chain Names window, control the items that are planned in the supply chain plan. An item must satisfy conditions imposed by both parameters before being included in the supply chain plan. Please see Choosing a Plan Type for further details. |
Assignment Set | The assignment set that holds the sourcing rules and bills of distribution that define the rules for material flow within your supply chain. |
Material Scheduling Method | Choose from Operation Start Date or Order Start Date scheduling methods. If you choose Operation Start Date, material is scheduled to arrive at the start of the operation for which it is required. If you choose Order Start Date, material is scheduled to arrive at the start of the order for which it is required. Order State Date is usually an earlier date than the Operation Start Date and therefore this selection represents the more conservative planning logic of the two options. |
Demand Priority Rule | When ASCP does detailed scheduling, it schedules demands one by one. The rule specified here dictates the order in which demands will be considered during detailed scheduling, and thus which demands will get the first opportunities to take up available materials and resource capacities. Please see the section Demand Priority Rules. |
End Item Substitution Set | If Decision Rules tabbed region > Use End Item Substitution is selected, select a substitution set. These are defined in the Planning Details - Substitute window discussed End-Item-Level Substitution. You can use a set of substitution relationships to be effective for a given plan by selecting the substitution set as an option for the plan. This allows you to run simulations of possible substitutions and evaluate performance indicators given possible future substitutions. |
Overwrite | Overwrite planned orders. For further details, please see Overwrite Options. |
Schedule By | Set this option to instruct the planning engine to: - Plan supplies based on sales order line request, promise, or schedule dates for either ship or arrival - Consume forecasts based on sales order line request, promise, or schedule dates. You must provide forecast dates that match your choice of this plan option; for example, if you select Promise Ship date for this plan option, make sure your forecast dates are in terms of promise ship dates. Select one of the following sales order line dates: - Schedule Ship Date - Schedule Arrival Date - Request Ship Date - Request Arrival Date - Promise Ship Date - Promise Arrival Date The default is Schedule Ship Date. For forecast consumption, the planning engine uses:
If you do not specify plan option Demand Priority Rule and have not specified a default demand priority rule (in the Define Priority Ruled form), the planning engine uses the value of this plan option as the demand priority rule. |
Demand Class | If you want to limit a production plan to a demand class, enter it. This field is active only for a Production Plan/MPS schedule. |
Demand Time Fence Control | Check this option to enforce demand time fence control. |
Append Planned Orders | Appends new planned orders to current plan. For further details, please see Overwrite Options. |
Planning Time Fence Control | Check this option to enforce item attribute planning time fence control. |
Move Work Orders to PIP | Check this option if you want to generate planned order supply even in the absence of demand in order to ensure that inventory is held on the manufacturing floor only for items designated as Planned Inventory Points. |
Display Key Performance Indicators | Check this option to calculate key performance indicators for the plan. |
Lot for Lot | Check this option to force the creation of a separate supply for each demand. This prevents creation of aggregate supplies that satisfy multiple demands. |
Include Critical Components | Select this plan option to instruct the planning engine to plan considering critical components. Depending on the plan type and the planning item types, the planning engine may plan critical components and not plan other components or components of those components. To mark an item as a critical component, select its item attribute Critical Component. |
Do Not Spread Forecast | The planning engine should use forecast entries as they exist for planning. |
Spread Forecast Evenly | The planning engine should spread aggregate forecast demand evenly across the daily buckets from the workday calendar. |
Consume by Forecast Bucket | The forecast consumption process does not search outside of the consumption bucket for forecasts and sales orders except in daily buckets. |
Explode Forecast | Select this plan option to instruct the planning engine to explode forecasts as follows during the consumption process: - Product family forecasts to product family member item forecasts - Model forecasts to other model, option class, and item forecasts. This option applies to forecasts with forecast control Consume and derive. If you clear this plan option, you have arranged for this explosion to occur in the source instance or in Oracle Demand Planning before the planning run. |
Backward Days | This parameter allows a sales order demand to consume forecast demand even if the forecast demand is up to the specified number of days earlier than the sales order demand. It applies only to the supply chain planning forecast and not to Oracle Demand Planning forecast scenarios. Please see the section Forecast Consumption Days for more details. |
Forward Days | This parameter allows a sales order demand to consume forecast demand even if the forecast demand is up to the specified number of days later than the sales order demand. It applies only to the supply chain planning forecast and not to Oracle Demand Planning forecast scenarios Please see the section Forecast Consumption Days for more details. |
Enable Pegging | Select this option (the default) to calculate pegging information. Oracle ASCP traces supply information for an item to its corresponding end demand details, which you can then view in a graphical display. This field is checked by default. |
Peg Supplies by Demand Priority | If Enable Pegging is selected, select to instruct the planning engine to peg in demand priority order from Demand Priority Rule. |
Reservation Level | If Enable Pegging is selected, choose a reservation level: Planning Group, Project, Project-Task, or None. |
Hard Pegging Level | If Enable Pegging is selected, choose a hard pegging level: Project, Project-Task, or None. |
This table describes the fields and options.
Object | Description |
---|---|
Plan Start Date | If you have never run the plan, this field displays today's date. If you have run the plan, this field displays the planning horizon start date of the last run. |
Plan End Date | Calculated planning horizon end date based on your entries in Buckets and the owning organization calendar. |
Start Date | Calculated start date for each bucket based on your entries in Buckets and the owning organization calendar. The value for the Days column is the Plan Start Date. |
Buckets | Number of buckets of this bucket type. Weekly buckets can only start on the week beginning day from the manufacturing calendar. If the daily horizon does not end on the day before a week beginning day, the planning engine extends it to the next day before a week beginning day. It plans the extended days in daily buckets, never minute or hourly buckets, regardless of any other settings. |
Items | Choose to plan at either the Item level or Product Family level. If you select Items in the first bucket, the other buckets can be set to either Items or Product Family. However, if you select Product Family in the first bucket, the remaining buckets are set to Product Family by default. |
Resources | Choose to plan at either the Individual level or Aggregate level. If you select Individual in the first bucket, the other buckets can be set to either Individual or Aggregate. If you select Aggregate in the first bucket, the remaining buckets are set to Aggregate by default. |
Routings | Choose to plan at either the routings or bill of resources level. Whatever level you select in any of the buckets, all the rest of the buckets are assigned that level by default. |
The planning run generates planned orders, recommendations, and resource requirements.
The planning horizon is synchronized with time of the plan run. As a result, planned orders, recommendations, and resource requirements are generated starting at the time of plan run.
This diagram shows how resource utilization is calculated. The resource requirements are calculated as of Time t2 and the resource availability as of Time t1. There is a disparity between the times of resource requirement calculation (t2) and resource availability calculation (t1).
This table describes the fields and options.
Object | Description |
---|---|
Global Demand Schedules | Select the names of Oracle Demand Planning scenarios that drive this plan. You can select demand planning scenarios that do not reference an organization (organization dimension set to All Organization). |
Ship To Consumption Level | Select a forecast consumption level for the Oracle Demand Planning scenario. The global forecasting process consumes forecast entries that have Ship To value the same as this plan option. You can select: - Customer - Customer Site - Zone - Customer Zone - Demand Class - Item The choices in the list of values changes depending on the published level of the scenario. |
Org | An organization which this plan should plan. |
Description | The name of the organization. |
Net WIP | Select to consider discrete jobs and other production orders as supply in the planning demand/supply netting process. |
Net Reservations | If checked, ASCP generates pegging of on-hand supply to sales orders that matches the reservations recorded in the source transaction system. |
Net Purchases | Select to consider purchase orders, purchase requisitions, in-transit shipments and other nonproduction order scheduled receipts as supply in the planning demand/supply netting process. This option covers all scheduled receipts not covered by the Net WIP option. |
Plan Safety Stock | Select to consider plan safety stock demand and supply in the planning demand/supply netting process. See Safety Stock. |
Include Sales Order | Select to invoke forecast consumption within ASCP for the selected organization. Check this if the demand schedules for the organization are unconsumed forecasts. Uncheck this if the demand schedules for the organization are consumed forecasts plus sales orders in the form of master demand schedules. |
Firm Planned Orders From Production Schedule | Select this check box to indicate that the organization can receive data from Production Scheduling to the schedule specified in the Schedule Name field.
See Feeding a Production Schedule Back into ASCP. |
Schedule Name | Enter the name of the production schedule. Note that this production schedule should be referencing this ASCP plan within its schedule options. In other words, the schedule name that is entered should reference the ASCP plan on the Schedule Options page, Scope tab.
See Feeding a Production Schedule Back into ASCP. |
Firm Horizon (Days) | Enter the number of days for which the planned orders from the feeding production schedule are considered by the ASCP plan.
See Feeding a Production Schedule Back into ASCP. |
Bill of Resource | Select Bill of Resources from the list of values. |
Simulation Set | Select a Simulation Set from the list of values. A simulation set is a set of adjustments to the base availability calendar of a resource, and is defined via the Oracle Bills of Material Department Resources form. You can define different simulation sets to model different availability scenarios (for example, the base availability calendar reflects 5 day operations; simulation set 1 reflects working 6 day operations; simulation set 2 reflects 7 day operations). The planning engine applies the simulation set to all resources in the organization. Oracle Enterprise Asset Management plans maintenance activity and creates maintenance work orders which may specify shutdown of equipment resources. If you are using Oracle Enterprise Asset Management, you can pass your maintenance downtimes to the planning engine. To plan for these shutdowns in Oracle Advanced Supply Chain Planning, run the Oracle Enterprise Asset Management Load Equipment Maintenance Downtime concurrent process. The process creates a simulation set with the downtimes recorded as capacity changes for reduced hours. You can specify the simulation set in the Organizations tabbed region of the Plan Options window. When the plan is run, the planning engine uses this simulation set to calculate the reduction in the available capacity of resources due to maintenance downtime. The planning engine plans production activities for these resources after considering the reduction in available capacity. You can view the impact of this change on the resource availability and usage profiles in the Planner Workbench. |
Demand Schedules | Select the names of demand schedules, forecasts, and plans that drive this plan. |
Include Targets | You can select this option for a distribution plan that you are using as a demand schedule. Distribution plans may use target inventory levels and attempt to plan to meet the target inventory demands. However, when smoothing their production schedules and resolving constraints, they may choose to produce some amount less than required by the target inventory levels. In this case, distribution planning distributes according to safety stock inventory levels first and then allocates the remainder using the target inventory levels. |
Ship To Consumption Level | Select a forecast consumption level for the local forecasts in the demand schedule. The forecast consumption process consumes forecast entries that have Ship To value the same as this plan option. You can select: - Customer - Customer Site - Demand Class - Item-org |
Interplant | If selected, the planning engine uses only interorganization orders and demands from interorganization planned orders. If cleared, the planning engine uses demands from all planned orders. |
Supply Schedules | Select the name of supply schedules that participate in this plan. |
Subinventory Netting | Opens the Subinventory Netting window. |
This table describes the fields and options.
Object | Description |
---|---|
Constraints Mode | Specify the constrained planning mode for this plan; see Choosing Planning Modes. Valid values are: Unconstrained: This is the default value. The options in the Scheduling region are grayed out. Constrained (Classic): The options in the Scheduling region are enabled. Constrained (Without Detailed Scheduling): The options in the Scheduling region are grayed out. You cannot use lot-for-lot planning in this planning mode. Constrained (With Detailed Scheduling): The options in the Scheduling region are enabled. You cannot set all Resource Constraints and Material Constraints to No. If you set any Resource Constraints to Yes, you cannot clear Calculate Resource Requirements. To enable pegging, select plan option Enable Pegging. |
Enforce Demand Due Dates | Select if you want demand due dates to be your hard constraint (that is, respected in lieu of material and resource capacity constraints if there is conflict). For more information, see Setting Constraints for Different Plan Types. |
Enforce Capacity Constraints | Select if you want material and resource capacity constraints to be respected in lieu of demand due date constraints if there is a conflict. For more information, see Setting Constraints for Different Plan Types. |
Start Date | Displays the start date for each bucket type. |
Buckets | Displays the number of buckets of this bucket type. |
Resource Constraints | Select Yes to consider resource constraints. If you select No, the planning engine assumes that resource capacity is infinite regardless of any simulation sets. |
Supplier Capacity Constraints | Select Yes to consider supplier capacity constraints. |
Enforce Purchasing Lead-time Constraints | Select this plan option to instruct the planning engine to constrain the plan by purchased item lead-times (item attributes or approved supplier list). Clear it to instruct the planning engine never to miss a demand due date because of a purchased item lead-time. For more details, see Enforce Purchasing Lead-time. |
Minutes Bucket Size (in Days) | Specify the number of minute buckets in the Days bucket type. If the plan start time is not 00:00, the planning engine schedules the remainder of the first day in minutes even if the value for plan option Minutes is 0. For example if you start the plan on 01-Jan 14:00, the planning engine schedules in minutes from 01-Jan 14:00 to 02-Jan 00:00. |
Hours Bucket Size (in Days) | Specify the number of hours buckets in the Days bucket type. |
Days Bucket Size (in Days) | Specify the number of days buckets in the Days bucket type. |
Calculate Resource Requirements | If selected, the program will calculate resource capacity utilization. Select in unconstrained plans to enable release of lot-based planned orders. |
Planned Resources | Select All Resources or Bottleneck Resources. If you have defined bottleneck resource groups in Oracle Bills of Material and you want to detail schedule only the bottleneck resources, select Bottleneck Resources and enter a Bottleneck Resource Group. |
Bottleneck Resource Group | If you have defined bottleneck resource groups in Oracle Bills of Material and you want to detail schedule only the bottleneck resources, select its name. |
If you plan using a bottleneck resource group, the planning engine schedules all resources but schedules resources in the bottleneck resource group differently than it schedules resources not in the bottleneck resource group.
For resources in the bottleneck resource group, it performs the usual detailed scheduling referring to the constraint planning options that you selected.
For resources not in the bottleneck resource group, it schedules activities and operations:
When needed
Based on the required duration (Resource usage / Assigned units)
Without regard to resource capacity. If its actions overload resource capacity, it issues Resource overloaded exception messages.
Without regard to the plan option Resource Constraints.
If the plan is:
Enforce capacity constraints, the planning engine may schedule the supply late because of the duration and issue Resource constraint exception messages.
Enforce demand due dates, the planning engine may compress the duration so that the supply completes on time, when it reaches the planning horizon start time, and when it reaches the planning time fence. As it compresses duration, it increases assigned units.
This table describes the fields and options.
Penalty factors are plan level values that:
You can override by setting values for organizations and items in the source instance
Override those set in profile options
This tabbed region is available as follows:
Unconstrained plans: It is never available.
Constrained plans: It is available only if profile option MSO: Enable Decision Rules is Yes.
Optimized plans (Optimization tabbed region, Optimize is selected): It is always available.
For buy items in unconstrained plans and constrained plans in which this tabbed region is not available, you can duplicate the functionality of this region's Use Alternate Sources parameter; set profile option MSC: Enable Enhanced Sourcing to Yes. You cannot duplicate this functionality for transfers from other organizations.
When this tabbed region is enabled, the planning engine does not consider the profile option MSC: Enable Enhanced Sourcing.
This table describes the fields and options.
Object | Description |
---|---|
Use End Item Substitution | If selected, use end item substitute prior to creating new planned orders. If cleared, use only the demanded item. Enter the End Item Substitution Set in the Main tabbed region. |
Use Alternate Resources | If selected, use primary resource and use alternate resource only if necessary. If cleared, use only primary resources. |
Use Substitute Components | If selected, use primary components and use substitute components only if necessary. If cleared, use only primary components only. |
Use Alternate BOM/Routing | If selected, use primary routings and use alternates only if necessary. If cleared, use only primary bills of material and routings. |
Use Alternate Sources | If selected, use primary sources and use alternate sources only if necessary. If cleared, use primary sources only. The planning engine does not use alternate sources (rank 2 or higher) as a sources of supply. |
The plan for one organization can be used as a demand (or demand schedule) for the plan of another organization.
Note: Users can collect forecasts into the APS planning server. Optionally, they can choose to consume forecasts by sales orders when they run ASCP plans. Forecasts are consumed if the Include Sales Order check box in the Organizations tab of the Plan Options window is checked. For multilevel assemble-to-order items, forecasts are consumed at all levels if the forecast explosion has occurred in the source instance prior to the collection.
Choose Supply Chain Plan > Names to create a new plan for the organization that will use an existing plan as a source.
The Supply Chain Plan Names window appears.
Select Plan Options.
The Plan Options window appears.
Choose the Organizations tab.
Specify the plan name to be used as a source for the new plan in the Demand Schedule portion of the window.
Click Subinventory Netting.
The Subinventory Netting window appears.
This table describes the fields and options.
Object | Description |
---|---|
Name | Shows all active subinventories for your organization. |
Description | Subinventory description. |
Net | Select to net the subinventory in the planning run. |
Oracle Advanced Supply Chain Planning collects the following information on a demand that represents a sales order line:
Original ordered item: The item that the customer asked for
Ordered item: The item that the customer ordered (the booked item)
The relationship between the ordered item and original ordered item is classified as:
Up-sell: The process of offering customers products superior in capability to the ones that they intend to buy
Cross-sell: The process of offering customers related products or accessories in addition to the ones that they intend to buy
Substitution: The process of offering customers similar products to the ones that they intend to buy. This is usually when the requested product is not available to ship.
During forecast consumption, Oracle Advanced Supply Chain Planning checks to see if the booked item in the sales order is one that has been offered to the customer as a substitute to what the customer originally requested. If so, Oracle Advanced Supply Chain Planning consumes the forecast of the original item. If the booked item in the sales order is an up-sell or a cross-sell item, Oracle Advanced Supply Chain Planning consumes the forecast of the booked item.
This feature helps you in offering equivalent substitute products when requested product is in short supply. It also makes the forecast consumption process sensitive to the relationship type between the original and the ordered items as recorded on the sales order. This provides you with accurate records of order booking history, which improves forecast accuracy.
The following table shows the relationship type on the sales order line. The planning engine considers this for identifying the forecast against which this sales order line should be consumed.
Relationship type on the sales order | Forecast consumption performed on forecast of ordered item? | Forecast consumption performed on forecast of original ordered item? |
---|---|---|
Up-Sell | Yes | No |
Cross-Sell | Yes | No |
Substitution | No | Yes |
Select the Manufacturing and Distribution Manager responsibility.
Navigate to Order Management > Orders, Returns > Sales Orders.
Highlight any sales order line, and select Related Items to see all the potential up-sell, cross-sell, and substitution possibilities. You can select one of the displayed options.
Once you select a related item, Oracle Order Management copies the item that the customer had originally requested for, into the original item column on the sales order line.
Enter related items in the sales order lines.
Collect data into the planning instance.
Change to the Demand Planner responsibility.
Select the data stream inputs for demand planning.
For more details, see Creating Data Streams for Demand Plans.
Create a demand plan.
For more details, see Oracle Demand Planning Implementation and User's Guide.
Oracle Demand Planning has options of recording history against either the original item or the ordered item through the choice of input data stream. This will influence the forecasting process for these items.
Change to the Advanced Supply Chain Planner responsibility.
Navigate to Plan Options > Organization tab.
In the Global Demand Schedules region or the Organization specific Demand Scheduled Region, select the demand planning scenarios that drive the plan.
Run the plan.
Navigate to the Supply/Demand window to view the information on the original item and the ordered item.
7
The forecast consumption process of Oracle Advanced Supply Chain Planning is sensitive to the presence of orders that have undergone item substitution.
Right-click on a sales order line and select Consumption Details.
Both the Original Item and the End Item are displayed in the Consumption Details window.
You can also view the forecast consumption details in the Horizontal Plan window if the forecast is a global forecast.
When creating demand plans, you can specify any one of the following data streams:
Booking History
Booking History - Booked Items
Shipment History
Shipment History - Shipped Items
The following table shows whether the planning engine records the history on the original item or the ordered item based on the relationship on the sales order.
Input data stream | Relationship type on the sales order | History recorded on ordered item? | History recorded on original item? |
---|---|---|---|
Booking History or Shipment History | Up-Sell | Yes | No |
Cross-Sell | Yes | No | |
Substitution | No | Yes | |
Booking History - Booked Item or Shipment History - Shipped Item | Up-Sell | Yes | No |
Cross-Sell | Yes | No | |
Substitution | Yes | No |
If the relationship type on the sales order is other than up-sell, cross-sell, or, substitution, the planning engine records the history against the ordered item in all the four input data streams.
If the relationship type is blank and the original item is specified, these are orders that have undergone item substitution in the planning process. The planning engine treats such orders as the substitution relationship type.
Note: In case of model items, the Calculate Planning Percentages feature works only with two input data streams: Booking History - Booked Items and Shipment History - Shipped Items. Using this feature in conjunction with the other two data streams may produce inconsistent results.
When you launch the planning process, you generate new planned orders and suggested repetitive schedules to meet your net requirements. Since you can firm a MPP, MPS, or MRP planned order, you may not want the planning process to overwrite any firm planned orders. You can use the Overwrite and Append plan level options to limit how the planning process reacts to firm planned orders and to stabilize the short term material plan.
When you enter All in the Overwrite field in the Main tab of the Plan Options form, the planning process overwrites all entries, planned and firm planned, from the current material plan. When you enter None in the Overwrite field, the planning process does not overwrite any firm planned orders. It does, however, overwrite any suggested planned orders that are not firm. When you enter Outside planning time fence in the Overwrite field, the planning process overwrites all entries from the current plan, planned and firm planned, outside the planning time fence, and overwrites only planned orders inside the planning time fence. It does not overwrite any firm planned orders within the planning time fence. The planning time fence can be different for each item, so the planning process looks at the planning time fence for each item when choosing what to delete.
When you uncheck the Append Planned Orders field in the Main tab of the Plan Options window, the planning process does not append any planned orders to the current plan. Additional demand does not cause planned order recommendations. Instead, the projected quantity on hand may go negative in response to demand that was not met by a suggested planned order.
When you check the Append Planned Orders field, the planning process appends additional planned orders after the last entry on the current material plan to meet any additional demand. The overwrite and append options work in combinations, as described below.
This option allows you to create a new material requirements plan for the plan name you specify, deleting all previous planned and firm planned entries while regenerating new planned orders. You can use this combination the first time you run your plan or if you want your plan to reflect all sources of new demand. For example, if an existing material plan has the following orders for an item:
Schedule Date | Quantity | Order Status |
---|---|---|
01-FEB | 100 | Planned |
08-FEB | 200 | MRP firm planned |
15-FEB | 300 | Planned |
And the following MDS is used to plan the material plan using All in the Overwrite field and Yes in the Append Planned Orders field:
Schedule Date | Quantity |
---|---|
02-FEB | 110 |
09-FEB | 220 |
16-FEB | 330 |
Then the resulting material plan would have the following suggestions for planned orders:
Schedule Date | Quantity | Order Status |
---|---|---|
02-FEB | 110 | Planned |
09-FEB | 220 | Planned |
16-FEB | 330 | Planned |
The planning process always suggests planned orders. You can change planned orders to a firm status using the Items window in the Planner Workbench.
This option allows you to create an extension to the material requirements plan for the plan name you specify, deleting planned and firm planned orders outside the planning time fence and deleting all planned entries inside the planning time fence for each item. The planning process creates (appends) new planned orders after the planning time fence date. In this case, since you are overwriting after the planning time fence, you are also appending new planned orders after that date. You can use this combination to stabilize the short-term plan and allow the long-term plan to react to new sources of demand.
Note: If an item has no time fence specified and this option is chosen, all planned and firm planned orders are overwritten.
For example, if an existing MRP has the following orders for an item:
Schedule Date | Quantity | Order Status |
---|---|---|
01-FEB | 100 | Planned |
08-FEB | 200 | MRP firm planned |
15-FEB | 300 | Planned |
And the following MDS is used to plan the MRP using Outside Planning Time Fence in the Overwrite field and Yes in the Append Planned Orders field
:
Schedule Date | Quantity |
---|---|
02-FEB | 110 |
09-FEB | 220 |
16-FEB | 330 |
Then the resulting material plan would have the following suggestions for planned orders, assuming the planning time fence is 05-FEB.
Schedule Date | Quantity | Order Status |
---|---|---|
05-FEB | 110 | Planned |
09-FEB | 220 | Planned |
16-FEB | 330 | Planned |
Since the entry on 01-FEB is not firmed, the MRP planning process overwrites this entry. If it was firmed, the process would not overwrite the entry. The additional demand from the MDS of 110 on 02-FEB was appended on the planning time fence date of 05-FEB. The MRP firm planned order on 08-FEB was deleted because it falls outside the planning time fence of 05-FEB. The planning process always suggests planned orders. You can change planned orders to a MRP firm status using the Items window in the Planner Workbench.
When you choose not to overwrite an existing plan, the planning process does not overwrite existing firm planned orders, but deletes any suggested planned orders. The planning process then creates (appends) new planned orders after the planning time fence date. This is analogous to firming sections of your short-term material requirements plan. You can extend the plan horizon without altering existing firm planned orders. For example, if an existing MRP has the following suggested planned orders for an item:
Schedule Date | Quantity | Order Status |
---|---|---|
01-FEB | 100 | Planned |
08-FEB | 200 | MRP firm planned |
15-FEB | 300 | Planned |
And the following MDS is used to plan the MRP using None in the Overwrite field and Yes in the Append Planned Orders field:
Schedule Date | Quantity |
---|---|
02-FEB | 110 |
09-FEB | 220 |
16-FEB | 330 |
The resulting material plan would have the following suggestions for planned orders assuming the planning time fence is 05-FEB:
Schedule Date | Quantity | Order Status |
---|---|---|
05-FEB | 110 | Planned |
08-FEB | 200 | MRP firm planned |
09-FEB | 20 | Planned |
16-FEB | 330 | Planned |
The firm order on 08-FEB remains on the MRP since the overwrite is None. However, the planned entries are deleted. Although additional demand exists on the MDS, no planned orders are suggested until the planning time fence (on 05-FEB). The MDS demand of 110 on 02-FEB was satisfied by a new planned order for 110 on 05-FEB. The demand for 220 on 09-FEB was partially met by the firm MRP planned order on 08-FEB. Thus an additional planned order was suggested on 09-FEB for 20 to meet the MDS demand of 220. A suggested planned order was created on 16-FEB for 330 to meet the demand from the MDS on 16-FEB.
In this case, the planning process does not overwrite existing firm planned entries, but deletes any suggested planned orders. In addition, it does not append additional demand to the end of the plan. Instead, it reports the instances where the material requirements plan is out of balance with the master demand schedule, and allows you to solve these problems by manipulating the plan manually. This gives maximum control to the material planner. For example, if an existing material plan has the following orders:
Schedule Date | Quantity | Order Status |
---|---|---|
01-FEB | 100 | Planned |
08-FEB | 200 | MRP firm planned |
15-FEB | 300 | Planned |
And the following MDS is used to plan the MRP using None in the Overwrite field and No in the Append Planned Orders field:
Schedule Date | Quantity |
---|---|
02-FEB | 110 |
09-FEB | 220 |
16-FEB | 330 |
The resulting MRP would have the following suggestions for planned orders:
Schedule Date | Quantity | Order Status |
---|---|---|
08-FEB | 200 | MRP firm planned |
The reason the additional demand from 02-FEB, 09-FEB, and 16-FEB was not planned for is because with the Overwrite None and Do Not Append Planned Orders, you choose not to overwrite firm planned orders nor create new planned orders to meet additional demand. In this case, the projected quantity on hand would go negative since no planned orders were suggested to meet the additional demand. The material planner can use online inquiries and reports with exception messages to identify material shortages.
In ASCP, planning decision-making occurs sequentially in the following phases:
Selection of alternates (routings, substitute components, internal source organizations, suppliers).
Note: Intelligent selection of alternates occurs in constrained plans with decision rules enabled or in optimized plans only. Constrained without decision rules enabled and unconstrained plans choose only the primary alternative (for example, the primary routing) and always respect the sourcing rank and percentages specified in sourcing rules.
Pegging of supplies (on-hands, scheduled receipts, and planned order supplies) to demands
Detailed scheduling of individual operation steps on resources
Note: This phase is enabled only if the Constrained Plan checkbox in the Constraints tab of the Plan Options form is checked
In the detailed scheduling phase, demand quantities that are pegged to planned order supplies are considered in internal priority order. Demands with higher internal priority get the first opportunities to take up available resource and material capacities; demands with lower internal priorities can only use remaining resource and material capacities and are therefore more likely to be satisfied late.
Oracle does not recommend driving a plan using both a master demand schedule and forecasts and sales orders directly. In such plans, the planning engine does not maintain demand priorities across these entities.
The internal priorities described above are different than the external priorities that can be attached to sales orders and master demand schedule entries. Internal priorities are generated for a plan on the basis of a priority rule that you attach to the plan in the Main tab of the Plan Options form.
Sign on using the Advanced Supply Chain Planner responsibility.
From the Navigator, select Setup > Priority Rules.
The Define Priority Rules window appears.
Use the information in the following table to fill in the fields in this form.
Field | Description |
---|---|
Name | Enter a name for your priority rule. You will refer to this name when defining plan options for a supply chain plan. |
Description | Enter a description for your priority rule. The description is for your personal reference only, and is not used elsewhere in ASCP. |
Enabled | Check this box to allow this priority rule to be attached to an ASCP plan. |
Default | Check this box to make this priority rule the default priority rule on the ASCP planning server. |
Criteria Name | Valid values are: Gross Margin, Promise Date, Request Date, Sales Orders and MDS Entries Priority, and Schedule Date. Select the criteria that you wish to evaluate each demand by when ASCP generates the internal priority for the demand. For example, if you select Sales Orders and MDS Entries Priority, then the demand entry that has the most urgent external priority (as specified on the sales order line or on the MDS entry) will receive an internal priority of 1, the demand with the next most urgent external priority will receive an internal priority of 2, and so forth. If you choose multiple criteria, each criterion will be used to break ties in the criteria that preceded it. In the screenshot example, if two sales order demands both have a priority of 1, the most urgent internal priority will be assigned to the sales order with the earliest Schedule Date (due date). If multiple demands tie on all criteria specified in the priority rule, then the tie is broken arbitrarily and the demands are assigned consecutive internal priority values. |
Criteria Order | This field is populated automatically. It numbers the criteria that you choose above sequentially, starting with 1, 2, ... |
Enter the priority rule name in the Demand Priority Rule field in the Main tab of the Plan Options form. Please see the section The Main Tabbed Region for further details.
By using the priority rule shown in the screenshot above, you ensure that the demands with the most urgent external priority will have the best chance of being satisfied on time, since they will have the first opportunity to utilize available resource and material capacities.
The planning engine uses this hierarchy to determine the priority rule:
Plan priority rule: Plan options form > Main tabbed region
Default priority rule: Priority rules form
Schedule Date: Prioritizes the demands in due date order
The planning engine allocates firm and nonfirm supplies to demands during the pegging process.
The planning engine pegs in different ways depending on settings that you choose, see the Pegging Overview section in Supply/Demand Window.
Oracle Advanced Supply Chain Planning allows you to plan supplies or consume forecasts based on the sales order line request dates, promise dates, or schedule dates. This helps you to honor as well as improve your delivery commitments.
Depending on the condition that your organization needs to meet, you can plan based on one of the following dates:
Plan to request date - If you want to meet a more aggressive set of dates compared to the ones initially scheduled by Oracle Global Order Promising. You can use this option when you have many alternate bills of materials (BOMs) / routings or alternate facilities. Since, Oracle Global Order Promising does not take into account these alternates, it often provides conservative schedule dates in these situations. In this scenario, you can use Oracle Advanced Supply Chain Planning's constrained, decision rule-based, or cost-optimized plans to arrive at better schedule dates.
Plan to promise date - If you want to meet dates communicated to customers and ignore any schedule date overrides. By comparing the resulting demand satisfied dates with the demand schedule dates, you can validate manual schedule date overrides made since the previous customer communication.
Plan to schedule date - If you want to meet demand dates as suggested by Oracle Global Order Promising and adhere to manually overridden dates.
From the Navigator, choose Supply Chain Plans > Plan Options.
The Plan Options window appears. The Main tab is displayed by default.
In the Schedule By box, select the type of sales order line date that you want to consider for your planning:
Schedule Ship Date (default)
Schedule Arrival Date
Request Ship Date
Request Arrival Date
Promise Ship Date
Promise Arrival Date
For more details on the Plan Options window, see Setting Plan Options.
Note: If no priority rule is specified in the Define Priority Rules form, then the planning engine considers a demand priority rule based on the option specified (or defaulted) in the Schedule By box of the Plan Options window.
You can consider either the arrival or the ship date of the demand to be the due date. The planning engine calculates the ship and arrival dates as following:
The planning engine calculates the schedule ship date or arrival date based on the date specified on the sales order line. If the schedule arrival date is specified on the sales order line, then the planning engine calculates the schedule ship date by offsetting the schedule arrival date by the intransit time.
For example:
If the Schedule Arrival Date is specified as Day 11 and the intransit time is 2 days, then the planning engine calculates the Schedule Ship Date as Day 9.
The planning engine calculates the corresponding ship dates or the arrival dates for the order request dates or the order promise dates with respect to the customer level attribute Request Date Type specified in Customers > Order Management tab.
If the Request Date Type is:
Arrival - The ship dates are calculated by offsetting the arrival dates by the intransit time
For example:
If the Request Arrival Date is Day 12 and the intransit time is 2 days, then the planning engine calculates the Request Ship date as Day 10.
Ship - The arrival dates are calculated by adding the intransit time to the ship dates
For example:
If the Request Ship Date is Day 12 and the intransit time is 2 days, the planning engine calculates the Request Arrival Date as Day 14.
Note: The planing engine also takes into account the shipping, receiving and, carrier calendar for calculating the ship and arrival dates. For more details on calendars, see Setting Shipping, Receiving, Carrier, and Supplier Capacity Calendars
Use forecasts to estimate future demand for items using historical, statistical, and intuitive techniques.
The types of multi-organization forecasts are:
Local: Forecasts with a ship from organization associated to them. You create and manage them in an organization in the source instance and that organization is their ship from organization or in Oracle Demand Planning where you specify an organization.
Global: Forecasts with no pre-specified ship from organization associated to them. You create and manage them in Oracle Demand Planning or in Oracle Demantra. See Global Forecasting.
Forecast consumption replaces forecasted demand with actual sales order demand. Each time you create a sales order line, you create actual demand. If the actual demand is already forecasted, the forecast demand must be decremented by the sales order quantity to avoid counting the same demand twice.
For example, this table shows the forecast and sales orders for item 1.
Order Type | Quantity | Date |
---|---|---|
Forecast | 50 | June 1 |
SO1 (sales order 1) | 10 | June 1 |
SO2 | 25 | June 1 |
This table shows the forecast and sales orders for item 1 after forecast consumption.
Order Type | Quantity | Date |
---|---|---|
Forecast | 15 (50 - (10 + 25)) | June 1 |
SO1 | 10 | June 1 |
SO 2 | 25 | June 1 |
Forecast consumption relieves forecast items based on the sales order line schedule date. When an exact date match is found, consumption decrements the forecast entry by the sales order quantity. Other factors that may affect the forecast consumption process are backward and forward consumption days and forecast bucket type.
When you create a new forecast, especially from an external source, you can also apply consumption that has already occurred for other forecasts to the new one.
You control forecast consumption against each component by setting its organization item attribute Forecast control:
Consume: Sales orders for this item consume forecasts for this item in the same organization.
Consume and derive: Sales orders for this item consume forecasts for this item in the same organization. Select this option if you will also do forecast explosion against the item; see Forecast Explosion.
None: Sales orders for this item do not consume forecasts for this item.
Consumption for an item and its corresponding sales order demand only occurs once within a forecast set. For example:
Forecast Set #1 contains Forecast #1 and Forecast #2. The same item, Item A, belongs to both forecasts within the set. Some possible scenarios and how consumption would work are:
If the sales order quantity is less than the forecast quantity of each forecast, only one of the forecasts for Item A is consumed.
If one of the two forecasts for Item A were on the same day as the sales order line schedule date, that forecast would be consumed first.
If the forecast for Item A is for the same day in both forecasts, the forecasts are consumed in alphanumeric order by forecast name.
For example, if each forecast for Item A is for a quantity of 100 and you place sales order demand for 20, the consumption process would decrement only Forecast #1 to 80. However, if the sales order quantity is for 120, Forecast #1 is decremented from
100 to zero and Forecast #2 is decremented from 100 to 80.
Forecasts can be created and maintained at the product family level, and exploded down to the members of the family based on the planning percentages and effectivity dates in the bill of materials. Forecast consumption depends on the Forecast Control item attribute: if Forecast Control for the product family item is set to Consume and at all levels below that to Consume and Derive, a sales order added for member items consumes its own forecast and the forecast for the product family. For example:
Suppose that the planning percentages for the member items are:
60% for B
40% for C
Also assume a product-family forecast for A of 100.
After forecast explosion, a sales order of 20 for item B consumes the forecast, leaving the following forecast:
100 20 = 80 for A
60 20 = 40 for B
40 0 = 40 for C
Similarly, if item B is a model and if Forecast Control for both D and E is set to Consume and Derive, then the forecast for item D gets consumed by 20 and the forecast for item E gets consumed by 20. The forecasts for items F and G remain the same.
Consumption can occur multiple times if an item appears in more than one forecast set. For example:
Forecast Set #1 contains Forecast #1 and Forecast Set #2 contains Forecast #2. The same item, Item A, belongs to both forecasts within each set.
When you create a sales order, both forecasts for Item A in Forecast Set #1 and Forecast Set #2 are consumed. This is because consumption occurs against each forecast set, and Item A exists in both forecast sets.
For example, if each forecast for Item A is quantity 100 and you place sales order demand for 20, the consumption process would decrement each forecast in each set from 100 to 80.
Note: In this example, Forecast Set #1 and Forecast Set #2 are most likely alternative scenarios two different sets for comparison purposes, so that consumption occurs for the same item in both sets. If you want to consume an item only once, define all forecasts for an item within a single set.
You can specify consumption levels in the forecast set:
Item level: Consumption occurs when item numbers match between the forecast entry and the sales order line.
Customer Level: Consumption occurs when item numbers and customer numbers match between the forecast entry and the sales order line.
Ship-to level: Consumption occurs when item numbers, customer numbers, and customer ship-to addresses match between the forecast entry and the sales order line
Bill-to level: Consumption occurs when item numbers, customer numbers, and customer bill-to addresses match between the forecast entry and the sales order line
Use consumption days if:
You do not always have an exact match between the sales order line schedule dates and forecast entry dates.
Your forecast entry quantity is not always sufficient to cover the sales order quantities.
Forecast consumption works as follows:
It searches backward from the sales order line schedule date, workday by workday, for forecast quantities to consume.
If that search is not successful in consuming the entire sales order line quantity, it searches forward from the sales order line schedule date, workday by workday, for forecast quantities to consume.
If that search is not successful in consuming the entire sales order line quantity, it creates an overconsumption (negative demand) entry on the sales order line schedule date.
You can assign a demand class to a forecast. When you create a sales order with a demand class, consumption searches for forecasts that have the same demand class. Consumption attempts to consume these forecasts first. If it does not find matching entries, it tries to consume forecasts that do not have a demand class.
For sales orders without an associated demand class, consumption attempts to consume forecasts that match the default demand class for the organization first, and then consumes forecast entries that have no demand class defined.
When consumption cannot find an appropriate forecast entry to consume, it creates, for information purposes only, a new forecast entry at the forecast set level. This entry has a zero original quantity and a negative current quantity equal to the unconsumed demand.
The entry is marked with an origination of overconsumption.
This controls the effects of abnormal demand with a maximum percent of the original quantity forecast that a single sales order can consume.
Example
You have several customers. Each typically orders 100 units in a given period. One of the customers is having a special promotion that could increase demand significantly. Use the outlier update percentage to ensure that these "one time" sales orders do not overconsume the forecast.
In the above example, daily forecast exists for 20 on the 2nd and the 9th with an outlier update percent of 50 on each forecast. When you place sales order demand for 50 on the 9th, the forecast consumption process attempts to consume on the sales order line schedule date only, since the forecast is stated in daily buckets and no backward consumption days exist. Because an outlier update percent of 50 exists on the forecast, the consumption process consumes only 50% of the forecast. The outlier update percent applies to how much of the original forecast quantity, not the sales order, the consumption process can consume. In this example, the consumption process consumes 50% of the forecast
(10) and the rest of the sales order quantity (40) is overconsumed. If there were a backward consumption days of 5, 50% of the forecast on the 2nd would also be consumed, and the overconsumed quantity would be 30.
Using the same example, if another sales order for 50 is placed on the 9th, it consumes 50% of the original forecast quantity (10) and the current forecast quantity on the 9th becomes zero. Overconsumption is increased by an additional 40 to a new total on the 9th (80).
The process tries to consume a forecast entry on the 12th (the sales order date) because the forecast is stated in daily buckets and no backward consumption days exist. Since there are no forecasts on the 12th, an overconsumption entry is created on the 12th and the forecasts remain the same.
Here, the process tries to consume a forecast entry between the 12th (the sales order date) and the 9th (backward 3 days). The forecast entry of 20 each on the 9th is consumed. The remaining sales order quantity of 5 creates an overconsumption entry.
In this example, the process tries to consume a forecast entry between the 2nd (back 3 days from the sales order date of the 5th) and the 10th (forward 3 workdays, skipping the weekend). Going backward, the forecast entry of 20 each on the 2nd is consumed. Going forward, the forecast entry of 20 on the 9th is reduced to 15 each.
In the above example, weekly forecasts exists for 20 on the 2nd and the 9th. When you place sales order demand for 25 on the 12th, the forecast consumption process attempts to consume in the week of the sales order only, since the forecast is stated in weekly buckets and no backward consumption days exist. Since there is a forecast in the week of the 12th, the entire forecast of 20 is consumed by the sales order for
25 and the remainder of the sales order becomes an overconsumption of 5 on the sales order line schedule date.
In the above example, weekly forecasts exists for 20 on the 2nd and the 9th. When you place sales order demand for 25 on the 12th, the forecast consumption process attempts to consume in the week of the sales order first and then backwards for the number of backward consumption days.
In this example, the backward consumption days of 5 causes the consumption process to go into another weekly bucket where it also consumes anything from that week. Since there is a forecast in the week of the 12th, the sales order for 25 consumes the entire forecast of 20 and then consumes the remainder of the sales order quantity (5) from the forecast on the 2nd.
Note: When you use weekly or periodic buckets and the consumption days carry the consumption process into a different week or period, the consumption process consumes from anywhere in the week or period, regardless of whether the consumption days span the entire week or period.
In this example, the process subtracts the backward consumption days from the 12th (excluding non-workdays) to day 5. Since day 5 is in the previous week, it consumes forecasts anywhere within the bucket; in this case, on the 2nd.
The consumption process consumes any forecasts that are included in the time fence created by the backward or forward consumption days, and then any other forecasts that are in the week or period. However, it does not consume a daily forecast that exists in the week or period if it is not covered by the time fence. In the above example, a daily forecast for the same item on the 4th would not have been consumed by the sales order; however, a daily forecast on the 5th would have since it is in the period included in the backward consumption days.
In the above example, a periodic forecast exists for 20 on the 2nd, the first day of the period. When you place sales order demand for 25 on the 12th (assuming it is in the same period), the forecast consumption process attempts to consume in the period of the sales order only, since the forecast is stated in periodic buckets and no backward consumption days exist. Since there is a forecast in the period starting on the 2nd, the entire forecast of 20 is consumed by the sales order for 25 and the remainder of the sales order becomes an overconsumption of 5.
In the above example, a periodic forecast exists for 20 on the 2nd, the first day of the period. When you place sales order demand for 25 on the 12th (assuming it is in the same period), the forecast consumption process attempts to consume in the period of the sales order line schedule date first and then backwards for the number of backward consumption days.
In this example, the backward consumption days does not cause the consumption process to go into another periodic bucket. It behaves the same as if there were no backward consumption days. Since there is a forecast in the period of the 2nd, the sales order for 25 consumes, and the remainder of the sales order becomes an overconsumption of 5 on the 12th. However, if the backward consumption days are large enough to carry forecast consumption into the previous period, forecast consumption can consume any forecasts in that period also.
Note: When you have a mix of daily, weekly, and periodic forecast entries, forecast consumption first consumes the daily entries, then the weekly entries, and lastly the periodic forecast entries that are included in the time fence created by the backward and/or forward consumption days.
Consume forecasts either:
In the source instance (local only): Use this option if you want to view the forecast consumption results in the source instance independent of their use in a plan run.
You consume the forecasts during the MDS Load concurrent process. To use the consumed forecasts in an Oracle Advanced Planning and Scheduling plan, collect them.
During the Oracle Advanced Supply Chain Planning plan run (local and global): Use this option if you want to view the forecast consumption results in the destination instance as an output of the planning run.
Collect unconsumed forecasts and use them to drive a plan.
In both cases, the method of forecast consumption is the same.
The planning engine can perform inline forecast consumption for source instance forecasts, Oracle Demand Planning forecasts and Oracle Demantra forecasts in the same plan run.
If you drive a supply chain plan by an Oracle Demand Planning or Oracle Demantra, or a source instance forecast instead of a source instance master demand schedule, the planning process consumes the forecast.
Among the forecast modification methods, the planning engine performs them in this order:
Forecast spreading
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is No. The planning engine neither considers forecast entries within the demand time fence as demand nor uses them for forecast consumption
Forecast consumption
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is Yes. The planning engine does not consider forecast entries within the demand time fence as demand but it uses them for forecast consumption
Forecast bucket consumption
Since you cannot specify these features in Oracle Demand Planning, you cannot use them if you collect forecast sets and forecasts from Oracle Demand Planning to the destination instance. However, you can use a variation of forecast consumption days.
To use these features with forecast sets and forecasts from Oracle Demand Planning:
Specify these features in the source instance forecast sets and forecasts
Publish the Oracle Demand Planning scenario to the source as a forecast set/forecast
Collect the source instance forecast sets and forecasts to the destination instance and run the plan
If all the forecast sets that you want to use in an Oracle Advanced Supply Chain Planning plan run have the same backward and forward consumption days, you can collect forecast sets and forecasts from Oracle Demand Planning to the destination instance and apply this feature when you run the Oracle Advanced Supply Chain Planning plan.
If the forecast sets that you want to use in an Oracle Advanced Supply Chain Planning plan run need different backward and forward consumption days, set them in the source instance forecast sets.
You can specify demand class in the forecast entry; if there is no forecast entry demand class the forecast consumption process uses the forecast entry's organization demand class.
You can specify demand class in the sales order line; if there is no sales order line demand class the forecast consumption process uses the sales order line's organization warehouse demand class.
If you consume by demand class and have forecasts without demand classes, set profile option MSC: Consume forecast with No demand class.
Since the sales orders that you collect affect the results of inline forecast consumption, consider the sales orders that you collect.
To collect past due sales order demand, set the profile option MSC: Sales Orders Offset Days. It specifies the number of days before the day that you run the collection engine that it is to collect shipped sales order lines. For example, if you set this option to 5 and collect today, the collection engine collects shipped sales order lines starting from 5 days before today. The default for this option is 99999.
The collection engine collects partially- or non-shipped sales orders regardless of this profile option.
You control forecast consumption against each component by setting its organization item attribute Forecast control:
Consume: Sales orders for this item consume forecasts for this item in the same organization.
Consume and derive: Sales orders for this item consume forecasts for this item in the same organization. Select this option if you will also do forecast explosion against the item; see Forecast Explosion.
None: Sales orders for this item do not consume forecasts for this item.
Set up the following in the Plan Options window:
In the Demand Schedule region of the Organization tab, specify the appropriate forecast sets.
In the Organizations region of the Organization tab, select Include Sales Order.
If you are using forecasts collected directly from Oracle Demand Planning, specify Forecast Consumption Backward Days and Forecast Consumption Forward Days. The planning engine applies this window to all Oracle Demand Planning forecasts driving the plan
If you want to specify this window for each Oracle Demand Planning forecast set, use the process in Forecast Consumption Features.
The forecast consumption process occurs in the snapshot phase. When you launch a plan, select Launch Snapshot (the default).
If an item does not have a demand time fence, the planning engine performs consumption across the planning horizon and uses the consumed forecast entries across the planning horizon in the gross-to net-explosion.
If an item has a demand time fence, the planning engine checks the profile option MSC: Consume forecast within demand time fence and does the following depending on its value:
If the value is No, the planning engine applies the demand time fence to the item, drops forecast entries within the demand time fence, and performs consumption outside the demand time fence if the forward consumption days value represents more days than the demand time fence. It uses the consumed forecast entries outside the demand time fence in the gross-to net explosion.
If the value is Yes, the planning engine performs consumption across the planning horizon and then applies the demand time fence to the item. It drops the forecast entries inside the demand time fence and uses the forecast entries outside the demand time fence in the gross-to net explosion.
Per the above process, the planning engine attends to the actual past-due forecast entries. However, to view their consumption, check the Day 0 forecast bucket.
The following diagram shows a consumption scenario for item A which has a demand time fence:
There is a sales order line for 100 units due between the anchor date and the demand time fence date.
There is a forecast entry for 40 units past due, two forecast entries for 60 units between the anchor date and the demand time fence date, and a forecast entry for 100 outside the demand time fence. The forward consumption days represents more days than the demand time fence.
Consumption scenario
The planning engine checks the profile option MSC: Consume forecast within demand time fence and does the following depending on its value:
If the value is No, the planning engine drops the past due forecast and the two forecast entries between the anchor date and the demand time fence date and uses the sales order for 100 to consume the forecast entry for 100 which is outside the demand time fence.
It uses that consumed forecast entry in the gross-to-net explosion.
This diagram shows the results of the No profile option using the previous example:
Profile option setting
If the value is Yes, the planning engine uses the sales order for 100 to consume the forecast entry for 40 which is past due and to consume one forecast entry for 60 between the anchor date and the demand time fence date.
It does not use the two consumed forecast entries in the gross-to-net explosion. The other forecast between the anchor date and the demand time fence date is not consumed and not used in the gross-to-net explosion. The forecast entry outside the demand time fence is not consumed but used in the gross-to-net explosion.
This diagram shows the results of the Yes profile option using the previous example:
Profile Option setting
View forecast consumption in the Planner Workbench.
Navigate to the Planner Workbench.
Select the plan name, organization, and item.
Right click on the item and select either Demand or Supply/Demand.
If you want to see which sales order lines consumed a forecast entry, select any entry with Forecast order type, right click the forecast name, and select Consumption Details.
If you want to see which forecast entries a sales order line consumed, select any entry with order type Sales Order, right click the sales order name, and select Consumption Details.
For example, to see the consumption details for the forecast from a previous example, select the forecast and right-click. Choose Consumption Details from the list that appears. This table illustrates the information that displays:
Forecast Qty | Forecast Date | Consumed Qty | Sales Order Date | Sales Order Number |
---|---|---|---|---|
50 | June 1 | 10 | June 1 | SO1 |
50 | June 1 | 25 | June 1 | SO2 |
To see how sales order 1 (SO1) from the previous example is consuming forecasts, select sales order 1 and right-click. Choose Consumption Details from the list that appears. This table illustrates the information that displays:
Forecast Qty | Forecast Date | Consumed Qty | Sales Order Date | Sales Order Number |
---|---|---|---|---|
50 | June 1 | 10 | June 1 | SO1 |
Use the following profile options to instruct the planning engine how to use shipment date, timestamp, and forecast due date to plan supplies:
You can set the profile option MSO: Use Default for Sales Orders to specify the timestamp for sales orders. For example, if you specify the value Beginning of Day, all sales orders have the timestamp 00:00. If you specify End of Day, the planning engine considers all sales orders due by 23:59. For more information about the profile option, see MSO Profile Options.
Set the profile option MSO: Default Timestamp Forecasts to specify the time when the planning engine should consider a forecast due. For more information about the profile option, see MSO Profile Options.
You can set the profile option MSO: Late Demands Exceptions Tolerance Minutes to specify the tolerance limit for late replenishments. The planning engine raises exceptions only after the tolerance limit is overstepped. For example, if you specify 1440 minutes as the tolerance for a demand due at 12:00 on Tuesday, the planning engine does not raise an exception until 12:00 on Wednesday. For more information about the profile option, see MSO Profile Options.
This timestamp behavior is not applicable to Availability to Promise (ATP) or Global Order Processing (GOP). As unconstrained plans use the smallest planning bucket (daily bucket), this profile option does not affect the scheduling behavior for supplies that are scheduled at 00:00.
You can instruct the planning engine to consume forecasts with sales orders only within the same time bucket (within the consumption bucket).
For each forecast, the consumption bucket is the same length as the forecast bucket. The consumption process consumes inside the consumption buckets going backward and then forward. It ends when either there are no more:
Unconsumed forecasts in the consumption bucket
Sales orders within the consumption bucket to consume forecasts
The consumption process does not search outside of the consumption bucket for forecasts and sales orders except in daily buckets. If you do not want the planning engine to use backward and forward consumption in daily buckets:
For Oracle Demand Planning forecasts, navigate to the Plan Options form, Main tabbed region; set Backward Days and Forward Days to zero.
For Oracle Advanced Supply Chain Planning and Oracle Demantra forecasts, navigate to the Forecasts form; set Backward Days and Forward Days to zero.
To use this feature, navigate to the Plan Options form, Main tabbed region; select Consume by Forecast Bucket. If you do not want to use this feature, select Consume Using Backward/Forward Days.
For example, you:
Enter forecast 1 with five forecast entries of quantity 100 to cover weeks 25 May - 31 May, 1 June - 7 June, 8 June - 14 June, 15 June - 21 June, and 22 June - 28 June
Enter forecast 2 with one forecast entry for quantity 200 to cover week 25 May - 31 May and one forecast for quantity 1500 to cover 1 June - 28 June.
Receive a sales order for quantity 150 due on 10 June.
Select plan option Consume by Forecast Bucket.
This table shows the results of the forecast consumption against forecast 1. The sales order consumes only the forecast entry in week 8 June - 14 June and does not consume from any other weekly entries. Since the planning engine cannot consume the entire sales order quantity from forecast 1, it looks for other forecasts with entries that cover 10 June.
Data or Calculation | 25 May - 31 May | 1 June - 7 June | 8 June - 14 June | 15 June - 21 June | 22 June - 28 June |
---|---|---|---|---|---|
Forecast 1 original quantity | 100 | 100 | 100 | 100 | 100 |
Sales order quantity | 0 | 0 | 150 | 0 | 0 |
Forecast 1 consumed quantity | 0 | 0 | 100 | 0 | 0 |
The planning engine finds forecast 2 with entries that cover 10 June. This table shows the results of the forecast consumption against forecast 2. The sales order consumes only the forecast entry in period 1 June - 28 June. If it could not consume the entire quantity fro the period, it would not consume from the forecast entry in week 25 May - 31 May.
Data or Calculation | 25 May - 31 May | 1 June - 28 June |
---|---|---|
Forecast 2 original quantity | 200 | 1500 |
Sales order remaining quantity | 0 | 50 |
Forecast 1 quantity | 0 | 50 |
You can see the backward and forward consumption days that apply to a forecast in the Planner Workbench, Demand window. See fields Consumption Backward Days and Consumption Forward Days.
Among the forecast modification methods, the planning engine performs them in this order:
Forecast spreading
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is No. The planning engine neither considers forecast entries within the demand time fence as demand nor uses them for forecast consumption
Forecast consumption
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is Yes. The planning engine does not consider forecast entries within the demand time fence as demand but it uses them for forecast consumption
Forecast bucket consumption
If you develop and maintain your Oracle Demand Planning forecasts in aggregate (week, month, or quarter), you can:
Use those forecasts in Oracle Advanced Supply Chain Planning
Instruct the planning engine to spread this aggregate forecast demand evenly across the daily buckets. It spreads according to the value of profile option MSC: Forecast Spreading Calendar.
Planning forecast demand in daily buckets may provide a more realistic estimate of the future supply but forecasting in aggregate may lead to more accurate forecasts.
Bucketing behaves as follows:
If you select plan option Spread Forecasts Evenly , the planning engine first allocates forecasts from the forecasting buckets down to the planning buckets
The consumption of these forecasts is dependent on the setting of flag Consume by Forecast Bucket
If you select Consume by Forecast Bucket, sales orders that fall within a forecast bucket can only consume the forecasts in that bucket. They cannot consume forecasts in the previous or the next forecast buckets
If you clear Consume by Forecast Bucket, sales orders consume forecasts based on the setting of plan options Backward Days and Forward Days. Sales orders within a forecast bucket can consume forecasts in the previous or the next forecast buckets
Among the forecast modification methods, the planning engine performs them in this order:
Forecast spreading
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is No. The planning engine neither considers forecast entries within the demand time fence as demand nor uses them for forecast consumption
Forecast consumption
Demand time fence control if profile option MSC: Consume Forecast Inside Demand Time Fence is Yes. The planning engine does not consider forecast entries within the demand time fence as demand but it uses them for forecast consumption.
Forecast bucketing consumption: Aggregates consumed forecasts and sales orders to planning buckets.
The forecast spreading process interacts with profile option MSC: Consume Forecast Inside Demand Time Fence as follows:
If it is No, the planning engine neither considers forecast entries within the demand time fence as demand nor uses them for forecast consumption. It drops them as demand before forecast consumption
If it is Yes, the planning engine does forecast consumption before it does demand time fence control. It does not consider forecast entries within the demand time fence as demand but it uses them for forecast consumption.
For a periodic forecast entry that falls in weekly planning buckets within the demand time fence, the process spreads the entries into daily entries.
If a daily entry is within the demand time fence, the process ignores the actual profile option value and proceeds as if the value is Yes.
If the daily entry is outside the demand time fence, the process ignores the profile option and consumes against the entry
To use this feature, set the following information:
Use only week or period forecast buckets in Oracle Demand Planning.
If you are publishing forecasts from Oracle Demand Planning, set planning parameter Include Past Due Forecast. Enter the number of days of past due forecasts to include in plans. No value indicates include all past due forecasts; zero indicates include no past due forecasts. This value does not apply to independent demands derived from assemble-to-order models.
If you are publishing master demand schedules and sales orders from Oracle Demand Planning, set Oracle Advanced Supply Chain Planning profile option Include MDS Days.
Navigate to the Plan Options form, Main tabbed region; select Spread Forecast Evenly.
Oracle Inventory Optimization always spreads forecasts into planning buckets.
Forecast Spreading Example
This diagram shows a forecast spreading example:
You entered forecasts of quantity 100 for the weeks of 13 March, 20 March, 27 March, 3 April, 10 April, and 17 April. Each week begins on Thursday.
The planning buckets are five days, two weeks, and one period.
The workdays are Monday through Friday and there is a holiday on Tuesday 1 April.
You set plan parameter Include Past Due Forecast to 0 and selected plan option Spread Forecast Evenly.
The planning engine spreads each weekly forecast of quantity 100 for the weeks beginning 13 March and 20 March to five daily forecasts of quantity 20.
The planning engine spreads the weekly forecast of quantity 100 for the week beginning 27 March to four daily forecasts of quantity 25.
The planning engine does not spread forecasts that map to planning horizon periods.
The planning engine plans to no forecast demand on planning daily buckets 10 March, 11 March, and 12 March. It plans to forecast demand of 20 on daily buckets 13 March and 14 March.
The planning engine plans for forecast demand of 100 on planning weekly bucket 17 March to 23 March (20 + 20 + 20 + 20 + 20).
The planning engine plans for forecast demand of 110 on planning weekly bucket 24 March to 30 March (20 + 20 + 20 + 25 + 25).
The planning engine plans for forecast demand of 350 on planning monthly bucket 31 March to 4 May (25 + 25 +100 + 100 + 100).
Forecast Spreading Example
If you set outlier percentage for a forecast set, the planning engine applies it to the forecasts after it spreads them.
If a forecast entry from Oracle Demand Planning falls on a non-workday in Oracle Advanced Supply Chain Planning, the planning engine places the forecast entry on the previous working day.
This table shows an example of workday forecast recalculation. . Oracle Advanced Supply Planning manufacturing calendar workdays are Monday to Friday, the planning horizon is ten workdays in daily buckets, and the plan run date is 10 June.
The shipping calendar that Oracle Demand Planning uses has all working days.
It has daily forecasts for seven days beginning on Monday 10 June.
The manufacturing calendar that the production organization uses has non-workdays on Saturday and Sunday.
The forecast spreading process places the forecasts for Saturday and Sunday on Friday
Date | Oracle Demand Planning Forecast Quantity | Oracle Advanced Supply Chain Planning Forecast Quantity |
---|---|---|
Monday 10 June | 9 | 9 |
Tuesday 11 June | 13 | 13 |
Wednesday 12 June | 10 | 10 |
Thursday 13 June | 7 | 7 |
Friday 14 June | 10 | 30 (10 + 10 + 10) |
Saturday 15 June (non-workday in manufacturing calendar) | 10 | - |
Sunday 16 June (non-workday in manufacturing calendar) | 10 | - |
For items under rounding control, the planning engine rounds a spread forecast quantity up and applies its cumulative remainder to the next bucket. It uses the item-organization item attribute. This table shows how the planning engine spreads a weekly forecast of quantity 36 for an item with item attribute Rounding Control selected.
This table shows an example of forecast spreading with rounding control:
The planning engine rounds the Monday forecast of 7.2 up to 8.
It calculates the Monday cumulative remainder as the difference between the two quantities which is - 0.8 (7.2 - 8).
It applies the cumulative remainder of the Monday forecast to the Tuesday daily forecast quantity to adjust it to 6.4. (7.2 - 0.8).
It rounds the Tuesday Forecast of 6.4 up to 7.
Data or Calculation | Monday | Tuesday | Wednesday | Thursday | Friday |
---|---|---|---|---|---|
Daily forecast before rounding | 7.2 (36 / 5) | 7.2 (36 / 5) | 7.2 (36 / 5) | 7.2 (36 / 5) | 7.2 (36 / 5) |
Daily forecast before rounding + Cumulative remainder | 7.2 (7.2 + 0) | 6.4 (7.2 - 0.8) | 6.6 (7.2 - 0.6) | 6.8 (7.2 - 0.4) | 7 (7.2 - 0.2) |
Daily forecast after rounding | 8 | 7 | 7 | 7 | 7 |
Cumulative remainder | -0.8 (7.2 - 8) | -0.6 (6.4 - 7) | -0.4 (6.6 - 7) | -0.2 (6.8 - 7) | 0 |
If the Oracle Demand Planning Forecast has decimal quantities, the rounded Oracle Advanced Supply Chain Planning forecasts may have decimal quantities.
Advanced Forecast Spreading Examples
This diagram shows an example of forecast spreading with backward and forward consumption days. In this example:
The forecast for this item is in weekly buckets.
The planning buckets are ten days and two weeks.
Both Backward Days and Forward Days are 3.
The forecast spreading process spreads the weekly forecast quantities for weeks 1 and 2 in to daily buckets to match the planning buckets.
The forecast consumption consumes these forecast quantities with these sales orders:
D1 and D2 with S1
D3 and D4 with S2
D5, D6, D7, D8 with S3
D8 and D9 with S4
D8, D9, and D10 with S5
Week 2 with S6
Week 2 with S7
Total Demand (after bucketing) for D5 is zero for consumption method using the Consume Using Backward/Forward Days method and 20 using the Consume by Forecast Bucket method.
Forecast Spreading with Backward and Forward Consumption Days
This diagram shows forecast spreading demand calculations in the order of their processing:
Forecast spreading
Forecast consumption
Forecast bucketing
Demand time fence
The parameters are:
Forecast Allocation: Spread Forecast Evenly
Forecast Consumption: Consume by Forecast Bucket
Demand Time Fence: 2 days
Include Past Due Forecast Days: 6 days
Planning Buckets: 5 days, 2 weeks
The process buckets past due:
Sales orders on days D -5, D -4, and D -1 into bucket D0
Forecasts on days D -3 and D -5 into bucket D0
Forecast Spreading Demand Calculations
You can define and maintain forecasts for any item, at any level on your bills of material. Forecast explosion is a process that creates forecasts for components from the forecasts of their parents. It occurs in the following situations:
Product family forecasts to product family member item forecasts. The planning engine considers these exploded forecasts as independent demand and uses pegging to link then to their product family forecast.
Model forecasts to other model, option class, option item, and included item forecasts. See Configure to Order Forecast Explosion.
Forecasting Planning Bills of Material
In Oracle Bills of Material, you can define multilevel planning bills, with multiple levels of planning items, to represent groups of related products that you want to forecast by family.
Typically, you can order components of a planning bill, but not the planning item itself. The planning item is an artificial grouping of products that helps you to improve the accuracy of your forecasting since, generally, the higher the level of aggregation, the more accurate the forecast.
Before you can perform forecast explosion, set up planning percentages in the product family and model bills of material. Planning percentage is the percent of the parent forecast that is attributable to the component. For example:
In a product family bill of material, product family member item A has planning percentage 30%, product family member item B has planning percentage 50%, and 5-56 product family member item C has planning percentage 20%.
A product family forecast entry has quantity 1000
After forecast explosion, the forecast quantity for product family member item A is 300, for product family member item B is 500, and for product family member item C is 200.
See Creating a Bill of Material, Oracle Bills of Material User's Guide and attend to tab Component Details, field Planning %.
The following table illustrates a planning bill for Training Computer, a planning item that represents a planning bill for three types of computers: laptop, desktop, and server. The planning percent assigned to each member of the planning bill represents anticipated future demand for each product.
Level | Item | BOM Item Type | Planning % |
---|---|---|---|
1 | Training Computer | Planning | - |
. 2 | . Laptop Computer | Model | 60% |
. 2 | . Desktop Computer | Model | 20% |
. 2 | . Server Computer | Model | 20% |
The following table illustrates forecast explosion, via the planning bill described in the previous table, for a forecast of 100 Training Computers. The table also illustrates forecast consumption after you place sales order demand for 20 Laptop Computers. Original forecast shows forecast quantities before forecast consumption. Current forecast shows forecast quantities after consumption by sales order demand.
Level | Item | Original Forecast | Current Forecast |
---|---|---|---|
1 | Training Computer | 100 | 100 |
. 2 | . Laptop Computer | 60 | 40 |
. 2 | . Desktop Computer | 20 | 20 |
. 2 | . Server Computer | 20 | 20 |
The planning percentages of all of the components of a parent can add to more than 100%.
You control forecast explosion to each component by setting its organization item attribute Forecast control:
Consume: There is no planning engine forecast explosion to this component.
Consume and derive: There can be planning engine forecast explosion for models depending on plan option Explode Forecast. The planning engine does not explode multi-organization models.
None: There can be planning engine forecast explosion for product families depending on plan option Explode Forecast.
For information about forecast explosion for model forecasts, see Configure to Order Forecast Explosion.
The forecast explosion process can round the member item forecasts after explosion of the product family forecast. Use this rounding if you find that, because of fractional member item forecasts, you:
Are creating excess inventory
Experience an increase in pegging records
To use this rounding, set item attribute Round Order Quantity for each member item of a product family.
To perform this rounding, the forecast explosion process:
Selects any member item
Rounds its forecast down to the nearest integer and saves the remainder
Applies (adds to or subtracts from) the remainder to the forecast of the next member item that it selects
Rounds its forecast to the nearest integer and saves the remainder
Continues until it has rounded all member item forecasts
You can explode forecasts in:
The source instance (local only): Then collect the exploded forecasts to the planning server. See Forecast Explosion in Oracle Master Scheduling/MRP and Oracle Supply Chain Planing User's Guide.
Oracle Demand Planning (local and global): Then use the forecasts as demand schedules to a plan run.
Oracle Advanced Supply Chain Planning (local only): During the plan run.
If you have exploded forecasts in the source instance or in Oracle Demand Planning, do not explode them in Oracle Advanced Supply Chain Planning.
Select the Demand Planning System Administrator responsibility.
Navigate to Demand Plans.
Select Calculate dependent demand to explode the forecast at a plan level.
Select the Scenarios tab.
Select Consume in Supply Plan to specify the Demand Planning scenario that needs to be consumed in by Oracle Advanced Supply Chain Planning.
Set Explode Demand Using to:
Global Bill of Material: To select a generic bills of material specified in item validation organization for forecast explosion purposes
Organization specific Bill of Materials: To use the bills of material of a specific organization for forecast explosion purposes
Select Scenarios > Output Levels.
Publish demand plans with organization dimension set to All Organizations
You can pre-explode the forecast using plan option Explode Forecast. This process occurs both for configure to order items and for product family items when the members have item attribute Forecast Control Consume and derive.
If you are using Oracle Demand Planning to explode the forecast, it publishes product family forecasts to Oracle Advanced Supply Chain Panning for the product family and the product family member items. Do not instruct the planning engine to explode forecasts; it will double count the demand for the product family member items.
If Forecast Control is None, Oracle Demand Planning publishes the product family forecast to Oracle Advanced Supply Chain Panning for the product family only. The planning engine disregards plan option Explode Forecast and always performs inline forecast explosion to the product family items based on planning percentages and forecast consumption.
Select the Advanced Supply Chain Planner responsibility.
Navigate to Supply Chain Plan > Plan Options > Main tab.
Select the Explode Forecast check box.
See Oracle Demantra Demand Management User's Guide.
Global forecasts a re forecasts with no pre-specified ship from Organization associated to forecasts. Oracle Advanced Supply Chain Planning supports global forecasting by using Oracle Demand Planning scenarios as global forecasts. The forecasts from Oracle Demand Planning are fed into the planning engine as demand schedules, which can be consumed without any reference to a ship from organization. You can then use sourcing rules to distribute the consumed forecasts and sales orders to appropriate shipping facilities.
Use global forecasting if your business has multiple shipping facilities and you would like to use multiple sources for end items without pre-determining the shipping organizations as you prepare and analyze your forecasts. Local forecasts apply to a shipping facility (inventory organization) while global forecasts apply to your entire business. Since, demand fulfillment is a dynamic process, you should be able to evaluate the current availability of supplies/resources and then come up with a fulfillment organization for the demand.
You can therefore select the demand fulfillment organization to take advantage of current supply conditions and constraints. This helps you in using existing supplies across multiple shipping organizations effectively and making more accurate forecast consumption.
Refer the following figure to understand the global forecasting process supported by Oracle Advanced Supply Chain Planning:
You can consume global forecasts at any of the Ship To entities displayed in the above figure. If you do not specify the consumption level, Oracle Advanced Supply Chain Planning consumes forecasts at the item level. You can then distribute the consumed forecast to multiple organizations using the forecast distribution process.
You can maintain global forecasts with Oracle Demand Planning.
An Oracle Demand Planning scenario is available to Oracle Advanced Supply Chain Planning only if output levels are set as follows:
Mandatory Dimensions
Time: Day, Manufacturing Week, or Manufacturing Period
Organization: Organization
Product: Item or Product Family
Optional Dimension Geography: Ship-to-location or Customer
Note: You cannot create global forecasts in Oracle Master Scheduling/MRP or Oracle Advanced Supply Chain Planning.
You can explode global forecasts either in Oracle Demand Planning or in Oracle Advanced Supply Chain Planning. You cannot explode them in the source instance.
See Forecast Explosion.
Consumption of local forecasts always occurs within a shipping facility.
Consumption of global forecasts occurs without any reference to a shipping facility. In global forecast consumption, sales orders in inventory organizations consume global forecasts with reference to a ship to entity like zone, customer site, demand class. It ignores the source organization on the sales order line and redetermines the source.
The planning engine can consume a global forecast with sales orders having the same ship to entities.
Note: If you have a scenario where a part of the forecast must be met by a specific source, then you need to remove such a source from the sourcing rule of the global forecast distribution. For such items, the planning engine assumes that you will provide an organization specific forecast or a local forecast. Global forecasts are then distributed to the sources that do not include the specific source and the local forecasts are distributed to the specific source.
If you provide a local forecast and global forecasts for the same item, Oracle Advanced Supply Chain Planning consumes both the forecasts.
You need to complete setup steps in the following Oracle products to use global forecasting:
Oracle Inventory
Oracle Bills of Material
Oracle Flow Manufacturing
Oracle Order Management
Oracle Shipping
Oracle Demand Planning
Oracle Advanced Supply Chain Planning
Select the Manufacturing and Distribution Manager responsibility.
Navigate to Inventory > Items > Organization Items > MPS/MRP Planning tab.
Set the Forecast Control item attribute to decide the method for consuming and exploding forecasts:
Consume or None: If you select this option, the planning engine:
Aggregates sales orders based on consumption level
Consumes the top level assembly
Distributes the remaining forecast
Explodes the remaining forecast as part of the bills of material explosion
Consume and Derive - If you select this option, the planning engine:
Aggregates sales orders based on consumption level
Explodes the forecast using Oracle Demand Planning or Oracle Advanced Supply Chain Planning
Consumes the model, option class, and optional items
Distributes the remaining forecast
If you have multi-level/multi-organization assemble-to-order assemblies, identify an organization where you intend to set up generic bills of material for forecast explosion purposes.
Set the profile option MSC: Organization containing generic BOM for forecast explosion based on your selection in step 4.
Specify a generic bills of material for forecast explosion in this organization.
Navigate to Bills of Materials > Bill > Bill.
If you have multi-level/multi-organization assemble-to-order assemblies, define a generic bills of material in the organization, which is specified by the profile MSC:Organization containing generic BOM for forecast explosion.
Navigate to Flow Manufacturing > Products and Parts > Product Family Members.
Define the product family member relationship in the item validation organization.
Navigate to Order Management > Customers > Trading Community > Trading Community > Customers > Standard.
Define Customer site addresses.
Navigate to Shipping > Setup > Regions and Zones > Regions and Zones.
Define Region, Zone or, Customer Zone to cover selected customer site addresses.
Navigate to Shipping > Setup > Regions and Zones > Transit Times.
Set up intransit lead-times between the zone and the shipping organizations.
Navigate to Regions and Zones > Zone tab.
Use the Zone Usage flex field to set the zone usage as Forecast Analysis.
When a sales order maps to multiple zones, then irrespective of the type of zone usage, Oracle Advanced Supply Chain Planning:
Figures out which region within the zone it maps to (if applicable)
Compares the levels of the regions within each of the zones and selects the more specific of the region and the corresponding zone
Checks if the levels of the regions are the same across zones, and retains only 1, which is selected at random
Oracle Advanced Supply Chain Planning applies the methods mentioned above to forecasts as well. When you define a Zone in Oracle Shipping, you have the choice of specifying how the zone will be used in Oracle Advanced Supply Chain Planning. You can specify that either the zone will be used for forecast analysis or for deriving intransit lead-time. There are two possible values for usage: Null and forecast analysis.
When the planning engine tries to distribute the forecasts to internal orgs, it uses Zones with usage set to forecast analysis.
In the process of distributing sales orders to different internal orgs, the distribution process can use Zones with usages set to forecast analysis or, Zones with no usage set or set to Null.
When a sales order maps to a region and a zone, the planning engine selects the intransit lead-time between the region and the customer or global organization.
Change to Demand Planning System Administrator responsibility.
Navigate to Demand plans > Scenarios > Output levels.
Define a demand plan and set the Organization dimension as All Organizations.
Enable the Consume in Supply Plan option.
Select Customer or, Demand Class as the hierarchy in the Geography dimension.
If you want to explode forecasts, select Calculate Dependent Demand.
If you have multi-level/multi-organization assemble-to-order assemblies, select Global Bills of Material to explode forecasts.
Set profile option MSD: Master organization. Set it either to:
The same organization as that in profile option MSC: Organization containing generic BOM for forecast explosion
An organization whose items are a subset of the items in the organization in profile option MSC: Organization containing generic BOM for forecast explosion
Update your sourcing assignment set to include transfer from rules that specify the organization where you want each forecast distributed.
. You also need a sourcing assignment that specifies where the item should be sourced within the organization. For example:
An item-instance rule that specifies all forecasts should be transferred from organizations M1 and M2 with a given planning percentage.
You also need to have make, buy, or transfer rules at the organization-item level that specify where to source these items.
You need to assign sourcing rules at zone level for global forecasting. For more details, see section Sourcing Rules at Region or Zone Level in Oracle Global Order Promising Implementation and User's Guide.
Oracle Advanced Supply Chain Planning supports global forecasting based at zone level and not at customer site level. This also implies that when you use global forecasting at the zone level for example, zone A, it also covers all the customer sites that fall under zone A.
Navigate to Supply Chain Plan > Plan Options > Organizations tab.
In the Global Demand Schedules region, select the names of either global or local (organization specific) demand planning scenarios to drive the plan.
Select one of the following forecast consumption level for the Oracle Demand Planning scenario in Ship to Consumption Level:
Zone: To represent demand from a number of customers who belong to a zone, which is a user specified definition of geography. Zone can be defined using city, postal code, state, and country. You do not get customer specific forecasts when you select this entity.
Customer Zone: To represent user specified definition of geography where multiple customers can be grouped. You can use this option if forecast for a few customers from a zone are known. You can choose to provide forecast at customer zone in addition to zone level forecast.
Customer
Customer Site
Demand Class - To group a demand segment. For example: internet sales, catalog sales
Global (Item)
Your selection depends on the dimension on which the demand planning scenario is published.
Note: The list of values displayed for Ship to Consumption Level changes depending on the published level of the demand planning scenario.
The global forecasting process consumes forecast entries that match the Ship To plan option value.
Publish demand plans with the organization dimension set to All Organizations.
Oracle Demand Planning allows you to publish the forecasts without the context of a ship from location. Oracle Advanced Supply Chain Planning picks up these forecasts without the context of an organization and uses these forecasts for forecast consumption and planning purposes.
Set the Schedule By plan option to determine the date by which Oracle Advanced Supply Chain Planning needs to consume the forecasts.
If you ship early, run Oracle Order Management concurrent process Re-schedule Ship Sets. Shipped sales orders consume forecasts only by schedule date. This concurrent process updates the schedule date of shipped sales orders to the ship date.
Run a supply chain plan with the appropriate explosion and consumption controls.
The forecast consumption occurs on forecast entries that have references to both Ship From (a generic reference) and Ship To (specific references) entities.
Forecasts in general are consumed by regular sales orders. Internal sales orders do not consume forecasts. The assumption here is that the forecast maintained at an org level or even globally is meant for demands that is destined to a specific customer. If you consume forecasts using internal sales orders, you may be consuming forecasts that was from a customer using a sales order that originated from an internal source (from another org) and therefore, understate the demand.
You can control how internal sales orders should consume forecasts by setting profile option MSC: Consume forecasts using Internal Sales Orders as follows:
Yes: The planning engine consumes forecasts with internal sales orders
No: The planning engine does not consume forecasts with internal sales orders
Only if Destination Organization on ISO is not part of Plan: The planning engine consumes forecasts with internal sales order that meet either of these conditions:
Its destination organization is not planned in this plan
Its destination organization is planned in a source plan (MRP/MPS/MPP). This applies only one level down from the internal sales order source organization.
You can forecast and stock a lower level configured item and then consume its forecast with sales orders for the parent assembly. Any remaining demand then consumes the forecast for the associated assemble-to-order model.
If you need to stock at the end item level or at lower level subassemblies to reduce delivery time, you can forecast a demand for the configuration item directly, release a planned order for that item, and build and stock that item.
The planning engine consumes the forecast for this specific configuration first, within the backward and forward consumption days. If there is remaining sales order demand after consuming the configuration's forecast, the planning engine then consumes forecasts for the base assemble-to-order model. For the part of the forecast that consumed the assemble-to-order model's forecast, the planning engine explodes the bills of material to consume any forecast for the lower level configured item. After consuming the forecast for the lower level configured item, the planning engine then consumes the base model forecast in the same manner. When demand consumes a model, the consumption process also consumes its option classes and option forecasts at that level.
To avoid double counting the forecast, reduce your exploded forecast or planning percentages to account for the separate forecast for the configured item.
For forecasted demands of assemble-to-order models, the planning engine reduces planned order resource requirements for optional resources. These planned orders are only generated for forecasted demands. Certain operations are utilized only when specific optional components are utilized.
When the planning engine reduces the resource usage for optional resources, it uses the component planned percentage for the optional component used at that operation to estimate the amount of time that resources are required.
If several options require the same operation, the planning engine sums the planned percentage for these options up to a total of 100% and then applies the formula Operation schedule quantity = Planned order quantity * planning percentage
To set up an option dependent resource, select Option Dependent for the operation on the routing, then assign the optional components to the operation on the bill of material.
The Auto-create Configuration concurrent process creates the configured item's bills of material with only the specified options. In the same way, it creates the configured item's routing with only those operations that are mandatory and the option dependent operations linked to the options that you select.
Common Routings for Option Classes
You can reference an assemble-to-order model routing as a common routing for option class items. The model routing includes the steps that all configurations require. The planning engine recognizes the common routing between the assemble-to-order model and its option class and ignores the repeated resources in the option class routing.
This only applies to an option class that shares a common routing with its immediate parent. If the option class shares a common routing with any other item, the option class's routing is planned as a separate routing. The planning engine does not ignore common routings for lower level assemble-to-order models that are tied directly to an assemble-to-order parent model.
The planning engine distributes forecasts in the following manner:
Unconstrained - Distributes based on ranks and planning percentage.
Constrained - Distributes based on ranks and planning percentage.
Constrained with decision rules - Distributes forecasts based on capacity and resource availability. The planning engine considers rank as well as material, resource, and transportation constraints.
Cost based optimized plans - In addition to supplies and constraints, the planning engine also considers the cost of production and transportation for distributing forecasts.
Note: Select the Round Order Quantity item attribute in Inventory > Items > Organization Items > MPS/MRP Planning tab to avoid the planning engine from sourcing forecast entries with fractional demand.
The planning engine only sources sales order lines that:
Have global forecasts against their item
Are present in constrained plans with decision rules and optimized plans
Are scheduled
Are not firmed
Are not marked ship model complete
You can manually select a shipping facility on a sales order line at the order entry time. However, the facility that you select may not be the best one at the shipment time due to the evolving global supply and demand picture. The planning engine selects a facility for sourcing the sales order based on the global supply availability, supply chain constraints, procurement costs, and production costs.
You can opt to enforce the global sourcing rule split. If the organization with the higher sourcing percentage has enough capacity, the planning engine places the entire sales order line there. If it does not find any capacity in any of the sources, it distributes based on the highest planned split percentage of the highest rank in the source. It uses the entire capacity of the organization with the higher sourcing percentage and sources the remaining supplies from other organizations.
The planning engine may distribute components of a configured item to multiple inventory organizations. In other words, it may source one line from one inventory organization and another line from another inventory organization regardless of whether you prefer to source all supplies for a sales order from a single source, the sales order has ship sets, or the sales order has arrival sets.
During demand allocation, the planning engine splits a sales order:
If capacity constraints are present
To use existing supplies
The planning engine does not split the sales order if:
You have partial demand quantity reserved. In this case, the planning engine does not change the source. The entire sales order will be sourced to the Org where you have partial reservation.
There are sourcing constraints because the planning engine does not include sales orders into enforce sourcing constraints calculations.
The planning engine evaluates alternate ship methods specified in the sourcing rules/BOD form and recommends the appropriate option. It can also release a ship method to the sales order, which is different from the one specified in the Transit Times form.
If a sales order is already firmed in Oracle Order Management, the planning engine provides recommendations only for ship method and schedule ship date and does not provide any suggestions for changing the shipping facility.
To review the forecast distribution from the global forecast to individual organizations' forecasts
Navigate to Supply Chain Plan > Workbench
Select View by Organization.
Select a plan name
Select an organization
Select an item
Select Horizontal Plan
The Horizontal Plan window presents the forecast consumption and distribution details in two parts.
The first part displays the global forecast plan with following rows:
Original forecast quantity
Consumed quantity
Current quantity
Cumulative original quantity
Cumulative original quantity
Expired forecast: The amount of unmet forecasts
The second part is the horizontal material plan, which is specific to the organization from where you navigated to the horizontal plan. The forecast row in this part of the horizontal plan displays the amount of forecasts distributed to the organization.
If you select View by Item, Planner Workbench displays the same global organization information with the supply and demand aggregated for all organizations instead of for a specific organization.
Right-click on the Horizontal Plan window and select Global Forecasting and select the level values available to analyze the consumption plan with respect to specific consumption levels.
You can use this option to bring up the forecast and consumption information specific to different zones. For example: you can right-click and select Global Forecasting > Zone 1 to display information that is specific to Zone 1.
In the Horizontal Plan window, double-click on the Current field to open the Supply/Demand window with all the distributed forecasts for a global forecast.
In the Horizontal Plan window, double-click on the Consumed field to open the Supply/Demand window with sales orders that consumed the forecast.
Note: Oracle Advanced Supply Chain Planning retains shipped sales orders for consumption purposes but the sales order is not shown in the demand picture as it has already been shipped. When you drill down from the Consumed field in the Horizontal Plan window to the Supply/Demand window, the planning engine does not show shipped sales orders while the consumption still happens using shipped sales orders. This may cause a mismatch between the numbers in the Consumed field and the numbers in Supply/Demand window (drill down from the Consumed field) .
You can set the Include Sales Order plan option to control whether the planning engine picks up sales orders behind a specific number of days or not. For details, see Chapter 5: Plan Options.
You can use the profile MSC: Sales Order offset days to filter out the sales orders that are not supposed to consume the forecast.
Right click from a specific sales order.
The Consumption Details window appears.
Navigate to Exception Details window to review overconsumption exceptions.
Oracle Advanced Supply Chain Planning generates the following exception for each occurrence of forecast over consumption:
Items with forecast overconsumptions
This section lists a few examples to further explain the global consumption and explosion process based on different scenarios:
Consider a standard item A for which:
The forecast consumption is at the item or global level.
The forecast is distributed to two manufacturing organizations M1 and M2:
The sourcing rules for M1 and M2 are set as 40% and 60% respectively.
Global Forecasting for a standard item
Refer the table below to see the amount of forecast consumed and distributed by the planning engine:
Forecast | 1/10 | 1/17 | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
Consumed forecast | 40 | 80 | 60 | 50 | 50 | 50 |
Forecast distributed to M1 | 20 | 10 | 15 | 11 | 10 | 20 |
Forecast distributed to M2 | 20 | 70 | 45 | 39 | 40 | 30 |
Result:
The distributed forecast is not according to settings in the sourcing rules/BOD. The forecast distribution amount can vary depending on the type of plan you run and the options you choose. Oracle Advanced Supply Chain Planning also supports enforcing a sourcing percentage. This option allows you to enforce the amount of forecasts on a percentage basis to specific organizations
Lead-times used during forecast distribution: If the forecast is specific to a customer site, and you have customer specific sourcing rule, Oracle Advanced Supply Chain Planning uses the intransit lead-time between shipment organization and customer site (via zones) if you have set up intransit lead-time between the two.
A product family item PF1 with two member items M1 and M2 is present in Organization 1. The member percentages are 40 and 60 for M1 and M2 respectively.
The product family item PF1 with two member items M1 and M2 is also present in Organization 2. The member percentages are 50 for both M1 and M2.
Forecast explosion cannot go across multiple organizations and it needs a single bill of material (product family relationship) to explode the forecast. Therefore, you need to define a representative product family relationship in the item validation organization.
The representative bill of material is used for forecast explosion purposes only. The planning percentage for M1 versus M2 is adjusted in the item validation organization to get a single definition of the product family.
Global forecasting for product family items
Oracle Demand Planning and Oracle Advanced Supply Chain Planning use the product family relationship that you specify in the item validation organization to explode the forecasts to member levels.
Forecast control is set to Consume and Derive
Assume that the following sales orders are present for members M1 and M2 of product family PF1 in Organization 1:
Sales Order No | Item | Date | Qty | Customer | Customer Site |
---|---|---|---|---|---|
1001 | M1 | 1/15 | 20 | C1 | S1 |
1002 | M1 | 2/1 | 50 | C1 | S2 |
1003 | M2 | 2/8 | 40 | C2 | S1 |
1004 | M2 | 3/1 | 80 | C3 | - |
Before forecast consumption and explosion and no organization context, the planning engine gives the following result:
Item | 1/10 | 1/17 | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
PF1 | 80 | 50 | 50 | 100 | 50 | 100 |
After forecast explosion, the planning engine gives the following result:
Item | 1/10 | 1/17 | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
PF1 | 80 | 50 | 50 | 100 | 50 | 100 |
M1 | 40 | 25 | 25 | 50 | 25 | 50 |
M2 | 40 | 25 | 25 | 50 | 25 | 50 |
Assume that backward consumption = 30 days.
After forecast explosion and consumption, the planning engine gives the following result:
Item | 1/10 | 1/17 | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
PF1 | 60 | 50 | 50 | 5 | 25 | 50 |
M1 | 20 | 25 | 25 | 0 | 25 | 50 |
Sales Order No | 1001 | - | - | 1002 | - | - |
M2 | 40 | 25 | 25 | 5 | 0 | 0 |
Sales Order No | - | - | - | 1003 1004 |
1003 | 1004 |
Result:
The forecasts are consumed against the product family.
No shipment organization has been referenced in the forecast consumption.
Forecast explosion can either happen in Oracle Demand Planning or Oracle Advanced Supply Chain Planning. If you bring forecasts at a global level, you can explode the forecast within Oracle Advanced Supply Chain Planning.
You have forecasts that need to be placed into specific organizations for materials and resources planning. Specify sourcing rules for product family items so that the planning engine can place the item in a specific organization and plan the item and its members.
When the forecast gets distributed to a specific Ship From organization, the order type for the demand is Production Forecast.
You need to assign the sourcing rules at the same level as the forecast consumption level. For example, if the forecasts are consumed at item level, then you need to provide the sourcing rule also at item level.
Forecast control is set to None or Consume
Consider:
Forecast control is set to None or Consume
Specify the sourcing rules for the product family item as mentioned in Scenario 1. This enables Oracle Advanced Supply Chain Planning to distribute the forecasts from generic Ship From organizations to specific organizations.
Result:
The forecast consumption happens before the forecast explosion at the product family level and the member item level.
The product family bill of material is exploded during bill of material explosion in Oracle Advanced Supply Chain Planning.
Oracle Advanced Supply Chain Planning explodes the demand to member items during the bill of material explosion as it does for standard items during regular planning process. When Oracle Advanced Supply Chain Planning explodes the bill of material in this case, it picks up the bill of material in the true organization and not the one in the item validation organization.
A single level single org ATO assembly in Organization 1.
The assembly for Model 1 contains Option Class OC1 and Mandatory Components MC1.
Option Class OC1 contains Option 1 and Option 2.
The bill of material is maintained in the item validation organization.
The fixed and variable lead-times are also maintained in the item validation organization.
Single level single org ATO assembly
Forecast control is set to Consume and Derive
Assume that:
Forecast control is set to Consume and Derive
The forecast for the Model item is maintained without any organization context.
The forecasts for optional items and mandatory components are maintained independently to service independent demands such as spares or safety stock requirements.
Refer the table below for the forecasts maintained for Model 1 in Organization 1:
Item | 1/10 | 1/17 | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
Model 1 | 40 | 20 | 10 | 20 | 50 | 40 |
Option 1 | 5 | 0 | 5 | 4 | 10 | 10 |
Option 2 | 0 | 0 | 0 | 5 | 6 | 10 |
Mandatory Components MC 1 | 2 | 2 | 2 | 2 | 2 | 2 |
The forecasts for Option 1, Option 2, and Mandatory components MC1, which belong to Models 1, account for the lead-time of its assembly item.
If you have independent forecasts, the planning engine derives the forecast date for the independent demand as the ship date for the options and mandatory components. However, the dependent demands Option 1, Option 2, and Mandatory components MC1 for Model 1 are offset for lead-time.
Assume that:
The sourcing rule for Model 1 is defined at Organization 1. This is the level at which you consumed the forecasts.
The fixed and variable lead-time for Model 1 = 5 days
After forecast explosion, the planning engine gives the following result:
Item | 1/5 | 1/10 | 1/12 | 1/17 | 1/19 | 1/24 | 1/25 | 2/1 | 2/3 | 2/8 | 2/10 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | 0 | 40 | 0 | 20 | 0 | 10 | 0 | 20 | 0 | 50 | 0 | 40 |
Option Class OC1 | 40 | 0 | 20 | 0 | 10 | 0 | 20 | 0 | 50 | 0 | 40 | 0 |
Option 1 | 20 | 5 | 10 | 0 | 5 | 5 | 10 | 4 | 25 | 10 | 20 | 10 |
Option 2 | 20 | 0 | 10 | 0 | 5 | 0 | 10 | 5 | 25 | 6 | 20 | 0 |
Mandatory Components MC 1 | 40 | 2 | 20 | 2 | 10 | 2 | 20 | 2 | 50 | 2 | 40 | 2 |
Assume that:
You receive a sales order for 25 units of Model with Option 1 on 1/17.
Backward consumption = 30 days
After forecast consumption, the planning engine gives the following result:
Item | 1/5 | 1/10 | 1/12 | 1/17 | 1/19 | 1/24 | 1/25 | 2/1 | 2/3 | 2/8 | 2/10 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | 0 | 35 | 0 | 0 | 0 | 10 | 0 | 20 | 0 | 50 | 0 | 40 |
Option Class OC1 | 5 | 0 | 0 | 0 | 10 | 0 | 20 | 0 | 50 | 0 | 40 | 0 |
Option 1 | 0 | 5 | 10 | 0 | 5 | 5 | 10 | 4 | 25 | 10 | 20 | 10 |
Option 2 | 20 | 0 | 10 | 0 | 5 | 0 | 10 | 5 | 25 | 6 | 20 | 10 |
Mandatory Components MC 1 | 15 | 2 | 20 | 2 | 10 | 2 | 20 | 2 | 50 | 2 | 40 | 2 |
Result: The above forecast is sourced to Organization 1.
Forecast control set to None or Consume
If the forecast control is set to None or Consume, you do not need to maintain the bill of material in the item validation organization. In this case, planning engine explodes the forecasts as part of regular planning explosion process.
It is enough to maintain the sourcing rules for Model 1. If the top level item's forecast control is set to Consume, Oracle Advanced Supply Chain Planning consumes only the top level model.
A multi level single org ATO assembly where the entire assembly is produced in Organization 1 but has multiple ATO assemblies.
The bill of material is maintained in the item validation organization.
The fixed and variable lead-times are also maintained in the item validation organization.
Forecast control set to consume for assembly and none or consume to components
Assume that:
Forecast control is set to consume for assembly and none or consume to components
The forecast for the Model item is maintained without any organization context.
The forecasts for optional items and mandatory components are maintained independently to service independent demands such as spares or safety stock requirements.
Refer the table below for the forecasts maintained for Model 1 in Organization 1:
Item | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|
Model 1 | 10 | 20 | 50 | 40 |
Option 1 | 5 | 4 | 10 | 10 |
Option 2 | 0 | 5 | 6 | 10 |
Option 3 | 2 | 2 | 2 | 2 |
Mandatory Components MC 3 | 4 | 4 | 4 | 4 |
Assume that:
The forecast is maintained at the global level.
The sourcing is maintained for the top level model, which is Model 1.
The fixed and variable lead-time for Model 1 = 3 days
The fixed and variable lead-time for = 2 days
You receive a sales order for 25 units of Model with Option 1 on 2/8 for Customer 1 and Site 1.
After forecast consumption, the planning engine gives the following result:
Item | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|
Model 1 | 10 | 20 | 25 | 40 |
Option 1 | 5 | 4 | 10 | 10 |
Option 2 | 0 | 5 | 6 | 10 |
Option 3 | 2 | 2 | 2 | 2 |
Mandatory Components MC 3 | 4 | 4 | 4 | 4 |
After forecast explosion, the planning engine gives the following result:
Item | 1/19 | 1/21 | 1/24 | 1/25 | 1/27 | 2/1 | 2/2 | 2/5 | 2/8 | 2/10 | 2/12 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | - | 10 | - | - | 20 | - | - | 25 | - | - | 40 |
Option Class OC1 | - | - | 10 | - | - | 20 | - | - | 25 | - | - | 40 |
Mandatory Components MC 1 | - | - | 10 | - | - | - | - | - | 25 | - | - | 40 |
Model 2 | - | 10 | - | - | 20 | - | - | 25 | - | - | 40 | - |
Option 1 | - | 5 | 5 | - | 10 | 4 | - | 13 | 10 | - | 20 | 10 |
Mandatory Components MC 2 | - | 10 | - | - | 20 | - | - | 25 | - | - | 40 | - |
Option Class OC2 | 10 | - | - | 20 | - | - | 25 | - | - | 40 | - | - |
Option 2 | 5 | - | 0 | 10 | - | 5 | 13 | - | 6 | 20 | - | 10 |
Option 3 | 5 | - | 2 | 10 | - | 2 | 12 | - | 2 | 20 | - | 2 |
Mandatory Components MC 3 | 10 | - | 4 | 20 | - | 4 | 25 | - | 4 | 40 | - | 4 |
Result:
The above forecast is sourced to Organization 1 for material and resource planning.
It is assumed that there are no constraints. If you run a constrained plan, the timing of the supplies and the demand satisfied dates for these forecasts may be away from the due dates.
Forecast control is set to Consume and Derive
If the forecast control is set to Consume and Derive, you need to maintain the bills of material in the item validation organization. In this case, Oracle Demand Planning performs the forecast explosion and provides forecasts to Oracle Advanced Supply Chain Planning.
Oracle Advanced Supply Chain Planning consumes the forecasts at the chosen level and distributes the forecasts based on the sourcing rules provided for Model 1, which is the top level model.
A single level multi org ATO assembly where Model 1 can be sourced from two different organizations
The forecast is set globally without the context of an organization.
Lead-time for Model 1 in Organization 1 = 2 days
Lead-time Model 1 in Organization 2 = 3 days.
Single level multi org ATO assembly
Forecast control is set to None or Consume
Assume that:
You need to consume forecast at the top assembly level and distribute the forecasts across sources. You can set the forecast control to None or Consume for the components.
The sourcing rules for Model 1 is maintained to source the items.
You need to maintain an independent forecast for the model and some optional items as follows:
Item | 1/10 | 1/17 | 1/24 | 2/1 | 2/8 | 2/15 |
---|---|---|---|---|---|---|
Model 1 | 20 | 20 | 16 | 20 | 30 | 20 |
Option 1 | 5 | 0 | 5 | 4 | 10 | 10 |
Option 2 | 0 | 0 | 0 | 5 | 6 | 10 |
The sourcing rule for Model 1 is maintained to source the items. The level at which you specify the sourcing rule must match the level at which you consume the forecast.
25% of the forecast needs to be sourced from Organization 1 and 75% of the forecast needs to be sourced from Organization 2.
Model 2 is needed for Model 1 assembly 100% of the time.
You get a demand of 25 units of sales order demand for Model 1 on 1/24 with Option 2.
After forecast consumption and explosion, the planning engine gives the following result:
Result for Organization 1:
Item | 1/7 | 1/10 | 1/14 | 1/17 | 1/21 | 1/24 | 1/27 | 2/1 | 2/5 | 2/8 | 2/12 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | 5 | - | 8 | - | 0 | - | 15 | - | 23 | - | 15 |
Option 1 | 8 | 5 | 4 | 0 | 0 | 5 | 8 | 4 | 12 | 10 | 8 | 10 |
Option 2 | 7 | 0 | 4 | 0 | 0 | 0 | 7 | 5 | 11 | 6 | 7 | 10 |
Result for Organization 2:
Item | 1/8 | 1/10 | 1/14 | 1/17 | 1/22 | 1/24 | 1/27 | 2/1 | 2/6 | 2/8 | 2/13 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | 5 | - | 3 | - | 0 | - | 5 | - | 8 | - | 5 |
Option 1 | 3 | 5 | 2 | 0 | 0 | 5 | 3 | 4 | 4 | 10 | 3 | 10 |
Option 2 | 2 | 0 | 1 | 0 | 0 | 0 | 2 | 5 | 4 | 6 | 2 | 10 |
The intransit lead-times and the organization specific lead-times are considered when distributing the demand and sourcing the items. Option 1 and Option 2 forecasts are offset using the lead-time in the Organization 1 and Organization 2 respectively.
Forecast control is set to Consume and Derive
Consider:
The forecast is maintained at the global level.
The sourcing is maintained for Model 1 to source the items. The level at which you specify the sourcing rule must match the level at which you consumed the forecast.
A generic bill of material is maintained in the item validation organization with all the options and mandatory components as shown below:
Bill of Material
Adjust the planning percentage on option class items and optional items to arrive at a figure that represent the figure in both organizations.
In this method the organization specific lead-times are not be applied. The lead-times specified in the item validation organization is used. Therefore, it is important to specify the lead-times that closely represents your set up.
The forecast control for mandatory components is generally set to None. Therefore, the demand on the mandatory components is placed when the bills of material explosion happens in Oracle Advanced Supply Chain Planning. If you put in mandatory components in the generic bill of material, the forecast is derived to the mandatory components. Therefore, it is not recommended that you add the mandatory components to the generic bill of material.
The forecast explosion occurs using the above bills of material in the item validation organization. After the forecast explosion, Oracle Advanced Supply Chain Planning consumes the forecast at the level you choose.
After forecast explosion, the planning engine gives the following result:
Item | 1/7 | 1/10 | 1/14 | 1/17 | 1/21 | 1/24 | 1/27 | 2/1 | 2/5 | 2/8 | 2/12 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | 20 | - | 20 | - | 16 | - | - | - | 30 | - | 20 |
Option Class OC1 | 20 | - | 20 | - | 16 | - | - | - | 30 | - | 20 | - |
Option 1 | 10 | 5 | 10 | 0 | 8 | 5 | 10 | 4 | 15 | 10 | 10 | 10 |
Option 2 | 10 | 0 | 10 | 0 | 8 | 0 | 10 | 5 | 15 | 6 | 10 | 10 |
You get a demand of 25 units of sales order demand for the model on 1/24 with Option 2.
After forecast consumption, the planning engine gives the following result:
Item | 1/8 | 1/10 | 1/14 | 1/17 | 1/22 | 1/24 | 1/27 | 2/1 | 2/6 | 2/8 | 2/13 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | 20 | - | 11 | - | 0 | - | 20 | - | 30 | - | 20 |
Option Class OC1 | 20 | - | 11 | - | 0 | - | 20 | - | 30 | - | 20 | - |
Option 1 | 10 | 5 | 10 | 0 | 8 | 5 | 10 | 4 | 15 | 10 | 10 | 10 |
Option 2 | 3 | 0 | 0 | 0 | 0 | 0 | 10 | 5 | 15 | 6 | 10 | 10 |
Result:
After forecast explosion, the forecast is consumed at the level that you choose.
The planning engine distributes the forecast for optional items between Organization 1 and Organization 2 based on the sourcing rules established for these models. If your optional items follow different sources than the model, you should define the different sources in the sourcing rule for the optional items.
If you want to maintain the sourcing splits between organizations, set Enforce sourcing constraints to No in the Plan Options form. The planning engine recommends the forecast quantities to be placed in each organization based on the constraints you might have in the lower levels of the bills of material in each of the organizations.
A multi level multi org ATO assembly where a lower level Model is sourced from two different organizations.
Forecasts are specified globally without the context of an organization.
The lead-time for Model 2 in Organization 2 = 2 days.
The lead-time for Model 2 in Organization 3 = 3 days.
The intransit lead-time for Organization 2 = 2 days.
The intransit lead-time for Organization 3 = 3 days.
Multi level multi org ATO assembly
Forecast control is set to None or Consume
Assume that:
You need to consume forecast at the top assembly level and distribute the forecasts across sources. You can set the forecast control to None or Consume for the components.
The sourcing rules for Model 1 and Model 2 are maintained to source the items. The level at which you specify the sourcing rules must match the level at which you consume the forecast.
You need to maintain an independent forecast for Model 1 and some optional items as follows:
Item | 1/24 | D2/1 | 2/8 | 2/15 |
---|---|---|---|---|
Model 1 | 16 | 20 | 30 | 20 |
Option 1 | 5 | 4 | 10 | 10 |
Option 2 | 0 | 5 | 6 | 10 |
Assume that:
25% of the forecast needs to be sourced from Organization 2 and 75% of the forecast needs to be sourced from Organization 3.
Model 2 is needed for Model 1 assembly 100% of the time.
You get a demand of 25 units of sales order demand for the model on 2/8 with Option 2.
After forecast consumption and explosion, the planning engine gives the following result:
Result for Organization 2:
Item | 1/20 | 1/24 | 1/26 | 2/1 | 2/4 | 2/8 | 2/11 | 2/15 |
---|---|---|---|---|---|---|---|---|
Model 1 | - | 4 | - | 5 | - | 1 | - | 5 |
Option 1 | 2 | 5 | 3 | 4 | 1 | 10 | 3 | 10 |
Option 2 | 2 | 0 | 2 | 5 | 0 | 6 | 2 | 10 |
Result for Organization 3:
Item | 1/18 | 1/24 | 1/24 | 2/1 | 2/2 | 2/8 | 2/9 | 2/15 |
---|---|---|---|---|---|---|---|---|
Model 1 | - | 12 | - | 15 | - | 4 | - | 15 |
Option 1 | 6 | 5 | 8 | 4 | 2 | 10 | 8 | 10 |
Option 2 | 6 | 0 | 7 | 5 | 2 | 6 | 7 | 10 |
The intransit lead-times and the organization specific lead-times are considered when distributing the demand and sourcing the items.
Forecast control is set to Consume and Derive
Consider:
The forecast is maintained at the global level.
The sourcing is maintained for Model 1 and Model 2 to source the items. The level at which you specify the sourcing rules must match the level at which you consumed the forecast.
A generic bills of material is maintained in the item validation organization with all the options and mandatory components as shown below:
Bills of Material
Assume that:
Lead-time for Model 1 = 1 day.
Lead-time for Model 2 = 2 days.
Model 2 is needed for Model 1 assembly 100% of the time.
After forecast explosion, the planning engine gives the following result:
Item | 1/22 | 1/23 | 1/24 | 1/29 | 1/31 | 2/1 | 2/5 | 2/7 | 2/8 | 2/12 | 2/14 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | - | 16 | - | - | 20 | - | - | 30 | - | - | 20 |
Model 2 | - | 16 | - | - | 20 | - | - | 30 | - | - | 20 | - |
Option Class OC1 | 16 | - | - | 20 | - | - | 30 | - | - | 30 | - | - |
Option 1 | 8 | - | 5 | 10 | - | 4 | 15 | - | 10 | 10 | - | 10 |
Option 2 | 8 | - | 0 | 10 | - | 5 | 15 | - | 6 | 10 | - | 10 |
You get a demand of 25 units of sales order demand for the model on 2/8 with Option 2.
After forecast consumption, the planning engine gives the following result:
Item | 1/22 | 1/23 | 1/24 | 1/29 | 1/31 | 2/1 | 2/5 | 2/7 | 2/8 | 2/12 | 2/14 | 2/15 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Model 1 | - | - | 16 | - | - | 20 | - | - | 5 | - | - | 20 |
Model 2 | - | 16 | - | - | 20 | - | - | 5 | - | - | 20 | - |
Option Class OC1 | 16 | - | - | 20 | - | - | 5 | - | - | 30 | - | - |
Option 1 | 8 | - | 5 | 10 | - | 4 | 15 | - | 10 | 10 | - | 10 |
Option 2 | 8 | - | 0 | 5 | - | 0 | 0 | - | 6 | 10 | - | 10 |
Result:
After forecast explosion, the forecast is consumed at the level that you choose.
The planning engine distributes the forecast for optional items between Organization 2 and Organization 3 based on the sourcing rules established for these models. If your optional items follow different sources than the model, you should define the different sources in the sourcing rule for the optional items.
If you want to maintain the sourcing splits between organizations, set Enforce sourcing constraints to No in the Plan Options form. The planning engine recommends the forecast quantities to be placed in each organization based on the constraints you might have in the lower levels of the bills of material in each of the organizations.
Oracle ASCP allows planning to occur at different levels of aggregation within the same plan. This allows detailed scheduling and long-range planning to take place within a single integrated plan. Flexible aggregation levels exist along several planning dimensions:
Time
Product
Resource/routing
Aggregation level options for each dimension is described below.
In ASCP, the available time aggregation levels are:
Minutes
Hours
Days
Weeks
Periods
In order to reduce the computational effort to calculate a plan and to reduce the volume of plan output (for clarity), time bucket sizes should be set only as small as is necessary to capture the necessary detail.
Time bucket size must increase or stay level over the planning horizon; it cannot decrease.
The following sequences of time aggregation levels are examples of those (but not all) that are valid within a single plan:
Minutes-hours-days-weeks-periods (check Constrained Plan in the Constraints tab)
Days (Aggregation tab)
Days-weeks (Aggregation tab)
Hours-days-periods (check Constrained Plan in the Constraints tab. Note: weeks time aggregation level is skipped.)
Planning at the minute and hour aggregation levels is referred to as scheduling, and is enabled only when the Constrained Plan check box in the Constraints tab of the Plan Options window is checked.
Periods default to months.
All lower level demand that occurs within a higher level time bucket (for example, a daily demand occurring in the middle of a weekly time bucket) is moved to the last day of the higher level bucket for planning purposes. This is the information lost through aggregation.
Supplies are always scheduled to arrive at the last day of periods.
If you use order modifier Fixed Days of Supply, the planning engine creates a single supply to cover multiple days of demand. During constraint-based scheduling, the planning engine may move the demand and supply dates such that you cannot reconcile the supply quantity to the demand dates and quantities. To attempt a reconciliation, Oracle recommends using the old due date on the planned order demands.
In Oracle ASCP, the available product aggregation levels are:
Item
Product family
Planning at the item level explodes material and resource requirements down to each bottom-level component (provided that the component's MRP Planning Type item attribute matches the type of Manufacturing, Production, or Master Plan being run).
When planning at the product family level, no explosion of material or resource requirements occurs. Information concerning the resources required to make a product family are taken from the routing for the product family. Therefore, if planning is to be done at a product family level, there needs to be a routing defined for each product family. No material requirements are considered when planning at a product family level.
There are two ways in which the aggregation level of resource information may be specified in Oracle ASCP:
Resource aggregation level of Individual aggregate
Routing aggregation level of Routing bill of resource (BOR)
Note: Resource aggregation levels do not have any effect unless the Constrained Plan check box in the Constraint tab of the Plan Options window is checked.
Resource aggregation levels can either be individual or aggregate.
Individual: All resources listed in all item routings (if the item aggregation level is set to Item) or all product family routings (if the item aggregation level is set to Product Family) are considered in planning.
Aggregate: Only resources specified as aggregate resources are considered in planning. Aggregate resources are specified in the window accessed by the Operations Resources button during routing definition (Use the Manufacturing and Distribution Manager responsibility. From the Navigator window, choose Bills of Material > Routings > Routings). Each operation resource can have a designated aggregate resource (which may be itself or another resource). If you designate a resource as an aggregate resource, do not use it as an individual resource; the planning engine does not plan it.
Routing aggregation levels serve a similar function.
Routing: all resources listed in all item routings (if the item aggregation level is set to Item) or all product family routings (if the item aggregation level is set to Product Family) are considered in planning. This is identical in meaning to the individual resource aggregation level described above.
Bill of resource (BOR): only resources listed in bills of resources for items (if the item aggregation level is set to Item) or product families (if the item aggregation level is set to Product Family) are considered in planning. Bills of resource are lists which associate items or product families with individual resources and the processing times (usages) incurred on those resources for each item/product family. (To define a bill of resource, use the Manufacturing and Distribution Manager responsibility. From the Navigator window, choose Capacity Planning > Bill of Resources > Bill of Resource.) The usages in a bill of resource may be automatically generated by summing the resource usages from the routings for an item and its components and subcomponents. A bill of resource may also be manually defined, allowing you to include only certain key resources and to manually adjust the usage quantity for each key resource as necessary.
When using the routing aggregation level bill of resources, Oracle ASCP generates resource requirements during planning only for those items or product families that have defined bills of resources.
When using the routing aggregation level bill of resources, operation sequencing information from the routings that are used to generate the bill of resources is lost. The bill of resources aggregation level is for use with the weekly and period buckets for an approximate rough-cut capacity planning. When using bills of resources, constraint-based planning is not recommended because the resource sequencing and interdependence is not considered. Bill of resources aggregation is not compatible with routing aggregation in the same plan, and bill of resources aggregation is not available when scheduling in minutes and hours.
The higher levels of resource aggregation (aggregate) and routing aggregation (BOR) both have the effect of limiting the number of resources considered in planning.
Resource and routing aggregation level have overlapping effects.
If either the resource aggregation level is set to individual or the routing aggregation level is set to routing, all individual resources for items (if the item aggregation level is set to Item) or product families (if the item aggregation level is set to Product Family) are considered in planning.
From the Navigator, select Supply Chain Plan > Options.
The Plan Options window appears.
Choose the Constraints tab.
Enter the time horizon in days, weeks, or periods.
You can specify different levels of aggregation in different time buckets so that detailed information is considered more frequently and less detailed information is considered less frequently.
Resources can be scheduled either individually or in aggregate. Selecting individual resource scheduling generates schedules down to the individual resource level and considers the available capacity of each resource in the schedule recommendations.
Selecting aggregate resource scheduling considers the overall capacity of all resources in a resource group required for an item. For example, the overall capacity of a department to which the individual resources are assigned are used.
For more information, see Defining a Resource in Oracle Bills of Material User's Guide.
You can specify material aggregation levels for each of the three planning time horizons.
From the Navigator, select Supply Chain Plan > Options.
Choose the Constraints tab.
Enter the time horizon in days, weeks, or periods.
You can specify different levels of aggregation in different time buckets so that detailed information is considered more frequently and less detailed information is considered less frequently.
You can schedule the product at either the item level or the product family level.
Ensure items are correctly assigned to a product family and that a planning percent is specified when setting up your BOMs.
You can specify routing aggregation levels for each of the three planning time horizons.
From the Navigator, select Supply Chain Plan > Options.
The Plan Options window appears.
Choose the Constraints tab.
Enter the time horizon in days, weeks, or periods.
You can specify different levels of aggregation in different time buckets so that detailed information is considered more frequently and less detailed information is considered less frequently.
Either routings or bills of resources can be selected for plans. For detailed scheduling in the minute, hour and daily buckets, routings are used. For long-range simulations in the weekly and monthly buckets, routings or bills of resources can be used. Note that routings and bills of resources cannot be used in the same plan.
Selecting routing level aggregation will result in schedules that consider the capacity of each resource as well as the sequencing of the resources during the production of an item. Selecting bill of resource level aggregation will only consider the resource requirements needed to produce an item without considering the sequencing and interdependence among the resources required for an item.
The bill of resources aggregation level is for use with the weekly and period buckets for an approximate rough-cut capacity planning. When using bills of resources, constraint-based planning is not recommended because the resource sequencing and interdependence is not considered. Bill of resource aggregation is not compatible with routing aggregation in the same plan, and bill of resource aggregation is not available when scheduling in minutes and hours.
When generating plans via the Optimized option, Oracle ASCP lets you specify the objectives to be considered in generating planned orders across the supply chain.
All objectives are expressed in units of dollars.
This section describes each of the available objectives and how multiple objectives can be combined into a single objective function which captures trade-offs between competing objectives.
You can optimize your plans to the objectives shown in the following table.
Objective Function | How is the Objective Achieved? |
---|---|
Maximize Inventory Turns | Minimize inventory carrying cost |
Maximize Plan Profit | Maximize plan revenue minus plan cost |
Maximize On-Time Delivery | Minimize penalty cost for late demand |
The inventory turns are maximized by minimizing inventory carrying cost. Inventory carrying cost is summed up for all items in all time buckets. Inventory carrying cost is calculated as follows:
Inventory carrying cost = (Average inventory per bucket) * (Carrying cost percent) * (Item cost)
Profit optimization occurs if you set profile option MSO: Cost Rollup for Optimization is No. Profit optimization should not use the internal cost rollup for optimization. That is used for making sure that costs of assemblies are more than the costs of components. It does not capture the true standard costs that profit optimization needs.
The planning engine optimizes subject to the plan constraints. The penalty factors, for example, demand lateness penalty, are the crucial part of this optimization. Based on the size of the demand lateness penalty factor, the planning engine may decide to satisfy a demand late in order to increase the profit.
Generally, the remainder of the planning process retains the optimized decisions. However,
If there are order modifiers, the planning engine may increase the size of some planned orders to satisfy the order modifier and eliminate planned orders no longer needed
If there are constraints, for example, resource capacity, the planning engine may reschedule some orders
Even if two supplies use the same resources and ingredients, the profit optimization process always schedules a supply pegged to a more profitable demand before a supply pegged to a less profitable demand
If there are several main products in a formula, the profit optimization rollup uses the bill of material usage to calculate and allocate costs. For example, item C is component or ingredient of item A and item B. The rollup determines how many or how much item C is required to make one item A and how many or how much item C is required to make one item B (or how much of ingredient C is used to produce one unit of A @ and one unit of B). The process translates percentages to bill of material usages to calculate the costs.
The profit optimization rollup calculates the cost of by-products using bill of material usage also.
To see the internal cost calculations, view file SCO_COST_<plan id>
The planning engine performs pegging by demand priority even in the case of profit optimization. It may override the profit optimization decision, for example:
There are two demands: D1 for quantity 100 on Day 5 has higher priority and is less profitable; D2 for quantity 100 on Day 5 has lower priority but is more profitable
There are two supplies: S1 for quantity 100 on Day 6; S2 for quantity 100 on Day 7
The profit optimization process recommends S1 > D2 and S2 > D1
The pegging process overrides the profit optimization recommendations pegs S1 > D1 with higher priority and S2 > D2 with lower priority
The calculation for margin percentage objective is in Margin Percentage
The on-time delivery objective is modeled as minimization of the penalty cost for late demand.
Penalty cost is calculated and summed up for all items with independent demand in all time buckets.
Penalty cost for late demand = (Penalty cost factor for late demand in $/unit/day * Days late * Quantity of late demand) + (Penalty cost factor for unmet demand in $/unit/day * Days late * Quantity of unmet demand)
Penalty cost sums two types of costs: late demand cost and unmet demand cost. An unmet demand is simply a very late demand. Specifically, it is a demand for which the plan generates supply that exceeds the demand due date by more than allowable days early/late. Allowable days early/late is a profile option.
Penalty cost factor for late demand is a plan option. Penalty cost factor for unmet demand is a system plan option, obtained by multiplying the penalty cost factor for late demand by a constant that is greater than 1. This makes unmet (very late) demands cost more than late demands.
In addition to the above objectives, which you can select/weight or deselect, Oracle ASCP maintains a set of implicit (hidden) objectives that it takes into consideration no matter what you select. These objectives are defined to be the negative of various penalty costs, as follows:
Implicit objectives =
-(Penalty cost for late demand)
-(Penalty cost for resource capacity violation)
-(Penalty cost for transport capacity violation)
-(Penalty cost for material capacity violation)
-(Penalty cost for safety stock violation)
-(Penalty cost for using alternate sources)
-(Penalty cost for using alternate routings)
-(Penalty cost for using alternate resources)
-(Penalty cost for using substitute items)
-(Percentage of carrying cost)
Maximizing implicit objectives results in minimization of the penalty costs.
Penalty costs are the product of the penalty factor and some other parameter such as list price, item cost, resource cost, or transportation cost. For example:
Penalty cost for late demand [$/unit/day] = (Penalty factor) * (List price)
You can set penalty factors at different levels using flexfields, plan options, or profile options. Flexfields let you set penalty factors at the most discrete level. For example, you can set the Penalty Factor for Late Demand at the Demand, Item, or Org level using flexfields. Plan options and profile options let you set the same penalty factor at the plan level and site level, respectively.
The planning engine combines the above objectives into the following objective function:
Overall objective = Maximize w1 * (Plan profit) + w2 * On-time delivery) + w3 * (Inventory turns) + 1.0 * (Implicit objectives)
Objective weights w1-w3 are restricted to the range 0 to 1. Setting an objective's weight to 0 directs Oracle ASCP not to consider that particular objective. Setting an objective's weight to 1 places the maximum possible emphasis on that objective. Objective weights w1-w3 may be set independently.
Objective weights w1-w3 in general do not precisely show the relative importance of each objective in planning decisions. As can be seen from the above definition of the overall objective, the percentage of the overall objective value occupied by a particular objective depends also on the dollar magnitude of the objective, and it is the product of the weight and the dollar magnitude of the objective which reflects the relative importance of each objective in planning decisions.
Take special note of interdependent objectives. Some costs are contained in more than one objective. For example, inventory carrying cost is a part of both the Plan Profit and Inventory Turns objectives. Therefore, only use these two objectives together if it is desired to artificially weight inventory carrying cost higher than the other costs (item cost, transportation cost) contained within plan profit.
A more subtle case is penalty cost for late demand, which appears both in the On-time Delivery objective and in the implicit objectives not seen by the user. Thus, no matter what the weight on-time delivery, the planning engine considers late demand cost in its planning decision-making.
Implicit and explicit objectives are affected by several factors and rules. These tables show:
The relationship of these objectives to costs, prices, priority rules, and sourcing ranks
The minimum data requirements for optimized plans based on different objectives
Yes means the cost/factor affects the objective.
Cost-Price/Objectives | Inventory Turns | On-time Delivery | Plan Profit |
---|---|---|---|
Resource Cost | No | No | Yes |
Item Standard Cost | Yes | No | Yes |
Carrying Cost Percentage | Yes | No | Yes |
Late Demand Penalty Factor | No | Yes | No |
List Price and Selling Price | No | Yes | No |
Transportation Cost | No | No | Yes |
Factor | Penalty Cost for Late Demand | Penalty Cost for Resource Capacity Violation | Penalty Cost for Transport Capacity Violation | Penalty Cost for Material Capacity Violation | Penalty Cost for Safety Stock Violation |
---|---|---|---|---|---|
Resource Cost | No | Yes | No | No | No |
Item Standard Cost | No | No | No | Yes | Yes |
Carrying Cost Percentage | No | No | No | No | No |
Exceeding Item Capacity Penalty Factor | No | No | No | Yes | No |
Exceeding Resource Capacity Penalty Factor | No | Yes | No | No | No |
Exceeding Transport Capacity Penalty Factor | No | No | Yes | No | No |
Late Demand Penalty Factor | Yes | No | No | No | No |
List Price and Selling Price | Yes | No | No | No | No |
Transportation Cost | No | No | Yes | No | No |
Factor | Penalty Cost for Using Alternate Sources | Penalty Cost for Using Alternate Routings | Penalty Cost for Using Alternate Resources | Penalty Cost for Using Substitute Items | Implicit Carrying Cost |
---|---|---|---|---|---|
Resource Cost | Yes | No | Yes | No | No |
Item Standard Cost | Yes | Yes | No | Yes | Yes |
Carrying Cost Percentage | No | No | No | No | Yes |
Sourcing Rank | Yes | No | No | No | No |
Substitute Item Priority | No | No | No | Yes | No |
BOM/Routing Priority | No | Yes | No | No | No |
Alternate Resource Priority | No | No | Yes | No | No |
At all levels of optimization except for unconstrained plan (see Choosing Plan Classes), Oracle ASCP performs some type of finite-capacity scheduling. This is computationally much more complex than the infinite-capacity planning performed in older versions. Therefore, formulating the planning problem so that it is less computationally intensive is worthwhile.
The computational burden of a planning problem increases with the number of scheduled resources, the number of items, and the number of demands.
Ways to decrease the number of resources include:
Leave non-critical (non-constraint) resources out of routings. For example, an entire cell in a cellular manufacturing system might be modeled as a single resource instead of as a group of resources.
Set planned resources to bottleneck resources and include only key constraint resources in the bottleneck resource group.
Maximize the use of resource and routing aggregation (see Choosing Resource Aggregation Levels).
Ways to decrease the number of items include:
Enable each item in as few organizations as possible because each combination of item-organization counts as a separate item.
Maximize the use of item aggregation (to the product family level) in the plan options.
Set the Planned Items option in the Main tab of the Plan Options window to something other than All Planned Items. For example, set it to Demand Schedule Items Only.
Ways to decrease the number of demands include:
Maximize the use of time aggregation (larger time buckets) in plan options. This collapses multiple demands occurring within a larger time bucket to a single demand at the end of the time bucket.
Maintain long-term forecasts in larger time buckets (for example, weeks or periods) instead of shorter time buckets such as days. This reduces the number of MDS demands once the forecast is loaded into an MDS for input to the planning process.
The majority of the data required for optimized plans for different objectives are available in ERP systems. These data include:
Item Standard Cost, List Price, Selling Price, Discount
Carrying Cost Percent
Resource Cost
Transportation Cost
Sourcing Rank
Substitute Item Priority
BOM/Routing Priority
Alternate Resource Priority
The remaining data can be set up at the profile option level or plan level to expedite the implementation of optimized plans. These data include:
Exceeding Item Capacity Penalty Factor
Exceeding Resource Capacity Penalty Factor
Exceeding Transport Capacity Penalty Factor
Late Demand Penalty Factor
Oracle ASCP considers some default values for these fields, such as 0.01 for the Standard Cost. The Optimization process cannot produce very valuable results based on these default values alone. It is recommended that you specify starting values for these fields at the profile option level at the start of implementation.
Oracle ASCP optimization does not consider allocation percentages specified in the sourcing rules and/or bills of distributions. Sourcing decisions are made based on capacity, item standard cost, and rank with respect to penalty costs and constraints.
Example 1: Enforce Capacity Constraints Scenario
Item A is sourced from organizations O1 and O2 with ranks equal to 1 and 2 respectively. If the total costs (item plus penalty costs) are equal in both organizations, and capacity is available only in O2; then this organization is used as the source for item A and ranking is overridden.
Example 2: Enforce Demand Due Dates Scenario
Item A is sourced from organizations O1 and O2 with ranks equal to 1 and 2 respectively. If the total costs (item plus penalty costs) are equal for both organizations, Organization O1 with rank 1 is loaded (or overloaded) to source item A.
Example 3: Enforce Demand Due Dates Scenario
Item A is sourced from organizations O1 and O2 with ranks equal to 1 and 2 respectively. If the total cost (item plus penalty costs) in organization O1 is greater than organization O2, Organization O2 with rank 2 is loaded (or overloaded) to source item A and ranking is overridden.
Nervousness is the condition in which small changes in demand cause large changes in supply (planned order releases). In traditional MRP, plan nervousness causes lost time due to extra setups (and confusion and frustration) on the plant floor. With Oracle ASCP's ability to generate a single global supply chain plan, the effects of nervousness are magnified because they extend to trading partners (who may not have the same urgency to constantly replan manufacturing to accommodate rapidly changing requirements).
Consider the following example. End-item A has lead-time 1 day and order modifier of Fixed Order Period = 3 days. End-item A contains one component B, which has a lead-time of 3 days and order modifier Lot for Lot. Initial planned orders for A and B are shown in the next two tables.
Item A | Current | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
Gross Requirements | 0 | 10 | 10 | 10 | 10 | 50 |
Scheduled Receipts | 0 | 0 | 0 | 0 | 0 | 0 |
Project On-Hand | 15 | 5 | -5 | 0 | 0 | 0 |
Net Requirements | 0 | 0 | 5 | 10 | 10 | 50 |
Planned Order Due Date | 0 | 0 | 25 | 0 | 0 | 50 |
Planned Order Start Date | 0 | 25 | 0 | 0 | 50 | 0 |
Item B | Current | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
Gross Requirements | 0 | 25 | 0 | 0 | 50 | 0 |
Scheduled Receipts | 0 | 0 | 0 | 0 | 0 | 0 |
Project On-Hand | 25 | 0 | 0 | 0 | -50 | 0 |
Net Requirements | 0 | 0 | 0 | 0 | 50 | 0 |
Planned Order Due Date | 0 | 0 | 0 | 0 | 50 | 0 |
Planned Order Start Date | 0 | 50 | 0 | 0 | 0 | 0 |
Now suppose that the demand for A on day 2 decreases by 5 units. Revised planned orders are shown in the two tables below.
Item A | Current | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
Gross Requirements | 0 | 0 | 70 | 0 | 0 | 0 |
Scheduled Receipts | 0 | 0 | 0 | 0 | 0 | 0 |
Project On-Hand | 25 | 25 | -50 | 0 | 0 | 0 |
Net Requirements | 0 | 0 | 50 | 0 | 0 | 0 |
Planned Order Due Date | 0 | 0 | 50 | 0 | 0 | 0 |
Planned Order Start Date | 0 | 50* | 0 | 0 | 0 | 0 |
Item B | Current | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
Gross Requirements | 0 | 10 | 5 | 10 | 10 | 50 |
Scheduled Receipts | 0 | 0 | 0 | 0 | 0 | 0 |
Project On-Hand | 15 | 5 | 0 | -10 | 0 | 0 |
Net Requirements | 0 | 0 | 0 | 10 | 10 | 50 |
Planned Order Due Date | 0 | 0 | 0 | 70 | 0 | 0 |
Planned Order Start Date | 0 | 0 | 70 | 0 | 0 | 0 |
* Late Start
Note that the decrease in demand caused the planned orders for A to change from 25 on Day 1 and 50 on Day 4 to 70 on Day 3. This is an example of nervousness at work.
Note further that the resulting change in dependent demand for B causes the planned orders for B to become infeasible, resulting in a late start - this after the demand for A decreased.
Several steps may be taken to reduce planning nervousness of the sort illustrated above.
Eliminate the use of the order modifier Fixed Order Period for end items. Instead, use Fixed Lot Multiple or Fixed Order Quantity. Reserve Fixed Order Period for lowest-level items only.
Make use of a planning time fence. A planning time fence of x days freezes planned orders in the interval [plan start date, plan start date + x]. This eliminates near-term disruptions to the manufacturing schedule.
Make use of a release time fence. A release time fence of x days automatically firms and releases to the execution system planned orders in the time interval [plan start date, plan start date + x]. Subsequent planning runs then treat these planned orders as scheduled receipts, not subject to manipulation via order modifiers. This reduces planning nervousness.
Time fences can be used to freeze near-term plans and reduce nervousness. However, they also reduce the ability of the planning process to accommodate changes in demand. They should be set to the lowest values possible.
There are three interdependent ways of controlling which items are planned in and which are excluded from an ASCP plan:
Setting the Planning Method item attribute in conjunction with selecting the Plan Type in the Supply Chain Plan Names form
The Planning Method item attribute can be set to:
Not planned
MPS planning
MRP planning
MRP/MPP Planned
MPS/MPP Planned
MPP Planned
Plan Type can be set to:
Manufacturing Plan
Production Plan
Master Plan
Setting critical items in conjunction with setting the Include Critical Components flag in ASCP plan options
An item can be set to be critical in two ways:
Explicitly, by checking its Critical Component item attribute
Implicitly, by having a routing (primary or alternate) that includes a resource in the ASCP plan's bottleneck resource group
Setting the value for the Planned Items plan option, along with setting the organization-level Include Sales Order flag in the Organizations tab of the Plan Options form. Valid values for the Planned Items plan option are:
All planned items
Demand schedule items only
Supply schedule items only
Demand & Supply schedule items
Demand schedule and WIP components
Demand schedule items and all sales orders
Demand schedule items/WIP components/all sales orders
The following tables shows the items planned based on the Planned Items Plan Option, Plan Type, Planning Method Item Attribute, Include Critical Component Plan Option, Critical Component Item Attribute, and Include Sales Order Plan Option:
Planned Items Plan Option | Plan Type | Include Critical Components Plan Option | Planned Items |
All Planned Items | Manufacturing Plan | Unchecked | All items in the planned organizations except ones having MRP planning code of Not Planned. |
All Planned Items | Manufacturing Plan | Checked |
Note: If the primary component is critical then ASCP also selects the non-critical substitute components. If the primary component is not critical then ASCP does not select the substitute components even if these substitutes are critical. This behavior is applicable for all variations of Plan Type and Planned Items plan option. |
All Planned Items | Production Plan | Unchecked |
|
All Planned Items | Production Plan | Checked |
|
All Planned Items | Master Plan | Unchecked |
|
All Planned Items | Master Plan | Checked |
|
Demand schedule items only | Manufacturing Plan | Unchecked |
Note: In this option (Demand schedule items only) ASCP does not include sales orders for those item/organizations that are not in the demand schedule even if the Include Sales Order checkbox is checked for the related organizations. |
Demand schedule items only | Manufacturing Plan | Checked |
|
Demand schedule items only | Production Plan | Unchecked |
|
Demand schedule items only | Production Plan | Checked |
|
Demand schedule items only | Master Plan | Unchecked |
|
Demand schedule items only | Master Plan | Checked |
|
Supply schedule items only | Manufacturing Plan | Unchecked |
Note: In this option (Supply schedule items only) ASCP does not include sales orders for those item/organizations that are not in the supply schedule even if the Include Sales Order checkbox is checked for the related organizations. |
Supply schedule items only | Manufacturing Plan | Checked |
|
Supply schedule items only | Production Plan | Unchecked |
|
Supply schedule items only | Production Plan | Checked |
|
Supply schedule items only | Master Plan | Unchecked |
|
Supply schedule items only | Master Plan | Checked |
|
Demand & Supply schedule items | Manufacturing Plan | Unchecked |
Note: In this option (Demand & Supply schedule items) ASCP does not include sales orders for those item/organizations that are not in the demand or supply schedules even if the Include Sales Order checkbox is checked for the related organizations. |
Demand & Supply schedule items | Manufacturing Plan | Checked |
|
Demand & Supply schedule items | Production Plan | Unchecked |
|
Demand & Supply schedule items | Production Plan | Checked |
|
Demand & Supply schedule items | Master Plan | Unchecked |
|
Demand & Supply schedule items | Master Plan | Checked |
|
Demand schedule and WIP Components | Manufacturing Plan | Unchecked |
Note: In this option (Demand schedule and WIP Components) ASCP does not include sales orders for those item/organizations that are not in the demand schedule even if the Include Sales Order checkbox is checked for the related organizations. |
Demand schedule and WIP Components | Manufacturing Plan | Checked |
|
Demand schedule and WIP Components | Production Plan | Unchecked |
|
Demand schedule and WIP Components | Production Plan | Checked |
|
Demand schedule and WIP Components | Master Plan | Unchecked |
|
Demand schedule and WIP Components | Master Plan | Checked |
|
Planned Items Plan Option | Plan Type | Include Critical Components Plan Option | Include Sales Order Plan Option (organization specific) | Planned Items |
Demand schedule items and all sales orders | Manufacturing Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Manufacturing Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items and all sales orders | Manufacturing Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Manufacturing Plan | Checked | Checked |
Note: Sales order demands are planned. |
Demand schedule items and all sales orders | Production Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Production Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items and all sales orders | Production Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Production Plan | Checked | Checked |
Note: Sales order demands are planned. |
Demand schedule items and all sales orders | Master Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Master Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items and all sales orders | Master Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items and all sales orders | Master Plan | Checked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Manufacturing Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Manufacturing Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Manufacturing Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Manufacturing Plan | Checked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Production Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Production Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Production Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Production Plan | Checked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Master Plan | Unchecked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Master Plan | Unchecked | Checked |
Note: Sales order demands are planned. |
Demand schedule items / WIP components / all sales orders | Master Plan | Checked | Unchecked |
Note: Sales order demands are ignored and not seen in the plan. |
Demand schedule items / WIP components / all sales orders | Master Plan | Checked | Checked |
Note: Sales order demands are planned. |
Consider items A and B with the following bills of materials and demands at organizations M1 and M2:
In the Organizations tab of the Plan Options form, the Include Sales Order flag is set as follows for M1 and M2:
Organization | Include Sales Order |
M1 | Yes |
M2 | No |
Item A has demand schedules and sales orders for both organizations M1 and M2. Item B has only sales orders in organizations M1 and M2.
The following table shows what items are planned in a Manufacturing Plan. It references some scenarios.
Scenario 1 - Demand schedule items only and Include Critical Component is not checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. All components of item A (A1, A2, A3, A4) are also planned in both organizations. Item B with only sales orders in organizations M1 and M2 is not planned.
Sales order demands of item A for organization M1 are planned. Sales order demands of item A for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 2 - Demand schedule items only and Include Critical Component is checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. Only critical components of item A (A1, A3) and sandwiched item A2 are planned in both organizations. Item B with only sales orders in organizations M1 and M2 is not planned.
Sales order demands of item A for organization M1 are planned. Sales order demands of item A for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 3 - Demand schedule items and all sales orders and Include Critical Component is not checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. All components of item A (A1, A2, A3, A4) are also planned in both organizations. In addition item B with sales orders in organizations M1 and M2 is planned. All components of item B (A1, A2, A3, A4) are also planned in both organizations.
Sales order demands of items A and B for organization M1 are planned. Sales order demands of items A and B for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 4 - Demand schedule items and all sales orders and Include Critical Component is checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. Only critical components of item A (A1, A3) and sandwiched item A2 are planned in both organizations. In addition item B with sales orders in organizations M1 and M2 is planned. Only critical component of item B (B3) and sandwiched item B2 are planned in both organizations.
Sales order demands of items A and B for organization M1 are planned. Sales order demands of items A and B for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Item | Organization | Planned Items with Demand schedule items only and Include Critical Component Option Set to No (Scenario 1) | Planned Items with Demand schedule items only and Include Critical Component Set to Yes (Scenario 2) | Planned Items with Demand schedule items and all sales orders and Include Critical Component Set to No (Scenario 3) | Planned Items with Demand schedule items and all sales orders and Include Critical Component Set to Yes (Scenario 4) |
A | M1 | Yes | Yes | Yes | Yes |
A1 | M1 | Yes | Yes | Yes | Yes |
A2 | M1 | Yes | Yes | Yes | Yes |
A3 | M1 | Yes | Yes | Yes | Yes |
A4 | M1 | Yes | No | Yes | No |
B | M1 | No | No | Yes | Yes |
B1 | M1 | No | No | Yes | No |
B2 | M1 | No | No | Yes | Yes |
B3 | M1 | No | No | Yes | Yes |
B4 | M1 | No | No | Yes | No |
A | M2 | Yes | Yes | Yes | Yes |
A1 | M2 | Yes | Yes | Yes | Yes |
A2 | M2 | Yes | Yes | Yes | Yes |
A3 | M2 | Yes | Yes | Yes | Yes |
A4 | M2 | Yes | No | Yes | No |
B | M2 | No | No | Yes | Yes |
B1 | M2 | No | No | Yes | No |
B2 | M2 | No | No | Yes | Yes |
B3 | M2 | No | No | Yes | Yes |
B4 | M2 | No | No | Yes | No |
This table shows what items are planned in a Production Plan assuming items A and B are MPS Planning (or MPS/MPP Planned) items and their components are not MPS Planning (or MPS/MPP Planned) items. It references some scenarios.
Scenario 1 - Demand schedule items only and Include Critical Component is not checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. Item B with only sales orders in organizations M1 and M2 is not planned.
Sales order demands of item A for organization M1 are planned. Sales order demands of item A for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 2 - Demand schedule items only and Include Critical Component is checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. In addition all critical components of item A (A1, A3) and sandwiched item A2 are planned in both organizations. Item B with only sales orders in organizations M1 and M2 is not planned.
Sales order demands of item A for organization M1 are planned. Sales order demands of item A for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 3 - Demand schedule items and all sales orders and Include Critical Component is not checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. In addition item B with sales orders in organizations M1 and M2 is planned.
Sales order demands of items A and B for organization M1 are planned. Sales order demands of items A and B for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Scenario 4 - Demand schedule items and all sales orders and Include Critical Component is checked
In this case ASCP plans item A with demand schedules in organizations M1 and M2. In addition all critical components of item A (A1, A3) and sandwiched item A2 are planned in both organizations. Item B with sales orders in organizations M1 and M2 is also planned. In addition critical component of item B (B3) and sandwiched item B2 are planned in both organizations.
Sales order demands of items A and B for organization M1 are planned. Sales order demands of items A and B for organization M2 are ignored because the Include Sales Order flag for organization M2 is unchecked.
Item | Organization | Planned Items with Demand schedule items only and Include Critical Component Option Set to No (Scenario 1) | Planned Items with Demand schedule items only and Include Critical Component Set to Yes (Scenario 2) | Planned Items with Demand schedule items and all sales orders and Include Critical Component Set to No (Scenario 3) | Planned Items with Demand schedule items and all sales orders and Include Critical Component Set to Yes (Scenario 4) |
A | M1 | Yes | Yes | Yes | Yes |
A1 | M1 | No | Yes | No | Yes |
A2 | M1 | No | Yes | No | Yes |
A3 | M1 | No | Yes | No | Yes |
A4 | M1 | No | No | No | No |
B | M1 | No | No | Yes | Yes |
B1 | M1 | No | No | No | No |
B2 | M1 | No | No | No | Yes |
B3 | M1 | No | No | No | Yes |
B4 | M1 | No | No | No | No |
A | M2 | Yes | Yes | Yes | Yes |
A1 | M2 | No | Yes | No | Yes |
A2 | M2 | No | Yes | No | Yes |
A3 | M2 | No | Yes | No | Yes |
A4 | M2 | No | No | No | No |
B | M2 | No | No | Yes | Yes |
B1 | M2 | No | No | No | No |
B2 | M2 | No | No | No | Yes |
B3 | M2 | No | No | No | Yes |
B4 | M2 | No | No | No | No |