Processing Orders Using Oracle Workflow

This chapter covers the following topics:

Selecting Workflows

Oracle Order Management comes seeded with several workflow processes. This section provides an overview of the header and line level processes that come seeded with Oracle Order Management. It also provides recommendations for which workflows processes can best meet your business needs.

Assigning workflow processes to header and line level transaction types enables you to initiate a process on an order and on an order line. Header level workflow processes must be assigned to transaction types in Oracle Order Management. After you define a line transaction type, line level processes must be assigned.

You cannot select any order workflow to be used with a line workflow. Some workflow steps between an order and line are interdependent based on how continue-flow and wait-for-flow activities are paired. Therefore, the same line transaction type must follow a different line flow when used with a different order transaction type. For example, Order Flow - Generic with Header Level Invoice Interface waits for an activity in the line flow to complete. If you do not use order and line flows designed to work together your orders or order lines could complete too early or never complete.

The inventory item that a line processes may have specific flow requirements. For example, a configuration must have a bill of materials and a work order created before it can be picked and shipped. The standard item can be picked from stock and shipped. Therefore, the workflow for a configuration item is different than for a standard item. Both types of order lines can be used for the same line type. The Workflow Assignments window displays the following item types to which a workflow can be assigned for a given order or order line type:

If the item type code is left blank, the specified workflow assignment applies to all item types for which there is no specific assignment. Specify an assignment for the configured item type if you plan to use the line type for ATO configurations.

Note: A Workflow assignment is required for a given line type to support creation of lines using that line type.

Header Level Processes

The following list provides an overview of the header processes seeded in Oracle Order Management:

Line Level Processes

With the exception of returns, all of the line level processes seeded in Oracle Order Management are used for outbound processing.

The following sections provide overviews of the line level processes seeded in Oracle Order Management.

The following line level workflow processes execute typical activities for entering and scheduling order lines:

This flow will not work for configured items generated from assemble-to-order models.

When Line Flow - Generic is selected, users need not select different processes for assemble-to-order items, assemble-to-order models, or a standard items. Outbound lines for all item types (other than Service) can be handled by Line Flow - Generic. By selecting Line Flow - Generic, the necessity of selecting a specific process for a particular item type is eliminated (this could be useful for customer service representatives).

From a setup perspective, Line Flow - Generic is effective because it manages several item types. If, however, you are a high volume ATO user, specific Assemble to Order (ATO) Processes can improve performance.

Assign the seeded line workflow for the Configured Item line type if your business processes ATO configurations. Configured Item refers to the actual item created by Oracle Configure to Order for an ATO model order line as part of the Autocreate configuration process.

If your business does not process ATO models or ATO items, but does process standard items and PTO items, you can delete Item Attributes that relate only to ATO models or ATO items to improve performance. The following are item attributes associated only with ATO models and ATO items:

ATO processes seeded in Oracle Order Management include the following:

The following line level workflow process are commonly used with Oracle Release Management:

The following line level workflow processes are used for returns or inbound lines:

Service Item Processes

The following process is used for service items:

Negotiation and Sales Agreement Processes

You can choose one of the following seeded header-level negotiation flows, which can be converted to a Sales Order in case of a Quote, or Active Sales Agreements if it is a Sales Agreement. The Sales Order negotiation can be converted to Sales Order in either the Entered or Booked status. The following are flows supporting the Negotiation phase for Sales orders and Sales Agreements:

Negotiation Flows and Fulfillment Flows

The negotiation flow represents the decision phase of the order process where a sale is discussed and agreed upon before the sale is confirmed. Once the order content is agreed upon, the negotiation moves into the fulfillment phase of the order where scheduling and shipping occur, resulting in invoicing through Receivables. The distinction between the two flows is specific to the activities in the seeded flows. The negotiation flow is a header flow only and all the lines follow that flow : there are no independent line flows during the negotiation phase. The negotiation flow also has an expiration that is based on the start and end active date, and will expire if not converted to an order. Only when the transaction transitions to the fulfillment part of the order process are line flows associated with the lines and can be managed independently.

Assigning Workflows to Transaction Types

Oracle Order Management transaction types determine the workflow processes executed at header and line levels. Oracle Order Management enables you to define both header and line level transaction types.

Oracle Order Management does not provide seeded transaction types. You must create your own transaction types using the transaction types window in Oracle Order Management.

See: Oracle Order Management Implementation Manual.

Transaction Types Window

the picture is described in the document text

The Transaction Type determines the header level process used at the header level on an order. The combination of transaction type, line type, and item type determines the line workflow. Please note that the Operating Unit field on the Transaction Types window is a mandatory field and transaction types are assigned to one or more operating units.

You can perform all standard processing including orders, returns, drop-ship orders, orders for configured items, and orders for assemble-to-order items using seeded workflows. You can also create your own workflows if you need additional processes, activities, or notifications.

Warning: Oracle provides support only for its seeded activities and processes. Oracle does not provide support for your custom activities and processes.

For more information about extending existing workflow processes, refer to Extending Oracle Order Management Seeded Workflows.

For information about creating your own workflow processes, refer to the Oracle Workflow User's Guide.

For more information on Operating Units in the Transaction Types window, please refer to the Oracle Order Management Implementation Manual.

Line Workflow Assignments

The Line Workflow Assignments window is available for Oracle Order Management order transaction types. Use this window to assign line flows to the line types used with an order type. The following image depicts the Line Workflow Assignments window.

Line Workflow Assignments

the picture is described in the document text

A line flow can be assigned to an order type, line type, and item type combination. Oracle Order Management enables you to define one assignment for a given combination. If the item type is left blank, then that assignment applies to all item types that do not have specific assignments. If you use a line type for ATO models, Oracle Order Management requires you to specify assignments for configured item types.

Workflow Background Engine Processing

The Workflow Background Engine processes deferred activities. It also processes wait activities and timed-out activities when the wait/time-out period is reached. Schedule the Workflow Background Process concurrent program to resubmit periodically. When scheduling with the concurrent program, select the required item type in the Parameters window.

Note: It is recommended to run the Workflow Background Engine at least three times a day. More frequent runs balance the load processing and allow lines to progress more frequently.

To set schedules for the Workflow Background Engine, set up the following options:

  1. Define the Process Deferred parameter as Yes. Set all other parameters to No. Schedule this request to run most frequently (for example, every 10 -15 minutes).

  2. Define Process Time-out as Yes, and all other parameters as No. This can run less frequently (for example, once every 30 - 60 minutes).

  3. Define Process Stuck set to Yes and all other parameters as No. This can run less often (for example, once per day).

The most common use of the background engine is to process deferred activities. To improve performance, process deferred activities frequently, and process time-out and stuck less frequently. For example, you probably have more deferred lines than timed out lines. In this case, you could progress deferred lines three times a day, and progress timed out lines only once a day.

Workflow Context Change

Oracle Order Management sets the application’s context for order headers and lines when the Workflow Background Engine processes them.The context is reset if any of the context attributes - user, responsibility, application or operating unit do not match the one on the Order Header or Line being processed. The following profile options are accessed using the context of the user who created the line or header for which they are retrieved:

Workflow Background Engine Performance Guidelines

The Workflow Background Engine also impacts overall system performance. By analyzing the frequency and type of processing you require, you can ensure that the WF background engine runs efficiently. To run the WF Background Engine, you must set the following parameters:

Avoid running the Workflow Background Engine multiple times with both the Deferred? and Timeout? parameters set to yes. Instead, run it as required to check for one of the parameters. For example, you might want progress deferred lines four times a day, and progress timed out lines one time a day. However, the frequency depends on your business needs. You may need to run the WF Background Engine several times a day, but the process will be more efficient if you specify either Deferred or Timed Out lines, but not both.

Note: The activity of the Workflow Background Engine affects all order processing: standard and HVOP order import, online processing, and Process Order API.

Scheduling Workflows

A line that is not scheduled from the Sales Orders window can be scheduled using a workflow activity. Each order process activity can be represented as a workflow activity. The workflow activities are completed automatically based on your workflow process definition.

Note: If scheduling encounters an unexpected error (such as system or network error), add, update and delete will also fail.

Schedule Workflow Activity

The standard schedule workflow activity performs the following functions:

For more information about the scheduling activities available in Oracle Order Management, Seeded Function Activity Definitions.

For more information about the subprocesses that use scheduling activities, refer to Seeded Subprocess Definitions.

High Volume Order Processing (HVOP)

Order Management now provides High Volume Order processing (HVOP) as an alternative way to import newly created orders. This method of order import achieves many performance gains.

Order Management seeds a generic line flow for performance called Line Flow—Generic, Performance. This seeded flow improves performance by reducing the number of subprocesses and status checks. It can be used for all items types. Because this flow is not modular, it should not be modified.

