Seeded Subprocess Definitions

This chapter covers the following topics:

• OM Order Header Subprocesses
• Approve Return - Order
• Approve Return – Order with Mixed Lines
• Book - Order, Deferred
• Book - Order, Manual
• Close - Order
• Header Level Invoice Interface - Order
• OM Order Line Subprocesses
• Authorized to Ship - Line
• Buy ATO Item Flow
• Calculate Lead Time - Line
• Close - Line
• Create ATO Supply
• Create Configuration - Line, Manual
• Create Manufacturing Configuration Data - Line, Manual
• Create Supply - Line
• Create Supply Order - Line, Manual
• Create Work Order - Line
• Enter - Line
• Export Compliance Screening - Line
• Header Level Invoice Interface - Line, Deferred
• Header Level Invoice Interface for Return Line w/o Receipt
• Header Level Invoice Interface for Return Line with Receipt
• Inventory Interface Non-Ship - Line
• Inventory Interface Non-Ship - Line, Deferred
• Invoice Interface - Line
• Invoice Interface - Line, Deferred
• Purchase Release - Line, Deferred
• Purchase Release - Line, Deferred - ATO
• Purchase Release - Line, Manual
• Reprice - Line
• Return Receiving - Line
• Schedule - Line
• Schedule - Line, Deferred
• Ship - Line, Manual
• Wait to Firm - Line
• Wait to Fulfill Line
• Negotiation Subprocesses
• Submit Draft - Negotiation
• Complete - Negotiation
• Internal Approval - Negotiation
• Customer Acceptance - Negotiation Process
• Offer Expiration - Negotiation Process
• Blanket Agreement/Sales Order Generation
• Sales Agreement Subprocesses
• Notifications for Sales Agreement Processes
• Execute - Blanket
• Terminate—Blanket
• Close—Blanket

OM Order Header Subprocesses

Approve Return - Order

The Approve Return - Order subprocess runs a sequence of activities that approve the return of a sales order. Approve Return - Order is a non-runnable flow and is initiated as a subprocess of the following order flow:

• Order Flow - Return with Approval

Approve Return - Order subprocess initiates as part of the Order Flow - Return with Approval process. When sales order return is submitted, this subprocess sends a notification to verify authorization for that order return. This subprocess can end with the following results:

• Complete

• Incomplete

If the return is not authorized, the process ends with an incomplete result and returns to the order flow. If the return is authorized, the subprocess ends and returns to the order flow.

Approve Return - Order is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

Summary of the Approve Return - Order Subprocess

To view the properties of the Approve Return - Order subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Approve Return - Order has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Approve Return - Order, you see that the process consists of 8 unique activities, which comprise the activity nodes that appear in the workflow diagram. The following diagram depicts the Approve Return - Order subprocess.

Approve Return - Order Workflow Process

The Approve Return - Order process begins when the following order flow is initiated:

• Order Flow - Return with Approval

The workflow begins with the Startactivity node.

The Utility - Set Notification Approver activity determines to whom notification is sent. Once this is determined, the process sends the Approve Return Order notification. If the return is authorized, then the notification returns a pass result and process is approved at the Approve - Continue Line activity. The process then ends with a complete result and returns to the order flow.

If the return is not authorized , then the workflow updates the return order status to Reject – Pending Cancellation. The notification then returns a failing result and the process proceeds to the Approval Failed block activity. The process then waits until the return is canceled.

Approve Return - Order Activities

The tables in this section provide descriptions of each activity in the Approve Return - Order subprocess.

For more information about individual function activities, refer to Seeded Function Activity Definitions.

The following table displays the different function activities in the Approve Return - Order subprocess.

Approve Return - Order Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
Utility - Set Notification Approver	OE_ORDER_WF_UTIL.SET_NOTIFICATION_APPROVER	None	Yes
Approve - Continue Line	WF_STANDARD.CONTINUEFLOW	None	Yes
End (Complete)	WF_STANDARD.NOOP	None	Yes
Update Status to Rejected – Pending Cancellation	OE_RMA_WF. UPD_FLOW_STATUS_CODE_REJ	None	Yes
Approval Failed	WF_STANDARD.BLOCK	None	Yes
End (Incomplete)	WF_STANDARD.NOOP	None	Yes

Approve Return – Order with Mixed Lines

The Approve Return – Order with Mixed Lines subprocess runs a sequence of activities that approve the return of a sales order with mixed lines. Approve Return - Order with Mixed Lines is a non-runnable flow and is initiated as a subprocess of the following order flow:

• Order Flow - Mixed or Return with Approval

Approve Return - Order with Mixed Lines runs as part of the order flow – Mixed or Return with Approval. When sales order return with mixed lines is submitted, this subprocess sends a notification to verify authorization for that order return. This subprocess can end with the following results:

• Complete

• Incomplete

If the return is not authorized, then the process ends with result Incomplete and returns to the order flow. If the return is authorized, then the subprocess ends with result Complete and returns to the order flow.

Approve Return - Order with Mixed Lines is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

Summary of the Approve Return - Order with Mixed Lines Subprocess

To view the properties of the Approve Return – Order with Mixed Lines subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Approve Return – Order with Mixed Lines has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Approve Return – Order with Mixed Lines, you see that the process consists of 7 unique activities, which comprise the activity nodes that appear in the workflow diagram. The following diagram depicts the Approve Return – Order with Mixed Lines subprocess.

Approve Return - Order with Mixed Lines Workflow

The Approve Return - Order with Mixed Lines process begins when the following order flow is initiated:

• Order Flow - Mixed or Return with Approval.

The workflow begins with the Startactivity node.

The Utility - Set Notification Approver activity determines to whom notification is sent. Once this is determined, the process sends the Approve Return Order notification. If the return is authorized, then the notification returns a pass result and process is approved at the Approve - Continue Line activity. The process then ends with a complete result and returns to the order flow.

If the return is not authorized, then the notification returns a failing result and the process proceeds to the activity Update Status to Rejected, which updates order status to Return Rejected and status of all pending return lines to Rejected - Pending Cancellation. The process then ends with result Incomplete and returns to order flow.

Approve Return – Order with Mixed Lines Activities

The tables in this section provide descriptions of each activity in the Approve Return - Order with Mixed Lines subprocess. For more information about individual function activities, refer to Seeded Function Activity Definitions. The following table displays the different function activities in the Approve Return - Order with Mixed Lines subprocess.

Approve Return - Order with Mixed Lines Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NO OP	None	Yes
Utility - SetNotificationApprover	OE_ORDER_WF_UTIL.SET_NOTIFICATION_APPROVER	None	Yes
Approve - ContinueLine	WF_STANDARD.CONTINUEFLOW	None	Yes
End (Complete)	WF_STANDARD.NOOP	None	Yes
Update Status to Rejected	OE_RMA_WF. UPD_FLOW_STATUS_CODE_MIX_REJ	None	Yes
End (Incomplete)	WF_STANDARD.NOOP	None	Yes

Book - Order, Deferred

Book - Order, Deferred enables you to move booking to the background engine. This can be used when you must enter many orders and cannot wait for each individual order to book before moving on. Book - Order, Deferred moves the booking process to the background engine.

When you use the Book - Order, Deferred subprocess, you do not need to specifically request for an order to book. The order will book when the Workflow Background Process concurrent program processes the activity.

The Book - Order, Deferred process ends only after an order is booked. After the order is booked, the subprocess ends and returns to the line flow.

Book - Order, Deferred is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

For more information on the Workflow Background Engine, refer to Processing Orders Using Oracle Workflow.

Summary of the Book - Order, Deferred Subprocess

To view the properties of the Book - Order, Deferred subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Book - Order, Deferred has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Book - Order, Deferred process, you see that the process consists of 4 unique activities, which comprise the 4 activity nodes that appear in the workflow diagram. The following diagram depicts the Book - Order, Deferred subprocess. Each node of this subprocess is numbered for referencing.

Book - Order Deferred Subprocess Workflow

The Book - Order, Deferred workflow begins at node 1 with the Book - Deferred activity.

At the Book activity in node 2 is a seeded lookup activity that can complete with a result of Incomplete, On Hold, Not Eligible, or Complete. A Complete or Not Eligible result leads to the Book - Continue Line (Complete) activity in node 3. An On Hold or Incomplete result leads to Book - Eligible activity in node 4. After the eligibility is determined, the process moves back to the Book activity in node 2. This process can only end after the order is booked.

Book - Order, Deferred Activities

The following table provides descriptions of each activity in the Book - Order, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Book - Order Deferred Subprocess Activities

Activity	Function	Result Type	Required
Book - Deferred (node 1)	WF_STANDARD.DEFER	None	Yes
Book (node 2)	OE_BOOK_WF.BOOK_ORDER	OM Subprocess results, handles holds	Yes
Book - Continue Line (Complete) (node 3)	WF_STANDARD.CONTINUEFLOW	None	Yes
Book - Eligible (node 5)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes

Book - Order, Manual

Book - Order, Manual is a subprocess that enables you to book an order manually by using the Book - Eligible activity. Book - Order, Manual is a non-runnable flow that is initiated as a subprocess of the following line flows:

• Order Flow - Generic

• Order Flow - Generic with Header Level Invoice Interface

• Order Flow - Return with Approval

The Book - Order, Manual process ends only after the order is booked. After the order is booked, the subprocess ends and returns to the line flow.

Book - Order, Manual is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

Summary of the Book - Order, Manual Subprocess

To view the properties of the Book - Order Manual subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Book - Order, Manual has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Book - Order, Manual process, you see that the process consists of 4 unique activities, which comprise the 4 activity nodes that appear in the workflow diagram. The following diagram depicts the Book - Order, Manual subprocess. Each node of this subprocess is numbered for referencing.

Book - Order Manual Subprocess Workflow

The Book - Order, Manual subprocess begins when the following line flows are initiated:

• Order Flow - Generic

• Order Flow - Generic with Header Level Invoice Interface

• Order Flow - Return with Approval

The workflow begins at node 1 with the Start activity.

At the Book - Eligible activity in node 2, the process waits for you to manually verify that the order is eligible for booking. When eligibility is determined, the process proceeds to the Book activity at node 3. After booking is complete, the processes ends and returns to its parent line flow.

Book - Order, Manual Activities

The following table provides descriptions of each activity in the Book - Order, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Book - Order Manual Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.DEFER	None	Yes
Book - Eligible (node 2)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes
Book (node 3)	OE_BOOK_WF.BOOK_ORDER	OM Subprocess Results, Handles Holds	Yes
Book - Continue Line (Complete) (node 4)	WF_STANDARD. CONTINUEFLOW	None	Yes

Close - Order

The Close - Order subprocess closes an order in Oracle Order Management. Close - Order is a non-runnable flow that is initiated as a subprocess of the following order flows:

• Order Flow - Generic

• Order Flow - Generic with Header Level Invoice Interface

• Order Flow - Return with Approval

The Close - Order process can end with a result of not eligible or complete. After the order closes or is determined not eligible, the subprocess ends and returns to the order flow.

Close - Order is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

Summary of the Close - Order Subprocess

To view the properties of the Close - Order subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Close - Order has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Close - Order process, you see that the process consists of 6 unique activities, which comprise the 6 activity nodes that appear in the workflow diagram. The following diagram depicts the Close - Order subprocess. Each node of this subprocess is numbered for referencing.

Close - Order Subprocess Workflow

The Close - Order process begins when the following order flows are initiated:

• Order Flow - Generic

• Order Flow - Generic with Header Level Invoice Interface

• Order Flow - Return with Approval

The workflow begins at node 1 with the Wait activity.

At the Close - Wait for Line activity in node 2, the process determines whether the all of the order lines in the order are closed before proceeding with the Close activity at node 3. Once the order is successfully closed, the subprocess moves to the End (Complete) activity at node 4.

If the Close activity returns an On Hold or Incomplete result, the process moves to another Wait activity at node 6. If the Close activity returns not eligible result, the process moves to the End (Incomplete) activity at node 5.

Close - Order Activities

The following table provides descriptions of each activity in the Close - Order subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Close - Order Subprocess Activities

Activity	Function	Result Type	Required
Wait (node 1)	WF_STANDARD.WAIT	None	Yes
Close - Wait for Line (node 2)	WF_STANDARD.WAITFORFLOW	None	Yes
Close (node 3)	WF_STANDARD.NOOP	None	Yes
End (Complete) (node 4)	WF_STANDARD.NOOP	None	Yes
End (Not Eligible) (node 5)	WF_STANDARD.NOOP	None	Yes
Wait (node 6)	WF_STANDARD.WAIT	None	Yes

Header Level Invoice Interface - Order

The Header Level Invoice Interface - Order subprocess conducts a series of activities that interface with Oracle Receivable to determine invoicing information for an order. Header Level Invoice Interface - Order is a non-runnable flow that is initiated as a subprocess of the following order flow:

• Order Flow - Generic with Header Level Invoice Interface

Header Level Invoice Interface - Order can be used only with Order Flow - Generic with Header Level Invoice Interface.

The Header Level Invoice Interface - Order process ends only after header level invoice information for an order is determined. After this information is received, the subprocess ends and returns to the line flow.

Header Level Invoice Interface - Order is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.

Summary of the Header Level Invoice Interface - Order Subprocess

To view the properties of the Header Level Invoice Interface - Order subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Header Level Invoice Interface - Order has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. When you display the Process window for the Header Level Invoice Interface - Order process, you see that the process consists of 5 unique activities, which comprise the 5 activity nodes that appear in the workflow diagram. The following diagram depicts the Header Level Invoice Interface - Order subprocess. Each node of this subprocess is numbered for referencing.

Header Level Invoice Interface - Order Subprocess Workflow

The Header Level Invoice Interface - Order process begins as a subprocess of the following process:

• Order Flow - Generic with Header Level Invoice Interface

The workflow begins at node 1 with the Start activity.

At the Fulfill - Wait for Line activity in node 2, the process waits for all of the order lines to fulfill before proceeding with the order flow. The process then moves to the Invoice Interface - Header Level activity at node 3. After Oracle Order Management interfaces with Oracle Receivables for the order the process moves to Invoice Interface - Continue Line and returns to its parent order flow.

Header Level Invoice Interface - Order Activities

The following table provides descriptions of each activity in the Header Level Invoice Interface subprocess.

For more information about individual activities, refer to, Seeded Function Activity Definitions.

Header Level Invoice Interface - Order Subprocess Activities

Activity	Function	Result Type	Required
Start (Node 1)	WF_STANDARD.NOOP	None	Yes
Fulfill - Wait for Line (Node 2)	OE_RLM_WF.CHECK_AUTHORIZE_TO_SHIP	Yes/No	Yes
Invoice Interface - Header Level (Node 3)	WF_STANDARD.NOOP	None	Yes
Invoice Interface - Continue Line (Node 4)	WF_STANDARD.BLOCK	None	No
Header Invoice Interface - Eligible (Node 4)	WF_STANDARD.BLOCK	None	No

OM Order Line Subprocesses

Authorized to Ship - Line

The Authorized to Ship is a subprocess specific to Oracle Release Management users. Authorize to Ship - Line verifies that a line is eligible for shipping. Authorized to Ship - Line is a non-runnable flow that is initiated as a subprocess of the following process:

• Line Flow - Generic with Authorize to Ship (RLM)

This subprocess verifies that an item is approved for shipping. If the item is not authorized for shipping, a hold is placed on the item. This subprocess will hold a line until it is authorized to ship.

The Authorize to Ship - Line process ends only when authorization to ship is granted. After the line is authorized, the subprocess ends and returns to the line flow.

Authorize to Ship - Line is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Authorized to Ship - Line Subprocess

To view the properties of the Authorize to Ship - Line subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Authorize to Ship - Line has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Authorize to Ship - Line process, you see that the process consists of 4 unique activities, which comprise the 4 activity nodes that appear in the workflow diagram. The following diagram depicts the Authorized to Ship - Line subprocess. Each node of this subprocess is numbered for referencing.

Authorized to Ship - Line Subprocess Workflow

The Authorize to Ship - Line process begins when either of the following line flows are initiated:

• Line Flow - Configuration with Authorize to Ship (RLM)

• Line Flow - Generic with Authorize to Ship (RLM)

The workflow begins at node 1 with the Start activity.

At the Authorize to Ship - Check Status activity in node 2, the process attempts to verify whether the order line is authorized to ship. If the order line is authorized to ship (a Yes result), then the subprocess completes and returns to the line flow. If the order line is not authorized to ship, then the process waits until authorization is granted before proceeding.

Authorized to Ship - Line Activities

The following table provides descriptions of each activity in the Authorize to Ship - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Authorize to Ship Line Subprocess Activities

Activity	Function	Result Type	Required
Start (Node 1)	WF_STANDARD.NOOP	None	Yes
Authorize to Ship - Check Status (Node 2)	OE_RLM_WF.CHECK_AUTHORIZE_TO_SHIP	Yes/No	Yes
End (Node 3)	WF_STANDARD.NOOP	None	Yes
Authorize to Ship - Wait for Authorization (Node 4)	WF_STANDARD.BLOCK	None	No

Buy ATO Item Flow

Buy ATO Item Flow is a subprocess of the Create ATO Supply workflow. Order lines follow this subprocess when the ATO item on the line has the Buy planning attribute on the organization item master, or when the buy type sourcing rules are assigned to it in the shipping warehouse. For these lines, the Buy ATO Item Flow transfers a record to the requisition interface tables for this order line. Once the data is placed in the requisition interface tables, this workflow subprocess ends and returns to its parent flow.

Buy ATO Item Flow is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Buy ATO Item Flow Subprocess

To view the properties of the Buy ATO Item Flow subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which means that it can be assigned to a transaction type.

The Details property page of the process activity indicates that Buy ATO Item Flow has an error item type of WFERROR. This item type is associated with the RETRY_ ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Buy ATO Item Flow process, you see that the process consists of 4 unique activities, which comprise the 4 activity nodes that appear in the workflow diagram. The following diagram depicts the Buy ATO Item Flow subprocess. Each node of this subprocess is numbered for referencing.

Buy ATO Item Flow Subprocess Workflow

The Buy ATO Item Flow begins at node 1 with the Start activity.

At node 2, the AutoCreate PO Req activity transfers its record to the requisition interface tables for the order line. Upon successful completion of this activity, the process moves to the End (Complete) activity at node 3.

Buy ATO Item Flow Activities

The following table provides descriptions of each activity in the Buy ATO Item Flow subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Buy ATO Item Subprocess Activities

Activity	Function	Result Type	Required
Start (Node 1)	WF_STANDARD.NOOP	None	Yes
AutoCreate PO Req (Node 2)	CTO_WORKFLOW_API_PK.AUTO_CREATE_PUR_REQ	Config Process Results	Yes
End (Complete) (Node 3)	WF_STANDARD.NOOP	None	Yes
End (Incomplete) (Node 4)	WF_STANDARD.NOOP	None	Yes

Calculate Lead Time - Line

The Calculate Lead Time subprocess is specific to Oracle Configure to Order users. This process is a non-runnable flow initiated as a subprocess of the following line flow:

• Create Manufacturing Configuration Data - Line, Manual

The Calculate Lead Time subprocess is initiated after Create Configuration - Line, Manual completes. Calculate Lead Time is initiated to determine the actual lead time of the configuration item in the organization in which it will be manufactured. The process updates the lead time attributes on the item master for the configuration item that organization.

If the configuration item has routing associated with it, the Calculate Lead Time subprocess ends when calculation is complete. If the configuration item does not have routing, this process ends without performing the calculation

Calculate Lead Time - Line is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Calculate Lead Time - Line Subprocess

To view the properties of the Calculate Lead Time - Line subprocess, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Calculate Lead Time

- Line has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Calculate Lead Time - Line subprocess, you see that the process consists of 4 unique activities which comprise the nodes in the workflow diagram.

The following image depicts the workflow diagram for the Calculate Lead Time - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Calculate Lead Time - Line Subprocess Workflow

Calculate Lead Time - Line begins as a subprocess of the following line flow:

• Create Manufacturing Configuration Data - Line, Manual

The workflow begins at node 1 with the Start activity.

At the Calculate Lead Time - Setup Parameters activity in node 2, the process sets the line number as the parameter of the concurrent program for lead time calculation and then moves to the Calculate Lead Time activity in node 3, where lead time is calculated. The process then moves to the End activity at node 4, and returns to its parent line flow. If at the Calculate Lead Time - Setup Parameters activity no routing is found, lead time is not calculated and the process proceeds directly to the End activity at node 4.

Calculate Lead Time - Line Process Activities

The following table provides descriptions of each activity in the Calculate Lead Time - Line subprocess.

For more information about individual activities, refer toSeeded Function Activity Definitions.

Calculate Lead Time - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Calculate Lead Time - Setup Parameters (node 2)	CTO_WORKFLOW.SET_PARAMETER_LEAD_TIME_WF_ML	Lead Time Result	Yes
Calculate Lead Time (node 3)	CTO_WORKFLOW.SUBMIT_AND_CONTINUE_WF	None	No
End (node 4)	WF_STANDARD.NOOP	None	Yes

Close - Line

The Close - Line process closes a line in a line flow and is mandatory for all line level processes. Close - Line is a non-runnable subprocess initiated at the end of the following line flows:

• Line Flow - ATO Item

• Line Flow - ATO Model

• Line Flow - Configuration

• Line Flow - Configuration with Authorize to Ship (RLM)

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Bill Only

• Line Flow - Generic, Bill Only with Inventory Interface

• Line Flow - Generic, Ship Only

• Line Flow - Generic, with Repricing at Fulfillment

• Line Flow - Return for Credit Only

• Line Flow - Return for Credit Only with Approval

• Line Flow - Return for Credit with Receipt

• Line Flow - Return for Credit with Receipt and Approval

• Line Flow - Standard Service

Each time an order line is saved, a workflow process is initiated. After the workflow runs through its functions, activities and subprocesses, it concludes with the Close - Line subprocess.

An order line is eligible to close when it completes all of the line-level activities within the workflow process. Order lines can close independent of each other. Once an order line is closed, no changes can be made to any fields except the descriptive flexfield, for which you can define processing constraints.

The Close - Line subprocess is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Close - Line Subprocess

To view the properties of the Close - Line subprocess, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that Close - Line has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Close - Line process, you see that the process consists of 4 unique activities which comprise the activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Close - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Close - Line Subprocess Workflow

