This chapter covers the following topics:
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:
ATO Models, Classes, Options, Items
Configured Item
Kits
Included Items
PTO Models, Classes, Options
Standard Items
Service Items
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.
The following list provides an overview of the header processes seeded in Oracle Order Management:
Order Flow - Generic: This is the most commonly used header flow. This process includes activities that book and close the order header. Always use this process unless you require the functionality specific to Order Flow - Generic with Header Level Invoice Interface or Order Flow - Return with Approval. Order Flow - Generic can be used with any line flow for any item type, with outbound lines and with return lines.
Order Flow - Generic with Header Level Invoice Interface: Use this header flow if your business requires that all lines on the order invoice together at the header level.
Note: This process must be used in conjunction with Line Flow - Generic with Header Level Invoice Interface.
Order Flow - Return with Approval: Use this header flow when all lines on the order are returns and header level approval is required.
Order Flow - Return with Submission and Approval: This flow is seeded for Oracle iStore RMA integration. It is not intended to be used as a standard OM flow.
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:
Line Flow - Generic: Use this process for all items except for service items, including assemble-to-order (ATO) items, ATO models, kits, and pick-to-order (PTO) models.
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.
Line Flow - Generic with Header Level Invoice Interface: Use this process when all order lines must invoice simultaneously. Invoice is controlled by the AutoInvoice concurrent program. Set up grouping rules in Oracle Receivables if only one invoice for the order is necessary.
Note: This process must be used in conjunction with Order Flow - Generic with Header Level Invoice Interface.
Line Flow - Generic, With Export Compliance: Select this process when products exported to a denied party must be checked. This process is commonly used in the defense industry, and could be used for screening after scheduling but before manufacturing. If the party (such as the ship to) is authorized, the line progresses through the create supply, ship, fulfill, invoice interface, and close processes.
Line Flow - Generic, Bill Only: Use this process when scheduling and shipping are not necessary for an ordered item. This process fulfills the order line, then proceeds with invoice interface. For example, this process might be used if an invoice was incorrect and an adjustment must be made visible in Oracle Order Management.
Line Flow - Generic, Bill Only with Inventory Interface: Use this flow when products are not shipped but inventory decrement is required. For example, some distributors have customers who pick up products in person. The inventory transaction must be accounted for, so the process line moves to invoice interface. The product is picked up, so shipping is not necessary.
Line Flow - Generic, Ship Only: Use this process if you must ship a product but an invoice is not necessary. This flow decrements inventory. For example, this process could be used when shipping free samples for a new product, or for shipping a non-billable toolset to repair a previously invoiced item.
Assemble to Order (ATO) Processes
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:
Lead Time Rollup Organization
Lead Time Rollup Config Item
Lead Time Date
Lead Time Category Structure
Lead Time Attribute Req ID
Lead Time Request ID
AFAS Line ID
ATO processes seeded in Oracle Order Management include the following:
Line Flow - ATO Item: Use this process instead Line Flow - Generic for ordering only ATO items. The process runs the typical entering and scheduling processes. This process also creates supply for an ATO Item. The process then continues with shipping, deferred fulfillment, fulfillment, invoice interface, and close.
Line Flow - ATO Model: Use this process instead of Line Flow - Generic for ordering only ATO models. The process runs entering, scheduling, creating configuration, shipping, fulfillment, invoice interface, and close.
Line Flow - Configuration: This process is for configured items. Assign this process to the order line type used for configurations as part of your implementation process. The configured item is created from a model as a part of the Autocreate configuration process for ATO items. The flow runs calculation of manufacturing data, and creation of supply for configuration. It then continues with shipping, fulfillment, and close.
Oracle Release Management Processes
The following line level workflow process are commonly used with Oracle Release Management:
Line Flow - Generic with Authorize to Ship (RLM): Use this flow if you use Oracle Release Management and want to forecast in Oracle Order Management. Demand interfaced from Oracle Release Management as Not Authorized To Ship can be changed to Authorized to Ship using this workflow process.
Line Flow - Configuration with Authorize to Ship (RLM): Use this flow if you use Oracle Release Management and want to forecast in Oracle Order Management. Demand interfaced from Oracle Release Management as Not Authorized To Ship can be changed to Authorized to Ship using this workflow process. The Line Flow - Configuration with Authorize to Ship (RLM) workflow process is associated with Oracle Release Management. Line Flow - Configuration with Authorize to Ship (RLM) ensures that a line is eligible for shipping. This workflow is specific to Oracle Release Management users and must be assigned during the implementation process.
Inbound Processes
The following line level workflow processes are used for returns or inbound lines:
Line Flow - Return for Credit Only: This process is used only for incoming lines. The process runs an activity that issues credit without waiting for a receipt of goods or an approval. This flow could be used, for example, if you give credit for a product shipped on a CD, but you do not want the CD to be returned.
Line Flow - Return for Credit Only with Approval: This processes is used only for incoming lines that requires approval. This process could be used, for example, when a return must be approved by a manager or a customer service representative before credit is issued.
Line Flow - Return for Credit with Receipt: This process is used only for incoming order lines that require receipt of goods before credit can be issued. Once the returned items are received by Oracle Purchasing, the process continues through invoicing and credit is issued. This process is useful when the returned items are expensive; credit should not be issued until the items are received.
Line Flow - Return for Credit with Receipt and Approval: This process is the most restrictive for incoming lines. The process requires both receipt of goods and an approval. This process is commonly used when items such as modems are returned. The modem is received then inspected to ensure that no mistreatment or neglect of the item occurred. Once inspected and approved, credit is issued.
Service Item Processes
The following process is used for service items:
Line Flow - Standard Service: Use this process for service items such as support. Once the line is fulfilled, invoice interfacing occurs.
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 Flow - Generic: Flow without approval. Prepare quote, get customer final acceptance, and converts the negotiation to an order.
Negotiation Flow - Generic with Approval: Flow with Approval. Prepare quote, get management approval, get customer final acceptance, and converts the negotiation to an order.
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.
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 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.
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
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.
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:
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).
Define Process Time-out as Yes, and all other parameters as No. This can run less frequently (for example, once every 30 - 60 minutes).
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.
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:
OM: Source For TP Early Ship/Deliver Date
OM: Sequence For TP Ship/Deliver Deadline
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:
Deferred? If set to yes, the WF background engine will pick up all deferred lines.
Timeout? If set to yes, the WF background engine will pick up all timed-out lines.
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.
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.
The standard schedule workflow activity performs the following functions:
Obtain a ship-from location for an order line.
Obtain the schedule date for an order line.
Obtain other scheduling attributes, including delivery lead time and shipping methods, for an order line.
Reserve order lines (when within the reservation time fence period).
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.
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.
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:
When repricing should occur
Which pricing event phases are executed when repricing
Whether to ignore the Calculate Price flag value for an order line
Note: You must use the Reprice activity to access repricing functionality.
For more information about the pricing functionality in Oracle Order Management, refer to the Oracle Order Management User's Guide.
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:
Actual shipment date
Schedule ship date
Fulfillment date
Promise date
Request date
System date
You can select the original pricing date on the order line if you set the Repricing Date attribute to Null.
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:
Line
Price
Reprice Line
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.
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:
Yes: Honors the value of the calculate price flag on the order.
No: Ignores the value of the calculate price flag.
Repricing and freight charge recalculation occurs regardless of the value of the calculate price flag.
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.
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:
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.
Place the Reprice activity after the fulfillment activity in your workflow.
Set the following workflow attributes:
Repricing Date: Fulfillment date
Repricing Event: Reprice Line or another defined event
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 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.