This chapter covers the following topics:
ATP Inquiry is typically performed through an application that can place orders or quotes. This type of application makes a call to Oracle Global Order Promising with information such as item, request date, quantity, or shipping warehouse. Oracle Global Order Promising returns availability information such as quantity available on request date or earliest available date (if the request cannot be met on the request date). Then, the application determines what specific information to display to the end user.
Oracle Global Order Promising has its own user interface to allow users to perform availability checks. Using this interface, you can obtain the detailed information returned by Oracle Global Order Promising. This section explains this user interface.
The following diagram illustrates the information flow through the Oracle Global Order Promising windows:
The Selection of Windows
Each window is explained in detail in the sections that follow.
ATP Criteria lets you enter parameters for the desired ATP check.
Choose ATP. Then select ATP Inquiry.
The ATP Criteria window opens.
ATP Criteria Window
The following table contains the fields and options in the ATP Criteria window:
Note: Not all of these fields are required.
Select ATP Details.
The ATP Details window appears with the ATP details and the pegging tree. The pegging tree shows how the demand is being met.
The ATP Details window has two regions:
Summary region
Pegging region
The summary region is a folder form.
Note: Not all fields are shown by default.
The following table describes each field in this window:
Field | Description |
---|---|
Item | Shows the requested item. |
Quantity | Shows the requested quantity. |
Org | Shows the shipping organization. |
Request Date Qty | Shows the quantity available on the request date. |
Ship Date Qty | Shows the quantity available on the date that the request quantity can be met. The quantity can exceed the requested quantity. |
Arrival Date | Shows the arrival date. Arrival date equals ship date plus transit lead time. |
Request Date | Shows the request date. |
Request Date Type | Shows either Ship Date or Arrival Date, based on the selection. |
UOM | Shows the primary unit of measure of the requested item. |
Group Ship Date | Shows the group ship date for a set, if the request is for a set. |
Group Arrival Date | Shows the group arrival date for a set, if the request is for a set. |
Ship Method | Shows the ship method that is passed from any calling application or default ship method defined for the shipping organization and receiver. |
Shipment Method Description | Shows the description of the ship method. |
Transit Lead Time | Shows the lead time associated with the above ship method. |
Demand Class | Shows the demand class associated with the request. |
Message | Shows any error or warning message. |
Customer | Shows the customer on the request. |
Ship To | Show the ship-to site of the customer. |
Latest Acceptable Date | Shows the date beyond the request date that the ATP request should be considered successful, if the requested quantity can be met. |
Arrival Set | Shows the set identifier passed by any calling application for grouping items in an arrival set. |
Ship Set | Shows the set identifier passed by any calling application for grouping items in an ship set. |
Line | Shows the order line number passed by any calling application for indication of demand line number. |
Plan Name | Shows the ASCP plan name used for Oracle Global Order Promising, if ATP is based on planning output. |
Original Item | Shows the requested item. The item field shows the substituted item. |
Original Item Request Date Qty | Shows the availability of the requested item on the request date. The Request Date Qty field shows the availability of the substituted item on the request date. |
Original Item ATP Date | Shows the earliest date the requested quantity for the requested item is available. |
Original Item ATP Date Qty | Shows the quantity available on the Original Item ATP Date. The available quantity may exceed the requested quantity. |
Status | Not used. |
Days Late | Shows the days between the request date and date the supply is available for the item. |
Matched Configuration | This field is only applicable for an ATO model request. When Oracle Global Order Promising finds a matched configuration, the configuration item is displayed in this field. |
ATP Pegging region further explains how Oracle Global Order Promising obtains the ATP results. Pegging is shown for each line in ATP Details: Summary Region.
Oracle Global Order Promising first checks the availability on the request date. If there is a shortage, then Oracle Global Order Promising finds a date beyond request date when the shortage can be met. The pegging depicts this logic.
For example, a request for item A on Day 10 for quantity of 20 for Org 1. Only a quantity of 5 is available on request date, but the shortage can be met on Day 12.
Pegging shows the following:
Line 1: A - Org 1 Qty 20 On Day 10
Line 2: A - ATP Org 1 Qty 5 On Day 10
Line 3: A - ATP Org 1 Qty 30 on Day 12
Explanation:
The first line represents the demand.
The second line represents the supply available on request date.
The third line represents the earliest date that the remaining demand can be satisfied. The availability on that date is 30.
When Multi-Level Supply Chain ATP is enabled, the pegging shows how Oracle Global Order Promising searches for supply throughout the supply chain.
Pegging Example: Supply Chain Bills of Materials (BOM): Item A can either be made in Org1 or transferred from Org2. Making item A is priority 1, as seen with Make(1). Also, Component X can be supplied from either S1 or S2.
Supply Chain BOM
Other setup:
Item A has a 1 day fixed lead time, and no variable lead time.
Item A has no post-processing lead time.
Component X has a 1 day post-processing lead time, but no pre-processing lead time.
S1 does not have processing lead time.
S2 has a 2 day processing lead time.
Transfer(2) shows the transfer of item A from Org2 to Org1, which takes a 1 day transfer lead time.
Cumulative Availability based on on-hand plus scheduled receipts is depicted in the following:
Note that D1 = today.
Org | D1 | D2 | D3 | D4 | D5 |
---|---|---|---|---|---|
A - Org1 | 0 | 0 | 40 | 80 | 120 |
X - Org1 | 0 | 10 | 10 | 10 | 10 |
Y - Org1 | 0 | 30 | 90 | 0 | 0 |
Z - Org1 | 10 | 50 | 50 | 0 | 0 |
S1 | 10 | 10 | 10 | 10 | 0 |
S2 | 10 | 10 | 10 | 10 | 0 |
A - Org2 | 10 | 50 | 100 | 100 | 0 |
An order for item A with a quantity of 100 on D4 gives the following pegging:
1 (D) A - Org1 Qty 100 on D3
2 (S) A - ATP Org1 Qty 40 on D3
3 (S) A - Make At Org1 Qty 20 on D3
4 (D) X - Org1 Qty 20 on D2
5 (S) X - ATP Org1 Qty 10 on D2
6 (S) X - Buy S1 Qty 0 on D2
7 (D) X - Qty 10 on D1
8 (S) X - ATP Qty 10 on D1
9 (D) Y - Org1 Qty 20 on D2
10 (S) Y - Org1 Qty 30 on D2
11 (D) Z - Org1 Qty 20 on D2
12 (S) Z - Org1 Qty 50 on D2
13 (S) A - Transfer From Org2 Qty 40 on D3
14 (D) A - Org2 Qty 40 on D2
15 (S) A - ATP Org2 Qty 50 on D2
Explanation:
In pegging, different graphical icons are used for supply and demand. In the above representation, the icons are represented by (S) and (D) respectively.
(D) represents the demand line. Demand lines, except the first demand line, indicate the actual demand that can be placed. They do not indicate what is required.
(S) represents the supply line. Supply lines have the following types:
ATP: supply from on-hand and scheduled receipts.
Make At: supply can be obtained from a Make At source.
Transfer From: supply can be obtained from a Transfer From source.
Buy From: supply can be obtained from a Buy From source.
Line 2: on request date (D3), there are 40 available for A. There is a shortage of 60.
Line 3: Oracle Global Order Promising finds components available to make 20 of A. Lines 4 to 12 explain why.
Line 4: to make A on D3, X is needed on D2 because of the lead time offset. However, only 20 of X can be demanded on D2. Lines 5 and 8 explain why.
Line 5: there are 10 of X available in Org1 on D2.
Line 6: 10 units of X can be obtained from supplier S1 on D2. Lines 7 and 8 explain why.
Line 7: X is needed from S1 on D1 due to a 1 day postprocessing lead time of X. Only 10 units of X can be demanded from S1. Line 8 explains why.
Line 8: on D1, there are only 10 of X available from S1. S2 has a Buy From source and a 2 day processing lead time. There is not enough time to meet demand on D1. Since Oracle Global Order Promising does not use S2, there is no pegging shown for S2.
Line 9: only 20 of X is available. Oracle Global Order Promising looks for 20 of Y. More does not help. On D2, 20 of Y can be demanded. Line 10 explains why.
Line 10: there are 30 of Y available on D2. If there are less Y, Oracle Global Order Promising would readjust X to demand less quantity.
Line 13: since there is still shortage of 40, Oracle Global Order Promising looks for supply at the Transfer From source. 40 of A can be transferred from Org2 on D3. Lines 14 and 15 explain why.
Line 14: demand for A is placed in Org2 on D2 due to a 1 day transfer lead time.
Line 15: there are 50 of A available on D2.
For details on ATP Logic, see: ATP Logic.
Select a supply line of the pegging tree.
Right-click to drill down to ATP details.
The available options are:
Expand
Show Late Supply Only
Show Constraints
Horizontal Plan
Supply/Demand
Supply
Demand
Properties
Note: To be able to drill down to ATP detail, you must set the profile MRP: Calculate Supply Demand to Yes before you initiate the ATP Inquiry
However, when the profile MRP: Calculate Supply Demand is set to Yes, Oracle Global Order Promising performs extra work to retrieve and retain the detail. This makes ATP performance slower. You should only set this profile to Yes for analysis purpose.
Right-click and select Expand.
When you select this option, all the lower nodes under the pegging line that you have selected are expanded.
For example, if you highlight a pegging line for a sub-assembly and right-click to select Expand, the pegging tree displays all the detail pegging lines for that sub-assembly.
Select a supply line of the pegging tree.
Right-click and select Show Late Supply Only.
When you select this option, the pegging region displays only those sales order lines that are receiving late supplies.
Right-click and select Supply/Demand.
This window shows supply and demand for the selected line of the pegging tree.
Supply/Demand Window
For an item, all of the supply and demand up to the item's infinite time fence appears in the Supply/Demand window. For a resource, all the supply and demand over the entire ASCP plan horizon appears.
The following table describes each field in this window:
Field | Description |
---|---|
Group Availability Date | This field is currently not populated. |
Organization Code | This field is currently not populated. |
Demand Class | This field is currently not populated. |
Item/Resource | Indicates the item or resource of the pegging line. |
Type | Indicates if it is an item or resource. |
UOM | Shows the primary unit of measure of the item or resource. |
Date | Shows the due date of supply or demand. |
Supply/Demand Type | Shows the supply or demand type. |
Identifier | Shows the identifier of the supply or demand. |
Quantity | Shows the quantity of the supply or demand. |
Right-click and select Horizontal Plan.
The Horizontal ATP window shows material or resource availability in a horizontal time scale. It shows total demand, total supply, net available-to-promise, and cumulative available-to-promise.
For ATP based on collected data: the time horizon equals the item's infinite time fence defined in the ATP rule, or the date of last supply or demand.
For ATP based on planning data: the time horizon equals the item's infinite time fence or the end of the plan horizon (if the infinite time fence is not defined).
Right-click and select Properties.
The Properties window appears.
Properties Window
Depending on whether you are viewing the properties of an item or a resource, the Properties window displays different fields. The Properties window for an item contains two tabs: Main and Other.
The display of values in the various lead time fields depends on the type of item (make/buy) and whether Oracle Global Order Promising uses a specific lead time for computing the order promising dates for the item.
For lot based components, the Other tab of the Properties window for a selected pegged item in the ATP Details window displays the following fields:
Component Yield: Displays the percent of the amount of the selected item present in the assembly.
Usage: The value displayed in this field defines the physical amount of the component used (1 unit, 2 units, etc.)
Scaling Type: Displays either Lot or Item based on the calculation basis of material requirements.
Rounding Direction: Displays the factor that indicates whether the integer quantity of the component must be rounded up or down.
Scale Rounding Variance: Displays the allowed variance (deviation) of the integer quantity from the non-integer quantity, in percentage terms, with the non-integer quantity as the basis. If no rounding variance is specified, it is assumed to be 0%. This means that no deviation is allowed from the proportionally scaled quantity. In such a case, the scale multiple would not impact the requirement of that component.
Scale Multiple: A factor used to convert component requirements to an integer. The value displayed in this field also ensures that components are consumed in multiples of the scaling factor.
In addition, the item quantity displayed in the pegging tree will also be based on the selected basis for material requirements.
Note: The Pegging region of the ATP Details screen also displays both forward ATP and forward CTP pegging information.
For a make item, Oracle Global Order Promising calculates the processing lead time using the following equation:
Processing lead time = fixed lead time + quantity * variable lead time
For a buy item, Oracle Global Order Promising uses the following values:
Preprocessing lead time
Processing lead time
Postprocessing lead time
Therefore, depending on the lead time data required for an item, the lead time fields display data in the Properties window.
When you perform an ATP inquiry, the ATP Details window provides you with the explanation on how the demand is satisfied. When a particular source (make, buy, or transfer) does not have any supply, the pegging region in the ATP Details window will not show the source. If you need to analyze the result and find out the constraint, you can perform an ATP inquiry in the diagnostic mode. In addition to detail views mentioned above, you can:
View all the supply sources on the pegging tree
Filter the pegging tree to show only the constraint nodes
View additional details about the pegging line, such as property, supply/demand, and horizontal plan.
When a source of supply does not have any availability during a capable-to-promise check, a planner might want to diagnose the underlying constraint that leads to a promise date being later than the request date. ATP Detail/Pegging displays the constraints and lets you quickly determine the reasons for not being able to return a promise date that meets the request date.
Log into Oracle Global Order Promising with the Advanced Supply Chain Planner responsibility.
Select an instance: organization.
Select ATP > ATP Inquiry.
The ATP Criteria window appears.
Select Tools > Enable Diagnostic ATP.
Tools Menu Options
Enter your ATP criteria in and click ATP Details.
The ATP Details window appears.
ATP Details Window: Diagnostic ATP Mode
View the constraint(s) in the pegging region.
Select a supply line of the pegging tree.
Right-click and select Show Constraints.
Note: Note: The Show Constraint option is enabled only in the diagnostic ATP mode.
When you select this option, it only expands the paths that contain constraints under the pegging line that you have highlighted. The rest of the nodes in the pegging tree will be abbreviated, represented by (+).
For example:
An order for item A with a quantity of 100 on D4 gives the following pegging:
1 - (D) A - Org1 Qty 100 on D3
2 (S) A - ATP Org1 Qty 40 on D3
3 - (S) A - Make At Org1 Qty 10 on D3
4 - (D) X - Org1 Qty 20 on D2
5 (S) X - ATP Org1 Qty 10 on D2
6 - (S) X - Buy S1 Qty 0 on D2
7 - (D) X - Qty 10 on D1
8 - (S*) X - ATP Qty 0 on D1 (Material Constraint)
9 - (D) Y - Org1 Qty 20 on D2
10 (S) Y - Org1 Qty 30 on D2
11 - (D) Z - Org1 Qty 20 on D2
12 (S) Z - Org1 Qty 50 on D2
13 - (S) A - Transfer From Org2 Qty 50 on D3
14 - (D) A - Org2 Qty 50 on D2
15 (S) A - ATP Org2 Qty 50 on D2
If X is the only constraint, the pegging tree with the Show Constraint option displays the following:
1 - (D) A - Org1 Qty 100 on D3
2 (S) A - ATP Org1 Qty 40 on D3
3 - (S) A - Make At Org1 Qty 10 on D3
4 - (D) X - Org1 Qty 20 on D2
5 (S) X - ATP Org1 Qty 10 on D2
6 - (S) X - Buy S1 Qty 0 on D2
7 - (D) X - Qty 10 on D1
8 - (S*) X - ATP Qty 0 on D1 (Material Constraint)
9 + (D) Y - Org1 Qty 20 on D2
10 + (D) Z - Org1 Qty 20 on D2
11 + (S) A - Transfer From Org2 Qty 50 on D3
ATP checks across the supply chain to perform backward scheduling and shows all the constraints encountered during scheduling of the requested quantity.
If demand is not met by the request date, then ATP does not perform a forward scheduling to project a date on which the demand could be met.
ATP does not project the partial amount that could be available by the request date.
ATP does not provide information about the substitute item that is used in place of the requested item in regular ATP inquiry.
The full requested quantity is placed as demand at each node. However, if that node has additional sources, then the last source for that node opens a planned order supply equal to the demand placed at that node, minus the planned order supplies acquired from other sources.
Note: When you perform Diagnostic ATP, the response is slower than non Diagnostic ATP because Oracle Global Order Promising needs to store all the pegging data during diagnostic ATP.
When you enable the diagnostic mode, each constrained pegging line in the pegging tree is appended with the type of constraint and the earliest due date of the planned order. The types of constraints that you can see on the pegging line are:
For a make item, when Assembly Requirement Date - (preprocessing lead time + fixed lead time + quantity * variable lead time). Today, no supply can be obtained and the supply pegging line will show 0 as the supply quantity. ATP categories this as a manufacturing lead time constraint.
For example:
Assembly A has component B
Fixed lead time = 0
Variable lead time = 0.1 day
The pegging tree for 100 of A on D5 in Org 1 will look like:
(D) - DEMAND A Org 1 Date 5 Qty 100
(S) - ATP A Org 1 Date 5 Qty 0
(S*) - Make A Org 1 Date -1 Qty 0 (Manufacturing Lead time Constraint: Due Date D6)
Explanation:
In pegging, different graphical icons are used for supply and demand. In the above representation, the icons are represented by (S) and (D) respectively.
(D) represents the demand line. Demand lines indicate the actual demand that can be placed. They do not indicate what is required.
(S) represents the supply line. Supply lines have the following types:
ATP: supply from on-hand and scheduled receipts.
Make At: supply can be obtained from a Make At source.
Transfer From: supply can be obtained from a Transfer From source.
Buy From: supply can be obtained from a Buy From source.
(S*) represents the supply line with a constraint.
On the requested date D5, A is not available. Therefore, there is a shortage of 100.
Oracle Global Order Promising finds components available to make 100 of A only on D6, which is one day after the requested date. This is a manufacturing lead time constraint.
For a buy item, when Requirement Date - (postprocessing lead time - preprocessing leave time - (the approved supplier list's processing lead time or item's processing lead time)) Today, no purchase supply can be obtained and the supply pegging line will show 0 supply quantity. ATP categories this as a purchasing lead time constraint.
For example:
Item A is purchased from supplier S1.
A's postprocessing lead time = 2 days
Preprocessing lead time = 1 day
S1's processing lead time = 3 days
The pegging tree for 100 of A on D5 in Org 1 will look like:
(D) - Demand A D5 Qty 100
(S) - ATP A D5 Qty 0
(S*) - Buy A S1 D -1 Qty 0 (Purchasing Lead time Constraint. Due Date: D6)
Explanation:
Org 1 cannot buy any quantity of B from S1 due to the processing lead time of 3 days required for S1, and the preprocessing lead time of 1 day as well as postprocessing lead time of 2 days for Org 1. This is a purchasing lead time constraint.
For a transfer item, when Requirement Date - (postprocessing lead time + transit lead time) < Today, no supply can be transferred and the Transfer From supply pegging line shows 0 as the supply quantity. ATP categorizes this as a transfer lead time constraint.
For example:
Item A is transferred from Org1 to Org2.
A's postprocessing lead time=2 days
The pegging tree for 100 of A on D1 in Org 2 will look like:
(D) - Demand A Org 2 D1 Qty 100
(S) - ATP A Org 2 D1 Qty 0
(S*) - Buy A Org 2 D1 Qty 0 (Transfer lead time constraint. Due Date: D2)
Explanation:
Item A has a postprocessing lead time of 2 days and cannot be transferred on D1 from Org 2. This is a transfer lead time constraint.
When no supply can be created due to a planning time fence constraint, the supply pegging line shows 0 as the supply quantity.
For example:
Assembly A has component B.
Fixed lead time = 0
Variable lead time = 0.1 day
Planning time fence date = D5
The pegging tree for 100 of A on D5 in Org 1 will look like:
(D) - DEMAND A D5 Qty 100
(S) - ATP A D5 Qty 0
(S*) - Make A D5 Qty 0 (PTF Constraint. PTF Due Date: D5)
In this example, the planning time fence due date is more constrained than the manufacturing lead time date. When two constraints are met for a supply line, Oracle Global Order Promising follows two rules to decide the constraint to be displayed on the pegging line:
When the lead time constraint and planning time fence constraint both exist, the pegging line displays the constraint that causes a later due date. If the due date in both the cases are equal, then the planning time fence constraint is displayed.
When a pegging line encounters a lead time or a planning time fence constraint, no further pegging will be available.
ATP marks all the lowest level supply nodes that do not satisfy the demands as material or resource constraints. A lowest level node is a node that does not have any sources to fulfill the residual demand left after consuming the ATP quantity. The nodes that qualify for this category are:
ATP node for supplier
ATP node for resource
ATP node for an item for which ATP Components flag is set to N in a organization
ATP categorizes a supply line as a material or resource constraint depending on the type of constraint met while scheduling for the requested quantity.
Resource constraint:
When there is not enough availability for a resource, ATP categorizes this as a resource constraint.
For example:
Item A needs to be made and transferred from Org 2 to Org 1.
Intransit lead time = 1 day
The pegging tree for 5 of A on D5 in Org 1 will look like:
(D) - Make A Org 2 D4 Qty 5
(D) - Demand R Org 2 D4 Qty 30
(S*) - ATP R Org 2 D4 Qty 20 (Resource Constraint)
Explanation:
On D4, 5 of A needs to be made in Org 2 due to a 1 day intransit lead time.
To make A on D5, R is needed on D4 because of the lead time offset. Demand for 30 of R is placed in Org 2 on D4 due to a 1 day intransit lead time.
On D4, there are only 20 of R available in Org 2. This is a resource constraint.
Material constraint:
When Oracle Global Order Promising looks for supply for an item, it first checks to see if there is existing on-hand supply or scheduled receipts. This is called ATP quantity. If there is not enough supply, it then performs a capable-to-promise check to see if the item is available through a make, transfer or buy sources option. When the ATP quantity is less than the required quantity and there is no other source to obtain the supply, ATP categorizes this as a material constraint.
For example:
Item A needs to be bought by Org 1 from supplier S1.
The pegging tree for 30 of A on D2 in S1 will look like:
(D) - Demand A S1 D2 Qty 30
(S*) - ATP A S1 D2 Qty 5 (Material Constraint)
Explanation:
On D2, demand for 30 of A is placed in S2.
On D2, there are only 5 of A available in S2. This is a material constraint.
Calendar constraint:
If the schedule ship or arrival date falls on a non working day, Oracle Global Order Promising categorizes this as a calendar constraint.
For example:
Org 1 needs item A from supplier S1 on D2. The transit lead time is 1 day and D1 is a non working day for S1.
The pegging tree for 30 of A on D2 in S1 will look like:
(D) - Demand A S1 D2 Qty 30
(S*) - ATP A S1 D2 Qty 5 (Calendar Constraint)
Explanation:
On D2, demand for 30 of A is placed in S2.
D1 is a non working day for S1 and the transit lead time is 1 day. Therefore, Item A cannot arrive at Org 1 on D2. This is a calendar constraint.
When you have Pick Source set to Yes and you have selected Pick Source, the ATP Sources and Global Availability window, as seen below, opens. Selecting Pick Source with the Yes setting triggers Oracle Global Order Promising to use sourcing rules to find all the possible shipping organizations.
ATP Sources and Global Availability Window
The following table describes the fields in this window:
Once you select or deselect the shipping organizations, then you can retrieve the ATP Details to obtain ATP results for each selected shipping organization.
This section discusses the features that help you schedule requests in Oracle Global Order Promising.
Scheduling sales orders for ATP as well as non-ATP items is carried out through Oracle Global Order Promising. Oracle Global Order Promising calculates supply at day level and returns Schedule Ship Date and Schedule Arrival Date with a timestamp of 23:59:00.
Note that ATP does not support time zones. There could be discrepancies in the time stamps of the scheduled ship date when compared to request dates. You can see discrepancies in the scheduled ship date even if you have existing inventory.
The timestamp display of 23:59:00 is applicable to all of the following:
ATP and non-ATP items
Override and non-override mode scheduling
ATP based on planning or ATP based on collection
Single line request and Set request
Requests with or without the latest acceptable date
If ATP is based on planning output, Oracle Global Order Promising creates supply and demand orders with the timestamp of 23:59:00 in the plan. The orders include:
Demand date of sales order
Demand date of planned order demand in the Planners Workbench
Supply date of planned order in the Planners Workbench
Resource requirement date
Note: Oracle Global Order Promising performs the return date calculation by checking the Scheduled Arrival Date against shipping, receiving, and carrier calendars. For details, see: Shipping, Receiving, and Carrier Calendars.
A few examples to illustrate how Oracle Global Order Promising calculates the Schedule Ship Date and Schedule Arrival Date in different scenarios are given in the following sections.
In all the 3 examples, assume that:
The transit lead time is 0.
The receiving calendar is setup as 24x7.
Non-ATP items with past due and non-past due request dates
Scenario Description | ATP Return Date |
---|---|
A single line request for a non-ATP item with a non-past due request date.
|
|
Two lines request for non-ATP items in a ship set with non-past due request dates.
|
For line 1:
For line 2:
For the group:
|
Two lines request for non-ATP items in an arrival set with non-past due request dates.
|
For line 1:
For line 2:
For the group:
|
A single line request for a non-ATP item with a past due request date
|
|
Two lines request for non-ATP items in a ship set with past due request dates
|
For line 1:
For line 2:
For the group:
|
Two lines request for non-ATP items in an arrival set with past due request dates
|
For line 1:
For line 2:
For the group:
|
Note: The Group Ship Date and Group Arrival Date is displayed as the Schedule Ship Date and Schedule Arrival Date for the set on the sales order.
ATP and non-ATP items in the same request but not in a set
Scenario Description | ATP Return Date |
---|---|
Two lines where: Line 1 = Non-ATP item Line 2 = ATP item The ATP item is available in sufficient quantity on the requested date.
|
For line 1:
For line 2:
|
ATP and non-ATP items in the same request and in a set
Scenario Description | ATP Return Date |
---|---|
Two lines in a ship set where: Line 1 = Non-ATP item Line 2 = ATP item The ATP item is available in sufficient quantity on the requested date.
|
For line 1:
For line 2:
For the group:
|
Two lines in an arrival set where: Line 1: Non-ATP item Line 2: ATP able item The ATP item is available in sufficient quantity on the requested date.
|
For line 1:
For line 2:
For the group:
|
The override ATP feature enables you to schedule a sales order on a date earlier than the product available date. You can schedule an order on a date where there is not enough supply or on a non-working day.
A Sales order overcommitment exception will be generated when you override ATP and you can view the exception in the Planner Workbench. In addition to this, you can send workflow notification to concerned users such as planners.
During business transactions, due to exceptional circumstances, you might have to schedule and ship orders for which your supply chain plan does not show availability. For instance, there could be occasions when:
You receive a fresh demand and it is possible to bring the supply in early to meet the demand
You can use the capacity that is allocated to another product's forecast for the requested product
You decide to push out an existing low priority order to accommodate the higher priority order
You need to ship an order on a non-working date.
In such scenarios, you might want to override ATP and make a commitment to your customer. Global Order Promising provides you with the option of allowing authorized users to override ATP.
You need to perform the following setup steps:
Set the profile option OM: Authorize to Override ATP to Yes.
Set the profile option MSC: Enable ATP Workflow. This is optional and can be set if you want to send a notification to any responsibility like Advanced Supply Chain Planner or Distribution Manager.
You can override the ATP on a sales order using the Sales Order window in Oracle Order Management.
For details on how Oracle Order Management performs an ATP override, see Overriding ATP in Oracle Order Management User's Guide.
Using Oracle Order Management, you can override the Schedule Ship Date or Schedule Arrival Date depending on the request date type.
When the Schedule Ship Date is overridden, Oracle Global Order Promising calculates the arrival date by adding the transit lead time to the Schedule Ship Date.
When the Schedule Arrival Date is overridden, Oracle Global Order Promising calculates the ship date by offsetting the transit lead time. If the ship date falls on a non-working day according to the manufacturing calendar of the shipping organization, the ship date is moved to the previous working day.
Once the Schedule Ship Date is determined, Oracle Global Order Promising will perform the same supply consumption calculation assuming the request date is the Scheduled Ship Date. Any shortage beyond the request date may trigger creation of new supply through capable-to-promise process with due date beyond the request date.
Note: You can only override a date and not time. Oracle Global Order Promising will use the end of day timestamp (23:59:00) for any scheduling actions.
Supplies and Demands for A and B are as follows. B is a component of A. A's manufacturing lead time is 1 day.
For item A
Record Type | Item | D1 | D2 | D3 | D4 |
---|---|---|---|---|---|
Supply | A | 0 | 0 | 0 | 0 |
Demand | A | 0 | 0 | 0 | 0 |
For item B
Record Type | Item | D1 | D2 | D3 | D4 |
---|---|---|---|---|---|
Supply | A | 0 | 10 | 10 | 10 |
Demand | A | 0 | 0 | 0 | 0 |
You have a sales order for 10 of A on D2, which cannot be met. Therefore, you perform an override ATP. The supply/demand picture after override ATP is:
For item A
Record Type | Item | D1 | D2 | D3 | D4 |
---|---|---|---|---|---|
Supply | A | 0 | 0 | 10 | 0 |
Demand | A | 0 | 10 | 0 | 0 |
For item B
Record Type | Item | D1 | D2 | D3 | D4 |
---|---|---|---|---|---|
Supply | A | 0 | 10 | 10 | 10 |
Demand | A | 0 | 10 | 0 | 0 |
Explanation: The ATP date when 10 of A can be promised is D3. However, an override ATP has been performed to meet the demand on D2.
Oracle Global Order Promising checks the shipping and receiving calendars that have been assigned to specific organizations, carriers, and customers for scheduling sales orders. Oracle Global Order Promising ensures that the scheduled ship and arrival dates on sales orders as well as the ship dates, dock dates on planned orders during the Capable-To -Promise process fall on valid working days according to the various shipping and receiving calendars.
Shipping calendars indicate when a shipment can start from a source organization or a supplier. Use of the shipping calendar ensures that the shipment is shipped on a valid day according to the shipping calendar of the shipping organization or the supplier.
Receiving calendars indicate when an organization or a customer can receive a shipment into the facility. Use of the receiving calendar ensures that the shipment arrives at the receiving site on a valid day according to the organization or customer's receiving calendar.
Carrier intransit calendars indicate the days when a certain carrier operates for transporting the shipment. Use of the carrier intransit calendar ensures that the shipment is planned for transportation on a valid day according to the carrier calendar. The duration of any shipment that uses the carrier accounts for the transit calendar.
In a supply chain, each entity, such as the supplier, manufacturer, or distribution center, can have constraints or preferences for shipping or receiving goods in or out of its facilities on specific days. For example, a manufacturing facility may be able to ship goods only on certain days of the week.
The support of shipping, receiving, and carrier calendars facilitates the process of scheduling sales orders by checking the days on which each entity can perform the required activity. Therefore, you can provide accurate dates during order promising. This scheduling also helps to reduce the manual intervention required to adjust shipping and receiving dates.
Complete the following steps to use calendars for scheduling ship and arrival dates:
Select Order Management > Shipping > Setup > Calendars > Assign.
The Assign Calendars window appears.
Assign Calendars window
Define the calendar that you want to use.
Run Collection.
Run an ATP-enabled plan if the profile INV: Capable to Promise is set to ATP/CTP Based on Planning Output.
For more details about setting up calendars, see Oracle Shipping User Guide and Oracle Advanced Supply Chain Planning Implementation and User's Guide.
If you do not want to use any calendar for scheduling ship and arrival dates, set the profile MSC: Use Shipping/Receiving Calendars to No. When you set this profile to No, Oracle Global Order Promising performs order promising without checking the schedule dates against a calendar. Therefore, the response time of Oracle Global Order Promising will be faster, resulting in improved ATP performance.
Oracle Global Order Promising verifies the schedule ship date against the shipping organization's calendar. It verifies the schedule arrival date against the carrier transit calendar as well as the customer/site receiving calendar.
If the requested date does not fall on a shipping date, Oracle Global Order Promising moves the request date to a previous shipping date. If goods are available on this date, then it becomes the schedule ship date. If availability is beyond this date but falls on a non-shipping date, then Oracle Global Order Promising uses the next valid shipping date as the schedule ship date beyond the availability date.
For details on calendar constraints, see Diagnostic ATP.
For a sales order with an ATP override, Oracle Global Order Promising leaves the overridden date as it is and checks the other dates against the calendars. For example, if you override the schedule ship date, Oracle Global Order Promising leaves the schedule ship date and checks the transit lead time against the carrier calendar and the schedule arrival date against the customer's receiving calendar.
This example shows how Oracle Global Order Promising uses the shipping, receiving, and carrier calendars.
Assume that the carrier transit time is 4 days.Working days are indicated by w.
This table shows the working and non-working days for the shipping, receiving, and carrier organizations. The letter w represents working days in the table. Non-working days are blank.
Calendar Type | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 |
---|---|---|---|---|---|---|---|---|---|---|
Organization shipping calendar | w | w | w | - | w | w | w | - | w | w |
Carrier calendar | w | w | w | w | - | w | w | - | w | w |
Customer receiving calendar | w | w | - | w | w | w | w | w | - | w |
Note that w represents working days in the above table. The non-working days are left blank.
If you have a sales order with the request ship date on D4, Oracle Global Order Promising calculates the schedule ship date and schedule arrival date as follows:
D4 is a non-working day for the shipping organization. Therefore, the schedule ship date is D3.
The carrier needs 4 days for transporting the items to the customer's site. D5 and D8 are non-working days for the carrier organization. Therefore, the carrier reaches the customer's site on D9.
D9 is a non-working day for the receiving organization. Therefore, the schedule arrival date is D10.