O2A Order Fallout Scenario Clarification (Doc ID 2018784.1)

Last updated on NOVEMBER 17, 2023

Applies to:

Goal

The following is a Clarification of the behavior of O2A PIP during order fallout.

Basic understanding:

1) A business fallout happened in a downstream system
2) OSM-COM detected the fault via AIA.
3) OSM-COM creates Trouble Ticket in CRM and receives TT-id in acknowledgement.
4) Order status in OSM will remain in-progress but in CRM order status should be changed to FAILED.
5) CRM can submit a revision order on the FAILED order for recovery of the fallout scenario.


In OSM, During a business fallout, O2A receives the OrderFalloutNotification from AIA and the recognition rule recognizes it.
“exists(../falloutxmlns:OrderFalloutNotification)"

As per the document -a typical flow path of SIFalloutProcess :

1)Get fulfillment order (search sales order correlated to this message)
2) Trigger transition of fulfillment order process into fallout recovery state (wait)
3) Send FAILED Status Update to Siebel.
4) Send trouble ticket to Siebel
5) Abort the sales order if a second fallout is detected during a revision

When tested in an integrated environment (CRM - AIA - OSM - BRM), and if we simulate a business fallout from BRM, we observe, TT is created in CRM , but order status not getting changed to FAILED in siebel.

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.