My Oracle Support Banner

EAR 9.2: Payment Predictor Not Using Partial Payment Switch if Tolerance Amount Is Met but Tolerance Percent Is Exceeded (Doc ID 2792246.1)

Last updated on JULY 16, 2021

Applies to:

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

Symptoms

The Business is trying to use Payment Predictor functionality to generate Payment Worksheets that match existing Payments with outstanding Invoices from customers. As such, the Payment Predictor Algorithm #DTL_TLR has been defined at the Method level, and at the Receivables Options level, Tolerances have been defined for Invoice Amount and Invoice Percentage. At the Customer's Bill To Options level as well, the 'Partial Payment Switch' checkbox has been selected.

    - Invoice Tolerance Amount = 10 USD
    - Invoice Tolerance Percent = 3%

As such, for any underpayments, Payment Predictor looks at the Tolerances defined, and if it is greater than the Tolerance, then a partial payment is applied, and if it is lesser than the Tolerances, the system performs a Write-off an Underpayment (WAU).

A problem though has been detected with Payment Predictor when the Item Balance minus the Payment Amount is less than 10 USD, but exceeds the 3% Percent Tolerance. Then, the Payment Predictor only creates a Payment Worksheet, which will need to be reviewed, and manually acted by a User, bypassing the Partial Payment Switch logic.

REPLICATION STEPS:

    1.- Log into the FSCM Online Application as a Receivables User
    2.- Go to the Customer set up component, navigate to the Bill To Options tab, and ensure that the 'Partial Payment Switch' is selected, and the Payment Predictor Method is left blank
    3.- Define a Payment Predictor Method ABC using Algorithm #DTL_TLR
    4.- At the Receivables Options level, in the Payment Options tab, define the Payment Predictor Method ABC
    5.- At the Receivables Options level, in the Predictor Detail Options tab, define the below settings:
           a) Invoice Tolerance Amount = 10 USD
           b) Invoice Tolerance Percent = 3%
    6.- Create a Pending Group for the Customer, and define one Item for an amount of 100 USD, and set it to Post Action Batch Standard
    7.- Run AR Update for the Business Unit value used, and Pending Items flag selected
    8.- Ensure that the Item has been posted against the Customer's Account
    9.- Create a new Regular Deposit, with one Payment for an amount of 96 USD, select the Payment Predictor flag, and in the Detail References link define the Item previously created. This will be an underpayment, where 4.00 USD is less than the 10 USD Tolerance Amount, but exceeds the 3# Percent Tolerance
    10.- Launch the Payment Predictor process for the Business Unit at hand
    11.- Confirm that the process completed successfully, and when checking the Message Log of the APR_PP1 AE Program, note that the system has created a Payment Worksheet, but the User still needs to review it
    12.- Open the Payment Worksheet, and see the Item listed, but the Worksheet is still unbalanced due to remaining amount left. User needs to perform all the tasks manually online for a partial payment

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

Users need to manually open the generated Payment Worksheet, and perform all the tasks online, which is time consuming, and not efficient.

PeopleBooks is clear enough, stating that Payment Predictor will always use the 'Partial Payment Switch' flag to perform partial payments, and leave the matched Item in Open Status, with a remainder leftover amount, should the difference of the underpayment exceed the defined Tolerances. While only the Percent Tolerance is exceeded in this scenario, the outcome should still be the same, partial payment applied, and ready for posting by AR Update.

NOTE: In the images/screenshots/examples mentioned and/or 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.