Setting Up Payment Predictor Processing

This chapter provides an overview of Payment Predictor processing and discusses how to:

• Define algorithm groups.

• Define payment predictor methods.

• Set up parallel processing.

• Select payments for Payment Predictor processing.

• Review payment predictor temporary tables and sections.

Note. This chapter is required. You must complete the tasks discussed in this chapter to implement Payment Predictor processing.

Understanding Payment Predictor Processing

The Payment Predictor Application Engine process (ARPREDCT) is the automatic cash application process in 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 section discusses:

• The Payment Predictor process flow.

• Algorithms and methods.

• Payment Predictor and multicurrency processing.

• Item-level adjustments and reference values.

• Payment Predictor multiprocess job.

The Payment Predictor Process Flow

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 should be excluded from Payment Predictor.

The source of payments does not matter when you use Payment Predictor. Payments can be online payments—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, or the cash drawer receipts interface (CDR_LOADPMT).

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 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 diagram shows the process flow of Payment Predictor.

Payment Predictor process flow

Algorithms and Methods

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.

Payment Predictor’s 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 familiar with your customers’ remittance patterns and exception processing procedures.

Payment Predictor and Multicurrency Processing

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 following:

• 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 there is a difference between the item amount in the base currency for the item's business unit on the item's accounting and payment dates.

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

Payment-Level Adjustments

When you use the #REFS algorithm group, and there is one payment in a deposit that pays for multiple items, 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 as follows:

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 defined on the payment predictor method with the exception of Release the Payment. For example, it could be to put it on account, write it off, make an adjustment or make a deduction with an option to create 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 dealing with an unmatched payment:

• When the overpayment exceeds 100.00 EUR or 25%, 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 write it off.

  The new item has the original item ID in the document field as a reference. The process actually 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).

See Also

Understanding Realized Gain and Loss Processing

Item-Level Adjustments and Reference Values

If Payment Predictor creates new on-account, underpayment, overpayment, prepayment, or deduction items when it applies a partial payment, it assigns the reference information 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 there are multiple references for the same reference qualifier code.

This table provides an example of how the process assigns reference values if there are multiple references.

The process populates reference values in these fields:

• 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 enables you to match new credits and debits with the items that Payment Predictor creates using the Automatic Maintenance process. To match the items, you should build automatic maintenance methods that match items by the appropriate reference fields and item amounts. This is very useful if you use the Cash Drawer Receipts feature to enter payments and deposits for counter sales.

See Also

Setting Up Automatic Maintenance Methods

Payment Predictor Multiprocess Job

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 releases the process instances on tables 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.

See Also

Setting Up Parallel Processing

Defining Algorithm Groups

This section provides an overview of algorithm groups, Payment Predictor modes, sample algorithm groups, and discusses how to:

• View algorithm groups.

• Deactivate an algorithm in an algorithm group.

• Add an algorithm group.

• Use #DETAIL and #DTL_TLR for partial payments and deductions.

• Use the #OVERDUE algorithm group.

• Review Payment Predictor and special conditions.

Understanding Algorithm Groups

Before you can use Payment Predictor to apply payments automatically, you must select and refine the algorithms that determine how Payment Predictor handles specific payment situations.

Algorithm groups are a collection of related algorithms. An algorithm group represents a section in the Payment Predictor process and each algorithm in the group represents a step in the section. Each algorithm has at least three statements:

• A statement that names the algorithm within the group.

• An insert statement that populates the PS_PP_MATCH_TAO temporary table.

  This step is usually named for the algorithm within the group, but it can be named anything.

• A statement that performs the post-match processing.

Receivables has sample algorithm groups that you can use to set up Payment Predictor. You can use an algorithm group as delivered. You can deactivate the algorithms in the group that you do not want to use, copy the same algorithm group to another method and then deactivate different algorithms. You can create new algorithm groups as needed by copying algorithms from other algorithm groups and then modifying the algorithms to suit your particular needs.

Understanding Payment Predictor Modes

Algorithm groups have instructions for processing payments. The instructions are based on the type of reference information that was used to match payments to customers. This table lists the type of reference information:

The following table describes payment predictor modes:

Understanding Sample Algorithm Groups

The following table lists the sample algorithm groups that come with Receivables. As you review the samples, consider the automatic cash application capabilities of your current system and your customers' remittance patterns.

Viewing Algorithm Groups

This section explains how to view the contents of an algorithm group.

To view an algorithm group:

1. Open the AR_PREDICT2 Application Engine program in Application Designer.

2. Locate the name of the algorithm group in the sections.

   Algorithm groups have names that start with # and appear first in the list.

3. To view details about the algorithms (steps), expand the algorithm group.

   Some algorithm groups, such as #BALANCE or #REF, may have steps in a repeating pattern. More details on this pattern are in the example that follows.

4. To view the SQL statement, double-click the SQL folder for the algorithm.

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.

There is one case, however, when an overpayment condition can exist. Payment Predictor processes two payments for the same customer together, 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 only rows for items 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 it makes sense in your business environment to apply a tolerance to the evaluation of a balance, modify the algorithm to include a tolerance calculation. This 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 in turn 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 deal with 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 other algorithm groups. Use this algorithm group only when there is no other way 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), 4, 7) = %Substring(%Sql(ARCASTCHAR, 
%Bind(REF_VALUE), 30), 1, 7))

Deactivating an Algorithm in an Algorithm Group

This section explains how to deactivate algorithms in an algorithm group that you do not want to use. For example, the #BALANCE algorithm group has two algorithms that are similar, but you only need one of them.

To deactivate an algorithm:

1. Open the AR_PREDICT2 Application Engine program in Application Designer.

2. Locate the name of the algorithm group in the sections.

   Algorithm groups have names that start with # and appear first in the list.

3. Expand the algorithm group and locate the step (algorithm) that you want to disable.

4. Clear the Active check box to disable the algorithm.

Adding an Algorithm Group

You can add an algorithm group by copying algorithms from an existing algorithm group. We recommend copying whenever possible. However, if copying is not permitted on the platform that you are using, you can write one yourself.

To add a new algorithm group:

1. Open the AR_PREDICT2 Application Engine program in Application Designer.

2. Select Insert, Section.

   A new section titled Section1 appears in the list.

3. Type over the name of Section1 algorithm group.

   The new name must start with #. For example: #NEW.

4. Save your work.

5. Copy algorithms from existing algorithm groups and paste them into the new algorithm group.

   Each algorithm requires a minimum of three statements: name, insert, and post match system processing.

   If the algorithm is customer-based, copy an existing algorithm that is most similar to one that you want to create.

   If the algorithm is reference-based, copy #REFS.

   To copy, right-click the section that you want to copy and select Copy.

   To paste, right-click the section where you want to insert the new section and select Paste.

6. Copy and paste the SQL statements for each step.

   To copy, right-click the appropriate action and select View SQL.

   To paste, right-click the appropriate action folder in the new section and select Paste.

7. Modify the SQL as needed.

Using #DETAIL and #DTL_TLR for Partial Payments and Deductions

This section has tips on using the #DETAIL or #DTL_TLR algorithm group. You must select one of these algorithm groups to process detail reference information that includes the amount of the item, as well as an item ID.

Typically, you use the #DETAIL algorithm group for payment-level adjustments and the #DTL_TLR group for partial payments and discounts. Both groups enable you to take deductions. The #DTL_TLR and #DETAIL algorithm groups enable you to specify the desired entry type and entry reason for handling exceptions.

Detail reference information for a particular payment is stored in the following fields of the PS_PAYMENT_ID_ITEM table:

Either PAY_AMT or else both ITEM_AMT and DISC_TAKEN must be positive numbers. If all these amounts are provided, Payment Predictor uses only PAY_AMT.

Using #DETAIL and #DTL_TLR for Deductions

The #DETAIL and #DTL_TLR algorithm groups enable 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. The item may be an existing item. The only restriction is that the deduction cannot be for the open item that is selected for the current payment. Deductions associated with prior activity can be processed by the payment.

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 setup 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 does the following:

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

  • 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 write off or adjust an overpayment.

If you clear 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 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 since 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 x 0.10. Therefore the 10.00 USD of the short pay amount is adjusted or written 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.

Note. If an item does not qualify for an earned discount, but the Disc (discount) field is selected for the item on the Detail Reference Information page and there is a discount amount entered; the process takes the unearned discount. The process takes the unearned discount regardless of the Partial Payment Switch field setting.

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 clear 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.

• 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 overpayment and unearned discounts on the Receivables Options - Predictor Detail Options page.

See Also

Setting Up Automatic Entry Types

Selecting Payment Predictor Options

Entering Additional Billing, Purchasing, Payment, and Write-Off Options for Bill To Customers

Using the #OVERDUE Algorithm Group

The #OVERDUE algorithm group handles payments for overdue charge line items. If you use the option to create overdue charges by item line, you can create payment predictor methods that use this algorithm group. You assign a sequence number to each entry reason for the overdue charge (FC-01) item entry type on the Item Entry Type - Selection page. Payment Predictor uses this sequence number to determine the order to pay the overdue charge line items. The #OVERDUE algorithm group handles payments based on certain conditions:

• Payment Predictor applies payments and any credit amount available to all overdue charges first before the remaining amount is disbursed to the principal amount.

• Payment Predictor applies a partial payment to the first item after the last fully paid item in the sequence if there are insufficient funds to pay for remaining open overdue charge line items.

  The sequence is determined by due date in ascending order. If there is any credit amount available, Payment Predictor applies it as part of the payment.

To set up your system to use the #OVERDUE algorithm group, perform these tasks:

1. Set up the sequence number for each entry reason for the overdue charge item entry type.

2. Set up a payment predictor method containing the #OVERDUE algorithm group.

3. Assign a payment predictor method that contains the #OVERDUE algorithm group to customers.

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.

See Also

Setting Up Item Entry Types

Reviewing Payment Predictor and Special Conditions

This section has background information on how algorithms handle special conditions.

To handle special conditions, Payment Predictor uses statements that execute within the algorithm group or within sections that are done from the algorithm group. This enables Payment Predictor to break up processing into pieces between which the answer set can be modified. Payment Predictor uses a DO SELECT that is driven by the same SQL statement to execute 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 executes 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’.” We recommend that you use an index based over PS_ITEM for each type of reference that you use on a regular basis.

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 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 where 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 exact match 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 Receivables that has an item ID that matches the value that you received in the ITEM field in the PAYMENT_ID_ITEM record.

Defining Payment Predictor Methods

To define payment predictor methods, use the Predictor Method (PP_METHODS) and Predictor Method Review (METHOD_REVIEW) components.

This section provides an overview of payment predictor methods and discusses how to:

• Define a payment predictor method.

• Review an example of a payment predictor method.

Understanding Payment Predictor Methods

A payment predictor method tells Payment Predictor how to handle the different situations it encounters during processing. Each method consists of a series of conditions and actions based on remittance information. You can define as many methods as you want, but keep the methods as simple as possible and tailor them closely to the remittance patterns of your customers to optimize the efficiency of auto matching. Although Receivables ships with sample methods, you must create your own methods and assign them to a setID or individual customers.

Ideally, the methods that you define should enable Payment Predictor to apply all your regular payments, leaving only the exceptions to be applied online using payment worksheets. To minimize the number of exceptions, your methods must reflect the ways your customers pay you. You can assign methods to an entire business unit or to specific customers, so that you can tailor your methods to groups of customers with similar payment practices.

If you have a mixed situation with some overrides, it is much easier to diagnose problems if your methods are stored under one setID. Deposit business unit values and item business unit values, if different, should both point to the same, common TableSet. PeopleSoft also recommends that you keep the number of methods that you use to a minimum. Start with one method that is specified at the deposit business unit level. Then add methods for handling customers that consistently pay you in a way that is different from your other remit from customers.

When you define a payment predictor method, consider the reference information that comes with the payment and how it can be used to match the payment to the customer. The type of reference information determines which algorithms you use.

We recommend that the first algorithm group in a method apply the most payments.

Important! If you use the vendor rebate option in Purchasing or the claim back option in Order Management, create payment predictor methods that do not write off the remaining balance for items. Assign those methods to the business unit that is set up for vendor rebate and claim back processing. Use the Claims Management Workbench in Purchasing or Order Management to handle write-offs. This enables the system to determine whether the write-offs meet the write-off tolerances for claim processing.

Payments Without Reference Information

For payments with no reference information, use the following algorithm groups.

• #BALANCE

• #COMBOS

• #OLDEST1

• #OLDESTC

• #OVERDUE

• #PASTDUE

• #STATMNT

Payments with Summary Reference Information

For payments with summary reference information (that is, references with item identification but no amount), use the following algorithm groups:

• #REFS

• #REF_ONE

• #REF_NG

If you use the Cash Drawer Receipts feature to record payments for counter sales, use one of these algorithm groups in your payment predictor method to apply the payments.

Note. Use an algorithm group for detail references if you receive payments with summary reference information that pay for multiple line items with the same item ID.

Payments with Detail Reference Information

For payments with detail reference information (that is, references with item identification and amount), use the following algorithm groups:

• #DETAIL

• #DTL_TLR

See Also

Understanding Payment Predictor Modes

Understanding Sample Algorithm Groups

Prerequisites

You must define the algorithm groups for payment methods, because methods use algorithm groups to select items.

Pages Used to Define a Payment Predictor Method

Defining a Payment Predictor Method

Access the Predictor Method page.

Step

Each step consists of one or more payment conditions; each condition has an action. The step number determines the order in which the step is processed in the method.

Click the Order buttons to change the order of the steps.

Condition and Action

A step must have at least one condition. You can assign up to seven conditions to a step and select one of five actions for each condition. The conditions cannot conflict with each other. The number of the condition determines the order in which it will be processed within the step. Values are:

1. First...

2. Any Overpayment

3. Overpayment Exceeds

4. Overpayment Is Less Than

5. Any Underpayment

6. Underpayment Exceeds

7. Underpayment Is Less Than

Note. If you use Any Overpayment or Any Underpayment, you cannot use the tolerance choices for overpayments or underpayments that exceed or fall short of a certain amount. The reverse is also true. If you use Overpayment Exceeds, Underpayment Exceeds, or Underpayment Is Less Than, you cannot use Any Overpayment or Any Underpayment. The exception is the #DTL_TLR algorithm group. For the #DTL_TLR algorithm group, you should not select any of the underpayment or overpayment conditions. The conditions for exceptions for this algorithm group are defined using the Predictor Detail Options page.

You must select one of the following actions:

Note. If you select Apply To Control Customer and Payment Predictor cannot identify any customers, Payment Predictor determines whether the default method associated with the deposit business unit indicates Apply To Control Customer when the customer identification is missing or is set to Doesn’t Matter.

Reviewing an Example of a Payment Predictor Method

This section includes an example of a summary reference Payment Predictor method.

The sample method contains five steps. Each step is based on remittance characteristics: how to structure Payment Predictor’s actions based on the results of customer identification and the presence or absence of summary reference information. Each step considers various payment conditions and each condition has an associated action.

The example assumes that you receive a mix of payments, some with payment summary references—references without associated item amounts—and some without summary references. It places the steps using algorithm groups for payments with references first, because it is normally more efficient to execute those steps first.

Note. To create an example of a detail reference method, change the algorithm group in Step 1 to one of the algorithm groups for detail references.

Step 1

In Step 1, the method’s remittance conditions take into account payments with references. Regardless of whether customers are identified, if payment summary references are supplied, Payment Predictor runs the algorithms in the #REFS group.

For the Customers Identified field, select Doesn’t Matter. For References Supplied, select Summary.

Step 2

The second step in the sample method executes regardless of the results of customer identification and only if you did not receive references.

For Customers Identified, select Doesn’t Matter to ask Payment Predictor to process any payment for which at least one customer was identified. For References Supplied, select No.

Step 3

Step 3 repeats the same remittance conditions as Step 2. It executes regardless of the results of customer identification and only if you did not receive references.

This step is useful for customers who often pay their entire open item balance. An algorithm variation exists for handling earned discounts.

For Customers Identified, select Doesn’t Matter so Payment Predictor processes any payment for which at least one customer is identified. For References Supplied, select No.

Step 4

Step 4 repeats the same remittance conditions as Steps 2 and 3. It executes regardless of the results of customer identification and only if you did not receive references.

For Customers Identified, select Doesn’t Matter to ask Payment Predictor to process any payment for which at least one customer was identified. For References Supplied, select No.

This step shows how the order in which algorithms are executed must be taken into consideration. It is possible that more than one algorithm group could apply to the same payment.

For example, if a remit from group has only one open item (for a new or low-volume customer), then either #COMBOS or #BALANCE would work. If all of the open items are past due (customer has not bought anything recently), then #BALANCE or #PASTDUE would work. Under these circumstances, it is advisable to order the algorithms from most to least efficient. This results in the order #COMBOS, followed by #BALANCE, and then #PASTDUE.

Other factors, such as the number of payments that a given algorithm group applies, are also important. If #PASTDUE could apply to 90% of payments, #BALANCE 10%, and #COMBOS 10% (the total can exceed 100%), then an option is to place #PASTDUE first. These decisions must be made on an individual basis, looking at both payment profiles and enabled algorithms.

When you start using Payment Predictor, begin by ordering steps according to efficiency. If production runs demonstrate that most payments are applied in a step far down in the method, reorder the steps until you establish an optimal configuration.

Step 5

Step 5 executes regardless of remittance conditions. It places any payments that steps 1 through 4 did not apply on account for a control customer. It acts as a catch all for payments that it could not identify.

For Customers Identified, select Doesn’t Matter to enable Payment Predictor to process any payment for which at least one customer is identified. For References Supplied, select Doesn’t Matter.

Setting Up Parallel Processing

This section provides an overview of parallel processing for Payment Predictor and discusses how to:

• Define the maximum instances in PSAdmin.

• Define the maximum concurrent processes for the server.

• Define the number of parallel processes.

• Add more parallel processes to the AR_PP multiprocess job.

• Add additional Payment Predictor process definitions.

Understanding Parallel Processing for Payment Predictor

Receivables enables you to process multiple Payment Predictor processes in parallel to achieve higher performance. You initiate the processes using one run control and the process automatically divides the work between the number of partitions that you specify in your setup.

The Payment Predictor multiprocess job (ARPREDCT) includes:

• The AR_PREDICT1 process.

• The AR_PP multiprocess job.

The following diagram illustrates how the process works if you have four partitions.

Payment Predictor parallel processes

When you use PeopleSoft Enterprise Process Monitor to check the status of the process, you view the status of the AR_PREDICT1 process and each process within the AR_PP multiprocess job. The system does not indicate that the Payment Predictor multiprocess job (ARPREDCT) is successful until each parallel process completes. The Job Message Log Summary page summarizes all the individual parallel process message log messages for the entire ARPREDCT job.

AR_PREDICT1 Process

The AR_PREDICT1 process acts as a preprocessor for the actual payment matching process and also:

• Gathers all the qualified data for processing.

• Places the qualified data in temporary tables.

• Partitions the data between the child processes.

• Initiates the AR_PP multiprocess job that starts child processes in parallel.

The distribution of the data among the child or parallel processes is based on the composition of the data and the number of parallel processes. The process attempts to spread the data volume evenly among the processors. The staging phase takes a little longer, but the overall processing time is faster because multiple children processes run concurrently. You should balance the decision of using parallel processing or single thread processing based on the volume of data and the hardware capacity to get the maximum benefit from this feature.

AR_PP Multiprocess Job

The AR_PP multiprocess job contains all the Application Engine process definitions that you use for parallel processing, such as AR_PP1. Each process definition calls the AR_PREDICT2 Application Engine process, which actually matches the payments, updates the application tables, and performs table cleanup before the process ends.

Receivables delivers eight process definitions—AR_PP1 through AR_PP8. If you want to run more than eight partitions of the Payment Predictor process at once, you must define additional process definitions. Use the AR_PP1 process definition as an example.

The standard setup for the AR_PP multiprocess job is to run a single threaded process and contains only the AR_PP1 process definition. If you want to use parallel processing, you must assign additional process definitions to the job definition. You must also specify the number of partitions that your organization will use. You might have to experiment with the number of partitions that works for you. We recommend that you assign just a couple of additional partitions and increase the number, if needed.

You might also have to override the server settings for your organization. By default, you can run up to three instances of a process at one time. If you want to run additional instances, you must change your configuration. If you also use parallel processing for the Aging (AR_AGING), Statements (AR_STMTS), and Receivable Update (AR_UPDATE) processes, the maximum instances applies to those processes, as well. For example, if you want to run eight instances for the Receivable Update process and four for the Payment Predictor process, you must configure your server for eight instances.

Pages Used to Set Up Parallel Processing

Defining the Maximum Instances for PSAdmin

Open the PSAdmin tool on your server to change the configuration settings.

To change the maximum instances:

1. Scroll to the section titled Values for config section – PSAESRV.

   The section looks as follows:

   Values for config section - PSAESRV.
   Max Instances = 3.
   Recycle Count=0
   Allowed Consec Service Failures=0.

2. Change the value for Max Instances to the maximum number of parallel processes that you want to run at once.

Defining the Maximum Concurrent Processes for the Server

Access the Server Definition page.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Defining the Number of Parallel Processes

Access the AR Parallel Processing Options page.

Adding More Parallel Processes to the AR_PP Process Job

Access the Job Definition page for the AR_PP job.

Run Mode	Always select Parallel.
Process Type and Process Name	Enter Application Engine for the type and select from AR_PP2 to AR_PP8 for each separate partition or process that you want to run. If you define additional process definitions, select the name of the definitions that you added. Note. You must have the same number of rows in the process list as you enter in the Maximum Partitions field on the AR Parallel Processing Options page.
Run Always on Warning and Run Always on Error	You must select these check boxes.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Adding Additional Payment Predictor Process Definitions

