lockbox file creation guide

LOCKBOX FILE CREATION GUIDE FOR

BAI & BAI2 FORMATS

Understanding SAP Lockbox 04/11/23

SAP

OverviewWhat is a lockbox? A company can create accounts called ‘lockbox’ accounts at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers’ remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two standard banking industry transmission formats: BAI and BAI2.

What is BAI? The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). Founded in 1924, the BAI organization is a partnership composed of its own BAI membership, a Board of Directors, various banking industry advisory groups and a professional staff. The organizational mission is “to help bank administrators achieve high levels of professional effectiveness and to help solve significant banking problems.” Activities include the definition of industry file formats, such as lockbox transmissions. BAI and BAI2 are the two defined lockbox transmission formats, however, BAI is considered ‘outdated’ by the BAI organization and is no longer supported (ie. standards are no longer updated or improved). Nonetheless, many banks still offer transmissions in the old BAI format.

What is the difference? BAI and BAI2 formats differ in their level of information detail. BAI does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as: 1. an “On account” posting (if the payment and invoice totals don’t match), or 2. an “Unprocessed” posting (if no customer account and documents could be identified from the transmission). In these scenarios, your Accounts Receivable cash application clerks will have to perform manual application to clear payments against open items on the proper accounts.Conversely, BAI2 splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a “Partially applied” status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your ‘hit rate’ percentage of payment-invoice matching from each transmission is likely to be higher when using BAI2 rather than BAI formats.

What should you use? This decision is dictated by a cost-benefit analysis. BAI2 is a more robust file format, but you pay more for this information richness. BAI is cheaper, but may not offer you a suitable ‘hit rate’ for automatically matching payments to customer open items. If you receive a large volume of lockbox payment transmissions each day, it is recommended that you use BAI2. Otherwise, a significant portion of your A/R staff time and effort will be spent on applying failed lockbox payments. However, if you only receive a small portion of your customer payments via lockbox transmissions, then BAI is likely to provide adequate results. You will have to inquire with your bank to ensure that they still utilize the BAI formats.

If you have further questions about the Bank Administration Institute, or its file format standards, you can reach them by phone at 800-224-9889, or on the Internet at http://www.bai.org.


THE PURPOSE OF THIS DOCUMENT:

The lockbox file generation programs within SAP (RFEBLBT1 and RFEBLBT2) are designed to create their own open items in the system, and create the corresponding lockbox file that perfectly matches these open items. The result is that the open items are completely cleared by the program. This is useful for illustrating the basic function of reading a basic lockbox file. However, for consultants to test their client’s own unique, complex lockbox import and postprocessing scenarios, a more flexible method of lockbox file creation is needed.

This document is designed to do two things:

1. To clearly explain the elements of a lockbox file (in both BAI and BAI2 formats)

2. To help consultants to design their own custom lockbox files which enable them to test numerous business scenarios in a quick, repeatable fashion.

At the end of this document are several different examples of .txt files that illustrate how each file can be modified to test different business scenarios. The specific lockbox files in this document were designed as part of the creation of lockbox preconfiguration for the 4.5A release. These files may be modified as often as you need to test each scenario. There are also a few configuration tips included at the back of the document that relate to how to maintain file format consistency with what is defined within lockbox configuration.

This document is written using color-coding to allow easier reading and interpretation of the data than if using variable fonts, underlining, etc. If you intend to print out this document for your reference, you will need to use a color printer.


LOCKBOX BAI TEMPLATE FOR USE WITHIN THE LOCKBOX DATA IMPORT PROGRAM

Sample Lockbox file:

100YPCCDESTINYPCCORIGIN98121512012YPCCDESTINYPCCORIGIN50010010012345981214YPCCDESTINYPCCORIGIN60010020001000000011000390997755331 00091230200180000190018000020001800002140010036017180000220018000023001800002400180000250018000026001800002740010046019001800002870010050012345981215010000100000080010060012345981215001000010000009 1000000 10000009000010

Note: this file illustrates a scenario in which only one lockbox transmission is imported, and only one batch exists within that lockbox transmission. A lockbox import file may contain several different lockbox transmissions (from different banks) each contained between their own 1 and 9 records. Further, multiple batches can exist within a single lockbox.

The following pages provide a breakdown of the lockbox file components. By identifying what elements go in which place, you can insert your own specific MICR (Magnetic Ink Character Recognition) numbers and invoice numbers, lockbox number, date, payment amount(s), check number(s), and batch numbers to create a valid test file. The record data is color-coded below to make it easier to interpret this file. All files should be saved in a text tab-delimited format (.txt).

KEY:

* Items you must change each time you run the lockbox with this file.

* a conditional change item.

Record 1: (Table FLB01)

100YPCCDESTINYPCCORIGIN98121512010000011111222223333344444555556666677777888 * * * *

This is the first record of the Lockbox. The item in blue is the Record Type indicator. There will only be one Record Type 1 in the Lockbox file. Record Type 1 is the “Header Record”. (Field name HR001)

The item in green is the Priority Code of the Lockbox. This item will have 2 characters (must fill both spaces, i.e. “1” is “01”). (Field name HR002)

The item in dark red is the Immediate Destination for the Lockbox. This will contain up to 9 characters (use spaces to fill up excess space if less than 9 characters exist in this item). Change this item if you want a different lockbox. The same goes for the next item. (Field name HR003)

The next item in black is the Origin of the Transmission – transit routing. This item may contain up to 10 characters (again filling up all ten spaces. (Field name HR004)

Following that are the File Date in dark blue and the File Time in purple. They will have six and four characters respectively. The program will require that the time be


different for each running of the same lockbox in the same day. Be sure to change the lockbox file date in order to reflect the transmission date of the simulated lockbox file. If you are using the same date on multiple files, you will have to be sure to change the transmission time. (Field name HR005, HR006)

The remainder of the record is made up of 47 characters of filler (or blank spaces) marked here in gray. (Field name HR007)

The total length for this record is 80 characters. Spacing is critical because the Lockbox program reads the file based on character position. Therefore, use spaces or zeros to make up the excess space not used by an item within the record. For example, if your Origin of Transmission only uses 8 characters, then it should be preceded by two blank spaces. If the spacing is off in any of the records, the program will misread the file and your lockbox process will fail.

Record 2: Table FLB02

2YPCCDESTINYPCCORIGIN * *

The item in blue is the Record Type indicator. Record 2 is the “Service Record”. From an SAP perspective, the 2 Record is not a mandatory record for lockbox importing. Some banks will utilize a 2 Record, others will not. Sometimes the information contained within this record will not adhere to the ‘proper’ definition, but rather be a restatement of the Record 1 (as shown above). If used, there can only be one Record Type 2 per lockbox transmission. There can be many lockbox transmissions within a single file, thus many 2 Records within the file. (Field name SR001)

The item in green is the lockbox Destination/Origin. This item will have 2 characters. (Field name SR002)

The item in dark red is the Reference Code for the lockbox. It is not generally used, but may be filled with information. This will contain up to 10 characters. (Field name SR003)

The next item in black is the Service Code for the lockbox, which the banks use for their own purposes to identify the transfer as a lockbox transfer. This item will use 3 characters/spaces. (Field name SR004)

Following that is the Record Length in dark blue, which will use 3 characters/spaces. (Field name SR005)

In purple is the Block Size of the lockbox (3 characters/spaces). (Field name SR006)

In dark yellow is the Format Code for the lockbox (1 characters/spaces). (Field name SR007)

The remainder of the record is made up of 40 characters of filler in gray. (Field name SR008)

The total length for this record is 80 characters. Be sure to pay attention to spacing!

Record 5: Table FLB0550010010012345981215YPCCDESTINYPCCORIGIN1111122222333334444455555666667777788888 * * * * * *

The item in blue is the Record Type indicator. There will only be one Record Type 5 per batch within the Lockbox file. Record 5 is the “Detail Header Record”. There can be many batches in a lockbox transmission, thus many 5 Records in each lockbox. (Field name DH001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. If you run this particular lockbox numerous times in the same day, you must change the batch number – the system will not allow the same batch to be input twice in the same day. (Field name DH002)

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DH003) You only need to change this number if you intend to use a new batch. Batch size is defined between the customer


and the bank. A common rule is that one batch may contain up to 50 invoices. Thus, when more than 50 invoices are included in a lockbox transmission, a second batch will be created. One lockbox transmission may contain up to 999 batches.

The next item in black is the Lockbox Number. This item will use 7 characters/spaces. (Field name DH004) The lockbox number only needs to change if you are testing a transmission from a new lockbox, or if the transmission contains information from several lockboxes, you must be sure to change the lockbox number in the appropriate section of the file.

Following that is the Deposit Date in dark blue, which will use 6 characters/spaces.(Field name DH005)

In purple is the Immediate Destination of the Lockbox (10 characters/spaces). (Field name DH006)

In dark yellow is the Origin of Transmission – transit routing (10 characters/spaces). (Field name DH007)

The remainder of the record is made up of 40 characters of filler in gray. (Field name DH008)



600100200010000000110003909977553310009123020018000019001800002000180000210 * * * * * * * * *

The item in blue is the Record Type indicator. Record Type 6 can appear numerous times in the Lockbox file. Record 6 is the “Detail Record” which applies to a particular check in the Lockbox. (Field name DR001) When you have a new check, or a new customer’s information within the same batch, you will create another Record 6.

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. As mentioned before the batch number must change when done consecutively in the same day. (Field name DR002) The bank sets the rules for how a batch is defined. For example, some banks will deliver up to a maximum of 50 checks in one batch. If there are 51 checks in a lockbox, thus there would be at least 2 batches.

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DR003)

The next item in black is the Remittance Amount for the Lockbox Record. This item will use 10 spaces (use zeros if necessary in front of the amount). (Field name DR004)

Following that is the Remitter Identifier: Transit Routing No. in dark blue, which will use 9 characters/spaces. The standard delivered SAP lockbox allows for only a 9-digit bank account number. As with any field that you may need elongated, you will have to submit a modification request for an ABAP consultant to change the number of characters allowed in the field.

In purple is the Remitter Identifier: Account Number (10 characters/spaces). It complements the Transit Routing No. element of the lockbox identification in what is known commonly as the “MICR” data (Magnetic Ink Character Recognition). This is the data that appears at the bottom of bank checks. Together, they provide a unique identification of the customer sending in the payment.

In dark yellow is the Check Number (9 characters/spaces). This item must change each time you run a batch. (Field name DR007)

In bright red are the Invoice Numbers (10 characters/spaces each). According to SAP table definition, only 3 invoices can fit into the Record 6. Any extra invoices in that check and lockbox batch must be provided in a Record 4 that follows immediately after the Record 6. Be careful to check that the invoice numbers are correct, and in the proper spaces.(FIf you are using SAP document number length of less than 10 digits, it is recommended that you use a right-justified, zero-padded left field convention (as displayed in the sample Record 6).

The remainder of the record is made up of at least 5 characters (depending upon how many invoices are in this record) of filler in gray. (Field name DR011)



Record 4 Table FLB04

4001003401700180000220018000023001800002400180000250018000026001800002700000 * * * * * * * *

The item in blue is the Record Type indicator. Record Type 4 can appear numerous times in the Lockbox file. Record 4 is the “Overflow Record” and it is used to hold invoices beyond the 3 that can be held in the preceding Record 6 for a particular invoice. (Field name OR001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name OR002)

The item in red is the Record Type identifier(1 character). This record is the overflow record (4 Record) holding the overflow from the 6 Record, and thus the number is a 6 to indicate where its overflow originates. It holds all extra invoices overflowing from the maximum of three allowed in the 6 Record. (Field name OR003)

Bright green is the Sequence Number for the record (2 characters). (Field name OR004)

The item in yellow is the End Indicator for the Lockbox. A ‘9’ indicates the last record of a Lockbox (1 character). (Field name OR005)

The next items in black are the Invoice Numbers (10 characters/spaces each). A maximum of six invoices can fit into the 4 record. If there are more than nine invoices being sent in one check, you will have to use consecutive 4 Records to handle the overflow. For example, if twelve invoices arrive in one check, three will be held in the 6 Record, six on the 4 Record, and the remaining three on a second 4 Record. (Field name OR006-OR012) If you are using SAP document number length of less than 10 digits, it is recommended that you use a right-justified, zero-padded left field convention (as displayed in the sample Record 4).

The remainder of the 4 Record is made up of at least 9 characters (depending upon how many invoices are in this record) of filler in gray. (Field name OR013)



700100500123459812150100001000000 * * * * * *

The item in blue is the Record Type indicator. Record Type 7 appears only once per batch in the Lockbox file. Record 7 is the “Batch Total Record” which signifies the end of the batch within the lockbox. If you have five batches in a lockbox, you will have five 7 Records. (Field name DH001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name DH002)

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 character spaces). (Field name DH003)

The next item in black is the Lockbox Number (7 characters/spaces). (Field name DH004)

Following that is the Lockbox Deposit Date in dark blue, which will use 6 characters/spaces. (Field name DH005)

In purple is the Number of Remittances Indicator (3 characters/spaces) for the batch within the lockbox. This should change based on the number of remittances in the lockbox file. (Field name DH006)

In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces – fill with spaces or zeros to take up space). These items should be changed to reflect the batch totals from the checks on the 6 Records in the lockbox. (Fie

Filler spaces or characters may take up the remaining 47 positions. (Field name DH008)



800100600123459812150010 10000009 1000000 10000001111122222333334444455 * * * * * * * * *

The item in blue is the Record Type indicator. Record Type 8 appears only once in the Lockbox file. Record 8 is the “Service Total Record” which signifies the end of all Lockbox bundles. (Field name ST001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name ST002)

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name ST003)

The next item in black is the Lockbox Number (7 spaces). (Field name ST004)

Following that is the Lockbox Deposit Date in dark blue, which will use 6 spaces. T005)

In purple is the Number of Remittances Indicator (4 spaces). This should change based on the number of remittances in the lockbox file. (Field name ST006)

In dark yellow is the Remittance Dollar Total for this Lockbox (10 spaces – fill with spaces or zeros to take up space). These items should be changed to reflect the batch totals from the 4 and 6 records in the lockbox. (Field name ST007)

In bright red is the Last Record Indicator(1 space). A ‘9’ indicates the end of the record. (Field name ST008)

Also in dark yellow are the TM Amount and MTD Amount for the Lockbox (11 spaces each). (10) These are not often utilized by the customer, but are delivered in standard SAP. They can be left blank, or populated with the lockbox remittance total dollar amount.

The remainder of the record is made up of 22 characters of filler in gray. d name ST011)


Record 9:

9000010

* The item in blue is the Record Type indicator. Record Type 9 appears only once in the

Lockbox file. Record 9 is the “Trailer Record” which signifies the end of the Lockbox file. In a file with multiple lockbox transmissions from separate banks, there will be a 9 Record at the end of each transmission. (Field name TR001)

The item in green is the Number of Records indicator. This item will have 6 characters. (Field name TR002)

Following this record item, there will be a Filler Record of 73 spaces, which can be either filled with characters or left blank. (Field name TR003)

NOTES:1. Whenever you load a particular Lockbox number into bank storage by running the Lockbox program, it will not

allow you to run the same Lockbox number at the same time on the same date. Thus, you will have to : a.) change the File Creation Time, b.) change the Lockbox batch number, and c.) change the check numbers.

2. You must be sure to use different Invoice Numbers each time you run the Lockbox file, otherwise the payments will be identified as being already cleared and thus placed “on account”.

3. When a Lockbox file fails, and the item is left “on account” and a payment advice is created, you will have to remove the payment advice by performing lockbox post-processing and clear the item off the account, or else your next Lockbox run will also not apply itself because an advice and cash exist on the account to clear the open item(s).

4. When lockboxes fail, they need to be processed under Lockbox Postprocess. You will identify the lockbox you just ran by the batch number.

Be very careful when making new data entries into the file to ensure that you observe the spacing rules – otherwise you will have data misread by the program and no payments will be applied.


BAI Issues:

When the customer pays at gross, despite being entitled to discounts under the payment terms, the lockbox will not ignore the payment terms to allow the payment at gross to be applied. It will treat the payment difference as being outside of customer tolerance limits and post the payment onto the customer account. Conversely, the BAI2 format is supposedly capable of ignoring payment terms on an item in the event that the customer is paying the item at gross.

All deductions taken in a BAI transmission must be manually processed through post-processing, whereas in BAI2 format items can be paid with deductions accompanied by reason codes (using external reason code conversion).


LOCKBOX BAI2 TEMPLATE FOR USE WITHIN THE LOCKBOX DATA IMPORT PROGRAM

Sample Lockbox file:

100YPCCDESTINYPCCORIGIN98121512022YPCCDESTINYPCCORIGIN50020010012345981215YPCCDESTINYPCCORIGIN60020020000090000011000390556677889 0102034194002003601716000002 00000100000000000000gh4002004602918000018 00001000000000000000gh70020050012345981215002000009000080020060012345981215000200000900009 0090000 00900009000002

The Principle: What is different between the BAI and BAI2 formats?

In the BAI format, the file can use the “6 Record” to hold the first three invoices, and consecutive “4 Records” to hold the overflow of up to 6 invoices each, per check. The dollar amount is given for that check, not for each individual invoice.

The BAI and BAI2 formats use the same record types for 1, 2, 5, 8, and 9.

In the BAI2 format, the file uses the “6 Record” as an identifier of the check dollar amount, the MICR number and the check number. No invoices are contained in this record. Following the “6 Record” are a series of “4 Records” which contain one invoice each, providing the invoice number, invoice dollar amount, deduction amount and external reason code.

This level of detail in the BAI2 record improves the “hit rate” for the lockbox program. Thus, it costs more. Why? Because the bank has its clerks enter in more information into the file, which takes more time. However, cost-benefit analysis should be performed by each customer to justify the decision.

The following pages provide a breakdown of the lockbox BAI2 file components. By identifying what elements go in which place, you can insert your own specific MICR and invoice numbers, lockbox number, date, payment amount(s), check number(s), and batch numbers to create a valid test file. The record data is color-coded below to make it easier to interpret this file. All files should be saved in a text tab-delimited format (.txt).

* All items marked with an asterisk are items that you will change each time you run the lockbox with this file.

* A red asterisk indicates a conditional change item.



100YPCCDESTINYPCCORIGIN981215120200000111112222233333444445555566666777778888899 * * * *

This is the first record of the Lockbox. The item in blue is the Record Type indicator. There will only be one Record Type 1 in the Lockbox file. Record Type 1 is the “Header Record”. (Field name HR001)

The item in green is the Priority Code of the Lockbox. This item will have 2 characters (must fill both spaces, i.e. “1” is “01”). (Field name HR002)

The item in dark red is the Immediate Destination for the Lockbox. This will contain up to 10 characters (use blank spaces to fill up excess space if less than 10 characters exist in this item). (Field name HR003)

The next item in black is the Origin of the Transmission. This item may contain up to 10 characters (again filling up all ten characters/spaces). (Field name HR004)

Following that are the File Date in dark blue and the File Time in purple. They will have six and four characters respectively. (Field name HR005)

The remainder of the record is made up of 47 characters of filler in gray. name HR006)

The total length for this record is 80 characters. Spacing is critical because the Lockbox program reads the file based on character position. Therefore, use spaces or zeros to make up the excess space not used by an item within the record. For example, if your Origin of Transmission only uses 8 characters, then it should be preceded by two blank spaces.


2YPCCDESTINYPCCORIGIN * *

The item in blue is the Record Type indicator. Record 2 is the “Service Record”. From an SAP perspective, the 2 Record is not a mandatory record for lockbox importing. Some banks will utilize a 2 Record, others will not. Sometimes the information contained within this record will not adhere to the ‘proper’ definition, but rather be a restatement of the Record 1 (as shown above). If used, there can only be one Record Type 2 per lockbox transmission. There can be many lockbox transmissions within a single file, thus many 2 Records within the file. (Field name SR001)

The item in green is the lockbox Destination/Origin. This item will have 2 characters.eld name SR002)

The item in dark red is the Reference Code for the lockbox. It is not generally used, but may be filled with information. This will contain up to 10 characters. ield name SR003)

The next item in black is the Service Code for the lockbox, which the banks use for their own purposes to identify the transfer as a lockbox transfer. This item will use 3 characters/spaces. (Field name SR004)

Following that is the Record Length in dark blue, which will use 3 characters/spaces.SR005)

In purple is the Block Size of the lockbox (3 characters/spaces). (Field name SR006)

In dark yellow is the Format Code for the lockbox (1 characters/spaces). (Field name SR007)

The remainder of the record is made up of 40 characters of filler in gray. (Field The total length for this record is 80 characters. Be sure to pay attention to

spacing!


Record 5: Table FLB 05

50020010012345981215YPCCDESTINYPCCORIGIN11111222223333344444555556666677 * * * * * *

The item in blue is the Record Type indicator. There will be one Record Type 5 in each batch within the Lockbox file. Record 5 is the “Detail Header Record”. There can be many batches in a lockbox transmission. If there are four batches, there will be four 5 Records. (Field name DH001)


The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DH003)

The next item in black is the Lockbox Number. This item will use 7 spaces. name DH004)

Following that is the Deposit Date in dark blue, which will use 6 spaces. (Field name DH005)

In purple is the Immediate Destination of the Lockbox (10 characters/spaces). d name DH006)

In dark yellow is the Origin of Transmission – transit routing (10 characters/spaces). 007)

The remainder of the record is made up of 40 characters of filler in gray. ld name DH008)



60020020000090000011000390556677889 010203412 * * * * * *

The item in blue is the Record Type indicator. Record Type 6 can appear numerous times in the Lockbox file or in each batch, but only once per check. A new 6 Record marks the start of a new item number. Record 6 is the “Detail Record” which applies to a particular check in the Lockbox. (Field name DR001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name DR002) The bank sets the rules for how a batch is defined. For example, some banks will deliver up to a maximum of 50 checks in one batch. If there are 51 checks in a lockbox, thus there would be at least 2 batches.

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DR003)

The next item in black is the Remittance Amount for the Lockbox Record. This item will use 10 characters/spaces (use zeros if necessary in front of the amount). (Field name DR004)

Following that is the Remitter Identifier: Transit Routing No. in dark blue, which will use 9 characters/spaces. (Field name DR005)

In purple is the Remitter Identifier: Account Number (10 characters/spaces). Field name DR006)

In dark yellow is the Check Number (9 characters/spaces). (Field name DR007) After the check number is the Data Element for the Article field, a user-defined field.

The total length for this record is 35 characters. You may use dummy numbers to fill out this record, or you may leave it blank. (Field name DR008)



4002003401716000002 000001000000000000004002004402918000018 00001000000000000000gh * * * *

The item in blue is the Record Type indicator. Record Type 4 can appear numerous times in the Lockbox file. Record 4 is the “Item Record” and it is used to hold one invoice each. (Field name OR001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name OR002)

The item in red is the Batch Item Number for the Lockbox. This item will have 3 characters/spaces. (Field name OR003)

The item in purple Type of Overflow record (1 space). In this case, it is a ‘4 record’ because it contains only its own item, not an item overflowed from a preceding 6 Record. (Field name OR004)

Bright green is the Sequence Number for the record (2 spaces). (Field name OR005)

The item in yellow is the End Indicator for the Lockbox. A ‘9’ indicates the last record of a Lockbox (1 space). (Field name OR006)

The next items in black are the Invoice Numbers (16 characters/spaces each). Only 1 invoice is placed into each 4 Record. (Field name IVCNR) The best field format convention would be to use left-justification, blank-padding right for the invoice number(as shown in the Record 4 above).

The items in dark yellow are the Payment Amounts per invoice (10 characters/spaces). (FiT)

The items in gray are the Deduction Amounts per invoice (10 characters/spaces). MT)

Dark Blue is the External Reason Code for the payment. (Field name RESTG) Up to the next 30 character spaces are available for short text. They may be left

blank if desired. (Field name OR011)


700200500123459812150020000090000 * * * * * *

The item in blue is the Record Type indicator. Record Type 7 appears only once per batch in the Lockbox file. Record 7 is the “Batch Total Record” which signifies the end of the batch within the lockbox. If you have five batches in a lockbox, you will have five 7 Records. (Field name DH001)


The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 character spaces). (Field name DH003)

The next item in black is the Lockbox Number (7 characters/spaces). (Field name DH004)

Following that is the Lockbox Deposit Date in dark blue, which will use 6 characters/spaces. (Field name DH005)

In purple is the Number of Remittances Indicator (3 characters/spaces) for the batch within the lockbox. This should change based on the number of remittances in the lockbox file. (Field name DH006)

In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces – fill with spaces or zeros to take up space). These items should be changed to reflect the batch totals from the checks on the 6 Records in the lockbox. (Field name DH007)

Filler spaces or characters may take up the remaining 47 positions. (Field name DH008)



80020060012345981215000200000900009 0090000 0090000 * * * * * * * * *

The item in blue is the Record Type indicator. Record Type 8 appears only once in the Lockbox file. Record 8 is the “Service Total Record” which signifies the end of all Lockbox bundles. (Field name ST001)

The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name ST002)

The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name ST003)

The next item in black is the Lockbox Number (7 characters/spaces). (Field name ST004)

Following that is the Lockbox Deposit Date in dark blue, which will use 6 characters/spaces. (Field name ST005)

In purple is the Number of Remittances Indicator (4 characters/spaces). (Field name ST006)

In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces – fill with spaces or zeros to take up space). (Field name ST007)

The following fields in the file are optional – the file will function without any data provided in these fields, although they may appear in some files and thus will be read:

Last Record Indicator(1 space): A ‘9’ indicates the end of the record. (Field name ST008) TM Amount and MTD Amount for the Lockbox (11 spaces each). (Field name ST009-ST010)

The remainder of the record is made up of 22 characters of filler in gray. (Field name ST011)


Record 9:

9000002

The item in blue is the Record Type indicator. Record Type 9 appears only once in the Lockbox file. Record 9 is the “Trailer Record” which signifies the end of the Lockbox file. (Field name TR001)

The item in green is the Number of Records indicator. This item will have 6 characters. (Field name TR002)

Following this record item, there will be a Filler Record of 73 spaces, which can be either filled with characters or left blank. (Field name TR003)


Closing notes:

In the beginning, it is usually easiest to have the Lockbox program look for the lockbox file in the pathway C:\temp\ . If you are using the lockbox to test scenarios, it is advisable to use the same base file name and simply modify the name with a unique end identifier, ie. saplockboxbai-a.txt ; saplockboxbai-b.txt; and so on… Eventually, when you intend to test the ability to acquire the file from the network, place the file into the directory and network drive that will hold your lockbox file as imported from the bank transmissions into the mainframe.

When you run the lockbox program, it is advisable to have a program variant set up for running your files. Give it a default file name that you must modify for running each file. Otherwise, it will perceive that it has already read the file. Thus, it may be best to simply enter in: c:\temp\saplockboxbai- . Then each time, enter in the a.txt, or the b.txt.

Attached with this file are several sample BAI and BAI2 format lockbox files. Each one will be spaced properly for testing various scenarios. Make sure that the spacing remains the same when you input new file information, otherwise the program will not read the file properly.

The type of scenario will be listed above the actual file. Simply copy the file (Records 1 through 9) and paste into another new MS Word document or text editor screen. Save the file as a .txt file which the lockbox program can read to help you test out various scenarios for your lockbox configuration. Follow the logic in this document to make the necessary changes for your own scenarios.


BAI TESTS:

Scenario 1: Lockbox file perfect match to multiple open invoices on customer account

Documents:

SAP Invoices # 18000022 - 18000031 / Gross Amount $10,000.00

Incoming lockbox file:


Result: should match and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 2: Lockbox file match to open invoices and customer account, invoice payment at discount, and reference to a credit memo to explain a short-payment (invoices at discount/credit memo at gross)

Documents:

SAP Invoice # 18000032 for $1000.00/ SAP Invoice #18000033 for $1000.00 with 2% discount/ One SAP Credit Memo #16000001 for $200.00 / Net Amount $1760.00



Result: should match invoices and credit memo, deduct discount allowance, and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 3: Wrong MICR information on the customer account; account identified via invoice numbers on the account.

Documents:

SAP Invoices # 18000034, 18000035, 18000036 for $3000.00 / Gross Amount $3000.00On customer #1000001; incorrect MICR listed on master record.Incoming lockbox file:

100YPCCDESTINYPCCORIGIN98121512032YPCCDESTINYPCCORIGIN50030010012345981215YPCCDESTINYPCCORIGIN60030020000300000011000390556677889100091230518000034180000351800003670030030012345981215003000030000080030040012345981215000300003000009 0300000 03000009000003

Result: lockbox program searches for customer by invoice numbers. It identifies the customer, and creates a batch session to update the correct MICR number onto the customer’s master record for future transmissions. The items are cleared.-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 4: Invoice payment via Alternate Payer Worklist

Documents:

SAP Invoices # 18000037-18000039 for $1000.00 each / Gross amount $3000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512042YPCCDESTINYPCCORIGIN50040010012345981215YPCCDESTINYPCCORIGIN60040020000300000011000390556677889 00091230618000037180000381800003970040030012345981215003000030000080040040012345981215000300003000009 0300000 03000009000003

Result: the system will find reference in the transmission for three open items on two customers. The payment will arrive with the MICR information of the parent customer. It will check the master records of both, recognize that one customer (parent) pays the bills for the other (subsidiary), and use the payment to clear the open items from both customer accounts.-----------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 5: Short payment allowed under customer/user tolerances

Documents:

SAP Invoices # 18000040-18000041 for $1000.00 each / Gross amount $2000.00 / Payment $1995.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512052YPCCDESTINYPCCORIGIN50050010012345981215YPCCDESTINYPCCORIGIN60050020000199500011000390556677889 000912307180000401800004170050030012345981215002000019950080050040012345981215000200001995009 0199500 01995009000002

Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this scenario, you the system should allow you to post with the difference under set short-pay tolerances.

Scenario 6: Short payment refused under customer/user tolerances / post-processing required

Documents:


Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this case, the payment difference exceeds the tolerance limits, and thus the user must perform lockbox post-processing to write-off the excess difference to a G/L account or back to the customer’s account as an open item.

Any extra deduction beyond tolerance limits must be written off to a payment differences G/L account maintained in the configuration**** Scenario 6 may be used to test the customer’s business scenarios for lockbox postprocessing in dealing with

unauthorized payment differences, such as: ability to apply a check, generate a deduction with any reason code that doesn’t generate

correspondence, dispute or write-off ability to apply a check, generate a deduction with a reason code that generates a letter ability to apply a check, generate multiple deductions to specific different ship-to numbers, then process a

partial payment ability to apply a check, generate multiple deductions, with several residual items, allowing discount under

the customer’s tolerance & user’s tolerance, and also using a reason code to write-off to discount performing the same process as above, but write-off to disputed balance ability to apply a check, generate multiple deductions, several partial payments with reference to closed

items, or items which cannot be located ability to apply a check which pays an item which belongs on an account that is in a worklist, and another

item which belongs on an account which is not in a worklist ability to distribute payment differences by age ability to charge off differences within the customer/user tolerance ability to redirect a check which has been identified to the wrong account


Scenario 7: Lockbox transmission received with multiple customer payments in one batchDocuments:


Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page that shows the two batch items separately and the impact upon the individual accounts.

Scenario 8: Lockbox transmission received with multiple batches in one lockboxDocuments:

SAP Invoices # 18000046-18000049 for $1000.00 each / Gross amount $4000.00 / Payment $4000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512082YPCCDESTINYPCCORIGIN50080010012345981215YPCCDESTINYPCCORIGIN60080020000100000011000390556677889 000912309180000466008003000010000001100039055667788910009893091800004770080040012345981215002000020000050090010012345981215YPCCDESTINYPCCORIGIN60090020000100000011000390556677889 000901231180000481800004970090030012345981215002000020000080090040012345981215000200004000009 0400000 04000009000004

Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page which shows the two batch items in one batch, and another batch item on another batch, and the impact upon the individual accounts.

To modify the file to fit each of these scenarios, make sure to change the check dollar amount, and referenced invoices and credit memos, as well as batch number and time.

These scenarios also provide a good test of the Document Flow functionality in the Deductions Management Component.------------------------------------------------------------------------------------------------------------------------------------------------------


BAI2 TESTS:

Scenario 1: Lockbox file perfect match to multiple open invoices on customer account

Documents:

SAP Invoices # 18000022 - 18000031 / Gross Amount $10,000.00


100YPCCDESTINYPCCORIGIN98121512012YPCCDESTINYPCCORIGIN50010010012345981215YPCCDESTINYPCCORIGIN60010020001000000011000390556677889 0009123014001003601718000022 000010000000000000004001004602718000023 000010000000000000004001005603718000024 000010000000000000004001006604718000025 000010000000000000004001007605718000026 000010000000000000004001008606718000027 000010000000000000004001009607718000028 000010000000000000004001010608718000029 000010000000000000004001011609718000030 000010000000000000004001012610918000031 0000100000000000000070010050012345981215010000100000080010060012345981215001000010000009 1000000 10000009000010

Result: should match and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 2: Lockbox file match to open invoices and customer account, invoice payment at discount, and reference to a credit memo to explain a short-payment (invoices at discount/credit memo at gross)

Documents:

SAP Invoice # 18000018 for $1000.00/ SAP Invoice #18000033 for $1000.00 with 2% discount/ One SAP Credit Memo #16000002 for $200.00 / Net Amount $1760.00


100YPCCDESTINYPCCORIGIN98121512022YPCCDESTINYPCCORIGIN50020010012345981215YPCCDESTINYPCCORIGIN60020020000176000011000390556677889 0102034124002003601716000002 000002000000000000004002004602718000033 000009600000000000004002005603918000018 0000100000000000000070020060012345981215003000017600080020070012345981215000300001760009000003Result: should match invoices and credit memo, deduct discount allowance, and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 3: Wrong MICR information on the customer account; account identified via invoice numbers on the account.

Documents:

SAP Invoices # 18000034, 18000035 for $450.00 each / Gross Amount $900.00On customer #1000001; incorrect MICR listed on master record.Incoming lockbox file:


Result: lockbox program searches for customer by invoice numbers. It identifies the customer, and creates a batch session to update the correct MICR number onto the customer’s master record for future transmissions. The items are cleared.-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 4: Invoice payment via Alternate Payer Worklist

Documents:

SAP Invoices # 18000037-18000039 for $1000.00 each / Gross amount $3000.001 invoice on customer 1000000, 2 invoices on customer 1000001Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512042YPCCDESTINYPCCORIGIN50040010012345981215YPCCDESTINYPCCORIGIN60040020000300000011000390556677889 0102034144004003601718000037 000010000000000000004004004602718000038 000010000000000000004004005603918000039 0000100000000000000070040060012345981215003000030000080040070012345981215000300003000009000003Result: the system will find reference in the transmission for three open items on two customers. The payment will arrive with the MICR information of the parent customer. It will check the master records of both, recognize that one customer (parent) pays the bills for the other (subsidiary), and use the payment to clear the open items from both customer accounts.-----------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 5: Short payment allowed under customer/user tolerances

Documents:


Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this scenario, you the system should allow you to post with the difference under set short-pay tolerances.

Scenario 6: Short payment refused under customer/user tolerances / post-processing required

Documents:

SAP Invoices # 18000042-18000043 for $1000.00 each / Gross amount $2000.00 / Payment $1990.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512062YPCCDESTINYPCCORIGIN50060010012345981215YPCCDESTINYPCCORIGIN60060020000199000011000390556677889 0102034164006003601718000042 000010000000000000004006004602918000043 0000099000000000000070060050012345981215002000019900080060060012345981215000200001990009000002Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this case, the payment difference exceeds the tolerance limits, and thus the user must perform lockbox post-processing to write-off the excess difference to a G/L account or back to the customer’s account as an open item.

Any extra deduction beyond tolerance limits must be written off to a payment differences G/L account maintained in the configuration**** Scenario 6 may be used to test the customer’s business scenarios for lockbox postprocessing in dealing with

unauthorized payment differences, such as: ability to apply a check, generate a deduction with any reason code that doesn’t generate

correspondence, dispute or write-off ability to apply a check, generate a deduction with a reason code that generates a letter ability to apply a check, generate multiple deductions to specific different ship-to numbers, then process a

partial payment ability to apply a check, generate multiple deductions, with several residual items, allowing discount under

the customer’s tolerance & user’s tolerance, and also using a reason code to write-off to discount performing the same process as above, but write-off to disputed balance ability to apply a check, generate multiple deductions, several partial payments with reference to closed

items, or items which cannot be located


ability to apply a check which pays an item which belongs on an account that is in a worklist, and another item which belongs on an account which is not in a worklist

ability to distribute payment differences by age ability to charge off differences within the customer/user tolerance ability to redirect a check which has been identified to the wrong account

Scenario 7: Lockbox transmission received with multiple customer payments in one batchDocuments:

SAP Invoices # 18000044-18000045 for $1000.00 each / Gross amount $2000.00 / Payment $2000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512072YPCCDESTINYPCCORIGIN50070010012345981215YPCCDESTINYPCCORIGIN60070020000100000011000390556677889 0102034154007003601718000044 000010000000000000006007004000010000001100039055667788910102034164007005602918000045 0000100000000000000070070060012345981215002000020000080070070012345981215000200002000009000002Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page that shows the two items within the same batch displayed separately, as well as the impact upon the individual accounts.

Scenario 8: Lockbox transmission received with multiple batches in one lockboxDocuments:

SAP Invoices # 18000046-18000049 for $1000.00 each / Gross amount $4000.00 / Payment $4000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512082YPCCDESTINYPCCORIGIN50080010012345981215YPCCDESTINYPCCORIGIN60080020000200000011000390556677889 0102034174008003601718000046 000010000000000000004008004601918000047 0000100000000000000070080050012345981215002000020000050090010012345981215YPCCDESTINYPCCORIGIN6009002000020000001100039055667788910102034184009003601718000048 000010000000000000004009004602918000049 0000100000000000000070090050012345981215002000020000080090060012345981215000400004000009000004

Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page which shows the two batch items in one batch, and two items in another batch, and the impact upon the individual accounts.


Scenario 9: Partial application status achieved based upon one invoice applied and one invoice unprocessed (unidentifiable)

SAP Invoice # 18000113 for $1000.00 / Unidentifiable document #99009999 for $995.00


Result: the first payment will be applied against the correct SAP document. The second payment will arrive into SAP in an “unprocessed” status. Thus, the check status will be “partially applied”. Post-processing will be required for the unprocessed item.

There are certainly other scenarios that can be tested using these variable lockbox files. These are just a few of the ones commonly encountered on a client engagement. Files are very flexible. You may use SAP invoice numbers, customer legacy system document numbers, or a combination of both, within a lockbox file. You must maintain configuration for the program to know what to expect in the file.

The file used for testing a user exit program (you have to develop this separately) which acts upon lockbox files that omit invoice numbers is the same. Such files can be used to test: matching by account gross owing, matching by account owing minus credit memos, matching by account owing net of discounts, matching by aging bucket, and so on. The only difference in the file is that no invoice numbers are provided.

Once you have these basic templates, you can test different scenarios simply by changing dollar payment amounts, invoices, short payments, etc.

IMPORTANT CONFIGURATION NOTES:

When you are creating the files, you must be aware of the lockbox configuration in the system. Of particular importance is the configuration accessed via the following menu path in 4.0B:

Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control Parameters

In the BAI format entry, you must be aware of the document number length specified. This number sets the number of spaces the lockbox program will read for each document number. All document numbers must fit within the allowed maximum number of spaces defined here. The system will read documents which are shorter, if they have been configured for that document length within SAP.

Second, you must define here how many documents will be attached to the 6 Record and to the 4 Record. The file must then adhere to this specification. If you define the 6 Record to have zero documents, then you should ensure that the incoming lockbox file also has no documents in the 6 Record. You will need to specify this requirement to the client bank for them to incorporate it into the lockbox files that they send. Further, the 4 Record has a maximum number of documents specified in the configuration. If the configuration dictates to the program that each 4 Record will have 5 documents, then you may use up to 5 documents in each record. If there are more than 5 documents to be sent for that customer, then you must “overflow” into a series of consecutive 4 Records. However, you must utilize all 5 document spaces within a 4 Record before overflowing into a new 4 Record. Otherwise, the program will fail as it attempts to create payment advice notices, and the lockbox will not apply the payments to the specified open items.

Third, if you wish to activate the program’s logic for creating the MICR number from lockbox information for customer’s that are missing this data in their master record, then you must click the box for Insert Bank Details and create your own batch session name (ie. MICRCREATE) into the blank field. When running the lockbox for a customer in this scenario, a batch session will automatically be created with the name you define in this screen. Executing the batch session will automatically create the MICR information on the customer’s master record.


If you wish to increase the number of spaces possible for a particular field, for example document length, you will have to perform a table modification. For example, if you wish to expand the bank’s ABA number field from 9 to 16 (maximum) spaces, you will have to have the field definition modified in the table. This will require SAP approval.

For handling lockbox files which lack document numbers, you will need to have a special User Exit program written to provide logic for such selection algorithms as account gross owing, account net owing, account net owing less credits, gross aging buckets, net aging buckets, etc.

From a G/L perspective, you can limit the number of postings into the Lockbox A/R account by selecting ‘2’ in the G/L postings field. This indicates that the program should create one posting per lockbox, rather than per check. This is particularly valuable for companies who have high-volume lockbox transactions and don’t wish the Lockbox A/R account to become inundated by lots of individual lockbox postings.

If you want to be able to utilize the Alternate Payer logic within lockbox, you must make a change in the G/L bank account master records, as well as the lockbox A/R G/L accounts. On the second screen of the G/L master record, you should click on the box labeled ‘Relevant to cash flow’. This will enable the lockbox to post to items across customers on a worklist.

Important Procedural Tips:

1. Handling a lockbox payment that the customer intends to use to clear open items on more than one company code.

In the event that payments are received into a lockbox that exists in one company code, but are intended to pay open items that exist on the same customer in multiple company codes, a work-around solution must be designed. This is because a lockbox in SAP is defined as being specific to a single company code. It cannot handle the splitting of payments across company codes during autocash processing. While one option may be to attempt to include complex logic in a user exit that uses external table look-up for company code identification, a better semi-manual approach is suggested.

The proposed solution would utilize a reason code for movement of the payment portion that belongs on a different company code. For instance, a reason code WLP (Wrong Lockbox Paid) could be created. This is important because it allows you to ‘close’ the On Account posting that exists in the lockbox bank storage records. By using the FLB1 transaction for post-processing, the cash application clerk can go to the customer’s account, clear the payment portion against the open item in the first company code, and assign the WLP reason code to the incorrectly assigned payment portion (to flag it for cross-company posting). As far as the lockbox tracking is concerned, this is now a ‘closed’ item and it will have the status Applied. Now, the AR clerk must perform the Transfer with Clearing function (F-30) to search the correct company code for the open item to be cleared, and associate it with the payment residual item that exists in the incorrect company code. This function will utilize the company code clearing function and thereby not cause any intercompany problems. Reports may be generated to list all payments that have been received into the wrong company code (by the WLP reason code) and may also be connected to a user-defined SAP Script correspondence that requests that the customer remit separately all payments to their appropriate remit-to address and lockbox.

2. Dealing with the issue of multiple external reference invoice numbers (BSEG-XBLNR) per company code

When dealing with legacy-created documents that are imported into SAP, sometimes duplicate reference document numbers will exist in SAP simultaneously. Up through release 4.0B, user exit logic must be incorporated to prevent the system from matching a lockbox payment with an open item if the MICR has not enabled the proper identification of the proper customer. Otherwise, the system can erroneously apply the cash to the wrong account based upon which open item was created most recently. (In the event that a customer is found by MICR, and duplicate XBLNR values exist, the system will select and clear the appropriate open item).


Valuable Cash Management Services Available from Banks:

As of summer 1999, a handful of banks now offer an online lockbox status tracking service. Among the few, SunTrust Bank offers customers an Intranet-accessible (via secure server connection) lockbox activity tracker that is updated every five minutes to show all incoming cash postings to their lockbox account. This enables customers to view check images, review a list of all posted items (up to 45 days in past), and download a current lockbox account extract. Such a service can be used for simple cash management tracking functions, verifying payments, and viewing remittance information. This service will soon be Internet-based.


2003

May IssueFor: "Improve Your Lockbox Performance with User Exits, a Reformat Program, and Customized Reports," by Qian Sharon Tang, System Project Manager, Applied Materials, Inc. The author supplements her article on lockbox performance in the May issue of FI/CO Expert with information on implementing the functionality. Improve Your Lockbox Performance with User Exits, a Reformat Program, and Reportsby Qian Sharon Tang, Systems Project Manager, Applied Materials, Inc.

In this online section, greater detail is provided as to how a user I will call ABC Company implemented its lockbox solution for each of the following five steps of the process:

1. Receive check data file from the bank via FTP over the Internet. An elaborate transmission process was set up to ensure reliable, confidential transmission of lockbox data.

2. Reformat bank BAI/BAI2 data to SAP formatMany SAP clients receive customized formats from their bank. In this case, the customized format must be rearranged and mapped to the SAP standard data structures (FLB01-09 and FLB24, 26). You can either write an ABAP program to reformat the custom file or you can modify the data dictionary to match your customizations. However, because SAP makes it clear that you would be responsible for transporting your data dictionary changes to future releases, using a reformat program is the most efficient way to converting bank’s lockbox data to meet SAP BAI/BAI2 standards. As for reformat program design, please refer to the May issue of FI/CO Expert newsletter for examples and ideas.

3. Execute lockbox main program (RFEBLB00)

3.1 This program imports the lockbox file from the server (or user’s local drive)As you know, background job can only access data from the server.

3.2 It also calls the program RFEBLB20 to map imported data to standard SAP data structures such as FLB01, FLB02, etc., according to SAP BAI or BAI2 format. It then reads the data and uses it to create payment advice per check submitted via the lockbox. Each payment advice contains important data about an incoming check, such as amount, invoice number, payment date, etc. In later steps, the lockbox attempts to match the lockbox invoice number (imported as Invoice number field, FLB24- IVCNR) in the payment advice with either the document number or/and reference document number of the billing document or A/R invoice, depending on the user selection of the search rule for invoice numbers on the selection screen of the main program. A report log of imported checks (Figure 1) is generated, which lists matching results for each check and corresponding invoices and payment advice numbers created for the check.

ABC Company Lockbox Time 13.46.14 Date 02/05/2003San Jose Log of imported checks RFEBLB00/LOCKBOXB Page 1 Destination ABCCOMPANY Origin 0012345678 Lockbox 0000100Pay. date 02/05/03 ID 00000203 Itm/Batch Check number Customer Amount Deduction amount