The Close - Line workflow begins at the end of runnable line flow. The workflow ends only when the order line is determined complete or not eligible.

The workflow begins at node 1 with the Start activity.

In the Close activity at node 2, the process attempts to close the line. This activity has four possible results:

• Complete

• Not Eligible

• Incomplete

• On Hold

If, after attempting to close, a result of Incomplete or On Hold is returned, the process conducts the Wait activity at node 4, which waits until the line is complete or the hold is released. The Wait activity has a default waiting time of 1 day. If the line is determined complete or not eligible, the line closes and proceeds to the Close - Continue Header activity at node 3, which signifies to the header level parent flow that the line is closed. The subprocess then ends and returns to its parent flow.

Close - Line Process Activities

The following table provides descriptions of each activity in the Close - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Close - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Close (node 2)	OE_CLOSE_WF.CLOSE_LINE	OM subprocess Results, handles Holds	Yes
End (node 3)	WF_STANDARD.NOOP	None	Yes
Wait (node 4)	WF_STANDARD.WAIT	None	Yes

Create ATO Supply

Create ATO Supply is a workflow subprocess that automates the creation of assemble-to-order supply for an order line. This process is a subprocess of the following workflow:

• Create Supply Order - Line, Manual

The Create ATO Supply subprocess determines the need for supply creation by branching according to supply type. The supply type is determined using the source type of the order line, the planning Make or Buy type, and the sourcing rules of the item. This subprocess evaluates the supply type to determine which branch to follow.

Create ATO Supply contains the following subprocesses:

• Purchase Release - Line, Deferred - ATO

• Create Work Order - Line

• Buy ATO Item Flow

Create ATO Supply can end with an incomplete or complete result.

Create ATO Supply is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Create ATO Supply Process

To view the properties of the Create ATO Supply process, select the process in the navigator tree and then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that the Create ATO Supply process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Create ATO Supply, you see that the process consists of 5 unique activities and 3 subprocesses, which comprise the 8 nodes that appear in the workflow diagram. The following diagram depicts the Create ATO Supply process. Each node of this process is numbered for referencing.

Create ATO Supply Subprocess Workflow

The workflow begins at node 1 with the Start activity.

In the Check Supply Type activity at node 2, the process determines the supply type for the order line. This activity has five possible results:

• Drop Ship

• Buy

• Work Order

• Flow Schedule

• Incomplete

If the supply type is Drop Ship, the process initiates the Purchase Release - Line, Deferred - ATO subprocess at node 5. Once this completes, the process resumes and proceeds to the End (Complete) activity at node 4.

If the supply type is Buy, the process initiates the Buy ATO Item Flow subprocess at node 6. Once this completes, the process resumes and proceeds to the End (Complete) activity at node 4, or, if Buy ATO Item Flow returns an incomplete result, the process proceeds to the End (Incomplete) activity at node 8.

If the supply type is Work Order, the process initiates the Create Work Order - Line process at node 3. Once this completes, the process proceeds the End (Complete) activity at node 4. If the Create Work Order - Line returns an incomplete result, the process proceeds to the End (Incomplete) activity at node 8.

If the supply type is Flow Schedule, the process initiates the Create Flow Schedule activity at node 7. The process then moves to the End (Complete) activity at node 4, or, if Create Flow Schedule returns an incomplete result, the process proceeds to the End (Incomplete) activity at node 8.

If the Check Supply Type activity has an error or is unable to determine a supply type, the process moves directly to the End (Incomplete) activity at node 8.

Create Configuration - Line, Manual

Create Configuration - Line, Manual is a workflow process that creates configuration for a line flow. This process is initiated as a subprocess of the following workflows:

• Line Flow - ATO Model line flow

• Create Supply - Line subprocess

Create Configuration - Line, Manual is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

This process can only end after configuration for the line is complete.

Summary of the Create Configuration - Line, Manual Process

To view the properties of the Create Configuration - Line, Manual process, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which means that it cannot be assigned to a transaction type; it is a subprocess of a runnable flow.

The Details property page of the process activity indicates that the Create Configuration - Line, Manual process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Create Configuration - Line, Manual process, you see that the process consists of 5 unique activities which comprise the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Create Configuration - Line, Manual subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Create Configuration - Line Manual Subprocess Workflow

If you use Line Flow - Generic to process ATO Models, this subprocess begins when the Create Supply - Line subprocess is initiated. If you use Line Flow - ATO Model this subprocess begins after the Schedule - Line subprocess completes.

The Create Configuration - Line, Manual subprocess begins at node 1 with the Start activity.

At the Create Configuration - Eligible activity in node 2, you must manually progress the order. Once this authorization is granted, the process proceeds to the Create Configuration activity at node 3. This activity has three possible results:

• Complete

• Incomplete

• On Hold

If the result of this activity is Incomplete or On Hold, the process returns to the Create Configuration - Eligible activity at node 2. If the result returned from the Create Configuration activity is complete, the process proceeds to the Wait for CTO activity at node 4. This activity has two possible results:

• Complete

• De-Link

If the result of this activity is De-Link, the process returns to the Create Configuration - Eligible activity at node 2. If the result of the Wait for CTO activity is Complete, then the process continues to End at node 5.

Create Configuration - Line, Manual Process Activities

The following table provides descriptions of each activity in the Create Configuration - Line, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Create Configuration - Line Manual Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Create Configuration - Eligible (node 2)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes
Create Configuration (node 3)	CTO_WORKFLOW.CREATE_CONFIG_ITEM_WF	Config Incomplete	Yes
Wait for CTO (node 4)	WF_STANDARD.BLOCK	Config Item Results	Yes
End (node 5)	WF_STANDARD.NOOP	None	Yes

Create Manufacturing Configuration Data - Line, Manual

Create Manufacturing Configuration Data - Line, Manual is a workflow subprocess that creates the manufacturing configuration data for an order line. Create Manufacturing Configuration Data - Line, Manual is a non-runnable flow that is initiated as a subprocess of the following line flows:

• Line Flow - Configuration

• Line Flow - Configuration with Authorize to Ship (RLM)

Create Manufacturing Configuration Data - Line, Manual contains the following subprocess:

• Calculate Lead Time - Line

Every time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is Line Flow - Configuration or Line Flow - Configuration with Authorize to Ship (RLM), the Create Manufacturing Configuration Data - Line, Manual process is initiated as a subprocess of the line flow.

The Create Manufacturing Configuration Data - Line, Manual is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of Create Manufacturing Configuration Data - Line, Manual Process

To view the properties of the Create Manufacturing Configuration Data - Line, Manual process, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess of a line flow.

The Details property page of the process activity indicates that the Create Manufacturing Configuration Data - Line, Manual process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Create Manufacturing Configuration Data - Line, Manual process shows that the process consists of 5 unique activities and 1 subprocess which comprise the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Create Manufacturing Configuration Data - Line, Manual subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Create Manufacturing Configuration Data - Line Manual Subprocess Workflow

The Create Manufacturing Configuration Data - Line, Manual begins after Line Flow - Configuration or Line Flow - Configuration with Authorize to Ship (RLM) is selected as the appropriate line flow for the order line. The Create Manufacturing Configuration Data - Line, Manual process is initiated as a subprocess of the selected line flow.

The workflow begins at node 1 with the Start activity.

In the Wait for Create Configuration activity at node 2 the process waits for the configuration data to complete. This activity can proceed down the default path, or, if the configuration data is already created, the subprocess can proceed to the End activity at node 5. Configuration data might already be created if the user created the configuration item using the Autocreate Config batch program, rather than progressing the workflow process.

If the process proceeds down the default path, it comes to node 3, Calculate Cost Rollup. Once this activity completes, the process proceeds to node 4: the Calculate Lead Time - Line subprocess. After successfully completing the calculate purchase price subprocess, the process moves to Calculate Purchase Price activity at node 5.

After Calculate Purchase Price finishes, the process proceeds to the End activity at node 6.

Create Manufacturing Configuration Data - Line, Manual Process Activities

The following table provides descriptions of each activity in the Create Manufacturing Configuration Data - Line, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Create Manufacturing Configuration Data - Line Manual Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Wait for Create Configuration (node 2)	WF_STANDARD.BLOCK	Config Data Results	Yes
Calculate Cost Rollup (node 3)	CTO_WORKFLOW.CALCULATE_COST_ROLLUP_WF_ML	None	Yes
Calculate Purchase Price (node 3)	CTO_WORKFLOW.PURCHASE_PRICE_CALC_WF	None	Yes
End (node 5)	WF_STANDARD.NOOP	None	Yes

Create Supply - Line

The Create Supply - Line subprocess creates supply for an order line. It is a non-runnable flow initiated as a subprocess of the following line flows:

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Ship Only

• Line Flow - Generic, with Repricing at Fulfillment

• Line Flow - Standard Service

Create Supply - Line contains the following subprocesses:

• Create Supply Order - Line, Manual

• Create Configuration - Line, Manual

• Purchase Release - Line, Deferred

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Create Supply - Line process will initiate as a subprocess of the line flow.

The first activity in this process is the Branch on Source Type activity. This activity evaluates the line source type and item attributes to determine the line type: drop ship, ATO Model, ATO Item, or standard item. If it is a dropship, ATO Model, or ATO Item, supply for the items must be created.

The Create Supply - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Create Supply - Line Process

To view the properties of the Create Supply - Line subprocess, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Create Supply - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Create Supply - Line process shows that the process consists of 5 unique activities. One activity is reused to comprise the 8 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Create Supply - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Create Supply - Line Subprocess Workflow

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Ship Only

• Line Flow - Generic, with Repricing at Fulfillment

• Line Flow - Standard Service

The workflow begins at node 1 with the Branch on Source Type activity. This activity has five possible results:

• Default

• ATO Item

• Stock

• Build

• Dropship

When ATO Item is selected, the process leads to the Create Supply Order - Line, Manual subprocess in node 3. Once this subprocess is completed, the process proceeds to the End activity at node 4.

All internal standard items and non-shippable lines such as classes, ATO options, and service lines follow the stock flow. This flow indicates that Oracle Order Management must not create supply for the item (planning will provide supply for the item). The item is eligible for shipping on its schedule date. Non-shippable lines are fulfilled after their dependencies are fulfilled.

An ATO model has the Build result type, which leads to the Create Configuration - Line, Manual subprocess in node 6. Once this process completes, the subprocess moves to the End activity in node 5.

All standard (non-ATO) items which have a source type code of External continue through the dropship workflow activity process. Oracle Order Management's Purchase Release subprocess is used for these order lines.

If the source type is not ATO Item, Stock, Build, or Dropship the process proceeds to the End activity at node 2, and the order line flow continues.

Create Supply - Line Process Activities

The following table provides descriptions of each activity in the Create Supply Order - Line, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Create Supply Order - Line Manual Subprocess Activities

Activity	Function	Result Type	Required
Branch on Source Type (node 1)	OE_OEOL_SCH.BRANCH_ON_SOURCE_TYPE	Source Type	Yes
End (nodes 2, 4, 5, 8)	WF_STANDARD.NOOP	None	Yes

Create Supply Order - Line, Manual

Create Supply Order - Line, Manual is a workflow subprocess that creates supply for ATO items and configurations. It first verifies that there is a reservation already on the sales order line. If there is, the subprocess ends. If there is no reservation, the subprocess encounters the Create Supply Order - Eligible block activity and waits until the user progresses the order line to the Create ATO Supply subprocess, or creates and reserves supply manually.

Create Supply Order - Line, Manual is initiated as a subprocess of the following workflow subprocess:

• Create Supply - Line

Create Supply Order - Line, Manual is initiated as a subprocess of the following runnable flows:

• Line Flow - ATO Item

• Line Flow - Configuration

• Line Flow - Configuration with Authorize to Ship (RLM)

The Create Supply Order - Line, Manual subprocess contains the following subprocess:

• Create ATO Supply

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Create Supply Order - Line, Manual process is initiated as a subprocess of the line flow.

The Create Supply Order - Line, Manual process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Create Supply Order - Line, Manual Process

To view the properties of the Create Supply Order - Line, Manual process, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Create Supply Order - Line, Manual process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Create Supply Order - Line, Manual process shows that the process consists of 4 unique activities and 1 subprocess, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Create Supply Order - Line, Manual subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Create Supply Order - Line Manual Subprocess Workflow

The Create Supply Order - Line, Manual process begins when its parent line flow or the Create Supply - Line subprocess initiates it as part of its flow. The workflow begins at node 1 with the Start activity.

At node 2, the Check Reservation activity determines whether there is quantity reserved to this line. If there is, the process proceeds directly to the End activity at node 5. If there is no reservation to the line, the process proceeds to the Create Supply Order - Eligible activity at node 3.

The Create Supply Order - Eligible activity at node 3 waits until the user progresses the order line to the Create ATO Supply subprocess at node 4. After Create ATO Supply completes, the line flow proceeds to the End activity at node 5, and returns to its parent line flow.

Create Supply Order - Line, Manual Process Activities

The following table provides descriptions of each activity in the Create Supply Order - Line, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Create Supply Order - Line Manual Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Check Reservation (node 2)	CTO_WORKFLOW.RSV_BEFORE_BOOKING_WF	Reserved Status	Yes
Create Supply Order - Eligible (node 3)	OE_STANDARD_WF.STANDARD_BLOCK	Reserved Status	No
End (node 5)	WF_STANDARD.NOOP	None	Yes

Create Work Order - Line

The Create Work Order - Line subprocess is a workflow process that is initiated as a subprocess of the Create ATO Supply subprocess. Create Work Order - Line is associated with assemble to order items.

The process can end with a complete or incomplete result. It ends with an incomplete result if the following occurs:

• There is an error during parameter setup.

• The order line is on hold.

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Create Work Order - Line process is initiated as a subprocess of the line flow.

The Create Work Order - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Create Work Order - Line Process

To view the properties of the Create Work Order - Line subprocess, select the process in the navigator tree, then select Properties from the Edit menu. The Create Work Order - Line process has a result type of Config Process Results, indicating that when the process completes, it has a result of either complete (work order created) or incomplete (work order not completed). This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Create Work Order - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Create Work Order - Line process shows that the process consists of 6 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Create Work Order - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Create Work Order - Lone Subprocess Workflow

The Create Work Order - Line workflow begins at node 1 with the Start activity. At node 2, the Create Work Order - Set Up Parameters activity prepares to launch AutoCreate FAS by setting up the line number as the parameter for the program. When the Create Work Order - Set Up Parameters activity completes with a result of incomplete or on hold, the process moves directly to the End (Incomplete) activity at node 6. If the process ends as incomplete, the parent process moves back to Create Supply Order - Eligible.

When the activity completes with a result of complete, it proceeds to the AutoCreate FAS activity at node 3. This activity initiates a concurrent program to create a work in process job for the order line, and then waits until the concurrent program completes before continuing. When it completes, the activity verifies the result. If the result is Normal, the process proceeds to the End (Complete) activity at node 4.

If the result is not Normal, the process moves to the Retry AutoCreate FAS notification activity. A notification is then sent to the Order Management Workflow administrator with the following message: Failed AutoCreate FAS. From this notification, the AutoCreate FAS activity can be retried (leading back to node 2), or aborted, which leads to the End (Complete) at node 4.

Create Work Order - Line Process Activities

The following table provides descriptions of each activity in the Create Work Order - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Create Work Order - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Create Work Order - Set Up Parameters (node 2)	CTO_WORKFLOW.SET_PARAMETER_WORK_ORDER_WF	Config Incomplete	Yes
AutoCreate FAS (node 3)	CTO_WORKFLOW.SUBMIT_CONC_PROG_WF	Concurrent Program Status	Yes
End (Complete) (node 4)	WF_STANDARD.NOOP	None	Yes
End (Incomplete) (node 6)	WF_STANDARD.NOOP	None	Yes

Enter - Line

The Enter - Line subprocess verifies that lines on an order are booked before proceeding with the line flow. Enter - Line is associated with the following line flows:

• Line Flow - ATO Item

• Line Flow - ATO Model

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Bill Only

• Line Flow - Generic, Bill Only with Inventory Interface

• Line Flow - Generic, Ship Only

• Line Flow - Generic, with Repricing at Fulfillment

• Line Flow - Return for Credit Only

• Line Flow - Return for Credit Only with Approval

• Line Flow - Return for Credit with Receipt

• Line Flow - Return for Credit with Receipt and Approval

• Line Flow - Standard Service

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Enter - Line process is initiated as a subprocess of the line flow.

The Enter - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Enter - Line Process

To view the properties of the Enter - Line Process, select the process in the navigator tree, then select Properties from the Edit menu. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Enter - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Enter - Line process shows that the process consists of 2 unique activities, comprising the 2 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Enter - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Enter - Line Subprocess Workflow

The workflow begins at node 1 with the Wait for Booking activity. This activity is a standard block activity that requires an order flow to be booked before proceeding. After the order is booked the process proceeds to the End activity in node 2.

Enter - Line Process Activities

The following table provides descriptions of each activity in the Enter - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Enter - Line Subprocess Activities

Activity	Function	Result Type	Required
Wait for Booking (node 1)	WF_STANDARD.WAITFORFLOW	None	Yes
End (node 2)	WF_STANDARD.NOOP	None	Yes

Export Compliance Screening - Line

The Export Compliance Screening - Line subprocess performs Denied Party screening according to United States Bureau of Export Administration's Denied Party listing. This process is a subprocess of the following line flow:

• Line Flow - Generic, With Export Compliance

When an order line is submitted that must comply with the United States Bureau of Export Administration's Denied Party listing, this subprocess initiates. If the line passes this screening process, then the process approves the line for exporting and continues. If it does not meet export requirements, the process initiates a hold until the requirements are met.

The process can end with the following results:

• Complete

• On hold

• Override

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Export Compliance Screening - Line process is initiated as a subprocess of the line flow.

The Export Compliance Screening - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Export Compliance Screening - Line Process

To view the properties of the Export Compliance Screening - Line process, select the process in the navigator tree, then choose Properties from the Edit menu. The Export Compliance Screening - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Export Compliance Screening - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Export Compliance Screening - Line process shows that the process consists of 5 unique activities, comprising the 7 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Export Compliance Screening - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Export Compliance Screening - Line Subprocess Workflow

The Export Compliance Screening - Line process is initiated as a subprocess of the Line Flow - Generic, With Export Compliance line flow. The workflow begins at node 1 with the Start activity.

At node 2, the Export Compliance Screening activity attempts to verify whether the line meets export requirements. This activity has four possible results:

• Incomplete

• Override

• Complete

• Hold Applied

A Complete or Override result moves the process to the End activities at nodes 3 and 7, respectively.

An Incomplete result leads to the Export Compliance Screening - Eligible activity at node 4. This activity blocks the process from proceeding until it can produce a result of Complete, Override or On Hold.

An On Hold result leads to the Export Compliance Hold Applied notification activity at node 5. This activity sends notification indicating that an export compliance hold is applied to the line. Upon completion of this activity, the process proceeds to the End activity at node 6.

Export Compliance Screening - Line Process Activities

The following table provides descriptions of each activity in the Export Compliance Screening - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Export Compliance Screening - Line Subprocess Workflow

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Export Compliance Screening (node 2)	OE_EXPORT_COMPLIANCE_WF.ECS_REQUEST	OM Export Compliance Results	Yes
End (nodes 3, 6, 7)	WF_STANDARD.NOOP	None	Yes
Export Compliance Screening - Eligible (node 4)	OE_STANDARD_WF.STANDARD_BLOCK	None	No

Header Level Invoice Interface - Line, Deferred

Header Level Invoice Interface - Line, Deferred is a workflow process that interfaces with Oracle Receivables to generate an invoice for order lines. The Header Level Invoice Interface - Line, Deferred subprocess works with the seeded header flow to support header level invoicing. Header Level Invoice Interface - Line, Deferred is initiated as a subprocess of the following line level process:

• Line Flow - Generic with Header Level Invoice Interface

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is Line Flow - Generic with Header Level Invoice Interface, the Header Level Invoice Interface - Line, Deferred process is initiated as a subprocess of the line flow.

The Header Level Invoice Interface - Line, Deferred process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Header Level Invoice Interface - Line, Deferred Process

To view the properties of the Header Level Invoice Interface - Line, Deferred process, select the process in the navigator tree, then select Properties from the Edit menu. The Header Level Invoice Interface - Line, Deferred process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Header Level Invoice Interface - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Header Level Invoice Interface - Line, Deferred process shows that the process consists of 6 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Header Level Invoice Interface - Line, Deferred subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Header Level Invoice Interface - Line Deferred Subprocess Workflow

The Header Level Invoice Interface is initiated as a subprocess of the Line Flow - Generic with Header Level Invoice Interface line flow. The workflow begins at node 1 with the Start activity.

At node 2, the Fulfill - Deferred activity defers the line flow to the background engine. Once the background engine restarts the process, the process proceeds to the Fulfill activity at node 3. At node 4, the Fulfill - Continue Header Flow continues the process to the Wait for Invoice Interface block activity in node 5. After completion of node 5, the process continues to the End activity at node 5.

Header Level Invoice Interface - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Header Level Invoice Interface subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Header Level Invoice Interface Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Fulfill - Deferred (node 2)	WF_STANDARD.DEFER	None	Yes
Fulfill (node 3)	OE_FULFILL_WF.START_FULFILLMENT	None	Yes
Fulfill - Continue Header Flow (node 4)	WF_STANDARD.CONTINUEFLOW	None	Yes
Wait for Invoice Interface (node 5)	WF_STANDARD.WAITFORFLOW	None	Yes
End (node 6)	WF_STANDARD.NOOP	None	Yes

Header Level Invoice Interface for Return Line w/o Receipt

Header Level Invoice Interface for Return Line w/o Receipt is a workflow process that interfaces with Oracle Receivables to generate an invoice for order lines at order header level. The Header Level Invoice Interface for Return Line w/o Receipt subprocess works with the seeded header flow to support header level invoicing. Header Level Invoice Interface for Return Line w/o Receipt is initiated as a subprocess of the following line level processes:

• Line Flow - Return for Credit Only with Header Invoicing

• Line Flow - Return for Credit Only with Approval and Hdr Inv

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is Line Flow - Return for Credit Only with Approval and Hdr Inv or Line Flow - Return for Credit Only with Header Invoicing, the Header Level Invoice Interface for Return Line w/o Receipt process is initiated as a subprocess of the line flow.