Access the Process Definition page.

Complete the fields on this page and the other pages in the Process Definition component (PRCSDEFN) to match the AR_PP1 process definition with two exceptions:

• Use another name.

• Use another description.

Use this format for the name: AR_PP#, for example AR_PP9.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Selecting Payments for Payment Predictor Processing

When you set up Payment Predictor methods, establish a hierarchy for processing business units, customers, deposits, and payments. This table describes how you can further refine the process by excluding specific customers or payments.

See Also

Defining Payment Options

Entering Payments

Applying Payments Using Payment Worksheets

Defining Account Information

Entering Additional Billing, Purchasing, Payment, and Write-Off Options for Bill To Customers

Reviewing Payment Predictor Temporary Tables and Sections

This section discusses how to:

• Review temporary tables.

• Review Payment Predictor sections and SQL statements.

Reviewing Temporary Tables

As an Application Engine-based program, Payment Predictor makes extensive use of set processing and temporary tables. This design improves performance and enhances your ability to modify processing for your environment.

Set processing is a method of manipulating data that operates on more than one row at a time. It is not a SELECT, FETCH, and UPDATE approach; rather, it inserts, updates, and deletes rows in sets. For example, Payment Predictor runs an algorithm group for all payments in all business units that use the current method and meet the remittance conditions of the current step.

The Payment Predictor uses cursor-based processing with reuse being on to avoid data contention and improve performance in support of the parallel processing.

Each of the temporary tables has PROCESS_INSTANCE as the high-order key to enable multiple Payment Predictor jobs to run on the server in parallel without interference.

The temporary tables are organized according to logical levels of data: payments, customers, items, steps, and matches.

Payment Predictor uses the following key temporary tables:

See Also

Defining Receivables Installation Options

Reviewing Payment Predictor Sections and SQL Statements

The Payment Predictor multiprocess job (ARPREDCT) runs two Application Engine processes—AR_PREDICT1 and AR_PREDICT2. Each Application Engine process runs a collection of SQL statements that are run by Application Engine. The AR_PREDICT2 process contains algorithm groups that represent sections. Each algorithm in the section represents a step that is either an SQL statement or the DO of another section. If you want to DO a section more than once, you use a DO SELECT. The processes perform the section you specify once for each row the select returns. It places values returned by the select in %BIND variables and references them by name in subsequent SQL statements.

The AR_PREDICT1 process prepares the staging tables and populates the temporary tables for the second multiprocess job. The staging tables are PS_PP_ITEM_TMP, PS_PP_CUST_TMP, and PS_PP_PYMNT_TMP, and they are images of the tables PS_PP_ITEM_TAO, PS_PP_CUST_TAO, and PS_PP_PYMNT_TAO. The staging tables populate the temporary tables used by the child processes. The AR_PREDICT2 process uses the information in the temporary tables to generate the groups and worksheets.

The AR_PREDICT2 process flow has four stages:

• Executing method steps.

• Generating transactions.

• Update tables and status.

• Release process instances on tables.

This section provides background information about the sections in the AR_PREDICT1 and AR_PREDICT2 Application Engine processes.

AR_PREDICT1 - Preparing Temporary Tables

This table describes the sections that prepare temporary tables:

%SelectInit(REF_QUALIFIER_CODE, FIELDNAME)SELECT DISTINCT R.REF_QUALIFIER_CODE ,
R.FIELDNAMEFROM %Table(PP_PYMNT_TAO) P , PS_PAYMENT_ID_ITEM X , 
PS_AR_FLD_REF_TBL R WHERE P.PROCESS_INSTANCE = %Bind(PROCESS_INSTANCE)
AND P.PP_REF_STATUS = 'Y' AND P.DEPOSIT_BU = X.DEPOSIT_BUAND 
P.DEPOSIT_ID = X.DEPOSIT_IDAND P.PAYMENT_SEQ_NUM = X.PAYMENT_SEQ_NUMAND 
X.REF_QUALIFIER_CODE = R.REF_QUALIFIER_CODE AND R.REF_STATUS = 'A'

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

AR_PREDICT2 - Executing Method Steps

This table describes the sections that run method steps:

AR_PREDICT2 - Generating Transactions

This table describes the sections that generate transactions: