My Oracle Support Banner

EAR: Partial Unpost Of A Payment From A Regular Deposit With Multiple Payments, Leaves It As Incomplete, With Non-Touched Payments As Not Posted And Incorrect Posted Amount And Posted Count (Doc ID 2619250.1)

Last updated on APRIL 09, 2024

Applies to:

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

Symptoms


A problem has been detected when using the Partial Unpost feature in Accounts Receivable, when a Payment, pertaining to a Regular Deposit with multiple Payments that have been fully processed, gets partially unposted. Upon processing AR Update, the Unpost Payment Group gets properly matched at the Item Activities of all Invoices involved, with correct Amounts balanced, and Accounting Entries generated. However, the previously completed Regular Deposit gets set to a Deposit Status of 'Partially Applied' (PS_DEPOSIT_CONTROL.DEPOSIT_STATUS = 'P'), and the Posted Total Amount, and Posted Count gets incorrectly calculated, displaying only the values of the Unpost Group recently processed, but no longer taking into consideration the values of the remainder Payments within the Regular Deposit that were not touched.

REPLICATION STEPS:

    1.- Log into the FSCM Online Application as a Receivables User
    2.- Create a new Pending Item Group with 3 new Invoices (Item IDs IT-0001, IT-0002, and IT-0003) for Business Unit US001, Customer ID 1003, and Amounts of 100 USD, 150 USD, and 250 USD
    3.- Set the Pending Item Group to a Post Action of Batch Standard
    4.- Launch AR Update for Business Unit US001 with the Pending Items flag selected
    5.- Proceed to create a new Regular Deposit, with two Payments (Payment IDs PY-0001, and PY-0002), having amounts of 30 USD, and 70 USD, and each making reference to Item IDs IT-0001 and IT-0002 respectively
    6.- Build a Payment Worksheet for the first Payment ID PY-0001, balance it for an amount of 30 USD against Item ID IT-0001, and set the Payment Worksheet to a Post Action of Batch Standard
    7.- Build a Payment Worksheet for the second Payment ID PY-0002, balance it for an amount of 70 USD against Item ID IT-0002, and set the Payment Worksheet to a Post Action of Batch Standard
    8.- Launch AR Update for Business Unit US001 with the Payments flag selected
    9.- Confirm that Item IDs IT-0001 and IT-0002 have been partially paid for amounts of 30 USD and 70 USD respectively
    10.- Noticing that Payment ID PY-0001 was wrongly applied to Item ID IT-0001 instead of IT-0003, proceed to perform a Partial Unpost of the Payment ID PY-0001, placing all amount of 30 USD from IT-0001 to IT-0003, and set the new Unpost Group to a Post Action of Batch Standard
    11.- Launch AR Update for Business Unit US001 with the Payments, and Unpost Transactions flags selected
    12.- ISSUE #1: Check the Regular Deposit in question, and in the Totals tab, confirm that Posted Total Amount and Posted Count only reflect the figures of the latest Unpost Group, and no longer include the values from Payment ID PY-0002 which was left untouched, and was still posted against Item ID IT-0002
    13.- ISSUE #2: Check the Incomplete Deposits search page, to see listed the Regular Deposit at hand, with reference to Payment ID PY-0002 for an amount yet to be posted of 70 USD, which is incorrect

To gather more information concerning this scenario and its related problem, refer to the available Replication Steps Word Document here linked containing the complete configuration and the replication steps necessary to reproduce the issue.

Regular Deposits that have all their Payments completely processed, and posted, with proper Accounting Entries generated on all involved Items, are still being marked as 'Partially Applied', and incomplete. There is no way to fix this anymore, as the Payment Groups from all defined Payment transactions are fully processed.

The Posted Total Amount and Posted Count fields from a Regular Deposit need to truly reflect the values of all related Payments being posted, including those left untouched after a Partial Unpost of one of the Payments at hand.

NOTE: In the attached document, user details / company name / address / email / telephone number represent a fictitious sample (based upon made up data used in the Oracle Demo Vision instance). Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

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


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