Last updated on AUGUST 26, 2016
Applies to:Oracle iProcurement - Version 188.8.131.52 to 12.1 [Release 11.5 to 12.1]
Oracle Inventory Management - Version 184.108.40.206 to 12.1.3 [Release 11.5.10 to 12.1]
Information in this document applies to any platform.
Correction transaction from iProcurement intermittently does not perform correction against both deliver and receive transactions. This causes receiving quantity/amount details to show differently in iProcurement versus the Receiving Transaction Summary form.
When correction transactions are performed in iProcurement, sometimes only one part of the correction completes. The iProcurement correction should perform a correction against both deliver and receive transactions for a direct delivery receipt. If correction against the deliver succeeds but correction against the receive fails this causes data corruption. The data shown in iProcurement is confusing and different from data shown in Core Apps Receiving (Core correctly shows the data).
Steps To Reproduce
Although it is not known exactly how to reproduce this intermittent issue in iProcurement, the resulting data confusion can be seen intermittently in iProcurement after performing the following steps:
1. Create Receipt in iProcurement (always Direct Delivery)
2. Query Receipt
3. Perform partial negative Correction (somehow the correction completes for the Deliver transaction, but fails for the Receive transaction)
4. Check Receiving details in iProcurement...there is no visibility that only one part of the Receipt was Corrected
5. Check Receiving details in Core Apps Purchasing Receiving and see sometimes that the correction was only successful for the Deliver transaction.
If a positive Correction is performed, Correction against Receive is inserted into rcv_transactions_interface, then Correction against Deliver is inserted into rcv_transactions_interface. If a negative Correction is performed, Correction against Deliver is inserted into rcv_transactions_interface, then Correction against Receive is inserted into rcv_transactions_interface. Even if the first transaction completes successfully the second may fail. It is not possible for Receiving software to prevent the second transaction from failing prior to implementing the fix for this issue.
Core apps receiving does not allow correction of Amount based items, so if this issue occurs for an Amount based item the only solution for the customer is to obtain a DATAFIX. If iProcurement modifies the code to use group id, the correction can get rolled back if either the DELIVER correction or the RECEIVE correction does not complete. Then the user would be allowed to retry the correction from iProcurement. The core apps receiving team would still be responsible for identifying the root cause when a reproducible test case can be provided to capture additional debug data. But in the meantime, the fix from iProcurement would prevent the data corruption and reduce the impact on customers.
OTHER COMMON SYMPTOMS
Output of Receiving data collection script may show the following:
In RCV_TRANSACTIONS table there may be a CORRECT Transaction_Type
In RCV_TRANSACTIONS_INTERFACE table there may be a record stuck with
There may still be RECEIVING Supply in MTL_SUPPLY and RCV_SUPPLY tables
When PO Line is Quantity based, User can be given access to Core form to perform the transaction that did not process. But, Amount based Purchase Orders cannot be transacted from Core forms, so User must use Receiving Open Interface functionality. The customer technical staff would need to compose a sql script to insert records into rcv_transactions_interface.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms