Viewing Algorithm Groups

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

To view an algorithm group:

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

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

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

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

    Some algorithm groups, such as #BALANCE 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), 3, 7) = %Substring(%Sql⇒
(ARCASTCHAR, 
%Bind(REF_VALUE), 30), 1, 7))