Previous	Next		Contents	Index	Navigation	Glossary	Library

A Lockbox transmission usually includes matching numbers. These are most often transaction numbers to be matched and applied, but they can also be other types of numbers. Lockbox uses the Match Receipts By method that you specify when you submit the program to determine which type of number to search for to match with a receipt. When it finds a match, Lockbox uses the matching number to determine the customer (if AutoAssociate is Yes and the customer or MICR number is not included in the transmission) and to apply the receipt during Post QuickCash.

If Lockbox can identify the customer for a receipt but cannot determine to which invoice this receipt should be applied, it applies the receipt using the AutoCash Rule Set defined for this customer. If Lockbox cannot identify the customer or to which invoice to apply the receipt, it assigns the receipt a status of Unidentified.

Note: In Release 11 of Oracle Receivables, you can only apply cross currency receipts using the Applications or the Mass Apply windows. You cannot apply cross currency receipts using Post QuickCash. For more information, see: Cross Currency Receipts.

Matching Rules

• Transaction Number

• Sales Order Number

• Purchase Order Number

• Consolidated Billing Invoice Number

• Other, user defined number (see below)

If the matched number is a sales order number, Lockbox searches for the first invoice that belongs to this order. Then, when you run Post QuickCash, it will apply the receipt to that invoice.

If the matched number is a purchase order number, Lockbox searches for a reference number that refers to this purchase order. Then, when you run Post QuickCash, it will apply the receipt to that invoice.

If the matched number is a consolidated billing invoice number, Lockbox will be able to identify the customer and Post QuickCash will apply the receipt to the included invoices using the AutoCash rule Clear Past Due Invoices Grouped by Payment Term.

Finally, if the matched number is determined using a custom matching rule, Lockbox uses the number that you specify to determine to which transaction to apply this receipt. See: Implementing a Custom Matching Rule.

If Lockbox cannot find a match after searching for each type of number in the sequence, it applies the receipts using the AutoCash Rule Set defined for this customer.

The following diagram shows how Lockbox applies receipts in a Lockbox transmission using each Matching Rule.

Match on Corresponding Date

AutoCash Rules

• Include the MICR or customer number in your transmission records

• Do not include matching numbers in your transmission records (otherwise, Post QuickCash will apply the receipt to each transaction for which it can find a match)

• Specify an AutoCash Rule set for your customer's profile class (otherwise, Receivables uses the AutoCash Rule set in the System Options window)

• Specify an AutoCash Rule set in the Quick Receipts window before you submit Post QuickCash

Overapplying Invoices

Additionally, if the sign of your application is different from the sign of the balance due on your invoice, Post QuickCash will not apply the receipt and the entire receipt amount will remain unapplied.

Application Rule Sets

Receipt Status

• Unidentified: Lockbox was not able to determine the customer for this receipt.

• Unapplied: Lockbox was able to identify the customer for this receipt, but it could not determine to which transaction to apply this receipt.

• Applied: Lockbox was able to identify the customer for this receipt, determine to which transaction to apply this receipt, and successfully apply the receipt (when you submitted Post QuickCash).

Attention: If you are using the automatic receipts feature, AutoLockbox ignores all transactions that are selected for automatic receipt (i.e. transactions assigned to a payment method whose associated receipt class has Creation Method set to 'Automatic').

Implementing a Custom Matching Rule

This procedure expects a row in the AR_LOOKUPS table with lookup_type = ARLPLB_MATCHING_OPTION and valid values for other columns required for using a customized matching rule. The master program arp_process_lockbox will fetch that row and - if it finds it to be one of the non-standard (i.e. not built in core AR) rows - it will pass the control to this procedure with the corresponding lookup_code in your database. The procedure should return a string that Dynamic SQL can use to open and parse a cursor. You need to create this SQL string to replace the string named p_cursor_string (see example below).

Your string should have the following restrictions:

1. You should only use the following bind variables:

a. b_current_matching_number - This will get a value of a matching_number passed in the overflow or payment record.

b. b_current_matching_date - This will get a value of a matching_date passed in the overflow or payment record.

c. b_current_installment - This will get a value for the installment number (if any) passed in the overflow or payment record.

d. b_customer_id - If the customer is identified using a customer number or an MICR number, the program will enforce that the matching_number is for the same customer (except if the value is 'Y' in b_pay_unrelated_customers).

e. b_pay_unrelated_customers - When you submit AutoLockbox, the program prompts you to choose whether to allow payments for unrelated customers. This variable will get a value 'Y' or 'N' based on the value that you choose.

f. b_lockbox_matching_option - The value of this variable will match to the value of ar_lookups.lookup_code. It is also stored in ar_customer_profiles.lockbox_matching_option and in ar_lockboxes.lockbox_matching_option.

g. b_use_matching_date - This variable will be assigned a value NEVER, ALWAYS, or FOR_DUPLICATES, depending upon the value of the Match on Corresponding Date option for your lockbox (in ar_lockboxes).

2. If you are customizing AutoLockbox using this procedure, be sure that this procedure returns a string that can create a valid cursor and that the SQL returns one and only one row (neither zero nor more than one).

3. The program expects three return values from the SQL statement in the following order:

1. Customer_Id (NUMBER(15))

2. Invoice Number (VARCHAR2(20))

3. Invoice Date (DATE)

4. The program expects that the combination of invoice number and invoice date is unique in ar_payment_schedules.

5. You do not have to use all the bind variables that are provided in your SQL statement. For example:

'from custom_table ct ' ||

'where ct.matching_number = :b_current_matching_number ' ||

'and ct.matching_date = :b_current_matching_date ';

6. The SQL statement must be such that, if it does not match with given matching number and matching date (optional), it must return the following:

trx_number = null,

trx_date = null.

7. If the statement matches to multiple customers but the same trx numbers, it must return customer_id = -7777. The procedure will ignore trx_number and trx_date in this case.

Note: The program calling this procedure does not expect it to return any errors because the definition of a cursor is a one-time procedure and, if done carefully, should not error.

Below is the packaged procedure arp_lockbox_hook.cursor_for_matching_rule that Receivables provides:

-----------------------------------------------------------------*/ PROCEDURE CURSOR_FOR_MATCHING_RULE(p_matching_option IN VARCHAR2, p_cursor_string OUT VARCHAR2) IS

BEGIN

arp_util.debug('arp_lockbox_hook.cursor_for_matching_rule()+');

p_cursor_string := 'select -9999, NULL, NULL from dual';

arp_util.debug('arp_lockbox_hook.cursor_for_matching_rule()+');

RETURN;

END cursor_for_matching_rule;

END arp_lockbox_hook;

COMMIT;

EXIT;

For more information about setting up Lockbox to use a custom matching rule, refer to the files $AR_TOP/admin/sql/ARRLBHKS.pls and $AR_TOP/admin/sql/ARRLBHKB.pls.

See Also

AutoCash

Automatic Receipts

Post QuickCash

AutoLockbox Validation

Commonly Asked Questions

Transmission Formats

Lockboxes