Setting Up Payment Predictor Processing

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

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

Click to jump to parent topicUnderstanding 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 section discusses:

Click to jump to top of pageClick to jump to parent topicPayment 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 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

Click to jump to top of pageClick to jump to parent topicAlgorithms 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.

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.

Click to jump to top of pageClick to jump to parent topicPayment 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:

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:

See Also

Understanding Realized Gain and Loss Processing

Click to jump to top of pageClick to jump to parent topicItem-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 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:

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.

See Also

Setting Up Automatic Maintenance Methods

Click to jump to top of pageClick to jump to parent topicPayment 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.

See Also

Setting Up Parallel Processing

Click to jump to parent topicDefining Algorithm Groups

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

Click to jump to top of pageClick to jump to parent topicUnderstanding 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.

An algorithm group is 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:

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

Click to jump to top of pageClick to jump to parent topicUnderstanding 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:

Type

Description

Customer reference information

Information such as the MICR ID or customer ID that is supplied with a payment. If a customer reference is not found, Payment Predictor uses item summary reference information or detail reference information to identify the customer.

Item summary reference information

Reference information that does not include the amount, for example, an item ID and reference qualifier code of I on payment entry.

Item detail reference information

Reference information that includes the amount, for example, item ID and item amount on payment entry.

The following table describes payment predictor modes:

Payment Predictor Mode

Description

Payment Predictor Result

Payments with customer identified and no item reference information provided.

Selects processing method for payments that are missing reference information.

If a payment is missing reference information, Payment Predictor places all open items for all of the customers identified by the payment into a temporary table called PS_PP_ITEM_TAO.

Note. If the deposit in a Payment Predictor run has more than one payment with the same customer ID and business unit, the process processes only the first payment when you are using one of these algorithm groups: #BALANCE, #COMBOS, #OLDEST1, #OLDESTC, #OVERDUE, or #PASTDUE. For example, the deposit has three payments:

Payment 1: References customer USA01 and business unit US001.

Payment 2: References customer USA05 and business unit US001.

Payment 3: References customer USA05 and business unit US001.

The algorithm group would process only payments 1 and 2.

Payments with item summary reference information and the customer identified does not matter.

Selects a processing method for payments with summary reference information. (Summary reference information does not include the amount. Example: item ID with no item amount.)

Payment Predictor places all matched open items for all of the customers identified by the payment into a temporary table called PS_PP_ITEM_TAO.

Payments with item detail reference information and the customer identified does not matter.

Selects a processing method for payments with detail reference information (includes amount), for example, item ID and item amount.

Detail reference information enables you to use Payment Predictor to process deductions that are associated with a payment. For example, a deduction for prior freight damages of 100.00 CAD can be processed with a payment of 900.00 CAD to pay an open item of 1,000.00 CAD. The sum of the detail reference items less the sum of the deductions should equal the payment amount.

Click to jump to top of pageClick to jump to parent topicUnderstanding Sample Algorithm Groups

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

Algorithm Group (SECTION)

Selects These Open Items

Use For

Algorithms in Group (STEPS)

#BALANCE

Selects all open items for identified customers, only if the payment amount exactly matches the open items total.

Payments without item references only and customer identified.

BALGR

Selects all open items.

BALNET

Selects all open items minus earned discounts.

#COMBOS

Selects all open items for identified customers only if the payment amount matches an item amount, an item amount with discount, or the total amount of any two items. The algorithm selects an item only if only one item matches the payment amount or if only two items match the payment amount. For example, if the payment amount is 200.00 EUR and one item for 200.00 EUR exists, it selects that item. However, if the payment amount is 200.00 EUR and two items exist, each for 200.00 EUR, it does not select any items.

Payments without item references only and customer identified.

DEBITGR

Selects a single unique open item.

DEBITNT

Selects a single unique open item minus earned discount.

ANY2GR

Selects any two unique open item balances combined.

#OLDEST1

Selects items with oldest due dates first until the remaining payment amount is less than the next item.

Payments without item references only and customer identified.

OLDEST

Selects open items in oldest first order by due date. Creates a partial payment for the next item.

#OLDESTC

Adds all items with credit balances to the payment amount. Then selects items with debit balances in oldest due dates order until the remaining payment amount is less than the next item.

Payments without item references only and customer identified.

CREDITS

First adds all credits to the payment amount. Then selects open items in oldest first order by due date. Creates a partial payment for the next item.

#OVERDUE

Selects all overdue items for payment matching using the sequence of the entry reasons associated with overdue charges.

Payments without item references only and customer identified.

OVERDUE

Selects the items to apply to the payment. First uses the sequence of overdue entry reasons.

Then selects open items in oldest first order by due date. Creates a partial payment for the next item.

#PASTDUE

Selects all past-due items for the customers identified only if the payment amount exactly matches the total of the past-due items.

Payments without item references only and customer identified.

PASTGR

Selects all past-due open items.

PASTNET

Selects all past-due open items minus earned discounts.

#REFS

Selects only open items that exactly match the references supplied with a payment.

Payments with item summary references only and customer identified does not matter.

ITEMREF

Selects all open items identified by the references regardless of customer identification. Enables you to add a unique debit or credit item for an underpayment or overpayment that completes the application.

#REF_ONE

Selects only open items that exactly match the references supplied with a payment.

Payments with item summary references only and customer identified.

ONECUST

Selects all open items identified by the references limited to the customer whose MICR ID or customer ID is supplied with the payment. Enables you to add a unique debit or credit item that completes the application.

#REFS_NG

Uses reference information that does not exactly match to select items.

Payments with item summary references only and customer identified does not matter.

PeopleSoft Receivables includes these algorithms as samples of possible ways for dealing with bad references. They are platform-specific and you can take advantage of any functions that your database allows.

FIRST8

Selects all open items identified by the first eight characters of the references.

MIDDLE7

Selects all open items identified by the seven characters after the first four characters in the references.

#DETAIL

Selects only open items that exactly match the references supplied with a payment.

Payments with item detail references only and customer identified does not matter. Created adjustments only adjust remaining overpayment or underpayment.

DETAIL

Selects all open items identified by matched references. Also accepts WS-08 deduction references. Payments with detail references should balance, but if not, the #DETAIL algorithm creates an Adjust Remaining Underpayment item for underpayments or an Adjust Remaining Overpayment item for overpayments.

#DTL_TLR

Selects only open items that exactly match the references supplied with a payment.

Payments with item detail references only and customer identified does not matter.

DTL_TLR

Selects all open items identified by matched references. Closes items that match the payment amount. If an underpayment exceeds the tolerances, it looks at the bill to customer to determine whether partial payments are allowed. If they are allowed, it creates a partial payment on the item. The actions taken are based on the selections on the Receivables Options - Predictor Detail Options page.

#DTL_PM

Selects only open items that exactly or approximately match the detail references supplied with a payment.

Payments with item detail references. Identified customer does not matter.

#DTL_PM:

  • First Pass:

    Selects all open items identified by matched references, including deduction references (WS-08).

  • Second pass:

    Whenever an overpayment is about to be created and there are unmatched items referenced in the payment, this algorithm serves as an example of how to deal with bad references. You can easily modify the algorithm to adapt to your organization's needs for matching open items.

    • FIRST8 :

      Selects all open items identified by the first eight characters of the reference.

    • MIDDLE7:

      Selects all open items identified by the seven characters after the first four characters in the reference.

Payments handled by this algorithm method should balance. If any of the payments do not balance, the #DTL_PM algorithm creates an Adjust Remaining Underpayment item (WS-07) for underpayments or an Adjust Remaining Overpayment item (WS-06) for overpayments.

If the customer cannot be identified for the new item, the algorithm applies the payment item based on the value selected (First, Last, Specify) for the Control Customer and Business Unit field on the Receivables Options, Predictor Details Options page.

#DTL_TPM

Selects open items that exactly or approximately match the detail reference item supplied with the payment.

Payments with item detail references only and customer identified does not matter.

#DTL_TPM:

  • First Pass:

  • Selects all open items identified by exactly matched references.

  • Second Pass:

    Whenever an overpayment is about to be created, and there are unmatched items referenced in the payment, this algorithm serves as an example of how to deal with bad references. You can easily modify the algorithm to adapt to your organization's needs for matching open items.

    • FIRST8 :

      Selects all open items identified by the first eight characters of the reference.

    • MIDDLE7

      Selects all open items identified by the seven characters after the first four characters in the reference.

If an underpayment exceeds the tolerances specified on the Receivables Options, Predictor Detail Options page. The system looks at the Bill To customer to see whether partial payments are allowed. If partial payments are allowed, it creates a partial payment on the item.

If the customer cannot be identified for the new item, the algorithm applies the payment item based on the value selected (First, Last, Specify) for the Control Customer and Business Unit field on the Receivables Options, Predictor Details Options page.

#STATMNT

Selects items from the most recent customer statement.

Payments without item detail references and customer identified.

STMTALL

Selects items from the most recent statement. The payment amount must exactly match the total amount of the items on the statement.

Click to jump to top of pageClick to jump to parent topicViewing 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 and #REFS, may have steps in a repeating pattern. More details about this pattern are in the example that follows this procedure.

  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.

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:

Step

Description

ALGO_1

Sets the name of the algorithm within the group. It updates the payment for any payments applied by this algorithm.

Type: Select

Statement:

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

"THE INSERT"

Populates PS_PP_MATCH_TAO. This step is usually named for the algorithm within the group but can be called anything. In this algorithm, the name of the first algorithm is BALGR.

Type: Update/Insert/Delete

Statement:

%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 )

ALGO_X1

If the system works after the process populates PS_PP_MATCH_TAO, it removes invalid items from PS_PP_MATCH_TAO and classifies the payment as either fully applied, over-applied, or under-applied. Runs a section called ALGRDONE.

Type: Do When

Statement:

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

ALGO_2

The name of the second algorithm in the group if more than one exists.

Type: Select

Statement:

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

"THE INSERT"

Populates PS_PP_MATCH_TAO. This step is usually named for the algorithm within the group, but can be called anything. In this algorithm, the name of the second algorithm is BALNET.

Type: Update/Insert/Delete

Statement:

%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 )

ALGO_X2

If the system works for the second algorithm after the process populates PS_PP_MATCH_TAO, it removes invalid items from PS_PP_MATCH_TAO and classifies the payment as either fully applied, over-applied, or under-applied. Runs a section called ALGRDONE.

Type: Do When

Statement:

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

Step

Description

ALGO_1

Sets the name of the algorithm within the group and updates the payment for any payments applied by this algorithm.

MATCHTMP2

Clears the PS_PP_MATCH2_TAO table.

ITEMREF

