Using #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 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 theand select a value in the Control Bus Unit and Customer field: