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 WAO-WAU Rows (Doc ID 2781326.1)

Last updated on JUNE 02, 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, and as such, the Payment Predictor Method is defined with Algorithm #DTL_TLR. Having applied the fix from <Bug 31663684> (AR: 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), inconsistencies are being detected when reviewing the Item Activity by Payment view (Page ITEM_PAYMENT), when Overpayments, and Underpayments have been tested.

When selecting the 'Display Amount Switch' option of 'Payment Amount' at the Item Activity From Payment page (ITEM_PAYMENT), the below was detected:

  1) The Item Activity Line Type of PY (Payment) displays an amount different than the Payment Amount (Record Fields PS_PENDING_ITEM.PAYMENT_AMT, and PS_ITEM_ACTIVITY.PAYMENT_AMT are set to a different value than PS_PAYMENT.PAYMENT_AMT)
  2) The Item Activity Line Type WAU (Case of an Underpayment) displays an amount of 0.00 (Record Fields PS_PENDING_ITEM.PAYMENT_AMT, and PS_ITEM_ACTIVITY.PAYMENT_AMT are set to 0)
  3) The Item Activity Line Type WAO (Case of an Overpayment) displays an amount of 0.00 (Record Fields PS_PENDING_ITEM.PAYMENT_AMT, and PS_ITEM_ACTIVITY.PAYMENT_AMT are set to 0)

When Payment Predictor is launched, it generates a new Payment Worksheet matching an outstanding Invoice, with an existing Payment, and calculating/applying the Earned Discount into the formula, taking into consideration any Underpayment, or Overpayment, but then setting the Record Field PS_PENDING_ITEM.PAYMENT_AMT Field as blank for the Write-off An Underpayment/Overpayment rows (ENTRY_TYPE = 'WAU' or 'WAO'). 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.

The Payment row, (ENTRY_TYPE = 'PY'), is also containing a Payment Amount value that differs from the original Regular Deposit Payment transaction, (Record Field PS_PAYMENT.PAYMENT_AMT).

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 Group for the Customer, and define 2 Items (A and B), each 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 Items have been posted against the Customer's Account, and calculated a Discount of 2 USD
  8.- Create a first new Regular Deposit, with one Payment for an amount of 97 USD, and link it to the Customer ID, Business Unit, and one of the Invoices (Item A) in question, and ensure the Payment Predictor flag is selected (Scenario for an UNDERPAYMENT)
  9.- Create a second new Regular Deposit, with one Payment for an amount of 99 USD, and link it to the Customer ID, Business Unit, and one of the Invoices (Item B) in question, and ensure the Payment Predictor flag is selected (Scenario for an OVERPAYMENT)
  10.- Launch the Payment Predictor process for the Business Unit at hand
  11.- Confirm that the system has created two Payment Worksheets, that they are both balanced, and manually place them into Post Action Batch Standard
  12.- Run AR Update for the Business Unit value used, and Payments flag selected
  13.- Check the Item's Activity for the Payment Groups generated, and confirm that under the Display of 'Payment Amount', the Write-off An Underpayment (WAU), as well as Write-off An Overpayment (WAO) rows have a 0 USD value in the Payment Amount column
  14.- At the same time, confirm that the Payment line (PY) is having a Payment Amount of 98 USD on both scenarios (Underpayment, and Overpayment), while the Payment Amounts were 97 USD and 99 USD respectively

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 remain blank for Entry Type Write-off An Underpayment (WAU), and Write-off An Overpayment (WAO) rows, as well as the Payment row containing an incorrect value.

The expectation is that Payment Predictor should create the new Payment Worksheet with all needed Payment information on any Underpayment or Overpayment scenarios, 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 all Entry Type rows, (ENTRY_TYPE = 'WAO', 'WAU', and 'PY').

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.