CTO Change Order is an Oracle Configure to Order workflow process that initiates if you change one of the following sales order attributes after a configuration item has been created:
Scheduled ship date
Request date/scheduled arrival date
Order line quantity
Configuration
This process is also initiated if you cancel an order.
This process sends a notification about the change(s) to different people depending on which item has been modified: If configured and ATO items are changed, a notification is sent to the planner of the top model/item in the shipping organization. For Purchase to Order ATO items, a notification is sent to the buyer on the requisition. Only one message is sent for all changes accepted in an order line. If the planner information is unavailable, the notification is redirected to the system administrator. The notification process cannot be initiated using the Sales Orders or any windows, it is automatically generated by the system.
For single-level, single-organization configurations and ATO items a notification is sent only if a reservation or flow schedule exists for the configuration. If there are configuration changes, a notification is sent even if no reservation exists.
For multi level, or multi organization configurations and ATO items a notification of the changes is always sent, regardless of whether a reservation exists for the top level configuration or ATO Item.
Note: Note: Please note that notifications for drop shipments are not sent using this process.
The Change Order Process is contained in the seeded data file CTO Change Order and is associated with the CTO Change Order item type. For more information on the CTO Change Order process, please refer to the Oracle Configure to Order Process Guide.
The properties of the CTO Change Order process indicate that it is runnable, it can be called by other processes.
The following table provides descriptions of each function activity in Change Order Process.
For more information about individual function activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Change Order Notification | NOTIFYCHG | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
If you change any order details (other than CTO/ATO/PTO items) on the Sales Orders window, you can send a notification to other users with the details of the change. Actions > Notification in the Sales Orders window enables you to initiate the OM Change Order process. This process can also be initiated in an error message by selecting the Notify option.
Change Order Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The OM Change Order process properties indicate that it is runnable, it can be assigned to other processes.
Sending a notification using the Sales Orders window
The following process diagram displays OM Change Order. As in CTO Change Order, the Change Order Notification activity is a seeded function.
Change Order Workflow
The following table provides descriptions of each activity in Change Order Process. For more information about individual function activities, see Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Change Order Notification | NOTIFYCHG | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
If you cancel the internal sales order, you can send a notification to the preparer of the Internal Requisition with the details of the cancellation. This process is relevant only in the context of Internal Requisitions and Internal Sales Orders change management. The following notification is displayed when the internal sales order is cancelled:
Internal Sales Order &ORDER_NUMBER has been cancelled.
The following information is part of the ISO Cancel notification:
Sales Order No: &ORDER_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER
Cancellation Date: &ORDER_CANCEL_DATE
ISO Cancel Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The following process diagram displays ISO Cancel Process. The ISO Cancel Notification activity is a seeded function.
ISO Cancel Process
If you cancel the internal sales order lines, you can send a notification to the preparer of the Internal Requisition with the details of the cancellation. This process is relevant only in the context of Internal Requisitions and Internal Sales Orders change management. The following message is displayed when the internal sales order lines are cancelled:
Internal Sales Order &ORDER_NUMBER Line &LINE_NUMBER has been cancelled.
The following information is part of the ISO Line Cancel notification:
Sales Order No: &ORDER_NUMBER
Line No: &LINE_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER
Line No: &REQ_LINE_NUMBER
Item: &INVENTORY_ITEM
Requested Quantity: &REQUESTED_QTY
Cancelled Quantity: &CANCELLED_QTY
Cancellation Date: &LINE_CANCEL_DATE
ISO Line Cancel Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The following process diagram displays ISO Line Cancel Process. The ISO Line Cancel Notification activity is a seeded function.
ISO Line Cancel Process
If you update the ordered quantity or secondary quantity on the internal sales order line(s), you can send a notification to the preparer of the internal requisition with the details of the update. This process is relevant only in the context of Internal Requisitions and Internal Sales Orders change management. The following message is displayed when you update the ordered quantity or secondary quantity on the internal sales order line:
Internal Sales Order &ORDER_NUMBER Line &LINE_NUMBER quantity has been updated.
The following information is part of the ISO Qty Update notification:
Sales Order No: &ORDER_NUMBER
Line No: &LINE_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER
Line No: &REQ_LINE_NUMBER
Item: &INVENTORY_ITEM
Original Requested Quantity: &REQUESTED_QTY
New Requested Quantity: &UPDATED_QTY
Update Date: &LINE_UPDATE_DATE
Original Secondary Requested Quantity: &REQUESTED_QTY2
New Secondary Requested Quantity: &UPDATED_QTY2
ISO Qty update Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The following process diagram displays ISO Qty Update Process. The ISO Line Ordered Quantity Update Notification activity is a seeded function.
ISO Qty update Process
If you update the Schedule Arrival Date on the internal sales order lines, you can send a notification to the preparer of the Internal Requisition with the details of the update. This process is relevant only in the context of Internal Requisitions and Internal Sales Orders change management. The following message is displayed if you update the Schedule Arrival Date:
Internal Sales Order &ORDER_NUMBER Line &LINE_NUMBER Schedule Ship/Arrival Date has been updated.
The following information is part of the ISO Line Schedule Arrival Date update notification:
Sales Order No: &ORDER_NUMBER
Line No: &LINE_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER
Line No: &REQ_LINE_NUMBER
Item: &INVENTORY_ITEM
Requested Quantity: &REQUESTED_QTY
Need By Date: &REQ_LIN_NEED_BY_DATE
New Schedule Ship Date: &LINE_SCH_ARRIVAL_DATE
Update Date: &LINE_UPDATE_DATE
ISO Schedule Date update Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The following process diagram displays ISO Line Schedule Arrival Date update Process. The ISO Line Schedule Arrival Date update Notification activity is a seeded function.
ISO Schedule Date update Process
If you update the ordered quantity, secondary quantity, or schedule arrival date on the internal sales order lines, you can send a notification to the preparer of the internal requisition with the details of the update. This process is relevant only in the context of Internal Requisitions and Internal Sales Orders change management. The following message is displayed when you update the ordered quantity, secondary quantity, or schedule arrival date in the internal sales order:
Internal Sales Order &ORDER_NUMBER Line &LINE_NUMBER Quantity and Schedule Ship/Arrival Date have been updated.
The following information is part of the ISO Line Qty and Schedule Arrival Date update notification:
Sales Order No: &ORDER_NUMBER
Line No: &LINE_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER
Line No: &REQ_LINE_NUMBER
Item: &INVENTORY_ITEM
Original Requested Quantity: &REQUESTED_QTY
New Requested Quantity: &UPDATED_QTY
Need By Date: &REQ_LIN_NEED_BY_DATE
New Schedule Ship/Arrival Date: &LINE_SCH_ARRIVAL_DATE
Update Date: &LINE_UPDATE_DATE
Original Secondary Requested Quantity: &REQUESTED_QTY2
New Secondary Requested Quantity: &UPDATED_QTY2
ISO Quantity and Schedule Date update Process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order item type.
The following process diagram displays ISO Quantity and Schedule Date update Process. The ISO Line Qty and Schedule Arrival Date update Notification activity is a seeded function.
ISO Quantity and Schedule Date update Process
This process sends a notification to the internal requisition preparer or SYSADMIN, if the preparer cannot be determined or is inactive, when an item is substituted on an internal sales order line. The following notification is displayed when an item is substituted on the internal sales order:
ISO Line Ordered Item Update
The following information is part of the ISO Line Ordered Item Update notification:
Sales Order No: &ORDER_NUMBER &LINE_NUMBER
Internal Requisition No: &REQ_HDR_NUMBER &LINE_NUMBER
Requisition Item
Sales Order Item
ISO Line Ordered Item Update process is contained in the Seeded Data File oexwford.wft and is associated with the OM Change Order.
The ISO Line Ordered Item Update notification activity is a seeded function. The following process diagram displays ISO Line Ordered Item Update process.
The following section discusses the three workflows associated with the OM Order Header item type:
For more information regarding the OM Order Header item type, refer to, Introduction.
The Order Flow - Generic workflow process is the most often used workflow in Oracle Order Management. The Order Flow - Generic process contains subprocesses to verify that an order is booked and closed properly.
Order Flow - Generic is initiated if it is assigned to the transaction type for the order. Transaction types determine which processes are attached to an order. For more information on defining transaction types, refer to the Oracle Order Management Implementation Manual.
Order Flow - Generic is associated with the following OM Order Header subprocesses:
Order Flow - Generic is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.
To view the properties of the Order Flow - Generic 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 Order Flow - Generic 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 Order Flow - Generic, you see that the process consists of 2 unique activities and 2 subprocesses, which comprise the 4 nodes that appear in the workflow diagram. The following diagram depicts the Order Flow - Generic process. Each node of this process is numbered for referencing.
Order Flow - Generic Workflow
The Order Flow - Generic workflow begins at node 1 with the Enter activity. The workflow then proceeds to the Book - Order, Manual subprocess in node 2.
Once the order is booked, the process continues on to the Close - Order subprocess in node 3 and wait for all lines under this order to close. Once all lines are closed, the order will close. After the order is closed, the process ends.
The following table provides descriptions of each activity in the Order Flow - Generic process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter | WF_STANDARD.NOOP | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Order Flow - Generic with Booking Approval enables creation of order with AME approval before booking of the order.
The Order Flow - Generic with Booking Approval workflow process is initiated when you create the order in Oracle Order Management. When the order is progressed for booking, the status of the order is changed to Pending Internal Approval, indicating that the order has been sent for approval. At the same time, the status of the order line will remain as Entered, awaiting approval of order for progressing further. Both outbound lines and return lines behave the same with respect to status, as they are children of new seeded workflow.
If the order is rejected, the status of the header is changed to Review Required.
If the order is approved, the status of the header is changed to Approved, indicating that the order has been approved. After the approval, the order would be pushed ahead for booking updating the status to Booked. If the order is approved, but does not get booked because of any reason, the workflow will move to the Book-Eligible activity updating the status to Entered. When progressing the order again for booking, then the order is not sent again for approval.
Booking may happen asynchronously if the order is sent for booking approval. If no approvers are returned from AME, then the booking will happen synchronously, sending messages back to the user. If there are approvers from AME, then the booking will happen asynchronously after approval. In this case, no messages will be sent back to the user. Until the time, order is not approved, order will be in Pending Internal Approval status.
The Order Flow - Generic with Booking Approval workflow process is associated with the following OM Order Header subprocesses:
Book - Order, Manual with AME Approval
Close - Order
Order Flow - Generic with Booking Approval is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.
To view the properties of the Order Flow - Generic with Booking Approval 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 Order Flow - Generic with Booking Approval 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 Order Flow - Generic with Booking Approval, you see that the process consists of 2 unique activities and 2 subprocesses, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Order Flow - Generic with Booking Approval process.
The Order Flow - Generic with Booking Approval workflow begins with the Enter activity. The workflow then proceeds to the Book - Order, Manual with AME approval subprocess.
Once the order is booked, the workflow process resumes and moves to the Close - Order. Once all the lines in the Return have been closed the Return will be closed. After the order is successfully closed, the process ends.
Order Flow - Generic with Booking Approval with Approval Activities
The following table provides descriptions of each activity in the Order Flow - Generic with Booking Approval process. For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter | WF_STANDARD.NOOP | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Order Flow - Generic with Header Level Invoice Interface can only be used along with Line Flow - Generic with Header Level Invoice Interface.
The Order Flow - Generic with Header Level Invoice Interface is a workflow process that is initiated when you enter a sales order in Oracle Order Management. When you submit a sales order that requires an invoice, the Order Flow - Generic with Header Level Invoice Interface first ensures that the order is booked before generating the invoice. When all lines in the order are complete, the process interfaces with Oracle Receivables to generate an invoice for the order. Upon completion of the invoice interface, the process closes the order.
Note: This flow interfaces to Receivables for invoice creation when all lines in the order has been fulfilled.
The Order Flow - Generic with Header Level Invoice Interface workflow process can only end once the order is successfully closed.
Order Flow - Generic with Header Level Invoice Interface is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.
To view the properties of the Order Flow - Generic with Header Level Invoice Interface 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 Order Flow - Generic with Header Level Invoice Interface 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 Order Flow - Generic with Header Level Invoice Interface, you see that the process consists of 2 unique activities and 3 subprocesses, which comprise the 5 nodes that appear in the workflow diagram. The following diagram depicts the Order Flow - Generic with Header Level Invoice Interface process. Each node of this subprocess is numbered for referencing.
Order Flow - Generic with Header Level Invoice Workflow
The Order Flow - Generic workflow begins at node 1 with the Enter activity.
The workflow then proceeds to the Book - Order, Manual subprocess in node 2. Once the order is booked, the process continues on to the Header Level Invoice Interface - Order subprocess in node 3. This subprocess initiates the interface with Oracle Receivables to generate an invoice for the order. After an invoice is generated, the process moves to the Close - Order process in node 4. The process ends in node 5 after the order is successfully closed.
The following table provides descriptions of each activity in the Order Flow - Generic with Header Level Invoice Interface process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter | WF_STANDARD.NOOP | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Order Flow - Return with Approval should be used with either Line Flow - Return for Credit Only with Approval or Line Flow - Return for Credit with Receipt and Approval.
The Order Flow - Return with Approval workflow process is initiated when you submit a return on a sales order in Oracle Order Management. Returns must be booked and closed using the same processes as a sales order.
When you submit a return in Oracle Order Management, the process first books the return and then sends a notification to verify that the return is authorized. When the return is approved, the corresponding return lines can proceed. When all the return lines have been closed, this header flow will close and end. The approving manager can also decline authorization for the return.
The Order Flow - Return with Approval process ends after the return order is closed. The process can end with a result of rejected if:
The approving manager does not authorize the return.
The order is not eligible for return.
The Order Flow - Return with Approval workflow process is associated with the following OM Order Header subprocesses:
Order Flow - Return with Approval is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.
To view the properties of the Order Flow - Return with Approval 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 Order Flow - Return with approval 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 Order Flow - Return with Approval, you see that the process consists of 2 unique activities and 3 subprocesses, which comprise the 5 nodes that appear in the workflow diagram. The following diagram depicts the Order Flow - Return with Approval process. Each node of this subprocess is numbered for referencing.
Order Flow - Return with Approval Workflow
The Order Flow - Generic workflow begins at node 1 with the Enter activity. The workflow then proceeds to the Book - Order, Manual subprocess in node 2.
Once the order is booked, the process continues on to the Approve Return - Order subprocess in node 3. This subprocess sends notification to verify that the return is authorized. After the authorization status is determined, the workflow process resumes and moves to the Close - Order process in node 4. Once all the lines in the Return have been closed the Return will be closed. After the order is successfully closed, the process ends.
The following table provides descriptions of each activity in the Order Flow - Return with Approval process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter | WF_STANDARD.NOOP | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Order Flow – Mixed or Return with Approval enables creation of order with mixed lines and return lines with approval. Use this workflow with either Line Flow - Return for Credit Only with Approval or Line Flow - Return for Credit with Receipt and Approval.
The Order Flow – Mixed or Return with Approval workflow process is initiated when you submit a return on a sales order with mixed lines and lines with approval in Oracle Order Management. Returns must be booked and closed using the same processes as a sales order. When you submit a return in Oracle Order Management, the process first books the return and then sends a notification to verify that the return is authorized. When the return is approved, the corresponding return lines can proceed. When all the return lines have been closed, this header flow will close and end. The approving manager can also decline authorization for the return. The Order Flow – Mixed or Return with Approval process ends after the return order is closed. The process can end with a result of rejected if:
The approving manager does not authorize the return.
The order is not eligible for return.
The Order Flow – Mixed or Return with Approval workflow process is associated with the following OM Order Header subprocesses:
Order Flow - Return with Approval is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Header item type.
To view the properties of the Order Flow – Mixed or Return with Approval 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 Order Flow – Mixed or Return with approval 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 Order Flow – Mixed or Return with Approval, you see that the process consists of 2 unique activities and 3 subprocesses, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Order Flow – Mixed or Return with Approval process.
Order Flow – Mixed or Return with Approval Workflow
The Order Flow - Generic workflow begins with the Enter activity. The workflow then proceeds to the Book - Order, Manual subprocess.
Once the order is booked, the 'Is AME Used for Approval' function in this workflow checks if the Use Approvals Management Engine check box is selected in the Transaction Type window. If yes, then it goes to 'Approve Return – Order with Mixed Lines AME' sub process. This sub process takes care of approvals from AME. If it is unchecked, then this function goes to 'Approve Return – Order with Mixed Lines subprocess as seen in the following diagram:
The Approve Return – Order with Mixed Lines subprocess sends notification to verify that the return is authorized. After the authorization status is determined, the workflow process resumes and moves to the Close - Order. Once all the lines in the Return have been closed the Return will be closed. After the order is successfully closed, the process ends.
Order Flow – Mixed or Return with Approval Activities
The following table provides descriptions of each activity in the Order Flow – Mixed or Return with Approval process. For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter | WF_STANDARD.NOOP | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The following section discusses the workflow processes associated with the OM Order Line item type:
For more information regarding the OM Order Line item type, refer to Introduction.
The Line Flow - ATO Item workflow process supports ATO item lines only, and can be assigned to ATO Item lines instead of the Line Flow-Generic.
The Line Flow - ATO Item workflow process is initiated when an item on a sales order line is entered as an Assemble-to-Order (ATO) item. ATO items are associated with Oracle Configure to Order. To learn more about implementing Oracle Configure to Order, refer to the Oracle Configure to Order Implementation Manual. When you enter an order line in Oracle Order Management, the process runs through several subprocess that schedule the line, create the supply for the assemble to order item, prepare for shipping, interface with Oracle Receivables for invoicing, and closing the line.
The Line Flow - ATO Item process can only end after the line is closed. To initiate the Line Flow - ATO Item process, you must enter an order in Oracle Order Management. The following subprocess are contained in the Line Flow - ATO Item workflow process:
Branch on Source Type
The Line Flow - ATO Item process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - ATO Item 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 Line Flow - ATO Item 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 following diagram depicts the Line Flow - ATO Item process.
Line Flow - ATO Item Workflow
The Line Flow - ATO Item workflow begins with the Enter - Line subprocess. This subprocess ensures that the order is booked before proceeding with the rest of the line flow.
After the order is booked the workflow process proceeds to the Schedule - Line subprocess. The Branch on Source Type activity is available in the Line Flow - ATO Item process just so that completion of this activity can be tracked. Once the activity is complete, you cannot change the warehouse on the line, if the change triggers a change in ato_line_id on the line. This activity is not intended to perform any branching in the Line Flow - ATO Item process. When scheduling for the line is complete the Create Supply Order - Line, Manual subprocess is initiated. The Ship - Line, Manual subprocess is initiated after supply is created for the line. The Fulfill - Deferred activity moves line fulfillment to the background engine. Next, the workflow interfaces with Oracle Receivables to create an invoice for the line. After the invoice interface is complete, the line is closed and the subprocess ends.
The following table provides descriptions of each activity in the Line Flow - ATO Item process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - ATO Model workflow process supports ATO model lines only, and can be assigned to ATO Model lines instead of the Line Flow - Generic.
The Line Flow - ATO Model workflow process is initiated when an item on a sales order line is entered as an Assemble-to-Order (ATO) model. ATO is associated with Oracle Configure to Order. For more information about implementing Oracle Configure to Order, refer to the Oracle Configure to Order Implementation Manual.
The Line Flow - ATO Model process can only end after the line is closed. To initiate the Line Flow - ATO Model process, you must enter an order in Oracle Order Management. The following subprocess are contained in the Line Flow - ATO Model workflow process:
The Line Flow - ATO Model process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - ATO Model 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 Line Flow - ATO Model 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 Line Flow - ATO Model, you see that the process consists of 3 unique activities and 5 subprocesses, which comprise the 8 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - ATO Item process. Each node of this subprocess is numbered for referencing.
Line Flow - ATO Model Workflow
The Line Flow - ATO Model workflow begins at node 1 with the Enter - Line subprocess. This subprocess ensures that the order is booked before proceeding with the rest of the line flow.
After the order is booked the workflow process proceeds to the Schedule - Line subprocess in node 2. When scheduling for the line is complete the Create Configuration - Line, Manual subprocess is initiated. The Fulfill - Deferred activity in node 4 moves line fulfillment to the background engine. In node 6, Invoice Interface - Line, Deferred, the workflow interfaces with Oracle Receivables to create an invoice for the line. After the invoice interface is complete, the line is closed (Close - Line) and the subprocess ends (End).
The following table provides descriptions of each activity in the Line Flow - ATO Model process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Configuration workflow process is associated with Oracle Configure to Order. This workflow works only with ATO configuration items and must be assigned specifically to configuration lines during the implementation process. To learn more about implementing Oracle Configure to Order, refer to the Oracle Configure to Order Implementation Manual.
To initiate the Line Flow - Configuration process, you must move an ATO model line through Create Configuration - Eligible activity by progressing the order line or by running the Autocreate Config batch program. This creates the configuration item, links it to the order, and starts the Line Flow - Configuration process.
The following subprocess are contained in the Line Flow - Configuration workflow process:
The Line Flow - Configuration process can only end after the line is closed. The Line Flow - Configuration process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Configuration 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 Line Flow - Configuration 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 Line Flow - Configuration, you see that the process consists of 4 unique activities and 4 subprocesses, which comprise the 8 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Configuration process. Each node of this subprocess is numbered for referencing.
Line Flow - Configuration Workflow
The Line Flow - Configuration workflow begins at node 1 with the Start activity. In node 2, the process runs the Create Manufacturing Configuration Data - Line, Manual subprocess, then the Create Supply Order - Line, Manual subprocess in
node 3. Once these subprocess are completed, the Ship - Line, Manual subprocess is initiated. In node 5, the Fulfill - Deferred activity moves fulfillment to the background engine. The process initiates the Close - Line subprocess in node 7. After the line is successfully closed, the process ends.
The following table provides descriptions of each activity in the Line Flow - Configuration process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
This process is not currently used in Oracle Order Management is listed for reference purposes only. Do not use this process when assigning processes to transaction types. Oracle does not provide support for this workflow process.
The Line Flow - Configuration with Authorize to Ship (RLM) workflow process is associated with Oracle Release Management users. Line Flow - Configuration with Authorize to Ship (RLM) ensures that a line is eligible for shipping.
This workflow is specific to Oracle Release Management users and must be assigned during the implementation process. To learn more about implementing Oracle Release Management, refer to the Oracle Release Management Implementation Manual.
To initiate the Line Flow - Configuration with Authorize to Ship (RLM) process, you must enter an order in Oracle Order Management. If the items on the line require authorization before shipping, this process initiates. The following subprocess are contained in the Line Flow - Configuration with Authorize to Ship (RLM) workflow process:
The Line Flow - Configuration with Authorize to Ship (RLM) process can only end after the line is closed.
The Line Flow - Configuration with Authorize to Ship (RLM) process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Configuration with Authorize to Ship (RLM) 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 Line Flow - Configuration with Authorize to Ship (RLM) 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 Line Flow - Configuration with Authorize to Ship (RLM), you see that the process consists of 5 unique activities and 5 subprocesses, which comprise the 10 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Configuration with Authorize to Ship (RLM) process. Each node of this subprocess is numbered for referencing.
Line Flow - Configuration with Authorize to Ship (RLM) Workflow
The Line Flow - Configuration with Authorize to Ship (RLM) workflow begins at node 1 with the Start activity.
In node 2, the process runs the Configuration - Check Status activity. Once status is verified the process moves through the Create Manufacturing Configuration Data - Line, Manual subprocess in node 3 and the Create Supply Order - Line, Manual subprocess in node 4. Once these subprocess are completed, the Authorized to Ship - Line subprocess is initiated in node 5, then Ship - Line, Manual subprocess in node 6. In node 7, the Fulfill - Deferred activity moves fulfillment to the background engine. The process initiates the Close - Line subprocess in node 9. After the line is successfully closed, the process ends.
The following table provides descriptions of each activity in the Line Flow - Configuration with Authorize to Ship (RLM) process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Configuration - Check Status | CTO_WORKFLOW.CHECK_RESERVATION_STATUS_WF | Config Data Results | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic process is a workflow process that is initiated when you save a sales order line in Oracle Order Management. The Line - Flow Generic process contains several subprocesses to ensure that an order line is properly entered, scheduled, created, invoiced, fulfilled, shipped, and closed. If you use several different line flows in your business, the Line Flow - Generic workflow can act as a default; it initiates when no other flow is determined necessary for a line. When you save an order line in Oracle Order Management, the process verifies that the order is booked before proceeding. Once booking is verified, the process continues with scheduling, supply creation, invoicing, fulfillment, shipping and closing. Several of these actions are performed in the following workflow subprocesses contained in Line Flow - Generic:
Line Flow - Generic can only end once the line is successfully closed.
The Line Flow - Generic process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic 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 Line Flow - Generic 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 Line Flow - Generic, you see that the process consists of 3 unique activities and 6 subprocesses, which comprise the 9 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic Workflow
The Line Flow - Generic workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. The Create Supply - Line subprocess is initiated in node 3. After supply is created for the line, the Ship - Line, Manual subprocess in node 4 initiates. In node 5, the Fulfill - Deferred activity moves fulfillment to the background engine. Node 7 is the Invoice Interface - Line subprocess that generates invoicing information for the line. The process initiates the Close - Line subprocess at node 8. After the line is successfully closed, the process ends.
The following table provides descriptions of each activity in the Line Flow - Generic process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Line Flow Generic, Performance is a more recent line flow optimized for high volume users who have performance concerns. It is functionally the same as Line Flow-Generic, but performance is improved by placing the subprocesses at the top level/main process.
If your performance is satisfactory and you are currently using Line Flow – Generic, you will probably want to continue to use the initially seeded generic flow. The traditional Line Flow – Generic has everything decomposed into subprocesses, which could make it easier to extend the flow. For example, you could add an activity to the top level/main flow without modifying the subprocesses seeded by Order Management. Then you could update a subprocess via patching, without the need to add your changes. If you are modifying the seeded flow, it may be beneficial to use Line Flow – Generic instead of Line Flow-Generic, Performance.
It is possible to extend or even customize Line Flow-Generic, Performance, but then you will have to make your changes to a copy of the line flow any time it is updated via a patch.
Line Flow - Generic, Performance can only end once the line is successfully closed.
The Line Flow - Generic, Performance process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, Performance 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 Line Flow - Generic, Performance 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 Line Flow - Generic, Performance, you see that the process consists of 7 unique activities and 2 subprocesses that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, Performance process.
Line Flow - Generic, Performance Workflow 1
The Line Flow - Generic, Performance workflow begins with the Wait for Booking subprocess. This function verifies that the order is booked before proceeding to the next step in the workflow.
The process then attempts to schedule the order line using the Schedule activity. If the order line is manually changed to incomplete or on hold, the Schedule - Eligible function will be used, otherwise the Schedule activity moves the workflow forward as complete. The Branch on Source Type function uses the lookup (has a result type of) Source Type. The source types include: ATO Item, Build, Dropship, and Ship (default). If Build is the source type, then the subprocess Create Configuration - Line, Manual is executed, then Ship. If ATO Item is the source type, then Create Supply Order - Line, Manual is executed, then Ship. If Dropship is the source type, then the Purchase Release - Line, Deferred activity is executed, after which the Purchase Release activity is executed. If the order line is manually changed to incomplete or on hold, the Purchase Release - Eligible function will be used, otherwise the Purchase Release activity moves the workflow forward to Ship. Next, the Fulfill - Deferred activity moves the workflow forward to the Fulfill activity.
Line Flow - Generic, Performance Workflow (Continued)
The Fulfill activity then processes the workflow onto the Invoice Interface function. If the order line is manually changed to incomplete or on hold, the Invoice Interface - Eligible activity will be used, otherwise, the Invoice Interface function moves the workflow to either Wait for Required for Revenue or Delivery (if Partial) or Close (if Not Eligible or Complete). If the order line is manually changed to incomplete or on hold, the Wait function is used to specify a day of the week, specific date, and so on before closing the line. When the order line is complete or not eligible, the workflow moves to Close - Continue Header where the workflow ends.
The following table provides descriptions of each activity in the Line Flow - Generic, Performance process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Schedule | OE_OEOL_SCH.SCHEDULE_LINE | On Hold, Incomplete, Not Eligible, Complete | Yes |
Schedule - Eligible | OE_STANDARD_WF.STANDARD_BLOCK | None | Yes |
Purchase Release - Deferred | WF_STANDARD.DEFER | None | Yes |
Purchase Release | OE_OEOL_SCH.RELEASE_TO_PURCHASING | On Hold, Incomplete, Not Eligible, Complete | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
Inventory Interface - Eligible | OE_STANDARD_WF.STANDARD_BLOCK | None | Yes |
The following workflow subprocesses are contained in Line Flow - Generic, Performance:
Note: Data Manipulation Language (DML) describes the portion of SQL that allows you to manipulate or control your data. The goal is to provide efficient human interaction with the system. A query language is a portion of a DML involving information retrieval only.
The Line Flow - Generic with Authorize to Ship (RLM) process is a workflow process that is initiated when you save a sales order line in Oracle Order Management. The Line - Flow Generic with Authorize to Ship (RLM) process is specific to Oracle Release Management users, and enables you to authorize order lines for shipping.
Line Flow - Generic with Authorize to Ship (RLM) contains all of the subprocess and activities contained in Line Flow - Generic, as well as the Authorize to Ship (RLM) subprocess.
To initiate the Line Flow - Generic with Authorize to Ship (RLM) process, enter an order line in Oracle Order Management. The following subprocess are contained in the Line Flow - Configuration with Authorize to Ship (RLM) workflow process:
The Line Flow - Generic with Authorize to Ship (RLM) process can only end after the line is successfully closed.
Because this workflow is specific to Oracle Release Management users, it must be assigned during the implementation process. To learn more about implementing Oracle Release Management, refer to the Oracle Release Management Implementation Manual.
The Line Flow - Generic with Authorize to Ship (RLM) process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic with Authorize to Ship (RLM) 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 Line Flow - Generic with Authorize to Ship (RLM) 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 Line Flow - Generic with Authorize to Ship (RLM), you see that the process consists of 3 unique activities and 7 subprocesses, which comprise the 10 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic with Authorize to Ship (RLM) process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic with Authorize to Ship (RLM) Workflow
The Line Flow - Generic with Authorize to Ship (RLM) workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. The Create Supply - Line subprocess is initiated in node 3. The Oracle Release Management user Authorized to Ship - Line subprocess at node 4 verifies that the line is approved for shipping. After approval is determined, the Ship - Line, Manual subprocess at node 5 initiates. In node 6, the Fulfill - Deferred activity moves fulfillment to the background engine. Node 8 is the Invoice Interface - Line subprocess that generates invoicing information for the line. The process initiates the Close - Line subprocess at node 9. After the line is successfully closed, the process ends.
The following table provides descriptions of each activity in the Line Flow - Generic with Authorize to Ship (RLM) process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic with Header Level Invoice Interface process is a workflow process that is initiated when you save a sales order line in Oracle Order Management. The Line - Flow Generic with Header Level Invoice Interface process interfaces with Oracle Receivables to generate invoicing information for an order line. The process works with the seeded header flow to support header level invoicing.
The Line Flow - Generic with Header Level Invoice Interface workflow contains several subprocesses to ensure that an order line is properly entered, scheduled, created, invoiced, fulfilled, shipped, and closed. Line Flow - Generic with Header Level Invoice Interface contains all of the subprocess and activities contained in Line Flow - Generic, but replaces the Invoice Interface - Line subprocess with the Header Level Invoice Interface - Line, Deferred subprocess.
When you save an order line in Oracle Order Management, the Line Flow - Generic with Header Level Invoice Interface process verifies that the order is booked before proceeding. Once booking is verified, the process continues with scheduling, supply creation, invoicing, fulfillment, shipping and closing. Several of these activities are performed in the following workflow subprocesses contained in Line Flow - Generic with Header Level Invoice Interface:
Line Flow - Generic with Header Level Invoice Interface can only end once the line is successfully closed.
The Line Flow - Generic with Header Level Invoice Interface process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic with Header Level Invoice Interface 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 Line Flow - Generic with Header Level Invoice Interface 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 Line Flow - Generic with Header Level Invoice Interface, you see that the process consists of 1 unique activity and 6 subprocesses, which comprise the 7 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic with Header Level Invoice Interface process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic with Header Level Invoice Interface Workflow
The Line Flow - Generic workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. The Create Supply - Line subprocess is initiated in node 3. After supply is created for the line, the Ship - Line, Manual subprocess in node 4 initiates. In node 5, the Header Level Invoice Interface - Line, Deferred activity moves header level invoice interfacing to the background engine. This enables the workflow to proceed. Node 6 is the Close - Line subprocess, followed by the End activity at node 7.
The following table provides a description of the activity in the Line Flow - Generic with Header Level Invoice Interface process.
For more information about Oracle Order Management workflow activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic, With Export Compliance process is a workflow process that is initiated when you save a sales order line in Oracle Order Management that requires exportation. The Line Flow - Generic, With Export Compliance process contains a subprocess that performs Denied Party screening according to United States Bureau of Export Administration's Denied Party listing.
When an order line is submitted that must comply with the United States Bureau of Export Administration's Denied Party listing, the Line Flow - Generic, With Export Compliance workflow process initiates. The Line - Flow Generic, With Export Compliance process contains several subprocesses to ensure that the order line is properly entered, scheduled, created, invoiced, fulfilled, shipped, and closed. Line Flow - Generic, With Export Compliance contains all of the subprocess and activities contained in Line Flow - Generic, as well as the Export Compliance Screening - Line subprocess.
When you save an order line in Oracle Order Management, the Line Flow - Generic, With Export Compliance process verifies that the order is booked before proceeding. Once booking is verified, the process continues with scheduling, supply creation, invoicing, fulfillment, shipping and closing. Several of these activities are performed in the following workflow subprocesses contained in Line Flow - Generic, With Export Compliance:
Line Flow - Generic, With Export Compliance can only end once the line is successfully closed.
The Line Flow - Generic, With Export Compliance process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, With Export Compliance 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 Line Flow - Generic, With Export Compliance 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 Line Flow - Generic, With Export Compliance, you see that the process consists of 3 unique activities and 7 subprocesses, which comprise the 10 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, With Export Compliance process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic with Export Compliance Workflow
The Line Flow - Generic With Export Compliance workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. To comply with the United States Bureau of Export Administration's Denied Party listing, the Export Compliance Screening - Line subprocess at node 3 initiates. If the line passes this screening process, then the process approves the line for exporting and continues.
The Create Supply - Line subprocess is initiated in node 4. After supply is created for the line, the Ship - Line, Manual subprocess at node 5 initiates. At node 6, the Fulfill - Deferred activity moves fulfillment to the background engine. Node 8 is the Invoice Interface - Line subprocess that generates invoicing information for the line. The process initiates the Close - Line subprocess at node 9. After the line is successfully closed, the process ends at node 10.
The following table provides descriptions of each activity in the Line Flow - Generic With Export Compliance process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic, Bill Only process is a workflow process is used for order lines that do not require shipping. The Line Flow - Generic, Bill Only process is used in a situation when only a bill for the order must be generated. The process contains several subprocesses to ensure that the order line is properly entered, invoiced, fulfilled, and closed.
When you save an order line in Oracle Order Management, the Line Flow - Generic, Bill Only process verifies that the order is booked before proceeding. Once booking is verified, the process continues with invoicing, fulfillment, and closing. Several of these actions are performed in the following workflow subprocesses contained in Line Flow - Generic, Bill Only:
Line Flow - Generic, Bill Only ends once the line is successfully closed. The only process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, Bill Only 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 Line Flow - Generic, Bill Only 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 Line Flow - Generic, Bill Only, you see that the process consists of 2 unique activities and 3 subprocesses, which comprise the 5 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, Bill Only process. Each node of this process is numbered for referencing.
Line Flow - Generic, Bill Only Workflow
The Line Flow - Generic, Bill Only workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
The process attempts to fulfill the order at node 2. At node 3, the Invoice Interface - Line, Deferred subprocess is initiated. This subprocess moves the invoice interface to the background engine. The process initiates the Close - Line subprocess at node 4. After the line is successfully closed, the process ends at node 5.
The following table provides descriptions of each activity in the Line Flow - Generic, Bill Only process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic, Bill Only with Inventory Interface process is a workflow process that is initiated when you save a sales order line in Oracle Order Management. The Line Flow - Generic, Bill Only with Inventory Interface process is used in a situation when only a bill for the order must be generated. The process contains several subprocesses to ensure that the order line is properly entered, invoiced, fulfilled, and closed.
When you save an order line in Oracle Order Management, the Line Flow - Generic, Bill Only with Inventory Interface process verifies that the order is booked before proceeding. Once booking is verified, the process continues with invoicing, fulfillment, and closing. Several of these actions are performed in the following workflow subprocesses contained in Line Flow - Generic, Bill Only with Inventory Interface:
Line Flow - Generic, Bill Only with Inventory Interface ends after the line is successfully closed.
The Line Flow - Generic, Bill Only with Inventory Interface process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, Bill Only with Inventory Interface 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 Line Flow - Generic, Bill Only with Inventory Interface 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 Line Flow - Generic, Bill Only with Inventory Interface, you see that the process consists of 2 unique activities and 4 subprocesses, which comprise the 6 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, Bill Only with Inventory Interface process. Each node of this process is numbered for referencing.
Line Flow - Generic, Bill Only with Inventory Interface Workflow
The Line Flow - Generic, Bill Only with Inventory Interface workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the Inventory Interface Non-Ship - Line, Deferred subprocess is initiated. After completion of that subprocess, the Line Flow - Generic, Bill Only with Inventory Interface process attempts to fulfill the order at node 3. At node 4, the Invoice Interface - Line, Deferred subprocess is initiated. This subprocess moves the invoice interface to the background engine. The process initiates the Close - Line subprocess at node 5. After the line is successfully closed, the process ends at node 6.
The following table provides descriptions of each activity in the Line Flow - Generic, Bill Only with Inventory Interface process.
For more information about individual activities, refer to Seeded Function Activity Definitions
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic, Ship Only process is a workflow process that is initiated when you save a sales order line in Oracle Order Management that does not require invoicing. An order line can require this when the rest of the order lines have already been shipped with an invoice for the order. Line Flow - Generic, Ship Only is associated with order lines that only require shipping.
Note: The Line Flow - Generic, Ship Only process is identical to the Line Flow - Generic process except that it does not include the Invoice Interface - Line activity.
The Line - Flow Generic, Ship Only process contains several subprocesses to ensure that an order line is properly entered, scheduled, created, fulfilled, shipped, and closed.
When you save an order line in Oracle Order Management, the Line Flow - Generic, Ship Only process verifies that the order is booked before proceeding. Once booking is verified, the process continues with scheduling, supply creation, fulfillment, shipping, and closing. Several of these actions are performed in the following workflow subprocesses contained in Line Flow - Generic, Ship Only:
Line Flow - Generic, Ship Only ends after the line is successfully closed.
The Line Flow - Generic, Ship Only process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, Ship Only 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 Line Flow - Generic, Ship Only 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 Line Flow - Generic, Ship Only, you see that the process consists of 3 unique activities and 5 subprocesses, which comprise the 8 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, Ship Only process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic, Ship Only Workflow
The Line Flow - Generic, Ship Only workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. The Create Supply - Line subprocess is initiated in node 3. After supply is created for the line, the Ship - Line, Manual subprocess in node 4 initiates. In node 5, the Fulfill - Deferred activity moves fulfillment to the background engine.
The process initiates the Close - Line subprocess at node 7. After the line is successfully closed, the process ends at node 8.
The following table provides descriptions of each activity in the Line Flow - Generic, Ship Only process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Generic, with Repricing at Fulfillment process is a workflow process initiated when you save a sales order line in Oracle Order Management that requires repricing after the order line is fulfilled. The Line - Flow Generic with Repricing at Fulfillment process contains several subprocesses to ensure that an order line is properly entered, scheduled, created, invoiced, fulfilled, repriced, shipped, and closed.
Line Flow - Generic, with Repricing at Fulfillment contains all of the subprocess and activities contained in the Line Flow - Generic workflow process, as well as the Reprice - Line subprocess.
When you save an order line in Oracle Order Management, the Line Flow - Generic, with Repricing at Fulfillment process verifies that the order is booked before proceeding. Once booking is verified, the process continues with scheduling, supply creation, invoicing, fulfillment, repricing, shipping, and closing. Several of these activities are performed in the following workflow subprocesses contained in Line Flow - Generic, with Repricing at Fulfillment:
Line Flow - Generic, with Repricing at Fulfillment ends after the line is successfully closed.
The Line Flow - Generic, with Repricing at Fulfillment process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Generic, with Repricing at Fulfillment 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 Line Flow - Generic, with Repricing at Fulfillment 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 Line Flow - Generic, with Repricing at Fulfillment, you see that the process consists of 3 unique activities and 7 subprocesses, which comprise the 10 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Generic, with Repricing at Fulfillment process. Each node of this subprocess is numbered for referencing.
Line Flow - Generic, with Repricing at Fulfillment Workflow
The Line Flow - Generic, with Repricing at Fulfillment workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
In node 2, the process attempts to schedule the line for the order using the Schedule - Line subprocess. The Create Supply - Line subprocess is initiated in node 3. After supply is created for the line, the Ship - Line, Manual subprocess in node 4 initiates. In node 5, the Fulfill - Deferred activity moves fulfillment to the background engine. At node 7, the Reprice - Line is initiated. After the line is repriced, the process proceed to the Invoice Interface - Line subprocess at node 8. The process initiates the Close - Line subprocess at node 9. Once the line is successfully closed, the process ends at node 10.
The following table provides descriptions of each activity in the Line Flow - Generic, with Repricing at Fulfillment process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The profile option Included Items Freeze Method has the following possible values: Ready to Pick/ Purchase Release, Entry, Booking and None. When the value of the profile option is Ready to Pick/Purchase Release, the workflow process Line Flow Generic with Freeze Included Items at Pick is initiated. The workflow process has an activity that holds Models, Classes and Kits. You can manually complete the workflow activity by progressing the order or using Freeze Included Items at Pick release concurrent program. You can release the activity before pick releasing the order. Included Items will also be prevented from getting interfaced to Shipping; manually releasing the Models, Classes or Kits before pick release will freeze and interface the included items to shipping.
The following table provides a description for the activities of Line Flow - Generic with Freeze Included Items at Pick.
Activity | Function | Result Type | Required |
---|---|---|---|
Included Items Freeze Required | INCLUDED_ITEMS_FREEZE_REQUIRED | PL/SQL | Yes |
Freeze Included Items - Eligible | FREEZE_INCLUDED_ITEMS_ELIGIBLE | PL/SQL | Yes |
Fulfill - Deferred | DEFER_FULFILLMENT | PL/SQL | Yes |
Fulfill | FULFILL_LINE | PL/SQL | Yes |
This flow is utilized by Oracle Learning Management (OLM). This line flow is assigned when events and enrollment are entered in Order Management. In the case of both inbound or outbound transactions, when a line starts its flow the UOM is checked - the UOM would be event or enrollment. Each UOM has an independent sub process. For more information on OLM (OTA) flows, please refer to the Oracle Learning Management User Guide.
The Line Flow - Return for Credit Only process is a workflow process is used for return orders submitted in Oracle Order Management that do not require receipt or approval. This is an order line process. When your customer returns partial quantity of an order, Oracle Order Management splits the return line so that customers can be issued credit for what was returned.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit Only process verifies that the return is booked before proceeding. Once booking is verified, the process continues with invoicing and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return for Credit Only:
Line Flow - Return for Credit Only ends after the line is successfully closed.
The Line Flow - Return for Credit Only process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit Only 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 Line Flow - Return for Credit Only 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 Line Flow - Return for Credit Only, you see that the process consists of 1 unique activity and 3 subprocesses, which comprise the 4 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit Only process. Each node of this subprocess is numbered for referencing.
Line Flow - Return for Credit Only Workflow
The Line Flow - Return for Credit Only workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process uses the Invoice Interface - Line, Deferred subprocess to generate the credit invoice. The process initiates the Close - Line subprocess at node 3. After the line is successfully closed, the process ends at node 4.
The following table provides a description for the End activity in the Line Flow - Return for Credit Only process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Return for Credit Only with Header Invoicing process is a workflow process is used for return orders submitted in Oracle Order Management that do not require receipt or approval. This is an order line process. When your customer returns an order quantity, Oracle Order Management issues credit for what was returned.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit Only with Header Invoicing process verifies that the return is booked before proceeding. Once booking is verified, the process continues with invoicing and closing.
Line Flow - Return for Credit Only with Header Invoicing ends after the lines are successfully closed.
The Line Flow - Return for Credit Only with Header Invoicing process is contained in the Seeded Data File oexwford.wft, and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit Only with Header Invoicing 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 definition form. The Details property page of the process activity indicates that the Line Flow - Return for Credit Only with Header Invoicing 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 Line Flow - Return for Credit Only with Header Invoicing, you see that the process consists of 4 activities and 3 sub-processes, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit Only with Header Invoicing process.
Line Flow - Return for Credit Only with Header Invoicing process
The Line Flow - Return for Credit Only with Header Invoicing workflow begins at node 1 with the Enter - Line. This sub-process verifies that the order is booked before proceeding with the remainder of the workflow.
The subprocess Header Level Invoice Interface for Return Line w/o Receipt has two activities: Fulfill - Continue Header Flow and Wait for Invoice Interface. The wait and continue activities have been included to ensure that all the order lines are invoiced before they are closed at the header level invoicing activity.
The following table provides a description for the activities in the Line Flow - Return for Credit Only with Header Invoicing process.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter - Line | - | None | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
Header Level Invoice Interface for Return Line w/o Receipt | - | None | Yes |
Close – Line | - | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
For more information about individual activities, refer to Seeded Function Activity Definitions.
The Line Flow - Return for Credit Only with Approval process is a workflow process is used for return orders submitted in Oracle Order Management that requires approval. This is an order line process. When your customer returns partial quantity of an order, Oracle Order Management splits the return line so that customers can be issued credit for what was returned.
Note: The Line Flow - Return for Credit Only with Approval process is identical to the Line Flow - Return for Credit Only process except that it includes the Wait for Approval activity.
The Line Flow - Return for Credit Only with Approval process contains several subprocesses to ensure that the return is properly entered, approved, invoiced, and closed.
Line Flow - Return for Credit Only with Approval contains all of the subprocess and activities contained in the Return for Credit Only workflow process, as well as the Wait for Approval block activity.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit Only with Approval process verifies that the return is booked before proceeding. The process then verifies that the return is approved before proceeding with the return. Once booking and approval are verified, the process continues with invoicing and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return for Credit Only with Approval:
Line Flow - Return for Credit Only with Approval ends after the line is successfully closed.
The Line Flow - Return for Credit Only with Approval process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit Only with Approval 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 Line Flow - Return for Credit Only with Approval 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 Line Flow - Return for Credit Only with Approval, you see that the process consists of 2 unique activity and 3 subprocesses, which comprise the 5 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit Only with Approval process. Each node of this process is numbered for referencing.
Line Flow - Return for Credit Only with Approval Workflow
The Line Flow - Return for Credit Only with Approval workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process encounters a block activity that requires the return order line to obtain approval before proceeding with the workflow. Once approval is obtained, the workflow proceeds to the Invoice Interface - Line, Deferred subprocess at node 3 to generate the credit invoice. The process initiates the Close - Line subprocess at node 4. After the line is successfully closed, the process ends at node 5.
The following table provides a description for the activities in the Line Flow - Return for Credit Only with Approval process.
Activity | Function | Result Type | Required |
---|---|---|---|
Wait for Approval | WF_STANDARD.WAITFORFLOW | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Return for Credit Only with Approval and Hdr Inv process is a workflow process is used for return orders submitted in Oracle Order Management that requires approval. This is an order line process. When your customer returns an order quantity, Order Management issues credit for what was returned
Note: Line Flow - Return for Credit Only with Approval and Hdr Inv process is identical to the Line Flow - Return for Credit Only with Header Invoicing process except that it includes the Wait for Approval activity.
The Line Flow - Return for Credit Only with Approval and Hdr Inv process contains several subprocesses to ensure that the return is properly entered, approved, invoiced, and closed.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit Only with Approval and Hdr Inv process verifies that the return is booked before proceeding. The process then verifies that the return is approved before proceeding with the return. Once booking and approval are verified, the process continues with invoicing and closing. Line Flow - Return for Credit Only with Approval and Hdr Inv ends after the line is successfully closed.
The Line Flow - Return for Credit Only with Approval and Hdr Inv process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit Only with Approval and Hdr Inv 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 definition form.
The Details property page of the process activity indicates that the Line Flow - Return for Credit Only with Approval and Hdr Inv 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 Line Flow - Return for Credit Only with Approval and Hdr Inv, you see that the process consists of 4 activities and 3 subprocesses, which comprise the 7 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit Only with Approval and Hdr Inv process.
Line Flow - Return for Credit Only with Approval and Hdr Inv
The Line Flow - Return for Credit Only with Approval and Hdr Inv workflow begins with the Enter - Line sub-process. This sub-process verifies that the order is booked before proceeding with the remainder of the workflow.
The sub-process Header Level Invoice Interface for Return Line w/o Receipt has two activities: Fulfill - Continue Header Flow and Wait for Invoice Interface. The wait and continue activities have been included to ensure that all the order lines are invoiced before they are closed at the header level invoicing activity.
The following table provides a description for the activities in the Line Flow - Return for Credit Only with Approval and Hdr Inv process.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter – Line | None | Yes | |
Wait for Approval | WF_STANDARD.WAITFORFLOW | None | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
Header Level Invoice Interface for Return Line w/o Receipt | None | Yes | |
Close - Line | None | Yes | |
End | WF_STANDARD.NOOP | None | Yes |
For more information about individual activities, refer to Seeded Function Activity Definitions.
The Line Flow - Return for Credit with Receipt process is a workflow process used for returns that require inspection before credit is given. This is an order line process. When your customer returns partial quantity of an order, Oracle Order Management splits the return line so that customers can be issued credit for what was returned.
The Line Flow - Return for Credit with Receipt process contains several subprocesses to ensure that the return is properly entered, approved, inspected, fulfilled, invoiced, and closed.
Line Flow - Return for Credit with Approval contains all of the subprocess and activities contained in the Return for Credit workflow process, as well as the Return Receiving - Line subprocess and two fulfillment activities.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit with Receipt process verifies that the return is booked before proceeding. Once booking is verified, the process continues with receiving, invoicing and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return for Credit with Receipt:
Line Flow - Return for Credit with Receipt ends after the line is successfully closed.
The Line Flow - Return for Credit with Receipt process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit with Receipt 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 Line Flow - Return for Credit 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.
When you display the Process window for the Line Flow - Return for Credit with Receipt, you see that the process consists of 3 unique activity and 4 subprocesses, which comprise the 7 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit with Receipt process. Each node of this process is numbered for referencing.
Line Flow - Return for Credit with Receipt Workflow
The Line Flow - Return for Credit with Receipt workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the Return Receiving - Line subprocess waits for inspection of the returned items before proceeding to the order fulfillment activities in nodes 3 and 4. The workflow proceeds to the Invoice Interface - Line, Deferred subprocess at node 5 to generate the credit invoice. The Close - Line subprocess initiates at node 6. After the line is successfully closed, the process ends at node 7.
The following table provides a description for the activities in the Line Flow - Return for Credit with Receipt process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Return for Credit with Receipt and Hdr Invoicing process is a workflow process used for returns that require inspection before credit is given. This is an order line process. When your customer returns an order quantity, Order Management issues credit for what was returned.
The Line Flow - Return for Credit with Receipt and Hdr Invoicing process contains 4 sub-processes and 1 activity to ensure that the return is properly entered, booked, inspected, fulfilled, invoiced, and closed.
Line Flow - Return for Credit with Receipt and Hdr Invoicing contains all of the sub-processes and activities contained in the Return for Credit only with Header Invoicing workflow process, as well as the Return Receiving - Line sub-process.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit with Receipt and Hdr Invoicing process verifies that the return is booked before proceeding. Once booking is verified, the process continues with receiving, invoicing and closing.
Line Flow - Return for Credit with Receipt and Hdr Invoicing ends after the line is successfully closed.
The Line Flow - Return for Credit with Receipt and Hdr Invoicing process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit with Receipt and Hdr Invoicing 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 definition form.
The Details property page of the process activity indicates that the Line Flow - Return for Credit with Receipt and Hdr Invoicing 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 following diagram depicts the Line Flow - Return for Credit with Receipt and Hdr Invoicing process.
Line Flow - Return for Credit with Receipt and Hdr Invoicing process
The Line Flow - Return for Credit with Receipt and Hdr Invoicing workflow begins at node 1 with the Enter - Line subprocess. This sub-process verifies that the order is booked before proceeding with the remainder of the workflow. At node 2 the Return Receiving - Line sub-process waits for inspection of the returned items before proceeding to the order fulfillment activities in nodes 3. The workflow proceeds to the Header Level Invoice Interface for Return Line with Receipt subprocess. The Close - Line subprocess initiates and after the line is successfully closed, the process ends.
The following table provides a description for the activities in the Line Flow - Return for Credit with Receipt and Hdr Invoicing process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Enter - Line | None | Yes | |
Return Receiving - Line | OM Sub-Process Success Results | Yes | |
Header Level Invoice Interface for Return Line with Receipt | None | Yes | |
Close - Line | None | Yes | |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Return for Credit with Receipt and Approval process is a workflow process used for returns that require inspection and approval before credit is given. This is an order line process. When your customer returns partial quantity of an order, Oracle Order Management splits the return line so that customers can be issued credit for what was returned.
Note: The Line Flow - Return for Credit with Receipt and Approval process is identical to the Line Flow - Return for Credit with Receipt process except that it includes the Wait for Approval activity.
The Line Flow - Return for Credit with Receipt process contains several subprocesses to ensure that the return is properly entered, approved, inspected, fulfilled, invoiced, and closed.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit with Receipt and Approval process verifies that the return is booked before proceeding. Once booking is verified, the process continues with receiving, invoicing and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return for Credit with Receipt and Approval:
Line Flow - Return for Credit with Receipt and Approval ends after the line is successfully closed.
The Line Flow - Return for Credit with Receipt and Approval process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit with Receipt and Approval 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 Line Flow - Return for Credit with Receipt and Approval 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 Line Flow - Return for Credit with Receipt and Approval, you see that the process consists of 4 unique activities and 4 subprocesses, which comprise the 8 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit with Receipt and Approval process. Each node of this process is numbered for referencing.
Line Flow - Return for Credit with Receipt and Approval Workflow
The Line Flow - Return for Credit with Receipt and Approval workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process encounters a block activity that requires the return order line to obtain approval before proceeding with the workflow. From this activity the process must be manually progressed before the workflow can proceed to node 3. At node 3, the Return Receiving - Line subprocess waits for inspection of the returned items before proceeding to the order fulfillment activities in nodes 4 and 5. The workflow proceeds to the Invoice Interface - Line, Deferred subprocess at node
6 to generate the credit invoice. The Close - Line subprocess initiates at node 6. After the line is successfully closed, the process to the End activity at node 8.
The following table provides a description for the activities in the Line Flow - Return for Credit with Receipt and Approval process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Wait for Approval | WF_STANDARD.WAITFORFLOW | None | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Line Flow - Return for Credit, Receipt, Approval, Header Inv process is a workflow process used for returns that require inspection and approval before credit is given. This is an order line process. When your customer returns an order quantity, Oracle Order Management issues credit for what was returned.
Note: The Line Flow - Return for Credit, Receipt, Approval, Header Inv process is identical to the Line Flow - Return for Credit with Receipt and Hdr Invoicing process except that it includes the Wait for Approval activity.
The Line Flow - Return for Credit, Receipt, Approval, Header Inv process contains several subprocesses to ensure that the return is properly entered, booked, approved, inspected, fulfilled, invoiced, and closed.
When you save a return order line in Oracle Order Management, the Line Flow - Return for Credit, Receipt, Approval, Header Inv process verifies that the return is booked and approved before proceeding. Once booking and approval is verified, the process continues with receiving, invoicing and closing.
Line Flow - Return for Credit, Receipt, Approval, Header Inv ends after the line is successfully closed.
The Line Flow - Return for Credit, Receipt, Approval, Header Inv process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return for Credit, Receipt, Approval, Header Invprocess, 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 definition form.
The Details property page of the process activity indicates that the Line Flow - Return for Credit, Receipt, Approval, Header Inv 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 Line Flow - Return for Credit, Receipt, Approval, Header Inv, you see that the process consists of 2 unique activities and 4 subprocesses, which comprise the 6 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return for Credit, Receipt, Approval, Header Inv process.
Line Flow - Return for Credit, Receipt, Approval, Header Inv
The Line Flow - Return for Credit, Receipt, Approval, Header Inv workflow begins at node 1 with the Enter - Line sub-process. This sub-process verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process encounters a block activity that requires the return order line to obtain approval before proceeding with the workflow. From this activity the process must be manually progressed before the workflow can proceed to node 3. At node 3, the Return Receiving - Line subprocess waits for inspection of the returned items before proceeding to the order fulfillment activities in node 4. The workflow proceeds to the Header Level Invoice Interface for Return Line with Receipt subprocess at node 4 to generate the credit invoice. The Close - Line subprocess initiates at node 5. After the line is successfully closed, the process moves to the End activity at node 6.
The following table provides a description for the activities in the Line Flow - Return for Credit, Receipt, Approval, Header Inv process.
For more information about individual activities, refer to Seeded Function Activity Definitions
Activity | Function | Result Type | Required |
Enter - Line | None | Yes | |
Wait for Approval | WF_STANDARD.WAITFORFLOW | None | Yes |
Return Receiving - Line | None | Yes | |
Header Level Invoice Interface for Return Line with Receipt | None | Yes | |
Close - Line | None | Yes |
Line Flow - Return with Receipt and Approval, No Credit is a line flow process used for returns that require inspection and approval. When your customer an order quantity of, Oracle Order Management proceeds to approve and then close the order lines without interfacing to Receivables or creating a credit memo.
Note: The Line Flow - Return with Receipt and Approval, No Credit process is identical to the Line Flow - Return for Credit with Receipt and Approval process except that it excludes the Invoice Interface – Line, Deferred activity.
The Line Flow - Return with Receipt and Approval, No Credit process contains several subprocesses to ensure that the return is properly entered, approved, inspected, fulfilled, and closed.
When you save a return order line in Oracle Order Management, the Line Flow - Return with Receipt and Approval, No Credit process verifies that the return is booked before proceeding. Once booking is verified, the process continues with receiving, approving and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return with Receipt and Approval, No Credit:
Line Flow - Return with Receipt and Approval, No Credit ends after the line is successfully closed.
The Line Flow - Return with Receipt and Approval, No Credit process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return with Receipt and Approval, No Credit 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 Line Flow - Return with Receipt and Approval, No Credit 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 Line Flow - Return with Receipt and Approval, No Credit, you see that the process consists of 4 unique activities and 3 subprocesses, which comprise the 7 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return with Receipt and Approval, No Credit process.
Line Flow - Return with Receipt and Approval, No Credit Workflow
The Line Flow - Return with Receipt and Approval, No Credit workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process encounters a block activity that requires the return order line to obtain approval before proceeding with the workflow. From this activity the process must be manually progressed before the workflow can proceed to node 3. At node 3, the Return Receiving - Line subprocess waits for inspection of the returned items before proceeding to the order fulfillment activities in nodes 4 and 5. The Close - Line subprocess initiates at node 6. After the line is successfully closed, the process moves to the End activity at node 7.
The following table provides a description for the activities in the Line Flow - Return with Receipt and Approval, No Credit process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Wait for Approval | WF_STANDARD.WAITFORFLOW | None | Yes |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
Line Flow - Return with Receipt Only, No Credit is a workflow process used for returns. This is an order line process. When your customer returns an order quantity and you enter the return quantity, Oracle Order Management proceeds to close the order lines without interfacing to Receivables or creating a credit memo.
The Line Flow - Return with Receipt Only, No Credit process contains several subprocesses to ensure that the return is properly entered, inspected, and closed.
Line Flow - Return with Receipt Only, No Credit contains all of the subprocess and activities contained in the Line Flow - Return for Credit with Receipt process, except the Invoice Interface – Line, Deferred sub-process.
When you save a return order line in Oracle Order Management, the Line Flow - Return with Receipt Only, No Credit process verifies that the return is booked before proceeding. Once booking is verified, the process continues with receiving and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Return with Receipt Only, No Credit:
Line Flow - Return with Receipt Only, No Credit ends after the line is successfully closed.
Line Flow - Return with Receipt Only, No Credit process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Return with Receipt Only, No Credit 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 Line Flow - Return with Receipt Only, No Credit 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 Line Flow - Return with Receipt Only, No Credit, you see that the process consists of 3 unique activities and 3 subprocesses, which comprise the 7 nodes that appear in the workflow diagram. The following diagram depicts the Line Flow - Return with Receipt Only, No Credit process.
Line Flow - Return with Receipt Only, No Credit Workflow
The Line Flow - Return with Receipt Only, No Credit workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the Return Receiving - Line subprocess waits for inspection of the returned items before proceeding to the order fulfillment activities in nodes 3 and 4. The Close - Line subprocess initiates at node 5. After the line is successfully closed, the process ends at node 6.
The following table provides a description for the activities in the Line Flow - Return with Receipt Only, No Credit process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
This flow is utilized by Oracle Learning Management (OLM). Please refer to the Line Flow – OTA Item for more information. This line flow is assigned when events and enrollment are returned in Order Management. The return flow performs validates the UOM and is intended to return for no credit to enable correction of an enrollment or event. In the case of enrollment the line flow returns a status of Cancel Enrollment and a notification is sent to specific recipients. Please refer to the Oracle Leaning Management User Guide for additional information.
The Line Flow - Standard Service workflow process is initiated when a sales order with service lines is submitted in Oracle Order Management. This type of line flow is used for service items that are purchased with other merchandise, such as a warranty.
The process contains several subprocesses to verify that the return is properly entered, fulfilled, invoiced, and closed.
When you save a return order line in Oracle Order Management, the Line Flow - Standard Service process verifies that the return is booked before proceeding. Once booking is verified, the process continues with invoicing and closing. These activities are performed in the following workflow subprocesses contained in Line Flow - Standard Service:
Line Flow - Standard Service ends after the line is successfully closed.
The Line Flow - Standard Service process is contained in the Seeded Data File oexwford.wft and is associated with the OM Order Line item type.
To view the properties of the Line Flow - Standard Service 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 Line Flow - Standard Service 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 Line Flow - Standard Service, 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.
Line Flow - Standard Service Workflow
The Line Flow - Standard Service workflow begins at node 1 with the Enter - Line subprocess. This subprocess verifies that the order is booked before proceeding with the remainder of the workflow.
At node 2 the process uses the Fulfill - Deferred to move the process to the background engine. After the Fulfill activity at node 3 complete, the line enters the Invoice Interface - Line subprocess at node 4 to process an invoice. The process initiates the Close - Line subprocess at node 5. After the line is successfully closed, the process proceeds to the End activity at node 6.
The following table provides a description for the activities in the Line Flow - Standard Service process.
For more information about individual activities, refer to Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
Fulfill - Deferred | WF_STANDARD.DEFER | None | Yes |
Fulfill | OE_FULFILL_WF.START_FULFILLMENT | None | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The following section discusses the workflows associated with the OM Negotiation Header item type:
The Negotiation Flow - Generic process can be assigned to both Sales Orders and Sales Agreements. A Sales Order that starts with the negotiation phase is considered a Quote until it transitions to the Fulfillment phase where it becomes a firm order, or Sales Order in Oracle Order Management. Sales Agreements maintain their same name during both the Negotiation and Fulfillment phases.
Negotiation Flow - Generic is initiated if it is assigned to the transaction type. Transaction types determine which processes are attached to a Sales Order and Sales Agreements. For more information on defining transaction types, refer to the Oracle Order Management Implementation Guide.
Negotiation Flow - Generic is associated with the following OM Negotiation Header subprocesses:
Negotiation Flow - Generic is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.
To view the properties of the Negotiation Flow - Generic 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 Negotiation Flow - Generic 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 Negotiation Flow - Generic process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Negotiation Flow - Generic process.
Negotiation Flow - Generic Workflow
The following table provides descriptions of each activity in the Negotiation Flow - Generic Process.
For more information about individual function activities, see Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Negotiation Lost | OE_NEGOTIATE_WF.Update_Status_Lost | Null | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The Negotiation Flow - Generic with Approval process can be assigned to both Sales Orders and Sales Agreements. A Sales Order that starts with the negotiation phase is considered a Quote until it transitions to the Fulfillment phase where it becomes a firm order, or Sales Order in Oracle Order Management. Sales Agreements maintain their same name during both the Negotiation and Fulfillment phases.
Negotiation Flow - Generic with Approval is initiated if it is assigned to the transaction type. Transaction types determine which processes are attached to a Sales Order and Sales Agreements. For more information on defining transaction types, refer to the Oracle Order Management Implementation Manual.
Negotiation Flow - Generic with Approval is associated with the following OM Negotiation Header subprocesses:
Negotiation Flow - Generic with Approval is contained in the Seeded Data File oexwford.wft and is associated with the OM Negotiation Header item type.
To view the properties of the Negotiation Flow - Generic with Approval 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 Negotiation Flow - Generic with Approval 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 Negotiation Flow - Generic with Approval process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Negotiation Flow - Generic with Approval process.
Negotiation Flow - Generic with Approval Workflow
The 'Is AME Used for Approval' function checks if the Use Approvals Management Engine check box is selected in the Transaction Type window. If yes, then it goes to 'Internal Approval Negotiation – With AME' sub process. This sub process takes care of approvals from AME. If it is unchecked, then this function goes to 'Internal Approval – Negotiation' sub process as seen in the following diagram:
The following table provides descriptions of each activity in the Negotiation Flow - Generic with Approval Process.
For more information about individual function activities, see Seeded Function Activity Definitions.
Activity | Function | Result Type | Required |
---|---|---|---|
Start | WF_STANDARD.NOOP | None | Yes |
Negotiation Lost | OE_NEGOTIATE_WF.Update_Status_Lost | Null | Yes |
End | WF_STANDARD.NOOP | None | Yes |
The following section discusses the workflows associated with the OM Blanket Header item type.
The Blanket Flow - Generic workflow process is used for the Fulfillment phase of Sales Agreements in Oracle Order Management.
Blanket Flow - Generic is initiated if it is assigned to the transaction type for the Sales Agreement. Transaction types determine which processes are attached to a Sales Agreement. For more information on defining transaction types, refer to the Oracle Order Management Implementation Guide.
Blanket Flow - Generic is associated with the following OM Blanket Header subprocesses:
Blanket Flow - Generic is contained in the Seeded Data File oexford.wft and is associated with the OM Blanket Header item type.
For Sales Agreements, the Fulfillment flow will start either after the Negotiation Flow has completed or, in the case where the Sales Agreement does not have a Negotiation Flow, it will start when you save the Sales Agreement.
To view the properties of the Blanket Flow - Generic 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 Flow - Generic 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 Blanket Flow - Generic process, which comprise the nodes that appear in the workflow diagram. The following diagram depicts the Blanket Flow - Generic process.
Blanket Flow - Generic
The Order Status page enables you to initiate returns. However please note that Order Information Portal does not process orders or returns, only the notification to initiate a return can be carried out.
The Delivery page of Order Information Portal enables you to initiate returns through notifications to the salesperson. You can initiate a return by submitting a Defect Report and this notifies the salesperson to start processing the return. The returns processing can only be done using the Sales Orders window, not the Order Information Portal.
The oexwfcog.wft file contains the COGS Account Generator workflows. There are 2 seeded workflows – Standard Flexfield Workflow and Generate Cost of Goods Sold Account. The Standard Flexfield Workflow consists of generic functions that assist you in generating account numbers, not only COGS Accounts. The Generate Cost of Goods Sold Account flow is described below.
The Generate Cost of Goods Sold Account consists of 2 processes: Generate Account Using Flexbuilder Rules and Generate Default Account.
If you have upgraded from previous versions that were using the Flexbuilder tool, you can use the Flexbuilder rules. Please note that you need to perform some upgrade to use the Flexbuilder rules in the Generate Account Using Flexbuilder Rules process.
Activity | Function | Result Type | Required |
---|---|---|---|
Start generating Code Combination | FND_FIND_FLEX_COMBINATION | None | Yes |
Upgrade From Flexbuilder | UPGRADE_FLEX | Flexfield Result | Yes |
Validate Code Combination | FND_FLEX_VALIDATE_COMBINATION | None | Yes |
Abort generating Code Combination | FND_FLEX_ABORT_GENERATION | None | Yes |
End generating Code Combination | FND_FLEX_END_GENERATION | None | Yes |
Generate Default Account is a seeded process that builds the COGS Account. It retrieves all segments from the COGS Account assigned to the item in the shipping inventory organization. The Chart of Accounts (the accounting structure that defines the number of segments making up an account) calls this process. The Cost Of Goods Sold Account is identified by a CODE_COMBINATION_ID (CCID), having a unique combination of segment values.
Use the Properties menu option to check the Runnable box in order to assign this process to a Chart of Accounts.
Activity | Function | Result Type | Required |
---|---|---|---|
Start generating Code Combination | FND_FLEX_START_GENERATION | None | Yes |
Get CCID for a line | GET_ITEM_DERIVED | Flexfield Result | Yes |
Copy Values from Code Combination | FND_FLEX_COPY_FROM_COMB | None | Yes |
Validate Code Combination | FND_FLEX_VALIDATE_COMBINATION | None | Yes |
End generating Code Combination | FND_FLEX_END_GENERATION | None | Yes |
Abort generating Code Combination | FND_FLEX_ABORT_GENERATION | None | Yes |
For a listing of seeded function activity definitions, please refer to Listing of Seeded COGS Functions.