This chapter covers the following topics:
The scheduling feature of Oracle Order Management (OM) enables you to determine when items will be available to promise to a customer, schedule the shipment or arrival of order lines based on this availability, and reserve on-hand inventory to sales order lines. These scheduling activities can be performed on individual order lines or groups of order lines such as ship sets, arrival sets, and configurations.
Oracle Order Management works closely with Oracle Advanced Planning and Scheduling (APS) and Oracle Inventory to provide scheduling functionality. The features are provided in a variety of ways enabling you to tailor your processes to meet your business needs.
The features that are provided under the umbrella term of scheduling are:
Calculating Available-to-Promise (ATP)
Scheduling
Reserving
Unscheduling and unreserving functionality is also provided. This chapter covers how scheduling works in Order Management and how to set up OM, APS and Inventory to achieve your scheduling goals.
In Oracle Order Management if a line requires more than one set of schedule details, such as schedule date or warehouse, the line is split into multiple lines. An order line represents demand and is visible to the planning applications when the VISIBLE_DEMAND_FLAG is set to yes. This flag is set when the line is scheduled.
Scheduling in Order Management includes the ability to:
Schedule at multiple points - either manually or automatically as the line is entered, when the order is booked, or later using a background process.
Determine the best warehouse for an order line using sourcing rules. This includes using ATO models.
Define by customer whether the request date is the requested ship date or requested arrival date.
Automatically set the scheduled ship and arrival dates based on the calculated ATP date.
Define a shipping network and determine the number of days required for delivery based on the transit time.
Automatically reserve on-hand inventory to order lines.
Control, based on order transaction type, the level of scheduling which should occur.
View availability for multiple warehouses at one time.
Group lines into arrival sets which may be shipped from different warehouses on different days but should arrive at the customer site on the same day, or group lines into ship sets which ship on the same day from the same location.
Reserve scheduled lines from multiple orders using the Reserve Orders concurrent program. Optionally, you can use reservations strategies such as Fair Share, Percentage, and Partial. You can choose whether to simulate or commit the reservations. An API Hook is provided for those who want to write an API to tailor reservation logic for a business-specific processes. Reserve Orders can be run either from the concurrent request menu, or from Scheduling Across Orders.
Override Available to Promise (ATP). This feature allows authorized users to override ATP schedule date from the sales order window as needed for exceptions.
Perform scheduling actions on multiple lines across orders.
Scheduling can be updated based on the latest planning output for planned items.
Configured items can be matched at scheduling for planned items.
Flexible scheduling parameters allow users to control the use of Promise Date, the impact of Request Date and Shipping Method on Schedule Date, the behavior of the LAD with manual scheduling, the scheduling of lines when they are added to ship or arrival sets, and whether to allow partial reservations for manual reservations and the reservation time fence.
ATP/Scheduling uses Transportation calendars like Shipping Calendar, In-transit (Carrier) Calendar, and Receiving Calendar to calculate the ship/arrival dates
The ATP window displays the scheduling results for all recent (related to the current order) scheduling actions- successes as well as failures.
Note: In this release with the introduction of the Multi-Org Access Control functionality, you will now be able to perform most scheduling actions on lines across operating units. This can be achieved via the Scheduling Organizer (Schedule Across Orders i.e. SAO ) or by running the Schedule Orders / Reserve Orders concurrent program. across operating units. For additional information please refer to the Oracle Order Management User's Guide.
Understanding the following terms will help you understand how scheduling works in Oracle Order Management.
Actual Arrival Date: The date the order line arrives at the customer site.
Actual Ship Date: The date the order line is shipped. This date is recorded by the ship confirm action.
Arrival Set: A set of order lines which arrive at the same time at the destination.
Available to Promise (ATP): The quantity of current on-hand stock, outstanding receipts and planned production not already committed to sales orders or other sources of demand.
ATP Date: The date that a requested quantity will be available to promise.
Delivery Lead Time: Time, in days, for items to reach the customer once they are shipped.
Demand: Requests which consume inventory such as sales orders. Discrete manufacturing work orders and flow manufacturing schedules place demand for component items, and sales orders place demand for finished goods.
Line Set: A set of lines which can be grouped into a Ship Set or Arrival Set.
Override ATP: An action that allows authorized users to schedule the line even if there is no supply. Overriding ATP requires users to find supply manually.
Promise Date: The date on which you agree you can ship the products to your customer or that your customer will receive the products. This field is for tracking purposes only. It may be defaulted from the schedule ship date or the schedule arrival date.
Request Date: The date the customer requests that the products be either shipped or received.
Reservation: A guaranteed allotment of product to a specific sales order. Once reserved, the product cannot be allocated to any other source of demand. Also known as a hard reservation.
Reservation modes: Choose one of three reservation strategies when using Reserve Orders: Fair Share, Percentage, or Partial.
Reservation Time Fence: Time, in days, before the schedule date, within which a line should be automatically reserved.
Reservation Types: Using Reserve orders, you can choose whether the reservation run should simulate the reservation strategy, or commit the reservations.
Reserve Orders: A concurrent program that attempts to reserve all those order lines specified in the search criteria in a batch process.
Schedule Arrival Date: The date returned by the system on which your customer can receive the products.
Schedule Ship Date: The date returned by the system on which you can ship the products.
Scheduling Across Orders: The ability to perform scheduling actions on lines from multiple orders. With Scheduling Across Orders, users can schedule, unschedule, reserve, unreserve and perform ATP checks on lines across orders.
Scheduling parameters: Scheduling attributes are added to the OM System Parameters
Ship Set: A set of lines which will be shipped together from the same warehouse to the same location.
Sourcing: Selecting the warehouse for the order lines.
Supply: Incoming inventory. Some Oracle transactions that generate supply are purchase orders, discrete manufacturing work orders and flow manufacturing schedules.
Oracle Order Management enables you to advise your customers when items will be available based on current on-hand inventory plus the expected incoming supply and outgoing demand. Calculating ATP requires as input the item, the order quantity, the order quantity unit of measure and the request date. In general the user will enter the item and order quantity on every order line. The request date and order quantity unit of measure may be defaulted or manually entered. ATP may be calculated for a single line, a group of lines, or a complete order. The results for a single line are displayed in a single column in a small window. The results for multi-line ATP are displayed in a table. In both formats, the following information is displayed:
Warehouse: Either the warehouse on the order line or, if the warehouse on the order line was blank, the best warehouse as selected by the sourcing rules.
Request Date Qty: The quantity that is available on the requested date
Available: The order quantity, if ATP was successful. The available quantity, which will be less than the order quantity, if ATP was not successful.
On-hand Qty: The quantity that is currently in the warehouse.
Qty Reservable: The on-hand quantity minus the quantity that is already reserved to other sources of demand.
Request Date: The date on the order line.
Available date: The date that the ordered quantity will be available. It could be the request date if the order quantity is available on the request date, or it might be a future date when the order quantity will be available
Error Message: Any error that occurred in calculating ATP. For example, if the Check ATP flag for the item is not selected then this field will display ATP not applicable.
Substitute Item: If the requested item is not available and the requested quantity for a defined substitute is available, the substitute item will be displayed. An additional tab, showing the availability of the substitute item, is also displayed.displayed for single items. A multi-line window displays availability information for sets and models.
Clicking the Global Availability button located at the bottom of the Availability window opens the ATP window that has the list of warehouses where the item is enabled. You can select the warehouses for which you want to see the availability, and the system will return the availability in all the selected warehouses.
The ATP Details window can also be opened from the Availability window by pressing the ATP Details Button. The ATP Details window displays how the results were derived.
ATP is calculated automatically during scheduling, and may be calculated manually by clicking Availability on the Line Items tab of the Sales Order window. There are several steps required for ATP calculations.
If you are using ASCP, supply/demand is set up at the plan level. See the Oracle ASCP Implementation Manual. Global Order Promising will only use the infinite time fence specified on the ATP rule.
If you are not using ASCP, ATP rules must be defined to determine the sources of supply and demand which are included in the calculation. The ATP rules must be associated with items and/or inventory organizations. Also, the data collection program must be run. There is a requirement for ATP calculations to be very fast; some customer service representatives will need to give this information to customers on the phone. However, considering all the possible sources of supply and demand for an ATP calculation can be very complex. Therefore, a concurrent process known as data collection must be run to summarize the supply and demand picture. This program is part of the Oracle Advanced Planning and Scheduling application. The ATP calculation is then performed on the summary tables. For details about setting up ATP rules and running the data collection program, see the setup section of this document.
Scheduling is an action performed on an order line or a group of lines. The action performs the following:
Determines the source (warehouse) for the order line. If the warehouse is entered on the line, either manually or using defaulting rules, the scheduling action uses the requested warehouse and the other scheduling results are based on it. If the warehouse is blank, the scheduling action determines the best warehouse based on the sourcing rules. This functionality includes ATO models.
Determines the schedule ship date, the schedule arrival date, the delivery lead time and the shipping method.
Makes the line visible to the planning applications and consumes supply for the item. When a line is successfully scheduled the VISIBLE_DEMAND_FLAG is set to Yes.
If the reservation time fence is set and the schedule ship date is within the reservation time fence, automatically reserves the line.
The request date may be either the requested ship date or the requested arrival date depending on the request date type of the customer. If the customer's request dates are requested arrival dates, the scheduling action calls MRP's scheduling API with the requested arrival date. The API returns the first date on or after the requested arrival date that the items could arrive at the customer location, and enters that date into the scheduled arrival date field for the line(s). The schedule ship date is calculated by subtracting the delivery lead time (number of days for items to reach the customer once they ship) from the schedule arrival date. If the shipping network has not been defined for this combination of locations, the delivery lead time will be considered zero days and the schedule ship date and schedule arrival date will be the same.
If you enter a schedule ship date on the order line before performing the schedule action, the system will attempt to schedule on that date when the schedule action occurs. If it cannot, the schedule action fails.
You can define for each customer the delivery window in days that they will accept by entering the latest schedule limit on the customer window. When you enter an order line, the latest acceptable date is calculated by adding the latest schedule limit to the request date. When the scheduling action occurs, the schedule date will only be returned if it is between the requested date and the latest acceptable date. If it is not within this range, the scheduling action fails. For example, suppose that you have a customer who only accepts orders that ship within 5 days of the request date. You would enter 5 in the latest schedule limit fields on the Order Management tab of the customer window. When you enter an order line, if the request date is September 10, the latest acceptable date would be September 15. When the scheduling action occurs, if the schedule date returned is not in the date range of September 10 through September 15, the schedule request fails.
You can control whether OM schedules lines on hold by using the system parameter OM: Schedule lines on Hold. If an order or line is on hold and this system parameter is set to No, then the scheduling action fails.
The scheduling action can be invoked in multiple ways. You can schedule from the sales order window by having autoschedule turned on, or by manually choosing to schedule using the context menu or the tools menu. You can schedule using a workflow activity either immediately or in deferred mode. If the scheduling action fails in the workflow then the line is moved to scheduling eligible activity. You can then use the Schedule Orders concurrent program to schedule the lines with exceptions.
Autoschedule
The sales order line is scheduled when it is saved. If either the Autoschedule check box on the order transaction type is checked or the OM: Autoschedule profile option is Yes, the sales order will be opened in Autoschedule mode. You can turn Autoschedule on or off from the sales order window by going to the Tools menu. Note that if autoschedule is turned on the availability window is automatically displayed when the sales order window is opened. You can close the availability window, but the lines will still be autoscheduled unless the autoschedule check box on the tools menu is unchecked.
Autoschedule Sets
If you set the value of OM: Auto Schedule Sets system parameter as No, then the application does not schedule the lines automatically, when you add them to a new ship or arrival set. You can schedule the lines manually whenever it is required. If you set the value of this system parameter as Yes, then the application schedules the lines as and when you add them to a set. The default value of the system parameter is Yes.
If the value of OM: Auto Schedule Sets system parameter is No, then the application behaves in the following manner:
When you or the application add a line to a new set, either by defaulting or manually, then upon saving, the line is not scheduled automatically. The application adds it to the set though. You can then schedule the line whenever required. However, once the line that is part of a set is scheduled, even if the OM: Auto Schedule Sets system parameter is set to No, it cannot be unscheduled. If the line has to be unscheduled, then you have to remove the line from the set first.
When you or the application add a line to an existing set, and the set is not scheduled (lines part of the set are not scheduled), then the application adds the line to the set but does not schedule the line. This is irrespective of the value of the OM: Auto Schedule Sets parameter.
When a line is added to an existing set, and the set is already scheduled (lines part of the set are already scheduled), then the new line gets scheduled and added to the set. The application considers the value of the OM: Auto Schedule Sets system parameter only when a line is added to a new set. However, if the new line could not be scheduled for any reason (scheduling errors out), then the line is not added to the set.
When a sales order in Entered status has lines that are part of a set and not scheduled, is booked, then the application schedules all the lines in the set. In this case, booking causes the order line workflow, as seeded by Oracle, to advance to activity Schedule (LINE_SCHEDULING), which triggers scheduling, irrespective of the value of the OM: Auto Schedule Sets system parameter.
When there are multiple lines in a set, and you try to schedule the set, if any of the lines in the set could not be scheduled to the set attributes, the whole set remains unscheduled. All the lines remain as part of the set.
When lines are added to a set and are not scheduled yet, the OM: Auto Schedule Sets system parameter is changed to Yes, and a new line is added to the same set, then the new line gets added to the set, but does not get scheduled. The new line remains unscheduled, even though the value of the system parameter is Yes. The application honors the value of the system parameter only when the set is getting created. If the set is already created, then new lines added to the set retain the set behavior, irrespective of the value of the system parameter.
The OM: Auto Schedule Sets system parameter is applicable to standard items, models (ATO/PTO) and kits.
Manual
You can access the scheduling sub menu either by selecting schedule from the list of activities on the tools menu or by placing your cursor on a line and pressing the right mouse button. Selecting schedule from these menus will trigger the scheduling action. If the action is selected from the order header tab, all the lines on the order will be scheduled. If the action is selected from the lines tab, it applies only to the line or group of lines selected.If the profile option MSC_OM_IMPORT_PRESCHEDULED is set to Yes, then you will be able to schedule ATO items on weekends as well. However if you require the scheduling to be done only on valid working days, set this profile option to No.
Workflow
The seeded scheduling workflow activity should be used in the workflow process for your order lines. In the Line Flow - Generic seeded flow, the schedule activity is a synchronous activity immediately after booking. With this type of process, scheduling will occur immediately after booking. Scheduling errors will be seen by the person who is booking the order. If the scheduling activity is deferred it will occur after the workflow background process runs and any error messages will be available in the process messages window.Only lines waiting at the Schedule-Eligible workflow activity are selected. The default is no value entered. Note that the lines may or may not be scheduled and still could be waiting at the activity. See: Using Oracle Workflow in Oracle Order Management.
Manual Scheduling Sub-Process
In Release 12, a new scheduling sub-process named Schedule-Line, Manual is provided to handle cases where you may want to control scheduling manually after the order is booked. If the new sub-process is used in the line workflow, then after booking the order, lines are blocked at the Schedule-Eligible activity. You can progress the Schedule-Eligible activity from Sales Orders window or use the Schedule Orders concurrent program to schedule the lines.
A new generic line workflow is not provided with this new sub-process. If you require to use this sub-process you can copy and customize the generic line workflow and replace the new sub-process in place of the existing Schedule – Line sub-process.
For additional details please refer to the Oracle Order Management User's Guide.
Schedule Orders Concurrent Program
The Schedule Orders Concurrent Program functionality has been enhanced in the current release. This program selects all lines that have failed workflow scheduling, and attempts to schedule them. These lines are waiting at the schedule-eligible activity. The user can select orders based on the order number and other parameters.
In addition, lines that have never been scheduled can now be scheduled using the Schedule Orders concurrent program. This is useful for high-volume orders, where a batch of imported orders in Booked status can be mass scheduled. Please note that lines that have not been booked are not scheduled.
Also the enhancements to the Schedule Orders concurrent program enable you to reschedule lines in case there is a change in supply dates or even unschedule lines if they have been scheduled previously. You have two re-scheduling options: Re-Schedule and Re-scheduling with Request Date. You can query scheduled lines and perform a reschedule. You can move schedules in and out based on the item’s availability, and if orders or delivery schedules from suppliers are changed or cancelled, then the allocated product can be rescheduled to meet other demands earlier or later. You can query and sort scheduled lines, and assign either a new Schedule Ship Date (this can be Schedule Ship Date or Schedule Arrival date; depending on the Order Date Type value) or Warehouse (location) when re-scheduling a line.
For each line of the order that fails workflow scheduling, messages will be stored in the Process Messages table and also printed in the logfile.
If scheduling was successful, the scheduling workflow activity will complete with a result of COMPLETE so that the line can progress to the next activity.
If scheduling was not successful, the workflow activity will complete with the result of INCOMPLETE. The line can then be scheduled manually by progressing the order from the sales order window (press the Action button and select Progress Order) or automatically in the next run of the scheduling concurrent program.
Submit the scheduling concurrent program by navigating to (N) Orders, Returns > Schedule Order. See: Oracle Order Management User's Guide
Scheduling Across Orders
Scheduling Across Orders provides the ability to view scheduling attributes of multiple lines across orders, and to perform any scheduling action from a single window. From the Scheduling tab on the Find window of the Order Organizer, you can query lines based on a variety of parameters, such as:
Item
Warehouse
Request Date
Reservation Status (Reserved or Unreserved)
Scheduling Status (Scheduled or Unscheduled)
Shipping Status (Picked, Unpicked, or Backordered)
Order Status
Customer
Shipment Priority
Schedule Date Ranges
Request Date Ranges
After performing an intelligent query to display a group of lines, you will see a new window, Scheduling Organizer. From the Scheduling Organizer, you can perform scheduling actions on lines across orders, that is, you can Schedule, Unschedule, Reserve, Unreserve and perform ATP inquiry.
Access to the scheduling tab is controlled by the Profile Option OM: Scheduling Role. Those with the role of CSR Only do not have access to the Scheduling tab, but they have the same functionality available in previous releases. Those with the role of Scheduler Only are allowed access to the Scheduling tab, but not to other tabs (Order Information, Line Information, Advanced, and Holds Information). Those with the role of both CSR and Scheduler have access to all tabs in the Find window of the Order Organizer. Additionally, the role determines whether some actions are available. For instance, those with the role of Scheduler only will not be allowed to open the Sales Order window from the Scheduling Organizer.
Scheduling Across Orders is useful in a variety of business scenarios:
Availability and/or scarce inventory: Who has the reserved items? Which customers have scheduled lines? Which customers have unscheduled lines? If desired, you can take supply away from lower priority customers, and give it to higher priority customers within Scheduling Across Orders.
Customer service: View all the lines for a customer. Which lines need to be scheduled or reserved?
Scheduling: Query all lines that are scheduled to ship on a specific date, and push out the schedule date for those lines as required. Or query any lines where Override ATP is flagged, and decide how to provide supply.
Revenue impact: Query up all lines for an item, and display gross margin. Using Folders, move gross margin to be one of the first three columns on the Scheduling Organizer. Then sort based on gross margin. Reserve the lines with the higher gross margins, and pick by prior reservation. By doing so, you can impact bottom line for a month, quarter, and so on.
To use these strategies, the general flow is:
Use business logic to select and reserve the lines you want to pick release
Pick release "By Prior Reservation"
Ship the reserved items immediately
Ship remaining qtys when supply is available
Scheduling Groups of Lines
For scheduling functions other than Override ATP, Order Management may perform the function on only one line or on that line and a group of related lines. Scheduling treats the following groups as scheduling sets. For these line groups, the scheduling activity occurs on all the lines of a set.
Assemble to Order (ATO) Models
Ship Model Complete (SMC) Pick to Order (PTO) Models
Line Sets
Ship Sets
Arrival Sets
Scheduling processes the lines of the set together and applies the rules required to honor the set. If lines are in a ship set they will be scheduled from the same warehouse and will have the same requested ship date and ship to. They may not have the same Shipping Method. For instance, in a PTO model or a ship set you might ship a fragile part using one Shipping Method, and a heavy part using another Shipping Method.
User created ship sets, ATO models and SMC PTO models are all ship sets.
All lines in a user created arrival set will have the same arrival date and ship to organization. Lines assigned to an Arrival Set within an order will be scheduled with the same requested arrival date and ship to.
The following table shows the behavior for each scheduling function with each type of line group.
| Line Group Type | Calculate ATP | Schedule | Reserve |
|---|---|---|---|
| Standard Line (not in any set) | That Line | That Line | That Line |
| Standard Line (in ship or arrival set) | Whole Set | Whole Set | That Line |
| ATO Model | Whole configuration | Whole configuration | Cannot Reserve |
| ATO Class | Whole configuration | Whole configuration | Cannot Reserve |
| ATO Option | Whole configuration | Whole configuration | Cannot Reserve |
| PTO Model (Ship Model Complete) | Whole configuration | Whole configuration | Whole configuration, but each line is reserved separately |
| PTO Class (Ship Model Complete) | Whole configuration | Whole configuration | Class and its included items |
| PTO Options (Ship Model Complete) | Whole configuration | Whole configuration | Only the option |
| PTO Model (non-Ship Model Complete) | Whole configuration, but ATP will be performed separately for each line | Whole configuration, but each line will be scheduled separately | Whole configuration, but each line is reserved separately |
| PTO Class (non-Ship Model Complete) | Class and its included items | Class and its included items | Class and its included items |
| PTO Options (non-Ship Model Complete) | Only the option | Only the option | Only the option |
| Included Item (Ship Model Complete) | Whole configuration | Whole configuration | That Line |
| Included Item (non-Ship Model Complete) | That line | That line | That line |
| Service Line | Cannot calculate ATP | Cannot schedule | Cannot reserve |
For scheduling actions other than Override ATP, you can manually request scheduling for more than one line at a time by multi-selecting the lines. (Override ATP is intended for exceptions only.) From the sales order window, select each line by pressing the Ctrl key and clicking the mouse. The selected lines will be highlighted. The scheduling activity that you request will be executed for the lines that you selected, plus any lines that are required to be scheduled with them because they are in the same group. The lines that are multi-selected that are not in a scheduling group will be processed independently.
Ship Sets can be enforced at the time of Pick Release or display a warning at Ship Confirm. If you decide to enforce Ship Sets at the time of Pick Release, N > Setup > Shipping > Shipping Parameters > Pick Release > check the flag to "Enforce Ship Sets and Ship Models." The enforcement ensures that all lines assigned to the same Line Set will not progress until each line in the set is ready.
A Ship Set is a group of order lines which must ship from the same warehouse on the same day with the same ship to location. If the enforce Ship Sets flag is checked, Pick Release will not pick anything in the ship set unless everything in the ship set is ready to go; that is, there is inventory available, no holds exist and it is eligible for pick release. The order entry window will ensure that the common attributes are the same across all lines in the set.
An Arrival set is a set of order line Shipments which must arrive at the customer site at the same time regardless of how each line is shipped or from where it is shipped. The scheduling functions will honor arrival sets and the ATP calculation will operate on a whole arrival set together as a group, taking delivery lead times into consideration to meet the scheduled arrival date. Arrival sets can ship from different warehouses and ship on different days, but the ship To organization and the scheduled arrival date must be the same on each line in the arrival set.
Lines in sets will be enforced to have some common attributes. Ship Sets need to have a common Schedule Ship date, Ship From and Ship To while Arrival Sets need to have a common Schedule Arrival Date and Ship To. A Line can either belong to a Ship Set or an Arrival Set at one time.
Oracle Order Management enhances Line Set (Ship/Arrival) functionality with seeded defaulting rules minimizing the need for user action thus reducing error and keystrokes.
Features include:
Allow defaulting header level Line Set (Ship/Arrival) from Order Transaction Types See Transaction Types for more information.
Customer
Invoice To
Ship To
Previously, there were hard coded defaulting rules such as Ship To, Line Set, Invoice To, Line Set, or Customer.Line Set (Sold to), depending on which lines were automatically included in Ship or Arrival Sets.
The hard coded defaulting rules have been converted to seeded defaulting rules using defaulting framework to provide flexibility in changing the sequence of the rules to be used.
Added defaulting rule for Order Type.Line Set
A facility has been provided to define a defaulting rule for Ship Set or Arrival Set based on the Transaction type.
Note: Defaulted Set at the header level will only affect the new lines that are being created and will not have any impact on existing lines.
Default Line set column has been added to the Transaction type Form. This is available only for Order Level Transaction types.
Line Set choice of "Ship" or "Arrival" provided by an LOV. N > Setup > Transaction Type > Define > Shipping Tab > Line Set field
See: Define Order Management Transaction Types
Oracle Order Management has increased the choice to their customers of header level Ship/Arrival Set functionality. The profile, "OM: Assign new set for each line," provides two alternatives:
Many businesses do not wish to create multiple shipments for a single order. The default is set to "No," creating a single Ship/Arrival Set per order. As an example, if the header level choice is Ship, all successfully scheduled lines are assigned to one Ship Set when created. If one line fails scheduling, none of the lines are assigned to a Ship Set.
It is important for other businesses that a single line ship complete and multiple shipments are allowed per order. By setting the profile to "Yes," the system creates a unique Ship/Arrival Set for each line in an order as long as the line can be scheduled.
This profile allows you to determine how Order Management places lines into sets. Set to "No," all successfully scheduled lines automatically go into one Ship or Arrival Set. Set to "Yes," each line is scheduled into a unique set (Ship or Arrival) based on the header level preference.
Option 1 provides functionality for businesses that prefer to group all lines of an order into one Ship Set or Arrival Set.
Setting the profile to "No" with header level set to "Ship" creates one Ship Set per order, scheduling all of the lines to ship together from the same warehouse to the same Ship To with the same Scheduled Ship Date, potentially saving on freight costs.
Setting the profile to "No" with header level set to "Arrival" creates one Arrival Set per order, scheduling all of the lines to arrive together at the same Ship To with the same Scheduled Arrival Date providing a high level of customer service through scheduling to deliver all lines of the order at the same time to the same place.
Option 2 creates an additional use of Ship/Arrival Sets by creating a unique set for each line of an order.
Setting the profile to "Yes" with header level set to "Ship" creates a unique Ship Set for each line of the order. Creating line level Ship Sets enforces that the full quantity ordered is scheduled to ship at the same time. Thus assisting in customer satisfaction through shipping full quantity every time an item is ordered. It also allows flexibility in that each line is independent. Consider an order with two lines, 1) Item A, quantity 500 2) Item B, quantity 200. At the time of scheduling, Item A has full quantity of 500 available to be ordered while Item B only has quantity 50 available. With separate Ship Sets, Item A, quantity 500 proceeds to Pick Release and Ship Confirm while Line 2, Item B will not progress. The customer is happy as full quantity 500 of Line 1, Item A is shipped immediately instead of waiting for the complete quantity of Line, 2 Item B to ship on the same date.
Similarly, setting the profile to “Yes” with header level set to “Arrival” creates a unique Arrival Set for each line of the order. Creating line level Arrival sets enforces that the full quantity ordered is scheduled to arrive. Thus assisting in customer satisfaction through shipping full quantity every time an item is ordered. It also allows flexibility in that each line is independent. Consider the same order with two lines, 1) Item A, quantity 500 2) Item B, quantity 200. At the time of scheduling, Item A has full quantity of 500 available to be ordered while Item B only has quantity 50 available. With separate Arrival Sets, Item A, quantity 500 proceeds to Pick Release and Ship Confirm while Line 2, Item B will not progress. The customer is happy as full quantity 500 of Line 1, Item A arrives together instead of waiting for the complete quantity of Line, 2 Item B to arrive on the same date.
Define a Defaulting Rule to determine header level setting as Ship or Arrival
Set the profile option OM: Assign New Set For Each Line to “No.”
Define a Defaulting Rule to determine header level setting as Ship or Arrival.
Set the profile option OM: Assign New Set For Each Line to “Yes.”
Order Management has many features to help manage scheduled lines when the lines are changed. When a scheduled line is changed, the system reschedules the line. For example, if you change the ordered quantity or the warehouse, the system reschedules based on this new information.
When a new line is inserted into a scheduling group (such as a ship set or a configuration) that is scheduled the system will first try to schedule the new line with the same attributes as the other lines in the scheduling group. If that fails, then it checks the value of the profile option Auto Push Group Date. If the value is No, the line is inserted but not scheduled. If the value is Yes, the system tries to reschedule the whole set. If rescheduling the whole set fails, the line is inserted but not scheduled. Exception: If the line is part of an ATO configuration or a ship model complete PTO configuration, and scheduling the group of lines together fails, then the line will not be inserted.
When you cancel a line that has been scheduled or reserved, the system unschedules the lines and removes the reservations. If a scheduled line is partially canceled, the system cancels scheduling information in this order:
If the quantity requested for cancellation includes lines with reservations, the system cancels the reservations one at a time until the reserved quantity does not exceed the remaining uncanceled quantity. Reservations are canceled in this order:
Reservations that are not detailed are canceled first, that is, organization or warehouse level reservations.Reservations that are detailed are canceled next, that is, subinventory or lot level reservations.
If a scheduled line is split then both of the new lines are scheduled. If the line is partially reserved, Order Management determines which of the new lines get the reserved quantity, based on whether the split is initiated by a user or the system.
User splits: The customer may request shipment on more than one date so the user splits the line. If a original line is partially reserved, the first new line gets as much of the reserved quantity as it needs, then the second line, etc. For example, suppose that a line has order quantity of ten and reserved quantity of three. If the line is split into two lines with order quantities of six and four, the first new line will have a reservation for three and the second new line will not have any reservation. If an order line has order quantity of ten and reserved quantity of seven, and the line is split into two lines with ordered quantities of six and four, then the first line will have a reserved quantity of six and the second line will have a reserved quantity of one.
System splits: Lines are split by the system when a partial quantity is ship confirmed. In this case the shipped line will have a reserved quantity of zero—it doesn't need reservations any more—so any remaining reserved quantity belongs to the unshipped line(s).
Global Order Promising for ATO Models
This feature offers the following functionality:
Ability to schedule an ATO model without supplying a warehouse: Supplying a warehouse is not necessary to schedule an ATO model. Sourcing rules are used to provide the best warehouse based on availability, and derive the source for the ATO Model. This is available regardless of whether you are using Operation Data Store or Planning Data Store. When scheduling with planned data, the system will try to net any existing configurations:
If a matching configuration is found, the system schedules based on the matched configuration. Available on-hand material is used before checking for other supply.
If no match is found, the system schedules based on the model and its children.
Ability to net configurations for ATO models: This feature is available only with a fully licensed version of ASCP and GOP. Match functionality is available with Planning Data Store only, not with Operation Data Store.
GOP promises availability based on the configuration instead of the model and options, if the date for the configuration is better than that of the model and options. If a match is found, the promised availability considers the matched configuration supply. The system checks whether there is any on hand or on order for a match that is not consumed by other orders before it checks availability for making a new item.
Linking refers to creating the configuration item. The configured item can be created either manually or via a concurrent program, Autocreate Configuration. The same match functionality used during scheduling is also supported during the creation of the configuration item.
Note: Operation Data Store (ODS) represents all tables that act as the destination for the collected data from Oracle applications or the legacy system. ODS ATP is Available to Promise based on collected data.
Note: Planning Data Store (PDS) encompasses all of the tables in ODS plus other output tables from planning. PDS ATP means ATP based on planning output.
Publishing Plan Results
For Scheduled lines with Planned items, Advanced Supply Chain Planning (ASCP) can make planning recommendations based on the latest supply/demand picture. These recommendations can be published to Order Management, automatically updating the sales order line(s). This is applicable for Planned items only. You can firm a line to prevent updates to the warehouse. Note that the ability to publish plan results to Order Management means that there is the potential for a number of scheduling attributes to be changed. If your items are not planned items, those items will not be impacted by any changes in planning.
The following attributes may be updated by ASCP:
Scheduled arrival date
Scheduled ship date
Warehouse (if line is not firmed)
Delivery lead time
Shipping method
Publishing Plan Behavior with Models:
‘Firm Demand' flag cascades across Assemble To Order (ATO) Models
Updates occur only if all lines within the ATO Model contain planned items
Pick To Order (PTO) models and kits
Ship Model Complete (SMC) models / kits (SMCs) are not supported
Options and included items in non-SMC models and kits are supported
Publishing Plan Behavior with Ship and Arrival Sets
Updates to sets will occur only if all the lines in the set contain planned items
Warehouse cannot be updated if any line within the set is firmed
If one line in the set is not planned, none of the lines in the set will be updated based on the results of the new plan.
Note: If one line in the set is firmed, all lines in the set are treated as firmed. The warehouse cannot be updated on any line in the set, if even one line of the set is firmed.
How would this new feature work with Override ATP?
APS can update overridden lines if they are NOT firmed. When this occurs, OM un-overrides the lines
OM allows APS to update the overridden lines irrespective of the authorization profile value OM: Authorized to Override ATP.
Firming a line prevents updates to the warehouse by APS
There are three optional firming methods:
Manually enable the ‘Firm Demand' Flag on Sales Order Line.
From the Shipping tab, use Folder functionality to display the Firm Demand flag.
To firm lines manually, check the flag for Firm Demand.
Set up pre-defined events on the Order Management System Parameters form
Create a Line Type with the seeded sub-process ‘Wait to Firm Line' inserted in the line flow. Then use the ‘Progress from Firm Process' concurrent program to progress and firm the line(s).
Override ATP enables you to schedule an item that is available to promise even if there is no supply. It is designed for exceptions. For example, you can take supply from one customer and give it to a higher-priority customer. You can make use of supply that is not recognized by the system. Once Override ATP is set for a line, that line remains overridden until the override flag is removed or the line is unscheduled.
You may want to allow only a single planner, scheduler, or sales order administrator to use this feature. Overriding ATP creates the responsibility of manually finding supply. Authorization to override ATP is secured through the use of a profile options, OM: Authorized to Override ATP.
Provide a schedule date
Check the Override ATP box
Save any changes.
Override ATP honors days, but ignores time stamps in the date fields. Once a line is overridden, unauthorized users cannot undo the override, unschedule a line, or change scheduling-related attributes such as warehouse or the Ship_To location. If the line is at a point in the flow where allowed by processing constraints, unauthorized users can cancel or reduce quantity, or delete the line. Unauthorized users can also split the line, if scheduling attributes are not changed.
If you uncheck the Override ATP check box, the system tries to reschedule the line. If there is supply, the line will schedule. If the supply in insufficient, the line can be left unscheduled, or the you can override ATP. Override ATP does not apply to service items or to drop ship or return lines.
For ATO models, the override flag cascades to other items within the model. For PTO models, it cascades only to included items.
In Oracle Order Management, you can reserve on-hand inventory to a sales order. Reserved inventory cannot be used for any other purpose. The reserved quantity for a sales order line is displayed on the shipping tab. You may reserve part or all of the ordered quantity.
A line must be scheduled before it can be reserved. If you try to reserve an unscheduled line, the system will first try to schedule the line. If the line is successfully scheduled then the system will try to reserve it.
There are two ways to reserve manually from the sales order window.
Select reserve from the scheduling option under the tools menu
Select reserve from the scheduling sub menu which is displayed when you select the context menu.
If you are on an order line the line will be reserved. If you are on the header, all the lines will be reserved.
Manual reservations are affected by a scheduling parameter that lets you control whether to apply a partial reservation manually. If 9 out of 10 are available, and if you have set the parameters to allow partials, you can right mouse click to bring up the context menu and select Reserve to reserve the 9.
Reservations are performed automatically whenever a line is scheduled and the schedule date is within the reservation time fence. For example, suppose the today's date is November 25th. An order line is scheduled for December 1st, which is 6 days away. If the reservation time fence is 10, the line will be reserved because 6 < 10. If the reservation time fence is 2, the line will not be reserved because 6 > 2. If the reservation time fence is NULL, then lines will not be automatically reserved. The reservation time fence is set using the system parameter Reservation Time Fence.
Reservations Time Fence is affected by the scheduling parameters, Allow Partials. If you want the reservation time fence to reserve as much as possible, even though full supply is not available, set the scheduling parameter to allow partials.
When you create reservations manually on the sales order window or automatically using the reservation time fence, the items are reserved at the warehouse level with no inventory details specified, or at the subinventory if the subinventory is specified on the line. You can specify inventory details for a reservation by using inventory's reservation details window. To access the window from the sales order window, go to the tools menu and select scheduling. From the list of options select Reservation Details, where you can reserve by lot, revision, subinventory and/or locator. You can only access the reservation details window for lines that are scheduled.
The Reserve Orders concurrent program is able to reserve any line that is scheduled, assuming full quantity for the line exists. A number of parameters are provided that enable you to select orders and lines to reserve by order number range, customer name, order type, item, request date, ship date, arrival date, order date, demand class, and within the reservation time fence.
Reserve Orders does not lock the supply for the queried lines. You may want to implement a business process of one person at a time reserving for an item.
You can run the Reserve Orders program against a filtered group of orders. In addition, there are Sort parameters, so that existing supply can be sequenced using attributes such as:
Date Ordered
Request Date
Scheduled Ship Date
Arrival Date
Promise Date
Line Planning priority
You can use this feature in a variety of business scenarios. Perhaps you are using the reservation time fence, but there is no supply at the time the line schedules. Once there is additional supply, you can run Reserve Orders to update reservations on lines that are within the reservation time fence. Or perhaps you have a Customer who is complaining about not receiving items as requested. You can query all lines for a particular customer, or for lines within a specific schedule date range, and place reservations on those lines.
You can also use Reserve Orders for the reservation strategies of Fair Share, Percentage, and Partial.
The following reservation modes are available for making reservations:
Fair Share
Percentage
Partial, include only unreserved lines
Partial, include partially reserved lines
Additionally, the following reservation run types are available:
Reserve
Simulate
Create Reservation for Set
If you have specific business needs not met by the above, you can write your own using the API hook OE_RESERVE_CONC_HOOK. The Business procedure can be used to add business validation logic, that is only reserve case quantities.
Hook Package: OE_RESERVE_CONC_HOOK. This hook is provided with two procedures: Simulation Data Procedure :
Business Validation Procedure : Procedure Qty_Per_Business_Rule
Simulated_Results Business procedure can be used to add business validation logics like allow only case qty reservation and so on.
For example, Fair Share might determine that 58 out of the requested qty of 80 can be reserved for Fair Share. But if the user wants to ship only case quantities of 50, then the user can write their own API to round the qty of 58 down to 50. The Simulation procedure can be used to read the simulated data.
Fair Share
Fair share distributes available on-hand supply among selected lines on a pro-rated basis. For example,
10 units are available.
Line 1 Requested Qty is 60
Line 2 Requested Qty is 40
Fair Share reserves as follows:
6 are reserved for Line 1
4 are reserved for Line 2
With this method, distribution is determined by the amount of each order; a larger order will receive a larger portion of available supply. Once the reservations are placed, you can Pick by Prior Reservation, ship those lines, and get them out the door. The remaining quantities are fulfilled as supply is available.
With Fair Share, every queried line receives something assuming there is supply for each line to get at least one piece. If supply is divided across warehouses, Fair Share is calculated separately for each warehouse, as shown below. In this example, there are 100 pieces in M1 and 100 pieces in M2. Because 140 are requested in M1, each line gets about 71% of supply. Notice that the fractional quantities are rounded down, assuming that the OM Indivisible flag is set on the Physical Attributes tab of the Item Master.
| Line | Item | WH | Req Qty | Factor | Factor * Req Qty | Derived Qty |
|---|---|---|---|---|---|---|
| 1 | ItemA | M1 | 80 | 0.71429 | 57.14286 | 57 |
| 2 | ItemA | M1 | 60 | 0.71429 | 42.85714 | 42 |
| 3 | ItemA | M2 | 20 | 0.625 | 25 | 25 |
| 4 | ItemA | M2 | 40 | 0.625 | 12.5 | 12 |
| 5 | ItemA | M2 | 100 | 0.625 | 62.5 | 62 |
In this case, supply is divided across warehouses and different warehouses are specified on the order lines. Fair Share is first calculated for each subinventory. Then if there is remaining supply, lines with no subinventory receive Fair Share
| Line | Item | WH | Sub | Req Qty | Factor | Factor * Req Qty | Derived Qty |
|---|---|---|---|---|---|---|---|
| 1 | ItemA | M1 | Stores | 80 | 0.71429 | 57.14285714 | 57 |
| 2 | ItemA | M1 | Stores | 60 | 0.71429 | 42.85714286 | 42 |
| 3 | ItemA | M2 | Stores | 20 | 1 | 20 | 20 |
| 4 | ItemA | M2 | FGI | 40 | 0.35714 | 14.28571 | 14 |
| 5 | ItemA | M2 | FGI | 100 | 0.35714 | 35.71429 | 35 |
| 6 | ItemA | M2 | 15 | 0.50000 | 7.50000 | 7* | |
| 7 | ItemA | M2 | 15 | 0.50000 | 7.50000 | 7* | |
| *Available in M2 Stores |
Percentage
Percentage allows you to specify that a percentage of the available supply is allotted to specified lines. For example, assume that 100 pieces of the specified item are available:
For Line 1, 80 are requested and 40 are reserved.
For Line 2, 100 are requested and 50 are reserved.
For Line 3, 30 are requested and 10 are reserved.
For Line 4, 20 are requested and none are reserved.
This mode reserves the specified percentage on each line, if supply exists. But when the supply is consumed, no further reservations can be made.
Order By parameters can be used with Percentage Mode, such as Order By Request Date, in order to give available supply to those lines that were requested earlier rather than later.
Partial
If only part of the full Requested Qty is available, a partial reservation can be applied.
The following chart shows what you can expect if 100 are available, and the following amounts are requested.
For Fair Share, each line gets approximately a third of the requested qty, because the demand for these lines is 300. Note that Line 2 rounds down, i.e. .33333 * 60 is rounded down to 19. You can have remaining quantities with Fair Share.
For Percentage and Partial, there is no guarantee that each line will get supply, which is why the Order By parameter is recommended.
| Lines | Req Qty | Fair Share | Percentage, 40% | Partial |
|---|---|---|---|---|
| 1 | 80 | 26 | 32 | 80 |
| 2 | 60 | 19 | 24 | 20 |
| 3 | 40 | 13 | 16 | |
| 4 | 20 | 6 | 8 | |
| 5 | 100 | 33 | 20 | |
| Remainder | 2 | N/A | N/A |
When using any of these reservation strategies, there is no special logic for sets and PTO models.
Reservation Run Types
Simulate - Reservations are not committed to the reservations table. They are instead saved in a temp table, and if desired, users can use the Scheduling Across Orders window to:
View the simulated reservations
Make modifications if desired
Create Reservation for Set - This allows users to commit the quantities reserved in the simulation set to become reservations.
You can perform Reservation Modes either from Scheduling Across Orders, or from Concurrent Requests. From Scheduling Across Orders, the steps are:
From the scheduling tab of the Find window, query the desired items / lines for reservations.
From the Actions menu, choose Reserve Orders Request. You will be asked to specify:
Reservation Run Type, i.e. do you want to simulate or reserve? If you reserve, the items will be reserved in Oracle's tables. If you simulate, you will have the opportunity to view and edit the reservations before committing them.
Reservation Set Name. You need to provide a name so that you can query later to see the results.
Override Set Name? If there is already a reservation set using this reservation set name, should that name be overridden?
Reservation Mode, i.e. do you want to do Fair Share or select another reservation strategy.
Percentage. If you've chosen the Percentage strategy, specify the percentage, i.e. 60% of requested quantity.
Order By. Not applicable for Fair Share. But for Partial and Percentage strategies, would you like to give preference to lines with an earlier request date, a higher planning priority, or other criteria?
After entering the above parameters, submit your request. Then if you choose, you can query by Reservation Set Name from the Scheduling tab of the Find window. The Derived Quantity indicates how many items were reserved. If you used a Simulation Run Type, you can make adjustments in the Corrected Qty column. Once satisfied, you can commit the reservations using Actions, Create Reservation for Set. Once the lines are reserved, the Processing column shows the lines as processed / reserved.
This hook is provided to allow creation of need-specific APIs, extending Reserve Orders to apply business-specific rules, such as:
Ensure that a particular customer receives only a case quantity.
Ensure that the reserved quantity for a line never exceeds a specified amount.
Give preference, if desired, to lines with promotional codes.
The modified reserved quantities can be passed back to Oracle and be reserved.
Note: This business process assumes only one person at a time performs reservations for an item.
Package Name: OE_RESERVE_CONC_HOOK. File Names: OEXRSHOS.pls and OEXRSHOB.pls, located in the $ONT_TOP/patch/115/sql directory. Procedures that you can use: Qty_per_Business_rule and Simulated_Results.
Inputs for the 2 procedures can be found in the file OEXCRSVS.pls, located in the $ONT_TOP/patch/115/sql directory. The input is a table of records, named Rsv_Tbl_type. The table of records is based on a record structure, named Res_Rec_type. You need to update the field, derived_reserved_qty with the reserved qty, as per your business rules. Please note that this API only performs reservations. You'll need to use inventory's public API, INV_RESERVATION_PUB, in order to perform unreserve activities.
You can unreserve lines that have been partially or completely reserved. The inventory which was allocated to the line becomes available for other orders, but the line will still be scheduled so it will be visible as demand to the manufacturing applications. The system automatically unreserves a line if it is deleted or canceled.
When you unschedule a line the system will both unreserve and unschedule it. Unscheduling the line sets the VISIBLE_DEMAND_FLAG to No so that the line is no longer visible as demand to the manufacturing applications.
You can unreserve or unschedule by choosing these options from the scheduling submenu of the tools menu or by choosing scheduling from the context menu.
To set up scheduling to meet the needs of your business, note that several fields on the Order Management tab of the customer definition window affect the way scheduling works:
Request Date Type: Scheduling by Ship or Arrival Date
To determine whether to schedule by Ship or Arrival date, set the Request Date Type flag on the customer window to Ship or Arrival. If the value is arrival, the request date will be considered as the arrival date by the system. If the value is ship, then the request date will be considered the ship date. The request date type can be defaulted from the customer information to the order, and the user can change it on the order if required.
Latest Schedule Limit: Latest Acceptable Date
To set a Latest Acceptable Date (LAD) for a particular customer on the order line, enter a value on the customer window for Latest Schedule Limit. This field can contain any numeric positive integer value. This value can be defaulted to the header field, Latest Schedule Limit. When you enter an order line, the latest acceptable date is calculated by adding the latest schedule limit to the request date. When the scheduling action occurs, the schedule date will only be returned if it is between the requested date and the latest acceptable date. If it is not within this range, the scheduling action fails. You can manually override the LAD, but the system will not schedule lines that exceed the LAD.
To set a default ship set or arrival set based on the customer, select either Ship Set or Arrival Set from the Lines In field. If desired, you can also set the value at the Ship To Address (Site) level. You can default this value to the order. If this value is set on the order, then all lines of the order will be placed into a system-defined set if scheduling is successful.
If you are using a reservation mode such as Fair Share with discrete items, set up the OM Indivisible flag on the Physical Attributes tab of the Item. For instance, if you want to reserve "Fair Share" quantity, and your items are discrete units, setting this attribute prevents decimal quantity reservations such as 1.65.
This parameter allows you to control rescheduling if there is a change to the Request Date.
This parameter allows you to control rescheduling if the ship method changes. By default, items are rescheduled if Ship Method is changed. This is desired if you are using Lead Time scheduling. If you are not using lead time scheduling, you can change the Ship Method without triggering rescheduling by setting this parameter to No.
This parameter defines the terms of the promise date. Available options are:
Manual: Promise date entered manually or with defaulting rules. Promise Date not taken from Schedule Ship Date, Schedule Arrival Date, or Request Date.
First Schedule Date
First Request Date
Dependent on Schedule Date: If Schedule Ship Date changes, Promise Date will change.
Dependent on Request Date: Promise Date tied to Request Date.
This parameter allows you to determine if partial reservations are accepted. The default behavior does not allow a reservation to be placed if the full quantity is not available. If necessary, you can set this parameter to allow a partial reservation to be placed using available supply.
Choices for Latest Acceptable Date
This parameter selects the behavior for the latest acceptable date for scheduling. Options are:
Honors the Latest Acceptable Date
Ignores the Latest Acceptable Date and gives a warning
Ignores the Latest Acceptable Date, and gives no warning (default setting)
Possible values are yes and no. If this field is set to yes, the scheduling action processes order lines even if the order or line is on hold. If set to no, the scheduling action will fail if the line is on hold.
This may be any positive integer numeric value. When a line is scheduled it is also automatically reserved whenever the schedule date is within the reservation time fence.
The value of OM: Auto Schedule Sets system parameter decides whether lines, which are getting added to a set, should be automatically scheduled or not, at the time of set creation. If the system parameter value is set to No, then the lines are not scheduled automatically, when they are added to a new set. However, you can schedule the lines manually whenever it is required. If you set the value to Yes, then the lines are scheduled as and when they are added to a set. The default value of the system parameter is Yes and the application treats no value as Yes.
The following profile options affect scheduling functionality:
OM: Autoschedule
Possible values are yes or no. If set to yes, the availability window is displayed when the sales order window is opened and scheduling occurs automatically as each order line is saved. This profile applies only to standard items. It applies to lines entered through Order Import.
OM: Auto Push Group Date
Possible values are yes and no. If the value is yes and a line is added to a scheduled configuration, and the new line cannot be scheduled on the date that the rest of the configuration is scheduled, then the system will try to reschedule the complete configuration at a different time. If the value is no and the new line cannot be scheduled, then scheduling for the new line will fail and the rest of the configuration will not be affected.
OM: Authorized to Override ATP
Possible values are yes or no. If the value is Yes, the the authorized user will be able to check the override ATP flag, and override the Schedule ship date or Arrival date. If the value is No, the user will not be able to override the schedule ship date or arrival date.
OM: Scheduling Role
This pertains to Scheduling Across Orders. Possible values are CSR only, CSR and Scheduler, and Scheduler only. This can be set at either the Responsibility or User level. This profile option determines which tabs can be accessed on the Find window of the Order Organizer. If set to CSR only, there is access to the tabs pertaining to the sales order, but no access to the Scheduling tab. If set to CSR and Scheduler, there is access to all tabs, including the tabs for CSRs and the one for schedulers. If set to Scheduler only, there is access to only the Scheduling tab.
MRP: ATP Assignment Set
This can be any valid assignment set which is defined in the MRP application. It specifies the assignment set that will be used for calculating ATP. Assignment sets are mentioned later in this section.
INV: Capable to Promise
Possible values are Enable Product Family ATP and CTP, Enable Product Family ATP, Enable ATP, ATP/CTP based on Planning Output, and ATP based on Collected Data. This profile option indicates whether and how to calculate ATP. You can choose one of two options.
If you license ASCP and want to use planning output, choose ATP/CTP based on Planning Output.
If you are not licensing ASCP but want to calculate ATP, choose ATP based on Collected Data. See: Scheduling Parameters
You may want to expose the Override ATP flag on the Shipping tab. You may also want to use Folders to tailor the Scheduling tab on the Find window of the Order Organizer, or the Scheduling Organizer window.
The scheduling level on the order transaction type determines what type of scheduling is allowed. The possible values for this are:
ATP Only
You will not be able to schedule or reserve lines on the order. If you have an order transaction type defined with a scheduling level of ATP Only then you must not have the scheduling activity in any of the line level workflow processes. This could be used for Bill-Only or Bill-Only with Inventory Interface flows, or possibly for quoting scenarios.
For example, you could use the ATP Only flow for Bill Only lines that you want to omit from a header level set. If you do not want the Bill Only lines to be scheduled and considered part of the header-level set, you could make the scheduling level of the line transaction type be ATP Only.
No Reservations
You can perform all scheduling functions except for reserving inventory. You will be able to use ATPable items, and schedule all items, but you will not be able to create reservations from the sales order window.
Allow All Scheduling Actions
All scheduling actions can be performed.
Inactive Demand With Reservations
You can manually enter any schedule date, but the system does not schedule. The line can be reserved. The schedule date is not visible to MRP / APS. This functionality is only for standard items, and it does not support ship or arrival sets.
Inactive Demand Without Reservations
You can manually enter any schedule date, but the system does not schedule. No reservation can be placed on the line. The schedule date is not visible to MRP/APS. This functionality is only for standard items, and it does not support ship or arrival sets.
If you don't want your order lines to be visible as demand to the manufacturing applications, do not schedule the lines. Alternatively, you can control this by setting the scheduling level of the order transaction type.
Several fields on the Order Management tab of the customer window affect the way scheduling works.
Scheduling by Ship or Arrival Date
To determine whether to schedule by Ship or Arrival date, set the Request Date Type flag on the customer window to Ship or Arrival. If the value is arrival, the request date will be considered as the arrival date by the system. If the value is ship, then the request date will be considered the ship date. The request date type can be defaulted from the customer information to the order, and the user can change it on the order if required.
Latest Acceptable Date
To set a Latest Acceptable Date (LAD) for a particular customer on the order line, enter a value on the customer window for Latest Schedule Limit. This field can contain any numeric positive integer value. This value can be defaulted to the header field, Latest Schedule Limit. When you enter an order line, the latest acceptable date is calculated by adding the latest schedule limit to the request date. When the scheduling action occurs, the schedule date will only be returned if it is between the requested date and the latest acceptable date. If it is not within this range, the scheduling action fails. You can manually override the LAD, but the system will not schedule lines that exceed the LAD.
Line Set
To set a default ship set or arrival set based on the customer, select either Ship Set or Arrival Set from the Lines In field. If desired, you can also set the value at the Ship To Address (Site) level. You can default this value to the order. If this value is set on the order, then all lines of the order will be placed into a system-defined set if scheduling is successful.
ATP Rules are created in the Inventory module. They indicate which sources of supply and demand to consider when calculating ATP. They can be assigned to inventory organizations and items. If an ATP rule is assigned to an item that is used. If the ATP rule for the item is blank, then the ATP rule for the inventory organization is used.
You must define sourcing rules if you want ATP to determine the warehouse for your order lines. Once sourcing rules are defined, they must be assigned to particular items, categories and/or inventory organizations. You do this using assignment sets.
For scheduling to work in Oracle Order Management you must successfully run the data collection concurrent request set. As previously stated, calculating ATP must happen almost instantaneously, but searching through all the possible sources of supply and demand to calculate ATP is very complex. Therefore, a concurrent process known as data collection must be run to summarize the supply and demand picture. The ATP calculation is then performed on the summary tables. To run the data collection request set, choose Scheduling -> Collect Data from the Oracle Order Management navigation menu. There are two programs in the request set. Enter parameters for both and submit the set. The Planning Data Pull program has a parameter named Complete Refresh. If this is set to yes, then the collection will select all scheduling related information from the relevant tables. If it is set to no, then only the updated information will be selected.
The basic steps for setting up ATP are summarized below:
In Inventory, create the ATP rule, and attach the rule to item(s).
In ASCP, define sourcing rules, such as Item X can be transferred from M1 to M2.
Set the MRP: ATP Assignment Set profile option to point to an assignment set that includes your sourcing rules. Include the ATPable items in the Assignment Set.
Run Collections from either Order Management or ASCP. (If you have never run Collections before, you will need first to define an Instance with assigned orgs. For details, please refer to Oracle Global Order Promising Implementation and User's Guide.
Set the INV: Capable to Promise profile option to the correct level. If you have licensed ASCP, choose ATP/CTP based on Planning Output. If you are using a shared version of ASCP, select ATP based on Collected Data. To use ATP / CTP based on Planning Output, plans must be run.
See: Oracle Global Order Promising Implementation and User's Guide
Oracle Inventory User's Guide
Oracle Master Scheduling/MRP and Oracle Supply Chain Planning User Guide
You can turn off some or all of the scheduling functionality of Order Management. If you want lines to be visible as demand to the manufacturing applications but do not want to perform an ATP check on them then you can set the Check ATP flag of the item to No. You would do this for items where you assume that the item is always available. When the scheduling action is called for a non-ATP item, the system will still perform the sourcing action to determine the warehouse if one is not specified. It will not check ATP but will copy the request date into the schedule date field. The line will become visible to the manufacturing applications as demand on the requested/schedule date.
If you do not want your order lines to be visible as demand to the manufacturing applications, do not schedule the lines. You can control this by setting the scheduling level of the order / line transaction types. The possible values for this setting are ATP only, No Reservations, Allow all Scheduling Actions, Inactive Demand with Reservations, and Inactive Demand without Reservations.
If you want to calculate arrival dates based on the time required for shipment from a warehouse to a customer location through a specified ship method, you must define your inter-location transit times.
See: Oracle Global Order Promising Implementation and User's Guide
Oracle Shipping Execution User's Guide
The penalty factor for late demand is used to calculate the penalty cost calculated by Planning Optimization. You can update the field, but no defaulting logic is provided. For details on how Planning Optimization uses this value, please refer to the Oracle Advanced Planning Implementation and User's Guide.
The schedule dates returned by MRP have only the day, and not the time. Therefore, automatic scheduling in OM can only be at the day level.The Order Management date fields have time capability, so you can enter the time on request dates, promise dates, and the like, but the scheduling function will ignore them: the time stamp returned by ATP is 23:59:59. Availability check provides a quick, rough-cut estimate, so it view availability by days, not hours.
You can use ATP with or without planning. To use ATP with planning, you must license ASCP.
If you have not licensed APS, you can still perform basic ATP. ATP without planning allows you to see what is currently available, but the system cannot use planning to determine if it's possible to build the product by the Request Date. ATP without planning is single-level. IT can see available for an ATO item that is assembled, or an if a WIP job or PO is expected by a certain date. But it cannot calculate whether there are components and resources to build it by a certain date. ATP without planning uses ODS.
If you have licensed APS, you can not only see what is currently available, but also determine if there are resources to source the product by the Request Date. This type of ATP is multi-level, so it can drill down to the component level and look at available materials and resources to determine an available date. ATP with planning uses PDS.
If scheduling is called with a request date that is before today's date then ATP will be calculated using today's date and not the request date. If for some reason (for example a non-ATP item) a schedule date is returned for a past date, the system will not automatically reserve the item even if it is within the reservation time fence.
There are some limitations to using the reservation details window. You cannot:
Multi-select lines and go to the reservation details window.
Go to the reservation details window from the orders block.
Use this window to reserve more than the ordered quantity.
Use this window to modify reservations for a configured item created for an ATO configuration.
Order Management does not guarantee the reservations from the Reservation Details window because the details passed to Inventory may not be valid for the Inventory hierarchy.
Assume the following lines are queried to be reserved, and 100 are available.
Line 1 Qty 35, reserved
Line 2 Qty 35, reserved
Line 3 Qty 35, unreserved (only 30 of 35 are available)
Line 4 Qty 20, reserved
Line 5 Qty 10, reserved
Notice that if full quantity is not available for the line, there is no reservation.
When you run Reserve Orders, there is no guarantee that all lines will be reserved. Another user running Reserve Orders, or reserving manually, may reserve the supply before you do.
When calling Reserve Orders, either from the concurrent requests menu or from Scheduling Across Orders, supply is not locked for the items queried and then reserved. This may mean that one person at a time should reserve for the item. You may want to evaluate if it's feasible for one person to reserve for an item at a time.
If you are using reservation modes to manage scarce inventory, analyze if the business is interesting is more interested in customer service than in cost-cutting. If so, it could be very useful to ship partial quantity that is currently available, and ship remaining quantities when there is more supply.
Reservations modes apply to discrete manufacturing, not process.
Supply is not available. Once the line is overridden, you must take the responsible for finding supply manually.
The following examples illustrate some scheduling features.
The warehouse for the order is defaulted from the ship to site. A shipping network is defined for this warehouse/ship to combination with the shipping method of UPS ground, and the transportation lead time is five days. The customer requests the shipment as soon as possible, so the request date is entered as today's date. On-hand inventory is available to fulfill the order. Autoschedule is on, and the reservation time fence is five days.
You enter an order line with the item, quantity and request date. When the line is saved, because autoschedule is on, it is automatically scheduled for the requested warehouse with a schedule ship date of today. Because the schedule ship date is within the reservation time fence the line is also automatically reserved.
One of the following is set up and used to defined to inter-location transit time from the warehouse:
A customer Location set up in inventory.
Region and Zones functionality introduced by APS
The shipping network is setup in inventory, specifying a Default method to be picked up by Order Management. On the Others tab of the Sales Order header, Order Date Type is Arrival. A warehouse for the customer defaults to the header and line. There is no ship method on the line.
The customer wants to receive the item on Day five. The Request Date is Day five. The item is available. The shipping lead time is three days. When scheduling by arrival date, the line schedules when it is saved. The default ship method defined in the shipping network defaults to the line. The user saves the line, and the item schedules to ship on Day five, arriving on Day five as requested by the customer.
See: Oracle Global Order Promising Implementation and User's Guide
No warehouse is defaulted or entered for the order. No shipping network is defined for the customer. The customer requests the shipment as soon as possible, so the request date is entered as today's date. There is no supply to fulfill the order, but there is a work order scheduled for completion in ten days, and the ATP rule includes work orders as source of supply. Autoschedule is off. The line level workflow process has the scheduling activity immediately after booking as a synchronous activity.
You enter an order line with the item, quantity, and request date. When the line is saved, it does not schedule because AutoScheduling is off. You enter additional lines and book the order. When the order is booked, the workflow scheduling activity executes. The warehouse is determined by sourcing rules. The schedule ship date is sysdate + 10 days, which is the day the work order is scheduled to complete. The schedule arrival date is the same as the schedule ship date.
Some order lines were scheduled to ship on Day 2 because a purchase order was expected on that day. You now know that 100 pieces will arrive on Day 5, not Day 2.
Within Scheduling Across Orders, query lines for the delayed item with a scheduled ship date of Day 2. Multi-select lines that you want to reschedule, then change the Schedule Date to today's date to a more accurate date, Day 5.
A high priority customer is complaining about not getting full ordered quantity of a particular item. Using Reserve Orders, query all order lines for that item and customer. Run Reserve Orders, to place reservations on those lines.
If desired, query the lines for that item and that customer in Scheduling Across Orders. View the reservations. You can also pick release using the Pick by Prior Reservation flag on the Release Orders window. By doing so, you have picked and shipped all lines reserved for a particular item for a high-priority customer.
A very important customer requires a large quantity of a scarce-inventory item to ship as soon as possible. There is no availability, so the line will not schedule.
You know supply has been scheduled for a lower priority customer. You could decide to override ATP for the high priority customer, giving that customer a Schedule Date. You could then review all scheduled lines for the scarce item in Scheduling Across Orders, searching for a lower-priority customer who can wait for supply. Once you've identified a lower priority customer, you could extend the Schedule Date, in effect taking supply from the lower priority customer to give to the higher priority customer.
Show that the schedule date is Day 4, but planning determines there is a shortage and the real schedule date is Day 6. The schedule date on the line can be updated. But maybe you know that for this particular Ship_To address, the warehouse should not be changed. You can firm the warehouse, so that although system can update the Schedule Date, it cannot update the warehouse.
Your supply for an item is short, and you want to give 100% of the requested quantity to your most important customer. Then you want to give everyone else Fair Share. First query all lines for that item for your highest priority customer, and reserve 100% of the requested quantity. Then query all other lines for that item, perhaps those lines scheduled to ship within a date range, and give those lines Fair Share. Then everyone gets something, even if not full quantity.
Perhaps you have short supply, and you have a couple of customers that you know you can short, that is, they are overstocked or have not been paying promptly. Query the lines for each of those customers, or perhaps query all lines with a lower planning or shipment priority. Give those lines 30% of requested quantity. Query all other lines, and give those lines Fair Share or a higher percentage. If you use percentage mode, use the Order By parameter to ensure that lines you deem more deserving get the limited supply ahead of less deserving lines. For example, Order By Request Date, Promise Date, or Ship Date.