The streamlined seeded workflow Line Flow—Generic, Performance provides the same functionality as the Generic line flow. The benefit of the Generic line flow is that it simplifies extending or customizing workflow. This is because the traditional Line Flow - Generic workflow has subprocesses. If you copy the flow and insert a new activity at the top level—that is, into the main flow, the rest of the flow will contain references to the subprocesses defined by Order Management. When Order Management updates these subprocesses with a patch, the modified workflow automatically points to the updated subprocess since the modified flow only contains a reference to it. The Line Flow—Generic, Performance workflow has no subprocesses. There are no references to subprocesses, only copies of the lineflow. Therefore, when a patch is applied, you need to recopy and reapply any modifications you have made to the seeded flow.

Streamlining workflow improves the performance of both standard and HVOP order import, as well as online performance. It improves the performance of the Process Order API, and concurrent programs that process workflow activities.

Repricing Order Lines

Oracle Order Management enables you to reprice an order line at any point in the order life cycle using Oracle Workflow. Oracle Order Management and Oracle Workflow also enable you to determine the following:

For more information about the pricing functionality in Oracle Order Management, refer to the Oracle Order Management User's Guide.

Pricing Date

Set the Reprice activity Repricing Date attribute when you insert the activity into a workflow. You can set the pricing date to one of the following dates for your order line:

You can select the original pricing date on the order line if you set the Repricing Date attribute to Null.

Pricing Phases

Set the Repricing Event attribute to Pricing Event to control line-level pricing phases to be executed at repricing. The Repricing Event attribute is an Oracle Order Management lookup type to list all pricing events for which repricing can be executed. Current lookup codes for Repricing Event include the following:

You can recalculate base price while keeping the discounts given during the order entry time by setting the Repricing Event attribute to Price.

Note: If you set the Repricing Event attribute to Null, the repricing event is Reprice Line. Reprice Line is a seeded pricing event. You can only associate line-level pricing phases with this event. For more information about pricing events, refer to the Oracle Advanced Pricing User's Guide.

If you add a new pricing event for use with Reprice, verify that you also define this event as a lookup type. If this is not defined as a lookup type, you cannot select the new pricing event when setting the Repricing Event attribute.

Calculate Price Flag

You can control whether the repricing line workflow activity honors the value of the calculate price flag by setting the Reprice attribute Honor Price Flag to one of the following:

Repricing and freight charge recalculation occurs regardless of the value of the calculate price flag.

Repricing at the Line Ship/Schedule Date

Place the Reprice activity after all shipping activities in a workflow to reprice an order line at shipment for workflows that processes only items and lines not in fulfillment sets.

Note: If the Reprice activity fails it does not impact your shipping activities. Use either the shipment date (either actual shipment date or scheduled ship date) for the Repricing Date attribute.

Repricing at shipment does not validate agreements and their effective dates. Repricing at shipment validates the price list associated with the agreement specified on the order.

Repricing at the Line Fulfillment Date

To reprice an order line at its fulfillment date, place the Reprice activity in your flow after the fulfillment activity then update your pricing events.

Note: Placing the Reprice Line workflow activity after the fulfillment activity enables your workflow to process shippable items, non-shippable items, and non-shippable lines in a fulfillment set.

Complete the following steps to reprice at the line fulfillment date:

  1. Navigate to the Event Phases window and add each desired phase.

For more information on defining Pricing Events, refer to the Oracle Advanced Pricing User's Guide.

  1. Place the Reprice activity after the fulfillment activity in your workflow.

  2. Set the following workflow attributes:

  3. Repricing Date: Fulfillment date

  4. Repricing Event: Reprice Line or another defined event

Cost of Goods (COGS) Account Generator

When an item is shipped to the customer, information regarding the shipped quantity is passed to the inventory module. Among the data that is passed to the inventory module, the Cost Of Goods Sold (COGS) Account for transactions is also passed and interfaced to Receivables. When the Inventory Interface inserts a row for a transaction, it only provides the COGS Account to record cost against. The Cost of Goods Sold Account is used to determine the profit realized from selling a product. For each item in an inventory organization Oracle Applications has the ability to record the type and amount of costs to maintain the item.

For more information on the COGS flows, please refer to the section Cost of Goods (COGS) Account Generator Flows.

EDI/XML

EDI/XML flows are not covered in this guide; for more information on these flows, please refer to the Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide and the Oracle XML Gateway User's Guide.