Defining Algorithm Groups

Example: #BALANCE

To understand how a customer-based algorithm group works, examine #BALANCE. This algorithm group compares the amount of the payment to the total of all items for the customer. When you scroll through the steps, you might notice that the steps have a pattern: ALGO_1, BALGR, ALGO_X1, then ALGO_2, BALNET, ALGO_X2.

Payment Predictor evaluates overpayments and underpayments based on the information in the PS_PP_MATCH_TAO. As long as an item has not been selected by another payment, it either fully applies a payment (if it matches the balance of all open items) or it does not apply it at all. An overpayment or underpayment condition cannot exist.

In one case, however, an overpayment condition can exist. Payment Predictor processes two payments together for the same customer, and the first payment pays one item while the second payment pays the entire customer balance including that same item. This situation might occur if the customer forgets that the first payment has already been made when they create the second payment. In this case, Payment Predictor determines that the sum of the open items matches the amount of the payment. It inserts rows only for items that are not already selected by another payment into the PS_MATCH_TAO temporary table. In this limited case, Payment Predictor detects and evaluates an overpayment condition.

If in your business environment applying a tolerance to the evaluation of a balance makes sense, modify the algorithm to include a tolerance calculation. This modification directs Payment Predictor to insert into PS_PP_MATCH_TAO item rows for which the total nearly, but not exactly, matches the amount of the payment. This tolerance calculation then enables Payment Predictor to recognize an overpayment or underpayment condition and then to take the appropriate action. This table describes the steps in the #BALANCE algorithm group:

%SelectInit(ALGORITHM )
SELECT 'BALGR'
FROM PS_INSTALLATION
WHERE 1 = 1

%Sql(ARPREDICT$CLAUSESCUSTIDU)
AND P.PAYMENT_AMT = 
( SELECT SUM(PAY_AMT) 
FROM %Table(PP_ITEM_TAO)
WHERE PROCESS_INSTANCE = P.PROCESS_INSTANCE 
AND DEPOSIT_BU = P.DEPOSIT_BU
AND DEPOSIT_ID = P.DEPOSIT_ID
AND PAYMENT_SEQ_NUM = P.PAYMENT_SEQ_NUM )

%SelectInit(AE_EXISTS)
SELECT 'X'
FROM %Table(PP_MATCH_TAO)
WHERE PROCESS_INSTANCE = 
%Bind(PROCESS_INSTANCE)
AND PP_PROC_FLAG = '0'

%SelectInit(ALGORITHM )
SELECT 'BALNET'
FROM PS_INSTALLATIONWHERE 1 = 1

%Sql(ARPREDICT$CLAUSESCUSTIDU)
AND P.PAYMENT_AMT = 
( SELECT SUM(PAY_AMT - DISC_PAY)
FROM %Table(PP_ITEM_TAO)
WHERE PROCESS_INSTANCE = P.PROCESS_INSTANCE 
AND DEPOSIT_BU = P.DEPOSIT_BU
AND DEPOSIT_ID = P.DEPOSIT_ID
AND PAYMENT_SEQ_NUM = P.PAYMENT_SEQ_NUM )

%SelectInit(AE_EXISTS)
SELECT 'X'
FROM %Table(PP_MATCH_TAO)
WHERE PROCESS_INSTANCE = 
%Bind(PROCESS_INSTANCE)
AND PP_PROC_FLAG = '0'

Example: #REFS

To understand how an item-summary-reference-based algorithm group works, examine #REFS. This algorithm group has one algorithm that selects only open items that exactly match the references supplied with a payment. When you scroll through the steps, you may notice that the steps have a pattern.

To help you understand how #REFS works, this table describes the steps.

Example: #REFS_NG

The #REFS_NG algorithm group has algorithms that you can modify to handle references that do not match items exactly. They are platform-specific and you should feel free to take advantage of any functions that your database allows. Because this algorithm group compares a partial ID and returns any possible matches, the processing time for this algorithm group is longer than for other algorithm groups. Use this algorithm group only when no other way is available to create matches, and always set up the payment predictor method to generate a worksheet, where you review and finalize the payment.

The following table describes the two algorithms in the #REFS_NG algorithm group:

%Substring(I.%Bind(FIELDNAME, NOQUOTES), 1, 8) = %Substring(%Sql(ARCASTCHAR, 
%Bind(REF_VALUE), 30), 1, 8)

%Substring(I.%Bind(FIELDNAME, NOQUOTES), 3, 7) = %Substring(%Sql(ARCASTCHAR, 
%Bind(REF_VALUE), 30), 1, 7))

Prerequisites

These prerequisites must be met in order to use the MULPAY algorithm to apply multiple payments to the same item:

• Deselect the No Mult Pending Item Selection (no multiple pending item selection) check box on the Installation Options - Receivables Page.

• Select the Multiple Payments for One Item check box on the Installation Options - Receivables Page.

• All payments that are associated with the paying item must have matching summary references.

• Payment currency must match the balance currency of the item.

• Multiple Payments must be for the same item.

• Add the #REFS algorithm group to the payment predictor method using the Predictor Method Page.

Processing Multiple Payments with the MULPAY Algorithm

The MULPAY algorithm processes multiple payments in this manner:

1. If the first payment amount is less than the item pay amount (balance amount), Payment Predictor selects the next payment and compares the payment amount to the item remaining balance. The same process continues until the item remaining balance is zero or there are no remaining payments.

2. For the last applied payment:

   1. If the payment amount is greater than the remaining item balance, an adjustment item is created based on the overpayment condition defined for the #REFS group algorithm in the Predictor Method Page.

   2. if the payment amount is less than the remaining item balance, the item remains open.

Using #DETAIL for Deductions

The #DETAIL algorithm group enables you to take deductions. For a deduction to occur, in the PAYMENT_ID_ITEM record, the ENTRY_USE_ID must be WS-08 (create a deduction). The record should also contain item reference information, including the business unit, customer ID, and item ID. For existing items, the deduction must be for the open item that is selected for the current payment. In addition, the sum of the payment amount and the deduction amount must equal the item balance. For example, if your customer wants to take a deduction for 50 USD on an item balance of 1,000 USD, then the payment amount must be 950 USD.

Using #DETAIL for Write-offs

The #DETAIL algorithm group enables you to deduct a write-off at the item level. For a write-off to occur, the ENTRY_USE_ID must be WS-09 (Write-Off) in the PAYMENT_ID_ITEM record. The record should also contain item reference information, including the business unit, customer ID, and item ID. To process a write-off using #DETAIL, you must also have a payment (PY) transaction for the same item in the PAYMENT_ID_ITEM record, and you must select the Partial Payment Switch field on the Bill To Options page for the customer. In addition, the detail references must equal the item amount. For example, if you have an item for 1,000 USD and you want to eliminate a 50 USD write-off from that balance, then the payment amount must be 950 USD. In this example, the Pay Amt field in the PAYMENT_ID_ITEM record must also be 950 USD.

Using #DTL_TLR for Partial Payments and Discounts

If Payment Predictor runs a payment predictor method that contains the #DTL_TLR algorithm group, the processing of partial payments differs depending on how you set up the tolerances on the Receivables Options - Predictor Detail Options page and whether you selected the Partial Payment Switch field on the Bill To Options page for the customer.

If you select the Partial Payment Switch check box, the process performs one of the following actions:

• If the payment amount is less than the open balance amount minus the earned discount amount, the process performs one of the following actions:

  • If the remaining amount is within the tolerances on the Receivables Options - Predictor Details Options page, it closes the item and creates a write-off or adjustment based on the setup.

  • If the remaining amount is greater than the tolerances on the Receivables Options - Predictor Details Options page, it makes a partial payment and leaves the remaining amount open on the item.

• If the payment amount is greater than the open balance amount minus the earned discount amount, the process pays the item in full and uses the values that you entered on the Receivables Options - Predictor Details Options page to determine whether to eliminate as a write-off or adjust an overpayment.

If you deselect the Partial Payment Switch check box, the process uses the values that you entered on the Receivables Options - Predictor Details page to determine whether to eliminate as a write-off or adjust an underpayment or overpayment.

For example, suppose that the tolerance amount is set at 50.00 USD and the percentage is set at 10 percent. If a payment of 90.00 USD is received after the payment term for the discount has expired for a 100.00 USD item, the payment will be within tolerance because the 10.00 USD short pay is less than the fixed tolerance amount of 50.00 USD and the calculated amount of 10 percent using 100 × 0.10. Therefore, the 10.00 USD of the short pay amount is adjusted or eliminated as a write-off based on what is specified using the Payment Predictor detail options.

A condition exceeds tolerance if it either exceeds the fixed tolerance amount or exceeds the tolerance percentage. In that case, you can set up Payment Predictor to take a different action for overpayments and underpayments.

To set up your system to use tolerances for partial payments and discounts, you must perform the following tasks:

• Assign the #DTL_TLR algorithm group to payment predictor methods.

• Select or deselect the Partial Payment Switch check box for customers for whom you want to apply payments using the #DTL_TLR algorithm group on the Bill To Options page.

• Assign a payment predictor method that runs the #DTL_TLR algorithm group to customers on the Bill To Options page or to business units on the Receivables Options - Payment Options page.

• Assign the entry types and reasons for the #DTL_TLR algorithm group to the appropriate automatic entry types on the Automatic Entry Type - Selection page.

• Select the Disc (discount) check box and enter a discount amount on the Detail Reference Information page.

• Define the discount tolerances and write-off limits for underpayments and overpayments on the Receivable Options - Predictor Detail Options page.

• (Optional) Override the default system function to use for underpayments and overpayments and unearned discounts on the Receivables Options - Predictor Detail Options page.

This table represents various scenarios and how Payment Predictor handles payments, earned discounts, and unearned discounts. All amounts are in USD.

The Results column shows the results after running Payment Predictor and the Receivables Update process.

Example: #OVERDUE Algorithm Group

This section provides an example of how payment predictor applies payments to overdue charge line items.

This table lists the sequence numbers that are assigned to the entry reasons for the automatic entry type for finance charges for this example:

This table lists items and finance charge line items that are open for a customer:

This table lists the sequence numbers that Payment Predictor would apply to the items to determine the payment order:

This table shows what the results would be if you applied a 50.00 payment to the customer.

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.