Lockbox interface

AutoLockbox lets us automatically process receipts that are sent directly to the bank instead of manually feeding them in Oracle Receivables.

AutoLockbox is a three step process:

1. Import: During this step, Lockbox reads and formats the data from your bank file

into interface table AR_PAYMENTS_INTERFACE_ALL using a SQL *Loader

script.

2. Validation: The validation program checks data in this interface table for

compatibility with Receivables. Once validated, the data is transferred into

QuickCash tables (AR_INTERIM_CASH_RECEIPTS_ALL and

AR_INTERIM_CASH_RCPT_LINES_ALL).

3. Post QuickCash: This step applies the receipts and updates your customer’s

balances.

 

Pre-Requisites:

Banks

Receipt Class

Payment Method

Receipt Source

Lockbox

Transmission format

AutoCash Rule sets

 

Interface tables:

AR_PAYMENTS_INTERFACE_ALL (Importdata from bank file)

AR_INTERIM_CASH_RECEIPTS_ALL

AR_INTERIM_CASH_RCPT_LINES_ALL (Validate data in interface table and place in quick cash tables)

 

Base Tables:

AR_CASH_RECEIPTS

AR_RECEIVABLES_APPLICATIONS

AR_ADJUSTMENTS

AR_DISTRIBUTIONS_ALL

AR_PAYMENT_SCHEDULES_ALL

 

Concurrent program:

Lockbox

 

Validations:

Check for valid record type, transmission record id.

Validate sum of the payments within the transmission.

Identify the lockbox number (no given by a bank to identify a lockbox).

 

Some important columns that need to be populated in the interface tables:

AR_PAYMENTS_INTERFACE_ALL:

STATUS

RECORD_TYPE

LOCKBOX_NUMBER

BATCH_NAME

TRANSIT_ROUTING_NUMBER

ACCOUNT

CHECK_NUMBER

REMITTANCE_AMOUNT

DEPOSIT_DATE

ITEM_NUMBER

CURRENCY_CODE

DEPOSIT_TIME

LOCKBOX_****

Once the lockbox data is received from banks, move it to a directory, normally a data

directory. Control file will be placed in $AR_TOP/bin/ as a .ctl file. Once can customize the

layout and ctl file by deciding what data you will be receiving and what format will be used.

Autolockbox has three steps:

Import: Reads the lockbox data from bank file, moving it to the lockbox tables using SQL*

loader script.

Validation: The validation program checks data in the AutoLockbox tables for compatibility

with Receivables. Once validated, the data is transferred into QuickCash tables. At this point,

you can optionally query your receipts in the QuickCash window and change how they will

be applied before submitting the final step, Post QuickCash.

Post QuickCash: This step applies the receipts and updates your customers’ balances.

In the Submit Lockbox Processing form:

Check - Submit Import.

Enter the "Transmission Name" for this transmission (Give any suitable name for your

transmission). Note this name for future use.

For Data file field, enter the data file name along with full path

Enter the control file name.

Select the Transmission Format Name.

Check Submit Validation.

Select the applicable Lockbox.

Allow Payment of Unrelated Invoices – Better not to check this.

Enter the appropriate date in the GL Date (usually the deposit date). This will usually default

to system date.

Select the Report Format you wish to use (usually ‘All’).

Check - Complete Batches Only.

Check - Submit PostQuickCash.

Save.

The Lockbox Execution Report will indicate if the data was imported and validated. It also

lists the possible exceptions and what they mean. If the data fails the import, the entire

transmission fails and will need to be run again.

Common errors would be with count and total amounts at the transmission, Lockbox,

batch or at transaction level. You may use the Maintain Transmission data form to correct

many errors. Select the "Transmission Name" of the transmission you wish to fix and start

your query. You will see all of the records that make up the transmission, along with the

status for each record. Position the cursor on the record you wish to correct and Click on the

Button for the data with the error. Correct the error on the appropriate page, and return to

the first form. Move to the next record to fix and continue until you have corrected every

error.

We can continue the cycle of correcting and validating the data until all records have been

"transferred" as indicated on the Lockbox Execution Report.

For re-running the validation, return to submit Lockbox Processing form.

Do not check - Submit Import.

Enter the "Transmission Name" you noted above.

Do not check - Allow Payment of Unrelated Invoices.

Select (List) the applicable Lockbox.

Enter the appropriate date in the GL Date (usually the deposit date).

Check - Submit Validation.

Select (List) the Report Format you wish to use (usually Rejects only for the subsequent

passes).

Check - Complete Batches Only.

Do not check - Submit PostQuickCash. ( Let us check this when whole validation gets over and

we have proper data)

Save.

When all records are "transferred," they will be moved from the Lockbox tables to the tables

used by QuickCash (the Interim Cash Receipt tables).

To apply the receipts, select the "Transmission Name" and Check Submit PostQuickCash.

Return to the Submit Lockbox Processing form:

Do not check - Submit Import.

Enter the "Transmission Name" you noted above.

Do not check - Submit Validation.

Check - Complete Batches Only.

Check - Submit PostQuickCash.

Save.

After receipts get created, we are allowed to make chaneges through form also

AutoLockBox Feature : LockBox Functionality ------------------------------------------ Normally for any company doing business , they have a Accounts Receivable(AR) system. That is ,they receive all kinds of receipts like cash, checks, credit cards, direct debits etc. However the company by itself would not receive all these receipts. Generally all these receipts would go to a different PO box address typically known

as Lockbox and from there, the bank would collect all these receipts, deposit money, summarize them and then send that information to the company. All these transactions go into the company's receivable system. So this information would come as a batch of records with count and amount. However for all these transactions, the actual cash is already remitted into their bank. Usually when we setup a lockbox in the AR system, we have to provide a lockbox number. This is a reference to the number of origin of the bank data file. Basically, you should be able to use any number you want, as long as the number is unique. So no, it's not a mandatory number that should be provided by your bank.

In Oracle Receivables, the Lockbox process would mainly consist of three steps and they are... 1. Using the sqlloader, import the flat file obtained from bank in a specific format (ex EDI 820,BAI). Once the import process completes, the data will be loaded into AR_PAYMENTS_INTERFACE table. And the process also generates the Lockbox execution report. 2. QuickCash step: Lockbox Validation. The data that is loaded into AR_PAYMENTS_INTERFACE table is now validated by this process and the validated results are written to AR_INTERIM_CASH_RECEIPTS_ALL and AR_INTERIM_CASH_RCPT_LINES_ALL tables and the log is written to Lockbox execution report. If the validation fails, then the process will not write any data into the interim table and we need to fix the report errors. 3. Post QuickCash. Once the data is validated, this validated data is written into the actual AR Receivables tables(like AR_CASH_RECEIPTS etc) and we also get a QuickCash Execution Report. Also this program will look for the AutoCash Rule sets which (i.e whether the oldest invoice or the highest invoice etc).

So we can summarize this as AR_PAYMENTS_INTERFACE ==> AR_INTERIM_CASH_RECEIPTS => AR_CASH_RECEIPTS_ALL etc. The Lockbox process, is where the bank gives us the statement periodically consisting of complete receipts and we try to apply to the debit items/on account using the autocash rules.(i.e whether the oldest invoice or the highest invoice etc). (However for reconciliation purposes, the bank can provide all the activity completely until that point, which includes the payments and receipts. And if you try to start the AutoReconciliation process in Cash Management, it will match it against the receipts in the receivables and invoices in payables systems). Lockbox processing is a little bit different from the regular receipt processing. In the case of lockbox,the receipts are created after we get the file from the bank. However in the case of regular receipt processing, first we create the receipt, remit and clear and then the cash is deposited in the bank. In the lockbox, the cash is already deposited in the bank and the bank sends the file to us and then we create the receipts in our AR system. The following are the steps involved in how the Autolockbox applies receipts : Receivables applies the receipts in a lockbox to the transactions during the PostQuickCash process.*/

-- If you create a lockbox,then it would show up in this table select lockbox_id,lockbox_number, status,bank_origination_number, batch_size,telephone,receipt_method_id, org_id

from ar_lockboxes_all order by lockbox_id /* Actually the hierarchy is that for each lockbox, we can multiple transmissions. And for each transmission, the bank can send in multiple batches. Actually we may not have any values for batch name and amount as it is not mandatory Lockbox => Transmission => Batch */ INSERT INTO ar_transmissions_all (transmission_request_id, transmission_id,transmission_name, trans_date, count, amount,status, requested_lockbox_id, requested_gl_date, org_id, requested_trans_format_id,created_by,creation_date,last_updated_by, last_update_date) VALUES (922,822,'MyTransmission22',sysdate,1,500, 'OP',1200,SYSDATE,44,1080, 1626,sysdate,1626,sysdate) select transmission_request_id,transmission_id, transmission_name,trans_date, time,count, amount,status, requested_lockbox_id, requested_gl_date, org_id , requested_trans_format_id,creation_date from ar_transmissions_all where requested_lockbox_id= 1200 and transmission_name ='MyTransmission22' --- order by trans_date desc -- where requested_lockbox_id in(1200,1020) and transmission_name in -- ('NTDP081202','MyTransmission3') --- order by trans_date desc AND count >0 ------

select * from ar_transmission_formats where transmission_format_id =1020 -- ar_trans_record_formats ar_payments_interface_v

/* Just a word on the record types in Lockbox processing: Each lockbox will have specific file format which will be sent by the bank. Oracle provides some standard predefined transmission formats like DEFAULT (Which is of the type BAI - Bank Administration International format). This is made up of a set of record types. These record types are all predefined and when we create a transmission format we define the sequence of these record types according to what we want. So we can define any kind of transmission format that we want, that suits our business needs. Ex of the record types are Transmission Header, Transmission Trailer, Lockbox header, lockbox trailer, Overflow payment, Payment(or receipt), Service Header. Just as we have a set of predefined record types, we also have a set of predefined field types. What we do is we pick a record type ,say ,Payment and click on the tranmission fields and here we choose what fields and the sequence of those fields. Exs of field types are transit routing number,account,remittance amount,deposit date etc */

insert into ar_payments_interface_all (transmission_request_id, transmission_id,transmission_amount,record_type,org_id, customer_number,customer_id, --batch_name, batch_amount,

lockbox_number,lockbox_batch_count,lockbox_amount,lockbox_record_count, receipt_date,receipt_method_id,check_number,item_number, remittance_amount,remittance_bank_name,remittance_bank_branch_name, --invoice1,amount_applied1, gl_date, creation_date, last_update_date, deposit_date, transmission_record_id,currency_code, transmission_record_count) values (999,888, 1000,1,44, 296577, 309319, 1200,1,500,1, '24-MAR-2006',1793,'CHK13',1, 500,'BOA','Mountain View', --'1190011566',500, sysdate, sysdate, sysdate , sysdate, 1,'USD',1) select batch_name, batch_amount, transmission_id,transmission_amount,record_type,org_id, customer_number,customer_id, lockbox_number,lockbox_batch_count,lockbox_amount,lockbox_record_count, receipt_date,receipt_method_id,check_number receipt_number, remittance_amount,remittance_bank_name,remittance_bank_branch_name,remittance_amount, invoice1,invoice2 , status, gl_date, creation_date, last_update_date, deposit_date ,transmission_record_id,record_type, currency_code, receipt_method_id,item_number,transmission_record_count from ar_payments_interface_all --where lockbox_number is not null where transmission_request_id = 902 COMMIT; /* During the Validation phase the lockbox processing will check for different things like , -- Ensure that the receipt number is there. (i.e the check number) -- Item number should be there , which should be unique, in a batch, transmission or lockbox. -- Receipt has invalid applications Once all the validation is complete , the rows are inserted into the ar_interim_cash tables.*/

-- Now let us insert a row in ar_payments_interface_all with no customer number information or the combination-- of the (routing#,account#) and with the AutoAssociate being set to true. insert into ar_payments_interface_all (transmission_request_id, transmission_id,transmission_amount,record_type,org_id, --customer_number,customer_id, --transit_routing_number, account, --batch_name, batch_amount, lockbox_number,lockbox_batch_count,lockbox_amount,lockbox_record_count, receipt_date,receipt_method_id,check_number,item_number, remittance_amount,remittance_bank_name,remittance_bank_branch_name, invoice1,--amount_applied1,

gl_date, creation_date, last_update_date, deposit_date, transmission_record_id,currency_code, transmission_record_count) values (922,822, 1000,1,44, --296577, 309319, 1200,1,400,1, '24-MAR-2006',1793,'CHK922',1, 400,'BOA','Mountain View', '1190011566',--400, sysdate, sysdate, sysdate , sysdate, 1,'USD',1) /* Now run the second step of Validation. Now since the customer information is missing and since the AutoAssociate is set to true, then it should go by the lockbox setting, "Match Receipt by" and if it is transaction number, then it associates this receipt to that particular transaction.

The following 4 points summarize the complete functionality of how the lockboxes identifies and applied to receipts. If the customer# or MICR(routing#,account#) is provided, then the customer is identified. If the customer# or MICR is not provided, AND Autoassociate is set to YES (and say the invoice# is provided) then the lockbox will try to apply the matching rules. and apply the receipt amount to that particular invoice. So in this case, the customer is identified and the status of the receipt is APP. (If the invoice amount is already 0, and if the overapplication profile option is No, then the status of the receipt will be UNAPP), otherwise the receipt will be applied and the status will be APP. If the customer# or MICR is not provided, AND Autoassociate is set to YES (but invoice# is not provided) So in this case, the customer is NOT identified and the status of the receipt is UNAPP. If the customer# or MICR is not provided, AND Autoassociate is set to NO (so no matching rules applied etc) So in this case, the customer is not identified and the status of the receipt is UNAPP. -- If the profile option AR:OverApplication of Invoices is set to 'Yes', then the invoice balance can go into negative after application.If it is set to No,and if the invoice balance is already 0, then the receipt amount will be in UNAPP status. */

/* Here one important point is that even if the receipt is unidentified, the column "status" will show a value of UNAPP ,but the "special_type" column will have a value of UNIDENTIFIED.*/ select cash_receipt_id,amount,pay_from_customer,type,status, special_type, receipt_number,gl_date from ar_interim_cash_receipts_all

/* There are 2 interim cash tables in lockbox. Once a receipt is validated it figures in the table ar_interim_cash_receipts_all and if there are any applications, then they go into the ar_interim_cash_rcpt_lines_all table. So if a particular receipt is applied against 2 invoices, then the lines table will have 2 lines,corresponding to header cash_receipt_id ar_interim_cash_receipts_all.*/

select * from ar_interim_cash_rcpt_lines_all /* Now after we run the post quickcash program, these receipts are transferred from the interim cash tables to the cash_receipt table ar_cash_receipts_all and ar_receivable_applications_all tables. Interestingly, the same cash_receipt_id in interim tables is preserved in the ar_cash_receipts_all table.*/ select * from ar_cash_receipts_all where receipt_date >= '24-MAR-2006' ORDER BY creation_date desc /* Generally sometimes in some of the columns in tables, some of the values might be strings like OOB, or constants like 1,2 and we dont know exactly what they mean. In such case, we can try to get the meaning of those from the lookup tables. For ex, */ select * from ar_lookups where meaning = '8' --lookup_code like '%TYPE%' --code = '8'

/* Overflow Indicator indicates whether there are any further records for this particular receipt. Let us say a particular receipt is there,apart from the usual header and trailer,you might have the payment record type which will consist of fields like (lockbox#,routing%,customer bankacct#,amt,date,check# etc). Now the overflow record will consist of invoice information etc,i.e info like (receipt#, invoice#, amount applied,overflow indicator etc) Typically the overflow indicator value of 0 indicates that there are further overflow records and a value of -9 indicates that it is the last record. */ SELECT arm.NAME, arm.receipt_method_id, arc.creation_method_code, arm.NAME, arm.receipt_method_id, arc.creation_method_code FROM ar_receipt_methods arm, ra_cust_receipt_methods rcrm, ar_receipt_method_accounts arma, ap_bank_accounts aba, ar_receipt_classes arc WHERE arm.receipt_method_id = rcrm.receipt_method_id AND arm.receipt_method_id = arma.receipt_method_id AND arm.receipt_class_id = arc.receipt_class_id AND arma.bank_account_id = aba.bank_account_id AND aba.set_of_books_id = 1 AND arm.receipt_method_id = 1002

/*Before we talk about the Automatic receipt creation process let us talk about the Manual Receipts.

Manual receipts are those which do not require any remittance. Let us explain this. Typically when a receipt is automatically generated i.e the Automatic Receipt Generation Program has generated that receipt. That kind of receipts will require the remittance, i.e the receipt has originated from the AR side. These receipts are called automatic receipts. Any other receipts are called Manual receipts; i.e the after the remittance has happened, the receipts are created either thru the lockbox or entered manually thru the form. See ,receipts for ex, checks, are never sent directly to the AR dept and they never enter manual checks in the form. Receipts typically checks are sent to a location called lockbox and from there they go to a bank and the bank prepares and sends the remittance advise to the customer banks,collects the money and then sends the lockbox file,containing the payment information to the company AR dept. This lockbox file is then loaded into our systems. All such receipts created are of payment type Manual.*/ -- Step by Step Lockbox Testing Process : ------------------------------------------ select transmission_request_id,transmission_id, transmission_name, trans_date,time, count, amount, status, requested_lockbox_id, requested_gl_date, org_id , requested_trans_format_id,creation_date from ar_transmissions_all where transmission_name = 'NTDP09142006' order by creation_date desc -- Get the transmission id from the above query. select * --count(*) -- 340 from ar_payments_interface_all WHERE transmission_id = 49302

/* The number of lines that are in the flat file is the number of records that we see in this table. The verisign flat file : The file itself is consisting of a different number of batches, with each batch consisting of fields like that batch amount, control count etc. That is for each set of records,called a batch, there will also be a record which gives the sum of that batch receipts. This record is preceded by a record identifier 7. Similarly for the entire transmission, there will be another record which will give the sum of all the receipts corresponding to the entire transmission.Similarly this record is preceded by a record identifier 7. */ select Batch_name, Batch_amount ,lockbox_number,lockbox_batch_count,lockbox_amount,lockbox_record_count ,Transmission_id,Transmission_amount,Record_type,Org_id ,customer_number,customer_id ,receipt_date,receipt_method_id,check_number receipt_number ,remittance_amount,remittance_bank_name,remittance_bank_branch_name,remittance_amount ,invoice1,invoice2 ,status ,gl_date, creation_date, last_update_date, deposit_date ,transmission_record_id,record_type, currency_code

,receipt_method_id,item_number,transmission_record_count from ar_payments_interface_all --where lockbox_number is not null where transmission_id = 49302

/* Some times you might get an error" invalid applications" which means the invoice information/number that appears in the overflow record in not there in the AR system and hence the lockbox process does not know to whom it should be applied. Also if the period is not open, you might get an error. */ /* The best way I believe is to open up the lockbox file,which is usually a text file and open up the transmission formats from and see what are the payment and overflow record identifiers. The payment record contains the receipt information while the overflow record contains the invoice information. Once we do that we need to see what is the starting and ending positions for these fields,pick up the invoice# and receipt# and then pull up those in the Oracle applications.*/ select sum(remittance_amount),sum(batch_amount), batch_name from ar_payments_interface_all where transmission_id = 49302 group by batch_name select remittance_amount, batch_amount ,batch_name from ar_payments_interface_all where transmission_id = 49302 and batch_name = 7 /* Even right after the first step is completed, the transmission table can show an error of OOB (out of balance) what this means is that the sum amounts are not adding up to the individual amounts. For ex,Batch amount column may not be adding up to the sum of the remittance amounts for a particular batch. Lockbox amount may not be adding up to the sum of all the receipt amounts. Transmission record count may not equal the total number of records,i.e let us say if the flat file has in total 340 lines, the transmission trailer line should show a value of 340. The above point can be simply verified by running the below query. */ select sum(remittance_amount) sum_rmt_amount, sum(batch_amount) sum_batch_amount, batch_name batch_name from ar_payments_interface_all where transmission_id = 49302 group by batch_name /* IMPORTANT: Receipt number and payment number is always part of the lockbox file. If the receipt number is already existing in the AR, then it fails. And receipt number should never be system generated (i.e it should not be generated by a document sequence etc)*/ ---- update ar_payments_interface_all set gl_date = gl_date + 30 where transmission_id = 49302

---- Once the validation part completes,the records should be found here. select * from ar_interim_cash_receipts_all -- what kind of records are found here. select * from ar_interim_cash_rcpt_lines_all /* Now during the 3rd step, the post quick cash completes and records should go to AR and the applications should happen, in ar_receivable_applications_all */ select * from ar_cash_receipts_all where creation_date >= trunc(sysdate) -- 140

select * from ar_cash_receipt_history_all where creation_date >= trunc(sysdate) --140

-- We can find out which receipts are created by going to the Receipts => Batch Summary /*and there query by the Transmission Name which is coming from all along.Here we see that the receipt batches are created consisting of the unidentified and unapplied receipts.Each record corresponds to a transmission batch coming from the file. We can try to correlate the data here with the flat file and ,open the

receipts and try to correct the data,like enterting the customer name etc.