EAR9.1: ARUPDATE Reset Process Does Not Unlock PAYMENT Table

(Doc ID 1932577.1)

Last updated on AUGUST 08, 2017

Applies to:

PeopleSoft Enterprise FIN Receivables - Version 9.1 to 9.1 [Release 9]
Information in this document applies to any platform.


On : 9.1 version, AR Update - Reset process.

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.

If reset process is updating tables like ITEM_ACTIVITY, PENDING_ITEM then it should reset PAYMENT table as well.

The issue can be reproduced at will with the following steps:

  1. Put some bad code at step AR_POSTING.DIFF_INH.UPD_INH.
  2. Enter payment and run ARUPDATE.
  3. The ARUPDATE will fail at "AR_POSTING.DIFF_INH.UPD_INH". 
  4. Now go to Receivable Update - reset process and reset the failed instance.
  5. 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.
  6. Payment is not getting picked up by next ARUPDATE.

Payment is not getting picked up unless reset PROCESS_INSTANCE in PAYMENT table using SQL update.


Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms