Understanding Payment Predictor Processing

The Payment Predictor Application Engine process (ARPREDCT) is the automatic cash application process in PeopleSoft Receivables. It provides an alternative to applying payments using an express deposit or payment worksheet. Think of Payment Predictor as an automated version of the payment worksheet, which is used to match payments manually to open items or to create adjustments or write-offs for overpayments and underpayments. The items, which have a payment method of cash, check, credit card, electronic file transfer, or giro - EFT, qualify for Payment Predictor processing. The ones with direct debit and draft payment methods are processed by other processes.

This topic discusses:

  • Payment Predictor process flow.

  • Algorithms and methods.

  • Payment Predictor and multicurrency processing.

  • Item-level adjustments and reference values.

  • Payment Predictor multiprocess job.

Payment Predictor processes payments in stages. Before you run the Payment Predictor process, you must establish a hierarchy for processing business units, customers, deposits, and payments. You must also decide which customers or payments to exclude from Payment Predictor.

The source of payments does not matter when you use Payment Predictor. Payments can be online payments that are entered in a regular or express deposit, or they can enter the system through an electronic interface, such as electronic data interchange (EDI), bank statement reconciliation, a lockbox interface, the cash drawer receipts interface (CDR_LOADPMT), or the Excel Upload Payment process (AR_EDIT_UPLOADED_PAY_INFO).

Each payment must have a Magnetic Ink Character Recognition (MICR ID), customer ID, or some other type of reference information. The system uses the reference information to match payments to customers.

Payment Predictor first looks for the MICR ID. If it finds a valid MICR ID, it moves on to the next stage. If it does not find a valid MICR ID, it then looks for a customer ID with a business unit. If it does not find a valid customer ID with a business unit, then it looks for a customer ID without a business unit and uses the deposit business unit to determine which SetID should identify the customer and the remit from customer.

After Payment Predictor finds and validates the reference information, it stores the results in temporary tables. The temporary tables are used to identify which payment processing method the system uses.

When you set up Payment Predictor, you create a payment predictor method that includes a detailed set of instructions for applying payments. The method also includes instructions for handling payments that cannot be applied, such as placing the payment on the customer's account, generating a payment worksheet so that the payment can be manually applied, or releasing the payment.

After Payment Predictor has completed every step in the method, it moves the payment information from the temporary tables to the application tables.

Note: If the only reference information is the deposit business unit, you can direct Payment Predictor to apply the payment to a control customer. To do so, create a payment predictor method that contains a step without an identified customer identity and without an instruction to generate an item for a control customer. Assign this method to the deposit business unit.

This flowchart illustrates the Payment Predictor process flow. Starting with the identification of the reference information (MICR ID, customer ID, and more), the Payment Predictor process stores this information to temporary tables, which are used to identify the payment processing method. After Payment Predictor processes the method's steps, it moves the payment information to the application tables.

Payment Predictor process flow: Starting with the identification of the reference information, the Payment Predictor process stores the reference information to temporary tables, which are used to identify the payment processing method. After Payment Predictor processes the method's steps, it moves the payment information to the application tables

 Payment Predictor process flow

Before you use Payment Predictor, you must establish exactly what you want it to do. How will you handle overpayments and underpayments? Should complex payments be reviewed before posting? You use algorithms and methods to tell Payment Predictor what kind of payment situations to expect and how to handle each one.

Algorithms are SQL statements that match payments with open items according to the criteria that you specify. Algorithm groups are collections of related algorithms. For example, the algorithm group PASTDUE includes two algorithms: PASTGR for all past due items without a discount and PASTNET for past due items with a discount.

Methods are a series of steps that are performed conditionally based on remittance information. Methods reference one or more algorithm groups.

The Payment Predictor algorithms use SQL to define how to match payments with open items. The program's flexibility means that the required setup generally needs the attention of the technical members of your project team who are fluent in SQL, especially for changes to algorithms. For method setup, the more technical members of the project team require input from the team members who are familiar with your customers' remittance patterns and exception processing procedures.

Payment Predictor applies payments even if the currency for the item and the currency for the payment are different. When more than one currency is involved in a payment, Payment Predictor looks at:

  • The payment currency (PAYMENT.PAYMENT_CURRENCY).

  • The base currency of the deposit business unit (PAYMENT.CURRENCY_CD).

  • The item currency (ITEM.BAL_CURRENCY).

  • The base currency of the item business unit (ITEM.CURRENCY_CD).

If the currencies are different, the process places the rows that have different currencies in the Payment Predictor Multicurrency Conversion table (PS_PP_MULTC_TAO). It converts the item amount to the currency for the payment using the exchange rate on the payment date to do the conversion.

Payment balancing is performed in the payment currency. The PAY_AMT field in the PS_PP_ITEM_TAO table contains the item amount in the payment currency. When a step in a payment predictor method generates an item to balance a payment, the Payment Predictor process uses exchange rate information for the payment and creates the item in the payment currency.

Realized Gain and Loss

The system calculates a gain or loss if a difference exists between the item amount in the base currency for the business unit of the item on the accounting and payment dates for the item.

If a discount has a gain or loss amount, the amount is included in the realized gain and loss calculation for the item.

Payment-Level Adjustments

When you use the #REFS algorithm group and one payment in a deposit pays for multiple items, then Payment Predictor creates one adjustment entry at the payment level instead of the item level. For example, if a payment pays for two items, Payment Predictor looks at the sum of both items and the payment amount. It uses this information to determine whether an overpayment or underpayment condition exists and to create one adjustment entry. The adjustment entry is either an on-account or write-off item.

Item-Level Adjustments

Detail reference information always includes the amount of the payment that Payment Predictor applies to an item. If the amount of the payment does not match the amount of the item, Payment Predictor handles it in the following way:

  1. Closes the item as paid in full.

  2. Calculates any realized gain or loss based on the entire amount, if needed.

  3. Creates a new item based on the action to be taken as defined in the Payment Predictor method with the exception of the action, Release the Payment. For example, it could put it on account, write it off, make an adjustment, or make a deduction with an option to create a worksheet for review before posting. The action choice made in the Payment Predictor method for each condition should be tailored to your specific business requirements.

For example, a detail payment method could designate the following actions for handling an unmatched payment:

  • When the overpayment exceeds 100.00 EUR or 25 percent, it releases payment for next matching.

    No new item is created on this condition.

  • When the underpayment exceeds 5.00 EUR, it creates a deduction item with the unmatched amount as its balance amount.

  • When the underpayment is less than 5.00 EUR, it creates an item with the amount and writes it off.

    The new item has the original item ID in the document field as a reference. The process creates two items in this case. For underpayments, it creates a WS-07 item to adjust the underpayment and then a WS-11 item (write-off an underpayment).

If Payment Predictor creates new on-account, underpayment, overpayment, prepayment, or deduction items when it applies a partial payment, it assigns the reference information that is provided with the payment to the new items. The process uses the reference qualifier code in the Payment ID Item table (PS_PAYMENT_ID_ITEM) to determine what reference field to populate for the new item. If a payment has multiple references, the process retains all the reference values unless multiple references exist for the same reference qualifier code.

This table provides an example of how the process assigns reference values if multiple references exist:

Reference Qualifier Code

Reference Value

Action

I (item)

Item100

Does not assign reference value to new item.

I (item)

Item200

Does not assign reference value to new item.

O (order)

Order100

Assigns reference value to new item.

P (purchase order number)

PO100

Assigns reference value to new item.

The process populates these fields with reference values:

  • Document

  • Item ID

  • Bill of Lading

  • Letter of Credit

  • Order Number

  • PO Ref (purchase order reference)

  • SubCustomer1

  • SubCustomer2

If the reference value has the I (item) reference qualifier code and the value is the same as the item ID for the new item, the process places the reference value in the Document field.

This functionality enables you to match new credits and debits with the items that Payment Predictor creates using the Automatic Maintenance process (AR_AUTOMNT). To match the items, you should build automatic maintenance methods that match items by the appropriate reference fields and item amounts. This functionality is very useful if you use the Cash Drawer Receipts feature to enter payments and deposits for counter sales.

The Payment Predictor multiprocess job (ARPREDCT) is a shell process that runs multiple subprocesses that process different sets of data concurrently. The multiprocess job contains two subprocesses that run sequentially. The second subprocess runs multiple child processes in parallel when you set up parallel processing for the Payment Predictor process.

  • The AR_PREDICT1 Application Engine process gathers the data for the process run, determines how many rows each parallel process should process, and starts each parallel process.

  • The Payment Predictor multiprocess job (AR_PP) starts after AR_PREDICT1 and calls each of the child processes that you define for it, such as AR_PP1 or AR_PP2. The child processes are multiprocess jobs and run in parallel.

    Each child process, such as AR_PP1, calls the AR_PREDICT2 Application Engine process, which does the actual payment application. AR_PREDICT2 matches the payments, updates the application tables, and generates process instances before ending the process. Each child process has its own process instance number and set of temporary tables and matches payments independently from the other child processes.