Populates PS_PP_MATCH2_TAO. It is done once for each unique reference qualifier that is used by the payments to be applied. If a payment is in both PS_PP_MATCH2_TAO and PS_PP_MATCH_TAO, it removes it from PS_PP_MATCH2_TAO. Then it copies the data from PS_PP_MATCH2_TAO to PS_PP_MATCH_TAO.

ALGR_A1

Removes invalid items from PS_PP_MATCH_TAO.

ALGR_B1

Processes matches.

ALGR_C1

Updates payment status.

ALGO_D1

Retrieves counts.

ALGO_E1

Sets PP_PROC_FLAG to 1 and ends the matching process.

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:

Algorithm

Description

FIRST8

Matches the first eight characters in the reference information to the first eight characters of the specified fields on the item in the database.

You can change the parameters in the %substring from either side of the equation, depending on how you want to match.

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

MIDDLE7

Skips the first three characters and matches the middle seven characters in the reference information to the middle seven characters of the specified fields on the item in the database.

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

Click to jump to top of pageClick to jump to parent topicDeactivating 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 need only 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 deactivate.

  4. Deselect the Active check box to deactivate the algorithm.

Click to jump to top of pageClick to jump to parent topicAdding an Algorithm Group

You can add an algorithm group by copying algorithms from an existing algorithm group. Oracle recommens 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 the 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.

Click to jump to top of pageClick to jump to parent topicUsing #DETAIL and #DTL_TLR for Partial Payments and Deductions

This section provides tips for 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.

The #DETAIL algorithm group handles exceptions as either an overpayment adjustment (AO) or an underpayment adjustment (AU), unless a create a deduction (WS-08) transaction or a write-off an item (WS-09) transaction is entered on the Detail Reference Information page for the payment (PAYMENT_ID_ITEM record). The #DETAIL algorithm group can assign only AO or AU entry types. Because the entry types assigned by the #DETAIL algorithm group are predefined by the system, you do not need to define more steps when using this algorithm group to create a payment method.

The #DTL_TLR algorithm group enables you to specify the desired entry type and entry reason for handling exceptions. When you are using the #DTL_TLR algorithm group, the action that Payment Predictor takes for underpayments, overpayments, and discounts is based on the options specified on the Receivables Options - Predictor Detail Options page. Because you specify the adjustments assigned by the #DTL_TLR algorithm group, you do not need to define more steps when using this algorithm group to create a payment method.

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

Field

Description

ITEM_AMT

The gross amount of the item selected to be paid.

PAY_AMT

The net amount of the item selected to be paid.

DISC_TAKEN

The discount amount applied to the item.

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

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 a discount amount is entered, the process takes the unearned discount. The process takes the unearned discount regardless of the setting of the Partial Payment Switch field.

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

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

Original Balance Amount

Payment Amount

Entered Discount

Discount Check Box Selected

Calculated Earned Discount

Calculated Unearned Discount

Action Item

Partial Payment Allowed

Results after running Payment Predictor and Receivables Update Process

Item Status

Closing Balance

1000

980

0

Y

20

0

0

Yes or No

20 USD earned discount is taken.

Closed

0

1000

1000

0

N

0

0

0

Yes or No

Apply payment in full and close the item.

Closed

0

1000

990

10

Y

0

10

0

Yes or No

10 USD unearned discount is taken (within the tolerance specified).

Closed

0

1000

960

40

Y

0

40

0

No

40 USD deduction item is created (the discount is not within the tolerance amount, a partial payment is not allowed, and the underpayment is not within the specified tolerance).

Closed

0

1000

960

40

Y

0

40

0

Yes

Process a partial payment (the discount is not within the specified tolerance amount).

Open

40

1000

980

10

Y

0

10

10 (WAU)

Yes or No

10 USD underpayment is written off (the discount is within the specified tolerance amount and the underpayment is within the specified invoice tolerance percent or amount).

Closed

0

1000

1010

0

N

0

0

10 (WAO)

Yes or No

10 USD overpayment is written off (the overpayment is within the specified invoice tolerance percent or amount).

Closed

0

1000

1010

0

Y

20

0

30 (OA)

Yes or No

New on-account item is created (the overpayment is above the specified invoice tolerance percent or amount).

Closed

0

1000

490

10

Y

0

10

0

Yes

Process the partial payment (the discount is not within the specified tolerance percentage).

Open

510

1000

490

10

Y

0

10

0

No

510 USD deduction item is created (the discount is not within the specified tolerance amount and a partial payment is not allowed).

Closed

0

See Also

Setting Up Automatic Entry Types

Selecting Payment Predictor Options

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

Click to jump to top of pageClick to jump to parent topicUsing #DTL_PM and #DTL_TPM to Handle Unmatched Payments

When the Payment Predictor process (ARPREDCT) runs, the PeopleSoft Receivables #DETAIL algorithm processes every item that gets matched with payment lines. If a payment has ten item detail references and nine of them match exactly and one remains unmatched, the nine matched item detail references are processed, while the unmatched item detail reference is not processed and remains untouched. In this case, an overpayment is usually created and the detail reference is lost.

When the payments and their item references get loaded from an external system, the system usually does not verify that the items exist. These unmatched items are usually off by a letter or two, which prevents the payments from being applied.

Before these processes can create these new items, you must access the Receivables Options – Predictor Detail Options page and select one of these values for the new Control Bus Unit and Customer field:

The #DTL_PM (partial match) and #DTL_TPM (tolerance partial match) algorithms identify items to be matched with a payment using the detail reference information in the first pass, just like the #DETAIL algorithm. The referenced customer does not matter. If, after this initial pass, the entire payment was not applied and an underpayment item must be created, and items were referenced in the payment that the #DETAIL algorithm method did not match, then a second payment predictor pass tries to match any unmatched items. In the second pass, the remaining payment amount from the first pass is considered, and a LIKE construct searches for the items that were not matched in the first pass. The referenced customer does not matter. The algorithm only uses the item as a reference. All of the items that are matched in the second pass are added to the ones found in the first pass, and from that point on these items will be treated as if they were all found in a single pass. Payments handled by this algorithm method should balance. However, if they do not balance, the #DTL_PM method creates an Adjust Remaining Underpayment item (WS-07) for underpayments or an Adjust Remaining Overpayment item (WS-06) for overpayments.

For example, there are ten payment lines with detail reference information. However, an item ID of one of the payment lines is off by a letter. The algorithm matches, but does not close, the first nine payment lines, and tries to match the tenth payment line by approximation using the FIRST8 or MIDDLE7 methods. If the match is successful, then the ten items will be in the same location, and all ten of the items will be processed and closed.

However, if the algorithm is unable to match the tenth item, the algorithm closes the nine items, and the tenth item remains outstanding. The algorithm creates an adjustment payment item (underpayment or overpayment) for the remaining payment amount. The system places this adjustment item either on a worksheet or on a customer account, depending on the setup.

The #DTL_TPM algorithm processes just like the #DTL_PM during the first and second passes through Payment Predictor. However, if an underpayment exists, #DTL_PM checks the tolerances and rules set up on the Receivable Options, Predictor Detail Options page. If an underpayment exceeds these tolerances, the system checks whether the Bill To customer allows partial payments. If partial payments are allowed, the system creates a partial payment of the item.

Important! Before the #DTL_PM and #DTL_TPM algorithms can create these new items, you must access the Receivables Options, Predictor Detail Options page and select a value in the Control Bus Unit and Customer field:

See Selecting Payment Predictor Options.

Click to jump to top of pageClick to jump to parent topicUsing 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 in which to pay the overdue charge line items. The #OVERDUE algorithm group handles payments based on certain conditions:

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:

Entry Reason

Sequence Number

ADMIN

1

PNLTY

2

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

Item

Line Number

Due Date

Entry Type

Entry Reason

Balance Amount

IT_OC1

1

March 17, 2002

OC

ADMIN

16.16 USD

IT_OC2

1

March 17, 2002

OC

ADMIN

32.32 USD

IT_OC2

2

March 17, 2002

OC

FIN

32.32 USD

IT_OC1

2

March 17, 2002

OC

FIN

16.16 USD

IC_OC1

3

March 17, 2002

OC

PNLTY

16.16 USD

IC_OC2

3

March 17, 2002

OC

PNLTY

32.32 USD

IT_OC1

0

March 3, 2002

IN

Not Applicable 

1000.00 USD

IT_OC2

0

March 3, 2002

IN

Not Applicable 

2000.00 USD

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

Item

Line Number

Due Date

Overdue Charge Sequence Number

IT-OC1

1

March 17, 2002

1

IT_OC2

1

March 17, 2002

1

IT_OC1

3

March 17, 2002

2

IT_OC2

3

March 17, 2002

2

IT_OC1

0

March 3, 2002

9

IT_OC2

0

March 3, 2002

9

IT_OC1

2

March 17, 2002

9

IT_OC2

2

March 17, 2002

9

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

Payment Amount

ITEM ID

ITEM Line

TYPE

16.16 USD

IT_OC1

1

PY

32.32 USD

IT_OC2

1

PY

1.52 USD

IC_OC1

3

PY

See Also

Setting Up Item Entry Types

Click to jump to top of pageClick to jump to parent topicReviewing 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:

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.

Click to jump to parent topicDefining 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, lists a prerequisite, and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding 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 PeopleSoft 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 that 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, diagnosing problems is much easier 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. Oracle 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 who 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.

Oracle recommends that the first algorithm group in a method apply the most payments.

Important! If you use the vendor rebate option in PeopleSoft Purchasing or the claim back option in PeopleSoft 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 claimback processing. Use the Claims Management Workbench in PeopleSoft Purchasing or PeopleSoft 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.

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:

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:

See Also

Understanding Payment Predictor Modes

Understanding Sample Algorithm Groups

Click to jump to top of pageClick to jump to parent topicPrerequisite

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

Click to jump to top of pageClick to jump to parent topicPages Used to Define a Payment Predictor Method

Page Name

Definition Name

Navigation

Usage

Predictor Method

PP_METHODS_TABLE

Setup Financials/Supply Chain, Product Related, Receivables, Payments, Predictor Method, Predictor Method

Define a payment predictor method.

Predictor Method Review - Review

PP_METHODS_REVIEW

Setup Financials/Supply Chain, Product Related, Receivables, Payments, Predictor Method Review, Review

View, but do not change, an existing payment predictor method. The fields on this page are identical to those on the Predictor Method page.

Click to jump to top of pageClick to jump to parent topicDefining a Payment Predictor Method

Access the Predictor Method page. (Select Setup Financials/Supply Chain, Product Related, Receivables, Payments, Predictor Method, Predictor Method.)

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.

Customers Identified

Select if customers must be identified for this step. Values are: None, One, More Than One, and Doesn't Matter.

References Supplied

Select the type of reference information that the payment must have for this step. Values are:

Summary: Use summary references (references such as an invoice number without amounts).

Detail: Use detail references (references such as an item ID with an amount).

No: No reference identification.

Doesn't Matter: Process the step with or without reference information.

In some cases, you do not care about customer information or payment references. For example, if you receive payment references, you can designate that customer information Doesn't Matter or vice versa. You might even define a step using Doesn't Matter in both cases: no matter how many customers are involved and regardless of payment reference information, take the specified action.

Exclude Disputed Items

Select if you do not want to apply payments to items in dispute.

Exclude Deduction Items

Select if you do not want to apply payments to deductions.

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 exceptions are the #DTL_TLR and the #DTL_TPM algorithm group. For the #DTL_TLR and #DTL_TPM algorithm groups, 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.

See Selecting Payment Predictor Options.

Amount or Percent

If you select an overpayment or underpayment, enter values in one or both of these fields. For example, you can specify an action when an overpayment is less than 100.00 EUR or less than 12 percent of the payment. If you specify both an amount and a percent, the system processes the overpayment or underpayment as long as one of the tolerance criteria is met. You can specify only one set of tolerance criteria for each condition. Enter the currency for the amount to enable the system to convert amounts properly when determining whether a write-off amount meets the tolerance.

You must select one of the following actions:

Release The Payment

Select to have Payment Predictor reset the payment for processing in a subsequent step. Normally, if Payment Predictor has applied even part of a payment, it ignores that payment in future steps. You can release the payment several times within a method.

Not available for condition 1, First.

Execute Algorithm Group

Select to have Payment Predictor run the SQL statements that are predefined as part of the selected algorithm group. A field appears to the right, so you can select the algorithm group.

If the method results in successful application, the payment status is Applied, and Payment Predictor creates a group and sets the posting action to Batch Standard. You can look at the group using an inquiry page. Select Worksheet to have Payment Predictor create payment worksheets instead of setting the posting action for the payment to Batch Standard.

Generate An Item

Select to have Payment Predictor create a pending item according to the system function that you provide in the field that appears. The payment status is Applied, and the posting action is Batch Standard. Select Worksheet to have Payment Predictor create payment worksheets instead of setting the payment to a Batch Standard posting action.

When more than one customer is identified in the PS_PP_CUST_TAO table, Payment Predictor uses the highest customer ID of the customers who had items paid when creating the pending item. The MAX function in SQL determines the highest ID through an alphanumeric sort sequence that will differ by database platform.

Valid system functions differ according to the payment conditions. Condition 1 can use only WS-05. Conditions 2, 3, and 4 can use only WS-04, WS-05, WS-06, and WS-10. Conditions 5, 6, and 7 can use only WS-07, WS-08, and WS-11.

Apply To Control Customer

Select to have Payment Predictor place the payment or remaining amount on account for the control customer business unit and customer ID that you provide. (If you omit the business unit, the system uses the deposit business unit by default.)

The payment status is Applied, and Payment Predictor creates a group and sets the posting action to Batch Standard. Select Worksheet to have Predictor create payment worksheets instead of setting the posting action for the payment to Batch Standard. This option is useful for placing payments on a control account when no customer is identified. This action is available only for Condition 1, First.

Generate A Worksheet

Select to have Payment Predictor create a payment worksheet for online review. The payment status is Worksheet. You can look at the resulting payment worksheet by accessing the Worksheet Selection page. The worksheet has the items that Payment Predictor matched with payments, plus the suggested overpayments and underpayments. You can then use the worksheet to accept the results of Payment Predictor processing as is or to make manual adjustments. When you are done working with the payment worksheet, you can post the payments.

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.

Click to jump to top of pageClick to jump to parent topicReviewing 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 perform 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 1, Condition 1 (First)

Select Execute Algorithm Group, and then select #REFS.

Step 1, Condition 3 (Overpayment Exceeds)

Enter a value in the Amount or Percent field. For example, an amount of 100.00. Select Release The Payment.

If an overpayment exceeding the tolerance occurs, the method directs Payment Predictor to release the payment for processing by another relevant step.

This step shows that when a large variance occurs, the wrong item may have been referenced. In this case, releasing the payment is better than applying it to the wrong item, which may belong to a different customer.

Another possibility is that a mix of valid and invalid references caused the large overpayment. If most references are valid or most payments have only one reference, this use of the overpayment condition could be helpful.

Step 1, Condition 4 (Overpayment Is Less Than)

Enter a value in the Amount or Percent field, for example, a percent value of 15. Select Generate An Item and select the system function WS-05 to place an amount on account.

The same remittance conditions apply here as in the previous condition. If an overpayment is less than the specified tolerance, Payment Predictor creates an on-account item. You can then use this item to apply to another item on a maintenance worksheet.

Notice that the tolerance amounts are the same as for Condition 3. Use the same amounts for both of the overpayment conditions so that Payment Predictor can handle all overpayment amounts.

You don't need to build a worksheet for online review; instead, enable the resulting payment group to be processed the next time the Receivable Update Application Engine process (ARUPDATE) runs for the appropriate business unit.

Step 1, Condition 6 (Underpayment Exceeds)

Enter a value in the Amount field, for example, 5.00. Select Generate An Item and select the WS-08 system function to create a deduction.

The same remittance conditions apply here. If an underpayment occurs that is greater than the specified amount, Payment Predictor creates a deduction for the difference and builds a worksheet for online review.

To define this condition and the following one, an online payment application scenario was considered and Payment Predictor was directed to emulate that action during background processing.

Step 1, Condition 7 (Underpayment Is Less Than)

Enter a value in the Amount field, for example, 5.00. Select Generate An Item and select the WS-11 system function to eliminate an underpayment.

The same remittance conditions apply here. If a very small underpayment occurs, Payment Predictor writes off the amount of the underpayment. You don't need to build a worksheet for online review; instead, enable the resulting payment group to be processed the next time the Receivable Update process runs for the appropriate business unit.

Step 2

The second step in the sample method runs 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 2, Condition 1 (First)

Select Execute Algorithm Group, and then select #COMBOS.

This algorithm group has three algorithms, two of which are active in the sample data. The two active algorithms look for a single debit or a single debit net of earned discount—belonging to one of the identified customers—that matches the payment amount. This approach is useful if your remittance analysis indicates that your customers often pay one open item at a time and the open items are usually for different amounts.

If you do not offer discounts, inactivate the algorithm that evaluates earned discounts. If your customers often pay two items at a time, consider activating the algorithm that looks for any two items combined that match the payment amount.

Step 3

Step 3 repeats the same remittance conditions as Step 2. It runs 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 that Payment Predictor processes any payment for which at least one customer is identified. For References Supplied, select No.

Step 3, Condition 1 (First)

Select Execute Algorithm Group, and then select #BALANCE.

Step 4

Step 4 repeats the same remittance conditions as Steps 2 and 3. It runs 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 4, Condition 1 (First)

Select Execute Algorithm Group, and then select #PASTDUE.

This step shows how the order in which algorithms are run must be taken into consideration. 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, you should order the algorithms from most to least efficient, which would result 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 percent of payments, #BALANCE to 10 percent, and #COMBOS to 10 percent (the total can exceed 100 percent), 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 runs 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.

Step 5, Condition 1 (First)

Select Apply to Control Customer, and then select a business unit and customer ID, selecting 99999 or another out-of-range identifier. Select the Worksheet check box.

Take a similar approach if your business practices call for posting all unidentified cash to a control customer.

Click to jump to parent topicSetting Up Parallel Processing

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

Click to jump to top of pageClick to jump to parent topicUnderstanding Parallel Processing for Payment Predictor

PeopleSoft 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 following diagram illustrates how the Payment Predictor process performs parallel processing on four different AR jobs. The process prepares and builds staging tables and partitions the work into four different jobs, which are run parallel to each other. The Payment Predictor process for each job matches the payments and updates the tables.

Payment Predictor parallel process workflow

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 finishes. 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:

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.

PeopleSoft 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, which 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. Oracle recommends 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.

Click to jump to top of pageClick to jump to parent topicPages Used to Set Up Parallel Processing

Page Name

Definition Name

Navigation

Usage

Server Definition

SERVERDEFN

PeopleTools, Process Scheduler, Servers, Server Definition, Server Definition

Define the maximum concurrent processes for Application Engine processes.

AR Parallel Processing Options

PARALLEL_AR_SBP

Set Up Financials/Supply Chain, Install, Installation Options, Receivables

Click the Parallel Processing Options link.

Define the number of parallel processes or partitions to use with Payment Predictor.

Job Definition

PRCSJOBDEFN

PeopleTools, Process Scheduler, Jobs, Job Definition, Job Definition

Add additional Payment Predictor process definitions to run the AR_PP multiprocess job.

Process Definition

PRCSDEFN

PeopleTools, Process Scheduler, Processes, Process & Definition, Process Definition

Add additional Payment Predictor process definitions if you need to run more than eight parallel processes.

Click to jump to top of pageClick to jump to parent topicDefining 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 like this:

    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.

Click to jump to top of pageClick to jump to parent topicDefining the Maximum Concurrent Processes for the Server

Access the Server Definition page. (Select PeopleTools, Process Scheduler, Servers, Server Definition, Server Definition.)

Process Type and Max Concurrent

For the Application Engine process type, enter the maximum number of parallel processes that you run at once. This figure must be the same or greater than the maximum instances that you defined for PSAdmin.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Click to jump to top of pageClick to jump to parent topicDefining the Number of Parallel Processes

Access the AR Parallel Processing Options page. (Select Set Up Financials/Supply Chain, Install, Installation Options, Receivables and click the Parallel Processing Options link.)

Parallel Process and Maximum Partitions

Enter the exact number of partitions or parallel processes that you want to run for the AR_PREDICT parallel process.

Click to jump to top of pageClick to jump to parent topicAdding More Parallel Processes to the AR_PP Multiprocess Job

Access the Job Definition page for the AR_PP job. (Select PeopleTools, Process Scheduler, Jobs, Job Definition, Job Definition.)

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

Click to jump to top of pageClick to jump to parent topicAdding Additional Payment Predictor Process Definitions

Access the Process Definition page. (Select PeopleTools, Process Scheduler, Processes, Process & Definition, Process Definition.)

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 this format for the name: AR_PP#. For example: AR_PP9.

See Also

Enterprise PeopleTools PeopleBook: PeopleSoft Process Scheduler

Click to jump to parent topicSelecting 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 to further refine the process by excluding specific customers or payments:

Defaults

Page Used to Set Default

What Defaults Affect

Turn On/Off

Assign Method

TableSet

Receivables Options - Payment Options

Business Units

Determines which Payment Predictor method the system uses as the default for a business unit.

 NA

X

Bank Account

Information

Deposits

Payment Predictor evaluates payments received electronically as well as those entered online. When the system receives a payment through a payment interface, it checks the bank account's attributes to determine whether payments from this bank account should use Payment Predictor as their default application approach.

