EAR 9.2: Payment Predictor Not Applying Item When #DTL_TLR if Customer Reference Business Unit Differs Item Business Unit (Doc ID 2792583.1)

Last updated on NOVEMBER 01, 2024

Applies to:

Symptoms

Payment Predictor is not generating the expected balanced Payment Worksheet for an Underpayment, where the difference between Item's Balance and Payment's Amount falls within the Tolerances defined (Amount and Percent) at the Predictor Detail Options. This seems to be the case when the Payment Predictor Method used is defined with an Algorithm of #DTL_TLR, but the Business Unit values differ between the Customer Information section, and the Detail References Item's Business Unit.

     - Invoice Tolerance Amount = 5 USD
     - Invoice Tolerance Percent = 2%
     - Item BU = US001
     - Item Balance = 100 USD
     - Deposit BU = US001
     - Payment Amount = 99 USD
     - PS_PAYMENT_ID_CUST.BUSINESS_UNIT = US005
     - PS_PAYMENT_ID_ITEM.BUSINESS_UNIT = US001

Having this difference between the Customer Information Business Unit value, and the Item's Business Unit (Detail References), the Step AR_PREDICT2.DTLRBODY.GENITMOI does not seem to be able to process the Payment/Item combination as per expected.

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 DTL_TLR using Algorithm #DTL_TLR
     4.- At the Receivables Options level, in the Payment Options tab, define the Payment Predictor Method DTL_TLR
     5.- At the Receivables Options level, in the Predictor Detail Options tab, define the below settings:
          a) Invoice Tolerance Amount = 5 USD
          b) Invoice Tolerance Percent = 2%
     6.- Create a Pending Group for the Customer, Business Unit US001, and define one Item for an amount of 100 USD. Continue by setting 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, under Deposit Unit US001, with one Payment for an amount of 99 USD, select the Payment Predictor flag, and in the Detail References link define the Item previously created, (PS_PAYMENT_ID_ITEM.BUSINESS_UNIT = US001). This will be an underpayment, where 1.00 USD is less than the 5 USD Tolerance Amount, as well as less than the 2% Percent Tolerance defined
     10.- At the Customer Information section, populate the Business Unit value to US005 (PS_PAYMENT_ID_CUST.BUSINESS_UNIT = US005)
     11.- Launch the Payment Predictor process for the Business Unit at hand (US001)
     12.- 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 it is not balanced, and the User still needs to review it
     13.- 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 by adding the new WAU Item Line for 1 USD difference

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 if the Payment Predictor Method uses an Algorithm of #DTL_TLR, the Customer Identified and alike information would not matter in the calculations of the AE Program to perform the needed matches. As such, it should generate a balanced Payment Worksheet, and Post Action should be Batch Standard.

Changes

Cause

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