Skip Headers

Oracle Order Management User's Guide
Release 12.1
Part Number E13408-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Order Management Processes

This chapter covers the following topics:

Line (Ship or Arrival) Sets

Order Management allows for 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, the concept of creating sets for shipment has been expanded to include additional set functionality based upon ship, arrival and fulfillment. In general, grouping order lines within sets can:

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:

Set Status

Order Management Sets are either Active or Closed.

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

Line Splits

If a order line is generated as a result of Split Shipment, and the original order line was within a Ship Set, the new order line generated (and also any existing lines in the ship set that are not shipped) will be removed from the ship set.

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.

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.

  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.

  2. 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

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.

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:

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

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 may. 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.

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 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.

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

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.

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:

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:

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.

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:

  1. Navigate to the Shipping tabbed region.

  2. Enter address information for the shipment schedule's final destination.

  3. 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.

  4. 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:

  1. Navigate to the Project tabbed region.

  2. Select a Project Number.

  3. 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.

  1. Navigate to the Release Management tabbed region.

  2. Enter the Customer Job number.

  3. Enter the Customer Production Line.

  4. Enter the option's Customer Model Serial Number.

  5. Enter the Customer Dock to which the item will be delivered.

  6. Select an Intermediate Ship To Location from the list of values.

  7. Enter the Planning Production Sequence number.

  8. Navigate to the Industry Information descriptive flexfield.

  9. The Additional Industry Attributes window appears.

  10. Save your work.

Information Retention Across Shipments when a Line is Split:

Attachments

For User Initiated Splits - Only manual attachments are duplicated when a line is split.

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:

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 Fulfil 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.

Seeded Order Management workflow processes and activities can be used 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.

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 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 set to Yes. The workflow then checks to see if the line is part of a fulfillment set.

Fulfillment Set Details

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 populates the value at the line level.

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.

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

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 has enhanced 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

Fulfill Line workflow activity in Order Management indicates:

  1. The workflow activity in order line workflow that should be used as the fulfillment activity.

  2. 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 desired result (i.e. ship confirm). If it has, then the Fulfill Line activity is completed and the order line is marked as fulfilled.

Shippable Vs. Non-Shippable Line Fulfillment

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

Note: *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:

  1. 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.

  2. 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:

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

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:

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.

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

  1. Navigate to the Transaction Types window.

  2. Setup Default Line set as Arrival Set for Transaction Type Standard.

  3. Save your work.

  4. Navigate to the Sales Orders window.

  5. Create an order with the Transaction Type Standard. The Line Set will be defaulted with the value Arrival.

  6. Add lines to the sales order.

  7. 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.

  8. Save your work.

To include lines in a Fulfillment Set automatically:

  1. Navigate to the Transaction Types window.

  2. Setup Default Fulfillment Set for Transaction Type Standard as Yes.

  3. Save your work.

  4. Navigate to the Sales Orders window.

  5. Create order with Transaction Type Standard. The default Fulfillment Set will be defaulted with the value Yes.

  6. Add Lines to the sales order.

  7. 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:

  1. Navigate to the Defaulting Rules Setup window.

  2. Setup Defaulting rules for: Customer, Ship To, Site etc. with a sequence specified in which the order Line Set is defaulted.

  3. Save your work.

  4. Navigate to the Sales Orders window.

  5. Create an order with the Customer Line Set that defaults with value Arrival or Ship depending upon the defaulting rules.

  6. 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.

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:

  1. The shipped quantity is not Null.

  2. The line is Invoice Interfaced.

  3. The item is Pick Released.

  4. 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.

  5. The Purchase Release workflow activity has been completed.

  6. An ATO item has been ship notified.

  7. 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:

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:

Validating Project and Task Information

Project and Task information is validated for the following:

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

End Item Unit number is validated when:

User Procedures

To query an order based on project and task:

  1. Navigate to the Sales Orders window, and choose the Find icon.

  2. Enter all or any of the following query criteria:

    Project Number

    Task Number

  3. Click Find.

    Find Window - Line Information Tab

    the picture is described in the document text

  4. View the orders returned by the entered query criteria.

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

  1. Navigate to the Sales Orders window.

  2. Enter the order information, then choose the Lines tab.

  3. Enter all required line information, then choose the Others tab.

  4. Enter the Project, Task, and End Item Unit number.

  5. Save your work.

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

  1. Navigate to the Sales Orders window.

  2. Query the line to update.

  3. Select the Others tab.

    Sales Orders Window - Others Tab

    the picture is described in the document text

  4. Update the appropriate field.

  5. 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:

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:

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:

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:

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

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:

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:

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:

  1. 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.

  2. 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.

  3. 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.

  4. Current Location. Defaults from the header either the Ship To, End Customer, Deliver To, Sold To, or Bill To location.

  5. 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.

  6. 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.

  7. 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.)

  8. 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.

  9. 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.

  10. 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

  11. If the item is shippable, the physical shipment is used to update Install Base.

  12. 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:

  13. 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.

  14. 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:

  1. 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.

  2. 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.

  3. Run order import. Note that EDI and XML are not available.

  4. 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

  5. If the item is shippable, the physical shipment is used to update Install Base.

  6. 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:

  7. 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.

  8. 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:

  1. Add the seeded workflow function activity, IB Interface, to the shippable line transaction type.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  6. If the item is shippable, the physical shipment is used to update Install Base.

  7. 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:

  8. 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.

  9. 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

  1. No changes are required to the header workflow for quotes.

  2. 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.

  3. Create the quote, specifying the End Customer information, the Owner, Current Location, and Installed At Location on the header.

  4. Create the lines for the quote, specifying different End Customers for lines as desired.

  5. 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.

  6. For shippable items, the values are passed after shipping.

  7. 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:

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:

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.

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:

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:

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:

Formatting Properties for Business Document Data

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

Variable Formatting

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

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

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:

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

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):

  1. Navigate to the Transaction Types window, Transaction Types Setup.

  2. In the field Layout Template, use the List of values choose a layout template for the transaction type.

  3. 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

  1. Initiate the workflow approval process. The approver receives approval notification, and may click the PDF link to preview the business document.

  2. The business document is displayed in PDF format; formatting is based on layout template.

  3. Review the document and print it if required, by clicking the File > Print menu option or by clicking Print icon, and close the document.

  4. 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:

  1. 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.

  2. 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.

  3. 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:

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.

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:

When processing drop shipments for orders, you can:

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:

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.

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:

  1. The organizational item attribute, Default SO Source Type.

    If the value of this attribute is NULL:

  2. Order Management will default the value Internal.

  3. 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.

  4. 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.

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.

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.

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:

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:

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.

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 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.

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:

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:

  1. Navigate to the Sales Orders window.

  2. Enter a sales order and an order line with an item sourced externally with a quantity of 10.

  3. Use a receiving org that is in a different Ledger.

  4. Book the order.

  5. Purchase Release runs automatically, if the purchase release is deferred, then run the workflow background process for WF Item Type Order Management Line (OEOL).

  6. Run Requisition Import (the requisition is created and approved) after changing to the appropriate operating unit.

  7. 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.

  8. Approve and print the purchase order. Verify the additional sales order information for the shipments.

  9. Send the purchase order to the supplier.

  10. Logically receive and deliver the purchase order.

  11. 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):

  1. Navigate to the Sales Orders window.

  2. Enter sales order and an order line with an item sourced externally and with a quantity of 10.

  3. Book the order.

  4. 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).

  5. Change the Ordered Quantity to 20.

  6. Run the Requisition Import and verify that the purchase requisition has an Ordered Quantity 20.

  7. 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.

  8. If Yes, the status will be shown on the Drop Ship tab.

  9. Create the purchase order from the requisition.

  10. 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.

  11. Approve the purchase order.

  12. 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.

  13. 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):

  1. Disable the constraints for changes to Ordered Quantity increase, Ship To Location, and Shipping Instructions.

  2. Query the sales order from the previous procedure.

  3. Change the Ordered Quantity to 50, Change the Ship To Location, and Shipping Instructions, then save. Changes are saved successfully.

  4. Verify that the purchase order's quantity, Ship To location, and Shipping Instructions have changed and the purchase order status is set to ‘Requires Re- approval.'

  5. Re-Approve the purchase order, print the changed purchase order, and verify the sales order data elements.

  6. 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

  1. Ensure you have created your Order Management Transaction Types and linked your Transaction Types to order and line workflows that support drop shipments.

  2. 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.

  3. Ensure the Oracle Workflow Background Engine is running.

  4. Ensure all Drop ship locations you will use to perform drop shipments have the Ship To Site and Receiving Site defined.

  5. Ensure you have defined the Internal Ship To Locations for your drop shipment customers (Oracle Receivables Standard Customer window, Business Purpose Details Tab).

  6. 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.

  7. 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:

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:

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

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

Workflow

Drop Shipments for standard items

  1. Enter an order for drop ship item.

  2. Book the order.

  3. Run Requisition Import.

  4. Create a purchase order from the requisition.

  5. Approve the PO.

  6. Receive against the PO.

    Forward drop ship flow for ATO model

    1. Enter a sales order for your dropshipped ATO model.

    2. Select your options.

    3. Schedule and Book order (Schedule date should default to request date for all lines.)

    4. Create the configured item by progressing your order ATO Model line or running the Autocreate Configuration batch process.

    5. Verify order and line status.

    6. Create Supply Order (Dropship requisition) by progressing your 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 your dropshipped ATO item.

    2. Schedule and Book order (Schedule date should default to request date for all lines.

    3. Create Supply Order (Dropship requisition) by progressing your 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 dropshipped standard options

    1. Enter Sales Order for your 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 PO.

    7. Receive the PO.

      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:

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:

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

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:

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:

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:

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:

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.

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.

eWorkflow Activity Results

The following workflow activity results are possible for Purchase Release:

Note: 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:

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 its Sales Order workbench. You can order services for product items currently being ordered, i.e. immediate services, or you can order services for already installed product items or delayed services.

Order Management enables you to:

Workflow

Order Management enables you to utilize Oracle Workflow to manage your 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 your workflow process to meet your business needs.

See: Using Oracle Workflow in Oracle Order Management, Release 12.

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 your 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:

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 may 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:

  1. Enter a service item in the Lines tab of the Sales Order workbench. For the service item, all the service related columns will be enabled in the Service tab.

  2. Navigate to the Line Items, Services tabbed region.

  3. Define the Service Reference Type.

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

    For sales orders,The LOV on the Service Ref Order Number field consists of the following columns:

    For customer products, the LOV displayed on the Service Ref Cust Product field consists of the following columns:

  4. Define the Service Order Type.

  5. Define the Service Reference Order and Line Numbers if your service reference type is Sales Order.

  6. Define the Service Reference Shipment and Option Numbers if your service reference type is Sales Order.

  7. Define the Service Reference Customer Product and System Name if your service reference type is Customer Product.

  8. Select the Service Coterminate Flag check box to disable or enable this option.

    The Service Coterminate field is used to set the same end date for all service programs sold to a particular customer or grouped into a specific system. Please refer to the Oracle Service Contracts User Guide for more information.

  9. Define the Service Start and End Dates.

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

  10. Define 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.

  11. Define the Transaction Reason and any additional Transaction Comments for the order.

  12. Save your work.

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

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:

  1. Navigate to the Sales Orders window.

  2. 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.

  3. If you do not want to return the full quantity of the line item, change the quantity to a lesser amount on the line.

  4. 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.

  5. Book the return.

  6. The Order Management Fulfillment workflow activity runs in the background to progress the product lines.

  7. The Order Management Install Base Interface runs in the background to progress the product lines.

  8. 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.

  9. 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:

  1. Navigate to the Line Items, Others tabbed region in the Sales Orders window.

  2. 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.

  3. 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.

  4. 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:

  1. Navigate to the Others tabbed region within the Line Items tab.

  2. 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.

  3. Enter the customer Production Line.

  4. Enter the item's Model Serial Number.

  5. Enter the Customer Dock to which the item will be delivered.

  6. Select an Intermediate Ship To Location.

  7. Enter the RLM (Release Management) Schedule Type.

  8. 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 or included 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:

  1. Navigate to the Sales Order window, Lines tab.

  2. From the Folders Menu, select Sort Data

    Order Lines Sorting Criteria Window

    the picture is described in the document text

  3. 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.

  4. Choose to qualify the sort order display for each order line attribute selected. Select from:

  5. 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.

  6. 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:

  1. Navigate to the Sales Orders window.

  2. Enter the header and line level information for a new order, or query an existing order.

  3. 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:

See:

Booking

Oracle Order Management Suite Implementation Manual, Oracle Payments Processing.

Add Customers

Sales Orders Tools menu.

Copying Orders.

Order Import.

Note: Only the sales orders customizations mentioned here are supported by Oracle Order Management.

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:

Messages Now Include the Message Status

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

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:

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).

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.

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:

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:

  1. 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.

  2. An Order Management Error notification is sent when an activity errors.

  3. 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:

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.