The associated bank account that uses Payment Predictor should have the PP_SW field in the PS_BANK_ACCT_DEFN table set to Y.

X

 NA

Customer

Bill To Options

Bill To Customers

Enables you to override the Payment Predictor method set at the business unit level for this customer.

Supports putting an individual customer on hold to exclude its items from consideration by Payment Predictor.

X

X

Payment

Express Deposit Payments

Regular Deposit Payments

Worksheet Selection

Payments

Determines whether Payment Predictor should apply an individual payment from an electronic payment or from an online payment. This choice overrides the on and off setting at the TableSet or bank account level.

To include or exclude an entire deposit for Payment Predictor processing, you must take action for each payment in the deposit.

Although usually not done, you can use Payment Predictor from the express deposit pages. Enter reference information, and then select Payment Predictor.

X

 NA

Note. NA means Not Applicable.

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

Click to jump to parent topicReviewing Payment Predictor Temporary Tables and Sections

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicReviewing 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 selected 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:

Table

Description

PS_PP_PYMNT_TAO

This table is the first table Payment Predictor populates. It contains one row for each payment processed.

The PREPARE section populates this table.

Payment Predictor processes only payments selected for Payment Predictor (PS_PAYMENT.PP_SW = Y) that are in balanced deposits (PS_DEPOSIT_ CONTROL.BAL_STATUS = I) for requested business units.

Keys: PROCESS_INSTANCE, DEPOSIT_BU, DEPOSIT_ID, PAYMENT_SEQ_NUM.

If any rows exist in PS_PAYMENT_ID_ITEM, the system sets PP_REF_STATUS to Y—references supplied. This setting is important because Payment Predictor processes payments with reference information differently than payments without reference information.

Note. Payment Predictor changes the initial value of Y to N—no references supplied—if it cannot identify any customers based on the reference information. That is, a value of N might be interpreted as no references supplied or that all references supplied are invalid.

Payment Predictor sets the value of PP_MICR_STATUS based on an analysis of the contents of PS_PP_CUST_TAO. The field name is somewhat misleading; the values placed in the field refer to the broader results of customer identification and not just the presence of a MICR ID. End result values are:

  • M (more than one customer identified)

  • S (only one customer identified)

  • N (no customer identified).

Payment Predictor stores the method and the setID for the method that was used to process the payment on this table. The PP_APPL_STATUS and PP_DISPOSITION fields contain information about the status of a payment and whether it has been applied or whether it requires a worksheet.

PS_PP_CUST_TAO

This table contains one row for each customer identified by each payment.

Keys: PROCESS_INSTANCE, DEPOSIT_BU, DEPOSIT_ID, PAYMENT_SEQ_NUM, CUST_ID (duplicates allowed)

Customers are identified using one or more of the following conditions:

  • One or many rows in PAYMENT_ID_ITEM containing reference information.

  • One or many rows in PAYMENT_ID_CUST containing a MICR ID.

  • One or many rows in PAYMENT_ID_CUST containing a customer ID (with or without a business unit).

Note. When a payment has reference information, Payment Predictor does not use the customer identification information placed in the PS_PP_CUST_TAO table. Instead, it uses the reference qualifier and reference information to find the corresponding items on PS_ITEM. The PS_ITEM records contain the business unit and the customer identifier. Payment Predictor uses the business unit and customer identifier to determine the appropriate customers and related remit from customers.

PS_PP_ITEM_TAO

This table contains one row for each item considered for payment application.

If the payment does not have reference information (rows in PS_PAYMENT_ ID_ITEM), Payment Predictor loads all open items for all customers in PS_PP_CUST_TAO into this table. Later, non-reference-based algorithms that are associated with a method evaluate the data in PS_PP_ITEM_TAO.

Note. An algorithm does not have to use this table as the basis for its evaluation. For example, suppose that the reference-based algorithms obtain information directly from PS_ITEM, bypassing PS_PP_ITEM_TAO completely. Payment Predictor then runs a reference algorithm by inserting a row for each item selected by that algorithm directly into PS_PP_MATCH_ TAO. It then backloads the matches into PS_PP_ITEM_TAO to maintain consistency between these two tables.

PS_PP_STEP_TAO

This table contains one row for each step, condition, and action of each method that is processed in a run. The SBLD module populates this table and then performs each step in turn.

SBLD drives the payment application process. After the process loads all steps for all identified methods into PS_PP_STEP_TAO, this module does a SELECT, FETCH, and DELETE of each method step in order. The actions associated with a step are performed simultaneously against all payments that have not been processed (or have been released), that have been assigned to the current method by Payment Predictor, and that meet the remittance pattern specified for the step. When the Payment Predictor process finishes, this table should be empty (because all steps should have been processed).

PS_PP_MATCH_TAO

The process uses this table to evaluate overpayment and underpayment conditions. This table contains one row for each item to be paid by the payment or to be included on a payment worksheet. It is populated by an algorithm (or by WBLD when you use the Generate A Worksheet option). It might also contain one additional row for each payment that represents a new item generated by the Payment Predictor. It is actually the join between this table and PS_PP_ITEM_TAO that represents the transactions generated by a payment for a worksheet or pending group.

PS_PP_OCSEQ_TAO

The process uses this table to evaluate the sequence of overdue charge entry reasons in the ENTRY_REASN_TBL.

See Also

Defining Receivables Installation Options

Click to jump to top of pageClick to jump to parent topicReviewing 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. 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 command of another section. If you want to perform a DO command on a section more than once, you use a DO SELECT. The processes perform the section that you specify once for each row that 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:

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:

Section

Description

PREPARE

Builds the temporary tables PS_PP_PYMNT_TAO and PS_PP_ITEM_TAO. For payments containing no references or completely invalid references (PS_PP_ PYMNT_TAO.PP_REF_SW = N), it loads all items for the customers identified through PS_PAYMENT_ID_CUST into PS_PP_ITEM_TAO.

ID_ITEM

Populates the temporary table PS_PP_CUST_TAO with customer identification information for payments with references (PS_ PYMNT_TAO.PP_REF_ STATUS = Y). Platform-specific codes can apply in this section.

First, Payment Predictor determines a list of the types of references that it uses for all payments in the run. Then for each type of reference it uses, it builds a dynamic SQL statement to insert a row into PS_PP_CUST_TAO for each payment. For each type of reference, it runs two SQL statements based on the algorithms CUSTMP1 and CUSTMP2.

For example, if ITEM references were included in any payments in the run, the module would concatenate "AND X.REF_ QUALIFIER_CODE = 'I' AND X.REF_VALUE = I.ITEM)" to the end of the statements and run the statements.

Loaded from the PREPARE section as a DO SELECT, ID_ITEM.

%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'

### 1 line break(s) inserted ###

Payment Predictor accomplishes the same results without a special module for the dynamic SQL. All the SQL is dynamic, and Payment Predictor uses the Application Engine bind variables that are returned from the DO SELECT.

AND X.REF_QUALIFIER_CODE = %BIND(REF_QUALIFIER_CODE)AND X.REF_⇒ VALUE = I.%BIND (FIELDNAME, NOQUOTES)

ID_CUST

Populates the PS_PP_CUST_TAO temporary table with customer identification information for payments with MICR or customer references. This is also done from PREPARE. Platform-specific codes can apply in this section.

AR_PREDICT2 - Executing Method Steps

This table describes the sections that run method steps:

Section

Description

SBLD

This section builds the PS_PP_STEP_TAO temporary table and then performs each step in turn. First, it inserts one row for each step, condition, and action of each method needed to process all payments for all business units requested. For example, if the step has a condition that runs an algorithm and then generates an adjustment for an underpayment, it inserts two rows into PS_PP_STEP_TAO.

It deletes each row upon completion; this table should be empty at the end of a normal run. After the PS_PP_STEP_TAO table is created, the second phase begins.

STEP

The Step Manager, done from SBLD with a DO SELECT. Depending on the step and condition that the system is processing, the appropriate section is done.

GENITEM

Run for each Generate An Item step. It might generate items based on the criteria specified in the method and on the condition of the payment.

WBLD

Run for each Generate A Worksheet step. It might generate worksheets based on the criteria specified in the method and on the condition of the payment.

CNTL_ACT

Run for a control account step.

RELEASE

Run for each release. The payment step uses only the temporary tables. It releases a payment that an algorithm has attempted to apply, enabling subsequent method steps that match the remittance profile to process the payment. When an algorithm finds any items to apply for a payment, another algorithm (or method step) does not consider that payment for application unless a Release The Payment step releases it.

ALGR

Not a true section. A dynamic DO performs the actual run of the SQL contained in the algorithm group, and the section that is run is the name of the algorithm group. The name of an algorithm group must begin with a # and must match the name of a section.

An algorithm is a group of statements in a section. When an algorithm populates PS_PP_MATCH_TAO, it must set the value of PP_PROC_FLAG to 0. Subsequent statements included in the algorithm group enable you to further adjust or refine the answer set contained in PS_PP_MATCH_TAO to:

  • Limit the answer set to just the customers included in the identifying information.

  • Add a unique single debit or credit.

ALGRDONE

Performs system processing after an algorithm populates PS_PP_MATCH_TAO. This includes handling the bulk of the Payment Predictor hold logic, performing the Check Pending option, and eliminating duplicate items from being selected. After it is called, all items selected have PS_PP_MATCH_TAO. PP_PROC_FLAG = 1. This switch changes to 2 after the group of steps is completed—after an Execute Algorithm and then overpayment and underpayment clauses.

ALGRDONE appears in sections at the points where the answer set can be modified. PeopleSoft Receivables implements this in the algorithm groups of #BALANCE, #COMBOS, #PASTDUE, and #STATEMNT.

AR_PREDICT2 - Generating Transactions

This table describes the sections that generate transactions:

Section

Description

UPDM

Updates the matches. This is required to assign sequence numbers needed for building the PS_PENDING_ITEM and PS_PAYMENT_ITEM tables. This is a SELECT, FETCH, and UPDATE operation.

UPDM performs other functions, including building deposits and payments generated during the run, making an additional pass for the check pending option, and handling the orphan payments that have not been processed. In addition, it excludes items that have been selected but that have a different currency from the payment.

PGEN

Generates payment worksheets, group control, and pending items, as needed. These are all set mode operations—a series of SQL statements run, each creating worksheets for a subset of payments.

PUPD

Performs a SELECT, FETCH, and UPDATE of each payment being processed in this run and updates the PS_PAYMENT table accordingly. PUPD exists as an individual section, because it can be replaced with a stored procedure on some SQL platforms.

TERMINATE

Calculates and logs messages for the payment totals and payment amounts either applied, generated to worksheets, or released. Releases the process instances on tables used.