1 001 128966 99998 CUSTOMER UVW Worklist 0001891011 11,395.00 Document found Advice total 11,395.00 Check amount 11,395.00 Payment advice D 0000099998 01478571 created. 1 900 1253901 99999 Customer XYZ Customer identified via invoice numbers 0001234567 1,621.59 Document found 0001234568 1.51 Document found 0001234569 298.56 Document found 0001234570 3,838.50 Document found 0001234571 602.00 Document found 0001234572 2,046.07- Document not found Advice total 4,316.09 Check amount 4,316.09 Payment advice D 0000099999 012953904 created.

Figure 1 Sample standard report: log of imported checks

3.3 RFEBLB20 also triggers a separate job, Lbox Bank Details. This job generates a batch input session that can change customer master records to insert new bank MICR numbers whenever the customer is identified and the corresponding MICR number is new. This functionality is activated if the option Insert Bank Details is selected in configuration T049B with a batch input session name specified.

3.4 The main lockbox program RFEBLB00 triggers yet another job, RFEBLB00-LOCKBOX. This job executes program RFEBBU00. It carries out what SAP calls ‘area-specific’ postings, with an approach that can be described as “one stone, two birds." If the configuration in table T049B is set up as such, it not only posts G/L transaction reflecting cash receipt, but also uses the payment advices created earlier (in Step 3.2) to clear against open items in accounts receivable that match with the searching criteria in the payment advice. This is the point where the lockbox program may fail to carry out clearing of invoices fully. Depending on the matching and clearing results, a check can be applied, partially applied, posted on account, or unprocessed. A report named Lockbox Posting Log (Figure 2) is produced at the end of this run, which provides check number, check application status, and corresponding G/L and A/R postings.

ABC Company Lockbox: Time 13.46.36 Date 02/05/2003San Jose Posting log RFEBBU00/LOCKBOXB Page 1 Destination ABCCOMPANY Origin 0012345678 Lockbox: 0000100 Date 02/05/03 ID 00000203 Check number Customer Amount Doc. (G/L) Doc. (AR) Doc on act Itm/Batch Advice 128966 99998 11,395.00 3100053634 1400003256 Applied 1 001 1253901 99999 4,316.09 3100053635 1400003257 Part. applied 1 900

Figure 2 Sample (standard) report: lockbox posting log

4 Standard batch input process program RSBDCSUB can be used to automatically process the batch input session created in Step 3.3 to update customer bank data MICR numbers on the customer master data records. A customized program can be created to report the list of customers and corresponding MICR numbers that have


been newly added to the customer master. You can find the logic of the program in the May 2003 issue of FI/CO Expert newsletter.

5 Standard R/3 report Lockbox Totals Report, RFEBLBR1 (Figure 3) can be executed to provide useful statistics regarding the amount and percentage of all different application statuses and its success rate for each lockbox that runs for a loading date. It sheds some light on the overall status of lockbox applications for the day and provides a good reference for the collection department, such as how much cash was collected, how many checks were processed, and the customer hit rate of the checks.

ABC Company Lockbox Totals Report Time 16.36.24 Date 02/05/2003San Jose RFEBLBR1/ LOCKBOXB Page 1 Lockbox Posting Summary Amount Checks Statement Date: 02/05/2003 Applied 11,395.00 10 Statement Time: 13:30:00 Partially Applied 4,316.09 1 Lockbox number: 0000100 On Account 2,000.00 1 Unprocessed 200.00 2 Lockbox Total 17,911.09 14 ABC Company Lockbox Totals Report Time 16.36.24 Date 02/05/2003San Jose RFEBLBR1/ LOCKBOXB Page 2 Lockbox Posting Summary Amount Checks Statement Date: 02/05/2003 Applied 500,00 1 Statement Time: 13:30:00 Partially Applied 20,000.00 1 Lockbox number: 0000200 On Account 0.00 0 Unprocessed 0.00 0 Lockbox Total 20,500.00 2 ABC Company Lockbox Totals Report Time 16.36.24 Date 02/05/2003San Jose RFEBLBR1/ LOCKBOXB Page 3 Lockbox Day Summary For: 02/05/2003 Amount Checks Applied 11,895.00 11 Partially Applied 24,316.09 2 On Account 2,000.00 1 Unprocessed 200.00 2 Lockbox Total 38,411.09 16 Customer Hit Rate: 00.0 % 100.0 %

Figure 3 Sample (standard) report: lockbox totals report

To fully appreciate the complexity of SAP Lockbox process, let’s count how many jobs are processed for its purpose per one lockbox run (for an overview, see Figure 4). In addition to the job (Lockbox_Main_Job) that contains steps for reformatting the data, executing the main lockbox program, processing the session to insert MICR numbers, and reporting on customers that have an MICR number added to their master data, the lockbox main program automatically triggers two more jobs of its own. They are job RFEBLB00-LOCKBOX to carry out posting and clearing of the data, and job Lbox bank details to create a batch input session for the MICR number insertion. Lockbox_statistics_job, which execute Lockbox Totals Report, is to provide statistics for a lockbox run. That’s total of five jobs, one of which contains a minimum of four steps.

Job name Scheduled Released Ready Active Finished CancelledLockbox_Main_Job X CUST-MICR X Lbox bank details X RFEBLB00-LOCKBOX X Lockbox_statistics_ job X


Figure 4 List of jobs for a complete lockbox run

OSS Messages and Notes

During the lockbox implementation, ABC Company encountered a number of lockbox program bugs and created OSS messages for them. SAP provided remedies (OSS notes) for these messages. ABC Company applied these OSS notes to fix the bugs and have the lockbox program work smoothly:

OSS note 105231: The lockbox program can search by either invoice number or reference document number. It has performance issues, however, if it searches by reference document number and the reference document happens to have a null value document number or is a reversal document, which may inherit the same reference document number from the original invoice.

OSS note 561171: This note should be applied when customers submit partial payments. If not applied, whenever a check contains some invoices that are partially paid and all other invoices are invalid document numbers, the lockbox program will terminate with the message Error in Routine INPUT_PRUEFEN.

OSS note 451121,437490, 391311, 358959: These notes should be applied if customers make multiple partial payments for one invoice at different lockbox runs. Without the note applied, the second partial payment won’t be able to be applied to the original invoice. Instead, it will clear off the first partial payment item and post the total amount of two partial payments to account.

OSS notes 458841, 407799, and 160257: These notes fix a clearing issue that is triggered when a customer is referencing a credit memo, but only takes the credit amount partially. Error message Exchange rate diff.accts are not defined for account & currency & appears in the lockbox posting log. The error message makes no sense since there are no foreign currencies involved during the whole billing and clearing process.

Qian (Sharon) Tang is a system project manager at Applied Materials Inc., focusing on the stabilizing and enhancing of various areas of SAP systems and leading SAP development projects. Prior to this, she was a senior FI/CO application consultant at SAP China for about three years. She has been working with SAP since 1995, focusing on FI/CO modules with emphasis on FI-GL/AR/AP, CO-CCA, CO-PC, CO-PA, and cross-module integration between FI/CO and logistics. She also has experience with SD and SM. She can be reached at [email protected].
