This chapter covers the following topics:
Oracle ASCP is a tool that integrates manufacturing and distribution into a single planning process. With Oracle ASCP, you can generate plans that include the entire supply chain. In a single step you can schedule and plan material and distribution requirements for multiple organizations, or centrally plan the entire enterprise. You can also include customer and supplier inventories in the supply chain planning process.
Oracle ASCP lets you plan finished products, intermediate assemblies, and purchased items for all facilities in your supply chain. Material plans for feeder plants and distribution centers automatically consider requirements originating from any number of other facilities. You can load planned order demand from multiple user organizations into the master schedule of supplying organizations.
In addition to planning the material requirements of your supply chain, you can plan the requirements for your distribution network. This includes all warehouses, distribution centers, and any location that ships products. You can use these master production plans (MPPs) as input for your material plans.
You can combine centralized distribution and material planning for items with significant interorganization supply or demand. You can perform subset planning where you prefer autonomous local planning. Output from the central plan can go into plant-level material plans and vice versa.
Oracle ASCP gives you a transparent view of the virtual enterprise, where all inventory locations participate in the planning process.
Sourcing rules and bills of distribution determine the movement of materials throughout your supply chain; these include items that you buy from your suppliers and make at your manufacturing organizations.
Sourcing rules and bills of distribution both specify date-effective sourcing strategies, combining replenishment sources with split allocation percentages and rankings. A replenishment source is:
An inter-organization transfer (Transfer From)
The replenished organization that manufactures the item (Make At)
An external supplier (Buy From)
Sourcing rules and BODs both describe sourcing supply; in other words, for any organization, they answer the question Where do I get part A? (They never ask Where do I send part A?) Sourcing rules apply the answer to one organization or all the organizations in your enterprise. BODs define this behavior across multiple organizations (not just one or all).
In a sourcing rule, time-phasing applies only to the shipping organizations; the receiving organization remains static for the life of the sourcing rule. In a bill of distribution, time-phasing applies both to shipping and receiving organizations.
For each item in a rule or bill, you can define effectivity dates to switch sourcing between make and buy, and set intransit lead times. If an item does not appear in a rule or bill, the item attribute determines the status; when these attributes conflict with a sourcing rule or bill of distribution, the rule or bill takes precedence. (See: Item and Bill of Material Attributes, and Defining Items, Oracle Inventory User's Guide.)
The following features are provided in Oracle Supply Chain Planning sourcing logic:
Alternate source search if allocation exceeds supplier capacity
Control over Make/Buy attributes
Delivery frequency calendars
Historical information used in allocations
Ranking sources and defining allocation percentages
Splitting demand according to sourcing percentages
Supplier capacity constraints
Supplier specific lead times
Supplier specific order modifiers
Tolerance fences
Sourcing Rules
Sourcing rules define inventory replenishment methods for either a single organization or all organizations in your enterprise. Time-phasing in a sourcing rule determines when each group of shipping method - ship org combinations is in effect, as in this example:
In the first phase of SR-C01, SAC is replenished equally by AUS and NYC. From 01-JUL-1997, AUS no longer supplies SAC, which receives all transfers from NYC: (mrp_suprulex.if)
This sourcing rule can apply to one org (SAC, in this example), or to all your organizations. However, you cannot choose a single organization in one phase and all organizations in another phase. That would require two sourcing rules, with consecutive effectivity dates. If you assign the sourcing rule to one receiving organization (SAC in this example), it is a local sourcing rule; if you assign it to multiple organizations, it is a global sourcing rule.
You cannot apply sourcing rules and bills of distribution (make them Planning Active) until the sum of the allocation percentages equals 100. Secondly, sourcing rules and bills of distribution do not take effect until they are assigned to a part or a range of parts. (See: Assigning Sourcing Rules and Bills of Distribution.)
Bills of Distribution
Bills of distribution define the sourcing strategies of several organizations. In other words, a bill of distribution is library of sourcing strategies. For instance, the sourcing strategy described in SR–C01 could apply to different organizations at different periods. You cannot do this with sourcing rules because you have to apply the strategy to one organization or all organizations.
In another example, an item is made in a manufacturing center and supplied to a distribution center, which in turn supplies three sales offices. Instead of using five different local sourcing rules, you could set up a three-level replenishment hierarchy with a bill of distribution for the item. This bill would specify how the item is sourced at each level.
Both sourcing rules and bills of distribution have effective dates, periods during which the scheme is valid. For each period, you can specify a list of sources, type, allocation percentage, rank, shipping method, and intransit time.
You cannot apply sourcing rules and bills of distribution (make them Planning Active) until the sum of the allocation percentages equals 100. Secondly, sourcing rules and bills of distribution do not take effect until they are assigned to a part or a range of parts. (See: Assigning Sourcing Rules and Bills of Distribution.)
Example - Sourcing Rule/Bills of Distribution
In the following scenario, distribution centers SFD and NYD receive finished goods from manufacturing plan SAC:
Sourcing rule SR-C02 describes the replenishment of SFD by SAC. Since no other plants supply the part (which is assigned to this rule separately), the allocation is 100%. SR-C02 is a local sourcing rule because it applies to SFD only. Similarly, SR-C03 describes the replenishment of NYD by SAC.
The bill of distribution (BR–E01 in this example) can define a specific set of receiving organizations, and for each organization it can define any number of shipping organizations - each with its own allocation percentage, ranking, and shipping method. Bills of distribution are more flexible than sourcing rules because, for each organization you list in the bill, you define a range of dates and a sourcing strategy to apply within those dates. Sourcing rules can only define the dates and strategy for one organization or all the organizations in your enterprise.
The following scenario illustrates this flexibility:
As the demand from NYD expands and exceeds SAC's capacity to meet the demand, the enterprise decides to build a new plant, called NYC. While NYC is brought online, SAC continues to meet 100% of demand from NYD. From 1-JUL, however, NYC begins to supply a small percentage of this demand, taking some of the burden away from SAC. The planning process can quickly and easily support this transition. Sourcing rule SR-C04 can define the dates during which the transition will occur, include NYC, and split the demand replenishment between it and SAC. Bill of distribution BR-E01 can accomplish this as well, but the bill can incorporate it into an enterprise–wide sourcing strategy.
You can define sourcing rules that specify how to replenish items in an organization, such as purchased items in plants. Sourcing rules can also specify how to replenish all organizations, as when the entire enterprise gets a subassembly from a particular organization.
If there are conflicts in Sourcing, a predetermined hierarchy will resolve the sourcing conflict. For instance, if you assign a bill of distribution to an organization AUS that tells it to source the part from another organization NYC, you can still define a local sourcing rule at organization AUS to source the part from yet another organization SAC. In this case, the local sourcing rule overrides the bill of distribution.
The planning assignment set holds information for:
Sales order global distribution
Organization-to-organization sourcing
Watch for conflicts between sourcing rules for external demands and sourcing rules for internal demands. For example:
External demand for an item is sourced globally from either organizations M1 or M2. The sourcing rule is Transfer from with M1, M2. assigned at the item level
Internal demand at organization M1 is sourced from organization M3. The sourcing rule is Transfer from with M3 assigned at the item/org level. The item/org assignment tells the planning engine that this sourcing rule applies to the sourcing for internal demand and not for the external demand.
If you assign a sourcing rule for external demand at the item level, then you cannot assign a sourcing rule for internal demand at that level.
Ship methods apply to Buy from and Transfer from sourcing rules. To create the ship methods:
Navigate to Oracle Inventory > Shipping Networks
Navigate to the detail region
Navigate (M) Tools> Shipping Methods
To define a sourcing rule
Navigate to the Sourcing Rule window.
Enter a unique sourcing rule name.
Indicate whether this sourcing rule is used for all organizations (global) or a single organization (local). If the sourcing rule is local, you must enter an organization name; otherwise, your current organization will be the receiving organization.
Choose Copy From to copy the effectivity dates and shipping organization from another sourcing rule into this one.
Enter effectivity dates. You must enter a start date, but entering an end date is optional.
For each range of effectivity dates, you can include multiple shipping organizations. For each shipping organization you want to include, select a sourcing type to specify whether you make, buy, or internally transfer the item. You can also copy a list of shipping organizations from an existing sourcing rule. If you enter a customer organization as the receiving organization, then you cannot select a supplier organization as the shipping organization.
Enter an allocation percentage for each shipping organization. Allocation percentage includes the number of planned orders issued to the part for the entire the planning horizon. Your total allocation may not exceed 100. If the allocation percentage for all the shipping organizations included within a range of effectivity dates equals 100, Planning Active is checked. If the sourcing rule is not planning active, the planning process will not use the rule to assign planned orders.
Enter a numeric rank value to prioritize each sourcing type. If you have two sources with the same allocation percentage, planned orders are sourced from the highest rank first.
Select a shipping method, such as FEDEX, UPS, or rail. (See: Defining Shipping Methods, Oracle Inventory User's Guide.
Save your work.
To copy shipping organizations from an existing sourcing rule
This feature allows you to include long, previously defined lists of shipping organizations without manual entry.
Select a sourcing type to specify whether you make, buy, or internally transfer the item.
Choose Copy Shipping Orgs From.
In the Find window, select a sourcing rule that includes the shipping organizations you want to duplicate in this new sourcing rule.
Choose OK.
To purge a sourcing rule
Select a sourcing rule name.
Choose Purge.
You can define bills of distribution that specify a multilevel replenishment network of warehouses, distribution centers, manufacturing centers (plants), and trading partners.
To define a bill of distribution
Navigate to the Bill of Distribution window.
Enter a unique bill of distribution name.
If the allocation percentage for this bill of distribution equals 100, Planning Active is checked. (See Step 7.)
Note: You cannot set the allocation percentage to less than or greater than 100 for sourcing rules that are already assigned in assignment sets
Choose Copy From to copy the receiving and shipping organization information from another bill of distribution into this one.
Enter the effectivity dates for each receiving organization in this bill of distribution.
For each receiving organization, you can enter a number of shipping organizations. For each shipping organization, select a sourcing type to specify whether you make, buy, or internally transfer the item. You can also copy a list of shipping organizations from an existing bill of distribution.
Note: Suppliers and supplier sites must be predefined in Oracle Payables. See: About Suppliers, Oracle Payables User's Guide
Enter an allocation percentage for each shipping organization. Allocation percentage includes the number of planned orders issued to the part for the entire the planning horizon. Your total allocation may not exceed 100. If the allocation percentage for all the shipping organizations included within a range of effectivity dates equals 100, Planning Active is checked. If the sourcing rule is not planning active, the planning process will use the rule to assign planned orders.
Note: For bills of distribution that are already named in assignment sets, you cannot set the allocation percentage to less than or greater than 10
Enter a numeric rank value to prioritize each sourcing type. If you have two sources with the same allocation percentage, planned orders are sourced in rank order.
Select a shipping method, such as FEDEX, UPS, or rail. See: Defining Shipping Methods, Oracle Inventory User's Guide.
Save your work.
To copy shipping organizations from an existing bill of distribution
This feature allows you to include long, previously defined lists of shipping organizations without manual entry.
Select a sourcing type to specify whether you make, buy, or internally transfer the item.
Choose Copy Shipping Orgs From.
In the Find window, select a bill of distribution that includes the shipping organizations you want to duplicate in this new bill of distribution.
Choose OK.
To purge a bill of distribution
Select a bill of distribution name.
Choose Purge.
Once you have defined your sourcing rules and bills of distribution, you must assign them to particular items and/or organizations. These assignments are grouped together in assignment sets. This is where your various sourcing strategies define a particular supply chain network.
Each assignment set to represents selection of organizations and/or items you want planned. To influence the planning process, you must include an assignment set in your plan options.
In an assignment set can assign your sourcing rules and bills of distribution at different levels, as follows:
Item-Instance: An item across all organizations. If the Item field is empty, use the Reduce Criteria Window to restrict the selection.
Item-Instance-Organization: A single item in an inventory organization
Instance-Organization: All items in an inventory organization
Category-Instance: Categories of items
Category-Instance-Organization: Categories of items in an inventory organization
Instance: All organizations
These levels allow you to assign a replenishment rule to as many or as few items as possible. For example, a category of items could be defined as packaging material, and a sourcing rule that identifies the suppliers could be assigned.
To assign a sourcing rule or bill of distribution
Navigate to the Sourcing Rule/Bill of Distribution Assignments window.
Enter an assignment set name and description.
Note: The assignment specified in profile option MRP: Default Sourcing Assignment Set is the only one used by Oracle Purchasing for its processing
Select an Assigned To type.
Note: You can assign a sourcing rule or bill of distribution to a category only if you have updated the profile option MRP:Sourcing Rule Category Set. See: MRP:Sourcing Rule Category Set
Enter an organization name, if the Assigned To type requires one.
Note: You cannot assign customers modelled as organizations to a global sourcing rule
Enter the name of the customer to which you want to assign a sourcing rule or bill of distribution.
Enter the specific site to which you want to assign a sourcing rule or bill of distribution.
Enter an Item/Category if you selected Item or Item-Org as the Assign To type.
Enter the sourcing rule or bill of distribution as the Type.
Enter the name of the sourcing rule or bill of distribution.
Save your work.
To purge a sourcing rule or bill of distribution
Select an assignment set name.
Choose Purge.
In the following table, rows below override rows above them. Columns on the right override columns on the left.
A global sourcing rule has an unspecified receiving organization.
Assignment Scope | Global Sourcing Rule* | Local Sourcing Rule | Bill of Distribution |
---|---|---|---|
Global | Yes | No | Yes |
Organization | No | Yes | No |
Category of Item | Yes | No | Yes |
Category of Items in an Organization | No | Yes | No |
Item | Yes | No | Yes |
Items in an Organization | No | Yes | No |
Since not all assignment types are valid for both sourcing rules and bills of distribution, the effect of the Sourcing Rules vs. Bill of Distribution Assignments table is illustrated in a linear hierarchy in the following table. The rows below override rows above them.
Assignment Scope | Sourcing Mechanism |
---|---|
Global | Global Sourcing Rule |
Global | Bill of Distribution |
Organization | Local Sourcing Rule |
Category of Item | Global Sourcing Rule |
Category of Item | Bill of Distribution |
Category of Items | Local Sourcing Rule |
in an Organization | |
Item | Local Sourcing Rule |
Item | Bill of Distribution |
Items in an Organization | Local Sourcing Rule |
You can quickly and easily retrieve sourcing rules for reference. After retrieving a sourcing rule, you can display it in a convenient, hierarchical representation, or you can locate the assignment sets in which it is assigned.
To view sourcing rules
Navigate to the View Sourcing Rule or Sourcing Rule window.
Place your cursor in the Name or Description field and select Find or Find All from the query menu.
Choose View to launch the Object Navigator and display the graphical view of your sourcing rule.
With the Object Navigator, you can display your sourcing rule in a visual hierarchy. Each element in the sourcing rule is displayed in a rectangular node, with connecting lines that depict the nodes' relationships to each another (known as the data flow). The nodes are also color-coded for easy identification, and other aspects of the data flow can be changed to meet specific requirements.
To view assignments for your sourcing rules
Sourcing rules govern replenishment of specific items in your enterprise based on the rule's assignment. Sourcing rules can be assigned to an item, and item in an organization, an organization, a category of items, a category of items in an organization, or to all items.
When modifying or viewing a sourcing rule, you can quickly refer to all the assignment sets in which the rule participates. You can also refer to the assignment level assigned to the rule. For more information about assignment sets, see: Assigning Sourcing Rules and Bills of Distribution.
Navigate to the View Sourcing Rule or Sourcing Rule window.
Place your cursor in the Name or Description field and select Find or Find All from the Query menu.
Choose Assignment Set. The list that appears includes all sets in which the current rule participates.
For each Sourcing Rule and Bill of Distribution in the Assignment Set, you can review the following information:
Assigned to: Each Sourcing and Bill of Distribution can be assigned:
A single item (across all organizations)
An item in a specific organization
All items in a specific organization
A category of items
A category of items in an organization
All items in all organizations (globally)
Note: You can assign a sourcing rule to a category only if you have updated the profile option MRP:Sourcing Rule Category Set. See: MRP:Sourcing Rule Category Set
Organization: Rules or bills assigned to an organization, a category of items in an organization, or an item in an organization will also display the name of that organization.
Customer and Customer Site: Rules or bills associated with a customer will also display this information.
Item/Category: Rules or bills assigned to an item or an item in an organization will display with the associated item or category of items (if the profile option has been updated to include categories).
You can quickly and easily retrieve bills of distribution for reference. After retrieving a bill of distribution, you can display it in a convenient, hierarchical representation, or you can locate the assignment sets in which it is assigned.
To view bills of distribution
Navigate to the View Bill of Distribution or Bill of Distribution window
Place your cursor in the Name or Description field and select Find or Find All from the Query menu.
Choose View to launch the Object Navigator and display the graphical view of your bill of distribution.
With the Object Navigator, you can display your bill of distribution in a visual hierarchy. Each element in the bill is displayed in a rectangular node, with connecting lines that depict the nodes' relationships to each another (known as the data flow). The nodes are also color–coded for easy identification, and other aspects of the data flow can be changed to meet specific requirements.
To view assignments for your bills of distribution
Bills of distribution govern replenishment of specific items in your enterprise based on the bill's assignment. Bills of distribution can be assigned to an item, and item in an organization, an organization, a category of items, a category of items in an organization, or to all items.
When modifying or viewing a bill of distribution, you can quickly refer to all the assignment sets in which the bill participates. You can also refer to the assignment level assigned to the rule. For more information about assignment sets, see: Assigning Sourcing Rules and Bills of Distribution.
Navigate to the View Bills of Distribution or Bill of Distribution window
Place your cursor in the Name or Description field and select Find or Find All from the Query menu.
Choose Assignment Set. The list that appears includes all sets in which the current bill participates.
For each Sourcing Rule and Bill of Distribution in the Assignment Set, you can review the following information:
Assigned to: Each Sourcing and Bill of Distribution can be assigned:
A single item (across all organizations)
An item in a specific organization
All items in a specific organization
A category of items
A category of items in an organization
All items in all organizations (globally)
Note: You can assign a sourcing rule to a category only if you have updated the profile option MRP:Sourcing Rule Category Set. See: MRP:Sourcing Rule Category Set
Organization: Rules or bills assigned to an organization, a category of items in an organization, or an item in an organization will also display the name of that organization.
Customer and Customer Site: Rules or bills associated with a customer will also display this information.
Item/Category: Rules or bills assigned to an item or an item in an organization will display with the associated item or category of items (if the profile option has been updated to include categories).
Once you have defined your sourcing rules and bills of distribution, you must assign them to particular items and/or organizations. These assignments are grouped together in assignment sets. This is where your various sourcing strategies define a particular supply chain network.
You can quickly view your assignment sets to review particular sourcing schemes, locate particular assignments of sourcing rules or bills of distribution, or view the supply chain bill for a particular assignment set.
To view sourcing rule and bill of distribution assignments
Navigate to the Sourcing Rule/Bill of Distribution Assignments window.
Place your cursor in the Assignment Set or Description field and select Find or Find All from the Query menu.
Select an assignment set from the list.
For each Sourcing Rule and Bill of Distribution in the Assignment Set, you can review the following information:
Assigned to: Each Sourcing and Bill of Distribution can be assigned:
A single item (across all organizations)
An item in a specific organization
All items in a specific organization
A category of items
A category of items in an organization
All items in all organizations (globally)
Note: You can assign a sourcing rule to a category only if you have updated the profile option MRP:Sourcing Rule Category Set. See: MRP:Sourcing Rule Category Set.
Organization: Rules or bills assigned to an organization, a category of items in an organization, or an item in an organization will also display the name of that organization.
Item/Category: Rules or bills assigned to an item or an item in an organization will display with the associated item or category of items (if the profile option has been updated to include categories).
To view details of a particular rule or bill
When viewing an assignment set, you can quickly retrieve full details on any sourcing rule or bill of distribution named in the set.
In the Assignments region, place your cursor in any field on the row containing the rule or bill you want.
Choose View Sourcing Rule/BOD
When there are multiple ship methods possible between a customer site and an internal organization, Oracle Advanced Supply Chain Planning evaluates the delivery time and selects the ship method that is most appropriate. Each ship method has a specific intransit lead-time. If the default ship method or the current ship method on the sales order does not meet the demand on time, you can evaluate multiple ship methods and select an alternate ship method that meets the demand on time.
For example, you may want to use a cost effective ship method such as ocean shipment or ground shipment for most part and switch to airfreight for certain orders to avoid late orders. With the automatic selection of ship methods, Oracle Advanced Supply Chain Planning suggests change in ship methods to meet orders on time by using ship methods that have shorter lead-times. Therefore, you can use the most cost effective ship methods for normal operations, but decide to use alternate ship methods if the orders are going to be late.
If you use cost based optimization, Oracle Advanced Supply Chain Planning selects the ship method based on costs associated with the specific ship method and the optimization objectives. You can send the selected ship method to Oracle Order Management along with the recommendation for the ship from organization. These planning decisions are communicated to Oracle Order Management using the Release process.
Note: Intransit lead-time depends on the ship method used to transport goods.
You can model alternate ship methods for:
Sales orders bound to a customer
Planned order between two organizations
Planned orders sourced at a supplier or planned orders with buy source
You need to complete setup steps in the following Oracle products to setup selection of outbound ship method:
Oracle Shipping
Oracle Inventory
Oracle Advanced Supply Chain Planning
Perform the following setup steps in both the execution as well as planning server.
Select the Manufacturing and Distribution Manager responsibility.
Navigate to Order Management > Shipping > Setup > Regions and Zones.
Set up ship methods.
Optionally set up zones to group customer sites and supplier sites.
For more details, see Oracle Shipping Execution User's Guide.
Navigate to Inventory > Set up > Organizations > Inter-Location Transit Times.
Set up ship methods and intransit lead-times between the following entities:
Organization and Customer sites
Between Organizations
From supplier site to Organizations
To model transit lead-time between customers and organizations, include it in supplier processing lead time
For more details, see Oracle Inventory User's Guide.
Navigate to Advanced Supply Chain Planner > Sourcing > Sourcing Rules.
Define sourcing rules or bills of distribution. Create multiple entries for the same source and select different ship methods and intransit lead-times in each entry.
Navigate to Sourcing > Assignment set
Assign sourcing rules at customer site level or one of the following levels:
Item-Instance-Region
Category-Instance-Region
Instance-Region
Assign sourcing rules to items.
Select the assignment set in the plan option.
Note: If destination is an Org, the level assignment can be at Item-Instance-Org, Category-Org etc.
Run a plan with the assignment set that contains sources and alternate ship methods.
Review the alternate ship method used/ ship method changed exceptions.
Drill down to Exception Details and review old and new ship methods and intransit lead-times.
Navigate to the Supply/Demand window and select the sales orders for release.
Release the sales orders with the selected ship method from the Planner Workbench.
Review the results in Oracle Order Management.
Note: The ship method is automatically changed on the sales order line.
Work with your suppliers to use the suggested ship method.
You can also evaluate and select ship methods between two internal organizations each time you run the plan.
This section explains supplier capacity:
Constraints
Set up
Setting by time periods
Oracle ASCP considers the following supplier capacity constraints.
You can allocate planned orders to sources taking historical allocations into account. Planning uses history to determine the allocations necessary to achieve your targeted allocations.
You can specify the capacity of individual suppliers to supply specific items. You can allocate planned orders taking capacity constraints of the suppliers into account. Planning uses the ranking information you specify and first attempts to source the planned orders with the primary sources. If the primary source does not have the capacity to fulfill the demand, planning suggests sourcing with the alternative sources you have specified, in the priority you have specified.
You can specify supplier-specific order modifiers at an item/supplier site level. Planning respects the order modifier quantities defined for the sources of the item. This enables you to specify more precisely the conditions related to each source.
You can specify supplier-specific lead-times for items. This ensures orders are placed early enough to provide the supplier time to react to your needs.
Use receiving calendars to specify the available delivery dates to:
An organization
An organization from a specific carrier
The reception schedule contains the dates that organizations can receive inbound shipments from carriers. The planning engine adjusts planned orders so that they are due on available dates in the reception schedule.
You can define capacity tolerance percentages that vary over time for each source. This allows the allocation of demand over capacity by a variable amount depending on the time in the future.
The planning engine accumulates supplier capacity on all workdays in the owning organization's manufacturing calendar. Capacity that accumulates on a given day is available for use the next day.
To specify unavailable supplier capacity for a certain supplier (for example, a shutdown), specify zero capacity for that period in the approved supplier list.
You can configure accumulation of supplier capacity depending on when your supplier starts production.
If the supplier has ongoing production, you might assume that material is always in process. Since the supplier can ship almost immediately, you might want to accumulate supplier capacity from the plan start date. Set profile option MSC: Supplier Capacity Accumulation (multiplier) to 0. This table shows an example of this scenario with Approved Supplier List Supplier Capacity at 10 each per day.
Schedule Entity | Th | Fr | Sa | Su | Mo | Tu | We | Th | Fr | Sa | Su | Mo | Tu | We |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Daily supplier capacity in source instance | - | 10 | - | - | 10 | 10 | 10 | 10 | 10 | - | - | 10 | 10 | 10 |
Daily supplier capacity in planning instance | - | 10 | - | - | 10 | 10 | 10 | 10 | 10 | - | - | 10 | 10 | 10 |
Cumulative supplier capacity in planning instance | - | 10 | - | - | 20 | 30 | 40 | 50 | 60 | - | - | 70 | 80 | 90 |
If the supplier starts making new material when it receives your order, it can ship after their lead-time. You might want to accumulate supplier capacity at the Approved Supplier List Processing Lead-time or a multiple of it. Set profile option MSC: Supplier Capacity Accumulation (multiplier) to 1 (for the Approved Supplier List Processing Lead-time) or another whole number (for a multiple of the Approved Supplier List Processing Lead-time.
This table shows an example of this scenario with quantity of 10 each per day and Approved Supplier List Processing Lead-time of 6 days. If there is no Approved Supplier List Processing Lead-time, the planning engine uses item attribute Processing Lead-time.
Schedule Entity | Th | Fr | Sa | Su | Mo | Tu | We | Th | Fr | Sa | Su | Mo | Tu | We |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Daily supplier capacity in source instance | - | 10 | - | - | 10 | 10 | 10 | 10 | 10 | - | - | 10 | 10 | 10 |
Daily supplier capacity in planning instance | - | - | - | - | - | - | - | 10 | 10 | - | - | 10 | 10 | 10 |
Cumulative supplier capacity in planning instance | - | - | - | - | - | - | - | - | 10 | - | - | 20 | 30 | 40 |
The planning engine does not consume supplier capacity with purchase orders unless you specify. In general, purchase order deliveries that consume supplier capacity can result in unnecessary reschedule out exception messages. They have consumed supplier capacity in the past; since the planning engine does not track past supplier capacity, it sees not enough supplier capacity between the plan start date and the purchase order delivery dock date.
You can configure purchase order consumption of supplier capacity in several ways depending on the amount of feedback that you receive from your suppliers:
Constrain new orders only
Constrain new orders only, purchase order placed early
Integrate with Oracle Collaborative Planning
To configure purchase order consumption of supplier capacity, set the following profile options:
MSC: Purchase Order Dock Date Calculation Preference: Specifies the purchase order date that the planning engine uses as the Dock Date, the scheduled date of purchase order receipt. If you select Promise Date, the Dock Date is Promise Date. If you select Promise Date and the delivery has not been acknowledged (Promise Date is blank), Dock Date is Need By Date. If you select Need By Date, Dock Date is Need By Date.
It also specifies whether purchase orders without promise dates consume supplier capacity. If you select Promise Date, the planning engine consumes supplier capacity with purchase order deliveries that have not been acknowledged (Promise Date is blank). If you select Need By Date, it does not.
MSC: Supplier Capacity Accumulation (multiplier): Specifies the date that the planning engine begins supplier capacity accumulation. You enter it as a multiplier of the Approved Supplier List Processing Lead-time.
To begin accumulation at the Approved Supplier List Processing Lead-time, enter 1 (the default). To begin accumulation at the plan start date, enter 0. To begin accumulation at a multiple of the Approved Supplier List Processing Lead-time, enter another whole number.
Use this scheme with the following business situation and assumptions:
The planning engine consumes supplier capacity and lead-time for planned orders after the supplier lead-time.
You typically place purchase orders just outside the supplier lead-time. The supplier starts to build supplies when you place the purchase order and they need the entire lead-time. If you typically place purchase orders early, consider using the Constrain new orders only, purchase order placed early scheme.
The supplier will deliver purchase orders on time.
The planning engine does not consume supplier capacity for purchase orders.
To implement this supplier capacity accumulation scheme, set profile option:
For example, this table shows the planning engine behavior for this scheme:
Approved Supplier List Supplier Capacity of 10 each per day and Approved Supplier List Processing Lead-time of 1 day.
The planning engine begins to accumulate supplier capacity on Friday which is available for receipt of new planned orders or requisitions on Monday.
The planning engine does not consume supplier capacity against the purchase order for 50. It does not issue an Orders to be rescheduled out exception message because of lead-time.
Schedule Entity | Th | Fr | Sa | Su | Mo | Tu | We | Th | Fr | Sa | Su | Mo | Tu | We |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Purchase orders | - | - | - | - | - | 50 | - | - | - | - | - | - | - | - |
Purchase requisitions | - | - | - | - | - | - | - | 30 | - | - | - | - | - | - |
Planned orders | - | - | - | - | - | - | - | - | - | - | - | 20 | - | - |
Daily supplier capacity in planning instance | - | 10 | - | - | 10 | 10 | 10 | 10 | - | - | - | 10 | 10 | 10 |
Cumulative supplier capacity in planning instance | - | - | - | - | 10 | 20 | 30 | 10 | 10 | - | - | 0 | 10 | 20 |
Use this scheme with the following business situation and assumptions:
The planning engine consumes supplier capacity and lead-time for planned orders after the supplier lead-time.
You typically place purchase orders earlier than just outside the supplier lead-time. The supplier starts to build supplies when you place the purchase order and they need the entire lead-time. If you typically do not place purchase orders early, consider using the Constrain new orders only scheme.
You maintain the purchase order delivery promise date within the supplier lead-time. Purchase order deliveries with no promise date have not been accepted by the supplier.
The supplier will deliver purchase orders on time.
The planning engine does not consume supplier capacity for purchase orders that have been acknowledged by the supplier.
To implement this supplier capacity accumulation scheme, set profile option:
The planning engine behaves as follows for this scheme:
For example, the supplier lead-time for an item is 5 days and the supplier capacity is 100 per day.
The planning engine begins to accumulate supplier capacity on day 5 which is available for receipt of new planned orders or requisitions on day 6.
The planning engine does not consume supplier capacity against purchase order deliveries with a promise date. It uses the promise date as the dock date.
The planning engine does not consumes supplier capacity against purchase order deliveries without a promise date. However, it may issue an Orders to be rescheduled out exception message because of lead-time and a Supplier capacity overloaded exception message because of supplier capacity.
You use Oracle Collaborative Planning to produce and send (publish) order forecasts from material plans to suppliers, either:
Unconsumed: Purchase orders, purchase requisitions, and planned orders
Consumed: Purchase requisitions and planned orders
The supplier responds to each statement of demand with:
Acknowledgements: Quantity and date tied to individual purchase order deliveries.
If the supplier uses iSupplier portal to accept purchase orders, the Oracle Advanced Supply Chain Planning collections process sets the promise date to the need by date for accepted purchase order deliveries.
Otherwise, use this information to manually update the promise date for each purchase order delivery. If the supplier acknowledges several partial quantity deliveries on different dates, manually split the deliveries and enter promise dates for each one.
Supply commit: Tied to the unconsumed portion of your forecast.
If the supplier uses Oracle Advanced Supply Chain Planning, they publish a supply commit that represents existing supplies and planned orders for the top level item that are pegged to forecasts and sales orders for a customer. To receive the supplier commit, run concurrent process Receive Supplier Capacity before running collections.
Otherwise, they provide aggregated time phased supply values into Oracle Supply Chain Collaboration using a flat file, an XML transaction, or manual entry.
You uses the supplier responses to constrain your material plan. The planning engine uses them as the supplier's commitment of capacity instead of the capacity statements in the approved supplier list.
Use this scheme with the following business situation and assumptions:
You use Oracle Collaborative Planning
You issue relatively few purchase order deliveries outside of the dates and quantities that Oracle Advanced Supply Chain Planning recommends.
To implement this supplier capacity accumulation scheme, set profile option:
For example, you run an unconstrained plan. This table shows the supplies for supplier 1, supplier site 1, item A. Although you have issued purchase orders 2 and 3, the supplier has not yet acknowledged them.
Order Type | Order Number | Order Line | Quantity | Need by Date | Promise Date | Dock Date |
---|---|---|---|---|---|---|
Purchase order | 1 | 1 | 20 | 29 April | 29 April | 29 April |
Purchase order | 1 | 2 | 100 | 1 May | 3 May | 3 May |
Purchase order | 2 | 1 | 10 | 6 May | - | 6 May |
Purchase order | 3 | 1 | 100 | 29 April | - | 29 April |
Purchase requisition | 100 | 1 | 200 | 13 May | - | 13 May |
Purchase requisition | 101 | 1 | 200 | 10 May | - | 10 May |
Purchase requisition | 102 | 1 | 300 | 14 May | - | 14 May |
Planned order | 301 | - | 100 | 20 May | - | 20 May |
Planned order | 302 | - | 100 | 27 May | - | 27 May |
Planned order | 303 | - | 100 | 3 June | - | 3 June |
You use Oracle Collaborative Planning to publish a forecast to Supplier 1 for item A of purchase orders, purchase requisitions, and planned orders based on dock date. This table shows the forecast.
Quantity | Date |
---|---|
20 | 29 April |
100 | 1 May |
10 | 6 May |
100 | 29 April |
200 | 13 May |
200 | 10 May |
300 | 14 May |
100 | 20 May |
100 | 27 May |
100 | 3 June |
Supplier 1 runs a constrained plan that results in the supply and demand situation for supplier site 1, Item A. This table shows the details of supplier 1 supplies that are pegged to your demands.
Supplier 1:
Has received sales orders for purchase order 1, lines 1 and 2; they consume your forecast for the demands on 29 April and 03 May.
Has not received sales orders against the demand that resulted in purchase orders 2 and 3; they do not consume your forecast.
Order Type | Order Number | Order Line | Quantity | Date |
---|---|---|---|---|
Sales order | 1 | 1 | 20 | 29 April |
Forecast | - | - | 100 | 29 April |
On hand | - | - | 20 | 29 April |
On hand | - | - | 100 | 29 April |
Sales order | 1 | 2 | 100 | 3 May |
On hand | - | - | 100 | 29 April |
Forecast | - | - | 10 | 6 May |
Oh hand | - | - | 20 | 29 April |
Forecast | - | - | 200 | 10 May |
WIP job | 1114 | - | 200 | 10 May |
Forecast | - | - | 200 | 13 May |
WIP job | 1113 | - | 200 | 13 May |
Forecast | - | - | 300 | 14 May |
Planned order | 3330 | - | 300 | 14 May |
Forecast | - | - | 100 | 20 May |
Planned order | 3331 | - | 100 | 20 May |
Forecast | - | - | 100 | 27 May |
Planned order | 3332 | - | 100 | 27 May |
Forecast | - | - | 100 | 3 June |
Planned order | 3333 | - | 100 | 3 June |
Supplier 1 uses Oracle Collaborative Planning to publish a supply commit with only supplies that are pegged to your forecast. This table shows the supplies that are pegged to your forecast.
Order Type | Order Number | Quantity | Date |
---|---|---|---|
On hand | - | 100 | 29 April |
On hand | - | 10 | 29 April |
WIP job | 1114 | 200 | 10 May |
WIP job | 1113 | 200 | 13 May |
Planned order | 3330 | 300 | 14 May |
Planned order | 3331 | 100 | 20 May |
Planned order | 3332 | 100 | 27 May |
Planned order | 3333 | 100 | 3 June |
This table shows the supply commit which is the statement of supplier capacity through its last entry date of 3 June. If an item-supplier site does not appear in the supply commit, the planning engine uses the Approved Supplier List Supplier Capacity.
The sales orders in the supplier's system that represent your purchase orders should be consumed during the supplier's forecast consumption process. The supplies pegged to these sales orders should not be in the supply commit.
Quantity | Due Date |
---|---|
100 | 29 April |
10 | 29 April |
200 | 10 May |
200 | 13 May |
300 | 14 May |
100 | 20 May |
100 | 27 May |
100 | 3 June |
You run a constrained plan based on the supply commit. The planning engine must schedule the items in this table.
Order Type | Order Number | Order Line | Quantity | Need by Date | Promise Date | Dock Date |
---|---|---|---|---|---|---|
Purchase order | 1 | 1 | 20 | 29 April | 29 April | 29 April |
Purchase order | 1 | 2 | 100 | 1 May | 3 May | 3 May |
Purchase order | 2 | 1 | 10 | 6 May | - | 6 May |
Purchase order | 3 | 1 | 100 | 29 April | - | 29 April |
This table shows how planning engine consumes supplier capacity in your constrained plan:
Since the supplier has acknowledged both purchase order deliveries in purchase order 1 (they have Promise Date), the planning engine does not consume supplier capacity against them.
Since the supplier has not yet acknowledged purchase order 2 and purchase order 3 (they do not have Promise Date), the planning engine consumes supplier capacity against them.
The planning engine consumes supplier capacity against the purchase requisitions and planned orders.
Date | Available Capacity | Required Capacity | Consuming Entity |
---|---|---|---|
29 April | 110 | 110 | Purchase orders 2 and 3 (no Promise Date) |
10 May | 200 | 200 | Purchase requisition 100 |
13 May | 200 | 200 | Purchase requisition 200 |
14 May | 300 | 300 | Purchase requisition 300 |
20 May | 100 | 100 | Planned order 3331 |
27 May | 100 | 100 | Planned order 3332 |
3 June | 100 | 100 | Planned order 3333 |
Please note the following when setting up supplier capacity:
It is important to select Global in the Supplier Capacity window.
Processing lead-time can be selected in number of days. This is a lead-time at the supplier end before the order is processed
The delivery calendar should be entered to reflect the days the supplier can deliver the order. Examples: M, W or M, W, F
Minimum order quantity can be entered if the supplier has to deliver some minimum quantity if an order is placed. For example, if you have set the minimum order quantity to 25, and if 20 is ordered, 25 will be delivered
Fixed lot multiple value needs to be entered if the supplier delivers only in certain multiples. For example, if you have set the fixed lot multiple to 5, if quantity 103 is ordered, 105 will be delivered
The capacity area of the Supplier Capacity window is used to specify supplier's capacity for a specific time period. The supplier could have different capacity on different days. For examples, from 10/11/00 to 10/22/00, the supplier could have 50 units/day, and from 10/23/00 to 10/31/00, the supplier could have 70 units/day
Tolerance fence values can be determined to reflect how much capacity a supplier can adjust if given enough advanced notice. For example, on 10/24/00, if tolerance percentage is 10, this means that on 10/24/00, the capacity will be 77 units (in the above example)
Supplier capacity can vary by time period. You can specify one daily capacity for period 1 and a different capacity for period 2. Time periods are specified from a start date to an end date.
Note: The methods you use to set capacity by time period vary depending on which version of Oracle Applications you are using.
The planning engine considers supplier capacity as infinite after the end date of the last item-supplier-supplier site capacity entry. If there are no item-supplier-supplier site capacity entries, it considers supplier capacity as infinite for the entire planning horizon
Navigate to the Purchasing module (you must use the Manufacturing and Distribution Manager responsibility).
Choose Purchasing > Supply Base > Approved Suppliers List.
Choose the searchlight icon in the toolbar to search for an item.
The Find ASL Item/Commodity window appears.
Choose an item or commodity.
Supplier information appears.
Choose a supplier by clicking in the Supplier field.
Select Attributes.
Choose the Planning Constraints tab.
Enter the numbers of days in advance and the tolerance percentage.
For example, entering 15 days and 5% means that within 15 days, the supplier can increase the capacity by 5%.
For more information on the following topics, see . Setting Up the Supply Chain.
You can define a rank for each source of supply named in the sourcing rules and BODs. You can then define a sourcing percentage for each source within a rank, allowing you to allocate a portion of the total orders to each source.
In unconstrained plans, demand can be divided and allocated to multiple sources according to target sourcing percentages set in the rules.
The data in these tables demonstrate how allocation percentages for planned orders are divided according to ranking information.
The demand for Item A is shown in the following table.
Demand | Due Date | Quantity |
---|---|---|
1 | 07/15 | 300 |
Sourcing for Item A is shown in the following table.
Item | Source | Rank | Percentage | Effective From | Effective To |
---|---|---|---|---|---|
A | S1 | 1 | 40 | 05/15 | 12/31 |
A | S2 | 1 | 30 | 05/15 | 12/31 |
A | S3 | 1 | 30 | 05/15 | 12/31 |
Demand is assigned using the ranking information and calculating the percentages assigned to each source to calculate the planned orders.
S1: 300 x 0.40 = 120
S2: 300 x 0.30 = 90
S3: 300 x 0.30 = 90
Three planned orders are created for the quantities of 120, 90, and 90 respectively.
Note: All planned orders generated in this process are subject to item order modifiers.
If you run a constrained plan and did not use optimization, the supplies calculated above will be scheduled based on the supplier capacity established for the item. If optimization is used, Oracle ASCP will not split the orders per the sourcing splits in sourcing rules; it will evaluate the suppliers by rank and considers supplier capacities to come up with allocations to suppliers. The rank, lead-time and capacity of 3 suppliers is shown in the following table.
Supplier | Rank | Lead Time | Capacity |
---|---|---|---|
Supplier 1 | 3 | 2 | 100 |
Supplier 2 | 2 | 2 | 100 |
Supplier 3 | 1 | 2 | 100 |
You can allocate planned orders taking into account historical allocations in unconstrained plans. The enhanced sourcing logic considers historical allocations and allows the splitting of demand to achieve target sourcing percentages.
The next eight tables contain the set up data required to explain the example. The ninth table has historical allocation data, which results from previous allocations.
This table shows demand for item A.
Demand for Item A | Due Date | Quantity |
---|---|---|
1 | 7/15/98 | 310 |
2 | 7/16/98 | 280 |
This table shows sourcing rules data for item A.
Item | Source | Rank | Percentage | Effective From | Effective To |
---|---|---|---|---|---|
A | S1 | 1 | 50 | 5/15/97 | 12/31/97 |
A | S2 | 1 | 50 | 5/15/97 | 12/31/97 |
A | S1 | 1 | 100 | 1/1/98 | 7/14/99 |
A | S2 | 2 | 60 | 1/1/98 | 7/14/99 |
A | S3 | 2 | 40 | 1/1/98 | 7/14/99 |
This table shows supplier capacity profile for item A.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 60 | 60 | 60 | 60 | 60 |
S2 | 80 | 80 | 80 | 80 | 80 |
S3 | 20 | 20 | 20 | 20 | 20 |
This table shows supplier capacity tolerance percentages for item A. The numbers in this table are from applying tolerance percentages to the supplier capacity profile; refer to those tables. For example, for supplier S1 on 7/16/98, total supplier capacity is 60 + 10%(60) = 66.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 0 | 10 |
S2 | 0 | 0 | 0 | 5 | 10 |
S3 | 0 | 0 | 0 | 5 | 10 |
S1 | 60 | 60 | 60 | 60 | 66 |
S2 | 80 | 80 | 80 | 84 | 88 |
S3 | 20 | 20 | 20 | 21 | 22 |
This table shows supplier delivery patterns for item A.
Source | Reception Pattern |
---|---|
S1 | Mondays and Wednesdays |
S2 | Mondays |
S3 | All days except Fridays |
This table shows supplier processing information for item A.
Source | Processing (days) |
---|---|
S1 | 3 |
S2 | 2 |
S3 | 2 |
This table shows order modifiers at each source for item A.
Source | Min. Order Quantity | Fixed Lot Multiple |
---|---|---|
S1 | 50 | 5 |
S2 | 25 | 25 |
S3 | 21 | 7 |
Order Modifiers for Item A:
Minimum Order Quantity: 17
Fixed Lot Multiple: 88
Lead Times for Item A:
Preprocessing: 0
Postprocessing: 1
This table shows historical allocation totals.
Source | Quantity |
---|---|
S2 | 1400 |
S3 | 1000 |
This table shows the horizontal plan.
Item A | 7/10/98 | 7/11/98 | 7/14/98 | 7/15/98 | 7/16/98 |
---|---|---|---|---|---|
Demand | 0 | 0 | 0 | 310 | 280 |
Excess Schedule Receipts | 0 | 0 | 0 | 16 | 0 |
Planned Orders - Org S1 | 0 | 0 | 288 | 0 | 0 |
Planned Orders - Org S2 | 0 | 0 | 125 | 100 | 0 |
Planned Orders - Org S3 | 0 | 0 | 21 | 56 | 0 |
Allocations for Demand #1
Allocation Calculation Using Historical Allocation Information and Target Percentages for Demand #1:
Quantity = 310
Due Date = 7/15/98 (Tuesday)
Note: The first date of planning horizon is 7/9/98. Only the last three rows in the source rules data table apply due to effectivity dates. S1 has rank 1 with allocation percentage = 100 (sourcing rules data table). This indicates that the system should allocate as much as possible to S1 before allocating the excess to other sources.
Based on the input demand data, we can now calculate how the demand for Item A will be satisfied.
Monday 7/14/98 is the latest reception date (supplier delivery patterns table) before due date (7/15/98). This respects the processing and postprocessing lead-times (supplier processing information table).
Cumulative capacity = 180 from supplier capacity profile with tolerance percentages table (tolerance percentage = 0)
Unsatisfied demand = 310 - 180 = 130
Allocation to S1 = 180
This table shows you the resource availability after the allocation of 180 items consumes capacity. The values in are derived from subtracting demand satisfied from supplier capacity tolerance percentages.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tu) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 80 | 80 | 80 | 84 | 88 |
S3 | 20 | 20 | 20 | 21 | 22 |
Consider S2 and S3 from historical allocation totals with rank 2. Historical allocations beginning 1/1/98.
S2 = 1400
S3 = 1000
Total allocations for S2 and S3 = 2400
Note: Because S2 has a higher sourcing percentage, we will begin with allocations to S2.
Target source percentages: S2 = 60% (see sourcing rules data table)
Total target allocation = historical allocation + unsatisfied demand = 2400 + 130 = 2530
Using the S2 target allocation percentage, calculate the allocation to S2.
Allocation to S2 + 1400 (historical allocation) / 2530 (total target allocation) = 0.6 (source percent)
S2 allocation = 118
S2 Allocation: 118 becomes 125 because S2 has a fixed lot multiple of 25 (see order modifiers at each source table). To respect that, 125 needs to be allocated.
S2: Allocation = 125, Date = 7/15/98
Monday, 7/14/98, is the latest reception date before the due date. This respects the processing and postprocessing lead-times.
Cumulative Available Capacity = 240 (tolerance percentage = 0); see supplier capacity profile after S1 allocation table.
This table shows you the resource availability after all allocations so far have consumed capacity.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/16/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 80 | 35 | 0 | 84 | 88 |
S3 | 20 | 20 | 20 | 21 | 22 |
Remaining quantity to allocate = 130 - 125 = 5
S3 allocation: 5 becomes 21 because the minimum order quantity for S3 is 21 (see order modifiers at each source table).
Tuesday is a valid reception date. The reception date must be moved to Monday 7/14 due to postprocessing lead-time. This respects all lead-times (see supplier delivery patterns table and supplier processing information table).
Cumulative Available Capacity = 60
This table shows you the resource availability after all allocations so far have consumed capacity.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 80 | 35 | 0 | 84 | 88 |
S3 | 20 | 19 | 0 | 21 | 22 |
Note: Scheduled receipt excess = 16 (for netting gross requirements for the next planning period) (see horizontal plan table).
This table shows summary of planned order allocations for demand #1.
Source | Allocation | Date |
---|---|---|
S1 | 180 | 7/14/98 |
S2 | 125 | 7/14/98 |
S3 | 21 | 7/14/98 |
The values for S1 come from Step 1: Allocation to S1, the values for S2 come from Step 4: Respect Order Modifiers If They Exist, and the values for S3 come from Step 7: Respect Order Modifiers If They Exist.
See demand table.
Quantity = 280
Due Date = 7/16/98 (Wednesday)
Unsatisfied Demand = 280 - 16 (scheduled receipt excess) = 264
Wednesday is delivery date. The receiving date must be moved to Tuesday, 7/15, due to postprocessing lead-time.
Tuesday is not a reception date. The allocation date is moved to Monday, 7/14/98.
Cumulative available capacity = 0 (tolerance percentage = 0) (see supplier capacity profile after S3 allocation table), hence allocation to S1 = 0.
Unsatisfied demand = 280 - 16 (excess supply due to order modifiers from previous bucket(s) = 264.
Consider S2 and S3 with rank 2 from the historical allocation totals table and the summary of planned order allocations for demand #1 table.
Historical Allocations beginning 1/1/98.
S2: 1400 + 125 = 1525
S3: 1000 + 21 = 1021
Total Allocations for S2 and S3 = 2546
Note: Because S2 has a higher sourcing percentage, we will begin with allocations to S2.
Target Sourcing Percentages: S2 = 60%
Total Target Allocation = Historical allocation + New allocation = 2546 + 264 = 2810
Using the S2 target allocation percentage, calculate the allocation to S2.
(S2 + 1525)/2810 = 0.6
S2 Allocation = 161
S2 Allocation: 161 becomes 175 because S2 has a fixed lot multiple of 25 (see order modifiers at each source table), and to respect that 7*25 = 175 needs to be allocated.
S2: Allocation = 175.
Date = 7/16/98 (Wednesday)
Reception date must be moved to Tuesday 7/15 due to postprocessing lead-time of one day (see order modifiers at each source table). Tuesday is not a reception date. Allocation date moved to Monday 7/14/98. This respects the processing and postprocessing lead-times.
Cumulative Available Capacity = 115 (see supplier capacity profile after S3 allocation table)
Respecting order modifiers: allocation of 115 becomes 125 because S2 has a fixed lot multiple of 25. To respect that, 5 x 25 = 125 needs to be allocated. However, accumulated capacity for S2 by 7/14/98 is 115, which is not a multiple of 25. Therefore, 100 units, which is the next lower value respecting order modifier and capacity will be scheduled.
This table shows you the resource availability after all allocations so far have consumed capacity.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 15 | 0 | 0 | 84 | 88 |
S3 | 20 | 19 | 0 | 21 | 22 |
Remaining quantity to allocate = 264 - 100 = 164
S3 Allocation: 164 becomes 168 because S3 has a fixed lot multiple of 7, so 24*7 = 168 needs to be ordered.
Allocation date moved to Tuesday 7/15/98 due to postprocessing lead-time. Tuesday is a valid reception date. This respects all lead-times.
Cumulative Available Capacity = 60
Respecting order modifiers: allocation of 60 becomes 63 because S3 has an order modifier of 7. To respect that, 9*7 = 63 needs to be allocated. However, accumulated capacity at S3 by 7/14/98 is 60, which is not a multiple of 7. Therefore, 56 units, which is the next lower value respecting order modifiers and capacity will be scheduled.
Unsatisfied quantity = 164 - 56 = 108
This table shows you the capacity available after all allocations so far have consumed capacity.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 15 | 0 | 0 | 84 | 88 |
S3 | 4 | 0 | 0 | 0 | 22 |
Search for Alternative Sources:
S1: Not possible due to postprocessing lead-time and reception date constraints.
S2: Wednesday is not a delivery date. Tuesday is not a delivery date.
Allocation of Excess Demand:
Excess Demand = 108
Allocate excess demand to primary source S1.
Postprocessing = 1 day becomes Tuesday, 7/15/98 (7/16 minus 1 day of postprocessing = Tuesday, 7/15).
Because Tuesday 7/15 is not a delivery date, the load excess is moved to Monday 7/14/98.
This table 6-17 shows you the capacity availability after all allocations so far have consumed capacity.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 0 | 60 | 66 |
S2 | 15 | 0 | 0 | 9 | 88 |
S3 | 4 | 0 | 0 | 0 | 22 |
This table shows the summary of allocations for planned order #2.
Source | Allocation | Date |
---|---|---|
S1 | 108 | 7/14/98 |
S2 | 100 | 7/14/98 |
S3 | 56 | 7/16/98 |
This table shows the planned order allocations summary.
Source | 7/10/98 (Thu) | 7/11/98 (Fri) | 7/14/98 (Mon) | 7/15/98 (Tue) | 7/16/98 (Wed) |
---|---|---|---|---|---|
S1 | 0 | 0 | 288 (180 + 108) | 0 | 0 |
S2 | 0 | 0 | 125 | 100 | 0 |
S3 | 0 | 0 | 21 | 56 | 0 |
Supplier contracts require that a company source its materials from suppliers based on specified allocation percentages. Similarly, requirements such as labor agreements necessitate adherence to allocation percentages from internal organizations.
You can control whether the planning process treats contractual sourcing allocation percentages as constraints, or is free to flex the allocation percentages to achieve plan objectives.
Oracle ASCP and Inventory Optimization impose the sourcing allocation percentages during optimization.
Specify Allocation Percentages.
Specify Sourcing Allocation Window.
Sign on using the System Administrator responsibility.
From the Navigator, choose Profile > System.
The Find System Profile Values screen appears.
Enter the profile option name, or use the search feature to search for a component of the profile option name (for example, you could search on the word Sourcing).
Select the Find button.
The System Profile Values screen appears.
You can specify the new profile option called MSO: Sourcing Allocation Window in the System Profile Values form. The default value is 7 days.
You can specify a length of time (in days) used to satisfy the allocation percentages. This time period during which the allocation percentages are enforced is called Sourcing Allocation Window. The sourcing constraints are enforced in a rolling horizon manner, in multiples of the Sourcing Allocation Window, with the finest granularity being the specific time bucket.
Specify Sourcing Percentage Variance.
In the System Profile Values screen, you can specify the new profile option called MSC: Sourcing Variance Tolerance in the System Profile Values form. The default value is 0.05 (5%).
The system allows you to specify a tolerance band for the difference between the user-specified allocation percentages and the plan-derived allocation percentages. If the difference is greater than the tolerance, then an exception is triggered.
Specify Allocation History Start Date.
In the System Profile Values screen, you can specify the new profile option called MSC: Start Date Offset for Sourcing History (Months) in the System Profile Values form. The default value is Null (system collects all history if the collection parameter Recalculate History is set to Yes).
The system allows you to specify a global allocation percentages start date from which the sourcing history is collected and accumulated for making sourcing decisions. The allocation history is ignored if the sourcing rule effectivity date is after the plan date.
Enforce Sourcing Constraints.
At the plan level, the system allows you to enable sourcing constraints for all sourcing rules. You can enable sourcing constraints by selecting the Enforce Sourcing Constraints checkbox in the Options tab of the Plan Options form.
Sign on using the Advanced Supply Chain Planner responsibility.
From the Navigator, choose Supply Chain Plan > Options.
The Plan Options screen appears.
Select the Enforce Sourcing Constraints checkbox.
Enforce Sourcing Splits Example
The following example shows how to use the enforce sourcing splits feature.
Suppliers S1 and S2 have the following contractual allocations:
Supplier S1: 50%
Supplier S2: 50%
The table below summarizes supply and demand and sourcing allocation percentages for suppliers S1 and S2.
Demand/Supply/Sourcing Allocation | Day 1 | Day 2 | Day 3 | Day 4 |
---|---|---|---|---|
Dependent Demand | 0 | 3 | 0 | 3 |
Planned Order Supply, S1 | 0 | 2 | 0 | 1 |
Planned Order Supply, S2 | 0 | 1 | 0 | 2 |
Cumulative Allocation, %, S1 | 0% | 67% | 67% | 50% |
Cumulative Allocation %, S2 | 0% | 33% | 33% | 50% |
On Day 2, it is not possible to exactly achieve the contractual 50%/50% split, so planned order supplies that achieve the closest possible split (67%/33%) are generated.
On Day 4, S2 is given a higher allocation in order to bring the cumulative allocation to the desired 50%/50%.
In this example, the sourcing allocation window is assumed to be equal to one day.
If you select the Enforce Sourcing Constraints at the plan option level, the precedence among the above constraints are established as follows:
You have selected the Enforce Demand Due Dates or the Enforce Service Levels plan option. In this case, the order of priority among the constraints is as follows:
Enforce Demand Due Dates/Enforce Service Levels (highest priority)
Enforce Capacity Constraints
Enforce Sourcing Constraints (lowest priority)
You have selected the Enforce Capacity Constraints plan option. In this case, the order of priority among the constraints is as follows:
Enforce Capacity Constraints (highest priority)
Enforce Demand Due Dates/ Enforce Service Levels
Enforce Sourcing Constraints (lowest priority)
Note that in either case, the sourcing constraints have the lowest priority; that is, these constraints may be violated, if required, to satisfy the capacity constraints or to meet demands.
Only Rank 1 sources are considered for enforcing sourcing allocation percentages. The allocation percentages are ignored for sources of ranks 2 and higher.
The system considers sources of ranks 2 and higher only if there is insufficient capacity among rank 1 sources to meet the required supply. If one or more rank 1 sources fall short of capacity, the sourcing allocation percentages are ignored, and the system allocates supply quantities among the sources of ranks 1 and higher based on cost and capacity considerations. The enforcement of ranking priority functionality is unchanged and it is accomplished by means of internal penalty factors.
The allocation percentages are enforced for all sourcing types:
External supplies from suppliers
Transfer supplies from internal organizations
Make supplies made within an organization
The system automatically uses internal penalty factors (i.e., not exposed to user) to minimize deviations from the desired allocation percentages. The system chooses penalty factors such that the sourcing constraints violations are penalized less than the unmet demands and capacity violations.
The manufacturing process or routing to make a product includes the operations that are required to be performed in a predetermined sequence.
Operation Resource Schedule Flag
Some resources are also required to carry out these operations and these resources need to be scheduled. The schedule flag determines whether a resource is scheduled.
When the schedule flag has been set to No, the corresponding operation resource is not brought over to the planning server as a part of the routings and is not scheduled. When the schedule flag has been set to Yes, Prior, or Next, the corresponding operation resources are brought over to the planning server as a part of the routings collection.
Within an operation, the planning engine assumes that there is at most one PRIOR activity and at most one NEXT activity. Also if you need to specify an activity as PRIOR, it should be the first activity within the operation; if you need to specify an activity as NEXT, it should be the last activity in the operation.
If a PRIOR activity is not the first activity, the planning engine sets all preceding activities to PRIOR also, regardless of the routing definition. If a NEXT activity is not the last activity, the planning engine sets all succeeding activities to NEXT also, regardless of the routing definition.
If you need a NEXT activity as an intraoperation step, break the routing into two operation steps so that the NEXT is at the end of the first of two operations rather than in the middle of one operation.
Sign on using the Manufacturing and Distribution Manager responsibility.
From the Navigator, select Bill of Material > Routings > Routings.
The Routings screen appears.
Select Operation Resources.
Operation Resources screen appears.
Set up resource schedule from the Scheduling tab. The possible values for the schedule flag are: Yes, No, Prior, Next.
For details on other columns and functionality, refer to the Routings chapter in the Oracle Bills of Material User's Guide.
When planning for long-running jobs or batches, Oracle Advanced Supply Chain Planning can plan for the arrival of the necessary raw materials or ingredients from external suppliers as well as from other internal organizations to occur incrementally throughout the duration of the job or batch instead of the raw materials to arrive prior to the start of the job. This reduces the total manufacturing lead-time significantly.
Oracle Advanced Supply Chain Planning also allows you to model overlaps of manufacturing operations in different organizations. An operation of a routing in the downstream organization can start after completion of a Minimum Transfer Quantity (MTQ) at the operation of another routing in the upstream organization.
Note: Theoretically, it is possible to combine Minimum Transfer Quantity with incremental supplies.
Oracle Advanced Supply Chain Planning allows you to specify a Minimum Transfer Quantity, which is the minimum amount that an operation must be completed in order to trigger the start of the next operation.
Minimum Transfer Quantity is used to model production operations in which materials are transferred in lots smaller than the processing lots, resulting in subsequent operations that start before the current operation is completely finished. You can specify Minimum Transfer Quantities between routings as well as between operations of a routing. Oracle Advanced Supply Chain Planning respects Minimum Transfer Quantity while scheduling operations.
In the process of scheduling an operation, Oracle Advanced Supply Chain Planning dynamically uses the production rate of the selected alternative resource to determine when to begin the material transfer to the subsequent operation. Production breaks are honored.
Oracle Advanced Supply Chain Planning allows you to model Minimum Transfer Quantity between operations across routings, in a single organization as well as between multiple organizations. This implies that a downstream operation of a routing in one organization can start after completion of Minimum Transfer Quantity at the upstream operation of another routing in a different organization.
The following diagram shows how the planning engine uses the Minimum Transfer Quantity:
Minimum Transfer Quantity
You can specify the Minimum Transfer Quantity between routings and between operations. Oracle Advanced Supply Chain Planning schedules operations with respect to Minimum Transfer Quantity.
You can specify the Minimum Transfer Quantity in the following manner:
Interrouting (between routings): The Minimum Transfer Quantity is specified for the last operation of the upstream routing.
Intrarouting (between operations of one routing): The Minimum Transfer Quantity is specified for the current operation.
Oracle Advanced Supply Chain Planning models MTQ with respect to the resource run rates of the upstream and downstream processes. These processes can have the same run rates or different run rates. The scheduling results can be different due to these rates.
Consider a routing with two operations, Operation 10 using resource R1 and Operation 20 using resource R2. There is an MTQ between Operations 10 and 20. The following equation presents the relationship between the resources run rates:
R1 Run Rate >= R2 Run Rate
Operation 20 can start after the completion of MTQ at Operation 10 with respect to resource availability.
Downstream process is slower than the upstream process or it has the same rate
Consider a routing with two operations, Operation 10 using resource R1 and Operation 20 using resource R2. There is an MTQ between Operations 10 and 20. The following equation presents the relationship between the resources run rates:
R1 Run Rate < R2 Run Rate
The planning engine schedules Operation 20 such that the end of Operation 20 is beyond the end of Operation 10 with minimum of MTQ.
Operations Finish Times Constraint: Operation 20 Finish Time - Operation 10 Finish Time >= MTQ
Downstream process is faster than the upstream process
A similar constraint holds for activities with respect to MTQ. Consider an operation with two activities, Activity 1 using resource R1 and Activity 2 using resource R2. The MTQ between Activity 1 and Activity 2 is inferred for the operation MTQ. The following equation presents the relationship between the resources run rates:
R1 Run Rate < R2 Run Rate
The planning engine schedules Activity 2 such that the end of Activity 2 is beyond the end of Activity 1 with minimum of MTQ.
Activities Finish Times Constraint: Activity 2 Finish Time - Activity 1 Finish Time >= MTQ
Downstream process is faster than the upstream process
When resource breaks are present, Oracle Advanced Supply Chain Planning adjusts the start time of the next operation with respect to the start time of the current operation. This ensures that the planning engine respects the Minimum Transfer Quantity constraints and also avoids starvation of the next operation. For more details, see the following examples:
The upstream activity has a break within MTQ (MTQ is available after the break)
The break delays the start of the downstream activity by delaying the time at which MTQ units are completed by the upstream operation.
MTQ = 100 units = 3 hours
Break 1 = 15 minutes starting at 10:00 am
Runtime activity of Operation 10 starts at 9:45 am.
A = 15 minutes
B = 2 hours and 45 minutes
MTQ Production Time = A + B = 3 hours
Runtime activity of Operation 20 can start any time after 1:00 pm (9:45 am + 3 hours + 15 min = 1:00 pm) with respect to the Activities Finish Times Constraint.
Resource Break: Scenario 1
Result:
Runtime Activity OP 20 Start Time >= (Runtime Activity OP 10 Start Time) + MTQ + Break 1
The upstream activity has a break after the completion of MTQ (MTQ is available before the break)
MTQ = 100 units = 3 hours
Break 2 = 15 minutes starting at 2:00 pm
Runtime activity of Operation 10 starts at 9:45 am.
If the downstream activity is faster than the upstream activity or it has the same run rate as the upstream activity, the downstream activity can start after MTQ Production Time plus break. The break postpones the start of the downstream activity.
Runtime activity of Operation 20 can start any time after 1:00 pm (9:45 am + 3 hours + 15 min = 1:00 pm) with respect to the Activities Finish Times Constraint.
Resource Break: Scenario 2: Case 1
Result:
T >= MTQ + Break 2
Runtime Activity OP 20 Start Time >= (Runtime Activity OP 10 Start Time) + MTQ + Break 2
If the downstream activity is slower than the upstream activity, then the downstream activity can start any time after MTQ.
Runtime activity of Operation 20 can start any time after 12:45 pm (9:45 am + 3 hours = 12:45 pm) with respect to the Activities Finish Times Constraint.
Resource Break: Scenario 2: Case 2
Result:
Runtime Activity OP 20 Start Time >= (Runtime Activity OP 10 Start Time) + MTQ
In case 1, if the downstream activity cannot start after MTQ plus break time (for example the activity start time has been firmed after MTQ but before MTQ plus break time), then there is a potential for starvation at the downstream activity.
Resource Break: Scenario 2: Continuation of Case 2
This implies that the above constraint can be violated with respect to firm requirements.
Both the upstream and downstream activities have equal breaks at the same time after the completion of MTQ
MTQ = 100 units = 3 hours
Break 2 = 15 minutes starting at 2:00 pm
Break 3 = 15 minutes starting at 2:00 pm
Runtime activity of Operation 10 starts at 9:45 am.
The downstream activity starts after MTQ with respect to the equal breaks.
Runtime activity of Operation 20 can start any time after 12:45 pm (9:45 am + 3 hours = 12:45 pm) with respect to the Activities Finish Times Constraint.
Resource Break: Scenario 3
Result:
Runtime Activity OP 20 Start Time >= (Runtime Activity OP 10 Start Time) + MTQ
This scenario is also valid if the downstream activity break is greater than the upstream activity break.
Both the upstream and downstream activities have unequal breaks at the same time after the completion of MTQ
MTQ = 100 units = 3 hours
Break 2 = 30 minutes starting at 2:00 pm
Break 3 = 15 minutes starting at 2:15 pm
Break 2 (upstream activity) > Break 3 (downstream activity)
Runtime activity of Operation 10 starts at 9:45 am.
Considering the larger break of the upstream activity, the downstream activity can start any time after MTQ plus the difference of the breaks.
Runtime activity of Operation 20 can start any time after 1:00 p.m. [9:45 a.m. + (3 hours) + (30 min -15 min) = 1:00 p.m.] with respect to the Activities Finish Times Constraint.
Result:
Runtime Activity OP 20 Start Time >= (Runtime Activity OP 10 Start Time) + MTQ + (Break 2 - Break 3)
If the downstream activity cannot start after MTQ plus the difference of the breaks (for example the activity start time has been firmed after MTQ but before MTQ plus the difference of the breaks), then there is a potential for starvation at the downstream activity.
When raw materials are replenished by external suppliers, Oracle Advanced Supply Chain Planning respects order quantity-limiting modifiers such as fixed order quantity, issues multiple raw material replenishment orders for each long-running production job, then staggers the due dates of the replenishment orders across the duration of the job.
When raw materials are replenished by internal organizations, Oracle Advanced Supply Chain Planning can model the replenishment as either of the following:
Continuous transfer- The production order in the destination organization is permitted to start after a suitable time offset from the raw material production order in the source organization.
The downstream process receives material in lot sizes of 1 from the upstream process. The transfer starts on or after the completion of Minimum Transfer Quantity at the upstream process.
Discrete incremental or non-continuous transfer - Multiple transfer orders that respect quantity limitations imposed by order modifiers are created, and their due dates are staggered across the duration of the production order in the destination organization.
The downstream process receives material in discrete increments (more than 1 at a time) from the upstream process.
When you use incremental planned orders, downstream supply can be split into multiple planned orders. In this case, the planned order demand driving these planned orders has a demand date of the later of the planned orders. By referring to the planned order demand, it could appear that the planned order supply occurs after the start of a scheduled activity. For example:
An assembly supply order calls for making quantity 30
An activity is scheduled 13-JAN 22:41:00 to 13-JAN 22:59:00
The planning engine creates incremental planned orders quantity 5 for 13-JAN 22:41:00 and quantity 25 for 13-JAN 22:44:00
The planned order demand becomes quantity 30 on 13-JAN 22:44:00
You can also model material transfers with respect to convergence and divergence of supplies. In case of divergence, supply from one upstream process splits into two or more downstream processes of the same item. In case of convergence, supplies from two or more upstream processes of the same item are sent to (consumed by) one downstream process.
You can adopt the following supply chain models for material transfer from suppliers and internal organizations:
To model non-continuous transfers inside one organization with incremental supplies
To model non-continuous transfers inside one organization with incremental consumption
To model non-continuous transfers across organizations with incremental supplies
To model non-continuous transfers across organizations with incremental consumption
To model non-continuous transfers between suppliers and internal organizations
Select the Manufacturing and Distribution Manager responsibility.
Navigate to Bill of Materials > Routings > Routings.
Define Routing.
Define Routing Operations.
Select the WIP tab.
Specify Min Transfer Qty for the feeding operation.
The Minimum Transfer Quantity is applied between the last scheduled activity of the upstream producing operation and the first scheduled activity of the downstream consuming operation.
In regular routings the last operation of the routing is considered as the producing operation. In case of network and complex routings, the upstream feeding operation can be any one of the operations in the upstream routing.
In case of process manufacturing, you can define Min Transfer Qty in the Operation Details Activities form.
Navigate to Operation Resources > Scheduling tab.
Set the Basis field to:
Item for value added activities (runtime).
Lot for setup (preparation) and teardown (clean up) activities.
Set the Schedule field to:
Yes for value added activities (runtime)
Prior for setup activities (preparation)
Next for teardown activities (clean up)
Note: The planning engine models Minimum Transfer Quantity only if both upstream and downstream operations have at least one activity.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Consider:
Items A and X are produced in Organization 1.
Item A routing consists of 2 operations - OP 10 and OP 20 - and each operation consists of 3 activities: Preparation, Runtime, and Clean Up.
Item X routing also consists of 2 operations - OP 10 and OP 20 - and each operation consists of 3 activities: Preparation, Runtime, and Clean Up.
The Runtime activity of operation 20 can start after completion of MTQ at the Runtime activity of operation 10.
Refer the figure below to view the continuous transfer modeling in Organization 1:
Continuous transfer inside one organization with MTQ
Result: The downstream process starts after a minimum quantity from the upstream process has been completed. The material transfer is continuous after the Minimum Transfer Quantity is completed.
This type of transfer is modeled for processes with continuous flow.
Complete from Step 1-9 listed in the section To model continuous transfer inside one organization.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Continuous Inter-Org Transfers item attribute to Yes.
Alternatively, you can also set the profile option MSO: Continuous transfer across organizations to Yes in the Personal Profile Values form.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Consider:
Items A is produced in Organization 1.
Item A routing consists of 2 operations - OP 10 and OP 20 - and each operation consists of 3 activities: Preparation, Runtime, and Clean Up.
The Runtime activity of operation 20 can start after completion of MTQ at the Runtime activity of operation 10.
Item X is produced in Organization 2.
Item X routing consists of 2 operations - OP 10 and OP 20 - and each operation consists of 3 activities: Preparation, Runtime, and Clean Up.
The Runtime activity of operation 20 can start after completion of Minimum Transfer Quantity at the Runtime activity of operation 10.
Refer the figure below to view the continuous transfer modeling between Organization 1 and Organization 2:
Continuous transfer across organizations
Result:
Downstream operation of the routing in Organization 2 starts after completion of Minimum Transfer Quantity at the upstream operation of the routing in Organization 1.
The planning engine adds the in-transit time between organizations and the item postprocessing lead-time to the specified Minimum Transfer Quantity to trigger the start of the downstream process.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Divergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Divergent Supply Feeding Pattern for Intra-Org Sourced orders to Series in the Personal Profile Values form.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Refer the following figure to understand how Oracle Advanced Supply Chain Planning allows you to model incremental transfer of supplies within an organization. The downstream process is incrementally fed with the supply segments of the upstream process.
Non-continuous transfers inside one organization with incremental supplies
Result: Order 1 of Item B can start after the completion of the first supply segment of Item A.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Convergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Convergent Supplies Consumption Pattern for Intra-Org Sourced orders to Series in the Personal Profile Values form
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Refer the following figure to understand how Oracle Advanced Supply Chain Planning allows you to model incremental consumption of supplies within an organization. The downstream process incrementally consumes supply orders of the upstream process.
Non-continuous transfers inside one organization with incremental consumption
Result: The supply orders of Item A are consumed in two increments by the downstream process of Item B. In this case, the overlap between the upstream process and the downstream process reduces the cycle time.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Divergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Divergent Supply Feeding Pattern for Inter-Org and Supplier Sourced orders to Series in the Personal Profile Values form.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Non-continuous transfers with incremental supplies in case of within an organization as well across organizations use the same item attribute:
Set the Divergence Pattern item attribute to Series
However, non-continuous transfers with incremental supplies in case of within an organization use the profiles options:
MSO: Divergent Supply Feeding Pattern for Intra-Org Sourced orders to Series
Whereas, non-continuous transfers with incremental supplies in case of across organizations use the profiles options:
MSO: Divergent Supply Feeding Pattern for Inter-Org and Supplier Sourced orders to Series
Refer the following figure to understand how Oracle Advanced Supply Chain Planning allows you to model incremental transfer of supplies between organizations. The downstream process is incrementally fed with the supply segments of the upstream process.
Non-continuous transfers across organizations with incremental supplies
Results:
Transfer Order 1 and Transfer Order 2 of Item A can start after the completion of the corresponding supply segments of Item A at organization 1.
Order 1 and Order 2 of Item B can start after the arrival of shipments of Item A supply segments (transfer orders) at organization 2. In other words, the production process for Item B Order 1 can start earlier when compared to non-incremental case.
The two supply segments are generated based on the two transfer orders.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Convergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Convergent Supplies Consumption Pattern for Inter-Org and Supplier Sourced orders to Series in the Personal Profile Values form.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Refer the following figure to understand how Oracle Advanced Supply Chain Planning allows you to model incremental consumption of supplies between organizations. The downstream process incrementally consumes the supply orders of the upstream process.
Non-continuous transfers across organizations with incremental consumption
Result: The transfer orders of Item A are consumed in two increments by the downstream process of Item B. In this case, the overlap between the transfer orders and the downstream process reduces the cycle time.
Navigate to Item > Organization Items > MPS/MRP Planning tab.
Set the Divergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Divergent Supply Feeding Pattern for Inter-Org and Supplier Sourced orders to Series in the Personal Profile Values form.
Set the Convergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Convergent Supplies Consumption Pattern for Inter-Org and Supplier Sourced orders to Series in the Personal Profile Values form.
Navigate to Items > Organization Items > General Planning tab:
Set the following item order modifiers:
Maximum Order Quantity
Fixed Order Quantity
Fixed Days Supply
Refer the following figure to understand how Oracle Advanced Supply Chain Planning allows you to model incremental supplies and incremental consumption of supplies between organizations.
Non-continuous transfers across organizations with incremental supplies and incremental consumption
Result:
The supply orders of Item A are consumed in two increments by the downstream process of Item B.
The overlap between the upstream process and the downstream process reduces the cycle time.
Transfer Order 1 and Transfer Order 2 of Item A can start after the completion of the corresponding supply segments of Item A at Organization 1.
The transfer orders of Item A are consumed in two increments by the downstream process of Item B. In this case, the overlap between the transfer orders and the downstream process reduces the cycle time.
Navigate to Items > Organization Items > General Planning tab.
Set the item order modifiers in the Organization Item form
Set the Convergence Pattern item attribute to Series.
Alternatively, you can set the profile option MSO: Convergent Supplies Consumption Pattern for Inter-Org and Supplier Sourced orders to Series in the Personal Profile Values form.
Refer the following figure to understand Oracle Advanced Supply Chain Planning allows you to model incremental consumption of supplies (Convergent Supplies Consumption Pattern) between suppliers and internal organizations. The downstream process incrementally consumes supply orders of the upstream process.
Incremental supplies do not always start at the start of the downstream operation and after that. These can also start before the start of the downstream operation.
Non-continuous transfers between suppliers and internal organizations
Result:
The supply orders of Item A are consumed in two increments by the downstream process of Item B.
The overlap between the supply orders and the downstream process reduces the cycle time.
This section discusses the business benefits from setting up alternate and simultaneous resources and discusses how to:
Set up alternate resources.
Set up simultaneous resources.
You can schedule two or more resources (simultaneous resources) to be used at the same time within the job operation. For example: you can schedule a person resource operating a machine resource.
You can define resource groups within the operation. This lets you give your primary resource a group number. This group can then be replaced by other resources. For example: a group of lathes can be replaced by a group of computer numerical control (CNC) machines.
You have the ability to define substitute resources for each primary resource group defined. This enables you to specify resource sequences that can replace the primary resource group. For example: a group of lathes can be replaced by a group of CNC machines.
You can assign a priority to the substitute resource groups, and specify the circumstances the substitute groups are to be considered. For example: you can assign a less expensive resources as priority 1, and a more expensive resources as priority 2. This means that resources with priority 1 (less expensive) will be used first.
You have control over the relative end times of principal and simultaneous resources. Principal and simultaneous resources can start and end at the same time. Or, principal and simultaneous resources can start and the same time and end at different times, which avoids over consumption of capacity and improves resource utilization.
A simultaneous resource is available as soon as processing is complete. If the simultaneous resource finishes early, it can be reassigned to other activities.
You can control the scheduling of simultaneous resources across breaks, which avoids cases where the principal resource completes before the simultaneous resource.
You can improve scheduling accuracy and quality because you can model your requirements precisely, which minimizes manual intervention and reduces cycle times.
From the Navigator, choose Bills of Materials > Routings > Routings.
The Routings window appears.
From the menu bar, select View > Find.
The Find Routings window appears.
Find your routing, by entering search criteria and selecting the Find button.
The Routings window appears with your routing.
From the Main tab, select the operation sequence with which you want to set up and select the Operation Resources button.
The Operation Resources window appears with the first resource already entered. This resource is considered as a primary resource.
Select the Scheduling tab.
Enter the Substitute Group Number.
If you have a machine and a labor resource modeled as primary and simultaneous resources, enter the same substitute group number for both of them. This indicates that when replacing them with alternate resources, they are both replaces as a group.
Select the Principal Flag for the resource or one of the resources if there are multiple present in the primary group.
Select the Alternate button.
The Operation Alternate Resources window appears.
Enter alternate resources and choose Replacement Group.
Replacement Group number establishes relative priority. Enter a value of 1 or higher. If you have multiple alternates, enter them as multiple rows with appropriate Replacement Group numbers to indicate priorities.
You can specify multiple resource sequences with the same replacement group number. This indicates that a set of primary resources are replaced by a set of alternate resources with the resource sequence number, and schedule sequence number, within each replacement group, indicating the order or simultaneity of scheduling within that replacement group.
Check the Principal Flag for your alternate resource as appropriate.
From the Navigator, choose Bill of Materials > Routings > Routings. The Routings window appears.
From the menu bar, select View > Find. The Find Routings window appears.
Find your routing by entering search criteria and selecting the Find button. the Routings window appears with your routing.
From the Main tab, select the operation sequence within which you want to set up and select the Operation Resources button. the Operation Resources window appears with the first resource already entered. This resource is considered a primary resource.
Select the Scheduling tab.
On the Operation Resources - Scheduling page, enter simultaneous resources in the rows below the initial resource.
In the Schedule Seq. (schedule sequence) field, enter the same number for both principal and simultaneous resources.
This indicates to planning that the resources are simultaneous resources.
Select the Principal Flag check box to indicate that one of the resources is the principal resource.
For some types of manufacturing operations, the duration can be shortened by applying greater numbers of processing resources. For example, the duration of a visual inspection operation can be approximately halved by increasing the number of inspectors from one to two. For these types of divisible manufacturing operations, it is important to accurately plan for the shrinking of the operation duration as greater numbers of processing resources are deployed. It is also important to be able to designate certain operations as divisible and others as indivisible (one resource per operation). The multiresource scheduling feature of Oracle ASCP accomplishes these aims.
Shown below are examples of how this feature can be used in various manufacturing scenarios.
Note: In the following scenarios, the notation Res 1, Res 2, etc., refers to multiple identical units of a single resource defined in Oracle Bills of Material, not to multiple distinct resources.
In this scenario, multiple resource units work together on an operation (divisible).
A manufacturing house is assembling telephone handsets. The handset assembly job consists of one assembly operation that takes one hour. The manufacturing house has one resource called RES. The resource RES has 4 resource units which are 4 assemblers (Res 1, Res 2, Res 3, Res 4). Please note that within ASCP, a resource can be either a single or a multiple resource unit of the same type.
The job parameters are:
Job: Handset assembly
Job Qty: 6
Resource RES units: Res 1, Res 2, Res 3, Res 4
Usage rate: 1 hour per operation
The following figure shows how the resource unit allocation should be done.
Scenario 1
Total processing time for the Job = 1.5 hours (when multiple resources can work together on a job)
This scenario shows a single unit per operation (indivisible).
In printed circuit board assembly, one resource unit is required to finish the entire operation. This is because the item is so small, only one person can handle it. Sometimes even from the process perspective it is not possible to use two units on one job at one time. After soldering, cleaning is done by a machine in which the board goes inside the cleaning machine. In this case, two cleaners cannot work together on a single board.
The job parameters are:
Job: PCB assembly
Job Qty: 6
Resource RES units: Res 1, Res 2, Res 3, Res 4
Usage rate: 1 hour per operation
The following figure shows how resource unit allocation should be performed in this situation.
Note: In the following figure, Oracle ASCP assumes that during the second hour, Res 3 and Res 4 remain consumed for the purpose of calculating resource utilization, and are not available for any other job. To overcome this approximation, you can define Res 1, Res 2, Res 3, and Res 4 as individual resources (instead of multiple units of the same resource).
Scenario 2
You select a rounding control attribute in the item master. When the Round Order Quantities flag is checked, it means only one resource unit can work on one assembly at a time.
From the Manufacturing and Distribution manager responsibility
Select Inventory > Items > Master Items.
Use the scroll arrow so that the MPS/MRP Planning tab appears.
Check or uncheck Round Order Quantities.
Following are the few examples of behavior when rounding control attribute is checked.
The job parameters are:
Job quantity: 4
Number of assigned resource units: 5
Job duration: 1 hour
Here, four resource units are assigned 4 jobs and the fifth resource unit is idle. The job takes one hour to complete.
The job parameters are:
Job quantity: 4
Number of assigned resource units: 3
Job duration: 2 hours
Here, all 3 resource units are occupied for first two hours (job duration). For the next two hours, only one resource unit is occupied. The job takes four hours to complete.
The job parameters are:
Job quantity: 8
Number of assigned resource units: 3
Job duration: 1 hour
Here, all 3 resource units are occupied for first two hours. For the next hour, two resource units are occupied. The job takes 3 hours to complete.
The following table also explains Example 3.
Example 3
Note: In ASCP, the number of resource units per operation/activity is controlled by the Assigned Units field in the Routing form.
Since Oracle ASCP treats the capacity of multiple units of a single resource as a large bucket (instead of as independent buckets for each resource unit), certain detailed scheduling decisions will be approximate and may not be locally optimal. For example, in the situation below:
The job parameters are:
Assigned units: 2
Job 1 quantity: 2
Job 2 quantity: 4
Job duration: 1 hour
Max/available resource units: 3
In the figure below, the table to the left shows what happens when Job 2 is scheduled first and the table to the right shows what happens when Job 1 is scheduled first. Both of the outcomes shown in the figure below are possible, depending on the order in which the jobs are assigned to the resource units.
Example 4
Lead-times are portions of the span of time from recognizing the need for an order to receiving the goods to inventory.
The planning time fence defines a time period within which the planning engine may not create planned orders. Use planning time fence control for schedule stability during the initial periods of a plan.
The more realistic that your lead-times are, the more accurate the plan matches what will actually occur during execution. Use planning time fence control for schedule stability during the initial periods of a plan.
Lead-times are portions of the span of time from recognizing the need for an order to receiving the goods to inventory.
This topic reviews the lead-times that Oracle Advanced Supply Chain Planning uses to plan and schedule. It also explains concurrent processes, profile options, plan options, and planning parameters that affect lead-time calculations.
Set lead-time values for the planning engine to use in the following source system forms:
Oracle Inventory > Organization items form > Item attributes > Lead-time tabbed region
Oracle Purchasing > Approved Supplier List form
The planning engine does not use subinventory lead-times from Oracle Inventory. These values are for the Oracle Inventory Min-Max planning process.
This topic describes the lead-time item attributes. You define them:
For each organization and not for the master organization
In work days from the manufacturing calendar
For more information, see Oracle Inventory User's Guide.
You can enter the following lead-time item attributes:
Preprocessing: The time required to place a purchase order or create a discrete job or schedule. This is also known as the paperwork or planning time.
Fixed: The time required to complete the tasks to make an assembly that are independent of order quantity, for example, setup, fixed run time, or teardown times.
Variable: The time required to complete the tasks to make an assembly that depend on order quantity, for example, run time. Oracle Bills of Material concurrent processes calculate this time.
Lead Time Lot Size: The typical quantity of the item that you buy, make or transfer. The default value is item attribute Standard Lot Size (set by Oracle Cost Management).
Oracle Bills of Material concurrent process Calculate Manufacturing Lead Time uses this value to compute Processing.
Processing: The time required for a supplier or your transfer from facility to deliver an item to your receiving dock or for you to manufacture an item. For make items, this is also known as manufacturing lead-time. For buy and transfer items, it includes in-transit time to your facility.
For transfer items, the planning engine only takes this lead time into account if the item is not planned at your source organization, If the item is planned at the source organization, the planning engine uses the lead times from the source organization.
Postprocessing: The time required to receive a buy or transfer item from the receiving dock to inventory.
Cumulative Manufacturing: For make items, the time required to make the item if you have all of the buy items in inventory and have to make all subassemblies and the item itself.
Cumulative Total: For make items, the time required to make the item if you have to purchase all of the buy items, make all subassemblies, and make the item itself.
The lead-times define dates that are associated with planned orders and scheduled receipts for these items:
Order date: The beginning of Preprocessing the date you should begin the processing to release the order.
Start date: The end of Preprocessing and beginning of Processing; the date you, your supplier, or your ship from facility should begin work on the order.
Dock date: For buy and transfer orders, the end of Processing and the beginning of Postprocessing; the date that the material should be on your receiving dock.
For make orders, dock date is the same as due date.
Due date: For buy and transfer orders, the end of Postprocessing and for make orders, the end of Processing; the date that the material should be in your inventory.
If you run the following Oracle Bills of Material concurrent processes, they can update lead-time values that you may have manually set:
These concurrent processes update the following lead-time item attribute fields:
Fixed: Oracle Bills of Material concurrent process Calculate Manufacturing Lead Time calculates this time and update your manual entry for make items. It sums the values in field Usage for lot-based, scheduled resources.
Variable: Oracle Bills of Material concurrent process Calculate Manufacturing Lead Times calculates this time and update your manual entry for make items. It sums the values in field Usage for item-based, scheduled resources.
Processing: The Oracle Bills of Material lead-time concurrent process Calculate Manufacturing Lead Time calculates this time and replaces your manual entry for make items. It uses calculation Fixed + (Variable * Lead Time Lot Size); if Lead Time Lot Size does not have a value, it uses 1.
Cumulative Manufacturing: The Oracle Bills of Material lead-time concurrent processes Calculate Cumulative Lead Time and Rollup Cumulative Lead Time calculates this time and replace your manual entry. For an assembly, they take each component's cumulative lead-time and subtract its operation lead-time offset in the assembly's routing. Then, they take the manufacturing lead-time of the assembly and add the largest adjusted cumulative manufacturing lead-time of its components.
Cumulative Total: The Oracle Bills of Material lead-time concurrent processes Calculate Cumulative Lead Time and Rollup Cumulative Lead Time calculate this time and replace your manual entry. For an assembly, they take each component's cumulative lead-time and subtract its operation lead-time offset in the assembly's routing. Then, they take the manufacturing lead-time of the assembly, add the largest adjusted cumulative manufacturing lead-time of its components, and add the longest buy part lead-time of its components.
Decimal lead-time quantities denote times less then one day and are the result of the lead-time divided by 24 hours.
For more information, see Oracle Bills of Material User's Guide.
Safety lead-time is a lead-time that you add to the normal lead-time of make and buy items. You use it to instruct the planning engine to schedule supplies in advance of the demand due dates that peg to them for the purposes of:
Having an inventory buffer to protecting against fluctuations in lead-time, demand (for example, forecast error), and supply (for example, variable supplier lead times and irregular operation yields)
Providing a time buffer to recover from fluctuations by taking longer to manufacture the original units or by manufacturing more units either to handle increased demand or to replace unsuitable parts from the original supply run
Safety lead-time is sometimes referred to as protection time or safety time
You can also complete supplies earlier than the demands that peg to them using transient safety stock levels. See Safety Stock. Use safety stock lead-time instead of transient safety stock if you want to have:
Lower average inventory level: Safety lead-time creates less excess supply because it creates safety stock from supplies pegged to actual demands rather than to additional safety stock level demands
Less late-satisfied demands: There are no supplies pegged to additional safety stock level demands that compete against actual demands for manufacturing and supplier capacity
Safety stock lead-time is:
Used in constraint-based planning and is not available for unconstrained planning
A soft constraint. If hard constraints prevent moving the supply due date to honor the safety lead-time, the planning engine will not honor the safety lead-time
To set safety lead time:
Set profile option MSO: Use Safety Lead Time to Yes
For each item-organization, set item attribute Safety Stock Method to MRP Planned % then, in item attribute Safety Stock Percent, enter safety lead-time in days.
When the planning engine schedules a supply subject to safety lead-time, it:
Creates planned orders based on demands
Pegs demands to these supplies and uses them to cover transient safety stock requirements
Ignores safety lead-time in forward scheduling so as to meet demand due date
Inflates the lead-time by the safety lead-time in backward scheduling to plan for receipt to stock.
This example shows how to analyze plan information for items subject to safety lead-time:
In the diagram, SS means safety stock and PAB means projected available balance.
Profile option MSO: Use Safety Lead Time = Yes
Item attribute Safety Stock Method = MRP Planned %
Item attribute Safety Stock Bucket Days = 5
Item attribute Safety Stock Percent = 200% = 2 days
The planning engine ignored transient safety stock, pegged supplies to actual demands, and scheduled supplies two days earlier than the demand due dates of the demands that peg to them.
Planned orders on day 4 are for quantities 400, 400, and 200.
The first planned order of quantity 400 on day 4 is against the transient safety stock of quantity 400 on day 1.
The second planned order of quantity 400 is against the increase in the transient safety stock to quantity 800 on day 3.
A third planned order of quantity 400 is against the increase in the transient safety stock to quantity 1200 on day 5. The planning engine splits the planned order of quantity 400 into two planned orders of quantity 200 (according to profile option MSO: Demand Size Tolerance Before Splitting Planned Orders). The demand on day 6 pegs to one planned order of quantity 200; the demand on day 8 pegs to the other planned order of quantity 200.
This example shows the plan information for the same demand position but using non-transient/transient safety stock planning. In the diagram, SS means safety stock and PAB means projected available balance.
If you use safety lead-time:
You might accumulate too much material too early. However, resource constraints reduce the possibility. By using safety lead-time planning, the risk of accumulation should be lower than by using non-transient/transient safety stock planning.
The planning engine might suggest that you delay lower priority demands in order to meet safety lead-time
You can also view Preprocessing, Processing, Postprocessing, Fixed, and Variable in the Collections Workbench Items window and the Planner Workbench Items window.
The planning engine does not use Cumulative Manufacturing and Cumulative Total values. You may see them in lists of values when you are entering lead-times, for example, item attribute Planning Time Fence.
Total lead-time is not an item attribute. The planning engine calculates it in unconstrained plans to determine an order's Order Date. It:
Begins with the order's Due Date
Calculates total lead-time for the order as item Fixed + (Variable * Order quantity)
Adds Preprocessing to calculate the order's Order Date
The Calculate Manufacturing Lead-time concurrent process uses the same general calculation for Processing as the planning engine uses for Total Lead-time. The Calculate Manufacturing Lead-time concurrent process uses item attribute Lead-time Lot Size to calculate item attribute Processing. The planning engine uses actual order quantity to calculate the processing time for a specific planned order or scheduled receipt.
This diagram shows the relative use of Total Lead-time, Cumulative Manufacturing, and Cumulative Total.
Calculations of Cumulative Lead-time Attributes
For all plan types, the planning engine schedules planned orders and scheduled receipts based on Demand Due Date of the demand that the supply is pegged to. It calculates these dates:
Need By Date: The earliest demand due date of all demands pegged to a supply.
Suggested Due Date: The date by which the supply is available for use by its demand. In an Unconstrained or Constrained - Enforce demand due dates plan this is the same as Need By Date. In a Constrained - Enforce capacity constraints plan this is the scheduled availability date of the supply.
Suggested Dock Date: For buy or transfer orders, the date the order arrives on your receiving dock.
Suggested Ship Date: For transfer orders, the date of departure from the source organization of the last transport used for the transfer.
Suggested Start Date: The date that you, your supplier, or your ship from facility should begin work on the order
Suggested Order Date: The date by which you need to place the order. For a scheduled receipt, this field displays the date the date that it was created.
Old Due Date, Old Dock Date, and Original Need By Date are the original dates from the source system for scheduled receipts.
You can view these dates in the Planner Workbench from among the Supply/Demand, Supply, and Demand windows.
Oracle Advanced Supply Chain Planning takes into account the actual requirement date and the lead-times for calculating the planned order demand due dates. This provides more accurate lead-time offsets in aggregate planning time buckets.
The planning engine allows you to plan at aggregate time bucket levels like periods and weeks. It provides you easy identification of aggregate supply/demand mismatches and helps you make strategic decisions related to equipment and labor acquisition, sourcing etc. without generating needless details.
The planning engine's Memory Based Planner calculates the planned order demand due dates for dependent demands based on the actual requirement date with respect to lead-time. It saves the calculated requirement date based on the lead-time value for subsequent calculation.
The planning engine aligns all dates to the ends of time buckets. You can get more accurate dates by first performing dependent demand explosion followed by alignment.
Example
Consider an organization with an assembly A, which has components B and C.
Assembly
The quantity per assembly for components B and C is 1.
The lead-time for assembly A = 4
The lead-time for sub-assembly B = 3
The lead-time for component C = 4
The organization follows a weekly planning bucket and working days are Monday through Friday.
An order quantity of 1 is placed for item A on Friday February 28.
The planning engine generates the following planned order demands:
Planned Order Demand Due Date Calculation
Explanation:
Calculated requirement date for B
= Demand Due Date for A - LT
= February 28 - 4 days
= February 24 (Monday)
Demand Due Date for B
= Calculated requirement date for B after bucketing into planning bucket
= February 28 (weekly demands are bucketed into Friday)
Calculated requirement date for C
= Calculated requirement for B - LT
= February 24 - 4 days
= February 18 (Monday)
Demand Due Date for C
= Calculated requirement date for C after bucketing into planning bucket
= February 21 (weekly demands are bucketed into Friday)
The planning engine uses work days from the manufacturing calendar to calculate dates for manufactured supplies, unless otherwise indicated.
Need By Date: The date that the material should ship or be in inventory for a next-higher level assembly. The earliest demand due date that the supply is pegged to.
Suggested Due Date: In an Unconstrained or Constrained - Enforce demand due dates plan this is the same as Need By Date. In a Constrained - Enforce capacity constraints plan this is the scheduled availability date of the supply. If the supply is constrained, the planning engine forward schedules from the constraint.
Suggested Dock Date: Demand Due Date. Dock Date is the day by which all shop floor operations are complete. Manufactured supplies do not have a Postprocessing lead-time.
Suggested Start Date: Suggested Due Date - Production duration. The day that you should begin shop floor operations.
lead-time offsetting begins only on a workday of the workday calendar. For example:
The workday calendar shows the week of 15 January as 5 workdays (Monday 15 January to Friday 19 January) followed by 2 non-workdays (Saturday 20 January to Sunday 21 January).
The planning engine creates a planned order against item A for quantity 45 with suggested ship date 20 January. Processing lead-time for item A is 5 days.
Since 20 January is a non-workday, the planning engine moves to 19 January to begin lead-time offsetting and calculates Suggested Start Date 12 January.
Sunday 21 January (non-workday)
Monday 20 January (non-workday) > Suggested Ship Date
Friday 19 January > Beginning of lead-time offsetting
Thursday 18 January > -1
Wednesday 17 January > -2
Tuesday 16 January > -3
Monday 15-January > -4
Sunday 14 January (non-workday)
Saturday 13 January (non-workday)
Friday 12 January > -5 and Suggested Start Date
Thursday 11 January
Unconstrained plans: Fixed + (Variable * Order quantity)
Constrained plans: Calculated resource and material duration. If the item does not have a routing, the planning engine uses the unconstrained calculation.
Suggested Order Date: Planned order Start Date - Preprocessing. The date on which you should place the order. For a scheduled receipt, this field displays the date the date that it was created.
This diagram shows dates calculated for manufacturing supplies.
Dates Calculated for Manufacturing Supplies
The planning engine calculates the component due dates of a manufacturing supply order according to your setting of the plan option Material Scheduling Method.
For value Order Start Date, the component due date is the supply Start Date.
For value Operation Start Date:
Unconstrained plans: The planning engine determines the operation that uses the component. It begins with the supply Start Date and increases it by lead-time % of that operation.
Constrained plans: Operation Start Date for the operation which uses it
If the item of the purchased supply has an Approved Supplier List, the planning engine:
You can view Approved Supplier List planning attributes in the Collections Workbench and the Planner Workbench, Items window, Sources tabbed region, and select Supplier Capacity.
The planning engine uses work days from the receiving organization calendar to calculate dates for purchased supplies, unless otherwise indicated.
Need by Date: Date that the material is required to satisfy demand.
Unconstrained plans: Need by Date
Constrained plans: The available date of the supply by forward scheduling
Unconstrained plans: Due Date - Postprocessing
Constrained plans: The latest delivery day for which the capacity is available and the material is needed
If the purchased supply item has an Approved Supplier List delivery calendar: The planning engine verifies that the Suggested Dock Date is a work day on the delivery calendar. If it is not, the planning engine changes Suggested Due Date to the next earliest working day of the delivery calendar.
Suggested Ship Date: Dock Date - Production duration
If the purchased supply item has an Approved Supplier List Supplier Processing lead-time: Approved Supplier List Supplier Processing lead-time
If the purchased supply item does not have an Approved Supplier List Supplier Processing lead-time: Item attribute Processing
Suggested Start Date: Ship Date
Suggested Order Date: Start Date - Preprocessing. For a scheduled receipt, this field displays the date the date that it was created. In Collections Workbench, purchase order create date. The planning engine calculates this date using the organization manufacturing calendar.
This diagram shows the calculations for purchased supplies.
Calculated Dates for Purchased Supplies
The planning engine uses work days from the receiving organization calendar and shipping organization calendar to calculate dates for transfer supplies.
Need By Date (receiving organization calendar): Date material is required to satisfy demand.
Demand Due Date (receiving organization calendar):
Unconstrained plans: Need By Date
Constrained plans: Forward scheduling from the constraint.
Suggested Dock Date (receiving organization calendar): Due Date - Postprocessing
Suggested Ship Date (shipping organization calendar):
Unconstrained plans: Dock Date - Intransit Time
Constrained plans: Dock Date - Intransit Time, considering constrained transportation duration. The planning engine considers transportation constraint maximum transfer quantity per day
Intransit Time is calendar days.
Suggested Start Date (shipping organization calendar):
Unconstrained plans: Ship Date - Processing
Constrained plans: Ship Date. The planning engine does not consider a build time because the supply may be on-hand.
Suggested Order Date (receiving organization calendar):
Unconstrained plans: Planned order Start Date - Preprocessing
Constrained plans: Ship date in the receiving organization, if the shipping organization is a planned organization. The constrained plan uses material and resource constraints in the shipping organization.
For a scheduled receipt, this field displays the date the date that it was created.
This diagram shows calculated dates for transfer supplies in an unconstrained plan. The planning engine calculates production duration differently for the source organization and the destination organizations; therefore, the dates in your plan may not line up as accurately as they appear in this diagram. If material is scheduled inside of these lead-times, planners can determine what action to take on the compression messages.
Calculated Dates for Transfer Supplies, Unconstrained Plan
This diagram shows that, in constrained plans, Need By Date and Demand Due Date in the shipping organization should be the same as planned order Ship Date in the shipping organization.
Calculated Dates for Transfer Supplies, Constrained Plan
The planning time fence defines a time period within which the planning engine may not create planned orders. Use planning time fence control for schedule stability during the initial periods of a plan
Specify a planning time fence time for an item in an organization using the item attributes Planning Time Fence and Planning Time Fence Days.
To enable planning time fence control in a plan, select plan option Planning Time Fence Control.
The planning engine calculates Planning Time Fence Date for each item in each organization as Plan Run Date + item attributes Planning Time Fence and Planning Time Fence Days, considering working days in the organization manufacturing calendar.
You can also instruct the planning engine to create a natural time fence when it first finds a firm scheduled receipt for an item. See Related Profile Options in this topic. If the natural time fence is later than Planning Time Fence Date, the planning engine changes Planning Time Fence Date to the date of the natural time fence.
You can view item attribute Planning Time Fence Days and Planning Time Fence Date on the Planner Workbench Items window. They may be hidden fields.
You can instruct the planning engine whether to remove firm planned orders from the last plan run. Use plan option Overwrite and select one of the values:
None: Do not remove any firm planned orders
All: Remove all firm planned orders
Outside Planning Time Fence: Do not remove firm planned orders due earlier than Planning Time Fence Date and remove firm planned orders due later then Planning Time Fence Date
The planning engine uses Planning Time Fence Date as follows:
In unconstrained plans, it does not set any planned order due dates earlier than Planning Time Fence Date
In constrained plans, it does not set any planned order due dates earlier then Planning Time Fence Date if, for
A make order, the start date of the first resource sequence within the first operation is earlier than or on Planning Time Fence Date
A buy order, purchase requisition, and purchase order, Dock Date is earlier than or on Planning Time Fence Date
A transfer order, internal requisition and flow schedule, Start Date is earlier than or on Planning Time Fence Date
For more information on profile options, see Profile Options Introduction.
These following profile options relate to planning time fence control and firming of supplies:
The planning engine decides whether to calculate Planning Time Fence Date based on plan option Planning Time Fence Control. These profile options instruct the planning engine to create natural time fences and to change Planning Time Fence Date to the natural time fence date if the natural time fence date is later than the calculated Planning Time Fence Date:
MRP: Create Time Fence: Instructs the planning engine to create a natural time fence for an item at the completion date of the latest firm discrete job, purchase order, flow schedule, or shipment.
MRP: Firm Planned Order Time Fence: Instructs the planning engine to create a natural time fence for an item at the completion date of the latest firm planned order.
MSC: Firm Internal Requisition Time Fence: Instructs the planning engine to create a natural time fence for an item at the completion date of the latest firm internal requisition.
These profile options affect the firming of specific supply types:
MRP: Firm Internal Req Transferred to OE: Instructs the planning engine to consider internal requisitions that have transferred to Oracle Order Management as firm.
You cannot reschedule transferred internal requisitions from Oracle Advanced Supply Chain Planning. To reschedule it, cancel the internal requisition and the internal sales order line in the source instance and create them again.
Since the planning engine coordinates the dates between internal requisitions and their internal sales orders, it never reschedules the internal sales order of a firm internal requisition.
MRP: Firm Requisitions within Time Fence: Instructs the planning engine to net purchase orders before netting purchase requisitions. Therefore, it may cancel or reschedule out some purchase requisitions that have earlier dates than some of the purchase orders for the same item.
MSC: Firm Intransit and PO in Receiving Supplies: Instructs the planning engine, in unconstrained plans, to consider intransit purchase orders and purchase orders in receiving as firm. It issues reschedule recommendations but you cannot release them from Planner Workbench.
MSC: MPS Auto-Firm All Planned Orders: Instructs the planning engine, for master production schedule plans, to firm all planned orders.
When a master production schedule is a demand schedule for another plan, the planning engine considers all master production schedule planned orders as firm, regardless of this profile option.
MSO: Firm Orders/Operations within Time Fence: Instructs the planning engine how to use planning time fence control on purchase orders, purchase requisitions, internal requisitions, discrete jobs, and flow schedules. The effect depends on order type; see Planning Time Fence Logic for Supply Types in this topic.
MSO: Net All Firm Supplies Before Creating Planned Orders: Instructs the planning engine to net firmed supplies available in any future period before creating new planned orders.
Profile option MRP: Recommend action within Planning Time Fence affects exceptions and recommendations. It instructs the planning engine, in unconstrained plans, to generate recommendations for scheduled receipts earlier than Planning Time Fence Date.
In unconstrained plans, the planning engine uses Due Date to determine if the supply is earlier than, later than, or on Planning Time Fence Date. In constrained plans, the planning engine uses different methods depending on order type and supply type.
Firm planned orders: The planning engine does not reschedule the completion date of a firm planned order but may reschedule its manufacturing resources. If profile option MRP: Firm Planned Order Time Fence is Yes, the planning engine creates a natural time fence.
Planned Orders: The planning engine does not create planned orders earlier than Planning Time Fence date. It schedules planned orders as follows depending on supply type:
Make supplies: Start Date of the first operation's first resource on or after Planning Time Fence Date.
Purchased supplies: Dock Date on or after Planning Time Fence Date
Transfer supplies: Start Date at the receiving organization on or after Planning Time Fence Date.
Firm purchase orders: Generally, the planning engine does not recommend reschedule or cancel.
Non-firm purchase orders, purchase requisitions, and internal requisitions: Generally, the planning engine recommends reschedule or cancel. However, it does not recommend reschedule in for jobs and schedules in the following circumstances in Unconstrained plans and Constrained - Enforce Capacity Constraints plans:
The due date is earlier or on the Planning Time Fence Date
It wants to reschedule the due date from later than Planning Time Fence Date to earlier or on Planning Time Fence Date.
If profile options MSO: Firm Purchase Orders Within Time Fence and MSO: Firm Requisitions Within Time Fence are Yes, the planning engine:
Considers non-firm purchase orders and purchase requisitions with Dock Date earlier than or on Planning Time Fence Date as firm and does not issue reschedule recommendations.
Considers internal requisitions with Start Date earlier than or on Planning Time Fence Date in the receiving organization as firm and does not issue reschedule recommendations.
If profile option MSO: Firm Operations/Orders Within Time Fence is No, the planning engine:
For non-firm purchase orders, purchase requisitions and internal requisitions, recommends reschedule out as needed, limited by the demand dates. It can recommend a reschedule out date that is earlier or on Planning Time Fence Date.
For purchase requisitions and internal requisitions, recommends cancel as needed
Firm standard discrete jobs and firm repetitive schedules: Generally, the planning engine does not recommend reschedule or cancel.
Non-firm standard discrete jobs and non-firm repetitive schedules: Generally, the planning engine recommends reschedule or cancel. However, it does not recommend reschedule in for jobs and schedules in the following circumstances in Unconstrained plans and Constrained - Enforce Capacity Constraints plans:
The due date is earlier or on the Planning Time Fence Date
It wants to reschedule the due date from later than Planning Time Fence Date to earlier or on Planning Time Fence Date.
If profile option MSO: Firm Operations/Orders Within Time Fence is Yes, the planning engine:
Considers operations with start dates earlier or on Planning Time Fence Date as firm
Considers operations with start dates later than Planning Time Fence Date as non-firm and subject to reschedule recommendations
Does not recommend reschedule against orders and schedules entirely earlier than or on Planning Time Fence Date
If profile option MSO: Firm Operations/Orders Within Time Fence is No, the planning engine, for non-firm orders:
Recommends reschedule out as needed, limited by the demand dates. It can recommend a reschedule out date that is earlier or on Planning Time Fence Date.
Does not cancel orders no longer pegged to a demand but issues excess exception messages
The planning engine considers non-standard discrete jobs and flow schedules as firm and not subject to reschedule recommendations. It does not recommend cancel for non-standard discrete jobs.
The planning engine's calculation of dates that you see in Planner Workbench can differ for:
Demand dates, depending on whether the demand is independent or dependent
Supply dates, depending on whether the supply is pegged to an independent or dependent demand
This table shows Planner Workbench demand dates.
Set the profile option MSC: Use Shipping Receiving Calendar at the site level. Do not set it at the user level or set in the same as at the site level. For example:
The site level value is Yes. The collection process collects the calendars and the planning engine uses them.
The user level value is No. Planner Workbench for that user does not display the collected calendars but displays all calendars as 24x7.
It appears to this user that the planning engine does not follow the calendars.
Demand Satisfied Date is the latest due date of the supplies pegged directly to an end demand. In unconstrained plans, it is the same as Demand Date. All supplies pegged to a end demand that have an end date on or before the suggested due date are included in the Demand Satisfied Date, even if that demand is late by a few hours.
Note: Customer date type is defined as the order date type (ship date or arrival date). When you specify a date in the sales order line in the request date column, the planning engine interprets the date as either a ship date or an arrival date depending on the customer's order date type. During the ATP calculation process, the planning engine calculates the schedule ship date and schedule arrival date based on the request date, the customer date type, and the transit lead-time from the shipping organization to the customer site using the selected ship method on the sales order.
Note: In the Supply Demand window, if the customer date type is ship date, the requested ship date is from the sales order line field Request Date. If the customer date type is arrival date, the requested arrival date is from the sales order line field Request Date. In both cases, the planning engine calculates the other field using the transit lead-time from the shipping organization to the customer site using the selected ship method on the sales order.
Note: The scheduled ship date and the scheduled arrival date are from the sales order fields with the same name.
Note: The promised arrival date and the promised ship date are from the sales order field promise date, with one of the two calculated using the order date type and the transit lead-time from the sales order. The calculation is the same as the requested arrival date or the requested ship date based on the order date type.
This table shows Planner Workbench supply dates:
Need by Date represents the Suggested Due Date of a supply as calculated by an unconstrained plan. For constrained but not optimized plans, Need By Date is the date that the planning engine uses to determine the effectivity date for the bill of material explosion.
Updated Need by Date represents the Suggested Due Date of a supply as calculated by the optimization planning phase for both cost-based or rule-based optimization. This approximation may not match the results of the detailed scheduling phase. If Updated Need By Date has an entry, the planning engine uses it, instead of Need by Date, to determine the effectivity date for the bill of material explosion.
If you use Oracle Transportation Management, you can update your production plans with the current status of estimated arrival times of purchase and transfer orders in transit. These changes occur either because of a change in the transportation plan or because of carries updates.
When Oracle Transportation Management detects a change in an estimated arrival time, it:
Notes the estimated arrival time in your production plans for purchase requisitions, internal requisitions, and internal sales orders
Compares its estimated arrival time to the corresponding plan dock date or scheduled arrival date
Issues exception messages if the dates differ--Order will be delivered later than scheduled or Order will be delivered earlier than scheduled
Sends a notification to the planner with a link to drill down to Oracle Transportation Management for details
Updates the arrival date in Oracle Collaborative Planning
Arranges for the Oracle Collaborative Planning exception process to evaluate the updates and issue exceptions as necessary
When the next production plan runs, it:
Updates the dock date with the estimated arrival time
Firms the order
Issues exception messages as necessary when the new arrival time has an effect on demand satisfaction—late replenishment, early replenishment, order at risk
You can view transportation updates in form View Transportation Updates
This topic shows examples of lead-time calculations for unconstrained and constrained plans. Some examples show the effect of planning time fence control on lead-time calculations.
Constrained - Enforce demand due dates plans violate the planning time fence to meet the demand due date. Since the lead-time calculations are similar between these and Constrained - Enforce capacity constraints plans, there are no examples specifically for no specific examples are provided for Constrained - Enforce demand due dates plans with planning time fence control.
The lead-time examples use these three calendars. They refer to dates as days, for example, Day 1 and Day 2, rather than as specific dates such as September 1.
Each calendar covers multiple weeks, each row has seven days. Non-work days have the letters NW after their day number; non-delivery days have the letters ND after their day number.
This is the organization calendar that organization ORG1, the receiving organization, uses. It follows a 5 on - 2 off pattern.
Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6NW | 7NW |
8 | 9 | 10 | 11 | 12 | 13NW | 14NW |
15 | 16 | 17 | 18 | 19 | 20NW | 21NW |
22 | 23 | 24 | 25 | 26 | 27NW | 28NW |
29 | 30 | 31 | 32 | 33 | 34NW | 35NW |
36 | 37 | 38 | 39 | 40 | 41NW | 42NW |
This is the organization calendar that organization ORG2, the shipping organization, uses. It follows a 6 on - 1 off pattern.
Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7NW |
8 | 9 | 10 | 11 | 12 | 13 | 14NW |
15 | 16 | 17 | 18 | 19 | 20 | 21NW |
22 | 23 | 24 | 25 | 26 | 27 | 28NW |
29 | 30 | 31 | 32 | 33 | 34 | 35NW |
36 | 37 | 38 | 39 | 40 | 41 | 42NW |
This is the delivery calendar from the approved supplier list for the supplier that supplies the purchased component.
Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday |
---|---|---|---|---|---|---|
1 | 2ND | 3 | 4ND | 5 | 6 | 7ND |
8 | 9ND | 10 | 11ND | 12 | 13 | 14ND |
15 | 16ND | 17 | 18ND | 19 | 20 | 21ND |
22 | 23ND | 24 | 25ND | 26 | 27 | 28ND |
29 | 30ND | 31 | 32ND | 33 | 34 | 35ND |
36 | 37ND | 38 | 39ND | 40 | 41 | 42ND |
Example 1: Manufactured Supply with Purchased Component
This example shows lead-time calculations for Item A manufactured supply using Item B purchased component both in organization ORG1. Item B is used at the first operation of Item A and its usage in Item A is 1.
lead-times:
Item A: Fixed, 3 days; Variable, 0.5 days, Preprocessing, 1 day
Item B: Processing, 2 days, Preprocessing, 1 day; Postprocessing, 1 day
Sourcing rules:
Item A in ORG1: Type, Make at; Allocation, 100; Rank, 1
Item B in ORG1: Type, Buy from; Allocation, 100; Rank, 1
There is a demand for 8 units of Item A due on day 19.
These calculations are for an unconstrained plan. The calculations for a constrained plan are similar, except that they consider detailed resource and material constraints.
See Example 1: Manufactured Supply with Purchased Component in this topic for setup information.
Need By Date: Day 19 (Demand Due Date)
Suggested Due Date: Day 19 (Need By Date)
Suggested Start Date: Day 10
Use ORG1 organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 19 - (3 days (0.5 days * 8) = Day 19 - 7 days
Two non-work days: Days 13 and 14
Suggested Order Date: Day 9
Use ORG1 organization calendar
Suggested Start Date - Preprocessing = Day 10 - 1 day
You use purchased component Item B to manufacture Item A. If you use Item B at Item A's first operation (Material Scheduling Method of Order Start Date), Demand Due Date: Day 10 (Item A Suggested Start Date).
Need By Date: Day 10 (Demand Due Date)
Suggested Due Date: Day 10 (Need By Date)
Suggested Dock Date: Day 8
Use ORG1 organization calendar
Suggested Due Date - Postprocessing Time = Day 10 - 1 day = Day 9
Use ASL delivery calendar for supplier of Item B
Day 9 is not a delivery work day. Move dock date to next earlier delivery work day.
Suggested Ship Date: Day 4
Use ORG1 organization calendar
Dock Date - Processing = Day 8 - 2 days
Two non-workdays: Days 6 and 7
Suggested Start Date: Day 4 (Suggested Ship Date)
Suggested Order Date: Day 3
Use ORG1 organization calendar
Start Date - Preprocessing = Day 4 - 1 day
This table summarizes the lead-times for Scenario 1: Unconstrained Plan, No Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 19 | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 19 | n/a | Day 10 | Day 9 |
ORG1 | B | Planned order demand | Day 10 | n/a | n/a | n/a |
ORG1 | B | Planned order | Day 10 | Day 8 | Day 4 | Day 3 |
See Example 1: Manufactured Supply with Purchased Component in this topic for setup information.
Item A, organization ORG1 Planning Time Fence Days: 15
Item A, organization ORG Planning Time Fence Date: Day 19
Use ORG1 organization calendar
Day 1 + Planning Time Fence Days = Day 1 + 15 days
Four non-work days: Days 6, 7, 13, and 14
The planning engine cannot schedule a planned order until the day after Planning Time Fence Date.
Need By Date: Day 19 (Demand Due Date)
Suggested Due Date: Day 22
Need By Date is Day 19
Planning Time Fence Date is Day 19
The planning engine cannot schedule planned order until Day 22 (Planning Time Fence Date + 1) = Day 19 + 1 day
Two non-work days: Days 20 and 21
Supply is due after Demand Due Date; issue shortage and late replenishment exception messages
Suggested Start Date: Day 11
Use ORG1 organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 22 - (3 days (0.5 days * 8) = Day 22 - 7 days
Four non-work days: Days 13, 14, 20, and 21
Suggested Order Date: Day 10
Use ORG1 organization calendar
Suggested Start Date - Preprocessing = Day 11 - 1 day
You use purchased component Item B to manufacture Item A. If you use Item B at Item A's first operation (Material Scheduling Method of Order Start Date), Demand Due Date: Day 11 (Item A Suggested Start Date).
Need By Date: Day 11 (Demand Due Date)
Suggested Due Date: Day 11 (Need By Date)
Suggested Dock Date: Day 10
Use ORG1 organization calendar
Suggested Due Date - Postprocessing Time = Day 11 - 1 day = Day 10
Use ASL delivery calendar for supplier of Item B
Day 10 is delivery work day
Suggested Ship Date: Day 8
Use ORG1 organization calendar
Dock Date - Processing = Day 10 - 2 days
Suggested Start Date: Day 8 (Suggested Ship Date)
Suggested Order Date: Day 5
Use ORG1 organization calendar
Start Date - Preprocessing = Day 8 - 1 day
Two non-work days: Days 6 and 7
This table summarizes the lead-times for Scenario 2: Unconstrained Plan, Assembly Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 19 | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 22 | n/a | Day 11 | Day 10 |
ORG1 | B | Planned order demand | Day 11 | n/a | n/a | n/a |
ORG1 | B | Planned order | Day 11 | Day 10 | Day 8 | Day 5 |
Constrained plans perform detailed scheduling which considers resource and material constraints. These examples assume no constraints and use lead-time offsets; the planning engine would only do this if Item A has no routing.
See Example 1: Manufactured Supply with Purchased Component in this topic for setup information.
Need By Date: Day 19 (Demand Due Date)
Suggested Due Date: Day 19 (Need By Date)
Suggested Start Date: Day 22
Use ORG1 organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 19 - (3 days (0.5 days * 8) = Day 19 - 7 days = Day 10
Two non-work days: Days 13 and 14
Planning Time Fence Date is Day 19
The planning engine cannot schedule planned order until Day 22 (Planning Time Fence Date + 1) = Day 19 + 1 day
Two non-work days: Days 20 and 21
Suggested Order Date: Day 19
Use ORG1 organization calendar
Suggested Start Date - Preprocessing = Day 22 - 1 day
Two non-work days: Days 20 and 21
Recalculate Suggested Due Date by forward scheduling from Suggested Dock Date
Suggested Due Date: Day 23
Use ORG1 organization calendar
Suggested Dock Date + Postprocessing = Day 22 + 1 = Day 23
Supply is due after Demand Due Date; issue shortage exception message
You use purchased component Item B to manufacture Item A. If you use Item B at Item A's first operation (Material Scheduling Method of Order Start Date), Demand Due Date: Day 22 (Item A Suggested Start Date).
Need By Date: Day 22 (Demand Due Date)
Suggested Due Date: Day 2 (Need By Date)
Suggested Dock Date: Day 19
Use ORG1 organization calendar
Suggested Due Date - Postprocessing Time = Day 22 - 1 day = Day 19
Two non-work days: Days 20 and 21
Use ASL delivery calendar for supplier of Item B
Day 19 is delivery work day
Suggested Ship Date: Day 17
Use ORG1 organization calendar
Dock Date - Processing = Day 19 - 2 days
Suggested Start Date: Day 17 (Suggested Ship Date)
Suggested Order Date: Day 16
Use ORG1 organization calendar
Start Date - Preprocessing = Day 17 - 1 day
This table summarizes the lead-times for Scenario 3: Constrained - Enforce Capacity Constraints Plan, Assembly Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 19 | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 31 | n/a | Day 22 | Day 19 |
ORG1 | B | Planned order demand | Day 22 | n/a | n/a | n/a |
ORG1 | B | Planned order | Day 22 | Day 19 | Day 17 | Day 16 |
Example 2: Purchased Component
These examples are the same as the scenarios in Example 1 but purchased component Item B has a planning time fence.
The scenarios in this example are similar to Scenario 1. In Scenario 1, neither assembly Item A or purchased component Item B has a planning time fence. In this scenario, assembly Item A does not have a planning time fence but purchased component Item B has a planning time fence.
Item B, organization ORG1 Planning Time Fence Days: 15
Item B, organization ORG Planning Time Fence Date: Day 19
Use ORG1 organization calendar
Day 1 + Planning Time Fence Days = Day 1 + 15 days
Four non-work days: Days 6, 7, 13, and 14
The planning engine cannot schedule a planned order until the day after Planning Time Fence Date.
See Example 2: Purchased Component in this topic for setup information.
See Scenario 1: Unconstrained Plan, No Planning Time Fence Control in this topic for the calculations of supply for Item A and demand for Item B. Item B has dependent demand due on Day 10.
Need By Date: Day 10 (Demand Due Date)
Suggested Due Date: Day 22
Need By Date is Day 10
Use ORG1 organization calendar
Planning Time Fence Date is Day 19
The planning engine cannot schedule planned order until Day 22 (Planning Time Fence Date + 1) = Day 19 + 1 day
Two non-work days: Days 20 and 21
Supply is due after Demand Due Date; issue shortage exception message. Do not reschedule supply for Item A.
Suggested Dock Date: Day 19
Use ORG1 organization calendar
Suggested Due Date - Postprocessing Time = Day 22 - 1 day = Day 19
Two non-work days: Days 20 and 21
Use ASL delivery calendar for supplier of Item B
Day 9 is a delivery work day
Suggested Ship Date: Day 17
Use ORG1 organization calendar
Dock Date - Processing = Day 19 - 2 days
Suggested Start Date: Day 17 (Suggested Ship Date)
Suggested Order Date: Day 16
Use ORG1 organization calendar
Start Date - Preprocessing = Day 17 - 1 day
This table summarizes the lead-times for Scenario 4: Unconstrained Plan, Purchased Component Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 19 | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 31 | n/a | Day 10 | Day 9 |
ORG1 | B | Planned order demand | Day 10 | n/a | n/a | n/a |
ORG1 | B | Planned order | Day 22 | Day 19 | Day 17 | Day 16 |
See Example 2: Purchased Component in this topic for setup information.
See Scenario 1: Unconstrained Plan, No Planning Time Fence Control in this topic for the calculations of supply for Item A and demand for Item B. Item B has dependent demand due on Day 10.
Need By Date: Day 10 (Demand Due Date)
Suggested Due Date: Day 10 (Need By Date)
Suggested Dock Date: Day 22
Use ORG1 organization calendar
Suggested Due Date - Postprocessing Time = Day 10 - 1 day = Day 9
Planning Time Fence Date is Day 19
The planning engine cannot schedule planned order until Day 22 (Planning Time Fence Date + 1) = Day 19 + 1 day
Two non-work days: Days 20 and 21
Use ASL delivery calendar for supplier of Item B
Day 22 is a delivery work day
Suggested Ship Date: Day 18
Use ORG1 organization calendar
Dock Date - Processing = Day 22 - 2 days
Two non-work days: Days 21 and 21
Suggested Start Date: Day 18 (Suggested Ship Date)
Suggested Order Date: Day 17
Use ORG1 organization calendar
Start Date - Preprocessing = Day 18 - 1 day
Recalculate Suggested Due Date by forward scheduling from Suggested Dock Date
Suggested Due Date: Day 23
Use ORG1 organization calendar
Suggested Dock Date + Postprocessing = Day 22 + 1= Day 23 + 7 days = Day 10
Supply is due after Demand Due Date; issue shortage exception message. Reschedule supply for Item A.
Suggested Start Date: Day 23 (Item B Suggested Due Date)
Suggested Due Date: Day 32
Use ORG1 organization calendar
Suggested Start Date + ((Fixed + (Variable * Supply quantity)) = Day 23 - (3 days + (0.5 days * 8) = Day 23 + 7 days = Day 32
Two non-work days: Days 27 and 28
Supply is due after Demand Due Date; issue shortage exception message.
Suggested Order Date: Day 22
Use ORG1 organization calendar
Suggested Start Date - Preprocessing = Day 23 - 1 day
This table summarizes the lead-times for Scenario 5: Constrained - Enforce Capacity Constraints Plan, Purchased Component Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 19 | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 32 | n/a | Day 23 | Day 22 |
ORG1 | B | Planned order demand | Day 23 | n/a | n/a | n/a |
ORG1 | B | Planned order | Day 23 | Day 22 | Day 18 | Day 17 |
Example 3: Transfer Component
This example shows lead-time calculations for Item A manufactured supply using Item C transfer component both in organization ORG1. ORG2 supplies Item C to organization ORG1. Item C is used at the first operation of Item A and its usage in Item A is 1.
Lead-times:
Item A in ORG1: Fixed, 3 days; Variable, 0.5 days, Preprocessing, 1 day
Item C in ORG1: Processing, 2 days, Preprocessing, 1 day; Postprocessing, 1 day
Item C in ORG2: Fixed, 4 days; Variable, 0.25 days, Preprocessing, 3 days
Sourcing rules:
Item A in ORG1: Type, Make at; Allocation, 100; Rank, 1
Item C in ORG1: Type, Transfer from; Allocation, 100; Rank, 1; Intransit Time, 2 days
Item C in ORG2: Type, Make at; Allocation, 100; Rank, 1
There is a demand for 8 units of Item A due on day 33.
These calculations are for an unconstrained plan. The calculations for a constrained plan are similar, except that they consider detailed resource and material constraints.
See Example 3: Transfer Component in this topic for setup information.
Need By Date: Day 33 (Demand Due Date)
Suggested Due Date: Day 33 (Need By Date)
Suggested Start Date: Day 24
Use ORG1 receiving organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 33 - (3 days (0.5 days * 8) = Day 33 - 7 days
Two non-work days: Days 27 and 28
Suggested Order Date: Day 23
Use ORG1 receiving organization calendar
Suggested Start Date - Preprocessing = Day 24 - 1 day
You use purchased component Item C to manufacture Item A. If you use Item C at Item A's first operation (Material Scheduling Method of Order Start Date), Demand Due Date: Day 24 (Item A Suggested Start Date).
Need By Date: Day 24 (Demand Due Date)
Suggested Due Date: Day 24 (Need By Date)
Suggested Dock Date: Day 23
Use ORG1 receiving organization calendar
Suggested Due Date - Postprocessing = Day 24 - 1 day = Day 23
Suggested Ship Date: Day 20
Use ORG1 receiving organization calendar
Suggested Dock Date - Intransit Time [include non-workdays] = Day 23 - 2 days = Day 21
Use ORG2 shipping organization calendar
Day 21 is not a work day. Move suggested ship date to next earlier work day.
Suggested Start Date: Day 13
Use ORG2 shipping organization calendar
Suggested Ship Date - ((Fixed + (Variable * Supply quantity)) [Fixed and Variable from ORG2]= Day 20 - (4 days (0.25 days * 8) = Day 20 - 6 days
One non-workday: Day 14
Suggested Order Date: Day 12
Use ORG1 receiving organization calendar
Start Date - Preprocessing = Day 13 - 1 day
You transfer component Item C from ORG2 to ORG1. Demand Due Date: Day 20 (Item A at ORG1 Suggested Ship Date).
Need By Date: Day 20 (Demand Due Date)
Suggested Due Date: Day 20 (Need By Date)
Suggested Start Date: Day 13
Use ORG2 shipping organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 20 - (4 days - (0.25 days * 8) = Day 20 - 6 days
One non-work day: Day 14
Suggested Order Date: Day 10
Use ORG2 shipping organization calendar
Suggested Start Date - Preprocessing = Day 13 - 3 day
This table summarizes the lead-times for Scenario 6: Unconstrained Plan, No Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Ship Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 33 | n/a | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 33 | n/a | n/a | Day 24 | Day 23 |
ORG1 | C | Planned order demand | Day 24 | n/a | n/a | n/a | n/a |
ORG1 | C | Planned order | Day 24 | Day 23 | Day 20 | Day 13 | Day 12 |
ORG2 | C | Planned order demand | Day 20 | n/a | n/a | n/a | n/a |
ORG2 | C | Planned order | Day 20 | n/a | n/a | Day 13 | Day 10 |
In constrained plans, the planning engine does not schedule Start Date to include the estimated processing time in the shipping org. This avoids pushing out a receiving order when the item may be on-hand or in process.
Compare this table with the table for unconstrained plans in Scenario 6: Calculations for Item C Supply (Make At, Shipping Organization) in this topic. Note the differences in the Suggested Start Date and Suggested Order Date in the receiving organization ORG1.
This table summarizes the lead-times for Scenario 6: Unconstrained Plan, No Planning Time Fence Control if you used a constrained plan.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Ship Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 33 | n/a | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 33 | n/a | n/a | Day 24 | Day 23 |
ORG1 | C | Planned order demand | Day 24 | n/a | n/a | n/a | n/a |
ORG1 | C | Planned order | Day 24 | Day 23 | Day 20 | Day 20 | Day 19 |
ORG2 | C | Planned order demand | Day 20 | n/a | n/a | n/a | n/a |
ORG2 | C | Planned order | Day 20 | n/a | n/a | Day 13 | Day 10 |
This scenario is the same as Scenario 6 but transfer component Item C has a planning time fence in receiving organization ORG1.
See Example 3: Transfer Component in this topic for setup information.
In Scenario 6, neither assembly Item A or transfer component Item C has a planning time fence. In this scenario, assembly Item A does not have a planning time fence but transfer component Item C has a planning time fence.
Item C, organization ORG1 Planning Time Fence Days: 20
Item C, organization ORG1 Planning Time Fence Date: Day 26
Use ORG1 receiving organization calendar
Day 1 + Planning Time Fence Days = Day 1 + 20 days
Six non-work days: Days 6, 7, 13, 14, 20, and 21
The planning engine cannot schedule a planned order until the day after Planning Time Fence Date.
See Scenario 6: Unconstrained Plan, No Planning Time Fence Control in this topic for the calculations of supply for Item A and demand for Item C at the receiving organization ORG1. Item C in the receiving organization has dependent demand due on Day 24.
Need By Date: Day 24 (Demand Due Date)
Suggested Due Date: Day 29
Use ORG1 receiving organization calendar
Need By Date: Day 24
Planning Time Fence Date is Day 26
The planning engine cannot schedule planned order until Day 29 (Planning Time Fence Date + 1) = Day 26 + 1 day
Two non-work days: Days 27 and 28
Supply is due after Demand Due Date; issue shortage exception message. Do not reschedule any other supply order that requires this supply. However, supplies below this one in the supply chain bill are delayed as the planning engine plans them.
Suggested Dock Date: Day 26
Use ORG1 receiving organization calendar
Suggested Due Date - Postprocessing = Day 29 - 1 day
Two non-work days: Days 27 and 28
Suggested Ship Date: Day 24
Use ORG1 receiving organization calendar
Suggested Dock Date - Intransit Time [include non-workdays] = Day 26 - 2 days = Day 24
Use ORG2 shipping organization calendar
Day 24 is a work day
Suggested Start Date: Day 17
Use ORG2 shipping organization calendar
Suggested Ship Date - ((Fixed + (Variable * Supply quantity)) [Fixed and Variable from ORG2] = Day 24 - (4 days + (0.25 days * 8) = Day 24 - 6 days
One non-workday: Day 21
Suggested Order Date: Day 16
Use ORG1 receiving organization calendar
Start Date - Preprocessing = Day 17 - 1 day
You transfer component Item C from ORG2 to ORG1. Demand Due Date: Day 24 (Item A at ORG1 Suggested Ship Date).
Need By Date: Day 24 (Demand Due Date)
Suggested Due Date: Day 24 (Need By Date)
Suggested Start Date: Day 17
Use ORG2 shipping organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 24 - (4 days - (0.25 days * 8) = Day 24 - 6 days
One non-work day: Day 21
Suggested Order Date: Day 13
Use ORG2 shipping organization calendar
Suggested Start Date - Preprocessing = Day 17 - 3 day
One non-work day: Day 14
This table summarizes the lead-times for Scenario 7: Unconstrained Plan, Purchased Component Planning Time Fence Control
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Ship Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 33 | n/a | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 33 | n/a | n/a | Day 24 | Day 23 |
ORG1 | C | Planned order demand | Day 24 | n/a | n/a | n/a | n/a |
ORG1 | C | Planned order | Day 29 | Day 26 | Day 24 | Day 17 | Day 16 |
ORG2 | C | Planned order demand | Day 24 | n/a | n/a | n/a | n/a |
ORG2 | C | Planned order | Day 24 | n/a | n/a | Day 17 | Day 13 |
Constrained plans perform detailed scheduling which considers resource and material constraints. These examples assume no constraints and use lead-time offsets; the planning engine would only do this if Item A has no routing.
See Example 3: Transfer Component in this topic for setup information.
See Scenario 7: Unconstrained Plan, Purchased Component Planning Time Fence Control in this topic for the calculation of Planning Time Fence Date for Item C in organization ORG1. Item C organization ORG1 Planning Time Fence Date: Day 26. The planning engine cannot schedule a planned order until the day after Planning Time Fence Date.
See Scenario 6: Unconstrained Plan, No Planning Time Fence Control in this topic for the calculations of supply for Item A and demand for Item C at the receiving organization ORG1. Item C in the receiving organization has dependent demand due on Day 24.
Need By Date: Day 24 (Demand Due Date)
Suggested Due Date: Day 24 (Need by Date)
Suggested Dock Date: Day 23
Use ORG1 receiving organization calendar
Suggested Due Date - Postprocessing = Day 24 - 1 day
Suggested Ship Date: Day 20
Use ORG1 receiving organization calendar
Suggested Dock Date - Intransit Time [include non-workdays] = Day 23 - 2 days = Day 21
Use ORG2 shipping organization calendar
Day 21 is not a work day. Move suggested ship date to next earlier work day.
Suggested Start Date: Day 27
Use ORG2 shipping organization calendar
Suggested Ship Date - ((Fixed + (Variable * Supply quantity)) [Fixed and Variable from ORG2] = Day 24 - (4 days + (0.25 days * 8) = Day 20 - 6 days = Day 13
One non-workday: Day 14
Planning Time Fence Date is Day 26
The planning engine cannot schedule planned order until Day 29 (Planning Time Fence Date + 1) = Day 26 + 1 day = Day 27
Day 27 is a workday in ORG2 shipping organization. It is a non-workday in ORG1 receiving organization.
Suggested Order Date: Day 26
Use ORG1 receiving organization calendar
Start Date - Preprocessing = Day 27 - 1 day
Recalculate Suggested Ship Date, Suggested Dock Date, and Suggested Due Date by forward scheduling from Suggested Start Date.
Suggested Ship Date: Day 31
Use ORG2 shipping organization calendar
Suggested Start Date + (Fixed + (Variable * Supply quantity)) [Fixed and Variable from ORG2] = Day 27 + (4 days + (0.25 days * 8) = Day 27 + 6 days
One non-workday: Day 28
Suggested Dock Date: Day 33
Use ORG1 receiving organization calendar
Suggested Ship Date + Intransit Time [include non-workdays] = Day 31 + 2 days = Day 33
Use ORG2 shipping organization calendar
Day 33 is a work day.
Suggested Due Date: Day 36
Use ORG1 receiving organization calendar
Suggested Dock Date + Postprocessing = Day 33 + 1 day
Two non-workdays: Days 34 and 35
Reschedule Item A supply Suggested Start Date and Suggested Due Date by forward scheduling from Day 36 (Item C Suggested Due Date in ORG1 receiving organization)
Suggested Start Date: Day 36 (Item C Suggested Due Date)
Suggested Due Date: Day 45
Use ORG1 organization calendar
Suggested Start Date + ((Fixed + (Variable * Supply quantity)) = Day 36 + (3 days - (0.5 days * 8) = Day 36 + 7 days
Two non-work days: Days 41 and 42
Reschedule Item A supply Suggested Order Date by backward scheduling from Day 36 (Item C Suggested Due Date in ORG1 receiving organization)
Suggested Order Date: Day 33
Use ORG1 organization calendar
Suggested Start Date - Preprocessing = Day 36 - 1 day
Two non-workdays: Days 34 and 35
You transfer component Item C from ORG2 to ORG1. Demand Due Date: Day 31 (Item C Suggested Ship Date at ORG1 receiving organization).
Need By Date: Day 31 (Demand Due Date)
Suggested Due Date: Day 31 (Need By Date)
Suggested Start Date: Day 24
Use ORG2 shipping organization calendar
Suggested Due Date - ((Fixed + (Variable * Supply quantity)) = Day 31 - (4 days - (0.25 days * 8) = Day 31 - 6 days
One non-work day: Day 28
Suggested Order Date: Day 20
Use ORG2 shipping organization calendar
Suggested Start Date - Preprocessing = Day 24 - 3 day
One non-work day: Day 21
This table summarizes the lead-times for Scenario 8: Constrained - Enforce Capacity Constraints Plan, Transfer Component Planning Time Fence Control.
Organization | Item | Order Type | Suggested Due Date | Suggested Dock Date | Suggested Ship Date | Suggested Start Date | Suggested Order Date |
---|---|---|---|---|---|---|---|
ORG1 | A | Demand | Day 33 | n/a | n/a | n/a | n/a |
ORG1 | A | Planned order | Day 45 | n/a | n/a | Day 36 | Day 33 |
ORG1 | C | Planned order demand | Day 36 | n/a | n/a | n/a | n/a |
ORG1 | C | Planned order | Day 36 | Day 33 | Day 31 | Day 27 | Day 26 |
ORG2 | C | Planned order demand | Day 31 | n/a | n/a | n/a | n/a |
ORG2 | C | Planned order | Day 31 | n/a | n/a | Day 24 | Day 26 |
This topic explains the scheduling of manufacturing work orders. Although the examples use Oracle Work in Process discrete jobs, they also apply to the scheduling of the primary path of Oracle Shop Floor Manufacturing lot based jobs and Oracle Process Manufacturing work orders.
This diagram shows a plan with the following features:
Run on May 5
Planning time fence control enabled
The profile options that create a natural time fence based on existing firmed supplies are disabled.
Planning Time Fence Date is based on the item attribute (User defined, 4 days) as May 9 and considers working days in the organization. The calendar for this organization has no non-work days in the organization calendar.
This diagram shows the supplies for this item after the plan run. The supplies have the following characteristics:
Job 1: Completely scheduled in the past.
Job 2: Operations scheduled in the past and completion date of May 6 is earlier than Planning Time Fence Date.
Job 3: Three operations scheduled to start prior to Planning Time Fence Date.
Job 4 and 5: All operations scheduled to start after Planning Time Fence Date.
Job 6: This job is firmed to complete on May 10.
This diagram shows the state of the collected discrete jobs.
State of Collected Discrete Jobs
In unconstrained plans, the planning engine schedules manufacturing work order completion dates earlier than Planning Time Fence Date, as follows:
Planned manufacturing orders and non-firm manufacturing work orders: Order Due Date never scheduled earlier than the item's Planning Time Fence Date.
Firm manufacturing work orders: Never cancel, reschedule, or change the Order Due Date.
Firm planned manufacturing orders: Retained based on the value of plan option Overwrite. If None or Overwrite Outside Planning Time Fence, retain the order and consider Order Due Date firm.
This diagram shows the same manufacturing work orders from topic Manufacturing Work Order Scheduling scheduled in an unconstrained plan. The planning engine schedules Order Due Date then offsets operations from Order Due Date according to Lead Time % on the manufacturing work order routing. For operations scheduled prior to the plan run date, the planning engine compresses them to start and complete on the plan run date:
Job 1: is rescheduled out to meet its demand on time. Operation 10 would have been scheduled to start and complete in the past. These dates are both updated to Start on Plan Run Date. Operation 20 would have been scheduled to start in the past and is now updated to Start of Plan Run Date
Job 2: Order Due Date rescheduled out to meet its demand on time. Operation start and completion dates offset with no compression.
Job 3: Order Due Date rescheduled out to meet its demand on time. Operation start and completion dates offset with no compression
Job 4: Rescheduled in to meet demand on time because Order Due Date is later than the Planning Tine Fence Date. All operations offset from this date.
Job 5: Canceled because it has no pegged demand
Job 6: A firm job, not rescheduled.
This diagram shows the effect of Planning Time Fence Date and firming on discrete job scheduling in Unconstrained plans.
Discrete Job Scheduling with Planning Time Fence and Firming, Unconstrained Plan
For a Constrained - Enforce capacity constraints plan, the planning engine applies the following planning time fence control rules based on the item's Planning Time Fence Date:
Planned orders: Do not schedule the first operation to start earlier than Planning Time Fence Date.
Non-firm manufacturing work orders: If an order, operation, or resource has a start date inside the planning time fence, do not rescheduled in. If the job a start date outside of the planning time fence, only reschedule in up to Planning Time Fence Date.
Firm manufacturing work orders: Never cancel or reschedule. Do not change the completion date or reschedule the operations. Calculate firm work order resource requirements and reduce resource availability by these requirements. Consider the resource loads for firmed jobs prior to scheduling all other supplies.
Firm planned manufacturing orders: Retained based on the value of plan option Overwrite. If None or Overwrite Outside Planning Time Fence, retain the order and consider Order Due Date firm. Consider the completion date firm; reschedule operations as required. The operation rescheduling may cause compression or violate Planning Time Fence Date because the supply is firmed.
In the operation detailed scheduling, the planning engine calculates Earliest Possible Start Date for each operation. This is never earlier than Planning Time Fence Date, but it may be later.
This diagram shows the same manufacturing work orders from topic Manufacturing Work Order Scheduling scheduled in an unconstrained plan:
Jobs 1, 2, and 3: Rescheduled out based on the required demand dates. All of these jobs had job and operation start dates earlier than Planning Time Fence Date, so their operations would never be rescheduled in. Job 1 cannot be scheduled in time to meet its required demand; the planning engine schedules the operations respecting their minimum lead-time and the first operation cannot start prior to the plan run date. The planning engine reschedules Jobs 2 and 3 to meet their demands on time. It schedules all operations to minimize slack between resources except Operation 10 which is scheduled earlier due to a capacity constraint
Job 4: Rescheduled in based on its demand due date. Since the planning engine cannot reschedule Start Date of the first operation earlier than Planning Time Fence Date, it forward schedules from Planning Time Fence Date.
Job 5: Canceled because it has no pegged demand and its start date is outside the planning time fence.
Job 6: Since the work order is firm, the planning engine never cancels it or reschedules its completion date. It does not reschedule the operation start and end dates and loads the resources are based on their requirements on the existing schedule dates.
This diagram shows the effect of Planning Time Fence Date and firming on discrete job scheduling in Constrained - Enforce capacity constraints plans.
Discrete Job Scheduling with Planning Time Fence and Firming, Constrained - Enforce Capacity Constraints Plan
Constrained - Enforce demand due dates plans generally follow the same rules as Constrained - Enforce capacity constraints plans. However, the planning engine may schedule supplies earlier than Planning Time Fence Date to meet the demand. It may also compress operations.
This diagram shows the same manufacturing work orders from topic Manufacturing Work Order Scheduling in Constrained - Enforce Capacity Constraints Plans scheduled in a Constrained - Enforce demand due dates plan. The planning engine schedules all the supplies to meet the due dates of their pegged demands even if it violates the planning time fence:
Job 1: Rescheduled out to meet its demand on time. May overload or compress resources.
Jobs 2 and 3: Rescheduled out to meet their demands on time with no resource overload or compression
Job 4: Rescheduled in to meet its demand on time. Operation 10 rescheduled in earlier than Planning Time Fence Date.
Job 5: Canceled because it has no pegged demand
Job 6: Firm, not rescheduled
This diagram shows the effect of Planning Time Fence Date and firming on discrete job scheduling in Constrained - Enforce capacity constraints plans.
Discrete Job Scheduling with Planning Time Fence and Firming, Constrained - Enforce Demand Due Dates Plan
If you want to maintain the detailed schedule dates from a previous plan or that you have set, you can direct the planning engine to consider operations within the planning time fence as firm.
In constrained plans only, set profile option MSO: Firm Operations/Orders Within Time Fence to Yes at the site level. The planning engine:
Consider operations with Start Date earlier than Planning Time Fence Date as firm
Does not change their schedule dates and loads resources on these schedule dates
Considers work orders with completion dates earlier then Planning Time Fence Date as firmed
Does not reschedule their the job completion dates or cancel them
This diagram shows the same manufacturing work orders from topic Manufacturing Work Order Scheduling scheduled in a Constrained - Enforce capacity constraints plan. The scheduling in Constrained - Enforce demand due dates plans is similar:
Jobs 1 and 2: All operations are earlier than Planning Time Fence Date; do not reschedule. Do not change Order Due Date. Compress the first two operations of Job 1 ad the first three operations of Job 2 to occur on the plan run date because their schedule dates occurred prior to the plan run date.
Job 3: Operations 10, 20, and 30 have Start Date earlier than Planning Time Fence Date (May 9); do not reschedule. Operation 40 starts after Planning Time Fence Date; schedule out based on the required demand date. Reschedule out completion date.
Job 4: All operations have Start Date after Planning Time Fence Date; reschedule them. Reschedule the first operation up to Planning Time Fence Date. In a Constrained - Enforce capacity constraints plan, do not violate the operation start date and forward schedule the job; the job is late for its demand. In a Constrained - Enforce demand due dates plan, schedule the operation prior to Planning Time Fence Date to meet the demand on time.
Job 5: Cancel because all operations scheduled to start after Planning Time Fence Date
Job 6: Firm; do not reschedule job completion date and operation schedule dates
This diagram shows the effect of firm operations and orders on discrete job scheduling in Constrained plans.
Discrete Job Scheduling with Firm Operations and Orders, Constrained Plans
Safety stock is a quantity of stock you plan to remain in inventory to protect against fluctuations in demand (for example, forecast error) and supply (for example, variable supplier lead times and irregular operation yields). Safety stock is sometimes referred to as overplanning, a market hedge, buffer stock, or reserve stock.
Safety stock is an inventory level that needs to be maintained. You satisfy demand, for example, sales orders and forecasts, by consuming inventory. Safety stock is an inventory level that you must maintain; it remains in projected available balance.
Safety stock level can be made up of different types of safety stock levels:
Non-transient safety stock levels are levels that you hold from their point of origination to the end of the planning horizon. They are safety stock levels without ending effectivity dates.
Transient safety stock levels are levels that you hold for only a certain time during the planning horizon. They are safety stock levels with ending effectivity dates. Transient safety stock levels plan for supplies to be completed earlier than the demands that peg to them and plan for the inventory to be held as safety stock. You can also complete supplies earlier than the demands that peg to them using safety lead-time; see Safety Lead-time
This diagram shows a safety stock level and its components for a 15-day planning horizon (PH). It details:
SSL: Safety stock level
T1, T2: Transient safety stock levels
NT1, NT2: Non-transient safety stock levels
D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 | D15 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
SSL | 10 | 10 | 10 | 10 | 10 | 10 | 25 | 25 | 25 | 18 | 18 | 18 | 15 | 15 | 15 |
T1 (D7 > D9) | - | - | - | - | - | - | 10 | 10 | 10 | - | - | - | -- | - | - |
T2 (D10 < D12) | - | - | - | - | - | - | - | - | - | 3 | 3 | 3 | - | - | - |
NT1 (D7 > PH) | - | - | - | - | - | - | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 | 5 |
NT2 (D1 > PH) | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
You can use several ways to specify safety stock levels to the planning engine:
You specify
Oracle Inventory calculates
The planning engine calculates
Oracle Inventory Optimization calculates
If you run optimized plans, see also Implicit Objectives.
You Specify Safety Stock Levels
Navigate to the item attributes (Inventory > Items > Master Items or Inventory > Items > Organization Items > tab General Planning > region Safety Stock > field Method.
Set Method to Non MRP Planned
Navigate to form Enter Item Safety Stocks (Inventory > Planning > Safety Stocks).
Enter Item, Quantity, and Effective Date.
If you specify only one safety stock level for an item, the planning engine considers the safety stock level as non-transient. If you enter more than one safety stock level for an item, the planning engine generally considers the safety stock level as transient. However, if the levels are always increasing, the planning engine considers the safety stock levels as non-transient. If there is no safety stock level for an item, the planning engine considers the safety stock level as zero.
See Entering and Reloading Safety Stocks, Oracle Inventory User's Guide.
Oracle Inventory Calculates Safety Stock Levels
Navigate to the item attributes (Inventory > Items > Master Items or Inventory > Items > Organization Items > tab General Planning > region Safety Stock > field Method.
Set Method to Non MRP Planned
Use one of these Oracle Inventory methods for calculating safety stock:
Mean absolute deviation (MAD): The formula is safety stock = Z * 1.25 * MAD, where Z is a function of the desired service level, which you enter.
User-defined percentage
User-defined percentage: The formula is the percentage you enter times the average monthly demand.
See Entering and Reloading Safety Stocks, Oracle Inventory User's Guide.
The Planning Engine Calculates Safety Stock Levels
Navigate to the item attributes (Inventory > Items > Master Items or Inventory > Items > Organization Items) > tab General Planning > region Safety Stock.
Set field Method to MRP Planned %
Specify Bucket Days as the number of days to be used for aggregating demand
Specify Percent as the percentage of aggregated demand to be used for safety stock.
If either Bucket Days or Percent are zero, the planning engine calculates the safety stock as zero.
The planning engine calculates safety stock level for all for working days in the planning horizon during the planning process. The level is a target to be satisfied by the end of the day. You can control it with profile option MSO: Default Timestamp Safety Stocks.
For each day, the planning engine multiplies the safety stock percentage you define by the sum of gross requirements for the safety stock days. For repetitively manufactured items in unconstrained plans only, the planning process multiplies the percentage you define by the average daily demand during each repetitive planning period.
The formula for discrete safety stock is (Sum of gross requirements for Bucket Days working days * Percent) / (100 * Bucket Days).
The organization manufacturing calender determines the working days.
The gross requirements includes both independent and dependent demands. For independent demands, the planning engine uses the demand date. For dependent demands, it uses the unconstrained demand date. In constrained and optimized plans, the scheduling process occurs after the safety stock calculation; the planning engine does not recalculate safety stock even if the scheduling process changes dates.
If the demand is in weekly buckets, the planning evenly divides the weekly demand over the days.
For example, an item has these item attributes:
Safety stock method: MRP Planned %
Bucket Days: 5
Percent: 500% = 5
Days D6 & D7 are non-workdays.
This table shows the demands for days D1 through D9 and the safety stock level for days D1 and D2. The planning engine does calculate safety stock levels for the other work days.
D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | |
---|---|---|---|---|---|---|---|---|---|
Demand (independent and dependent) | 10 | 20 | 15 | 35 | 25 | - | - | 5 | 35 |
Safety stock level | 105 [(10+20+15+35+25) * 500] / (100 *5)] | 100 [(20+15+35+25+5) * 500] / (100 *5)] | - | - | - | - | - | - | - |
Oracle Inventory Optimization Calculates Safety Stock Levels
Navigate to the item attributes (Inventory > Items > Master Items or Inventory > Items > Organization Items > tab General Planning > region Safety Stock.
Set field Method to MRP Planned %. You may leave Bucket Days and Percent blank. Oracle Inventory Optimization calculates safety stock level only for items with item attribute Method set to MRP Planned %.
Use Oracle Inventory Optimization to calculate safety stock levels that account for variability in demand and lead times. See Oracle Inventory Optimization Implementation and User's Guide.
The planning engine receives information for each item-organization combination. The levels are timed with the inventory optimization plan's time buckets.
If there is a planned item that is not in the inventory optimization plan and item attribute Method is set to:
MRP Planned %: The planning engine calculates safety stock level for the item
Non MRP Planned: The planning engine receives safety stock level for the item from Oracle Inventory.
When receiving safety stock information from Oracle Inventory Optimization, the planning engine:
Does not process safety stock demands that occur after the plan horizon date
Sets safety stock demand for the last bucket to be the same as the safety stock demand in the second to the last bucket
In weekly and period buckets, moves safety stock demands that occur on a non-workday to the previous workday
Enabling Safety Stock Planning
Navigate to form Plan Options (Supply Chain Planning > Supply Chain Plan > Options). In tab Organizations:
In region Organizations, select field Plan Safety Stock for the organizations that you want. You can default this setting in the Plan Parameters form (Supply Chain Planning > Setup > Parameters > Execution Defaults).
Only if you set safety stock levels by an Oracle Inventory Optimization plan, in region Demand Schedules > field Name, select the inventory optimization plan with the safety stock levels that you want the planning engine to use.
Planning Phases for Safety Stock
The planning engine plans to meet safety stock levels through a process of sequential phases:
Safety stock smoothing: Smooths out fluctuations in safety stock. This phase is optional. The planning engine only performs safety stock pegging if profile option MSC: Use FIFO Pegging is No.
Inventory netting: Creates planned orders and recommendations to meet safety stock levels
Pegging: Associates supplies and demands
Scheduling: Detailed schedules supplies
This topic explains phases Safety stock smoothing, Inventory netting, and Scheduling. To understand the Pegging phase, see Safety Stock Pegging.
Safety Stock Smoothing Planning Phase
Consider this phase especially if you have the planning engine calculate safety stock levels. The planning engine bases safety stock levels on demand levels; as demand levels fluctuate, safety stock levels fluctuate. This phase help smooth out nervous safety stock levels.
There are the types of safety stock smoothing:
Within time intervals:
Across time intervals:
Safety Stock Smoothing Planning Phase: Within Time Intervals
You can instruct the planing engine to keep safety stock levels relatively constant within a time interval.
You specify:
The number of days in the time interval: Set profile option MSC: Safety stock change interval (Days)
The method that the planning engine should use to calculate the constant value: Set profile option MSC: Smoothing method to calculate Safety stock within Change interval
The planning engine begins at the plan start date and:
Groups the days in to the time interval based on the number of days you specify
Finds the value among the days that corresponds to the method--minimum, maximum, or average
Sets the safety stock level for all the days in the time interval to that value
This table shows the daily safety stock levels. It then shows the smoothed safety stock levels that the planning engine calculates for the value of profile option MSC: Smoothing method to calculate Safety stock within Change interval with profile option MSC: Safety stock change interval (Days) set to 3. Levels are rounded to integers.
D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13 | D14 | D15 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Daily | 11 | 14 | 25 | 5 | 5 | 15 | 35 | 45 | 25 | 12 | 45 | 23 | 5 | 10 | 15 |
Min | 11 | 11 | 11 | 5 | 5 | 5 | 25 | 25 | 25 | 12 | 12 | 12 | 5 | 5 | 5 |
Avg | 17 | 17 | 17 | 8 | 8 | 8 | 35 | 35 | 35 | 27 | 27 | 27 | 10 | 10 | 10 |
Max | 25 | 25 | 25 | 15 | 15 | 15 | 45 | 45 | 45 | 45 | 45 | 45 | 15 | 15 | 15 |
Safety Stock Smoothing Planning Phase: Across Time Intervals
You can instruct the planning engine to minimize safety stock levels across the smoothed time intervals.
You specify:
Whether you want the planning engine to do this smoothing only for MRP Planned % items or for all items. Set profile option MSC: Apply Safety Stock Change interval to non MRP Planned Safety Stock.
The maximum change in safety stock values that you will allow between time intervals. Set profile option MSC: Maximum Percentage variation in safety stock values.
The minimum change in safety stock values that you consider significant enough to trigger a change in the safety stock level from one bucket to the next. Set profile option MSC: Minimum Percentage variation in safety stock values.
The planning engine finds the highest safety stock level within the planning horizon and begins the smoothing process from that time interval. It proceeds backwards to the plan start date and smooths each time interval, then proceeds forward to the end of the planning horizon and smooths each time interval.
The planning engine calculates the change between time intervals as [100 * (Safety stock level in the next interval - Safety stock level in this interval)] / Safety stock level in this interval.
If the deviation between the two time intervals is:
Between the minimum and maximum changes in safety stock levels that you will allow, the planning engine leaves the original safety stock level
Higher than the maximum changes in safety stock levels that you will allow, the planning engine adjusts the original safety stock level to be at the maximum percent.
Lower than the minimum changes in safety stock levels that you consider significant, the planning engine retains the safety stock level for the two buckets.
In this table:
The value you enter for profile option MSC: Smoothing method to calculate Safety stock within Change interval is Minimum.
You set profile option MSC: Maximum Percentage variation in safety stock values to 55. This is the maximum deviation that is considered significant to trigger a change in safety stock between two periods.
You set profile option MSC: Minimum Percentage variation in safety stock values to 10. This is the minimum allowed deviation between any two periods.
The planning engine finds the highest smoothed safety stock level in the planing horizon to be D7-9. It begins from there and smooths across time intervals by calculating deviations in the order D7-9 to D4-6, then D4-6 to D1-3, then D7-9 to D10-12, and then D10-12 to D13-15.
D1-3 | D4-6 | D7-9 | D10-12 | D13-15 | |
---|---|---|---|---|---|
Smoothed Minimum safety stock level within time intervals | 11 | 5 | 25 | 12 | 5 |
Maximum allowed deviation | +/- 55% | +/- 55% | Base | +/- 55% | +/- 55% |
Minimum allowed deviation | +/- 10% | +/- 10% | Base | +/- 10% | +/- 10% |
Order of smoothing calculations | 2 | 1 | Base | 3 | 4 |
Actual deviation | +46.6% [100*(16.13-11)/11] |
+400% [100*(25- 5)/5] |
Base | -52% [100*(12-25)/25] |
-58% [100*(5-12)/12] |
Decision | Actual deviation within minimum / maximum range; retain value | Actual deviation outside of maximum allowed; cap safety stock level at 55% of base level | Base | Actual deviation within minimum / maximum range; retain value | Actual deviation outside of maximum allowed; cap safety stock level at 55% of previous level |
Smoothed safety stock level across time intervals | 11 | 16 [25 / (1+0.55) = 16.13] |
25 | 12 | 5 [12*(1 - 0.55)] = 5.4] |
Inventory Netting Planning Phase for Safety Stock
When there is a safety stock level for an item, the netting process checks for a shortage using this formula: Projected available balance from last period + Supplies in this period - Independent and dependent demand in this period - Safety stock level in this period.
After the planning engine resolves the shortage through planned orders, future firm planned orders, and recommendations, the projected available balance should be the safety stock level. However, the projected available balance may be affected by order modifiers and constraints.
Pegging Planning Phase for Safety Stock
To understand the Pegging phase, see Safety Stock Pegging.
Scheduling Planning Phase for Safety Stock
The planning engine uses the safety stock pegging information to schedule supplies. It schedules supplies so that they meet both demands and safety stock levels as appropriate.
Other Safety Stock Planning Principles
The planning engine uses unconstrained demand dates in the inventory netting and pegging phases. The scheduling phase may move supplies in and out and that could result in your holding too much or too little safety stock.
The planning engine uses unconstrained demand dates when it calculates safety stock level. Therefore, it could sometimes be difficult to tie safety stock level to the MRP Planned % values. The dependent demands used in the initial calculation of safety stock level may have moved by the scheduling process.
These profile options also relate to safety stock:
MSC: Excess and Safety Stock by Demand Class, see MSC Profile Options
MSO: Default Timestamp Safety Stock, see MSD Profile Options
Viewing Safety Stock Results
To see the results of safety stock planning, see Horizontal Plan, Supply/Demand Window, and Pegging.
Oracle Advanced Supply Chain Planning plans a variety of supply chain activities like manufacturing, inter facility shipments, purchases, and shipment to customers. Each of these activities is controlled by a set of calendars. Manufacturing, supplier, and customer facilities may be able to ship or receive goods on specific days. Oracle Advanced Supply Chain Planning plans each type of supply or demand considering the working and non working days in the appropriate set of calendars.
The planning engine considers the following calendars while planning and scheduling:
Org/Supplier shipping calendar
Org/Customer receiving calendar
Carrier calendar
Supplier capacity calendar
Manufacturing Calendar
It does not consider account-level customer calendars.
The planning engine generates specific exceptions when the dates in the calendar cause a delay in meeting a customer order or, when the dates are violated.
The shipping calendar indicates the valid working days for shipment activities originating from suppliers and organizations. The planning engine does not recommend a shipment out from those facilities if the date is a non-working day. The planning engine adjusts the shipment date if the current shipment date is a non-working day. For example, an inter organization shipment that originates at a certain organization may be able to start only between 9 a.m. and 5 p.m. on Monday through Friday. The planning engine considers the working days and times when generating recommended transfers as part of the planning process.
Shipping calendars also need to be variable by the combination of carrier and the service level. For example, a carrier company may only pick up parcels between Monday and Friday. However, another carrier company may also have a Saturday pickup. In addition, any carrier or service level shipping calendars override the default shipping calendar for the organization or a supplier.
The planning engine uses:
Processing lead time to calculate the dock date during the planning and scheduling process
Shipping calendars to calculate valid ship date (dock date - intransit lead time) after the planning and scheduling process completes
In some cases, the planning engine may not find a valid ship date for a buy order, for example, if:
You have an item with processing lead time that is less than the intransit time from supplier to organization
Your shipping calendar has many non-workdays
In these cases, the planning engine uses today's date (the plan run date) as the ship date. If today is a non-workday on the shipping calendar, the planning engine issues exception message Order violates a business calendar.
The receiving calendar governs the receiving activities at the organizations or customer sites that receive goods. The planning engine allows organizations to receive shipments only on a working day. If the current shipment arrival date is a non-working day according to the receiving calendar, the planning engine defers the receipt of the shipment until the next (or previous) working day. For example, the dock doors of a distribution center that receives truckload shipments from a manufacturing facility may be open between 12 noon and 5 p.m. on a daily basis. When generating planned transfers between these two facilities, the planning engine assigns dock dates on these planned transfers based on the receiving calendar of the organization.
Receiving calendars can also vary by combination of carrier and service level. You need to specify valid receiving calendars for organizations and customers at the carrier and service levels.
The carrier calendar indicates the working and non-working days and times for material that is intransit using different means of transport. For example, certain methods of shipment such as parcel carriers may not work on weekends. This may cause the transit time to be stretched over the weekends. The planning engine needs to consider these non-working times of various transportation modes that are modeled in the supply chain. Consider a carrier that has a regular transit time of 3 days. However, this carrier does not pick, deliver or operate during weekends. This implies that while a shipment that starts on a Monday morning can arrive on a Thursday morning, a shipment that starts on a Friday morning cannot arrive on a Monday morning. It can only arrive on a Wednesday morning because the carrier does not operate on Saturday and Sunday.
Note: The carrier calendar indicates the operating calendar of the carrier or the service. It does not indicate the pickup or delivery dates of the carrier.
The supplier capacity calendar governs how supplier capacity is accumulated over a period of time. Supplier capacity is only accumulated on the working days according to the supplier capacity calendar. The supplier capacity calendar also governs how the supplier processing time is calculated.
You may or may not define all the calendars available. Therefore, depending on the calendars that you define, the valid calendar for scheduling dates could change. Refer the following table for the hierarchy that the planning engine uses for determining valid calendars:
Calendar Name | Option 1 | Option 2 | Option 3 | Option 4 | Option 5 |
---|---|---|---|---|---|
Supplier capacity calendar | Supplier/supplier site capacity calendar | 24x7 calendar | - | - | - |
Supplier shipping calendar | Carrier/supplier/supplier site calendar | Supplier/Supplier Site Shipping Calendar | Carrier/Supplier Calendar | Supplier Shipping Calendar | 24x7 calendar |
Organization Receiving Calendar | Carrier/Org Calendar | Organization Receiving Calendar | Organization Manufacturing Calendar | - | - |
Organization Manufacturing Calendar | Organization Manufacturing Calendar | - | - | - | - |
Organization Shipping Calendar | Carrier / Org Calendar | Organization Shipping Calendar | Org Manufacturing Calendar | - | - |
Customer Receiving Calendar | Carrier/Customer/Customer Site Calendar | Customer/Customer Site Receiving Calendar | Carrier/Customer Calendar | Customer Receiving Calendar | 24x7 calendar |
Intransit Calendar | Carrier Intransit Calendar | 24x7 calendar | - | - | - |
Note: An organization manufacturing calendar always exists for an organization.
The planning engine first checks option 1 for each calendar. In case, option 1 is not defined in your setup, then it checks the next option available. For example, when the planning engine needs to take into account a supplier shipping calendar, it checks for a supplier / supplier site / carrier shipping calendar. If not specified, the planning engine looks for a supplier / supplier site shipping calendar. If not specified, it looks for a supplier / carrier calendar. If not specified, then it looks for a supplier shipping calendar and if that does not exist, it then defaults to a 24x7 calendar.
If you want any organization shipping and receiving calendars to be 24x7, then you need to define the specific calendar as 24x7 if the organization manufacturing calendar is not 24x7.
In case of receiving calendars, the planning engine checks customer receiving calendars set up at the customer level. Customer receiving calendars set up at the account level are not supported.
If you do not want to use any shipping, receiving, or, carrier calendar for planning/scheduling, set the profile MSC: Use Shipping/Receiving Calendars to No. When you set this profile to No, the planning engine uses only the organization manufacturing calendar while generating a plan. Irrespective of the setting of this profile, the planning engine takes into account the supplier capacity calendar to accumulate supplier capacity. If the supplier capacity calendar is not specified, the planning engine uses the 24x7 calendar. If you want to accumulate supplier capacity based on the organization manufacturing calendar, you need to set your supplier capacity calendar to be the same as the organization manufacturing calendar.
Oracle Advanced Supply Chain Planning plans orders depending on the type of order as well as the type of date on the order. The planning engine checks the working and non working days on specific calendars after taking into consideration the lead-time for each type of order.
Lead-time offsetting begins only on a workday of the workday calendar.
Refer the following figure for the calendars and lead-times that the planning engine takes into account while processing make orders.
The processing time for make orders is calculated as follows:
Routing specified: Manufacturing duration based on resource usages in the routing
Routings not specified: Fixed + variable lead-time
In unconstrained plans, the value of fixed + variable lead-time is used regardless of whether routings are specified or not.
Refer the following figure for the calendars and lead-times that the planning engine takes into account while processing buy orders.
The processing time for buy orders is calculated as follows:
Supplier defined: Supplier processing lead-time (assumed to include transit lead-time)
Supplier not defined: Item processing lead-time
The planning engine calculates the transit lead-time as follows:
Planned order: The ship method on the sourcing rule that the planning engine selects
Purchase order: The default ship method between the supplier and the receiving organization
Refer to the following figure for the calendars and lead-times that the planning engine takes into account while processing transfer orders.
In case of transfer orders for constrained plans:
Ship Date = Start Date
The intransit lead-time between the organizations is specific to the carrier used.
Refer to the following figure for the calendars and lead-times that the planning engine takes into account while processing sales orders and forecasts.
The intransit lead-time is specific to the carrier used and the location of the customer site.
Oracle Advances Supply Chain Planning optionally uses the specified shift timings on the shipping, receiving, and carrier calendars for calculating lead-times. When the profile MSO: Use Shift Definitions When Scheduling Lead Times is set to Yes, the planning engine counts only the working time within the shifts. This is applicable only to constrained plans.
This means that if each working day defined in a calendar has only one active shift with 8 hours of working time, a lead-time of 1 day (24 working hours) takes 3 working days, since each working day only offers 8 hours of working time. Also, with this profile option set to Yes, each date on the order lies within a valid shift timing defined as part of the calendar. For example, if the shift timing is from 8 a.m. to 4 p.m., then any date on the order will have a time stamp between 8 a.m. and 4 p.m.
Select Order Management > Shipping > Setup > Calendars > Enter.
The Workday Calendar window appears.
Select Order Management > Shipping > Setup > Calendars > Assign.
The Assign Calendars window appears.
Define the calendar that you need to use.
For more details on setting up the calendars, see Oracle Shipping User Guide.
Run collections.
For more details on collections, see Running Collections.
The planning engine collects the following data:
The shipping, receiving, and carrier calendar association with their respective trading partners (including the carrier or the shipment method) into the destination tables.
The supplier calendar associated with the Approved Suppliers List (ASL).
Manufacturing calendars associated to the organizations.
Run a plan.
The start date, ship date, arrival dates, order date etc. are associated with the respective shipping, receiving, and carrier calendars instead of the organization's manufacturing calendar.
View the calendar from the Planner Workbench.
Collect the calendar data using the following control files
msc_st_calendars.ctl
msc_st_workday_patterns.ctl
msc_st_calendar_exceptions.ctl
msc_st_shift_exceptions
msc_st_shift_times
Collect the calendar associations using the following control files:
msc_st_item_suppliers.ctl
msc_st_trading_partners.ctl
msc_st_calendar_assignments.ctl
Run the Legacy Collections concurrent program.
For more details on Legacy Collections, see Legacy Collection.
Run a plan.
The start date, ship date, arrival dates, order date etc. are associated with the respective shipping, receiving, and intransit calendars rather than with the organization's manufacturing calendar.
View the calendar from the Planner Workbench.
You can use the Calendar window to view the valid working days and shift timings on the various calendars used by the planning engine.
Open the Planner Workbench or Collections Workbench.
Select Tools > Work Dates.
The Calendar window appears.
You can also view calendar data from the following windows:
Supply/Demand window: For more details, see Supply/Demand Window.
Pegging region of the Supply/Demand window: For more details see Right-click Menu Options in the Pegging Region of the Supply/Demand Window.
Exceptions Details window: For more details, see Exception Details Window.
You can view the calendar data for the following exceptions:
Late Replenishment for Sales Order
Late Replenishment for Forecast
Early Replenishment for Sales Order
Early Replenishment for Forecast
Overcommitment for Sales Order
Order Violates a Business Calendar
For more details about the exceptions listed above, see Exception Messages. Only those calendars that are relevant to the exception message are enabled in the popup menu.
To view calendar data from exceptions:
In the Exceptions Details window, select one of the exceptions listed above.
Right-click and select the Calendar option from the pop-up menu.
Scheduled receipts are open orders with assigned due dates. This topic explains scheduled receipts as they relate to planning.
When you use non-standard discrete jobs to model rework, the item is both the assembly and a component of the discrete job. Use one of the following processes to create and process the discrete job:
Store and record the item in a nettable subinventory. In the non-standard discrete job, set MRP Net Qty to the expected yield of the non-standard job. Immediately issue the component material from the nettable subinventory to the to the discrete job. Complete the finished assemblies to a nettable subinventory.
Store and record the item in a non-nettable subinventory. In the non-standard discrete job, set MRP Net Qty to the expected yield of the non-standard job and clear the component Net MRP. Complete the finished assemblies to a nettable subinventory.
For successful planning when you have non-standard discrete jobs for rework, if you provide a value for the job MRP Net Qty, then clear the component Net MRP.
You can instruct the planning engine to use all non-firm purchase orders of components in the substitution chain before creating a planned order for a primary component. It uses the purchase orders in first-in, first-out sequence.
The planning engine:
Generally fulfills all possible demands in a day with a purchase order before moving to the demands on the next day.
Uses purchase orders in order of purchase order availability. It uses component substitution priority to prioritize multiple purchase orders for the same item on the same day
Does not reserve supply to meet demands
May create a planned order on one item and cancel purchase orders on another item in order to follow purchase order availability sequence.
This method:
Only applies to purchased items
Only applies in Constrained – Enforce capacity constraint plans
Does not pay attention to order modifiers for scheduled receipts. Oracle recommends no order modifiers on these items.
Does not pay attention to safety stock. Oracle recommends no safety stock on these items.
Works only with single-level bills of material
Does not source across organizations
Bases demand priorities on demand date
This diagram shows an example of the processing.
There are two assemblies, A and AA.
The primary component of:
Assembly A is component B
Assembly AA is component BB
The substitution chain for:
Component B is B1 - B2 - B3
Component BB is B1
In this example:
The supply of item B1 on day 1 for quantity 600 satisfies demands for items B and BB on days 1 and 2.
The supplies of items B2 and B3 on days 2 and 3 satisfy demands for item B on days 3 and 4. These items are not in the substitution chain for item BB.
The supply for item B1 on day 4 partially satisfies the demand for item BB on day 3.
The planning engine uses the purchase order for item BB quantity 400 to satisfy its remaining demand quantity on day 3 and its demand on day 4. It does not use quantity 100 of this purchase order.
The planning engine recommends that you cancel both purchase orders for item B on day 15 and the purchase order for item BB quantity 100 on day 15. In the diagram, they have asterisks after their quantities.
To enable this processing, set these profile options:
MSO: Component offset logic for optimization to 2
MSC: Use Optimization Phase Supply Due Dates for Pegging to Yes
MSO: Schedule PO in FIFO to Yes
MSO: Additional Demand Slices for Shared Supply Rescheduling to -1
MSO: Net All Firm Supplies Before Creating Planned Order to All Supply Types
You can instruct the planning engine to use the on-hand and on order supply of substitute components before using the on-hand, on order, and planned supply of primary components. Use this method if you prefer to buy or produce less of primary components by first using the supply of their substitute components
This method uses supplies in this order to satisfy its demands:
Use on-hand and scheduled receipts of substitute components
Use on-hand and scheduled receipts the of primary component
Recommend planned orders for primary components
Recommend planned orders for substitute components
This method:
Only applies in Constrained (Without Scheduling) planning mode
Only uses on-hand of a substitute component if it is higher than order modifiers Minimum Order Quantity, Fixed Order Quantity, and Fixed Lot Multiplier
May only use part of the on-hand of a substitute component if it is higher than order modifiers but not a multiple of them
It uses substitute priority to decide the substitute component supply to use first. However, the highest priority substitute component supply may not always satisfy the earliest demand. These tables show an example:
This table shows demand for assembly A.
Entity | Day 10 | Day 20 | Day 30 |
---|---|---|---|
Item A Demand | 5 | 5 | 5 |
This table shows the substitute components for assembly A, their substitute priority, and their on-hand.
Substitute Component | Substitute Priority | On-hand |
---|---|---|
B1 | 1 | 10 |
B2 | 2 | 5 |
B3 | 3 | 5 |
In this example, the planning engine does not use the on-hand for substitute component B3; the quantities of substitute components with higher substitute priorities (B1 and B2) are enough to satisfy the demands for assembly A. The planning engine can do any of the following
Use on-hand of substitute component B1 quantity 10 to satisfy the demands for assembly A on day 10 quantity 5 and day 20 quantity 5. Use on-hand of substitute component B2 quantity 5 to satisfy the demand for assembly A on day 30 quantity 5.
Use on-hand of substitute component B2 quantity 5 to satisfy the demand for assembly A on day 10 quantity 5. Use on-hand of substitute component B1 quantity 10 to satisfy the demands for assembly A on day 20 quantity 5 and day 30 quantity 5.
Use on-hand of substitute component B1 quantity 10 to satisfy the demands for assembly A on day 10 quantity 5 and day 30 quantity 5. Use on-hand of substitute component B2 quantity 5 to satisfy the demand for assembly A on day 20 quantity 5.
This diagram shows an example of the processing if you use this method.
There is an assembly A with order modifier Minimum Order Quantity of 500.
The primary component of assembly A is component B
The substitution chain for component B is C.
In this example:
Assembly A has demands of quantity 500, quantity 250 on day 5 and quantity 250 on day 10.
The planning engine recommends a planned order against assembly A of quantity 500 on day 5 to satisfy both demands.
Because of the planned order for assembly A on day 5, the planning engine creates planned order demand for quantity 500 against substitute component C.
The on-hand for component C of quantity 500 satisfies the planned order demand for substitute component C on day 5.
To enable this processing, set these profile options:
MSO: Use up existing supply of primary components before substitute to No; This setting states your preference to use substitute supplies before primary supplies. However, if there is no on hand or scheduled receipts for the substitute components or the primary component, the planning engine creates planned orders for the primary component first, then the substitute components
MSO: Use Existing Supplies in Alternate BOM/Subs. Comp to 0 or 1 (do not use 2 or 3): This setting states your preference for whether or not the planning engine uses alternate bill of material component supplies.
MSO: Postpone Use of Alternates to Latest Possible Time to No: This setting states your preference that the planning engine should not delay planning alternate supplies until the last possible moment.
MSO: Cost Roll-up incremental factor to 1
This diagram shows an example of the processing if you do not use this method.
In this example
Because of the planned order for assembly A on day 5, the planning engine creates planned order demand for quantity 250 on primary component B and creates planned order demand for quantity 250 on substitute component C.
The on-hand for primary component B of quantity 250 satisfies the planned order demand for primary component B on day 5.
Quantity 250 of the on-hand for substitute component C of quantity 500 satisfies the planned order demand for substitute component C on day 5.
Batch operations can process multiple items simultaneously. Typical examples of batch operations are heat treatment, sand blasting, electroplating, specialized drying, and gamma ray treatment to kill bacteria.
Work scheduled via batch processing is characterized by the same work performed on multiple items simultaneously for a preset amount of time. Some of the other characteristics of batch processing are similarities in processing, capacity available to hold the items, and minimum batch size considerations.
The critical issues for scheduling batch operations are:
Grouping items for scheduling
Constraining resources along multiple dimensions
Honoring minimum and maximum batch sizes
Delaying or prebuilding to make up a batch
The following steps show the basic business process flow for scheduling batch operations:
Group orders for an item or across items for batch operations.
Evaluate batch resources availability along multiple dimensions.
Determine minimum and maximum batch sizes.
Determine delaying and/or prebuilding criteria for batching.
Oracle ASCP allows you to specify a resource as a batch type resource at the department resource level. A batch type resource is consumed only on a Lot basis. Oracle ASCP batches several orders for an item or across items when scheduling batch resources. Oracle ASCP batches operation sequences that carry the same batchable resource and schedules them as a batch. The criteria for batching depends on the following factors:
Sharing same standard operation code
Same usage on the routing
If you do not assign a standard operation code to an operation sequence that uses a batchable resource, Oracle ASCP only batches orders with matching durations.
If the maximum capacity is exceeded, the planning engine pushes out batchable resources to the first unconstrained bucket.
Sign on using the Manufacturing and Distribution Manager responsibility.
From the Navigator, select Bills of Materials > Routings > Resources.
The Resources form appears.
To specify a resource as a batch type resource at the department resource level, select Batchable.
Enter Minimum Batch Capacity and Maximum Batch Capacity quantities and their Batch Capacity UOM.
The minimum batch size is implemented as a non-enforced constraint. The maximum batch size is an enforced constraint; the planning engine continues to batch orders until it meets the maximum batch size or exceeds the batching window.
Verify that there is a unit of measure conversion factor between the routing assembly primary unit of measure and the resource Batch Capacity UOM.
Enter Batching Window and its UOM
Specify the window size in days. If the planning engine does not find enough order quantity within the batching window to at least meet Minimum Batch Capacity, it:
Starts a batch with less than the minimum quantity
Issues an exception message
Enter Batching Penalty.
Oracle Advanced Supply Chain Planning calculates the capacity of the batchable resource as
(Specified Batch Capacity in Resource Screen) * (Number of Resource Units specified in Department/Resources Screen)
When releasing a planned order, Oracle Advanced Supply Chain Planning always sets the assigned units on a batchable resource requirement to 1. To prevent data inconsistencies, make sure that the planned order quantities do not require more than one assigned unit's worth of capacity. Use order modifier Maximum Order Quantity against the routing assembly.
You can specify a window to batch orders and specify the window size at the department resource level. If the system does not find orders in the batching window which is equal to or more than the minimum batch quantity, it starts a batch with less than minimum quantity. In this case, an exception message is generated.
Specify the batching window value on the source system in days to match the way that the collections process considers it.
If the planning engine appears to schedule large gaps between resources and you want to reduce them, Oracle recommends that you lower the batching window size.
You can specify minimum and maximum batch quantities for batch type resources. The minimum batch size is implemented as a soft constraint. The maximum batch size is a hard constraint. Oracle ASCP continues to batch orders until the maximum batch size is met or until the Batching window is exceeded.
You can specify a unit of measure (volume or weight) at the resource level that is appropriate to your resource. In addition to the resource availability (time dimension), Oracle ASCP allows you to constrain a resource in one other dimension (batching dimensions are time, volume, and weight).
The batching activity is constrained by the maximum capacity set for a resource.
In order to define routings including batchable resources, you must have a unit of measure conversion factor between the item's primary unit of measure and its batchable unit of measure.
Example: Batching orders for 2 items
The following table presents order quantities for two items, A and B, sharing the same batchable resource:
Item | Day 1 Qty. | Day 2 Qty. | Day 3 Qty. | Day 4 Qty. | Day 5 Qty. | Day 6 Qty. | Day 7 Qty. | Day 8 Qty. | Day 9 Qty. | Day 10 Qty. |
---|---|---|---|---|---|---|---|---|---|---|
Item A | 0 | 0 | 0 | 2 | 0 | 0 | 0 | 3 | 0 | 4 |
Item B | 0 | 2 | 0 | 0 | 3 | 0 | 0 | 0 | 2 | 0 |
Batching Window = 3
Maximum Capacity = 6
Considering the batching window and the maximum capacity of the resource, the first batch is processed on day 2 for the total quantity of 4:
First Batch on Day 2 = 2 + 2 = 4
Because there is a maximum capacity of 6, the 3 units on day 5 is not included in the first batch.
Second Batch on Day 5 = 3 + 3 = 6
Example: Required Hours and Required Capacity
Order Qty: 2500
Weight requirement: 15 pounds/item
Batch process time: 14 hours
Routing assigned units: 2
If the order is firm order, if it pegs to a firm order, or if the plan is Constrained - Enforce demand due dates, the resources are overloaded.
The resources consume 8 assigned units instead of 2 units (max), then:
Required hours: 112
Required capacity: 525,000 resource hours per batch (2500 units * 15 pounds/unit * 14 hours)
You can perform the following tasks only on the Planning Server:
Create instances
Define plan names and its options
Create priority rules
You can perform the following tasks on the source or Planning Server:
Add new sourcing rules
Add new assignment sets
Add new bill of distribution
Change the order priority for any independent demand
Add/change supplier capacity and flex fences
Change plan parameters