Troubleshooting the Order Orchestration Integration

See the Order Orchestration Web Services Guide on https://support.oracle.com (ID 2953017.1) for information on possible errors returned by Order Orchestration and additional troubleshooting information.

See also:

Credit card authorization reversals: Authorization reversals take place when the Order Orchestration status is:

C (Closed): The request was canceled before submission to Order Orchestration.
E (Error): Order Orchestration returned an error response.
J (Rejected): The order was rejected by the pickup location. Reversal takes place only for a pickup order.
U (Unfulfillable): Order Orchestration cannot fulfill the order or line.
Y (Pending Cancel): A request to cancel the order or line has been sent to Order Orchestration.
Z (Canceled): Order Orchestration has confirmed that the order or line was canceled.

For more information:

See Order Orchestration Status Summary Table for more information on Order Orchestration statuses.
Use the Order Broker Lines option at the Batch Job Statistics page in Modern View to check the total number of Order Broker lines in the currently selected company, broken out by current status.

Problem	Possible Explanation
No fulfilling location is displayed at the Work with Order Broker Screen	Is the Order Orchestration request’s status E (error), U (unfulfillable), C (Closed) or Z (canceled)? In this case, the order line will not be fulfilled through Order Orchestration.
The status of the Order Orchestration request is Closed, but there have not been any shipments	Order Administration changes the status of a brokered backorder request to C (closed) if you cancel it before it has been submitted to Order Orchestration (when its status is R (ready)).
A backordered order line is not being submitted to Order Orchestration for fulfillment	Check that the order is eligible under the Rules for Submitting Backorders to Order Orchestration Confirm that you have completed the Order Orchestration Configuration Confirm that the customer is not flagged to Bypass reservation Confirm that the item has the OROB eligible flag selected If the order was previously in held status and then released, use the BROKER periodic function or select the order for maintenance and then accept your maintenance session
I created a ship-for-pickup order, but it is not listed at the Work with Order Broker Screen or on the Order Inquiry screen in Order Orchestration	If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER, Order Administration does not send ship-for-pickup orders to Order Orchestration until you generate the pick slip. See Ship-for-Pickup Orders for an overview.
Order Orchestration returned an error	The error is displayed at the Display Order Broker History Screen. An error of `Null response from OROB` indicates that the OROB Account (K49) system control value is not set correctly. An error of `Invalid Sold To address, missing req` indicates that the sold-to customer is missing the first and last name or the company name; a first and last name or a company name are required for the sold-to customer on all orders sent to Order Orchestration. An error of `Duplicate Order/line` (code 2040) indicates that the order or line was already created in Order Orchestration. This situation can occur if the Use Duplicate Order Checking option is selected in Order Orchestration and the order or line was already created there, but for some reason Order Administration did not receive or process the original response message. In this case, Order Administration puts the Order Orchestration record’s status to Acknowledged, and the order line continues processing normally. See the Order Orchestration Web Services Guide on My Oracle Support (ID 2953017.1) for a list of possible errors that Order Orchestration might return to a Submit Order request.
Will there be Order Orchestration records in error if the Order Orchestration application is not running?	If Order Administration includes orders in a status inquiry list request and does not receive a response from Order Orchestration, the Order Orchestration records remain in their current status.
Where are messages logged between Order Administration and Order Orchestration?	If specified in the XML Logging setting at the Event Logging screen in Order Orchestration, Order Orchestration logs the messages.
Retail pickup and delivery orders not created in Order Administration	If the Send Inventory by Warehouse to OROB (L06) system control value is selected, Order Administration does not send fulfillments requests to Order Orchestration unless an OROB location is specified for the warehouse.
Ship-for-pickup orders are not created	An OROB_MESSAGE_VERSION of 16.0 or higher is required to use the Ship-for-Pickup Orders integration with Order Orchestration. Note that this property cannot be set higher than 19.9 for integration with Order Broker 19.x, or higher than 21.1 for integration with Order Orchestration 22.2.301.0 or higher.
Status updates are not generated when ship-for-pickup orders are in transit	The Order Type for Retail Pickup Orders Brokered to OROMS (K92) and Order Type for Orders Brokered for Delivery (K91) system control values must be populated to generate the status update message when a ship-for-pickup order is in transit.
Order initially created in Order Administration in error status, then put on hold after error corrected	Canceled by originating system? If an order is initially created in Order Administration in error status and then corrected, Order Administration sends an inquiry request to Order Orchestration before changing the order’s status to open. If the response from Order Orchestration indicates that the originating system has canceled the order, Order Administration then puts the order on hold and writes an order transaction history message, such as: Order held - line[s] canceled in Order B.
Tax is not calculated correctly for the invoice on a fulfilling order, while it is calculated correctly on the originating order	Select the Tax on Freight (B14) system control value if this issue occurs.
Multiple invoices are created for the lines on a single order that was fulfilled on the same day	The invoice is consolidated for order lines that were previously in the same status and confirmed as fulfilled in the same status inquiry response from Order Orchestration, even if your company is not configured to consolidate invoices. Example: A line on the order is set to fulfilled in Order Orchestration at 9:00, and the other line at 9:02: The two shipments create a single invoice if they are returned in the same status inquiry response. The two shipments create two separate invoices if Order Administration receives the update on the second line in a separate status inquiry response. NOTE: In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date. If the Invoice Ship For Pickup Order Once Intransit (M73) system control value is selected, the invoice is created after the status inquiry response indicates a ship-for-pickup order is in transit or received, as well as fulfilled.
An order received from Order Orchestration is created in error status because the Price Override Limit Percent (E55) was exceeded	This situation can occur if the order includes a free or low-priced item, such as through a BOGO promotion. A possible solution to prevent this error is to set the Order Broker Price Override (K95) to a price override reason code whose Override item offer price flag is selected.
Delivery orders are in G (Resend Fulfilled) status, or ship-for-pickup orders are in H (Resend Intransit) status	Orders can be in these statuses if the order status update request message, generated to set their statuses to Complete (delivery order) or Intransit (ship-for-pickup order), did not receive a response from Order Orchestration. This might occur if, for example, message authentication failed or communication is down. In this case, the BROKER_ORD job resends the request the next time it runs.

Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration

Checking status in pick slip generation: A retail pickup or delivery order is put on AU (Broker Order Under Review) hold when:

Pick slip generation sends a status list request to Order Orchestration, and
The response message indicates that the order is under review.

Checking if under review through the BROKER process: When the BROKER integration layer process sends the status list request to Order Orchestration and receives a response indicating that an order is not under review, it removes the AU hold, if any, on the order. However, if the response from Order Orchestration indicates that the order is now canceled, the order is put on hold using the Order Broker Hold Reason (Cancel) (L02). If that system control value is blank, the order remains on AU hold.

Note:

If there are other holds on the order, they are not automatically removed.

When an originating order is put on AR hold: When both an originating and fulfilling order exist, the holds applied work as follows:

A ship-for-pickup order or brokered backorder that originated in Order Administration was assigned by Order Orchestration to Order Administration for fulfillment, and Order Administration created a new fulfilling order.
The originating order’s initial authorization expired.
The attempt to reauthorize the originating order through the REAUTH periodic function failed, and the originating order was put on AR hold.

In this case, the system:

Applies the AU hold reason to the fulfilling order.
Voids any pending pick slips that have expired authorizations. Also, writes an order transaction history record such as: Pick #### voided due to expired auth.
Writes an order transaction history message such as SYS-HLD - BROKER ORDER UNDER REVIEW, where BROKER ORDER UNDER REVIEW is the description of the hold reason code.
If the Generic Pick Out API is in use, generates a trigger for a CWPickout message indicating that the pick slip was voided.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Note:

Drop ship pick slips or purchase orders, including those fulfilled through supplier direct fulfillment in Order Orchestration, are not updated when the reauthorization fails. You need to monitor these orders separately.

If the reauthorization is declined after shipment through the fulfilling order: It is possible, based on the timing of the REAUTH job and billing, that the REAUTH job can attempt to reauthorize the originating order after the fulfilling order has made the shipment. In this case, the system still sends the order update to Order Orchestration indicating to put the order under review, even though the order may already be closed in Order Orchestration. If the order is already closed, no additional automatic updates take place.

Releasing Orders from AR or AU Holds

Restrictions: Orders on AR (Declined Credit Card Authorization) or AU (Broker Order Under Review) system holds can only be released under the following conditions:

AR: You cannot release an order on AR system hold unless the order has a valid authorization for the balance of the order. Otherwise, you can cancel the order.
AU: You cannot release an order on AU hold through a screen in Classic or Modern View. Instead, based on the response received from Order Orchestration through the BROKER integration layer process, the AU hold is removed automatically if the response indicates that the order is no longer under review. Also, the order can be canceled based on the response received through the BROKER process.