Reviewing Payment Predictor and Special Conditions

This section provides background information about how algorithms handle special conditions.

To handle special conditions, Payment Predictor uses statements that run within the algorithm group or within sections that are done from the algorithm group. This functionality enables Payment Predictor to segment processing so that the answer set can be modified between segments. Payment Predictor uses a DO SELECT statement that is driven by the same SQL statement to run the statements.

Reference-Based Algorithms

To process a reference-based algorithm, Payment Predictor builds a list of references for all payments in the run. Then, for each type of reference used, it modifies and processes the algorithm dynamically. For example, if any payments in the run have ITEM references, it modifies the SQL to "AND I.ITEM = D.REF_VALUE AND D.REF_QUALIFIER_CODE = 'I'." Oracle recommends that you use an index based over PS_ITEM for each type of reference that you use regularly.

In the ID_ITEM section, Payment Predictor uses the reference to identify a customer by using the item. In the ITEM_REF algorithm, a DO SELECT drives a DO of the section RLOOP. This action populates the PS_PP_MATCH_TAO temporary table using the same two lines and %BIND variables concatenated at the end of the basic insert that joins the payment, items, and item references.

AND X.REF_QUALIFIER_CODE = %BIND(REF_QUALIFIER_CODE) 
AND X.REF_VALUE = I.%BIND(FIELDNAME, NOQUOTES)

Limiting Items Applied by References to Customer-Identified Items

Normally, a payment with an item reference pays items regardless of the item's customer ID. In cases in which you receive both reference information and customer identification, Payment Predictor restricts the items applied by references to the customers identified through the use of an algorithm group called #REFS_ONE. The #REFS_ONE algorithm group contains a section, ONE_CUST, that deletes from the PS_PP_MATCH_TAO record those rows in which the customer is not part of the remit from group associated with the MICR ID or the customer. This statement has no effect if the MICR ID or customer ID is invalid.

Ordering by Oldest Due Date First

Payment Predictor loads all the customer items into the PS_PP_MATCH_TAO record to perform oldest first processing (ordering items with the oldest item first). It loops through the items, record by record, in oldest due date first order and then deletes any unused records. Payment Predictor uses two algorithm groups that accomplish the same result in the same manner. They selectively eliminate items from the PS_PP_MATCH_TAO record with an ordering option. The two algorithms are:

  • #OLDEST1: Orders open items from oldest to latest due date, including credit items.

  • #OLDESTC: Includes all credits as part of the payment first, then applies payments.

    Orders the remaining items from oldest to latest due date.

Allowing Partial Payments

If you are using the #OLDEST or #OLDESTC algorithm, Payment Predictor always makes partial payments on the last item that depletes the remainder payment amount for bill to customers when the payment amount does not exactly match the sum of the matched items. If you are using DTL_TLR (detail with tolerance algorithm), Payment Predictor makes partial payments when the payment amount does not exactly match the item balance amount and if the customer has been set up for partial payments on the Bill To Options page.

See Using #DETAIL and #DTL_TLR for Partial Payments and Deductions.

Setting Up for Prepayments

If your organization receives payments that are prepayments for specific invoices that you created in your billing application, you can set up Payment Predictor to create Prepay Items (WS-04). To take advantage of this feature, you must receive the invoice number in the ITEM field on the PS_PAYMENT_ID_ITEM record. You must also activate the NOTFOUND step (algorithm) in the DETAIL section (algorithm group) of the AR_PREDICT1 Application Engine process. You must also use a payment predictor method that uses detail references.

Using this feature is the same as creating a prepayment item on the payment worksheet. Payment Predictor applies the prepayment to an item later—after you enter an item in PeopleSoft Receivables that has an item ID that matches the value that you received in the ITEM field in the PAYMENT_ID_ITEM record.