My Oracle Support Banner

EAR 9.2: Payment Predictor Algorithm #DTL_TLR Does not Populate Record Field PS_PENDING_ITEM.PAYMENT_AMT, and Therefore also PS_ITEM_ACTIVITY.PAYMENT_AMT for Earned Discount Rows (Doc ID 2721307.1)

Last updated on OCTOBER 21, 2020

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, and as such, the Payment Predictor Method is defined with Algorithm #DTL_TLR.

However, when Payment Predictor generates a new Payment Worksheet matching an outstanding Invoice, with an existing Payment, and calculating/applying the Earned Discount into the formula, it sets the Record Field PS_PENDING_ITEM.PAYMENT_AMT Field as blank for the Deduction/Discount rows (ENTRY_TYPE = 'DE'). As such, when AR Update posts the Payment Group in question, this very same blank value gets filtered into Record Field PS_ITEM_ACTIVITY.PAYMENT_AMT.

This does not happen if the Payment Worksheet, and the resulting Payment Group, is created manually online by a User building the Worksheet, and selecting the Item in question.

A similar issue was raised, and fixed through <Bug 20889947> (AR: PAYMENT_AMT IS NOT POPULATED FOR EARNED DISCOUNT WHEN #REFS IS USED), and whose solution was delivered within PeopleSoft Enterprise FSCM 9.1 FIN Bundle #35. Seems that a fix in FSCM 9.2 Application Release is still missing for Algorithm #DTL_TLR.

REPLICATION STEPS:

    1.- Log into the FSCM Online Application as a Receivables User
    2.- Define a Customer with Payments Terms stating that the Invoices are due after 30 days, but if paid within the first 10 days, a discount of 2% would be applied (Payment Terms = 21030), and ensure the Partial Payment Switch is selected
    3.- Define a Payment Predictor Method using Algorithms #REFS and #DTL_TLR
    4.- Set up that Payment Predictor Method at the Receivables Business Unit Options, as well as configure the Predictor Detail Options to have:
        a) Tolerance
        b) Discount
    5.- Create a Pending Item Group for the Customer for an amount of 100 USD, and set it to Post Action Batch Standard
    6.- Run AR Update for the Business Unit value used, and Pending Items flag selected
    7.- Ensure that the Item has been posted against the Customer's Account, and calculated a Discount of 2 USD
    8.- Create a new Regular Deposit, with one Payment for an amount of 98 USD, and link it to the Customer ID, Business Unit, Invoice in question, and ensure the Payment Predictor flag is selected
    9.- Launch the Payment Predictor process for the Business Unit at hand
    10.- Confirm that the system has created a Payment Worksheet, it is balanced, and placed into Post Action Batch Standard
    11.- Run AR Update for the Business Unit value used, and Payments flag selected
    12.- Check the Item's Activity for the Payment Group generated, and confirm that under the Display of 'Payment Amount', the Deduction row has a 0 USD value in the Payment Amount column

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.

The Payment Predictor process is not generating the needed Payment Worksheet information, so Record Fields PS_PENDING_ITEM.PAYMENT_AMT and PS_ITEM_ACTIVITY.PAYMENT_AMT remains blank for Entry Type Deduction rows, (ENTRY_TYPE = DE). This is inconsistent with how online manually created Payment Worksheets get created.

The expectation is that Payment Predictor should create the new Payment Worksheet with all needed Payment information, so that when AR Update processes the new Payment Group, the Record Fields PS_PENDING_ITEM.PAYMENT_AMT and PS_ITEM_ACTIVITY.PAYMENT_AMT should be populated with the correct amount for the Entry Type Deduction row, (ENTRY_TYPE = DE).

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.