The Header Level Invoice Interface for Return Line w/o Receipt process is contained in the Seeded Data File oexwford.wft, and is associated with the OM Order Line item type.

Summary of the Header Level Invoice Interface for Return Line w/o Receipt Process

To view the properties of the Header Level Invoice Interface for Return Line w/o Receipt process, select the process in the navigator tree, then select Properties from the Edit menu. The Header Level Invoice Interface for Return Line w/o Receipt process is a sub-process. This process is not runnable, which indicates that it cannot be assigned to a transaction type definition form; it is a sub-process to a line flow.

The Details property page of the process activity indicates that the Header Level Invoice Interface for Return Line w/o Receipt process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Header Level Invoice Interface for Return Line w/o Receipt process shows that the sub-process consists of 2 unique activities, comprising the 2 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Header Level Invoice Interface for Return Line w/o Receipt sub-process:

Header Level Invoice Interface for Return Line w/o Receipt Sub-process Workflow

At node 1, the Fulfill – Continue Header Flow activity continues the header processing.

Header Level Invoice Interface for Return Line w/o Receipt Process Activities

The following table provides descriptions of each activity in the Header Level Invoice Interface for Return Line w/o Receipt sub-process.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Header Level Invoice Interface for Return Line w/o Receipt Sub-process Activities

Activity	Function	Result Type	Required
Fulfill – Continue Header Flow	WF_STANDARD.CONTINUEFLOW	None	Yes
Wait for Invoice Interface	WF_STANDARD.WAITFORFLOW	None	Yes

Header Level Invoice Interface for Return Line with Receipt

Header Level Invoice Interface for Return Line with Receipt is a workflow process that fulfills and interfaces with Oracle Receivables to generate an invoice for order lines at order header level. The line is fulfilled only when the ‘Wait for receiving’ workflow activity (under ‘Return Receiving – Line’ sub-process) is completed. The Header Level Invoice Interface for Return Line with Receipt sub-process works with the seeded header flow to support header level invoicing. Header Level Invoice Interface for Return Line with Receipt is initiated as a sub-process of the following line level processes:

• Line Flow - Return for Credit with Receipt and Hdr Invoicing

• Line Flow - Return for Credit, Receipt, Approval, Header Inv

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is Line Flow - Return for Credit with Receipt and Hdr Invoicing or Line Flow - Return for Credit, Receipt, Approval, Header Inv, the Header Level Invoice Interface for Return Line with Receipt process is initiated as a subprocess of the line flow.

The Header Level Invoice Interface for Return Line with Receipt process is contained in the Seeded Data File oexwford.wft, and is associated with the OM Order Line item type.

Summary of the Header Level Invoice Interface for Return Line with Receipt Process

To view the properties of the Header Level Invoice Interface for Return Line with Receipt process, select the process in the navigator tree, then select Properties from the Edit menu. The Header Level Invoice Interface for Return Line with Receipt process is a sub-process. This process is not runnable, which indicates that it cannot be assigned to a transaction type definition form; it is a sub-process to a line flow.

The Details property page of the process activity indicates that the Header Level Invoice Interface for Return Line with Receipt process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Header Level Invoice Interface for Return Line with Receipt process shows that the process consists of 4 unique activities, comprising the 4 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Header Level Invoice Interface for Return Line with Receipt sub-process.

Header Level Invoice Interface for Return Line with Receipt Sub-process Workflow

At node 1, the Fulfill – Deferred activity continues the header processing.

Header Level Invoice Interface for Return Line with Receipt Process Activities

The following table provides descriptions of each activity in the Header Level Invoice Interface for Return Line with Receipt sub-process.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Header Level Invoice Interface for Return Line with Receipt Subprocess Activities

Activity	Function	Result Type	Required
Fulfill – Deferred	WF_STANDARD.DEFER	None	Yes
Fulfill	OE_FULFILL_WF.START_FULFILLMENT	None	Yes
Fulfill – Continue Header Flow	WF_STANDARD.CONTINUEFLOW	None	Yes
Wait for Invoice Interface	WF_STANDARD.WAITFORFLOW	None	Yes

Inventory Interface Non-Ship - Line

Inventory Interface Non-Ship - Line is a workflow process that interfaces with Oracle Inventory to relieve reservations and demand for non-shippable order lines. It is initiated as a subprocess of the following line flow:

• Line Flow - Generic, Bill Only with Inventory Interface

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Inventory Interface Non-Ship - Line process is initiated as a subprocess of the line flow.

The Inventory Interface Non-Ship - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Inventory Interface Non-Ship - Line Process

To view the properties of the Inventory Interface Non-Ship - Line process, select the process in the navigator tree, then select Properties from the Edit menu. The Inventory Interface Non-Ship - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Inventory Interface Non-Ship - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Inventory Interface Non-Ship - Line process shows that the process consists of 4 unique activities, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Inventory Interface Non-Ship - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Inventory Interface Non-Ship - Line Subprocess Workflow

The Inventory Interface Non-Ship - Line process is initiated as a subprocess of the Line Flow - Generic, Bill Only with Inventory Interface line flow. The workflow begins at node 1 with the Start activity.

At node 2, the Inventory Interface activity can complete with three possible results:

• On Hold

• Incomplete

• Complete

• Not Eligible

A Complete or Not Eligible result moves the process directly to an End activity. An On Hold or Incomplete result leads the process to the Inventory Interface - Eligible block activity at node 4. This activity holds the process until the line is manually progressed. The process then returns to the Inventory Interface activity at node 2.

Inventory Interface Non-Ship - Line Process Activities

The following table provides descriptions of each activity in the Inventory Interface Non-Ship - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Inventory Interface Non-Ship - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Invoice Interface (node 2)	OE_INV_IFACE_WF.INVENTORY_INTERFACE	OM Subprocess Results, Handles Holds	Yes
Inventory Interface - Eligible (node 4)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
End (nodes 3, 5)	WF_STANDARD.NOOP	None	Yes

Inventory Interface Non-Ship - Line, Deferred

Inventory Interface Non-Ship - Line, Deferred is a workflow process that interfaces with Oracle Inventory to relieve reservations and demand for non-shippable order lines. Inventory Interface Non-Ship - Line, Deferred is a workflow process that is initiated as a subprocess of the following line flow:

• Line Flow - Generic, Bill Only with Inventory Interface

  Note: The Inventory Interface Non-Ship - Line, Deferred process is identical to the Inventory Interface Non-Ship - Line process except that it contains an extra activity for deferment.

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Inventory Interface Non-Ship - Line, Deferred process is initiated as a subprocess of the line flow.

The C process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Inventory Interface Non-Ship - Line, Deferred Process

To view the properties of the Inventory Interface Non-Ship - Line, Deferred process, select the process in the navigator tree, then select Properties from the Edit menu. The Inventory Interface Non-Ship - Line, Deferred process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Inventory Interface Non-Ship - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Inventory Interface Non-Ship - Line, Deferred process shows that the process consists of 5 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Inventory Interface Non-Ship - Line, Deferred subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Inventory Interface Non-Ship - Line Deferred Subprocess Workflow

The Inventory Interface Non-Ship - Line, Deferred process is initiated as a subprocess of the Line Flow - Generic, Bill Only with Inventory Interface line flow. The workflow begins at node 1 with the Start activity.

At node 2, the Inventory Interface - Deferred activity defers inventory interface. After this activity completes, the process continues to the Inventory Interface activity at node 3. From this activity the process is identical to the Inventory Interface Non-Ship - Line subprocess.

At node 3, the Inventory Interface activity initiates a PL/SQL that has three possible results:

• On Hold

• Incomplete

• Complete

• Not Eligible

A Complete or Not Eligible result moves the process directly to the End activity at node 4 or node 6, respectively.

An On Hold or Incomplete result leads the process to the Inventory Interface - Eligible block activity at node 5. This activity holds the process until the line is manually progressed. The process then returns to the Inventory Interface activity at node 3.

Inventory Interface Non-Ship - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Inventory Interface Non-Ship - Line, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Inventory Interface Non-Ship - Line Deferred Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Inventory Interface - Deferred (node 2)	WF_STANDARD.DEFER	None	Yes
Inventory Interface (node 3)	OE_INV_IFACE_WF.INVENTORY_INTERFACE	OM Subprocess Results, Handles Holds	Yes
Inventory Interface - Eligible (node 5)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
End (nodes 4, 6)	WF_STANDARD.NOOP	None	Yes

Invoice Interface - Line

Invoice Interface - Line is a workflow subprocess used to interface with Oracle Receivables to obtain an invoice for an order line. Invoice Interface - Line is initiated as a subprocess of the following line flows:

• Line Flow - ATO Item

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, with Repricing at Fulfillment

• Line Flow - Standard Service

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Invoice Interface - Line process is initiated as a subprocess of the line flow.

The Invoice Interface - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Invoice Interface - Line Process

To view the properties of the Invoice Interface - Line process, select the process in the navigator tree, then select Properties from the Edit menu. The Invoice Interface - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Invoice Interface - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Invoice Interface - Line process shows that the process consists of 6 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Invoice Interface - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Interface - Line Subprocess Workflow

The Invoice Interface - Line process begins at node 1 with the Start activity. In the Invoice Interface activity at node 2 the process interfaces with Oracle Receivables to generate invoicing information for the order line. When this activity ends with a Complete result, the process moves to the End (Complete) activity at node 6 and returns to its parent flow. If the Invoice Interface activity returns a Not Eligible result, the process moves to the End (Not Eligible) activity at node 3 and returns to its parent flow.

If the Invoice Interface activity returns a result of On Hold or Incomplete, the process moves to the Invoice Interface - Eligible activity node 4, where is waits until the process is manually progressed.

If the Invoice Interface activity returns a result of Partial, the process moves to the Wait for Required for Revenue or Delivery where it waits the necessary revenue or delivery information. Once this information is received, the process proceeds to the End (Complete) activity at node 6 and returns to its parent flow.

Invoice Interface - Line Process Activities

The following table provides descriptions of each activity in the Invoice Interface - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Invoice Interface - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Invoice Interface (node 2)	OE_INVOICE_WF.INVOICE_INTERFACE	OM Subprocess Results, Handles Holds	Yes
End (Not Eligible) (node 6)	WF_STANDARD.NOOP	None	Yes
Wait for Required for Revenue or Delivery (node 5)	WF_STANDARD.BLOCK	None	Yes
Invoice Interface - Eligible (node 4)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
End (Complete) (node 6)	WF_STANDARD.NOOP	None	Yes

Invoice Interface - Line, Deferred

Invoice Interface - Line, Deferred is a workflow subprocess used to interface with Oracle Receivables to obtain an invoice for an order line. Invoice Interface - Line is initiated as a subprocess of the following line flows:

• Line Flow - ATO Model

• Line Flow - Generic, Bill Only

• Line Flow - Generic, Bill Only with Inventory Interface

• Line Flow - Return for Credit Only

• Line Flow - Return for Credit Only with Approval

• Line Flow - Return for Credit with Receipt

• Line Flow - Return for Credit with Receipt and Approval

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Invoice Interface - Line, Deferred process is initiated as a subprocess of that line flow.

Note: The Invoice Interface - Line, Deferred process is identical to the Invoice Interface - Line process except that it contains an extra activity for deferment.

The Invoice Interface - Line, Deferred process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Invoice Interface - Line, Deferred Process

To view the properties of the Invoice Interface - Line, Deferred process, select the process in the navigator tree, then select Properties from the Edit menu. The Invoice Interface - Line, Deferred process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Invoice Interface - Line, Deferred process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Invoice Interface - Line, Deferred process shows that the process consists of 7 unique activities, comprising the 7 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Invoice Interface - Line, Deferred subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Interface - Line Deferred Subprocess Workflow

The Invoice Interface - Line process begins at node 1 with the Start activity. In the Invoice Interface - Deferred activity at node 2 defers the process to the background engine. Once the background engine is run, the process resumes. In the Invoice Interface activity at node 3 the process interfaces with Oracle Receivables to generate invoicing information for the order line. When this activity ends with a Complete result, the process moves to the End (Complete) activity at node 6 and returns to its parent flow. If the Invoice Interface activity returns a Not Eligible result, the process moves to the End (Not Eligible) activity at node 4 and returns to its parent flow.

If the Invoice Interface activity returns a result of On Hold or Incomplete, the process moves to the Invoice Interface - Eligible activity node 7, where is waits until the process is manually progressed.

If the Invoice Interface activity returns a result of Partial, the process moves to the Wait for Required for Revenue or Delivery where it waits until the revenue or delivery information is received. Once this information is received, the process proceeds to the End (Complete) activity at node 6 and returns to its parent flow.

Invoice Interface - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Invoice Interface - Line, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Invoice Interface - Line Deferred Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Invoice Interface - Deferred (node 2)	WF_STANDARD.DEFER	None	Yes
Invoice Interface (node 3)	OE_INVOICE_WF.INVOICE_INTERFACE	OM Subprocess Results, Handles Holds	Yes
End (Not Eligible) (node 4)	WF_STANDARD.NOOP	None	Yes
Wait for Required for Revenue or Delivery (node 5)	WF_STANDARD.BLOCK	None	Yes
End (Complete) (node 6)	WF_STANDARD.NOOP	None	Yes
Invoice Interface - Eligible (node 7)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes

Purchase Release - Line, Deferred

The Purchase Release - Line, Deferred subprocess interfaces to Oracle Purchasing for externally sourced lines. It is initiated as a subprocess of the following subprocess:

• Create Supply - Line

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the assigned line flow for the line contains Create Supply - Line subprocess, the Purchase Release - Line, Deferred process is initiated as a subprocess of that subprocess.

The Purchase Release - Line, Deferred process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Purchase Release - Line, Deferred Process

To view the properties of the Purchase Release - Line, Deferred process, select the process in the navigator tree, then select Properties from the Edit menu. The Purchase Release - Line, Deferred process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Purchase Release - Line, Deferred process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Purchase Release - Line, Deferred process shows that the process consists of 5 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Purchase Release - Line, Deferred subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Purchase Release - Line Deferred Subprocess Workflow

The Purchase Release - Line, Deferred subprocess begins at node 1 with the Start activity.

The Purchase Release - Deferred activity at node 2 moves processing to the background engine. In the Purchase Release activity at node 3, the process releases a record to the Oracle Purchasing requisition import tables. If the Purchase Release activity returns an On Hold or Incomplete result, the process moves into the Purchase Release - Eligible activity at node 5. This activity enables you to manually progress the order.

If the Purchase Release activity returns a Complete or Not Eligible result, the process proceeds to an End activity and returns to its parent process.

Purchase Release - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Purchase Release - Line, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Purchase Release - Line Deferred Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Purchase Release - Deferred (node 2)	WF_STANDARD.DEFER	None	Yes
Purchase Release (node 3)	OE_OEOL_SCH.RELEASE_TO_PURCHASING	OM Subprocess Results, Handles Holds	Yes
Purchase Release - Eligible (node 5)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
End (nodes 4, 6)	WF_STANDARD.NOOP	None	Yes

Purchase Release - Line, Deferred - ATO

The Purchase Release - Line, Deferred - ATO subprocess interfaces to Oracle Purchasing for externally sourced lines. It is initiated as a subprocess of the following subprocess:

• Create ATO Supply

  Note: The Purchase Release - Line, Deferred ATO subprocess is identical to the Purchase Release - Line, Deferred process but is used specifically for ATO order lines.

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the assigned line flow for the line contains Create ATO Supply subprocess, the Purchase Release - Line, Deferred - ATO process is initiated as a subprocess of that subprocess.

The Purchase Release - Line, Deferred ATO process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Purchase Release - Line, Deferred ATO Process

To view the properties of the Purchase Release - Line, Deferred - ATO process, select the process in the navigator tree, then select Properties from the Edit menu. The Purchase Release - Line, Deferred - ATO process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Purchase Release - Line, Deferred - ATO process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window for the Purchase Release - Line, Deferred - ATO process shows that the process consists of 5 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Purchase Release - Line, Deferred - ATO subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Purchase Release - Line Deferred - ATO Subprocess Workflow

The Purchase Release - Line, Deferred - ATO subprocess begins at node 1 with the Start activity.

The Purchase Release - Deferred activity at node 2 moves processing to the background engine. In the Purchase Release activity at node 3, the process releases a record to the Oracle Purchasing requisition import tables. If the Purchase Release activity returns an On Hold or Incomplete result, the process moves into the Purchase Release - Eligible activity at node 5. This activity enables you to manually progress the order.

If the Purchase Release activity returns a Complete or Not Eligible result, the process proceeds to an End activity and returns to its parent process.

Purchase Release - Line, Deferred - ATO Process Activities

The following table provides descriptions of each activity in the Purchase Release - Line, Deferred - ATO subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Purchase Release - Line Deferred - ATO Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Purchase Release - Deferred (node 2)	WF_STANDARD.DEFER	None	Yes
Purchase Release (node 3)	OE_OEOL_SCH.RELEASE_TO_PURCHASING	OM Subprocess Results, Handles Holds	Yes
Purchase Release - Eligible (node 5)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
End (nodes 4, 6)	WF_STANDARD.NOOP	None	Yes

Purchase Release - Line, Manual

The Purchase Release - Line, Manual subprocess interfaces to Oracle Purchasing for externally sourced lines. Purchase Release - Line, Manual enables you to manually progress the process instead of waiting for the background engine to pick it up.

Note: The Purchase Release - Line, Manual subprocess is identical to the Purchase Release - Line, Deferred process except that it does not contain a deferment activity.

The Purchase Release - Line, Manual process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Purchase Release - Line, Manual Process

To view the properties of the Purchase Release - Line, Manual process, select the process in the navigator tree, then select Properties from the Edit menu. The Purchase Release - Line, Manual process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Purchase Release - Line, Manual process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Purchase Release - Line, Manual process shows that the process consists of 4 unique activities, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Purchase Release - Line, Manual subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Purchase release - Line Manual Subprocess Workflow

The Purchase Release - Line, Manual subprocess begins at node 1 with the Start activity.

In the Purchase Release - Eligible activity at node 2, the activity must be manually progressed to the Purchase Release activity at node 3. If the Purchase Release activity returns an On Hold or Incomplete result, the process returns to the Purchase Release - Eligible activity at node 2.

If the Purchase Release activity returns a Complete or Not Eligible result, the process proceeds to an End activity and returns to its parent process.

Purchase Release - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Purchase Release - Line, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Purchase Release - Line Deferred Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Purchase Release - Eligible (node 2)	OE_STANDARD_WF.STANDARD_BLOCK	None	No
Purchase Release (node 3)	OE_OEOL_SCH.RELEASE_TO_PURCHASING	OM Subprocess Results, Handles Holds	Yes
End (nodes 4, 5)	WF_STANDARD.NOOP	None	Yes

Reprice - Line

The Reprice - Line subprocess enables you to reprice an order line. This is useful for invoicing purposes. Reprice - Line is initiated as a subprocess of the following line flow:

• Line Flow - Generic, with Repricing at Fulfillment

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the assigned line flow is Line Flow - Generic, with Repricing at Fulfillment, the Reprice - Line process is initiated as a subprocess of the line flow.

Reprice - Line is contained in the Seeded Data File oexwford.wft and process is associated with the OM Order Line item type.

Summary of the Reprice - Line Process

To view the properties of the Reprice - Line process, select the process in the navigator tree, then select Properties from the Edit menu. The Reprice - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Reprice - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Reprice - Line process shows that the process consists of 4 unique activities, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Reprice - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Reprice - Line Subprocess Workflow

The Reprice - Line subprocess begins at node 1 with the Start activity.

In the Reprice activity at node 2, the reprices the line. If the Reprice activity returns an Incomplete result then the process moves to the Reprice - Eligible activity at node 4. The process must be manually progressed to return to the Reprice activity. If the Purchase Release activity returns an Not Eligible or Complete result, the process proceeds to an End activity and returns to its parent process.

Reprice - Line Process Activities

The following table provides descriptions of each activity in the Reprice - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Reprice - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Reprice (node 2)	OE_REPRICE_WF.START_REPRICING	OM Subprocess Results	No
Reprice - Eligible (node 3)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes
End (nodes 4, 5)	WF_STANDARD.NOOP	None	Yes

Return Receiving - Line

The Return Receiving - Line subprocess is used in returns. The Return Receiving - Line subprocess executes a series of activities that determine the status of a returned item.

Return Receiving - Line is initiated as a subprocess of the following line flows:

• Line Flow - Return for Credit with Receipt

• Line Flow - Return for Credit with Receipt and Approval

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the assigned line flow is Line Flow - Return for Credit with Receipt or Line Flow - Return for Credit with Receipt and Approval, the Return Receiving - Line process is initiated as a subprocess of the line flow.

Return Receiving - Line is contained in the Seeded Data File oexwford.wft and process is associated with the OM Order Line item type.

Summary of the Return Receiving - Line Process

To view the properties of the Return Receiving - Line process, select the process in the navigator tree, then select Properties from the Edit menu. The Return Receiving - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Return Receiving - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Return Receiving - Line process shows that the process consists of 4 unique activities, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Return Receiving - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Return Receiving - Line Subprocess Workflow

The Return Receiving - Line subprocess begins at node 1 with the Start activity.

In the Utility to Get Line Category activity at node 2 determines whether the line is an order or a return. If the line is a return, it is not eligible for return receiving and the process closes. In the Wait for Receiving activity at node 3 the process waits until the return item is received before progressing. If the return item is not eligible for receiving, the process ends.

If the return item is eligible for receiving, the process then moves to the Wait for Inspection activity at node 4. After the inspection is complete the process moves to the End (Complete) activity at node 5 and returns to its parent process.

Return Receiving - Line Process Activities

The following table provides descriptions of each activity in the Return Receiving - Line subprocess.

For more information about individual activities, refer toSeeded Function Activity Definitions.

Return Receiving - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Utility to Get Line Category (node 2)	OE_STANDARD_WF.GET_LINE_CATEGORY	Line Category	No
Wait for Receiving (node 3)	OE_RMA_WF.WAIT_FOR_RECEIVING	OM Subprocess Success Results	Yes
Wait for Inspection (node 4)	WF_STANDARD.BLOCK	None	Yes
End (Complete) (node 5)	WF_STANDARD.NOOP	None	Yes
End (Not Eligible) (nodes 6, 7)	WF_STANDARD.NOOP	None	Yes

Schedule - Line

The Schedule - Line subprocess schedules an order line for all order lines that must be shipped. This process is a subprocess of the following line flows:

• Line Flow - ATO Item

• Line Flow - ATO Model

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Ship Only

• Line Flow - Generic, with Repricing at Fulfillment

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Schedule - Line process is initiated as a subprocess of the line flow.

The Schedule - Line process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Schedule - Line Process

To view the properties of the Schedule - Line process, select the process in the navigator tree, then select Properties from the Edit menu. The Schedule - Line process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Schedule - Line process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Schedule - Line process shows that the process consists of 4 unique activities, comprising the 5 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Schedule - Line subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Schedule - Line Subprocess Workflow

The Schedule - Line subprocess begins at node 1 with the Start activity.

The Schedule activity at node 2 attempts to schedule the order line. If the Schedule activity returns a result of Incomplete or On Hold, the process moves to the Schedule - Eligible activity at node 4. From there the process must be manually progressed to return to the Schedule activity.

If the Schedule activity returns a Not Eligible or Complete result, the process proceeds to an End activity and returns to its parent process.

Schedule - Line Process Activities

The following table provides descriptions of each activity in the Schedule - Line subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Schedule - Line Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Schedule (node 2)	OE_OEOL_SCH.SCHEDULE_LINE	OM Subprocess Results, Handles Holds	No
Schedule - Eligible (node 3)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes
End (nodes 4, 5)	WF_STANDARD.NOOP	None	Yes

Schedule Line - Manual subprocess

Schedule-Line, Manual enables you to control scheduling manually after the order is booked. After booking the order, if this subprocess has been used, it initiates and prevents the lines from progressing at the Schedule-Eligible activity. You can manually progress the Schedule - Eligible activity from the Sales Orders window or use the Schedule Orders concurrent program to schedule the lines. You can customize your workflow to include the Schedule Line Manual subprocess.

Schedule - Line, Deferred

The Schedule - Line subprocess schedules an order line for all order lines that must be shipped.

Note: The Schedule - Line, Deferred subprocess is identical to the Schedule - Line process except that it contains two new activities: an activity to determine whether the line is scheduled, and a defer activity.

The Schedule - Line, Deferred process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Schedule - Line, Deferred

To view the properties of the Schedule - Line, Deferred process, select the process in the navigator tree, then select Properties from the Edit menu. The Schedule - Line, Deferred process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Invoice Interface - Line, Deferred process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Schedule - Line, Deferred process shows that the process consists of 6 unique activities, comprising the 9 activity nodes that appear in the workflow diagram. The following image depicts the workflow diagram for the Schedule - Line, Deferred subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Schedule - Line Deferred Subprocess Workflow

The Schedule - Line, Deferred subprocess begins at node 1 with the Start activity. The Is Line Scheduled activity at node 2 determines whether the line has already been scheduled. If scheduling is complete or the line is not eligible for scheduling, the process ends and returns to its parent flow. If scheduling has not yet been completed, the process moves to the Schedule - Deferred activity at node 5. This activity moves scheduling to the background engine.

The Schedule activity at node 6 attempts to schedule the order line. If the Schedule activity returns a result of Incomplete or On Hold, the process moves to the Schedule - Eligible activity at node 8. From there the process must be manually progressed to return to the Schedule activity.

If the Schedule activity returns a Not Eligible or Complete result, the process proceeds to an End activity and returns to its parent process.

Schedule - Line, Deferred Process Activities

The following table provides descriptions of each activity in the Schedule - Line, Deferred subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Schedule - Line Deferred Subprocess Activities

Activity	Function	Result Type	Required
Start (node 1)	WF_STANDARD.NOOP	None	Yes
Is Line Scheduled (node 2)	OE_OEOL_SCH.IS_LINE_SCHEDULED	OM Subprocess Results	No
Schedule - Deferred (node 5)	WF_STANDARD.DEFER	None	Yes
Schedule (node 6)	OE_OEOL_SCH.SCHEDULE_LINE	OM Subprocess Results, Handles Holds	No
Schedule - Eligible (node 8)	OE_STANDARD_WF.STANDARD_BLOCK	None	Yes
End (nodes 3, 4, 7, 9)	WF_STANDARD.NOOP	None	Yes

Ship - Line, Manual

Ship - Line, Manual enables you to manually initiate shipping for an order line. Ship - Line, Manual is initiated as a subprocess of the following line flows:

• Line Flow - ATO Item

• Line Flow - Configuration

• Line Flow - Configuration with Authorize to Ship (RLM)

• Line Flow - Generic

• Line Flow - Generic with Authorize to Ship (RLM)

• Line Flow - Generic with Header Level Invoice Interface

• Line Flow - Generic, With Export Compliance

• Line Flow - Generic, Ship Only

Each time an order line is saved in Oracle Order Management, the line is evaluated to determine which workflow is assigned to the line. If the appropriate line flow for the line is one of the previously mentioned flows, the Ship - Line, Manual process is initiated as a subprocess of that line flow.

The Ship - Line, Manual process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Ship - Line, Manual Process

To view the properties of the Ship - Line, Manual process, select the process in the navigator tree, then select Properties from the Edit menu. The Ship - Line, Manual process is a subprocess. This process is not runnable, which indicates that it cannot be assigned to a transaction type; it is a subprocess or a line flow.

The Details property page of the process activity indicates that the Ship - Line, Manual process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window for the Ship - Line, Manual process shows that the process consists of 6 unique activities, comprising the 6 activity nodes that appear in the workflow diagram.

The following image depicts the workflow diagram for the Ship - Line, Manual subprocess. Each node of this subprocess is numbered for referencing. The numbers themselves are not part of the process diagram.

Ship - Line Manual Process Workflow

The Ship - Line, Manual subprocess begins at node 1 with the Ship activity, which returns one of the following four results:

• Over Shipped Beyond Tolerance

• Ship Confirm

• Non Shippable

• Unreserved

If the Ship activity returns the Over Shipped Beyond Tolerance result, a notification is sent and the process moves to an End activity and returns to its parent line flow. If the Ship activity returns a Ship Confirm, Non Shippable, or Unreserved result, the process moves to an End activity and returns to its parent line flow.

Ship - Line, Manual Process Activities

The following table provides descriptions of each activity in the Ship - Line, Manual subprocess.

For more information about individual activities, refer to Seeded Function Activity Definitions.

Ship - Line Manual Subprocess Activities

Activity	Function	Result Type	Required
Ship (node 1)	OE_SHIPPING_WF.START_SHIPPING	Shipping Results	Yes
End (Ship Confirm) (node 2)	WF_STANDARD.DEFER	None	Yes
End (Over Shipped Beyond Tolerance) (node 4)	WF_STANDARD.NOOP	OM Subprocess Results, Handles Holds	Yes
End (Non Shippable)(node 5)	WF_STANDARD.NOOP	None	Yes
End (Unreserve) (nodes 6)	WF_STANDARD.NOOP	None	Yes

Wait to Firm - Line

The Wait to Firm - Line workflow subprocess is used to hold order lines until they are firmed by the Firm Demand Process concurrent program.

The Wait to Firm - Line subprocess is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type

Summary of the Wait to Firm - Line Process

To view the properties of the Wait to Firm - Line process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type. The Details property page of the process activity indicates that the Wait to Firm - Line process has an error item type of OMERROR. This item type is associated with the R_ERROR_RETRY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

When you display the Process window for the Wait to Firm - Line, you see that the process consists of 3 unique activities and 3 subprocesses, which comprise the 6 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Standard Service process. Each node of this process is numbered for referencing.

Wait to Firm - Line Workflow

Wait to Firm - Line Activities

The following table provides descriptions of each activity in the Wait to Firm - Line Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Wait to Firm - Line Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
End	WF_STANDARD.NOOP	None	Yes

Wait to Fulfill Line

The subprocess Wait to Fulfill Line enables you to prevent changes to non-shippable lines after booking or prevent shippable lines from being fulfilled even if they have been ship confirmed.

The Wait to Fulfill Line subprocess is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.

Summary of the Wait to Fulfill Line Subprocess

You can add the subprocess Wait to Fulfill Line before the existing defer fulfillment functions or fulfill line functions.

You can use the subprocess Wait to Fulfill Line in flows like Line Flow - Generic, with Wait to Fulfill Line:

In the subprocess, the order line reaches the check_wait_to_fulfill_line function after it is scheduled and shipped (for shippable lines only). The check_wait_to_fulfill_line function returns a value of Yes or No:

Yes: for non-shippable order lines excluding all lines part of a configuration and service lines. In this case, the order lines will wait at the Fulfill_Line_Eligible block.

No: for all shippable lines and all lines part of a configuration and service lines referencing a shippable order line in the same order. These lines will go to defer fulfillment subprocess. The Fulfillment functionality can handle non-shippable lines in a configuration as well as service lines with reference to the same order. Hence these lines do not need additional wait.

You can customize this subprocess to reflect the specific business process that will determine the completion of this block.

Wait to Fulfill Line Activities

The following table provides descriptions of each activity in the Wait to Fulfill Line Process.

Wait to Fulfill Line Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
Check to Wait before Fulfill Line	CHECK_WAIT_TO_FULFILL_LINE	PL/SQL	Yes
Fulfill Line - Eligible	FULFILL_LINE_ELIGIBLE	PL/SQL	Yes
End	WF_STANDARD.NOOP	None	Yes

Negotiation Subprocesses

Submit Draft - Negotiation

The Submit - Draft Negotiation subprocess is included in the seeded Negotiation workflows. Submit Draft - Negotiation is initiated if it is part of the Negotiation workflow that is attached to the transaction type for the sales document.

Submit Draft - Negotiation is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.

Summary of the Submit Draft - Negotiation Process

To view the properties of the Submit Draft - Negotiation process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Submit Draft - Negotiation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities of the Submit Draft - Negotiation process, which comprise the nodes that appear in the workflow diagram.

The following diagram depicts the Submit Draft - Negotiation process.

Submit Draft - Negotiation Process Workflow

Submit Draft - Negotiation Activities

The following table provides descriptions of each activity in the Submit Draft - Negotiation Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Submit - Draft Process Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
Submit Draft - Eligible	OE_STANDARD_WF.STANDARD.BLOCK	Submit Draft, Lost	Yes
Submit Draft	OE_NEGOTIATE_WF.Submit_Draft_Internal	End	Yes
End	WF_STANDARD.NOOP	None	Yes

Complete - Negotiation

The Complete - Negotiation subprocess is included in the seeded Negotiation workflows. Complete - Negotiation is initiated if it is part of the Negotiation workflow that is attached to the transaction type for the sales document.

Complete - Negotiation is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.

Summary of the Complete - Negotiation Process

To view the properties of the Complete - Negotiation process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type. The Details property page of the process activity indicates that the Complete - Negotiation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities of the Complete - Negotiation process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Complete - Negotiation process.

Complete - Negotiation Workflow

Complete - Negotiation Activities

