Order Management Processes

This chapter covers the following topics:

Line (Ship or Arrival) Sets
Arrival Sets
Ship Sets
Shipment Schedules
Information Retention Across Shipments when a Line is Split:
Common attributes across shipments originating from a Line Split
Fulfillment Sets
Fulfillment With Wait
Ship Set For Each Line
Ship Set for Each Line Major Features
User Procedures
Project Task Changes for Booked Orders Overview
Project Task Changes for Booked Orders Major Features
User Procedures
Seed Data Changes
End Customer
End Customer Major Features
User Procedures
Preview and Print Sales Documents
Preview and Print Major Features
Document Formatting
Security
User Procedures
Integrations
Seed Data
Drop Shipments Overview
Drop Ship Across Ledgers and Change Management Overview
Drop Ship Across Ledgers Major Features
User Procedures
Seed Data: Constraints
Drop Shipment Processing
Change Management for Drop Ship Orders
Purchase Release
Defining Sales Order Line Services Information
Service Termination Overview
Service Termination Major Features
User Procedures
Defining Sales Order Line Project Manufacturing Information
Defining Sales Order Line Release Management Information
Required Fields for Entering Orders
Sorting Order Lines within the Sales Order window, Lines Tab
Booking a Sales Order
Exception Management
Projected Sales Revenue Reporting by Sales Group
User Procedures

Line (Ship or Arrival) Sets

Order Management enables the creation and usage of Line Sets based upon common order line attributes. Ship sets ensure that at the time of ship confirm, all lines within the set are picked and shipped together, and not individually. With Oracle Order Management, creating sets for a shipment expands to include additional set functionality based upon ship, arrival and fulfillment. You can prevent order lines that are part of 'Bill Only' flows to be added to a Ship or Arrival set by specifying the line type as 'Bill Only' in the Transaction Type window.

See: Defining Order Management Transaction Types, Oracle Order Management Implementation Manual for more details.

In general, grouping order lines within sets can:

Assist in reducing shipping costs.
Enable you to deliver complete order quantities to specified customers on mutually agreed upon dates regardless of the order source.
Specify models and kits can only be shipped complete, not partially.
Enable you to perform functions as a group instead of individually. For example, prevent the billing of goods or services until all lines reach fulfillment by ensuring all lines with a set complete a particular activity before progressing to the next activity within their respective process flows.
Add a Split Shipment (backordered line) line to a new or existing Ship Set.

Identifying Order/Line Attributes of Sets

Set definitions are created based upon order line attributes. The set definition enables Order Management to maintain set integrity.

For additional information regarding set specific identifying order/line attributes, see:

Arrival Sets

Fulfillment Sets

Ship Sets

Order lines can be automatically added to either an Arrival or Ship Set (but not both) if you enable header level defaulting of sets. You enable header level defaulting of order lines to sets (either Arrival or Ship Sets only) automatically by customer site; select the appropriate check box (Arrival Sets or Ship Sets) within the Standard Customer window, Order Management tab.

Note: You cannot create a Defaulting Rule using the entity Order Header to default a value for set details. This functionality is unavailable.

Set Functions

You may define, add, or move order lines to sets by choosing one of the following three methods within the Sales Order Lines window:

Using the mouse Right click feature, select Sets, and then select the appropriate function.
Either entering, selecting or clearing the data within the appropriate Set name field in the Shipping tab, with the exception of the Fulfillment Set field.

Note: You must use the right mouse click features when defining a Fulfillment set. You cannot define a new Fulfillment set definition by entering a unique value in the Fulfillment Set field.

If the function you are performing cannot be completed because an appropriate Set definition for the current order is not present, the New Set pop up window will display, enabling you to enter a new set.

For example, you wish to move an existing order line from an Arrival Set to a Ship Set, but a Ship set definition is not present for the current order; Order Management display the New Set pop up window, and instead perform the Add set function. Enter the Set name and click OK to create and add the order line to the new set, or click Cancel to cancel the creation of the new set.

Set Status

Order Management Sets are either Active or Closed.

A Set is Active until one or all of the lines within the set are shipped.
A Set is Closed when one or all order lines within a set have been either shipped, fulfilled, or based upon the arrival date (dependent upon the set definition).

If one order line within a set is shipped, then all remaining lines within the set are removed from the set definition if they are also not shipped and the set Closed.

You cannot add or remove order lines to a closed set.

Set Function Details

When you define a new set, Order Management creates a set definition based upon current order line identifying attributes.

For additional information regarding set specific identifying order/line attributes, see the following:

Arrival Sets

Fulfillment Sets

Ship Sets

An order line may be in single or multiple sets and may also overlap partially or completely with a different set type within an order. For example, you may wish to ensure that all order lines for a Ship To location are included in an Arrival Set and that only some lines within the Arrival set are included in a Fulfillment set.
Sets cannot span multiple orders; sets are limited to the order for which they are created. Sets may, however, span multiple organizations and are either system or user controlled.
- System defined sets (inherent sets) are automatically created under certain conditions when order lines are saved. The sets are system controlled, and the set data encompassed by the system defined set may not be updated. System controlled sets are automatically created for order lines that contain ATO configurations and Ship Model complete PTO configurations.
- User defined Sets are the result of a request by a user to define a new set.
Set functions are unavailable for non shippable order lines.
When you perform any set function, order line scheduling always occurs for the line selected, and if the line is part of a set, scheduling always occurs for all lines within the set.

If successful, order line updates have been committed and are displayed within the Sales Order Lines, Shipping tab window.

If unsuccessful, an appropriate error message is displayed. No updates will occur. For example, suppose you wish to move an order line from arrival set ABC to arrival set CDF. The results of the insert may fail if the scheduled arrival date of the set ABC is earlier than the scheduled arrival date of CDF.
If the Latest Acceptable Date does not exceed the Infinite Supply Time Fence, then the Sales Order line will schedule depending upon the option selected for the latest Acceptable Date in the Scheduling flexibility.
Whenever you perform any set function, with the exception of defining a new set, Order Management enforces the following two conditions:
1. The set selected must be Active.
2. The order line you selected to perform a set function against must be able to inherit the identifying attributes of the set selected.
  
  Note: If you are defining a new set, Order Management will validate order line attributes entered or defaulted against existing set functionality.
  
  Note: For example, if you enter an arrival date and a scheduled ship date for an order line, and then attempt to define a new Arrival set, order line scheduling occurs. If the value entered in the Scheduled Arrival Date cannot be met due to scheduling errors, the request to define a new Arrival set for the order line will fail.
If you move or remove an order line from a set, and the order line is the only line within a set definition, the set definition is not deleted. The definition of the set can the be used to add/create order lines within the set definition, until the order is closed.

Note: When moving or removing an order line from a set, Order Management will automatically update the Wait workflow activity associated with any order line within the set that may be have been awaiting the completion for the line moved/removed from a set.
The data currently displayed within the Schedule Ship Date and Scheduled Arrival Date fields is not updated when you remove order lines from a set; you must perform the Unschedule function to update the data within these fields.

Note: You cannot unschedule an order line if it is part of set. If an order line is part of a set, and you wish to unschedule the line, you must remove the line from the set prior to unscheduling the line.
ATO configuration or Ship Model complete PTO model are always included in system defined sets. If either is included within a user defined set, both the model line and all option lines are automatically included in the user defined set definition, provided validation is successful.

If you remove a model or parent item from a set, all option lines are automatically removed from the set. To perform any set operations for a model is on the parent.
Order Management has validations to restrict functions against a set; once a set is defined, if any line within a set is shipped, the set is considered closed and the set definition cannot be modified.
If a set attribute changes for one order line within a set, then the attribute is cascaded to all order lines within the set. This results in a set definition update.
Group scheduling is a unit transaction: either all order lines within the set pass scheduling and are added to a set.

Line Splits

If a order line is generated as a result of a Split Shipment, and the original order line was within a Ship Set, then the application assigns a new ship or arrival set for the new order line generated based on the value of the OM: Assign New Set For Each Line profile option.

If there is a line in a ship set and a portion of the line is shipped, a new line will be created as a result of partial shipment, and the new line will be assigned to a ship set if the value of the profile option OM: Assign New Set for Each Line is set to Yes.
If there are two lines in a ship set and one of the lines is shipped completely then the second line is removed from the ship set. It is not be placed in a new ship set.

Note: The application creates and assigns set information for split standard lines, ATO Models, PTO Models, Kits, and Hybrid Models.

For more information, see the Order Management Profile Option Descriptions and Settings, Oracle Order Management Implementation Manual.

Cascading of Identifying Set Attribute Values

If the set function chosen by a user warrants cascading of data, Order Management will perform cascading of identifying set attributes to all order lines within a set.

Only set identifying attributes are cascaded when performing set functions. (Ship and Arrival sets only)
Cascading within set functions occur downward only (Ship and Arrival sets only).
If a system defined set is also part of a user defined set, all changes made to the user set are cascaded to system defined sets.

Scheduling and Ship Sets

Within Order Management Ship Sets, scheduling of order lines within the ship set occur after you have committed (saved) order lines.

User Procedures for Order Management Set Functions

To perform Set functions using the mouse Right click feature:

Note: Whenever you perform any set functions, the cursor is always returned to the first order line after completing the requested set function.

Note: For example, suppose you multi select order lines 4 through 6 from an order to add to an Arrival Set. Once you have selected the order lines and entered the Arrival Set name, the cursor is returned to order line 1.

From the Sales Order Line window, with your cursor on an existing order line, right click with your mouse, select Sets, then select the appropriate function from the sub menus displayed.
Select the appropriate set name from the LOV displayed for the function you are performing.

Note: You can define, move, or remove an Order line from a set by entering, updating, or deleting values within the respective Set name and date fields within the Sales Order Lines, Shipping Tab window.

Note: This is true for all sets fields with the exception of the Fulfillment Set field; this field is not enterable or updateable. You must perform any Fulfillment Set functions using the mouse right click feature.

Line Sets are used to group lines. Ship Set and Arrival Sets are based on similar dates: Ship Set (Schedule Ship Date) and Arrival Set (Schedule Arrival Date). Ship Sets can be enforced at the time of Pick Release. You can assign Ship Sets that will give a warning message at the time of Ship Confirm. The enforcement ensures that all lines assigned to the same Ship Set will not progress until each line in the set is ready. A line can either belong to a Ship Set or an Arrival Set at one time.

Ship Sets by definition are enforced by three attributes:

Warehouse

Ship To

Schedule Ship Date

An optional attribute that can be added to the Ship Set definition is Shipping Method. This is controlled by a profile option: OM: Enforce Shipping Method for Ship Sets A value of 'Yes' will add Shipping Method to the definition of Ship Sets. The default value is 'No.'

Note: The Line Set value at the header level can be defaulted from the following three locations: Ship To, Bill To, and Sold To.

Oracle Order Management currently provides functionality for users to add lines to Ship, Arrival, and Fulfillment Sets. Addition of lines to a Ship Set or Arrival Set without user intervention can be controlled at the header level. At the line level, lines can be added to Line Sets by specifying the Set Name manually on the line. Addition or removal of lines from Line Sets can be controlled with actions in the menus.

Line Level Ship/Arrive Sets

You can create one invoice per order using Fulfillment Sets. Arrival Sets can be used to coordinate the Schedule Arrival Date of lines that may have different Ship Methods. Ship Sets ensure that selected order lines have the same Schedule Ship Date.

Default The Line Set Field From The Order Transaction Type

The order transaction type determines whether or not the defaulting rules for Ship Sets, Arrival Sets, and Fulfillment Sets are activated.
The status of each Line Set determines when a line can no longer be added to the existing Set.
- Ship Set: status Closed (after Ship Confirm activity) if Shipping Parameter is set to enforce Ship Sets, then status would be Closed (after Pick activity).

Addition and Removal of Lines From Any Line Set Through Order Import and Process Order API

Order Import and Process Order API support the removal of a line from a Fulfillment set(s), and addition and removal at the same time to and from a Fulfillment set.

You cannot add or remove if a Line Set status is:
- Ship Set: status Closed (after Ship Confirm activity) if Shipping Parameter is set to enforce Ship Sets, then status would be Closed (after Pick activity)
- Arrival Set: status, Closed

Name Ship/Arrival Set On The Header

You can specify a name for the system generated Ship/Arrival Set on the header. The name cascades to the sales order lines. If a name is not specified, the system populates the sales order lines with the set number.

Arrival Sets

Arrival sets ensure all order lines within the set definition are scheduled to arrive at a customer site on the same date regardless of shipping method and ship to location. Arrival sets can:

Span multiple organizations, but are limited to the order for which they were created
Ship from different warehouses and ship on different days

All order lines within a Arrival Set must have the following identical identifying order/line attribute values:

Order Line Scheduled Arrival Date
Order Line Ship To Organization

If a new line is added to an existing arrival set, it must meet the conditions above or the request will fail. For example, a request to insert a line into an arrival set results in the schedule arrival date being inherited from existing lines within the set. You must first update the schedule arrival date on all the existing lines of the set and then you may add the line to the set definition.

If line scheduling or ATP check functions are performed against any order line within an Arrival set, the function will include all order lines within the set.

Note: Services (Extended Warranty and Subscription) can't be added to an arrival set.

To perform Arrival Set functions for an order line, see User Procedures for Order Management Set Functions.

Ship Sets

Overview

Ship Sets enable you to group order lines within a set for shipment. See Ship Set For Each Line

Ship sets ensure that all order lines within a Ship set do not progress past the Ship workflow sub process within respective line flows until all lines within the set have available quantity to ship. Ship sets are limited to order lines that contain the same following identifying order/line attribute values:

Ship From and Ship To Organization (a null value within either of these fields is not valid)
Scheduled Ship Date

Note: Services (Extended Warranty and Subscription) can't be added to a shipment set.

Ship Set Details

Since an order line can be assigned to multiple delivery lines but still remain within a ship set, Oracle Shipping Execution limits processing of Ship Sets to enforcing the grouping of order lines associated with a Ship Set definition, not the grouping of delivery lines generated or created for the order lines associated with the Ship Set definition.

Oracle Shipping Execution enables a user to override Ship Set functionality at pick release if you choose to leave the Enforce Ship Sets and Ship Models check box unchecked within the Shipping Parameters window, Pick Release Tab.

If you do not select the Enforce Ship Sets and Ship Models box, delivery lines for ship sets and ship models are not validated during picking (validated at Ship Confirm) even if the ship set is specified on order lines.

Note: Depending on your business needs, you must set up the Enforce Ship Sets and Ship Models parameter for each warehouse.
If you select the Enforce Ship Sets and Ship Models check box, delivery lines for ship sets and ship models are validated during picking. A warning message will appear if any line within the ship set is unavailable for picking, and a user can choose to override set functionality and process only lines available for shipping or accept the warning message and wait until all lines within the Ship set are available for picking. All order lines in the ship set will then either be released completely or auto-backordered during pick release. If any portion is not available, then all lines in the ship set are backordered.

When you create the order, you must specify if you want to retain (or not retain) the ship set for the back-ordered lines. You can do this in the Sales Order window in Order Management.

Note: Ship sets for non-transactable delivery lines are validated during ship confirm. However, a ship set for non-transactable delivery lines is not validated during pick release because the item(s) are not picked from inventory.
If you define an order line for a configured product as a ship set, Order Management waits until all items in each configuration are available before releasing the line for picking.
A line that is in a ship set but is not processed during shipping is placed in a derived ship set. Order Management will pass all lines in a ship set together to Oracle Shipping Execution, whether the line is eligible to ship or not. If a line is not eligible, Order Management will also pass a reason why the line is not eligible.
Lines that are either not processed by Oracle Shipping Execution or lines that need to be split (due to partial processing) at the time of shipping are placed into new ship set.
You can add lines that have different release statuses to a ship set. The release statuses of lines that you can add to a ship set are Staged and Released to Warehouse. If the line status is Closed, you cannot add the line to a ship set.

Splitting Ship Sets

Split

If a line that is a part of a ship set is split by the system, you will receive a message informing you of the split. When the Ship Confirm process is initiated, the split line is removed from the original Ship Set and will not be automatically assigned to any Ship Set.

To perform Ship Set functions for an order line, see Line (Ship or Arrival) Sets.

Order Line Scheduling and Ship Sets

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 when they are added to a set. The default value of the system parameter is Yes and the application treats no value as Yes.

For more information on the OM: Auto Schedule Sets system parameter, see the Seeded System Parameters section in the Oracle Order Management Implementation Manual.

If you group order lines into Ship Sets automatically or manually and one of the order lines Latest Acceptable Date exceed the Infinite Supply Time Fence for the item, the order line will not schedule, nor will any order lines within the Ship Set be scheduled.

If the default Order Header value for Sets is not set to Ship (determined by the value of Line Sets Check box, Order Management tab within the Customer window), and you manually group order lines within sets, Order Management will attempt to schedule all order lines within each set based upon your ATP setup. If any line within a set fails scheduling for any reason (such as an incomplete item setup), Order Management will display an appropriate error message and not generate a set for all order lines that you attempted to place in the same set as the failed line.
If the default Order Header value for sets is set to Ship, and the profile option, "OM: Assign new set for each line," is set to "N," Order Management will automatically determine the earliest Scheduled Ship Date, based upon your setup, and create a common ship set for all order lines. If the automatic set routines fail for any reason (such as an incomplete item setup), a Ship Set is not generated and you will manually need to add order lines to a Ship Set.
If the default Order Header value for sets is set to Ship, and the profile "OM: Assign new set for each line," is set to Yes, Order Management will automatically determine the earliest Scheduled Ship Date, based upon your setup, and create a unique ship set for each line in an order. If the automatic set routines fail for any reason (such as an incomplete item setup), a Ship Set is will not be generated for that particular order line(s) and you will manually need to add the order line(s) to a Ship Set.

Order Management additionally provides a concurrent program which, when submitted, will attempt to reschedule all lines within Ship Sets. Use this concurrent program to reschedule Ship Sets, based upon real-time supply and demand, to ship earlier than the current date scheduled. See: Ship Sets, Re-Schedule Ship Sets concurrent program.

Additionally, the following details assist with the control of creating Ship Sets:

The Latest Acceptable Date must be set to exceed the Infinite Supply Time Fence for the largest lead time item of the order
Oracle Shipping Execution Parameters must be set to enforce Ship Sets
The Order Management profile option, OM: AutoPush Group Date must be set to Yes
AutoSchedule is off

For example, suppose you had the following supply details within the following table for order number 123:

Example of Supply Details
Item	On Hand	Supply Date	Infinite Supply = 6 months	Latest Acceptable Date = 7 months
A	20	7 Nov 2001	120 days	140 days
B	100	7 Nov 2001	120 days	140 days
C	10	WIP order on 20 Nov 2002	120 days	140 days
D	0	No supply scheduled = infinite	120 days	140 days

For order 123:

No Ship Set is entered manually on the lines at the time of order entry.
When saving, the system assigns and populates the Ship Set Name.
The system looks at ATP availability for all order lines when ATP is applicable, and schedules the order lines for the Ship Set to the latest acceptable ATP date.
If scheduling fails to meet a common date then the order lines are saved, but will not scheduled or assigned to a Ship Set. (This occurs only if the Latest Acceptable Date does not exceed the Infinite Supply Time Fence)

The scheduling details for order 123, after the initial save was performed are displayed within the following table.

Example of Save Performed
Order Line	Item	Qty	Request Date	Schedule Date	Ship Set
1	A	20	7-Nov-2001	7-May-2002	1
2	B	20	7-Nov-2001	7-May-2002	1
3	C	20	7-Nov-2001	7-May-2002	1
4	D	20	7-Nov-2001	7-May-2002	1

Now, if two additional lines are added to the order, the system will assign and populate the Ship Set, once the order is saved.

The system again verifies ATP availability, and will auto push the entire group (order lines), scheduling the lines for the Ship Set to the latest ATP date. If scheduling fails to meet a common date then the two new lines will be saved, are not scheduled, and will not be assigned to a Ship Set (Latest Acceptable Date is greater than the Infinite Time Fence).

The following table displays the scheduling results after adding two additional order lines.

Example of Scheduling Results
Order Line	Item	Qty	Request Date	Schedule Date	Ship Set
1	A	20	7-Nov-2001	7-May-2002	1
2	B	20	7-Nov-2001	7-May-2002	1
3	C	20	7-Nov-2001	7-May-2002	1
4	D	20	7-Nov-2001	7-May-2002	1
5	D	20	7-Nov-2001	7-May-2002	1
6	D	20	7-Nov-2001	7-May-2002	1

After scheduling, order lines are now within a single Ship Set (1), but the schedule date is significantly pushed out. If item D is available much earlier than 7 May, then the shipment may not have to wait until the scheduled date. Choose to accept the current scheduled date, or to submit the Re-Schedule Ship Sets concurrent program to try to re-schedule the order lines to the earliest finite supply date.

The new concurrent program Reschedule Ship Sets takes the following parameters to derive the criteria to pick lines.

Ship Set Name
Sales Order Number Low
Sales Order Number High
Number of days from current date (Start)
Number of days from current date (End)

