Troubleshooting

Expected Errors

There are two error types that can occur in order and line flows: unexpected errors and expected errors. Expected errors are errors that business processes anticipate. For example, booking requires that a customer is specified on the order. If you attempt to book an order that does not specify a customer, the order will not book. The Book activity will end with a result of Incomplete.

Other examples of expected errors include the following:

To anticipate these errors, activities are set to end with a ON_HOLD result if it cannot complete because of a hold, or end with an INCOMPLETE result. The flow must then transition to a block (which can be completed from the Sales Order window) or to a wait activity.

For example, the invoicing activity finds a hold on a line. The activity posts a message indicating the line is on hold and then completes to the Wait activity with an ON_HOLD result. The Wait activity is set to wait for a response for eight hours. After eight hours it transitions back to the invoicing activity.

As another example, the booking activity finds a hold on an order. The activity posts a message indicating that the order is on hold and then completes to the booking eligibility block with an ON_HOLD result.

When an activity is completed via the Sales Order window, the Processing Messages window appears to display messages that indicate errors.

When an activity is process by the Background Engine (the activity is deferred), error messages are stored in the Oracle Order Management processing message table. View these messages via the Processing Message window using the concurrent program request number, the workflow activity, and/or order or line basis.

Repricing Errors

You can still reprice an order line if Reprice - Line encounters an expected error, such as an invalid repricing event or pricing engine failure to locate a price list. Complete the following steps to reprice a line that failed the Reprice activity:

  1. Navigate to the Sales Order Process Messages window to view the error condition.

  2. Correct the error condition.

  3. Navigate to the Sales Order window and query the order where the repricing error occurred.

  4. Select the Lines tab and locate the line with the repricing error.

  5. Select the line, select Actions, and then select Progress Order.

  6. Select Reprice Eligible from the menu to reprice the line again.

  7. Repeat Steps 1 through 6 until the error is resolved.

  8. Save your work.

Errors Viewing Workflow Status From Within Oracle Order Management

If you encounter an error when trying to view workflow processes from within Oracle Order Management, your Oracle Workflow setup or your browser setup on your computer could be incorrect. For more information about workflow viewing problems from within Oracle Applications, refer to the Oracle Workflow User's Guide.

Unexpected Errors

Unexpected errors are those that an Oracle Order Management function activity does not anticipate. Causes of unexpected errors can include the following:

To avoid unexpected errors, specify an error process when defining function activities and processes. All seeded Oracle Order Management function activities and process have a specified error process.

The default error process, Retry Only, is a seeded Oracle Workflow error process. The activity that encountered an unexpected error is marked with an Error status (in WF_ITEM_ACTIVITY_STATUSES) and a notification listing the error details is sent to the role specified in the OM Workflow Administrator item attribute. The Role item attribute WF_ADMINISTRATOR is defined for the header and line work item, and is set as SYSADMIN. The error process sends notifications about the error to this role.

Once the problems have been corrected, the administrator can select the Retry option on the notification and complete it. This initiates a retry of the activity in error. The administrator can also opt to retry the activity from the Workflow Monitor.

For more information on setting the OM Workflow Administrator item attribute, refer to Assigning Workflows to Transaction Types.

Workflow Validation

Sometimes customizations and modifications can bring in exceptions that cause data corruption and degrade performance. In order to ensure that a workflow process does not error out at run-time , you can use the Order Management workflow validation feature to validate the workflow process before it is actually used. Order Management workflow validation provides additional validation over and above the basic validation performed by the Oracle Workflow Builder. In Order Management, you can validate workflow processes in the Transaction Types window.

While saving your transaction type definition, implied or mandatory validation takes places for most workflow processes. However if you need to validate a specific workflow process, you can use one of the following three options:

the picture is described in the document text

For more information on the Workflow Validation functionality and a list of errors and warnings generated by Workflow Validation, please refer to the Workflow Validation section in the Oracle Order Management Implementation Manual.

Exception Management

The Retry Activities in Error concurrent program retries failed workflow activities across multiple transactions using the Standard Request Submission (SRS) window. The concurrent program expands the ability of Order Management functional users to recover gracefully from unexpected errors that result in stuck transactions and typically require data fixes to be able to progress the transactions. You can retry activities in batch rather than individually. The following workflow item types are supported in the retry activity:

If you enter an Order Number, then the header flow and all failed line flows are retried. All other parameter values are ignored. Since Item Type is mandatory, it is defaulted to order header. The Order Number parameter displays order numbers across operating units.

When the Ship Line workflow activity errors out, at least one corresponding delivery detail is closed since the line was shipped. In this case, retrying the activity via the existing Exception Management functionality will always fail. When Exception Management encounters this situation, the workflow activity is set to Notified instead of being retried.