EAR9.1: ARUPDATE Reset Process Does Not Unlock PAYMENT Table
(Doc ID 1932577.1)
Last updated on DECEMBER 12, 2019
Applies to:
PeopleSoft Enterprise FIN Receivables - Version 9.1 to 9.1 [Release 9]Information in this document applies to any platform.
Symptoms
On : 9.1 version, AR Update - Reset process.
ACTUAL BEHAVIOR
---------------
If ARUPDATE job that is trying to post a payment group runs to No Success when running AR_POST1 process and the reset process is run for that abend, it does not unlock the process instance on the PAYMENT table.
EXPECTED BEHAVIOR
-----------------------
If reset process is updating tables like ITEM_ACTIVITY, PENDING_ITEM then it should reset PAYMENT table as well.
STEPS
-----------------------
The issue can be reproduced at will with the following steps:
- Put some bad code at step AR_POSTING.DIFF_INH.UPD_INH.
- Enter payment and run ARUPDATE.
- The ARUPDATE will fail at "AR_POSTING.DIFF_INH.UPD_INH".
- Now go to Receivable Update - reset process and reset the failed instance.
- Query PAYMENT table for the failed payment you will see PROCESS_INSTANCE is not set to 0. Query tables like PENDING_ITEM, DEPOSIT_CONTROL, GROUP_CONTROL resets PROCESS_INSTANCE to 0.
- Payment is not getting picked up by next ARUPDATE.
BUSINESS IMPACT
-----------------------
Payment is not getting picked up unless reset PROCESS_INSTANCE in PAYMENT table using SQL update.
Changes
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
| Symptoms |
| Changes |
| Cause |
| Solution |
| References |