If the item D is now available for December 10, 2001, the status of order 123 (listed blow with Table 4) will be as follows after submitting the Re-Schedule Concurrent program, assuming the request is run with parameters of Order number low - 123, Order Number High - 132, Schedule Ship date - 7-May-2002, Min. days - 0, Max days - 0 Ship Set Name - 1.

Example Status Results
Order Line	Item	Qty	Request Date	Schedule Date	Ship Set
1	A	20	7-Nov-2001	10-Dec-2001	1
2	B	20	7-Nov-2001	10-Dec-2001	1
3	C	20	7-Nov-2001	10-Dec-2001	1
4	D	20	7-Nov-2001	10-Dec-2001	1
5	D	20	7-Nov-2001	10-Dec-2001	1
6	D	20	7-Nov-2001	10-Dec-2001	1

See:

Re-Schedule Ship Sets Concurrent Program

For additional information regarding the functionality and usage of Order Management Set types, refer to

Arrival Sets

Fulfillment Sets

Ship Sets

Shipment Schedules

If your customers place orders requiring multiple shipments over time, you can split the order line rather than enter separate order lines.

Once you have split a line into multiple shipments, you have access to them through the Line Items tab in the Sales Orders window. You can modify them like you would an order line.

If you split a model line into shipments, Order Management duplicates everything beneath the model to each shipment schedule. With PTO configurations you can change the options for that shipment schedule until the individual shipment schedule has been ship-confirmed. For example, your customer has a sales agreement order to ship 100 configurations each month for the next six months. After three months you no longer support one of the options they chose, and they still have three months' worth of shipments outstanding. You can update the remaining three shipment schedules, removing the obsolete option.

If you schedule shipments for multiple request dates, Order Management automatically manages the release of the shipment schedules. Order Management only releases the shipment schedule lines which match your pick-release criteria. For example, if two shipment schedule lines exist with request dates of 31-MAY-2000 and 31-OCT-2000 and you release orders with request dates through 31-MAY-2000, Order Management automatically checks the dates and releases only the first shipment schedule line.

To define shipping information for a shipment schedule:

Navigate to the Shipping tabbed region.
Enter address information for the shipment schedule's final destination.
Select the Shipment Priority for the order line.

Note: Shipment priority enables you to group shipments into different categories of urgency, and can be used as a parameter for Pick Release. You can define additional shipment priorities in the Order Management QuickCodes window.
Select the Freight Carrier.

Note: The freight carrier can be used as a parameter for Pick Release.

To define project information for a shipment schedule:

Navigate to the Project tabbed region.
Select a Project Number.
If you chose a Project Number, select a Task Number.

To modify or define release management line information for an shipment schedule:

Warning: You must have Oracle Release Management installed to access this region.

Navigate to the Release Management tabbed region.
Enter the Customer Job number.
Enter the Customer Production Line.
Enter the option's Customer Model Serial Number.
Enter the Customer Dock to which the item will be delivered.
Select an Intermediate Ship To Location from the list of values.
Enter the Planning Production Sequence number.
Navigate to the Industry Information descriptive flexfield.
The Additional Industry Attributes window appears.
Save your work.

Information Retention Across Shipments when a Line is Split:

Attachments

For User Initiated Splits - If OM: Apply Automatic Attachments profile is set to Yes and you have not changed the Ship To for the line, then the application copies automatic and manual attachments for the new line. If the profile is set to Yes, but you have changed the Ship To for the new line, then the application automatically applies the attachments based on the attachment addition rules and creates a copy of the manual attachments for the new line. For the original line, the application retains the original automatic and manual attachments. If the profile is set to No, then the application duplicates the manual attachments when you split the line.

For further information regarding attachment addition rules, see Define Attachments, Oracle Order Management Implementation Manual. Additionally, see Profile Options in Oracle Order Management Setup, Oracle Order Management Implementation Manual.

For System Initiated Splits - Both manual and automatic attachments are duplicated.

Discounts/Surcharges/Freight Charges

Surcharges and freight charges are handled in the same manner as adjustments.

Holds

Non- released holds are duplicated when a line is split. Changing attributes on the new split line will result in re-evaluation of hold source application rules.

Sales Credits

Line level sales credits are duplicated when a line is split.

Status Information

Line workflow status information is duplicated when a line is split. The new split line has a flow of its own. The new line will be in the same point in its flow as the original line it split from.

Reservations

These are split when a line is split, provided the scheduling attributes remain the same.

Tax

This is re-evaluated when a line is split.

Common attributes across shipments originating from a Line Split

Order Management creates a line set when you split a line. All the shipments that originate from the original line belong to the same line set. Line sets are created only for the standard item lines and top-level lines in configurations and kits.

Order Management ensures that the following attributes are common across all shipments in a Line Set:

Ordered Item
UOM
Over and Under Shipment Tolerances

Splitting lines in the background for configurations

You can split lines in the background using the concurrent request Split Configuration in the sales orders window. This applies to ATO Models, PTO configurations and Kits. The Defer Split box in the Split Line action window enables you to split configuration lines in the background and continue with other actions on the sales order. The Defer Split box is enabled only for ATO Models, PTO configurations and Kits. When you select the Defer Split box and click Split, the concurrent program Split Configuration splits the lines as a background process. This improves performance and you can also continue working in the sales orders window. You need to requery the lines to see the result of the line split.

Defer Split in the Background

the picture is described in the document text

If you require to cancel the Split Configuration concurrent program, you can use the Cancel Split Configuration action from the order line. You can cancel the line split process only if the concurrent program is in progress. When the Split Configuration concurrent program is running for a particular line, you cannot initiate further splits on that line, otherwise the following message is displayed:

An active Split Configuration request with id &REQUEST_ID exists. The line cannot be split at this time

Fulfillment Sets

Background

Order Management provides the functionality required to recognize fulfillment of an order or order line. One of the key features of fulfillment is to ensure order lines are invoiced together, and not separately.

Overview

A Fulfillment set is a group of sales order lines with common attributes which must be fulfilled together. Any order line which is part of a fulfillment set can not progress past the Fulfill Activity within it's flow until all lines of the fulfillment set have completed their respective Fulfill activities.

Order Management utilizes the Fulfill workflow activity to ensure order fulfillment.

You can use the seeded Order Management workflow processes and activities to provide baseline functionality for sales order, drop ship and return lines. The functionality is also designed to allow you the flexibility to define other activities as fulfillment methods so that you can model your unique business processes.

Note: Standalone subscription lines can be added to a fulfillment set but extended warranty lines can't be added to a fulfillment set.

Key Functions

A order or order line can be considered fulfilled based upon many different events. Within Order Management fulfillment functionality is controlled by the workflow activity Fulfill.

An order is considered fulfilled when the Fulfill workflow activity has successfully completed.

Note: All lines within a fulfillment set must have the Fulfill workflow activity included in its' order line flow.

There are two activities which are considered fulfillment method activities (workflow item attribute) in the seeded Order Management workflow process. For a standard shippable line, the fulfillment method activity is the Shipping activity. For a return line the fulfillment method activity is the Receiving activity.

You may define any activity as the fulfillment method activity in a workflow process. The fulfillment activity must be prior to the Fulfill workflow activity in each respective workflow you define.

When a line workflow reaches the fulfillment activity, a call is made to determine if the fulfillment method activity (Shipping or Receiving) completed successfully. If so, the fulfilled quantity on the line is updated to either the shipped, ordered, or received quantity, and the fulfilled flag is set to Yes. The workflow then checks to see if the line is part of a fulfillment set.

If the line is not part of a fulfillment set, then it completes the fulfillment activity and continues with the next activity in the workflow process.
If the line is part of a fulfillment set, it checks to see if the other lines in the fulfillment set are fulfilled.
- If any lines are not fulfilled, the order line waits at the fulfillment activity.
- If all the lines are fulfilled it completes the fulfillment activity for all the lines in the fulfillment set.

Fulfillment Set Details

You can remove a line from a fulfillment set. However, a line can not be added to or removed from a fulfillment set if the line is fulfilled.
A line can not be added to a fulfillment set if any of the existing order lines within the set has been fulfilled.
If there are two fulfillment sets defined for an order which have some lines common between the sets, none of the lines will progress beyond fulfillment until all the lines are fulfilled. For example, if fulfillment set F1 has lines 1, 2, and 3, and fulfillment set F2 has lines 3, 4 and 5. Any of the lines 1,2,3,4 and 5 will not progress beyond fulfillment until all the lines 1, 2, 3, 4 and 5 are fulfilled.
If a line is part of a fulfillment set and you have the Fulfill Activity with an order line's process flow, no lines of the configuration process past the fulfillment activity until all lines within the fulfillment set have been fulfilled.

Note: Partial fulfillment of a fulfillment set is not supported. If partial fulfillment of an order line, which is part of a fulfillment set, takes place, the split line will also be placed in the same fulfillment set with the original line and the fulfillment set will not be fulfilled until the newly created line is fulfilled.
You can have multiple fulfillment sets in a single order. If a line is a member of two fulfillment sets then all lines from both fulfillment sets must be fulfilled for any of the lines to complete the fulfillment activity.
If a order line workflow process with notification is in a fulfillment set and the notification is rejected, then other lines within the set will not progress within their respective flows. Manually delete or cancel the rejected line unless a re-approval process has been incorporated into the order line flow; in this case, either re-approve the notification or delete or cancel the rejected line.
If there are no lines assigned to the fulfillment set, or if assigned lines are deleted, the fulfillment set automatically closes.

To perform Fulfillment Set functions for an order line, see User Procedures for Order Management Set Functions.

Automatically Assign All Lines Of An Order To One Fulfillment Set

You can have all lines of an order invoice at the same time. One way to achieve this is through fulfillment sets. Instead of typing in the Fulfillment Set Name for each line in the order, you can automatically assign all lines of an order to a fulfillment set. You can control this at the order level as well as use defaulting rules based on Customer, Ship To, Invoice To, and Order Transaction Type. The default at the header level populates the value at the line level.

When a line is added to an existing order, that line is populated with the default Fulfillment Set value unless the status of the existing Fulfillment Set is Closed. If the status of the existing Fulfillment Set is Closed, then all new lines added to the existing order will not be assigned to a Fulfillment Set.
- An error message alerts you that the line cannot be added to the existing Fulfillment Set because the Fulfillment Set is Closed.
The default Fulfillment Set value can be manually overridden.

Note: Service line added to a fulfillment set are fulfilled once the parent line is fulfilled.
- Arrival Set: status, Closed.
- Fulfillment Set: status, Closed (after Fulfill activity).
You can define a Transaction Type definition to determine whether the lines can be added to a fulfillment set automatically for a specific transaction type.
- Lines can be added to multiple Fulfillment Sets
Default Line set (Ship or Arrival) is automatically defaulted for specific Transaction type.

Addition and Removal of Lines From Any Line Set Through Order Import and Process Order API

Order Import and Process Order API support the removal of a line from a fulfillment set, and addition and removal at the same time to and from a fulfillment set.

Fulfillment Set: status, Closed (after Fulfill activity) Name Fulfillment Set On The Header

Using the Fulfillment Set check box available in the Others tab at order header, you can state on the order header whether or not you want the lines automatically placed in the fulfillment set.

You can specify a name for the system generated fulfillment set on the header. The name cascades to the sales order lines. If a name is not specified, the system populates the sales order lines with the set number

If you select a fulfillment set at the header level, order based service lines are added into the fulfillment set when the line it is associated with is already part of the fulfillment set. This will be fulfilled only after the parent line is fulfilled.

User Procedures

Oracle Order Management provides the choice 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 N creating one Ship/Arrival Set per order. As an example, if the header level choice is Ship, then all successfully scheduled lines, will automatically go into one ship set when created.

It is important for other businesses that a single line ship complete and multiple shipments are allowed per order. By setting the profile to Y, the system creates a unique Ship/Arrival Set for each line in an order if the line can be scheduled.

Fulfillment With Wait

Fulfill Line Workflow

The Fulfill Line workflow activity in Order Management indicates:

The workflow activity in the order line workflow that is used as the fulfillment activity.
The desired completion result of the fulfillment activity.

At the Fulfill Line workflow activity, Order Management checks to see if the fulfillment activity for this line is completed with the desired result (i.e. ship confirm). If it has, then the Fulfill Line activity is completed and the order line is marked as fulfilled.

Note: During the order line fulfillment phase, the application raises the oracle.apps.ont.oip.statuschange.update business event if profile OM: Raise Status Change Business Event is set to Yes.

Shippable Versus Non-Shippable Line Fulfillment

In order to block the fulfillment of non-shippable lines as and when they are booked, the seeded flows - Line Flow - Generic, Bill Only with Wait to Fulfill and Line Flow - Generic, Bill Only with Payment Assurance and Wait to Fulfill can be used on an order line by creating the line type assignments to an order type using the Transaction Types window. These flows can be assigned to Standard items, ATO Classes, ATO options, PTO Classes, PTO options, Kits, and Included items. For more information on the Transaction Types window, see: Oracle Order Management Implementation Manual.

After booking, the lines using these flows pass through a block activity. Lines with standard items, shippable items of Models, Kits, and Service lines that refer to a line in another order are blocked at this activity and wait for the user to progress the lines manually using Actions > Progress Order. The non-shippable lines of Models, Kits, and the service lines referencing another line in the same order are not blocked because the lines wait for the fulfillment of the dependent shippable lines.

In general, shippable lines use the Ship Line workflow activity as a fulfillment activity and ship confirm as the completion result.

Important: It is not mandatory to have ship line as fulfillment activity for shippable lines.

Non-shippable lines (such as lines with Bill Only workflow, Service, etc.) on the other hand, do not have any obvious fulfillment activity. Fulfillment of these lines is usually dependent on fulfillment of some other shippable lines in the order or is handled outside the Order Management system. When an order is booked, shippable lines wait at the Ship Line activity for actual shipment before transitioning to the Fulfill Line activity. However, non-shippable lines immediately reach the fulfill line activity. In absence of any fulfillment activity, the Fulfill Line is completed.**

Note: **The only exception to this is if the lines are in a fulfillment set.

Seeded Workflow Sub-process

Some businesses may want to hold the fulfillment of shippable lines even after the lines are actually ship confirmed. The seeded workflow sub-process called Wait to Fulfill Line can be added before the existing Defer Fulfillment and or Fulfill Line functions.

Wait to Fulfill Line Workflow

the picture is described in the document text

Check Wait To Fulfill Line

The workflow order line will reach the Check Wait To Fulfill Line function after it is scheduled and shipped (for shippable lines only).

This feature by default returns one of two values:

No for all shippable lines and all lines that are part of a configuration and service lines referencing a shippable order line in the same order. These lines will go to 'defer fulfillment' as in a workflow without this sub-process. Fulfillment functionality has special processing to handle non-shippable lines in a configuration and service lines with reference to the same order. These lines do not need an additional wait.
Yes for non-shippable order lines excluding the type of non-shippable lines mentioned in point 1. In this case, the order lines will wait at the Fulfill Line Eligible block. Completion of this block will be decided by your business process.

Note: You can copy the sub-process Wait to Fulfill Line. You can write a procedure to handle the copied check_wait_to_fulfill_line function so that it returns a value of Yes for order lines eligible for delayed fulfillment specific to your business requirement.

A procedure is provided to:

OE_Fulfill_WF. Complete_Fulfill_Eligible_Block. This will complete the block Fulfill_Line_Eligible when called from a custom fulfillment solution outside Order Management. You can use it when the lines are fulfilled per your business process and when to progress them to fulfillment.
Additionally the block (wait) can also be completed using the Sales Orders window, Action > Progress Order.

Note: There is no seeded concurrent program to complete the Fulfill_Line_Eligible Block. This is because every business may have a different event or process function to decide whether to transition to defer fulfillment or not.

Ship Set For Each Line

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 will be set to "N" thus creating ONE Ship/Arrival Set per order. As an example, if the header level choice is Ship, then all successfully scheduled lines, will automatically go into one Ship Set when created.

It is important for other businesses that a single line ship complete and multiple shipments are allowed per order. By setting the profile to "Y," the system will create a unique Ship/Arrival Set for each line in an order as long as the line can be scheduled.

This ensures that all lines assigned to the same Ship set will not progress until each line in the set is ready. Fulfillment Set groups lines by activity, (Ship or Return) that aids in sending lines to Invoicing together. A line can be in multiple Fulfillment sets and can also be added to a Ship or Arrival set.

Note: A Line can either belong to a Ship Set or an Arrival Set at one time.

Ship Set for Each Line Major Features

Arrival Sets coordinate the Schedule Arrival Date of lines that may have different ship methods.
Ship Sets are used to ensure that selected order lines have the same Schedule Ship Date. This creates informal consolidations of lines with the same ship method.

You can choose if a line goes to either the Ship set or Arrival set by setting the line set field at the header level. If the choice is Ship then all successfully scheduled lines, will automatically go into one Ship set when created. Similarly, if the choice is Arrival then all successfully scheduled lines, will automatically go into one Arrival set when created.

This functionality will place each line in a new set (Ship or Arrival) if the line can be scheduled.

Lines that have been grouped into a Ship set have the same Schedule Ship date, Ship From, and Shipping Method. If you try to change one of these fields, the system will not allow a change until the line has been removed from the Ship set. An error message advises you that the system will remove the line from the Ship set if you wish to proceed with the change to the Schedule Ship date, Ship From, and/or Ship To.

The error message: Changing the Schedule Ship date, Ship From, Ship To will remove the line from the Ship set. Do you wish to proceed? (Y/N)

You can use the same ship set name across orders. The ship set names are mapped to ship_set_ids which are unique to each ship set.

User Procedures

Oracle Order Management has enhanced the choice of header level Ship/Arrival Set functionality. The profile, OM: Assign new set for each line, provides two alternatives:

To Set a default line set for a specific transaction type:

Navigate to the Transaction Types window.
Setup Default Line set as Arrival Set for Transaction Type Standard.
Save your work.
Navigate to the Sales Orders window.
Create an order with the Transaction Type Standard. The Line Set will be defaulted with the value Arrival.
Add lines to the sales order.
All the lines will be added to arrival set automatically if the line can be scheduled for the set date or based on the auto push group date profile, the entire group will be pushed for rescheduling to obtain a common date.

If the Default line set is setup as Ship Set then all the lines will be added automatically to ship set.
Save your work.

To include lines in a Fulfillment Set automatically:

Navigate to the Transaction Types window.
Setup Default Fulfillment Set for Transaction Type Standard as Yes.
Save your work.
Navigate to the Sales Orders window.
Create order with Transaction Type Standard. The default Fulfillment Set will be defaulted with the value Yes.
Add Lines to the sales order.
All lines will be added to Fulfillment set if specified on the header or is system generated Fulfillment set automatically.

To set defaulting rules for defaulting ship or arrival set:

Navigate to the Defaulting Rules Setup window.
Setup Defaulting rules for: Customer, Ship To, Site etc. with a sequence specified in which the order Line Set is defaulted.
Save your work.
Navigate to the Sales Orders window.
Create an order with the Customer Line Set that defaults with value Arrival or Ship depending upon the defaulting rules.
All the lines will be added to a ship set or arrival set automatically if line can be scheduled for the set date or else based on the auto push group date profile, the entire group will be pushed to obtain a common date.

To add promotional (get) items to a ship or arrival set:

Use the site level system profile option OM: Line Set for Promotional Items to include promotional (get) items in a Ship/Arrival set, together with buy items. The promotional item is assigned to the Ship/Arrival set based on the profile option value as follows:

If the value of the profile option is Always, the following scenarios may occur for all operating units:
- If the buy item on the sales order line already has a value in the ship set or arrival set (added manually or assigned automatically), then the promotional (get) items are assigned to the same set.
- Otherwise, if the buy item on the sales order line does not have an assigned ship set or arrival set (regardless of the line set value on order header), create a ship set, and assign the ship set to both buy and get items.
If the value of the profile option is Modifier Setup, the Pricing modifier setup will be referred for evaluation on item to item basis. In the pricing call, Order Management can receive the Line Set value as any of the following:
- Yes - The following scenarios may occur for all operating units:
  
  If the buy item on the sales order line already has a value in the ship set or arrival set (added manually or assigned automatically), the promotional (get) item is assigned to the same set.
  
  Otherwise, if the buy item on the sales order line does not have an assigned ship set or arrival set (regardless of the line set value on order header), create a ship set, and assign the ship set to both buy and get item.
- No/Blank – Buy item and get items will not be assigned to a default Ship/Arrival set.
If the value of the profile option is set to Null/No/Blank, buy item and get items are not assigned to a default Ship/Arrival set. This is the default value.

Note that the Ship/Arrival sets can be assigned to Standard, Model, or Kit line types only, therefore, the Ship set is created automatically only for these line types, and the buy and promotional item are added. The system does not create ship/arrival sets where the line type of the buy item is Option, Class, or Included Item.

For more information on the Pricing related functionality, see: Modifiers in the Pricing chapter.

Project Task Changes for Booked Orders Overview

Oracle Project Manufacturing functionality allows an organization to plan, schedule, process and cost material and labor against a specific customer contract. Project Manufacturing as a process touches most of the products in the Oracle e-Business suite including Oracle Order Management. Oracle Order Management captures Project/Task information on the sales order lines, shipments, and options, both online using the Sales Orders window and in batch mode using the Order Import concurrent program. It also captures End Item Unit Number for Model/Unit Effectivity for controlled items. This information is used for integration with Oracle Project Manufacturing.

A seeded constraint still prevents changes to the project and task number after booking, but this constraint can be deleted. This allows more flexibility when working with project manufacturing information. Additional seeded system constraints (which cannot be deleted) prevent changes in the following situations:

For Order Lines:

The shipped quantity is not Null.
The line is Invoice Interfaced.
The item is Pick Released.
The Inventory Interface workflow activity has been completed.

This activity is used in the non-ship cycle and its completion would signal that an item has been distributed (and so, the inventory needs to be updated). At that point no more updates to the project/task of that line are allowed.
The Purchase Release workflow activity has been completed.
An ATO item has been ship notified.
The configuration line on an ATO model has been ship notified.

For Return Lines:

The line has been booked.

Projects are specific to a warehouse, or inventory organization. When you update either the warehouse or the project so that the result is an invalid warehouse/project combination, an error message appears. Scheduling will not update the warehouse if there is a Project on the line. The LOV will show the warehouses that are valid only for the Project entered.

If an order line is rescheduled after booking, the warehouse is passed to Global Order Promising, which checks the availability of material only in that warehouse.

Updates on Split Lines

If you attempt to change/update the project/task on any one of the split lines and save the line, you receive the message requiring the project and task be updated on all the split lines.

To update the project/task, you can manually change each of the split lines and then save or select all the split lines and use the mass change feature to update the project/task.

Task Validation

You can specify those Tasks that have been setup in Oracle Project Manufacturing against the Project entered on the sales order line. Any change to the Project information will clear the Task field. Tasks may not be specified unless a valid Project has been first entered. E.g. If Project P1 has two tasks T1 and T2 associated to it and Project P2 has tasks T3 and T4, an entry of P1, T1 is valid. If however, the Project is now changed to P2, the Task field is cleared and it only accepts T3 or T4 as a valid Task number.

All options under an ATO Model or a hybrid ATO within a PTO model have the same Project and Task as the one specified on the model line.

Project Task Changes for Booked Orders Major Features

Sales Orders Window

Searching for Orders and Order Lines by Project and Task

Use the Find window on the Sales Orders window to search for orders or order lines that have one or more lines with the Project and Task specified in the search criteria. You can use Project and Task number as search criteria only if Oracle Project Manufacturing has been installed.

Entering Project and Task on Sales Order Lines

Use the Sales Orders window or Schedule Orders window to input the Project and Task information for a sales order line. You can enter this information when:

Project Manufacturing product is installed at the site.

The Warehouse on the line is set up as Project Enabled in Oracle Inventory.

Defaulting Project and Task Information

The Project and Task specified on an order line is defaulted to all its child shipment lines. If the order line is a model, the Project and Task defaults to all options specified for the model.

Cascading Project and Task Information

If the Project and Task information is updated, this information is cascaded. The information cascades to all child shipment lines from an order line and to all options from the model line.

Entering End Item Unit Number for a Model/Unit Number Effectivity Controlled Item

Use the Sales Orders window or the Schedule Orders window to input the End Item Unit Number for a sales order line. You can enter this information only when:

Project Manufacturing product is installed at the site.
The Warehouse on the line is set up as Project Enabled in Oracle Inventory.
The item is under Model/Unit Number Effectivity Control.

Validating Project and Task Information

Project and Task information is validated for the following:

Only active Projects and Tasks may be specified.
Only those Projects may be specified that are associated with the customer on the sales order. This may be optionally enforced.
A Task cannot be specified unless a Project has been.
If the Project Control Level for a line warehouse is setup to be a Task, and if a Project is specified for the order line, the Task must also be specified before the order is booked.
All options under an ATO model or a hybrid ATO within a PTO model have the same Project and Task as the one specified on the model line.

Validating the End Item Unit Number for Model/Unit Number Effectivity Controlled Item

End Item Unit number is validated when:

End Item Unit Number is validated against the table
End Item Unit Number cannot be changed once the order is booked

User Procedures

To query an order based on project and task:

Navigate to the Sales Orders window, and choose the Find icon.
Enter all or any of the following query criteria:

Project Number

Task Number
Click Find.

Find Window - Line Information Tab
View the orders returned by the entered query criteria.

To enter the Project, Task, and End Item Unit Number:

Navigate to the Sales Orders window.
Enter the order information, then choose the Lines tab.
Enter all required line information, then choose the Others tab.
Enter the Project, Task, and End Item Unit number.
Save your work.

To update the Project, Task, and End Item Unit Number:

Navigate to the Sales Orders window.
Query the line to update.
Select the Others tab.

Sales Orders Window - Others Tab
Update the appropriate field.
Save your work.

Seed Data Changes

Constraints for Project and Task

The seeded constraint that disallows updates to the Project and Task after booking, is not system seeded so you can delete it based on your implementation.

The following new conditions are seeded system constraints and cannot be changed:

Order Lines:

No Update to Project and Task if the shipped quantity is not Null
No Update to Project and Task if the line is Invoice Interfaced
No Update to Project and Task if the item is Pick Released
No Update to Project and Task if the Inventory Interface workflow activity has been completed
No Update to Project and Task if the Purchase Release workflow activity has been completed
No Update to Project and Task if an ATO item has been Ship Notified
No Update to Project and Task if the configuration line of an ATO model has been Ship Notified

Return Lines:
No Update to Project and Task if the line has been Booked

Messages

Name: OE_VAL_PROJECT_REQD

Message: Project is required, when task is not null.

Purpose: Validation Purposes. This message displays when you create a line with a task and without a project.

Name: OE_VAL_PROJ_UPD

Message: Project is not updatable when class/option is within ATO model.

Purpose: This message displays when you update a Project on a class or option that belong to an ATO model.

Name: OE_VAL_TASK_REQD

Message: Project control for warehouse is set to TASK. The project references must consist of both Project and Task.

Purpose: This message displays when a project is not null and a task is null and the control is set to task.

Name: OE_VAL_TASK_UPD

Message: Task is not updatable when class/option is within ATO model.

Purpose: This message displays when you update a Task on a class or option that are belong to an ATO model.

End Customer

This functionality addresses the following:

Businesses want to know the end customer for an order line for a number of reasons, for example, who is entitled to product support? Who is entitled to sales credits? Who is the user of sold items?

Note: The Sold To customer/Partners can return items for either credit or repair.

If using Partner Order Processing, it is typical for a partner to sell to a number of End_Customers. You can consolidate sales to multiple end customers on a single order.

If the end customer is specified when taking the order, it is possible for the system to automatically populates Install Base with the correct end customer, streamlining the integration of Order Management and Install Base.

If a business uses Service Contracts, you can create one Service Contract from the sales order. This feature is useful if the Sold To customer / Partner owns the Service Contract for multiple end customers. (You cannot create multiple Service Contracts for multiple End Customers on a single sales order.)

This functionality is appropriate for those who:

Use Install Base for product support.
Use Service Contracts for support contracts
Want a better understanding of the sales channels used in their marketplace, i.e. who are the customers of Partners and for the End Customers
Split sales commissions between partners and End Customers

End Customer Major Features

Specify the End Customer on the Sales Order Header and/or Line

There are columns on the Sales Order window, at both the header and line level, for users to specify attributes for the end customer in Install Base. You can set flags to specify the Owner, Install At Location, and Current Location in Install Base.

Line Level Independence

Each line on the order can have a different end-customer.

Orders Referencing Agreements Support End Customers

Orders that reference Sales Agreements or pricing agreements can specify end-customers, both at the header and at the line.

End-customer functionality is supported on both the standard and the Quick Sales Orders windows.

End-customer functionality is supported on both the standard Order Organizer, and the Quick Order Organizer. You can query by end customer, and also view the end customers.

Ship to Either the Partner or the End Customer

You can ship to either the End customer or the Partner/Sold-to customer. Additionally, if shipping to the End customer, the End customer party name displays on the Bill of Lading.

Default the Appropriate Owner into the Install Base

You can default the appropriate owner to Install Base. In some situations, the owner may be the Sold To customer. In other instances, the owner may be the End customer.

Identify the Install At Location / Current Location

You can identify the locations of both the Current Location and Installed At Location. The location of the end customer may be used as the Installed At or Current Location.

Default the Current Location into Install Base

You can default the Current Location to Install Base. The current location could be the ship_to, End_Customer, deliver_to, sold_to, or – in rare cases – the bill_to location.

Default the Installed Location into Install Base

You can default the Installed Location to Install Base. The Installed Location can be the ship_to, End_Customer, delivery_to, sold_to, or bill_to location.

Default the Sold_To to Customer for Service Contracts

You can default the Sold To customer to Service Contracts.

Import Sales Credits Split Based on the End-customer

If an end customer is specified, you can split the sales credit, i.e. give 50% to the sales rep associated with the End Customer, and 50% to the sales rep associated with the Sold To Customer. You can import the split sales credits from iStore, or using standard Order Import.

Import End-customer Attributes

Standard order import supports the end-customer attributes. EDI and XML are not supported at this time.

You can create one Service Contract per sales order. The Sold To Customer (Partner) on the header is passed to Service, and one Service Contract can be created.

The End Customer, Location, and Contact mean the following:

End Customer: The ultimate recipient of the benefits of the good(s) on the order.
End Customer Location: A site of the End Customer, with a business purpose of Sold To, Ship To, Deliver To, or Bill To.
End Customer Contact: A contact of the End Customer, with a role of Sold To, Bill To, Ship To, Deliver To, or with no role.

New Order / Line Attributes: IB Owner, Installed Location, and Current Location

The owner of an item in IB can be either the sold-to customer (partner) or the end-customer. The values for the IB_Owner flag in Order Management are restricted to:

Sold To Customer
End Customer

For the End Customer Location, any of the following business purposes are available.

Ship-to
Deliver-to
Sold-to
Bill-to

Constraints

There are constraints that prevent updating IB Owner, Current Location, and Installed Location once the line is interfaced with Install Base. The IB Owner, Install Location, and Current Location is passed to Install Base:

For shippable items, the attributes pass after shipping.
For non-shippable items, the attributes pass after fulfillment.

Automatic Account Creation for End Customer

You can automatically create an account for the End Customer, for use with applications like Quoting.

Mass Change for End Customer Attributes

You can use mass change for End Customer attributes. A common business example includes an order that has multiple end customers on a line. Five lines could apply to one End Customer, six lines to another End Customer, four lines to another End Customer, etc. You can multi-select a set of lines, and change the End Customer, or mass change all End Customer attributes, including End Customer Address, Contacts, Owner, Current Location, and Installed At Locations in the Installed Base.

HVOP Support for End Customer Attributes

You can import end customer attributes using HVOP, which is bulk-enabled for high volume users. High volume orders are common in the distribution industry.

Reporting End Customer Information

You can report End Customer sales by partner. This also reports:

What End Customers did my partner / Sold_To customer sell to?
Who does this End Customer buy from?

OIP Displays the Name and Address of the End Customer

Within Order Information Portal (OIP) you can view the name and address of the End Customer, as captured at the time of processing the order, at both at the header and line levels.

OIP Displays the Contact for the End Customer

You can view the contact for the End Customer, when captured at the time of processing the order, at both the header and line level. External partners can use the contact for follow-up. Internal users can display the End Customer contact; if not wanted, the contact can be hidden via personalization.

OIP Displays End Customer Attributes for the Installed Base

You can view the Owner, Installed at Location, and Current Location in OIP – at both the header and line level. This information is useful for both internal and external users. The information displayed is what is captured on the order, not updates that may have been made later in the Installed Base.

OIP Displays Individual DFF Segments

Within OIP you can view the contents of Descriptive Flexfields (DFF) fields, with user-defined labels. For example, it may be important to capture the name or address of the reseller, the second-year renewal amount, or the CSI number. You can display all the individual segments of the DFFs, at the header and line level OIP.

Sort by End Customer

Using OIP, you can sort query results by End Customer. For example, you may query all orders , and then want to sort those orders by End Customer. This gives an indication of which End Customers are most active, and helps to find information about orders pertaining to specific End Customers.

User Procedures

To define the End Customer manually from the Sales Orders window:

Header-level defaulting. Any of the following attributes can be entered manually. However, most users will default values to the Sales Orders window. If desired, you can create an API Defaulting Condition, i.e. if Agreement is X, then default End Customer to be the IB owner, but if Agreement is Y, default Sold To customer as the IB owner. Alternately, attributes can default based on profile options for the Install Base Owner, Current Location, and Installed At Location.
End Customer. Determine if End Customer should be entered manually, or if it should default from either the Ship To or Sold To on the order header.
IB Owner. You may want to create an API Defaulting Condition to define logic for populating the header level dependent attribute for IB Owner, or you can use the defaulting framework to default either the Sold To customer or End Customer.
Current Location. Defaults from the header either the Ship To, End Customer, Deliver To, Sold To, or Bill To location.
Install At Location. Defaults from the header either the Ship To, End Customer, Delivery To, Sold To, or Bill To location.

The values for Owner, Current Location, and Install Location will be passed to Install Base.
Line level defaulting. Any of the values can be entered manually. Optionally users can define how the four above attributes should default to the line level. For instance, the same values at the header can default to the line, if desired.
Define the Customer. Using the Customers window, define the End Customer. This will allow End Customer to be used as a Sold To Customer. If the End Customer is to be used as the Ship To customer, a Ship To site must also be defined. If desired, set up other business purposes such as Bill To and Deliver To. (The End Customer location can have a business purpose of Sold To, Ship To, Deliver To, or Bill To.)
Order header. Create an order header as usual. Select the End Customer from the header LOV if desired. Review the values defaulted for the Install Base attributes (Owner, Installed Location, and Current Location), and make modifications if desired.
Order lines. Enter information on the Lines tab, specifying a different End Customer for every line if desired. Optionally, the End Customer on the header can be defaulted to End Customer on the lines, using the Defaulting framework.
Progress the order as defined by the order and line transaction types, i.e. book, ship, invoice, etc. If the function activity IB Interface is inserted in the shippable line flow, the IB attribute values are passed to Install Base as described below.

Outbound order lines
If the item is shippable, the physical shipment is used to update Install Base.
If the item is not shippable, then there are no physical shipment details. The Fulfill - Line activity in the line flow is used to update Install Base.

Inbound lines

If the line is an RMA, the update of Install Base depends on whether an inventory material transaction may be used to update the line:
If the line is an RMA and it requires a physical material receipt, updating Install Base is triggered by the inventory material transaction for that receipt.
If the RMA line does not require a receipt, then Install Base is updated via the Fulfill - Line workflow activity in return line flow.

End Customer Functionality with Order Import:

Decide whether you will populate the values for the End Customer and the Install Base Attributes (Owner, Installed At Location, and Current Location) directly in the interface tables. Alternatively, you can use the Defaulting framework to default these values to the order header and lines, using the Defaulting framework and the profile options sources as desired.
Set up the End Customer in the Customers window. This will allow End Customer to be used as a Sold To Customer. For the End Customer to be used as the Ship To customer, a Ship To site must be set up. Other business purposes such as Bill To and Deliver To can be set up if desired.

Note: Add Customer functionality for Order Import does not support End Customer.
Run order import. Note that EDI and XML are not available.
Progress the order as defined by the order and line transaction types, i.e. book, ship, invoice, etc. The IB attribute values are passed to Install Base as below.

Outbound order lines
If the item is shippable, the physical shipment is used to update Install Base.
If the item is not shippable, then there are no physical shipment details. The Fulfill-Line workflow activity node is used to update Install Base.

Inbound lines (RMAs)

If the line is an RMA, the update of Install Base depends on whether an inventory material transaction may be used to update the line:
If the line is an RMA and it requires a physical material receipt, updating Install Base is triggered by the inventory material transaction for that receipt.
If the RMA line does not require a receipt, then Install Base is updated through the Fulfill-Line workflow activity node.

iStore orders brought into Order Management through Order Capture:

Add the seeded workflow function activity, IB Interface, to the shippable line transaction type.
Set up the End Customer in the Customers window. This will allow End Customer to be used as a Sold To Customer. If the End Customer is to be used as the Ship To customer, a Ship To site must be set up. Other business purposes such as Bill To and Deliver To can be set up if desired.
Create the order in iStore, specifying the End Customer information, the Owner, Current Location, and Installed At Location. Specify different End Customers for lines as desired.
Order Capture calls the Group API to bring the order into Order Management. The End Customer information and the IB attributes (owner, current location, and install location) are brought into Order Management from iStore.
Progress the order through the processing defined by the order and line transaction types, i.e. book, ship, invoice, etc. If using Install Base and Service Contracts, the IB attribute values are passed to Install Base as described below.

Outbound order lines
If the item is shippable, the physical shipment is used to update Install Base.
If the item is not shippable, then there are no physical shipment details. The Fulfill - Line workflow activity node is used to update Install Base.

Inbound lines (RMAs)

If the line is an RMA, the update of Install Base depends on whether an inventory material transaction may be used to update the line:
If the line is an RMA and it requires a physical material receipt, updating Install Base is triggered by the inventory material transaction for that receipt.
If the RMA line does not require a receipt, then Install Base is updated through the Fulfill - Line workflow activity node.

Quotes with End Customer

No changes are required to the header workflow for quotes.
Set up the End Customer in the Customers window. This will allow End Customer to be used as a Sold To Customer. If the End Customer is to be used as the Ship To customer, a Ship To site must be set up. Other business purposes such as Bill To and Deliver To can be set up if desired.
Create the quote, specifying the End Customer information, the Owner, Current Location, and Installed At Location on the header.
Create the lines for the quote, specifying different End Customers for lines as desired.
Once the quote has been converted to an order, progress the order through the flow defined by the order and line transaction types, i.e. book, ship, invoice, etc. For Shippable lines with IB workflow, the IB attribute values are passed to Install Base. If using Service Contracts, Order Capture passes the Partner / Sold To Customer is passed to Service Contracts.
For shippable items, the values are passed after shipping.
For non-shippable items, OC captures the information after fulfillment and sends it to Service Contracts.

Note: The End Customer is null for non-partner orders. If you have a mix of Partner and non-Partner orders, you may want to consider using two different Order Types.

Preview and Print Sales Documents

Businesses require documentation containing different information, each tailored to their unique business needs. A dynamic preview and print feature provides the ability to generate a printable Adobe Portable Document Format (PDF) that can meet your layout requirements. Preview and Print is an action available on each business document (Sales Order, Release Order, Quote, or Sales Agreement) that displays the viewable and printable PDF document.

Features include:

Layout Templates can be designed to meet specific formatting requirements
Print pertinent information of the business document including header, line information, and signature block
A default Layout Template can be defined on the Transaction Type
A Business Document field displays the Layout Template defined for the Preview and Print
Ability to automatically attach a PDF in the workflow notification to Internal Approvers and attach the PDF file to the business document in the system by extending the seeded Negotiation workflow to include the subprocess, Sales Agreement/Sales Order Generation
Sales Agreement/Sales Order Generation
Ability to print custom data along with the transactional data in a blanket sales agreement, sales order, or quote.

Preview and Print Major Features

Preview and Print Document

Many businesses want to preview the Sales Agreement, Quote, or Sales Order, as it would appear for customer signing, and to print the document. The document may or may not include textual terms and conditions as part of the agreement.

Note: Contract Terms can only exist on a Sales Agreement when the customer has Oracle Sales Contracts licensed and setup.

Preview and Print Sales Agreement and Quote/Sales Order

When a user initiates previewing of a sales document, Sales Agreement, or Quote/Sales Order, the system generates a preview of the document based on the following components:

Sales Agreement data (including Sales Agreement header and lines, pricing and Terms and Conditions
A customizable Style sheet, or layout template, for formatting

or
Quote/Sales Order data (including order, pricing, and Terms and Conditions (see note above)
A link to the PDF of a referenced Sales Agreement at the header and/or line levels of the Quote or sales order

Preview Sales Documents

You can preview the formatted Sales Agreement. The document may include header information, line and price information, and textual terms and conditions.

To Preview and Print from the Sales Agreement header, you can use the Action, Preview and Print or right mouse click to access Preview and Print, to Preview and Print from the Sales Agreement header. When a specific sales agreement is open, you can initiate preview of the formatted contract document. The document always displays in PDF format when previewed from the sales agreement; you will not be required to choose a file output format.

When submitting the Sales Agreement for internal approval, the system will automatically generate a formatted PDF document that will be stored as a contract document attachment to the Sales Agreement. This PDF will automatically be stored as an attachment only if the WF extension mentioned above has been added to the Negotiation phase.

You can preview the formatted sales document. The printed document may include header information, line and price information, and textual terms and conditions.

Note: The Oracle Sales Contracts license and setup are required to enable contract terms on the sales agreement and printed document.

T&Cs are only with Oracle Sales Contracts integration. A menu option Preview & Print is available from the Quote/Sales Order header. When a specific Quote/Sales Order is open, you can initiate preview of the formatted ordering document.

The ordering document always displays in PDF format when previewed from the Quote/Sales Order, and you will not be required to choose a file output format.

Attaching the Preview to the Sales Agreement or a Quote/Sales Order

When you initiate (Actions > Submit Draft) the approval process for a Sales Agreement or Quote, is initiated. The system attaches a formatted PDF file of the Sales Agreement or Quote to the workflow approval notification at the time the approval process is started. This enables approvers to view the formatted document directly from the approval notification.

When you Book a sales order, the system automatically attaches a formatted PDF file of the sales order.

Note: The subprocess, Sales Agreement/Sales Order Generation, must be added to the Negotiation with Approval flow to obtain the automatic attachments.

Previewing the Business Document from a Workflow Approval Notification

The approver can open the workflow approval notification, and click a link directly within the approval notification to view the business document. The output file type is in PDF format.

All business variables are shown with the appropriate placeholders for empty business variables.

You can select to print the business document PDF file from the File window by selecting the File > Print menu option in Adobe Acrobat, or by clicking the Print Toolbar icon, a variable in Adobe Acrobat.

Note: This is not compatible with the combination of Netscape 4.79 and Adobe Acrobat Reader 5.0. Higher revisions are compatible. Upgrading to Acrobat Reader 6.0 resolves compatibility issues.

Printing of the contract is performed by choosing the File > Print menu option from Adobe Acrobat, or by choosing the Print menu icon from the toolbar.

Printing

For all three transactions, the ability to print is the same. First you must preview (Action > Preview and Print) the PDF (or open an existing attachment) Then you can print the PDF using the printer icon or File > Print or Ctrl+P.

Printing Custom Data

You can print custom data along with the transactional data in a blanket sales agreement, sales order, or quote. You can achieve this using the 'PrintExtensionObject' Java interface and OM: Printed Document Extension Class Name profile option. You can create a custom class, by implementing the method 'getPrintExtensionXMLFragment' in the interface ''PrintExtensionObject' , to generate a custom XML structure and register the name of the implemented custom class in the profile option. The print module executes this custom class to retrieve the custom data. getPrintExtensionXMLFragment can either return a XMLFragement or a sql query. If getPrintExtensionXMLFragment returns a string which starts with "select", then the application code executes that query and appends the corresponding XML to the main XML. You can use a modified layout template to expose this custom data in the PDF document.

Document Formatting

A style sheet or layout template defines the format of the Sales Agreement or Quote/Sales Order document when previewed or printed. Four layout templates will be seeded with the application:

Layout template to generate XML PUBLISHER for generating PDF for Sales Agreement
Layout template to generate XML PUBLISHER for generating PDF for Quote/Sales Orders
XML PUBLISHER Layout template to generate HTML for Sales Agreement
XML PUBLISHER Layout template to generate HTML for Quote/Sales Orders

The super user can define multiple custom Layout templates during the setup. As part of the setup the user will associate a Layout template for each Order Management transaction type. When the user initiates the preview, the document will be previewed based on the layout template associated to that transaction type.

Note: When the layout template is defined, the author will need to give it an intuitive name so when they associate it to the transaction type it is easy to pick the right one. This step is only done once at setup, not by everyday users.

Note: You can create layout templates or layout templates using XML Publisher > Templates.

Format Business Document Data

The Super User can define the layout template formatting properties for each of the following components of the Sales Agreement and Quote/Sales Orders:

Sales Agreement and Quote/Sales Order data: data such as item, item description, price, and commitment quantity (Sales Agreement only), for example, can have specific properties defined in the layout template that will tell the contract preview tool how to format the data
Sections: Super users can define formatting properties for sections of clauses. Sections are the headings of clause groups, such as “1.0 General Terms” below. The section title and sequence number may have its own style setting:
- 1.0 General Terms
- 1.1 Term 1
- 1.2 Term 2
Clauses: Super users can define formatting properties for clause text. The title of the clause, the clause text, and the clause number may have their own style settings (assuming Oracle Sales Contracts has been licensed and set up).

Static text: other text not appearing in the Sales Agreement or Quote/Sales Order schema, or the terms and conditions, may need to be printed. This data is defined in the layout template. For example, the text, “Software License Agreement,” “between” and “and” in the following example is defined in the layout template:

Software License Agreement

Between

<Oracle> <system variable>

And

<Company B> <system variable>
Business Variable: values substituted for business variables may have their own style, as defined in the clause. This includes both system and user defined variables.

Security

Layout Template Security

Layout templates have global visibility and are not specific to an organization.

User Profiles

Listed below are the users and the tasks they will be performing while using the preview/print functionality.

Super User

System Administrators and IT Engineers are usually Super Users. These users define/customize the XML PUBLISHER Layout templates as part of the application setup. Definition of the layout template is a programming task and requires knowledge of XML PUBLISHER.

Business User

Business Users can be Sales Managers, Sales Representatives, Customer Service Manager, Customer Service Representatives, Contract Administrators/Negotiators, and other Business Managers (Sales Officers, Pricing Specialists).

Some of the tasks that business users are involved in are business document authoring, negotiation, and approval. Business users are usually responsible for defining the layouts of the business document and working with System Administrators to define or update the Layout templates to generate business documents in appropriate format.

End User

The Sales Representative and Customer Service Representative (CSR) constitutes the end user community. This person uses the document preview/print functionality. They use the Preview/Print functionality as part of their day-to-day responsibility.

Examples of when Preview and Print (PnP) may be used:

Prior to initiating approval
Approvers will use PnP for each WF Notification to view details of the business document
Sharing with customer prior to customer acceptance
Capture customer signature on hard copy, scan and attach to the business document for future reference
View details of signed version when referencing the transaction

Formatting Properties for Business Document Data

Super User can define the following layout template properties for contract components:

Font type and size
Font attributes such as bold, underline, italics

Variable Formatting

The Super user can define formats for the business variables. The following formatting options are supported for table formatting:

The text for each column header
The columns displayed/printed and their order
Font type (14 standard PDF fonts) and size for columns and headers
Font attributes such as weight (bold) and emphasis (underline, italics) for columns and headers
Borders (total or none, line width)

The following formatting options are supported for variables appearing in text format:

Font type and size
Font attributes such as bold, underline, italics

Format Header and Footer

The Super user can define a header and footer for the document as part of customizing the layout template. The header and footer may include:

Static text
Page Numbers (Arabic numbers)
Total Pages (if supported by FOP/ATG infrastructure)
Variables, which are available for the document. For e.g. Supplier Name

The following style properties can be defined for the header and footer in the Layout template:

Font type (14 standard PDF fonts) and size
Font attributes such as weight (bold) and emphasis (underline, italics)

Generate Signature Block

The system generates a signature block as part of the SA or Quote/Sales Order when it is defined in the layout template.

Register New Layout Templates

You can create new layout templates and/or modify existing layout templates, and register them with the application.

Note: Seeded Layout templates will be protected from modification to support upgrades. However, you can download the seeded layout template and register it as a valid Layout template with or without modifications.

Associate Layout template to Transaction Type

You can select a format layout template and associate it with an Order Management Transaction Type. Generation of the business document is formatted according to the transaction type of the business document and the associated layout template.

For example:

Transaction Type Layout Template Associations
Transaction Type	Layout template Name	Contains
Sales Agreement	Sales agreement Format	Layout template for preview/print of PDF output type
Quote/Sales Order	Sales Order Format	Layout template for preview/print of PDF output type

If the layout template is not identified in the Transaction Type screen, and you initiate the preview/print action, you receive an error message, telling you that the layout template must be defined. Setup > Transaction Type > Define, the Layout Template field has an LOV that will list all of the registered layout templates available to choose from.

Transaction Types Window - Layout Template Field

the picture is described in the document text

In Line Formatting

The preview/print supports inline formatting with a limited number of HTML style tags. Since Business Document Preview/Print functionality does not provide a rich text editor, these tags need to be inserted directly in the text.

For example, some words within an clause may be required to be formatted in bold: “Applicable shipping costs are to be paid for by the Customer, who agrees to pay them in full per payment terms.”

Business Variable Substitution

The Business Document authoring functionality supports the inclusion of business variables into the clauses. These variables are substituted by its value when the business document is previewed/printed. The application supports simple (scalar) variables and table business variables.

Substitute Simple Business Variable

Simple Business Variables are replaced by their value whenever the document is previewed or printed. The display formats for business variables are defined in the layout template. You can customize the layout template to implement all the custom formatting needs.

Example of Simple Business Variable, where <Customer> would be substituted for the customer name:

“Applicable shipping costs will be paid for by <Customer> …”

Example where Customer = ACME Corporation:

"Applicable shipping costs will be paid for by ACME Corporation..."

Substitute Table Business Variable

Table Business Variables are represented by XML values contained in the variable. The display formats for the table including which columns to display are defined in the layout template. You can customize the layout template to implement all the custom formatting needs. The XML representation contains all the table columns available for printing. The layout template determines which columns should be displayed and their ordering.

Print Unresolved Business Variables

When a Business variable has no defined value, the system prints a placeholder that is an underlined blank space with a length of 10 characters.

User Procedures

Listed below are the user procedures along with the User/Role that performs each procedure, in using the Document Preview/Printing functionality.

To associate a layout template to an Order Management Transaction Type (Super User + Business User):

Navigate to the Transaction Types window, Transaction Types Setup.
In the field Layout Template, use the List of values choose a layout template for the transaction type.
Save your work.

Note: When previewing a Business Document from this transaction type, the formatting will be based on the layout template defined here.

Previewing and Printing from Approval Notification, this is the same for all transactions

Initiate the workflow approval process. The approver receives approval notification, and may click the PDF link to preview the business document.
The business document is displayed in PDF format; formatting is based on layout template.
Review the document and print it if required, by clicking the File > Print menu option or by clicking Print icon, and close the document.
Respond to the approval notification, which is still open; you may not modify the Business document during the approval cycle.

To preview and print from the Quote, Sales Orders, or Sales Agreements window:

Navigate to the window and find the transaction (SA) to preview or print. From the Action button or right mouse click the Preview and Print option.
If a layout template has not been defined, then the system displays an error message: “Unable to preview or print the business document < > as a Layout Template has not been defined in the Transaction Type setup screen.”

If a layout template has been defined, the business document is generated in a PDF format, based on formatting from the style sheet.
Review the document and elect to also print the document from the Acrobat window by choosing File Print menu option in Acrobat, or by clicking the Print icon.

Previewing and Printing from the Contract Terms Window

When you are in the Contract Terms window, (Action > Contract Terms) and you click Preview Document, the same formatted business document will be generated, using the layout template identified in the Transaction Type setup screen, if you have Oracle Sales Contracts installed.

Note: Only price lists and modifiers created from the sales agreement specific to that sales agreement will be previewed or printed. If a standard price list has been identified, it will show as a reference on the business document.

Integrations

Integration Dependencies: XML PUBLISHER Dependency

To be able to generate the document preview (in PDF), XML PUBLISHER is required. XML PUBLISHER is a mandatory pre-requisite for Oracle Sales Contracts, so if Oracle Sales Contracts is installed, you will have the capability to preview and print. If Sales Contracts is not installed, then users MUST install XML PUBLISHER to be able to generate the document preview. If XML PUBLISHER is not installed, the Preview and Print action for Blanket Sales Agreements and Quote/Sales Orders will not be enabled. This dependency affects the ability to:

Manually initiate generation of the formatted document preview (in PDF file format) 2-132 Oracle Order Management User's Guide.
Automatically generate the formatted document and attach it to the approval notification for viewing.

Seed Data

This section identifies all the seed data that are required for the Preview/print of the Blanket Sales Agreement or Quote/Sales order.

Seeding of Layout templates for the Business Document. A layout template (Default Sales Agreement) is seeded for the preview of a generic Sales Agreement format.
Layout template for generating PDF for Quote/Sales Orders.
Layout template to generate HTML for SA.
Layout template to generate HTML for Quote/Sales Orders.
Functions have been seeded to display the preview or printing of the Sales Agreement.
- When the preview/print of the SA is called from the Sales Agreement window, the following seeded function is invoked, that launches the Preview/Print page
- Function: ONT_PRINT
- User Function name: Order Management Print
When the preview/print of the BSA is called from the Contract Terms window, the following seeded function is invoked to launch the Preview/Print page
- Function Preview and Print

Drop Shipments Overview

Overview

Drop shipping functionality enables you to take an order from your customer and fulfill it directly from your supplier's site. Order Management enables you to enter drop ship sales orders and lines for standard, model and kit, and configured items, although you currently cannot perform a drop shipment for Ship Model Complete (SMC) PTO's.

You can receive orders for items that you do not stock or for which you lack sufficient inventory, and have a supplier provide the items directly to your customer. The benefits of drop shipping include:

No inventory is required
Reduced order fulfillment processing costs
Reduced flow times
Elimination of losses on non-sellable goods
Elimination of packing and shipping costs
Reduced inventory space requirements
Reduced shipping time to your customer
Enables you to offer a variety of products to your customers

When processing drop shipments for orders, you can:

Optionally receive and electronically process Advanced Shipping Notices (ASN)
Automatically perform logical receipts upon notification of shipment
Perform Drop Ship for both make and buy items, and automatically default the source type of External for order lines which need to be drop shipped

The supply and demand details for drop ship orders are not visible to Oracle Planning applications. Therefore, it is recommended that you associate a separate logical (dummy) organization for shipping drop ship orders; the logical organization should not be included in your planning processes.

It's not uncommon to see companies use drop ship items in normal inventory organizations. This is fine as long as the company is not using MRP or Min-Max. The reason for this is because Min-Max and MRP are designed to consider all supply as expected increases in on hand quantity while in actuality, supply tied to drop ship orders will increase the on hand quantity and then the on hand quantity will immediately be decremented for the quantity received. Since this 'false' supply can throw MRP and Min-Max off for the quantities listed on drop ship purchase orders, it's recommended that drop ship inventory organizations are created entirely separate from non-drop ship inventory organizations. The Order Management User's Guide mentions that drop ship organizations should be 'logical' inventory organizations; which can be translated to say drop ship orders should only be conducted in drop ship inventory organizations.

When processing drop shipments for orders that contain models or kits, you can drop ship individual items within non SMC PTO configurations from different vendors or even ship several components from your own inventory.

When processing drop shipments for orders that contain ATO configurations, you can:

Send a generated attachment file which provides the configuration details to the vendor to manufacture the configurable item. Your vendors can also view this information via the iSupplier portal.
Perform a match and use existing configuration ids. instead of generating new ones during the Create Config subprocess. Match is organization/supplier independent.

For more information on purchasing, dropshipping ATO items or configurations, and changes to these order types, see: CTO Implementation Manual.

Note: For additional features supported in this release for Drop Shipments please refer to the section, Drop Ship Across Ledgers and Change Management Overview

Item Attributes that affect Drop Ship orders

All Drop Ship items (and all external ATO or PTO models, it's option class and options) must be defined within the item validation organization specified by the value of the Order Management system parameter Item Validation Organization.

The table below displays a listing of the inventory item attributes and the respective value that affect the ability to create drop shipment orders lines for an item.

Inventory Item Attributes
Item Attribute used within Drop Ship order processing	Setting
Purchased (PO)	Enabled
Purchasable (PO)	Enabled
Transactable (INV)	Enabled
Stockable (INV)	Enabled
Reservable (INV)	Enabled
Customer Ordered (OM)	Enabled
Customer Orders Enabled (OM)	Enabled
Default SO Source type	Optional
Shippable (OM)	Enabled
Transactable (OM)	Enabled
Costing Enabled	enabled for items that are to be costed
Inventory Asset Value	enabled for asset items (non-expense items)

In Oracle Purchasing, a term called one-time expense item is used. This term refers to an expense item that is not defined in inventory, nor does an associated record exist in the items database table, MTL_SYSTEM_ITEMS. Since a one-time expense item is not defined in inventory, it cannot have the inventory attributes checked and therefore, cannot be drop shipped.

Once the drop ship inventory organization is created, subinventories should be defined. To create the subinventory, go to an inventory responsibility and navigate to Setup:Organizations:Subinventories. All drop ship subinventory must have the Reservable box checked. Asset subinventories must have the Reservable and Asset boxes checked. Expense subinventories must have the Reservable box checked and CANNOT have the Asset box checked.

Subinventory Attributes for Asset Subinventory
- Reservable/Allow Reservations
- Asset Subinventory
Subinventory Attributes for Expense Subinventory
- Reservable
- Asset – must NOT be enabled

Defaulting order line attribute Source Type

The organizational item attribute, Default SO Source Type, (Organization Item window, Order Management Tab) is used within the seeded Order Management defaulting framework to provide a default value for the Source Type field for sales order lines, enabling you to set the value of this attribute by organization.

The initial sequence for defaulting the Source Type field is:

The organizational item attribute, Default SO Source Type.

If the value of this attribute is NULL:
Order Management will default the value Internal.
If you do not wish to default a value for the Source Type field for sales order lines, you must disable the seeded defaulting rules for the order line attribute Source Type.
If the value of Source Type for an order line is changed from External to Internal and you have manually entered the Schedule Ship Date for the line, Order Management will attempt to schedule the order line with the date provided.
- Order Management seeded constraints will not enable you to perform changes to the Source Type value if the branch on source type workflow activity within the Create Supply - Line workflow subprocess has completed.

Mass Change and order line attribute Source Type

You can perform a Mass Change for the order line attribute Source Type. The order line attribute Source Type is available (as a field) within the Shipping Tab of the Mass Change window.

Reservations

Once an order line has been specified as an External order, Order Management does not allow reservations to be placed against the order line.

Entry and Booking

You can enter orders using standard Order Management functionality, and decide at the time of entry whether a particular line will be drop shipped (order line source type is set to External). Both standard and expense items may be drop shipped, although drop shipments currently support a Destination Type (item attribute) of Expense and Inventory only. As with standard sales orders, you can modify orders or lines that you intend to drop ship after you have entered them, typically up to the point of Booking the order line.

When an order line with a source type of external is booked, the seeded workflow Line Flow - Generic will process drop shipment lines. The Create Supply - Line subprocess utilizes the function Branch on Source Type which detects an item with a Source Type of External and moves the line to Purchase Release - Deferred. External ATO Models or ATO Items will still follow the appropriate ATO paths. Then within the Create Supply Order - Line, Manual subprocess, CTO detects that the item has a Source Type of External and moves the line to Purchase Release - Deferred When the Workflow Background processor processes the line, the Purchase Release process is initiated to write records to the PO_REQUISITIONS_INTERFACE table.

Note: The application does not pass the values of Additional Line Attribute Information to the PO_REQUISITIONS_INTERFACE table. It passes these values to Oracle Receivables for invoicing.

Purchase Release and Requisition Import

The Purchase Release concurrent program processes eligible lines with a source type of External and passes information to Oracle Purchasing. Buyer details transferred to Oracle Purchasing during Purchase Release are dependent upon the value of the Order Management profile option OM: Population Of Buyer Code For Dropship.

The Autocreate Drop Ship concurrent program processes eligible ATO item and configuration lines with a source type of External and passes information to Oracle Purchasing. Submit the Oracle Purchasing Requisition Import concurrent program to create purchase requisitions based on this information. When you submit the program, ensure that you set the input parameter Multiple Distributions to No.

Note: If the buyer makes changes to the requisition or purchase order in Oracle Purchasing after Purchase Release has been run, or modifies the sales order after the PO has been created, use the Order Management Sales Order and Purchase Order Discrepancy Report to note differences between the original sales order and its associated purchase order.

Confirmation of Shipment and Receipt

Standard Oracle Purchasing functionality confirms that your supplier has completed the drop shipment. Confirmation may be as simple as a phone call, or it may include Electronic Data Interchange (EDI) documents, such as an Advance Shipment Notice (ASN) and an Advance Shipping and Billing Notice (ASBN).

When you receive shipment confirmation, enter a receipt in Oracle Purchasing, even if the drop shipped item is not transactable. This creates inbound and outbound material transactions in your system for accounting purposes. Drop shipment orders can be processed across Ledgers, operating units, or legal entities.

You must receive drop ship items in a logical organization. If you use Oracle Advanced Planning and Scheduling for planning, to avoid miscounting supply, you may not want to include logical organizations during your planning. If you choose to include logical organizations, ensure that doing so does not cause planning and forecasting complications.

If your supplier should send only an invoice, you need to enter a passive receipt.

Invoicing

After your system's inventory has a record of the transaction, run the Invoicing Activity and AutoInvoice programs to generate an invoice for your customer. You may want to pass on any landing or special charges that your supplier imposed on the drop shipment.

Passive Receipts

When a vendor sends only an invoice for drop shipments, you will need to perform a passive receipt. Passive receiving must be performed manually.

The receipt quantity should be retrieved from the associated invoice and a logical receipt of the drop shipment should be performed.

Service Items

Purchasable service items can be drop shipped based on the assumption that the service is provided by the seller and the vendor is actually drop shipping the item; service lines for drop shipment are not source dropshipped.

For example, you can define a television as a serviceable item. When you place the order, the source type must be set to External and then define service lines for the television. However, only the television can be sent to Oracle Purchasing for creating a requisition or purchase order. The vendor is only responsible for the shipping of the television to the customer.

Deferred services for models or kits, the service is defined as an order line in order management.

Scheduling

When performing drop shipments of models or kits or standard items, the scheduled ship date is defaulted from the order line request date, and Oracle Global ATP calculations are ignored (demand for drop ship orders are not visible to Oracle Planning products).

Drop Shipment orders cannot consume forecast demand for standard items, ATO items, and models and their respective components.

Returns

Use standard Order Management functionality to process return material authorizations (RMAs). Your customers can return drop shipped items to you or to your supplier. If you receive the return into your inventory, you can retain it or ship it to your supplier. If you pass the returned item to your supplier, you should notify the buyer and authorize the return by generating a return document in Oracle Purchasing. If your supplier receives the return directly, they must inform you of the event before you can process the return within Order Management.

Holds and Approvals

Standard holds and approvals functionality controls drop ship sales orders. You can implement holds and approvals at different stages in your order workflow to control the drop shipment process. For example, if your supplier reserves the right to refuse returns, you can add an approval step to your order workflow to ensure that the customer will not receive a credit unless your supplier notifies you that they accept the returned item.

If you place a hold on a line before you submit the Requisition Import concurrent program, the requisition will not be created; the hold must be removed prior to successfully generating a requisition.
If you place a hold on a line before you submit the Purchase Release concurrent program, the Purchase Order will not be created; the hold must be removed prior to successfully generating the purchase order.

Once a purchase order has been generated for your drop ship order line, you must control holds manually, which you can coordinate with your supplier. The Sales Order and Purchase Order Discrepancy Report displays orders on hold for your review.

See

Drop Shipment Processing

Cancelling Orders

Overview of Holds

Copying Orders

Note: If you are using Drop Shipment Across Ledgers / InterCompany transactions refer to the section, Drop Ship Across Ledgers and Change Management Overview

See: Oracle Order Management Implementation Manual, Order Overview of Shipping Tolerances.

Using Oracle Workflow in Oracle Order Management Manual.

For details on the required setup for a purchased item, see: Oracle Purchasing User's Guide, Oracle Inventory User's Guide, and the Oracle Configure To Order Implementation Manual.

Drop Ship Across Ledgers and Change Management Overview

Drop Ship

There are three trends in business that require Oracle to enhance its support for outsourced manufacturing:

Increased reliance on contract manufacturers to supply some or all of their products to their customers.
Increased customer demand for mass customization, where the product is configured specifically to customer needs.
Increased globalization, where companies are doing business throughout the world. Companies often have global supply plans, and global contracts with suppliers, but have country specific agreements as to which subsidiaries and suppliers are authorized to provide products to which country.

Many companies, create separate local organizations for every country where they do business. These organizations are in separate ledgers, and own the right to sell and service hardware and software products in specific geographic regions or countries. There are separate legal entities that own the distribution rights for the products. Often, but not always, there is a physical distribution center associated with the distribution legal entity. For instance, companies may have one distribution entity in their home country and one for all international country organizations. For internationally sourced products, the local country organizations must place orders with the legal entity that owns the distribution rights for their region. These trends require Oracle to enhance the functionality for drop shipment, outside processing, and manufacturing collaboration.

Drop shipments may happen for several reasons:

Customer orders an item not normally keep in stock
Customer orders an unusually large quantity of an item
It is more cost-effective for the supplier to ship the item directly to the customer

Drop Ship Across Ledgers and Change Management
Drop Ship across ledgers, operating units, or legal entities. With the enhanced Drop Ship, functionality, you can choose a warehouse that belongs to a different operating unit (OU), legal entity, or ledgers than the order taking organization.
Enhanced Inter-company transactions between multiple Organizations (Operating Units or Legal Entities) which could be in the same or different Ledgers. Intercompany accounting is supported between multiple operating units.
Enhanced Change Management between Order Management and Purchasing. With enhanced Change Management support, changes in Order Management and Purchasing will be automatically synchronized.
Additional Sales Order Data Elements sent to Supplier. With the enhanced Drop Ship functionality, additional Sales Order Data Elements that are essential for the drop ship process are sent to the supplier.

Drop Ship Across Ledgers Major Features

Drop Ship Across Ledgers

You can now Drop Ship across Ledgers, operating units, or legal entities. A common scenario involves manufacturing facilities in some countries, sales organizations in others, and financial companies in several others. These entity structures allow multinationals to avail themselves of the benefits of each legal environment in which they are organized. They also allow companies to provide products to market quickly and profitably, taking advantage of regional 'hub' operations that rationalize product demand and control supply sourcing in a centralized fashion.

The ability to drop-ship goods across Ledgers, operating units, or legal entities is a major business requirement for today's businesses. Formerly it was not possible to drop ship across operating units and Ledgers in Oracle Applications. The introduction of cross operating unit drop ships raised the need for hybrid drop shipments where the sales order is drop shipped to one, but not both, of the organizations involved in executing the transaction.

You can model a drop ship where the source of the goods is another organization or where a sales order is entered as a drop ship. When a purchase release is run, the order line is visible in the Procurement Organization's purchasing system (a different operating unit using a separate Ledger).
You can view customer addresses across Ledger and legal entities to support the drop ship practices.
You can receive and record an Advance Shipment Notice (ASN) to facilitate logical receipt of the goods in the sales organization. The ASN will indicate the quantities, items, shipment dates, and ship-to location (customer address). The ASN is created automatically when the procurement organization processes a logical receipt.
Intercompany receivables and payables transactions are recorded automatically. The procurement organization creates an intercompany receivables invoice for the goods, and the sales organization generates an intercompany payables invoice. These transactions are based on prices negotiated between the two organizations. For the intercompany accounts to stay balanced, the receivables and payables invoices must be created simultaneously.

For example, Company A needs to perform a drop ship transaction across their global enterprise. The drop ship transaction needs to balance inside each legal entity (debits = credits). These legal entities may have different chart of accounts, calendars. or currency.
For drop ship lines, the cost of the item is taken from the organization that has been specified in the Finance Options window (Financial System Parameters).

Following diagram shows the process flow for Drop Shipments:

Drop Ship Process Flow

the picture is described in the document text

Drop Ship Across Ledgers

With enhanced Drop Ship support, you can choose any warehouse available in the system. Warehouses can come from a different Ledger, OU, or Legal Entity (LE). At a high level, there are two enhanced Drop Ship flows, Flow 1: Drop Ship Across Ledger; or Flow 2: Distribution center Drop Ship.

Flow 1: Drop Ship Across Ledger

The sales order is placed in OU1/DC. The order is fulfilled by the Distribution Center (DC/OU3) by shipping directly through its supplier.

The sales order line is created in the OU1 operating unit, the Ship From Organization (receiving Organization) is DC and it is marked as a Drop Ship Order Line.
The purchase requisition is created in operating unit OU3, the Ship To Organization is DC. The Ship to Location will be the Customer Location.
The purchase order is created in operating unit OU3 and the Ship To Organization is DC. The Ship to Location will be the Customer Location.

The Process flow for drop ship across Ledger remains the same as the existing drop ship process, except that the requisitions and purchase orders are now created in different operating units. Intercompany transactions are performed when the logical receipt and delivery transactions occur for the purchase order. Please refer to Enhanced Intercompany transactions section below.

Flow 2: Distribution Center Drop Ship

The sales order is placed in OU1/MO. The order is fulfilled by the Distribution Center (DC/OU3) by shipping directly through its supplier.

The sales order line is created in the OU1 operating unit, the Ship From Organization (receiving Organization) is MO and it is marked as a Drop Ship Order Line.
The purchase requisition is created in the OU1 operating unit, the Ship To Organization is MO. The Ship to Location will be the Customer Location.
The purchase order is created in the operating unit OU3 and the Ship To Organization is MO. The Ship to Location will be the Customer Location.

Flow 2 is supported by the new Shared Procurement functionality available in Purchasing. In this case, the requisition can be in one organization (Order Management/OU1), and the buyer can decide to source the material from a supplier that belongs to another organization (DC/OU3). As the supplier is tied to OU3, the purchase order will be cut from OU3, but the Ship To Organization will still be MO.

In another variation of the flow, the sales order can be placed in OU1/RC and the purchase order could be fulfilled by OU3/DC by shipping directly from its supplier.

Enhanced Inter-company Transactions

With the enhanced Intercompany transaction support, you can perform Intercompany transactions between multiple Organizations (OU1, OU2 and OU3) that are involved in the Drop Ship flow. In addition, Intercompany relations have to be set up that will define the intercompany accounts, costs, etc. between the organizations that are involved in the transactions.

Intercompany transactions are performed automatically when the delivery transaction occurs in the Purchasing system, where the sales order line will be marked as fulfilled and progressed to invoicing.

If customers have defined transaction flows, there is a change of behavior in the Intercompany accounting and also the Drop Ship Receiving Process in Order Management. When the delivery transaction occurs in Purchasing, and if there is a transaction flow defined, then the Inventory module will do all the processing and call Order Management to indicate that the line is fulfilled. In this case, Order Management will not perform any Inventory decrements, only the sales order line will be marked as fulfilled and progressed. From an accounting perspective, Inventory will not be incremented and decremented, only the logical intercompany transactions will be performed between the organizations that are involved in the Transaction flow.

If you do not use transaction flows, then the existing Intercompany transactions are still performed, provided that the Inter-Company relations are set up between the organizations. In this case, inventory will be incremented by the purchase order delivery and inventory will be decremented by the logical Sales Order Issue. Intercompany transactions are performed by using the sales order issue transaction. Note that existing intercompany transactions can only be used between two organizations. Transaction flows can also be defined between two organizations without an intermediate organization.

Changed Behavior for Existing Customers

Currently, a requisition is created in the same operating unit of the sales order as the warehouses can only come from the same Ledger. With the new changes, the purchase requisition is always created in the operating unit of the warehouse. This is more consistent with cross Ledger or legal entities business, where the requisition has to be created in the same operating unit of the warehouse. In addition, it will enable the intercompany logic to clearly identify the points where the inter-company is involved.

Drop Ship Design Changes

The following windows and processes will handle the enhanced Drop Ship across Ledger functionality.

Sales Orders window:

For Drop ship orders, you can choose any of the warehouses available. The list of values for the warehouse field shows warehouses across Ledgers.

Order Business Object Changes (Process Order):

Changes in the Process Order validations:

Validation for Drop ship lines to allow any warehouses.
Additional Line Information Window:
Added Operating Unit information for the requisition and purchase order in the overflow region.
With Multi-Org Access Control, even if Purchase Orders and Sales Orders are created in different Operating Units, if you have access to the Operating Unit that the Purchase Order was created in, you can view the Purchase Order.
Drop Ship Information view is changed to get the requisition or purchase order information.

Purchase Release Process:

Purchase Release process is modified to create the purchase requisition in the operating unit of the receiving org if the receiving org does not belong to the operating unit of the sales order.

Drop Ship Receiving Process:

Drop Ship Receiving logic is modified to handle Drop Ship Across Ledger, where the purchase order could be in a different operating unit than the sales order.

Employee/Requestor Information and Cross-Business Groups Impact

To handle the cases where employees (users) might be creating purchase orders in different operating units that are in a different business groups, Purchasing allows Requisition Import to enable a customer service representative (CSR) to create a requisition in an operating unit associated with a different business group, than the one the CSR belongs to, if the value of the profile option HR:Cross Business Group is set to Yes.

User Procedures

To enter a drop ship sales order line (sourced externally) with a different Ledger:

Navigate to the Sales Orders window.
Enter a sales order and an order line with an item sourced externally with a quantity of 10.
Use a receiving org that is in a different Ledger.
Book the order.
Purchase Release runs automatically, if the purchase release is deferred, then run the workflow background process for WF Item Type Order Management Line (OEOL).
Run Requisition Import (the requisition is created and approved) after changing to the appropriate operating unit.
Create the purchase order in Purchasing. Verify the sales order information on Drop Ship tab of the Shipments block. The Purchasing button is enabled only if you have access to the operating unit in which you created the Purchase Order.
Approve and print the purchase order. Verify the additional sales order information for the shipments.
Send the purchase order to the supplier.
Logically receive and deliver the purchase order.
Verify that the sales order Lines shipped quantity is set properly.

To change data elements after a purchase order is approved when constraints are in place (not allowed):

Navigate to the Sales Orders window.
Enter sales order and an order line with an item sourced externally and with a quantity of 10.
Book the order.
Purchase Release is run automatically, if the Purchase Release is deferred, then run the Workflow Background process for WF Item Type Order Management Line (OEOL).
Change the Ordered Quantity to 20.
Run the Requisition Import and verify that the purchase requisition has an Ordered Quantity 20.
Update the sales order line's ordered quantity to 30, then save the changes. Verify that the requisition quantity is changed in purchasing. Choose the Drop Ship tab in Additional Line Information window.
If Yes, the status will be shown on the Drop Ship tab.
Create the purchase order from the requisition.
Update the sales order line's ordered quantity to 40, then save the changes. Verify that quantity has changed to 40 on the purchase order Line. Choose the Drop Ship tab in the Additional Line Information window.
Approve the purchase order.
Now try to change the Ordered Quantity to 50, and save. You get a message indicating the sales order cannot be changed as the related purchase order is approved.
This procedure can be repeated for all data elements (Ship to Location etc.) that are communicated between Order Management and PO.

To Change Data Elements After a Purchase Order is Approved When Constraints are Not in Place (Allowed):

Disable the constraints for changes to Ordered Quantity increase, Ship To Location, and Shipping Instructions.
Query the sales order from the previous procedure.
Change the Ordered Quantity to 50, Change the Ship To Location, and Shipping Instructions, then save.

The application saves the changes and then launches the approval workflow. If the person making the changes has enough authority to approve the document, then it automatically approves the changes. However, if the person does not have enough authority to approve, then the applicable purchase order goes into the In process status and will be routed to the appropriate person for approval based on the approval hierarchy.
Again, this procedure can be repeated for all data elements that are communicated between Order Management and Purchasing.

Seed Data: Constraints

Constraints

New Constraints have been added for the Drop Ship Sales Order Lines (source Type is EXTERNAL) that can be removed/disabled depending on the business needs.

Constraints
Disable Allowed	Constrained Operation	Attributes	Validation Template
No	Update	Warehouse	Purchase Release completed.
No	Update	Ordered Qty UOM	Purchase Release completed.
Yes	Update	Ordered Qty	If the related Drop Ship purchase order is approved. If there are multiple requisitions and purchase orders, then do not allow the change if all the purchase orders or releases are approved.
Yes	Update	Shipping Instructions, Packing Instructions, Ship To Contact, Deliver to Address, Deliver to Contact, Customer PO Number, Customer PO Line Number, Customer PO Shipment Number, User Item Description, Shipping Method, Ship To, Schedule Ship Date	Do not allow the change if any one of the related purchase orders or releases is approved. For Customer PO Number and Customer PO Line Number, the system processing constraint can be enabled or disabled in case you wish to update the PO Number before Invoice Interface.
Yes	Cancel		Do not allow partial cancellation if the related Drop Ship purchase order is approved. If there are multiple requisitions and purchase orders, then do not allow the change if all the purchase orders or releases are approved. Do not allow complete cancellation, if any one of the linked Drop Ship purchase orders or releases are approved.
No	Update	Project, Task, End Item	Purchase Release completed.

Drop Shipment Processing

Prerequisites

Ensure you have created your Order Management Transaction Types and linked your Transaction Types to order and line workflows that support drop shipments.
Ensure the Order Management profile option OM: Included Item Freeze Method is set accordingly. Depending on your installation details, additional application profile options may affect the processing of drop shipment order lines.
Ensure the Group Requisitions by Sales Order system parameter is set accordingly. The Group Requisitions By Sales Order system parameter determines whether the Requisition Import process will import all the drop ship sales order lines into a single purchase requisition even though the lines belong to multiple sales orders or whether the process will group all drop ship sales orders lines by sales order and then import them into multiple purchase requisitions.

For more information on this Group Requisitions By Sales Order system parameter, see Oracle Order Management Setup in the Oracle Order Management Implementation Manual.
Ensure the Oracle Workflow Background Engine is running.
Ensure all Drop ship locations you will use to perform drop shipments have the Ship To Site and Receiving Site defined.
Ensure you have defined the Internal Ship To Locations for your drop shipment customers (Oracle Receivables Standard Customer window, Business Purpose Details tab).
Ensure your standard items have an associated List Price defined within your PO Inventory organization (Oracle Payables Financial Options window, Supplier-Purchasing Tab).

For ATO Models, ensure the model an its option classes and option are purchased and purchasable, and follow the purchasing setup steps defined in setup chapter of the Oracle Configure To Order Implementation Manual.
Optionally, ensure that you have enabled the defaulting rule to default the sales order line, Source Type field. The defaulting rule for field Source Type utilizes the item attribute, Default SO (Sales Order) Source Type to default the value for the Source Type field for order lines.

Note: If you are using Drop Shipment Across Ledgers / InterCompany transactions refer to the section Drop Ship Across Ledgers and Change Management Overview.

Additional Details for Drop Shipments of Standard Items

Scheduled Ship Date

When performing drop shipment of standard items, Order Management returns a scheduled ship date after the purchase release workflow activity completes.

Cascading Order Line Attribute Source Type

Additional Details for Drop Shipments of Models, Kits and Configurations

For ATO models or kits, the Default SO Source Type attribute is inherited from the model by all items within the model. For PTO Models, the Default SO Source Type attribute is NOT inherited.

The defaulting and cascading logic for the order line Source Type field is:

For order lines belonging to a ATO configuration:

Default the value for Source Type for top level ATO models based on the defaulting rule
When a new option is added to a configuration, Order Management will default the value for Source Type (for the new order line added) from the top level ATO Model line

If you wish to change the value of Source Type, you will need to change the value on the model line. Order Management cascades a change to the Source Type value for all child lines of a model. Additionally, Order Management does not allow the change of source type at the option /class or configuration item level, and the rules for not allowing a change to the Source Type value after certain checkpoints within order line workflows still remain valid.

For non SMC PTO order lines:

The default source type on the components of a non SMC can come from the defaulting source.
The rules for not allowing a change to the Source Type value after certain checkpoints within order line workflows still remain valid.

Order Management will not cascade the value of Source Type for non SMC PTO models and associated child lines.

Sourcing

Individual lines under a PTO model (excluding SMC PTOs), including order lines with included items under a model, class, or a kit are sourced and drop shipped from individual suppliers based on your the value of the order line Source Type, the Planning item attribute Make, Buy Type and on your sourcing rules for each of these items or models.

You can choose to source a portion of a PTO model internally. If several order lines within a non-ship model complete PTO model are sourced internally and some externally, Oracle Global ATP is used to schedule the internally sourced lines, but Schedule Ship Date for drop shipped order lines are always defaulted from the drop shipped order line Request Date.

Scheduling

When performing drop shipments for ATO models, Order Management will return a schedule ship date equal to the Request Date as part of the order line scheduling workflow activity.

Oracle Global ATP is not used to schedule externally sourced lines. If you change the Request Date, the change will not be reflected in the Scheduled Ship Date; you must change the Scheduled Ship Date manually.
A warehouse is mandatory for ATO models and associated child lines to complete the scheduling function.

Change Order Notifications

The Change Order Notification functionality within Order Management is suppressed for drop shipments of externally sourced ATOs items or models; no notifications are sent for order changes. Use the Sales Order and Purchase Order Discrepancy Report to note differences between the original sales order and its associated purchase order, and take the appropriate action.

If a change order or cancellation is made to order lines that contain a model, kit, or component of a model or kit, then the configuration is delinked.

If you to cancel a drop ship sales order line, you must ensure that no receipts have been created against the line.

If a partial receipt is created it will create a split line for the sales order; the remaining quantity not shipped becomes the quantity for the new, backordered split line. You will not be able to make changes to an externally sourced ATO Model once its configuration has been fully or partially received. However, if you wish to cancel the backorder order line, you can, provided the order line not been received.

Note: For remnant model lines and their child lines, cascading and configuration validation will not happen. Any changes that the user makes on any of the remnant lines will be treated as if the line is a standard line.

PTO remnants for drop shipments

With this release of Order Management, if you have an order with mixed order lines (both internal and external sourced), as soon as any order line for a mixed PTO model has been shipped or received, the model is made a remnant.

In order to process PTO models that contain mixed order lines, you should enable header level invoicing or use fulfillment sets in order to be able to invoice the PTO model when all the lines of the PTO model are shipped. Header Level invoicing does not enable individual order lines for invoicing until all order lines are available for invoicing, and fulfillment sets do not enable an order to be fulfilled until all order lines reach the Awaiting fulfillment workflow subprocess.

Requisition Import / Purchase Release

The Purchase Release order line workflow activity enables the creation of requisitions for ATO items, configured items, and shippable components of non SMC PTOs.

For additional details on how list price is defaulted during Requisition Import and Purchase Release, see Oracle Purchasing User's Guide.

Invoicing

If you currently invoice only complete models and kits, you should use header level invoicing, or manually place all lines of a configuration (model or kit) within a Fulfillment Set. If Fulfillment Set or header level invoicing is not used, Order Management functionality enables non-shippable lines to be invoiced as soon as the first shippable component (line) for an order is shipped, with the remaining order lines to be invoiced as they are shipped.

Validations

You cannot change the Source Type order line attribute for any options or classes of ATO configuration.
Order Management validates that the purchasing enabled item attribute is set (check box selected) for all order lines under an external ATO Model.
Order lines for a SMC Model will not be allowed to be dropshipped.
You will not be able to make changes to an externally sourced ATO Model once its configuration has been fully or partially received.

Workflow

If the source type of a model or ATO item is External, the branch on source type activity will branch to ATO item and build (for ATO model) branch respectively and will not progress to the dropship branch.
For configured items and ATO items, the CTO Create Supply - Line subprocess now validates the Source Type item attribute, and if the value is External, the Order Management Purchase Release workflow activity will autocreate Oracle Purchasing Requisitions.
If the source type of non-shippable components of a PTO or ATO model is External, the Oracle Purchase Release program will not insert records for these items within Oracle Purchasing interface tables. Instead, the line workflow for these items will be progressed to the next workflow additivity by setting the result to purchasing not applicable.

Sample Drop Ship Order Flows

Drop Shipments for Standard Items

Enter an order for a drop ship item.
Book the order.
Run Requisition Import.

Note: The Group Requisitions By Sales Order system parameter determines whether the Requisition Import process will import all the drop ship sales order lines into a single purchasing requisition even though the lines belong to multiple sales orders or whether the process will group all drop ship sales orders lines by sales order and then import them into multiple purchasing requisitions.

For more information on this Group Requisitions By Sales Order system parameter, see Oracle Order Management Setup in the Oracle Order Management Implementation Manual.
Create a purchase order from the requisition.
Approve the purchase order.
Receive against the purchase order.

Forward Drop Ship Flow for ATO Model
1. Enter a sales order for the drop shipped ATO model.
2. Select the options.
3. Schedule and Book the order (Schedule date will default to request date for all lines.)
4. Create the configured item by progressing the order ATO Model line or running the Autocreate Configuration batch process.
5. Verify order and line status.
6. Create Supply Order (Drop ship requisition) by progressing the configuration item line or running the Autocreate Dropship Requisition batch process.
7. Run the Oracle Purchasing Requisition Import to create a Purchase Requisition.
8. Create a Purchase Order for the requisition.
9. Approve the Purchase Order.
10. Receive the Purchase Order.
Forward Drop Ship Flow for ATO Item
1. Enter a sales order for the drop shipped ATO item.
2. Schedule and Book the order (Schedule date will default to request date for all lines.
3. Create Supply Order (Drop ship requisition) by progressing the configuration item line or running the Autocreate Dropship Requisition batch process.
4. Run the Oracle Purchasing Requisition Import to create a purchase requisition.
5. Create a purchase order for the requisition.
6. Approve the purchase order.
7. Receive the purchase order.
Non-SMC PTO Model with Drop Shipped Standard Options
1. Enter a sales order for the PTO model.
2. Select options; Source type on the components will default.
3. Schedule and Book the order.
4. Run requisition import to create a purchase requisition.
5. Create a purchase order for the requisition.
6. Approve the purchase order
7. Receive the purchase order
  
  See
  
  Drop Shipments Overview
  
  Copying Orders
  
  Order Import
  
  See Additional Sample flows under Drop Ship Across Ledgers and Change Management Overview
  
  For details on the required setup for a purchased item, see: Oracle Purchasing User's Guide, Oracle Inventory User's Guide, and the Oracle Configure To Order Implementation Manual.

Change Management for Drop Ship Orders

With enhanced change management support between Order Management and Purchasing, user initiated changes on the sales order will automatically trigger changes to the requisition or purchase order. If a change cannot be performed on the requisition or purchase order due to the document status, then your change will be rejected and an appropriate message will be issued.

Another aspect of change management comes from the purchasing or supplier systems. Buyers can make changes to the requisitions or purchase orders and the supplier system can also change the promise dates and quantities. With enhanced change management, changes on the requisitions and purchase orders will be synchronized with the sales order line. Certain types of changes like Ship To Location, etc. that were allowed earlier because of an asynchronous link between sales orders lines and purchase orders, will now be restricted.

Note: The Sales Order Purchase Order Discrepancy report contains Holds discrepancies between Order Management and Purchasing. With de-support of the Purchase Order Discrepancy Report, this information is no longer available.

Sales Order Changes

Sales order changes are supported as long as the purchase order can be changed. If the sales order line is linked to a requisition, which is not converted to a purchase order, then the requisition will be updated with the new changes. If the sales order line is linked to a purchase order that is not yet approved, then the purchase order is updated. Purchasing also allows changes on the purchase orders even if they are approved. Changes on approved purchase orders will re-trigger the approval process and the changes may or may not be approved. If changes are not approved, a notification will be sent to the CSR. If the purchase order changes are approved, then the changed purchase order is sent to the supplier, where the supplier can always reject the changes if the sales order in supplier's system cannot be changed or if the goods have shipped. For a drop ship sales order line, this could cause a problem as the sales order line could already be canceled. To handle the cases, where the system is not aware of the status of the order in the supplier system, Order Management has constraints that can be disabled. These constraints will restrict the sales order line changes once the purchase order is approved. Depending on the business and the relationship with the supplier, you can choose to disable the constraints to allow more flexibility for sales order changes, provided they also take the responsibility of handling any exceptions.

When a Drop Ship Sales Order line that is interfaced to Purchasing is changed, the change management process is started. If the requisition import is not run and the Purchase Requisition request is still in the Requisition interface, then the interface record will be updated. If a purchase requisition or purchase order exists for the order line, Order Management will accept the updated data elements and cascade the change to the requisition or purchase order if it is allowed, the same process will also start the change management/automatic approval process. If the requisition or purchase order cannot be changed due to the document status, then a message is given indicating the reason for failure. Data elements that are present on the purchase order will be updated directly on the requisition or purchase order.

When there is a partial receipt and the sales order line is split, the Sales Order Line number that is displayed in the drop ship tab on the PO shipment reflects the open sales order line, and the shipped quantity will display as null. However where there is a full receipt and the sales order line is closed, the shipped quantity will reflect the quantity delivered into inventory.

When a sales order line is cancelled, the corresponding requisition line has the following fields updated: Cancel flag is set to Yes and the amount is set to 0. When one or more multiple sales order lines are cancelled, the following updates are made to the requisition line: Cancel flag is set to Yes, Cancel Date is defaulted from system date, Cancel Reason has to be entered, and amount is set to 0.

Sales order changes are sent to the purchase order and then to the supplier including:

Cancellation
Request or Schedule dates
Order Quantity
Ship To Address

Changes can be made by the buyer or supplier.

Additional Sales Order Data Elements Sent to the Supplier

With enhanced Change Management, the following Sales Order Data Elements will be sent to Supplier:

Ship To Customer Name
Ship To Customer Address (Already supported)
Ship To Contact Name
Ship To Contact Phone Number
Ship To Contact Fax Number
Ship To Contact E-mail
Deliver To Customer Name
Deliver To Customer Address (All address information)
Deliver To Contact Name,
Deliver To Contact Phone Number
Deliver To Contact Fax Number
Deliver To Contact E-mail
Shipping Method
Shipping Instructions
Packing Instructions
Customer Product Description*
Customer PO Number
Customer PO Line Number
Customer PO Shipment Number

The following precedence is used to derive the Customer Product Description: User Item Description, Customer Item Description, and Generic Item Description. Purchasing will not store the Sales Order Data elements on the requisition or purchase order tables, instead the information is taken from the sales order lines whenever required.

All communication modes listed below will communicate changes to the additional sales order data elements to the supplier:

Printed Change Order Report
Printed PO Report
Fax PO
E-mail PO
EDI 860 (Change PO Outbound)
XML (CHANGE_PO)
iSupplier Portal

The following sales order line fields are directly interfaced to Purchasing and are available on the purchase requisition and purchase order: Ship To Location, Need By Date, Ordered Quantity, Ordered Quantity UOM, Project, Task, End Item, Ordered_Qty2, UOM2, Grade, Inventory Item. Additional data elements that are sent to the supplier are referenced and not stored on the Requisition or Purchase Order.

If the sales order line is still in Requisition Interface, all Field changes are supported and the record is updated in the interface record.

If the requisition or purchase order is already created, then following rules apply:

Only the primary quantity (Ordered Quantity) updates on a sales order line will trigger secondary quantity synchronization changes in Purchasing.
Purchasing will synchronize a secondary quantity (Ordered_Qty2) only if there is a one-to-one mapping between the sales order and requisition/ purchase order and if the UOM's are same. If the secondary quantity cannot be automatically synchronized with the sales order, then Purchasing will derive the secondary quantity based on the standard conversion. In other words, If the Item is dual UOM controlled, then all the dual UOM controls (Fixed, Default, No Default) will be handled as a Fixed control and will use the standard conversion.
Grade will not be automatically synchronized between Order Management and Purchasing. You can change the grade both in Order Management and Purchasing.

Ship Method Information Passed to Purchasing

The purchase requisition for Drop Ship orders currently contains the Shipping Method. The Shipping Method in Order Management dictates how a package will be shipped to the customer. Since the purchase requisition contains the ship method, the drop ship supplier now has visibility to the customer's desired shipping method. For instance, if customer A wants their sales order as soon as possible, the ship method on this order would let the person who is ship confirming the order know to ship it, overnight via air. If customer B indicates that they are in no rush to get their order, the ship method on their order would let the person ship confirming the order know to ship the order, via ground service.

Shipping Information Passed To the Drop Ship Supplier

Customer specific shipping instructions are captured when the original sales order is placed Order Management. This information is forwarded to the purchase requisition and subsequent purchase order. For warehouse-based shipments, the shipping information is converted into supplier shipping instructions and passed to the supplier as part of the purchase order shipping instructions. The purchase order information adheres to EDI, XML, industry standard interface requirements and iSupplier Portal. All the relevant customer information on the sales order is available for the shipping organization.

The following data elements from the sales order shipping information are available to all associated drop shipped suppliers:

Ship To Customer Name
Ship To Customer Address
Ship To Customer Contact Name
Ship To Customer Contact Name Phone Number
Ship To Customer Contact E-mail
Deliver To/For Use At Customer Name
Deliver To/For Use At Customer Address
Deliver To/For Use At Customer Contact Name
Deliver To/For Use At Customer Contact Name Phone Number
Deliver To/For Use At Customer Contact E-mail
Shipping Method
Shipping Instructions, Packing Instructions
Customer PO Number, Customer PO Line Number

Note: The Ship To and Deliver To addresses may be different for a customer. Also, the customer name may be different at the Ship To address from the final Deliver To customer name.

Visibility of Sales Order Number and Data Fields in Purchasing

Buyers can see the sales order line details in the new Drop Ship tab added to the Shipments block of both the Enter Purchase Order window and the Enter Releases window.

Following sales order information is displayed on the Purchasing Drop Ship tab:

Sales Order Number
Sales Order Line Number
Sales Order Line ordered quantity
Sales Order Line shipped quantity
Sales Order Line status
Ship To Customer Name
Ship To Customer Contact
Sales Order Line Status

A new menu option called View Sales Order is on the Purchase or Release Shipment windows. A buyer can invoke this option to view Sales Order information such as customer or shipping details, if the Purchase Order Shipment references a requisition line associated with a Drop Ship Sales Order line.

Following new status details are available for order tracking:

PO Req Requested

PO Req Created

PO Created

PO Received

The requisition or purchase order status is available on the Drop Ship tab of the Additional Line Information window.

Purchase Requisition Changes

The buyer cannot change the following data elements on purchase requisitions that are linked to a Drop Ship Sales Order:

Inventory Item
Ship To Location (Deliver to in PO).
UOM
Quantity
Need By Date
Warehouse (Ship To Org)
Project and Task Information

In addition, Drop Ship Purchase Requisitions cannot be returned to the requestor. Normally, buyers can return the requisitions to the requester and no action will be performed. Splitting the purchase requisition is also not allowed for the buyer. Purchase requisitions linked to a sales order cannot be canceled or finally closed.

Purchase Release

The Purchase Release program passes information about eligible drop-ship order lines to Oracle Purchasing. You can run this program for one Operating Unit at a time by specifying a value for the Operating Unit parameter or run it for all Operating Units that you have access to by leaving the parameter blank. For more information on MOAC in concurrent programs, please refer to the Appendix on Concurrent Programs.

This program processes purchase releases for drop ship sales order lines, even if the user who initially created these orders is terminated as an employee, based on the value of the Requestor For Drop Ship Orders Created By Inactive Users system parameter. See Seeded System Parameters, Oracle Order Management Implementation Manual.

After Purchase Release has completed successfully, run Requisition Import in Oracle Purchasing to generate purchase requisitions for the processed order lines.

The Purchase Release program is equivalent to the purchase release workflow activity. You need to use the Purchase Release program only if you have designed your workflow to make all the lines eligible for purchase release and then want to pick up the lines. The seeded workflow handles the purchase releasing of the lines as the flow reaches the deferred workflow activity and the workflow engine picks up the lines.

Note: With Drop Ship Across Ledgers functionality Purchase Release will now create the Purchase Requisition in the Operating Unit of the Warehouse, if the Warehouse on the Sales Order does not belong to the Operating Unit where the where the Sales Order is created.

Holds Effect on Eligible Order Lines

The Purchase Release program does not process orders or order lines with unreleased holds that specify no workflow activity or a workflow activity of Purchase Release. You must remove any such holds on orders or order lines that you want to interface to Oracle Purchasing.

Workflow Activity Results

The following workflow activity results are possible for Purchase Release:

Eligible: The order line has booked successfully and has a source type of External
Complete: Order line information has interfaced successfully to Oracle Purchasing
Incomplete: The order line does not have enough information to release to purchasing

Additional Information: Note: If purchase Release activity could not be completed because of: 1. A hold on that line. 2. Incorrect employee setup. 3. The Deliver to Location is invalid. 4. The Item attribute setup is incorrect. then the Purchase Release concurrent program completes with a Warning instead of an Error.

Prerequisites

Before using this program, you should:

Enter and book an order with lines that you want to fulfill externally
Satisfy any other order or order line prerequisites that you have defined for the order flow activity

Submission

In the Purchase Release window, enter Purchase Release in the Name field, or select the Purchase Release, Requisition Import request set.

Parameters

When you request Purchase Release, Order Management provides you with the following parameters.

Order Number (Low/High)

Select an order number or range, or leave this parameter blank to run the program on eligible lines on all orders.

Request Date (Low/High)

Select a range of order request dates, or leave this parameter blank.

Customer PO Number

Select the number that corresponds with the purchase order received from your customer, or leave this parameter blank.

Ship-To Location

Select the ultimate location to which the line or lines will be delivered, or leave this parameter blank.

Order Type

Select a specific order type, or leave this parameter blank.

Customer

Select the customer associated with the order, or leave this parameter blank.

Item

Limit processing to a particular item, or leave this parameter blank.

See:

Oracle Purchasing User's Guide, Requisition Import Process

Drop Shipment Processing

Defining Sales Order Line Services Information

Order Management enables you to order services from the Sales Orders window. You can order services for product items currently being ordered, such as immediate services, or you can order services for already installed product items or delayed services.

At the time of ordering the service, you can specify the billing option and billing frequency of the periodic billing. Based on the selected frequency, the application generates the billing schedule invoices accordingly. You can specify the service level like Gold and Silver while ordering the service from Order Management using the service coverage template.

Additionally, you can order subscription services and specify service related attributes such as service start date and duration, which the application uses to fulfill the subscription line as a service line. You can order tangible and intangible subscriptions. Order Management supports subscription services as Model or part of the Model like optional or mandatory item. You can select the subscription service in the Configurator for fulfilling the subscriptions as service line and interfacing to Oracle Service Contracts for service contract creation. To achieve this functionality, you must set up defaulting rules for service attributes like service start date, service duration, and service subscription template before the configuration of subscription service. The defaulting rules are required if you do not provide the values for Service Start Date, Service Duration, Service Period, and Service Subscription Template during the time of booking. You can use the Configurator while the order is in entered status and provide values for these fields manually (without setting up the defaulting rules), before the order is booked. The system prices tangible and intangible subscriptions based on the subscription period, subscription frequency, and the quantity in each subscription. The flexible billing options available for service items like extended warranty are available for subscription service items as well. You can order extended warranty on subscription services.

Subscription services are similar to extended warranty service as you can create a new subscription service contract while creating a new subscription line or attach a new subscription line to the existing subscriptions contract at the time of ordering the service. Order Management does not interface freight charges on the order to Oracle Receivables for service lines when billing is done from Oracle Service Contracts for service items and subscription services.

You can order subscription services without any coverage level or covered product. You can mass change the billing profile, coverage template, and subscription template. Additionally, you can set defaulting rules and processing constraints for service item and subscription related fields such as billing option, billing profile, coverage and subscription templates. In Service Contracts, you can query subscription orders with contract category as 'subscription agreement' and by providing sales order number to view the contract created by a sales order in Order Management.

You can also order subscription services in the Sales Order window as a promotional good. To order subscription services as a promotional good you need to define an Advanced Pricing modifier using a "Promotion" list type and entering the subscription service as a get item. When entering the subscription service as a get item you can specify its service duration, service period, and subscription template. For example, let us say that when a customer orders a laptop they will receive one year of internet service for free. For this example, you would need to define a promotion modifier so that when you order the laptop item the internet service (subscription service) is the get item. Then when you go the Sales Order window and order the laptop item the internet service (subscription service) is automatically added to the sales order as well.

Process Order API

For a Subscription Item, if the subscription_enable_flag is set to "Y", then the Process Order API creates the line as a Subscription Service Line. The Process Order API does not honor the value of the Default Behavior for Subscription Item on Order Line system parameter. If no values are passed to this API, then it honors the defaulting rules if you have set them.

Order Import

For a Subscription Item, if subscription_enable_flag is set to "Y", then the Process Order API creates the line as a Subscription Service Line. The Process Order API does not honor the value of the Default Behavior for Subscription Item on Order Line system parameter.

When importing kits/models from external systems, if the PRE_EXPLODED_FLAG on the top kit/model line is set to "Y", then the Order Import process will import the kits/models and the associated included items for those kits/models into Order Management. Included items could be subscriptions and the details for the subscriptions such as start date and end date. The PRE_EXPLODED_FLAG indicates whether the BOM component is exploded outside and imported to Order Management as a pre-exploded component.

High Volume Order Import (HVOP)

HVOP does not support creation of services and subscription services.

Order Management enables you to:

Order service and subscription service lines along with the product lines.
Capture additional service related attributes for extended warranty lines including billing profile and coverage template.
Import service lines and service orders using order import.
Generate invoice for the first bill period.
Perform applicable operations that the application applies to any other order, including billing.
Enter service for all serviceable options in a configuration once.

Workflow

Order Management enables you to utilize Oracle Workflow to manage the service lines with service item types. Service lines are non-schedulable and non-shippable. You can assign a workflow process that does not include these two functions for service lines using the Oracle Workflow Assignments window. With Oracle Workflow assignments, you can have a combination of line and item types assigned to a workflow process; this enables you to customize the workflow process to meet your business needs.

See: Oracle Order Management Using Oracle Workflow in Oracle Order Management.

Applying Changes

When you apply duration-related changes to the service order line, Order Management automatically applies those changes to the associated service order lines in the configuration. You can change the individual option lines directly. Enter the price adjustments and sales credits for all service order lines in a configuration simultaneously. When you apply changes to the price adjustments and sales credits, Order Management automatically applies those changes to the associated service order lines in the configuration. You have the option of changing the individual service option lines directly.

Decimal Quantities

Order Management enables you to enter service items for quantities less than a unit rather than defining a unit of measure (UOM) to represent the partial quantity in the Sales Orders window. See: Decimal Quantities.

Percent-Based Pricing

Order Management enables you to structure the pricing of service as a percent of the product with which it is associated.

Shipping

Order Management, Shipping, and Oracle Service provide you with the ability to synchronize the start of a service program with the shipment of an associated product.

You can define the Service Starting Delay when you define serviceable products in Oracle Inventory. The Service Starting Delay represents the time in days an included warranty is offset to commence after the shipment date. The start date of the support service is the ship date plus the starting delay. The end date is calculated by adding the duration to the start date of the support service. This is applicable for included warranties and not extended warranties (service programs).

Payment Terms

Order Management enables you to specify payment terms for ordered service to be different from the associated product. You can specify the payment terms on each order line.

Related Customers

You can support entry of related customers for services in either of the following ways:

Support ordering services referencing Installed Base products for a customer other than the one ordering the service.
Support ordering services referencing sales order lines sold to a customer other than the one ordering the service.

Depending on the value of the system parameter Customer Relationships (Service), you can facilitate ordering services for products sold to a different customer. The customer may be a related customer (related through Account relationships and not Party relationships).

If the value of the system parameter is Single Customer, then you can not enter related customer information for service products referenced in the Installed Base. Order details would be for the same customer only. Similarly, you can reference a sales order line belonging to the same customer only.

If the value of the system parameter is Related Customer, the related customer can order services for the item specified by the original customer. That is, any customer that has an account relationship (not a party relationship) with the original customer can order services referencing the item specified by the original customer.

If the value of the system parameter is All Customers, you can order services for items sold to any customer.

Contract Details window

For more information on viewing the warranties created, please refer to the Oracle Service Contracts User Guide.

Service Availability Rules

For more information on using service availability rules, please refer to the Oracle Service Contracts User Guide.

To Define Sales Order Service Information:

Enter a service item in the Line Items tab of the Sales Orders window. For the service item, all the service related columns will be enabled in the Services tab.
Navigate to the Line Items, Services tabbed region.
Select the Service Billing Option. Options are:
- Full Billing from Order Management: This option enables Order Management to invoice interface the complete line amount to Oracle Receivables. If you do not select any option, then Order Management considers it as full billing from Order Management.
- Full Billing from Service Contracts: This option skips invoicing from Order Management. There is no invoice interface for this line and Service Contracts bills completely as per the billing schedule. The workflow activity Invoice Interface is "Not Eligible" and ends with status as "Billed from Contracts". For line level payments, there is no amount available for which a payment has to be made since Service Contracts generates the invoice. For order level invoice payments, the payment can be made only for the amount that is billed from Order Management. At order payment level, Order Management does not perform credit card authorizations for the amount which is invoiced through Service Contracts. Service Contracts performs authorization as appropriate at the charging or billing phase.
- First Period Billing from OM, Subsequent from Contracts: This option results in Order Management invoice interfacing the first period billable amount to Oracle Receivables. Oracle Service Contracts performs the subsequent billing as applicable. Service Contracts provides the "Service First Period Bill Amount" and "Service First Period End Date" values and Order Management retains them on the line. Order Management invoice interfaces the First Period Amount to Oracle Receivables for Invoice and the First Period End Date. The application does not invoice any freight charges on a service line or adjustments separately to Oracle Receivables to be in sync with Services Contracts which does not invoice freight charges nor display adjustment details in the subsequent invoices. It treats the Show Discount Details on Invoice system parameter always as "No". Order Management invoice interfaces any freight charges at the sales order level only if there is at least one line in the sales order that needs to be billed from Order Management. The application does not consider the freight charges on the line level in the total for order and line level payments. For payments performed through a credit card, the application performs credit card authorization for the first period billing amount and not for the line amount (corresponding to whole duration of the service). Additionally, it calculates the tax on the sales order line for the entire line amount and not for the first period amount. Thus while performing Invoice payment, the application considers the tax for the entire period.
  
  You can default the billing option using the Order Management Defaulting Rule functionality. If you set up the defaulting rule for Billing Option as "First Period Billing from OM, Subsequent from Contracts", then you can use the billing profile having one time billing to have the complete billing performed from Order Management rather than changing the billing option every time.
Note: For Subscription service as "Included" item type (when inside a model), the Service Billing Option field has no value and is non-updateable.
Select the Service Billing Profile.

Select the billing profile from the list of values that displays all profiles for the bill to customer on the order line as well as the generic billing profiles (where customer/site is not attached to the billing profile). Service Contracts uses this value for creating a contract. The field is enabled only for Extended Warranty and Subscription Service lines. The field is mandatory if you select the service billing option as "First Period Billing from OM, Subsequent from Contracts" or "Full Billing from Service Contracts". If you select the billing option as "Full Billing from Order Management", then the Service Billing Profile field is disabled. You can update the billing profile on the order line when line status is either "Entered", "Booked" or "Awaiting Fulfillment" and it is yet to be interfaced to Oracle Service Contracts. You can select a different service billing profile for each line on the sales order. When the application creates a new service line for a new or existing service contract from a sales order line, then each service line is created has its own billing schedule in Oracle Service Contracts as per the billing profile that you select here. You can default the billing profile using Order Management Defaulting Rule functionality. Ensure that you have defined billing profiles in Oracle Service Contracts.
(Optional) Select the Service Coverage Template.

Select from the list of values that displays all active templates. Service Contracts uses this value for creating the contract. The field is enabled only for Extended Warranty lines. You cannot edit or update the coverage template details in Order Management. If you do not specify a template in Order Management, then Oracle Service Contracts populates the value. You can use this field as a custom pricing attribute to price the Extended Warranty line based on the coverage provided, for example Gold Coverage or Silver Coverage. You can update the coverage template on the order line when line status is either "Entered", "Booked", or "Awaiting Fulfillment" and it is yet to be interfaced to Oracle Service Contracts. Ensure that you have defined service coverage templates in Oracle Service Contracts.
View the Service First Period Bill Amount.

This is a display field that you cannot edit. If you select "First Period Billing from OM, Subsequent from Contracts" as the service billing option, then Order Management calls the Service Contracts API to get the first period billable amount and stores it in this field. Order Management invoice interfaces only for this first period bill amount. This field has no value if billing option is "Full Billing from Order Management" or "Full Billing from Service Contracts".
View the Service First Period.

This is a display field that you cannot edit. If you select "First Period Billing from OM, Subsequent from Contracts" as the service billing option, then Order Management calls the Service Contracts API to get the first end date and stores that value in this field. For Partial Period Revenue Recognition, Order Management interfaces the Service First Period End Date to Oracle Receivables. The field has no value if billing option is "Full Billing from Order Management" or "Full Billing from Service Contracts".
Select the Service Subscription Template.

Select an active subscription template defined in Service Contracts. This is a mandatory field on a subscription service line if the sales order is Booked. This template determines the service frequency and thereby pricing of the line. For example, a monthly subscription for a period of 1 year is priced for 12 items whereas a yearly subscription for a period of 1 year is priced for only 1 item. The field is not enabled for any non-subscription service line. You can update the subscription template on the order line when line status is either "Entered" or "Booked" and it is yet to be interfaced to Service Contracts. For a subscription service line, Subscription Template, Service Start Date, and Service End Date fields are mandatory and are used to derive the price. You can optionally enter the Billing Option and Billing Profile fields.
Select the Subscription Service check box to enable or disable this option

When you enter a subscription item on the order line, then based on the default behavior for the Subscription Item system parameter, the system populates this check box. You can modify the value before saving the line. After saving the line, you cannot change the check box value and the order line progresses according to the applicable workflow. If you clear the check box, then the line progresses as standard shippable line. If you select it, then the line progresses as a subscription service line in Order Management and Oracle Service Contracts creates it as subscription line type. For any order coming from an external source such as ASO API, Order Import, and direct Process Order API, the Subscription Service check box is not selected by default.

Note: For a subscription item as a part of Model, if the default behavior for the Subscription Item on Order Line parameter is set to "Subscription Service Line", then the application treats the line as a Subscription Service Line. After saving the line, you need to revisit the Configurator for a change to BOM configuration (you need to set this system parameter according to your business requirement). The check box is enabled only if the item on the line is a Subscription Item (in Item Master, the "Contract Item Type" in Services tab must have a value of "Subscription"). For a Subscription Service line, there is no interface performed by Order Management to Oracle Install Base for IB Instance creation. Oracle Service Contracts creates the instances when the subscription contract gets created. There is no scheduling involved for Subscription Service Lines and the Scheduling Organizer does not display them.
Enter the Service Reference Type.

There are two service reference types: Sales Order and Customer Product.

For sales orders, the Service Ref Order Number field consists of the following columns:
- Order Number
- Order Type
- Customer Number
- Customer Name
For customer products, the Service Ref Cust Product field consists of the following columns:
- Product:Serial#:Reference#
- Description
- System
- Customer Number
- Customer Name
Enter the Service Order Type.
Enter the Service Reference Order and Line Numbers if the service reference type is Sales Order.
Enter the Service Reference Shipment and Option Numbers if the service reference type is Sales Order.
Enter the Service Reference Customer Product and System Name if the service reference type is Customer Product.

Note: The Service Ref Serial Number field is a folder enabled field and not displayed by default on the Services tab. You can display this field on this tab using the folder functionality. If you know the serial number for the product you can select it using the Service Ref Serial Number field. If you select the serial number using this field, the Service Reference Customer Product field is automatically populated from the serial number selection you made using the Service Ref Serial Number field.
Select the Service Coterminate Flag check box to disable or enable this option.

Use the Service Coterminate field to set the same end date for all service programs sold to a particular customer or grouped into a specific system. You can also use the Service Coterminate Flag check box to end date the subscriptions lines of a contract. Refer to the Oracle Service Contracts User Guide for more information.
Enter the Service Start and End Dates.

The Service Start and End Dates fields determine the start and end dates of the service program.
Enter the Service Duration and Period.

The Service Duration field determines the duration of the service program. You need to enter either this field or the Service End Date field.

The Service Period field determines the period of the service program such as day, month, or year.
Enter the Service Txn (Transaction) Reason and any additional Service Txn (Transaction) Comments for the order.
Save your work.

Note: This functionality is also available in the Quick Sales Orders window.

To Order Subscription Services as a Promotional Good

Define a subscription service item using the Master Item window.
1. Navigate to the Master Item window.
2. Define the subscription service item. In the Service tab, select Subscription in the Contract Item Type field in the Service Contracts region.
Define the Advanced Pricing Promotion Modifier using the Advanced Pricing - Define Modifier window by selecting the Subscription Service check box at the line level for the subscription service item as a get item when ordering another item.

Also enter the Service Duration, Service Period, and Subscription Template for the subscription service item in the Get region. When the Subscription Service check box is selected, the Service Duration, Service Period and Subscription Template fields are mandatory as they are used in calculating the price of the subscription service get item. If you do not enter this service information here then you need to enter it when creating the sales order.

For more information on defining a promotion modifier, see Promotional Goods in Modifier Type Setup, Oracle Advanced Pricing Implementation Guide.
Create a sales order for the item which has the subscription service item as a promotional good using the Sales Orders window and save the order.

A message will display letting you know that a line has been created on the sales order for the promotional good (subscription service).
Enter the additional fields (service start date) required for the subscription service item in the Services tab. The Service Subscription Template, Service Start Date, Service Duration, and Service Period fields are required before you can book the sales order.

Note: To simplify the process, you can enter defaulting setup rules to populate the additional fields required for the subscription service item.

For more information on defaulting setup rules, see Define Defaulting Rules, Oracle Order Management Implementation Manual.
(Optional) View the adjustments that were made to the sales order for the promotional good.
1. Select the line item for the subscription service
2. Click the actions button and select View Adjustments
Continue to process the sales order per the standard sales order processing steps.

Service Termination Overview

Service items are traditionally defined as agreements to provide service such as extended warranties. The ability to terminate a service item and credit the customer is a common business requirement in many industries.

Order Management interfaces to Service Contracts via the Fulfillment workflow activity (Fulfill Line). This activity populates the Service Contracts interface table. You need to run the Service Contracts Order Processing concurrent program to process the interface records.

When a serviceable item is returned for credit, whether the customer is credited for the extended warranty depends on the value of the profile OKS: Raise Credit Memo for IB Instance Termination. Additionally the amount of credit issued is determined by the Global Contracts default setting. This can be overriden at the serviceable item return line level via the workflow activity Set Order Line- Service Credit. You can use this activity to set the service_credit_eligible_code to a value of Full, Pro-rated or None.

Service Termination Major Features

Ability to Terminate a Service Item When a Product is Returned

You can terminate a service item when a product is returned. The Source transaction (RMA) will be responsible for determining if a credit is issued for service when a service is terminated in Service Contracts.

OM automatically qualifies an RMA line for service credit when a product is returned for credit and processed in OM. Currently, when a product is returned for credit in OM, Install Base changes the ownership of the item instance to internal organization and also terminates the associated warranties & extended warranties for the product by calling Service Contracts. Install Base also determines if the termination of service for the product item should result in Issue/Non-Issue of credit by looking at the product item in OM.

Issue a Full or Partial Credit for Service Lines

An indicator shows that a full credit (100%) should be issued for service of the return line (product item). This control is introduced initially as a profile option in Oracle Service Contracts and can be set at the Responsibility or Site levels. Oracle Order Management uses the existing integration between Order Management, Install Base and Service Contracts to terminate the service. For more information on service termination, please refer to the Oracle Service Contracts User Guide.

User Procedures

To set up for Service Termination:

Set the profile option OKS: Full Credit for Product Return for full or partial credit of service lines within the Service Contracts application. The profile option can be set at Site level.

To terminate a service item when a product is returned for credit only with Reference:

Navigate to the Sales Orders window.
Enter the header information including: Customer Name, Order Type = Return or Mixed.

Note: An order type with an order category of "Return" or "Mixed" with a Line Type which has a Return flow should be setup. Order Management does not seed order/line types.
If you do not want to return the full quantity of the line item, change the quantity to a lesser amount on the line.
In Line Items tab, enter the Product Item number, choose the Returns tab, enter Line type = Return for Credit Only. Click the Reference field, enter the Referenced Type = Sales Order, enter the sales order number and line number. Enter a return reason. Also, enter the installation details for the return line.
Book the return.
The Order Management Fulfillment workflow activity runs in the background to progress the product lines.
The Order Management Install Base Interface runs in the background to progress the product lines.
When returning a service item, the Install Base terminates related service contract lines based on the IB transaction types. The IB will let the Service Contract API automatically pro-rate credit based upon termination date or issue full credit based on the profile setting. This is an automated flow and no manual override of credit amount is allowed. The service lines are interfaced to AR from the Service Contracts application to issue a separate credit for them in OKS.
The product lines progress to the Invoice Interface workflow activity in Order Management. This activity is run in the background and AR will pick up the product lines for invoicing and issue a credit for them in Order Management.

Defining Sales Order Line Project Manufacturing Information

Order Management enables you to plan, schedule, process and cost material and labor against a specific customer contract. You can capture project and task information on sales order lines by utilizing the Sales Orders window.

Note: You have to have Project Manufacturing fully installed to enable the Project to be selected within the Project field.

To define project manufacturing information:

Navigate to the Line Items, Others tabbed region in the Sales Orders window.
Select a Project Number.

If the warehouse's Project Control Level is set to Project in Oracle Inventory, enter a Project Number prior to booking.
Select a Task Number.

If the warehouse's Project Control Level is set to Task in Oracle Inventory, you must enter a Task number if you selected a Project.
Select an End Item Unit Number.

Model/End Item Unit Numbers are used to identify part configurations. A part's configuration can be changed or its parent-component relationship altered for a specific effectivity.

Project and Task Cascading

Project and Task changes, if specified at the top model level, are automatically cascaded to all options lines for the top model. However, in the case of ATO sub-assemblies, Project and Task cascading are enabled when these changes are specified at the respective Project or Task level.

For example, an ATO sub assembly my be an option of a top model. Any changes to Project and Task for any other option will not be allowed.

Sales Orders Customization

Defining Sales Order Main and Other Header Information

Defining Sales Order Line Item Main Information

Defining Sales Order Line Shipping Information

Defining Sales Order Line Addresses Information

Defining Sales Order Line Return Information

Defining Sales Order Line Services Information

Defining Sales Order Line Project Manufacturing Information

Defining Sales Order Line Release Management Information

Oracle Project Manufacturing User's Guideand Oracle Project Manufacturing Implementation Manual.

Defining Sales Order Line Release Management Information

Order Management enables you to manage changes to demand which are not authorized to ship. A demand can be planned to shipped on the date scheduled, but not sent to customers until an authorizing event occurs such as the removal of any holds on demand. Authorization can take place through responding to a workflow notification. You can also make changes to attributes like quantities, dates and times for a demand authorized to ship.

Timestamp

You can timestamp all date fields including the request date, schedule date and promise date. The request date can represent either the ship date or delivery date.

Configurations

Order Management enables you to perform changes to a configured order. For ATO and PTO Ship Model Complete configurations, all the related lines will have the same status as that of the parent model line. For example, if the parent model line has a Not Authorized to Ship status, then all the related lines in the configuration which is in a ship set will have the same status of Not Authorized to Ship.

Processing Constraints

You can restrict a given user from making changes to the attributes of the demand after a given action is performed. For example, users can be prevented from making changes to the quantity ordered if the demand has already been shipped. You can apply any processing constraints on the demand lines interfaced, in addition to the Order Management's processing constraints on any changes made to an order.

Customer Item Cross Reference

You can query, view, enter, and report cross references for order lines using either the internal item number or customer item number. When viewing or reporting on orders, you will be able to view the customer item cross references. You will be able to find orders or lines by specifying a customer part number.

View Current Demand

You can exclude closed order lines when reviewing an order. You have the ability to view either all lines, only open order lines or closed lines while reviewing the order in the Find Orders window. You can view an order that has no open order lines.

You have the option to specify whether an order that has no open order lines will remain open or closed. You can define holds on activities such as close lines and close orders. You can apply these activity specific holds to prevent an order with no open lines on it from being closed.

Deletion of Booked Lines

Order Management supports the deletion of booked lines. However, you cannot delete lines once the order has been invoiced or pick released.

Cancellations

An update to the quantity is processed based on the increment/decrement to the attribute. Process Order updates order lines and performs a security validation to check for any violations. The order is committed immediately so the Release Management can process all or none of the order lines.

Order Purge

You can purge closed released management orders from Order Management if it meets all order purging criteria.

Note: Order Purge functionality is provided with Oracle Order Management. The Purge Orders concurrent program enables you to purge selected closed orders and their workflow history.

To define release management information:

Navigate to the Others tabbed region within the Line Items tab.
Enter the customer job.

Note: Customers who use the functionality of Customer Job, should create a Custom Index on the column 'CUSTOMER_JOB' of OE_ORDER_LINES_ALL table in their schema.
Enter the customer production line.
Enter the item's model serial number.
Enter the customer dock to which the item will be delivered.
Select an intermediate ship to location.
Enter the RLM (Release Management) schedule type.
Save your work.

Required Fields for Entering Orders

The following tables show the fields for which you must provide values when entering or booking an order. You can achieve this by defaulting information according to your defaulting rules, as well as by entering values in the Sales Orders window, copying data from an existing order or return, or using Order Import. You can book an order that contains no order lines, provided you have entered or defaulted all required values.

See:

Copying Orders

Order Import

Order Information, Main tabbed Region

The following table lists Order Header attributes available from the Main tabbed region of the window, and when a value must be provided for an order or return.

Order Header Attributes Available from the Main Tabbed Region
Attribute	When required
Customer Name or Number	Booking
Order Number	Entry (system-generated)
Order Type	Entry
Customer PO Number	If Order Type requires; Booking.
Salesperson	Booking
Ordered Date	Booking
Ship To Location	Booking (not required for Return)
Bill To Location	Booking
Transaction Phase	System generated if not defaulted
Agreement	If Order Type requires; Booking.
Price List	Booking
Payment Terms	Booking (not required for Return)
Currency	Entry
Conversion Type	If Currency entered is not your functional currency; Booking
Conversion Date	If Conversion Type entered is User; Booking
Conversion Rate	If Conversion Type entered is User; Booking
Tax Handling	Booking
Tax Reason	If Tax Status is Exempt at Entry
Payment Amount	If Payment Type requires
Check Number	If Payment Type requires
Credit Card	If Payment Type requires
Credit Card Holder	If Payment Type requires
Credit Card Number	If Payment Type requires
Credit Card Expiration Date	If Payment Type requires
Credit Card Approval Code	If Payment Type requires

Order Line

The following table lists Order Line attributes available from the order lines window and when a value must be provided for an order or return.

Order Line Attributes Available from the Order Lines Window
Attribute	When required?
Line Type	Entry
Line Number	Entry
Shipment Number	Entry
Item	Entry
Quantity	Entry
Unit of Measure (UOM)	Booking
List Price, Selling Price, Price List	Booking (except for configured items)
Customer	Booking
Ship To	Booking (not required for Return)
Bill To	Booking
Payment Term	Booking (not required for Return)
Tax Handling	Booking
Tax Date	Booking
Tax Code	Booking, when Tax Handling is Required or Calculate Tax is set to Yes
Service Duration	Booking, only for service lines
Task	Entry, depending on Project Control Level
Tax Reason	Entry, if status is exempt
Request Date	for order lines, required at Scheduling. Scheduling occurs before Booking. For return lines, required at Booking
Return Reason	Entry (only for entering returns)
Warehouse	Booking (only for entering returns)

Sorting Order Lines within the Sales Order window, Lines Tab

You can choose to sort sales or return order lines within the Sales Order window, Lines tabs by criteria you specify, or display order and return lines sequentially by line number (default).

If you wish to sort order or return lines, choose to sort by selecting from one, two, or three order attributes. Each attribute chosen can be qualified for additional sorting by ascending or descending order. The default sort order qualifier is ascending order.

Additionally, choose to suppress the display of either closed or cancelled order lines by selecting the corresponding check box. If you select either the Closed or Cancelled check boxes, closed or cancelled order lines will not be displayed when the sort is completed.

To perform order line sorting within the Sales Order window, Lines Tab:

Navigate to the Sales Order window, Lines tab.
From the Folders Menu, select Sort Data

Order Lines Sorting Criteria Window
Select at least one order attribute to sort order or return lines. You can choose to sort order lines using any combination of one, two, or three order attributes.

Select the initial sort order attribute in the Order By field, and any additional order line attributes for additional sorting within the Then By fields. The LOV for all sort fields is based upon order attributes within the database view definition OE_ORDER_LINES_V.
Choose to qualify the sort order display for each order line attribute selected. Select from:
- Ascending: Sequentially display order lines sorted in ascending (lowest value to highest value) order.
- Descending: Sequentially display order lines sorted in descending (highest value to lowest value) order.
Choose to display only closed or cancelled order lines when sorting by selecting the Closed or Canceled check boxes. The initial value of the Closed and Cancelled check boxes is determined by the value of the profile options OM: View Closed Lines and OM: View Cancelled Lines, respectively.
Select OK to initiate order line sorting or click Cancel to close the order line sort window.

Booking a Sales Order

Booking a sales order indicates that the order entry process is complete and that the customer has committed to the order. Booking is required before the order or return can advance to the next workflow activity.

Note: Within Order Management, you can book an order without defining a single order line for the order.

To book an order:

Navigate to the Sales Orders window.
Enter the header and line level information for a new order, or query an existing order.
Click Book Order.

Booking validates that all required fields for an order are entered. See, Section on Required Fields for an Order for details about the required fields. If validation succeeds, a confirmation message will appear that the order has been booked, and the order will proceed to subsequent workflow activities. If validation fails, the Process Messages window will display messages about the validation failure. You can choose to:
- Select Continue or Cancel - the window will close and control will be returned to the Sales Order window.
- Select Save Messages - the messages will be saved and can be queried later using the Process Messages window.
- Select Notify - the notification window will be displayed to enable you to send a notification to a selected responsibility.
  
  Note: Booking occurs for all order lines of an order at the same time; you cannot have booked and unbooked lines within the same order.
  
  Changes may be made to a booked order (depending on the processing constraints which are defined) and these changes may include the addition of new order lines. When an order line is added to a booked order, the entire order will undergo booking validation as the order is saved.
  
  To progress an ATO Model (Create config item) after booking, it is mandatory that a defaulting rule exists for Accounting duration. For standard items and PTO models this is not applicable.
  
  After booking the order, the application may not display the tax amount and the tax code may change to location at line level. This is due to the predefined dependency between schedule ship date and tax date. This dependency triggers the clearing and re-defaulting of tax code whenever you change the schedule ship date. Additionally, schedule ship date can change as part of scheduling activity through workflow. To disable the dependency between schedule ship date and tax date, see Dependencies, Oracle Order Management Implementation Manual.
  
  When order booking fails and if profile OM: Raise Status Change Business Event is set to Yes, , then the application raises the oracle.apps.ont.oip.processfailure.update business event with the following parameters:
  - name: 'PROCESS_NAME', value: 'BOOK_ORDER'
  - name: 'HEADER_ID, ' value: header__id of order for which booking failed
  - name: STATUS_CODE, value: flow_status_code of order This business event is for the order header and line ID has no value.
  Only the sales orders customizations mentioned here are supported by Oracle Order Management.

Related Topics

See:Booking

Oracle Order Management Suite Implementation Manual, Oracle Payments Processing.

Add Customers

Sales Orders Tools menu

Copying Orders

Order Import

Exception Management

You can now view and correct stored workflow errors in the Process Messages window. Each logged message has an associated status (seeded values are Open or Closed).

The various transaction ** windows provide direct navigation to Open errors, and allow you to retry a workflow activity that failed. If the retry is successful, Open messages are automatically closed.

The new workflow error handling process generates an Order Management-specific notification that uses standard workflow functionality to enable the recipient to retry an activity in error. The workflow also generates diagnostic information for the problematic order or line automatically.

In some cases it may take you a couple of iterations of fixing errors and retrying the activity to fix all the issues that are causing an activity to error. This feature also includes a record of errors and corresponding diagnostic information for Oracle Support to aid in fixing the problem.

** - Sales Order, sales agreements and Open Interface Tracking

Major Features

Enhanced Visibility of Workflow Activity Errors

You can query and view the errors that occurred in a particular workflow activity directly from the various transaction windows. For example if your cursor is in the Sales Orders window Lines tab, you will only see the errors for that particular line.

The following windows allow you to directly view open errors:

Sales Orders
Order Organizer
Quick Sales Order
Quick Order Organizer
Sales Agreements
Open Interface Tracking

Messages Now Include the Message Status

Error messages have an associated status (Open/Closed) to identify corrective action for the Open status.
The statuses available for each message are extensible so you can add your own statuses. Custom statuses are treated the same as the Open status.
Error messages that are not closed are closed automatically when the activity is retried.
The Message Purge concurrent program accepts the status as a parameter.

Retry Errored Activities

Retry is available on the above-mentioned windows using the Actions Button, right-mouse click (where Right Mouse Click functionality is available) and from the workflow notification. Error messages that are not closed are closed automatically when the activity is retried and completes successfully.

Order Management-specific Workflow Activity Error Handling

If the profile option OM: Generate Diagnostics for Error Activities is set to Yes, the Diagnostics: OM Order Information concurrent program is automatically started by the new error handling process when a workflow activity goes into error. The concurrent program output contains workflow error messages and workflow activity skip information to ease the debugging of problematic orders.
The new error handling workflow places the request ID in the notification, and adds a message with the request ID that is visible in the Process Messages. You can locate the concurrent program output and provide it to support when logging a TAR with Oracle Support for errored activities that you are unable to resolve.
This error handling flow is associated with the Order Header, Order Line, Negotiation, Sales Agreements, and Electronic Messaging workflows.

The following functions are protected by function security:
View Open Messages – this function is enabled for all users by default.
Retry Activities in Error – this function is not enabled for all users by default, as you may not want to allow all users to retry workflow activities. The System Administrator must enable it once the Exception Management patch is applied.

Progress Order Vs Retry Capability

The Retry Activities in Error action is different from the existing Progress Order action. The existing Order Management workflow processes contain eligible states for most function activities (e.g. Book – Eligible for Booking, Schedule – Eligible for Scheduling , Invoice Interface – Eligible for Invoice Interface). If such an activity fails due to an expected error, the workflow goes back to the eligible state and you can manually select the Progress Order action after taking corrective steps.

However, the new Retry Activities in Error enables you to retry a particular activity when the workflow itself is in an error state due to an unexpected error. In other words, Progress Order applies to activities in the eligible state whereas Retry Activities in Error applies to activities that are in an error state.

The Online User

Online, you try to progress the order in the Sales Orders window, and receive an error message. You can:

View the errors for that header or line via the View Open Messages function. This function is available via the Actions button or right-mouse click on both the Sales Orders, Quick Sales Orders, Order Organizer, Quick Order Organizer windows.
You can take steps to correct the error (if the cause is known).
If you have been granted access to the Retry Activities in Error function, you can also retry the activity via the Actions button or the right-mouse click menu.

The Administrator

The WorkFlow administrator can also identify orders and address workflow activity errors based on the notification sent automatically by the new Order Management Error flow. This feature is useful in cases when there is no online user (e.g. workflow activity errors during deferred Workflow Background Engine processing).

The workflow administrator can view the order by clicking the link to the Order Information Portal embedded in the notification.
The workflow administrator can also query the order in the Sales Orders window since the notification will contain the Order Number, and other Order Management-specific information.
The workflow administrator can view the errors, take steps to correct the error, and retry the activity directly from the notification or as described in the previous section.
If the value of the profile option OM: Generate Diagnostics for Error Activities is set to Yes, the Diagnostic Order Information concurrent program output will be available to provide to support when logging a TAR.

To review orders with messages of a particular message status:

The Order Organizer/Quick Order Organizer can be used to query all orders with error messages with a particular status.

The Organizer can be used to query orders containing at least one message with the status Open.

This feature can also be used in conjunction with the extensibility of the message status codes. For instance, online users can manually change the status of Open messages to some other custom status if they are not able to fix the problem. Next, a Power User/Administrator can periodically query orders based on the custom message status to identify orders that need more detailed analysis.

Examples of Workflow Activity Failure and Handling It

The following diagram depicts the business flow for correct workflow activity errors using this new feature:

Exception Management Business Flow

the picture is described in the document text

Process Messages Window

the picture is described in the document text

Access to Open Messages

You can process the Open messages for an order/line directly without leaving the Sales Orders, Order Organizer, Quick Sales Orders, or Quick Order Organizer windows. The action does not work if you have multi-selected records.

Query Capability

You can query orders/lines that have at least one message in a particular seeded or custom status.

You can now search for Orders based on a Message Status.

Order Organizer Find Window - Order Information

the picture is described in the document text

You can now search for Lines based on Message Status.

Order Organizer Find Window - Line Information

the picture is described in the document text

Order Organizer Window

the picture is described in the document text

The Open Messages check box indicates whether there are any Open Messages for the Order.

For the Sales Orders and Quick Sales Order forms, there is also an Open Messages check box at the line level (Main tab), besides the Open Messages check box visible in the Order Organizer and Quick Order Organizer.

Note: For performance reasons, this field is only populated if the value of the profile option OM: Show Process Messages Flag is set to Yes.

Order Organizer, Sales Orders, Quick Order Organizer, Quick Sales Orders

The Actions and right-mouse click menu functions are accessible from both the Summary and Lines regions.

Enhanced Diagnostics: OM Order Information Concurrent Program

This concurrent program shows the following information:

Header Processing Messages (all statuses)
Line Processing Messages (all statuses)
Workflow Skip Information
When you skip the Ship activity, Order Management logs the user_id, application_id, and responsibility_id, and two workflow notifications are also sent out. One notification is sent to SYSADMIN and one to whoever skipped the Ship activity. The notifications alert them of the skip and advise them not to skip activities in the future.

If the Profile OM: Generate Diagnostics for Error Activities is set to Yes, the OM Error Process now starts this concurrent program automatically in case of an unexpected workflow activity failure.

The diagnostics concurrent program will not be triggered for Electronic Messaging flows where there is no corresponding sales order (e.g. Process PO failed to create an order) or for Sales Agreement flows.

Message Purge Concurrent Program

This concurrent program includes the following parameter: Message Status

Message Purge Concurrent Program - Parameters Window

the picture is described in the document text

Note: The values for the parameter will be based on the same lookup type ONT_MESSAGE_STATUS. If the concurrent program is submitted with the message status parameter set to Open, then messages with NULL status will also be purged in addition to messages with Open status.

OM Error Workflow

The new Order Management-specific error flow starts when an activity errors. The notification includes Order Management-specific information that will help the System Administrator to identify the order and find the root cause of the error. This includes Order Number, Order type, Line number, Organization, etc. If the Profile OM: Generate Diagnostics for Error Activities is set to Yes, it automatically submits an OM Diagnostics concurrent program. Included is a link from the notification to the Order Information Portal for the order or the line that is in error.

Workflow for OM Standard Error Process with Retry (OMERROR/R_ERROR_RETRY)

This new workflow error process is associated with the existing workflow activities. The associated workflow package is OE_ERROR_WF. Note: The notification timeout is seeded as 3 days. At the end of this period the flow automatically closes if the error no longer exists.

OM Standard Error Process with Retry Steps

the picture is described in the document text

OM Standard Error Process with Retry Steps
Number	Process Step	Description
1	Initialize Error	This procedure checks to see if the error flow has the item attribute “WF_ADMINISTRATOR” and a value assigned to it. If it does, then it uses that value to send out a notification. If not then it uses the default value of SYSTEM.
2	Set Entity Descriptor	Sets the values for the message attributes that are needed for the default notification.
3	Submit Concurrent Program	Submits a Diagnostics: OM Order Information concurrent request.
4	Update Process Messages	Adds the concurrent request ID to the message stack.
5	Check if Error Still Active	Checks to see if the Error is still active.
6	Retry Error Activity	If the activity is still in error, it retries the activity.

Validations

Notifications for Order Management Standard Error Process with Retry
Desc	To:	Result Type	Responses	Message
OM Error NTF with RETRY only	If the error flow has the item attribute WF_ADMINISTRATOR and a value assigned to it, then it uses that value to send out a notification. If not then it uses the default value of SYSTEM	@Retry	OM Error message with RETRY as the only option.	You have received an error in the following Workflow activity. Please review the error information below to resolve this issue. Operating Unit =&OPERATING_UNIT VersionNumber = &VERSION_NUMBER Flow Status = &FLOW_STATUS Request ID = &CONC_REQ_ID &TRANSACTION_DETAIL_URL Workflow Detail:Item Type = &ERROR_ITEM_TYPE Item Key = &ERROR_ITEM_KEY User Key = &ERROR_USER_KEY Error Name = &ERROR_NAME Error Message = &ERROR_MESSAGE Error Stack = &ERROR_STACK Activity Id = &ERROR_ACTIVITY_ID Activity Label = &ERROR_ACTIVITY_LABEL

Note: The subject of the notification will read as follows for the various entities, Order Header:

OM Error in Workflow Order Type: Standard, Sales Order XXXX ORA-20001 Order Line

OM Error in Workflow Order Type: Standard, Sales Order XXXX, Line 1.1 ORA-20001 Negotiation Header

OM Error in Workflow Order Type: Standard, Quote Number XXXX ORA-20001 Sales Agreement Header

OM Error in Workflow Order Type: Standard, Sales Agreement Number XXXX ORA-20001 Electronic Messaging

OM Error in Workflow Order Source: XML, Original System Document Reference: XXXX, Customer: Computer Service and Rentals ORA-20001 In addition, for Electronic Messaging, there are certain cases when the order number does not exist (e.g. Process PO failed to create an order). In these cases, the Version Number, Flow Status, link to OIP, and OM Diagnostics Request ID will not be shown on the notification as all of these fields are only pertinent when an order exists.

Also, in the case of the activity Send Document (used by outbound XML documents), this activity is owned by XML Gateway and only referenced by OM. As such, this activity has its own XML Gateway-specific error handling and notification (ECXERROR) Therefore, if the Send Document fails, the System Administrator will not receive the OM-specific notification above. The user will still be able to retry the activity from the Open Interface Tracking form as well as the XML Gateway notification.

Note: Retrying of the Send Document activity from the Open Interface Tracking form will not cause prior error notifications for the same activity to be removed automatically. This would also hold true for other activities that do not use the OM Standard Error Process with Retry error workflow because only existing notifications sent from this error flow are removed.

Retry Activities in Error Concurrent Program

You can retry workflow activities in error across multiple orders/lines by launching the Retry Activities In Error concurrent program. The following workflow item types are supported:

the picture is described in the document text

If you enter an Order Number, then the header flow and all failed line flows are retried. All other parameter values are ignored. Since Item Type is mandatory, it is defaulted to order header. The Order Number parameter LOVdisplays order numbers across operating units.

The concurrent program supports two modes: Preview and Execute. In Preview mode, the concurrent program shows a summary of activities in error.

In Execute mode, the activities are retried. You can use the Preview mode to identify the number of activities in error, and use the Execute mode to retry them.

Parameter	Description
Order Number	Order Number (only valid if the Item Type is Order Management Order Header). If populated, the lines of the corresponding sales order are retried before the header.
Item Type	Order Management Order Header, Sales Agreement Header, etc.
Activity in Error	This is filtered by the Item Type
Activity Error Date From	Workflow activity in error start date (low)
Activity Error Date To	Workflow activity in error start date (high)

the picture is described in the document text

This concurrent program retries workflow activities in error and then displays the result of the retry and any error messages. It will retry all the failed activities satisfying the criteria entered in the Standard Request Submission window.

the picture is described in the document text

The Retry Activities in Error concurrent program is incompatible with the following concurrent programs: Retry Activities in Error - Cannot run two instances of this program at the same time; Schedule Orders; Reserve Orders; Re-Schedule Ship Sets.

There are cases when retrying a workflow activity in error will not resolve the problem. One such case occurs when the Ship Line workflow activity errors out, but at least one corresponding delivery detail is closed since the line was shipped. In this case, retrying the activity via the existing Exception Management functionality will always fail.

With the new functionality when Exception Management encounters this situation, the workflow activity is set to Notified instead of being retried.

Setting the activity status to Notified is not supported when the Ship Line activity is retried from the Oracle Workflow Status Monitor. You must use one of these three methods:

Use the action, Retry Activities in Error on the Sales Orders Organizer, Quick Order Organizer, and the Sales Orders and Quick Sales Orders windows, and the ability to retry from the Order Management Error notification.
An Order Management Error notification is sent when an activity errors.
The Retry Activities in Error concurrent program.

Note: The behavior of the Retry Activities in Error action from the Open Interface Tracking window and the Sales Agreements window is unchanged.

Use caution assigning access to the Retry Activities in Error concurrent program. Since this concurrent program retries activities in error and thereby increases the number of rows stored in the Oracle Workflow tables, incorrect or indiscriminate usage can result in the excessive population of the workflow tables and lead to severe performance issues. You should use the messages included in the log output of the concurrent program to identify and fix as many errors as possible before re-submitting the program. In addition, the concurrent program can be submitted in Preview mode to help identify errors without retrying activities in error. An activity will complete successfully on retry only if the root cause of the failure has been identified and corrected.

The Retry Activities in Error action and concurrent program will also abort and purge any active WFERROR flows before retrying an activity in error.

Sales Agreements Forms

Sales Agreement Organizer

the picture is described in the document text

Access to Open Messages

You can process the open messages for Sales Agreements directly without leaving the Sales Agreements window.

Note: You cannot perform this action by multi-selecting for the first phase.

Query Capability

You can query Sales Agreements that have at least one message in a particular seeded or custom status.

Sales Agreements Organizer

The Open Messages Check box indicates whether there are one or more messages that are not closed.

Note: Retry Workflow Activities in Error will not be available from the SA Organizer.

Sales Agreements Window Actions and Right Mouse Click

The Actions and right-mouse click menu functions are accessible from the Main tab.

Open Messages – Open Interface Tracking Window

You can process the Open messages for an Electronic Messaging transaction directly without leaving the Open Interface Tracking window.

Note: The View Open Messages function is only available from the Actions button on the Details window, as the right-click menu is not supported for any functions on this window. Multi-select is not supported in the Open Interface Tracking window.

Retry Capability

You can retry activities in error from the Open Interface Tracking window.

Note: The Retry function will only be available from the Actions button on the Details window; the right-click menu is not supported for any functions on this window. Multi-select is not supported in the Open Interface Tracking window.

Query Capability

You can query transactions that have at least one message in a particular seeded or custom status.

Find Window Details

Open Messages check box indicates whether there are one or more messages that are not closed.

Projected Sales Revenue Reporting by Sales Group

Within Order Management, you can specify the Sales Person(s) who receives sales credit on any sales order line. Now, the Sales Group is captured on the order line. In addition to storing the Sales Group on the order line, there are certain new features:

Default a Sales Group based upon the Sales Person
Freeze the Sales Group from future changes or updates
Override the Sales Group
The addition of Sales Group to return lines (RMA)

Order Management Support for Sales Group

The Sales Group is automatically populated when the Sales Person is selected. The Sales Group is also shown with RMA lines if referenced.

Prevent Changes to the Sales Group

Fix or prevent changes to the Sales Group is supported via a Fixed check box.

Override the Defaulted Sales Group

You can manually change the Sales Group on an order line. When the Sales Person is entered, the appropriate Sales Group is automatically populated on the order line. However, you can change the Sales Group to another valid group.

User Procedures

Sales Group is Defaulted

The Sales Group is defaulted when the sales person is entered in the Sales Credit window, and when the sales credit is created via Process Order. Besides Sales Reps, the Order Date or Book Date is used as an input for the API for defaulting purpose.

The API considers the Sales Groups that have an Order Date or Book Date that fall in between the start and end of the Sales Group effective date. When the order is entered but not booked, the system defaults the Sales Group by sending Order Date to the API. When the order is booked, the system re-defaults the sales group by sending the Booked Date to the API. The re-defaulting will take place only when you have not manually overridden the defaulted value or nullified the Sales Group value.

Fix or Set a Sales Group

You can mark the sales group as being frozen or not available for update, by checking the Fixed check box if you want the sales group which defaulted during order entry. By doing so, this ensures that the Sales Group will not be re-defaulted at booking time even if the Sales Group effectivity has changed.

Choose a Different Sales Group

You can manually override the defaulted Sales Group by picking a valid Sales Group from a Sales Group LOV. The Fixed check box will be checked after you have selected a record from the LOV.

Copy the Sales Group on RMA Lines

The original Sales Group and sales credit on the order line must be copied to any new RMA lines if it is a referenced RMA.