The following table provides descriptions of each activity in the Complete - Negotiation Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Complete - Negotiation Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
Negotiation Complete	OE_NEGOTIATE_WF.Negotiation_Complete	Incomplete, End	Yes
Negotiation Complete - Eligible	OE_STANDARD_WF.STANDARD_BLOCK	Negotiation Complete, Lost	Yes
End	WF_STANDARD.NOOP	None	Yes

Internal Approval - Negotiation

The Internal Approval - Negotiation subprocess is used for approvals in Oracle Order Management.

The Internal Approval - Negotiation subprocess is included in the seeded Negotiation workflows. Internal Approval - Negotiation is initiated if it is part of the Negotiation workflow that is attached to the transaction type for the sales document.

Internal Approval - Negotiation is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.

Summary of the Internal Approval Process

To view the properties of the Internal Approval - Negotiation subprocess, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Internal Approval - Negotiation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities and subprocesses of the Internal Approval - Negotiation process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Internal Approval - Negotiation process.

Internal Approval Workflow

Internal Approval - Negotiation Activities

The following table provides descriptions of each activity in the Internal Approval - Negotiation Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Internal Approval - Negotiation Activities

Activity	Function	Result Type	Required
Initiate Approval	OE_APPROVALS_WF.Initiate_Approvals	Complete, Not Eligible	Yes
Get Next Approver	OE_APPROVALS_WF.Get_Next_Approver	Yes, No	Yes
Approval Timeout	OE_APPROVALS_WF.Approval_Timeout	Continue, Reject	Yes
Internal Approved	OE_APPROVALS_WF.Approve_Approval	None	Yes
Internal Rejected	OE_APPROVALS_WF.Reject_Approval	None	Yes
End	WF_STANDARD.NOOP	None	Yes

Customer Acceptance - Negotiation Process

The Customer Acceptance - Negotiation workflow process is used for negotiation in Oracle Order Management.

The Customer Acceptance - Negotiation subprocess is included in the seeded Negotiation workflows. Customer Acceptance - Negotiation is initiated if it is part of the Negotiation workflow that is attached to the transaction type for the sales document.

Customer Acceptance - Negotiation is contained in the Seeded Data File oexford.wft and is associated with the OM Negotiation Header item type.

Summary of the Customer Acceptance - Negotiation Process

To view the properties of the Customer Acceptance - Negotiation process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Customer Acceptance - Negotiation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities and subprocesses of the Customer Acceptance - Negotiation process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Customer Acceptance - Negotiation process.

Customer Acceptance - Negotiation Workflow

Customer Acceptance - Negotiation Activities

The following table provides descriptions of each activity in the Customer Acceptance Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Customer Acceptance Activities

Activity	Function	Result Type	Required
Customer Acceptance	OE_NEGOTIATE_WF.Customer_Acceptance	Accept, Reject	Yes
Customer Accepted	OE_NEGOTIATE_WF.Update_Customer_Accepted	None	Yes
Customer Rejected	OE_NEGOTIATE_WF.Update_Customer_Rejected	None	Yes
End	WF_STANDARD.NOOP	None	Yes

Offer Expiration - Negotiation Process

The Offer Expiration - Negotiation workflow process is used for Quotes in Oracle Order Management. Sales Agreements do not include the Offer Expiration - Negotiation process.

The Offer Expiration - Negotiation subprocess is included in the seeded Negotiation workflows. Offer Expiration - Negotiation is initiated if it is part of the Negotiation workflow that is attached to the transaction type for the sales document.

Offer Expiration - Negotiation is contained in the Seeded Data File oexford.wft and is associated with the OM Negotiation Header item type.

Summary of the Offer Expiration - Negotiation Process

To view the properties of the Offer Expiration - Negotiation process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Offer Expiration - Negotiation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities and subprocesses of the Offer Expiration - Negotiation process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Offer Expiration - Negotiation process.

Offer Expiration - Negotiation Workflow

Offer Expiration - Negotiation Activities

The following table provides descriptions of each activity in the Offer Expiration - Negotiation Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Offer Expiration - Negotiation Activities

Activity	Function	Result Type	Required
Assign	WF_STANDARD.ASSIGN	None	Yes
Check Expiration Date	OE_NEGOTIATION_WF.Check_Expiration_Date	Complete, Expire Today, No Pre-expiration Reminder, Expired	Yes
Wait for Expiration	WF_STANDARD.BLOCK	Timeout, Date Changed	Yes
Set Final Expiration Date	OE_NEGOTIATE_WF.Set_Final_Expiration_Date	Expired	Yes
Wait for Final Expiration	WF_STANDARD.BLOCK	Timeout, Date Changed	Yes
Offer Expired	OE_NEGOTIATE_WF.Offer_Expired	Expired	Yes
End	WF_STANDARD.NOOP	None	Yes

Blanket Agreement/Sales Order Generation

The following sub-flow is a standalone subprocess that is not part of any seeded flow. However, you can put it in the runnable negotiation flow as needed and is available to copy and extend the seeded flow through addition of this sub-flow.

Blanket Agreement/Sales Order Generation is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.

Summary of the Blanket Agreement/Sales Order Generation Process

To view the properties of the Blanket Agreement/Sales Order Generation process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Blanket Agreement/Sales Order Generation process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities of the Blanket Agreement/Sales Order Generation process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Blanket Agreement/Sales Order Generation process.

Blanket Agreement/Sales Order Generation Workflow

Blanket Agreement/Sales Order Generation Activities

The following table provides descriptions of each activity in the Blanket Agreement/Sales Order Generation Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Blanket Agreement/Sales Order Generation Process Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
End	WF_STANDARD.NOOP	None	Yes

Sales Agreement Subprocesses

Notifications for Sales Agreement Processes

Enter Blanket - The Enter - Blanket subprocess is included in the seeded Blanket workflows. Enter - Blanket is initiated if it is part of the Blanket workflow that is attached to the transaction type for the sales document.

Notifications for Sales Agreement Processes

Display Name	Result Type	Message
Blanket Pre-Expiration Notification	FYI	Notify Sender of Blanket Pre Expire
Blanket Expiration Rejection	FYI	Notify Sender of Blanket Rejection
Notify Sender of Blanket Termination	FYI	Notify Sender of Blanket Termination

Enter—Blanket is contained in the Seeded Data File oexwford.wft and is associated with the OM Blanket Header item type.

Summary of the Enter—Blanket Process

To view the properties of the Enter—Blanket process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Enter—Blanket process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities of the Enter—Blanket process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Enter—Blanket process.

Enter—Blanket Workflow

Enter—Blanket Activities

The following table provides descriptions of each activity in the Enter—Blanket Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Enter-Blanket Process Activities

Activity	Function	Result Type	Required
Check Negotiation Exists	OE_BLANKET_WF.Check_Negotiation_ Exists	Yes, No	Yes
Submit Draft - Eligible	OE_STANDARD_WF.STANDARD_BLOCK	Submit Draft, Incomplete	Yes
Submit Draft	OE_BLANKET_WF.Submit_Draft	Incomplete, Default	Yes
End	WF_STANDARD.NOOP	None	Yes

Execute - Blanket

The Execute - Blanket workflow process is used for the Fulfillment flow of Blanket Sales Agreements in Oracle Order Management.

The Execute - Blanket subprocess is included in the seeded Blanket workflows. Execute - Blanket is initiated if it is part of the Blanket workflow that is attached to the transaction type for the sales document.

Execute - Blanket is contained in the Seeded Data File oexwford.wtf and is associated with the OM Blanket Header item type.

Summary of the Execute - Blanket Process

To view the properties of the Execute - Blanket process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Execute - Blanket process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities and subprocesses of the Execute - Blanket process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Execute - Blanket process.

Execute - Blanket Process

Execute - Blanket Activities

The following table provides descriptions of each activity in the Execute - Blanket Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Execute - Blanket Activities

Activity	Function	Result Type	Required
Assign	WF_STANDARD.ASSIGN	Calculate Effective Dates	Yes
Calculate Effective Dates	OE_BLANKET_WF.CALCULATE_EFFECTIVE_DATES	Start Date Reached, Expire Today, No Expiration Reminder, Expired, No End Date	Yes
Set Final Expiration Date	OE_BLANKET_WF.Set_Final_Expiration_Date	Blanket Expired, Blanket Active - Wait for Final Expiration	Yes
Blanket Active - Wait for Expiration	WF_STANDARD.BLOCK	Timeout, Date Changed, Terminate	Yes
Blanket Active - Wait for Final Expiration	WF_STANDARD.BLOCK	Timeout, Date Changed, Terminate	Yes
Blanket - Expired	OE_BLANKET_WF.Expired	End	Yes
Wait for Start Date	WF_STANDARD_BLOCK	Timeout, Terminate, Date Changed	Yes
Blanket Active - No End Date	WF_STANDARD_BLOCK	Terminate, Date Changed	Yes
End	WF_STANDARD.NOOP	None	Yes

Terminate—Blanket

The Terminate—Blanket process is used in the Fulfillment phase in Oracle Order Management.

The Terminate - Blanket subprocess is included in the seeded Blanket workflows. Terminate - Blanket is initiated if it is part of the Blanket workflow that is attached to the transaction type for the sales document.

Terminate—Blanket is contained in the Seeded Data File oexwford.wft and is associated with the OM Blanket Header item type.

Summary of the Terminate—Blanket Process

To view the properties of the Terminate—Blanket process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Terminate—Blanket process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process. The Process window displays the activities and subprocesses of the Terminate—Blanket process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Terminate—Blanket process.

Terminate - Blanket Process

Terminate—Blanket Activities

The following table provides descriptions of each activity in the Terminate—Blanket Flow Process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Terminate - Blanket Activities

Activity	Function	Result Type	Required
Terminate—Blanket	OE_BLANKET_WF.Update_Status_Terminate	None	Yes
End	WF_STANDARD.NOOP	None	Yes

Close—Blanket

The Close—Blanket process is used for the Blanket Sales Agreement Fulfillment flow in Oracle Order Management.

The Close - Blanket subprocess is included in the seeded Blanket workflows. Close - Blanket is initiated if it is part of the Blanket workflow that is attached to the transaction type for the sales document.

Close—Blanket is contained in the Seeded Data File oexwford.wtf and is associated with the OM Blanket Header item type.

Summary of the Close—Blanket Process

To view the properties of the Close—Blanket process, select the process in the navigator tree and then select Properties from the Edit menu. This process is runnable, which indicates that it can be assigned to a transaction type.

The Details property page of the process activity indicates that the Close—Blanket process has an error item type of WFERROR. This item type is associated with the RETRY_ONLY error process. The purpose of this error handling process is to alert an administrator when an error occurs in a process and prompt the administrator to retry the process in error. This error process is initiated only when an unexpected error with Oracle Workflow is encountered in the process.

The Process window displays the activities and subprocesses of the Close—Blanket process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Close—Blanket process.

Close - Blanket Process

Close—Blanket Activities

The following table provides descriptions of each activity in the Close—Blanket process.

For more information about individual function activities, see Seeded Function Activity Definitions.

Close - Blanket Activities

Activity	Function	Result Type	Required
Start	WF_STANDARD.NOOP	None	Yes
Close Blanket - Eligible	OE_STANDARD_WF.STANDARD_BLOCK	Complete, Extend	Yes
Close - Blanket	OE_BLANKET_WF.Close	Incomplete, End	Yes
End	WF_STANDARD.NOOP	None	Yes