Overview
SAP Lockbox
A company can create ‘lockbox’ accounts at a bank that are used as payment collection accounts for customer receivables. The company informs its customers that all payments should be submitted to one of its established bank lockbox accounts at a designated remittance address. A lockbox account is usually a designated post office box which has the company name but the customer payments are actually received by the bank.
SAP lockbox utilization results in two primary business benefits: funds collection and remittance information delivery. The major benefits are that the company is able to recognize the funds more quickly, and the customer’s check is cashed in a more timely manner. The bank collects the payments along with the customers’ remittance information which indicates the open items the customer is paying. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company in groups of checks called batches.
These electronic files are typically transferred nightly to the company which owns the lockbox. The files can be in one of two standard banking industry formats: BAI or BAI2. They can also be transmitted via EDI using the ANSI X.12 823 for lockbox remittances. A combination of the two is not uncommon where a BAI format is delivered within an EDI message.
Customer identification is the primary task of the initial (SAP) data processing of each lockbox payment. Finding the corresponding document clearing information is the second task. Lockbox programs RFEBLB00 for BAI and BAI2 formats and RFEBLB30 for EDI format attempt to identify the customer first by MICR number (ABA/bank account number combination) and then by invoice number. It is strongly recommended that companies maintain the bank details on their customer master records. The MICR numbers must be unique across banks configured within SAP. Additionally, the MICR and customer account number also need to uniquely identify a single customer within the system. If a customer is identified by the document number but the bank details do not correspond to the MICR number, they can be added via the optional batch input session. This allows the SAP system to ‘learn’ customer bank accounts via repeated use of the lockbox service. Processing statistics in future lockbox remittances will greatly improve with repeated use of this option.
BAI / BAI2 Formats
The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). BAI and BAI2 are the two defined lockbox transmission formats, however, BAI is considered outdated by the BAI organization and is no longer supported. Many banks still offer BAI format. Refer to note 118470 for contact information on the BAI institute from which formal documentation can be purchased. Banks which offer lockbox services frequently supply documentation on the formats they provide.
BAI and BAI2 formats differ primarily in their level of information detail. BAI does not subtotal the incoming check line items by invoice reference. One check total amount contains all invoices listed underneath it. Consequently, in BAI format files, the entire check must match the total amount for all invoices listed or be within configured payment difference tolerances. If it does not match or fall within tolerance limits, the entire check will enter into SAP as:
1. an “On Account” posting – the payment and invoice totals do not match or
2. an “Unprocessed” posting – no customer account or document could be identified from the transmission via MICR or invoice identification
The accounts receivable department will have to perform manual application to clear items which have received either of the statuses above. This is accomplished in the lockbox post-processing described below.
BAI2 splits the check total into separate invoice references and corresponding payment amounts per invoice. Each record type 4 contains only one invoice. It can also contain deduction amounts as well as the external reason code for the deduction. Within a payment targeted for multiple invoices, BAI2 format files can achieve a processing status of “Partially Applied” which means that some of the items within a check have been matched and cleared, and other invoices were not identified so their payment portion will be placed “On Account”. As a result, the hit rate or application rate percentage is higher when using BAI2 format than when using BAI format.
The decision of which format to use (given that your bank is able to supply BAI), is dictated by a cost-benefit analysis. The BAI2 format is more detailed so it costs more for the lockbox bank to enter and deliver the data. The BAI format is cheaper, but may not offer a suitable hit rate. The BAI2 format is recommended for large volume, multiple invoice payments and scenarios where deductions and short payments are taken. The BAI format is probably adequate if only a small portion of customer payments are received via lockbox transmission. In general, a high percentage of checks achieving a status of at least ‘on-account’ is targeted to reduce the intervention by post-processing analysts and achieve an acceptable ‘cash application’ rate.
ANSI X.12 823 (EDI)
Using EDI, the bank file is brought into the system using the FINSTA01 IDOC with the logical message type LOCKBX and process code LOBX. This process is slightly different to the BAI2 process which uploads the statement and posts it immediately. With EDI, the IDOC inserts the statements into the bank tables and then the posting program, RFEBLB30, is executed to post the statements. The information received in this format is identical to that which is received in BAI2 and is particularly effective in scenarios where extremely large remittance information is passed with a single payment. As with all EDI services delivering data to the SAP system, this format will require a translation mechanism for mapping the bank file in an ANSI format to the SAP IDOC format. This translation is done by an EDI subsystem. You can find a list of vendors which offer this service in the Complementary Software Program Directory. While the intent of this process is to translate ANSI X.12 823 files into the IDOC format, you could also translate the BAI2 file into the IDOC format. Companies which want to use the IDOC format for all external file transfer may choose to do this. Additional SAP configuration not described in this document is required if you wish to use the EDI process within the SAP system.
Benefits
» Better control of customer check float time and customer credit management.
» Accelerated collection and deposit of checks benefits the payee and allows for better and more efficient cash management.
» The automated lockbox system can reduce your own internal processing costs by automatically updating your cash postings and cash application to the subledger. Additionally your customer requirement to maintain data entry staff should be reduced.
Components of the SAP Lockbox
1. Control Parameters (Transaction OBAY)
» Procedure
» The procedure for payment processing. The system currently only supports the procedure LOCKBOX.
» Record Format
» The standardized record format of the file which you receive from the bank. The only supported formats are BAI, BAI2 and IDOC. For record format BAI only, you must also tell the system the length of the document and the maximum number of invoices which can be contained in record types 4 and 6. For the BAI format, record type 6 contains the detail per check. If there are more than 3 invoices being paid by a check, then a record type 4 is required. Record type 4 is the overflow record. The BAI data needs to conform strictly to this format creating a new ‘overflow’ record only when the prior record is filled with the number of entries indicated in the configuration. For the BAI2 and IDOC formats, it is not necessary to specify this information.
» G/L Account Posting Type
» You have two options when posting to the GL. You can choose to post one line item per check in both the clearing account and the GL bank account or you can choose to post one line item per check in the clearing account and only one line item for the total lockbox amount in the bank account. This reduces the number of postings to the GL bank account. As of release 4.6, you will also have the option to post one line item per batch. In the case where you have a file with three batches, each containing 50 checks, you would have 150 line items to the clearing account and 3 line items to the GL bank account. It is generally accepted to enable this compression on the GL account either at the bank or the batch level.
» Partial Payments
» The “Partial Payments” option is not recommended for customers with high volume. This box changes the default behavior of the program to post partial payments rather than creating residual items. The result is an “on account” posting with a reference to the original. This increases the number of open items on the customer account since nothing was cleared. Note that new SAP customers are typically accustomed to ‘partial payments’ in their view of the lockbox cash application. Residual item creation and the clearing of the initial customer invoice offers similar processing and capability along with the reduction of open items on the customer account. Additionally, the link is maintained between the residual item created and the original customer invoice from which it was created.
» Insert Bank Details
» The execution of the lockbox program allows you also to create a batch input session which will update your customer master records with bank account information, allowing the system to ‘learn’ customer bank information and improve processing statistics.
2. Posting Data (Transaction OBAX)
» Destination / Origin
» The Destination and Origin can be almost anything and are agreed upon with the lockbox bank as to their values. In some cases one of them may be the ABA number of the lockbox bank and the destination may be a cash account to which lockbox remittances are eventually transferred. They are both contained in record 1 of the file. The destination is in fields 4 to 13 and the origin is in fields 14 to 23.
» House Bank / Account ID
» If the lockbox is receiving payments which are of a currency other than the company code currency, then you have to create a house bank and account id for the lockbox account and specify the alternate currency in the house bank account. Canadian companies may have a US dollar lockbox for example. Note that lockbox accounts for each currency of receipt need to be configured. You can not have multiple currencies in the same file.
» Bank (G/L) Account / Bank Clearing Account (A/R)
» The automated lockbox posting program uses a two-step posting process. In step one, it posts to a GL account which is a bank account (House Bank / Account ID) and also to an AR clearing account commonly called an ‘unapplied cash’ account. In step two, the program attempts to clear a customer open item. If successful, it clears the customer open item and also the item in the clearing account (unapplied cash) which was posted in the first step. *** If you are using the cash management module, then the GL account in the “Bank (G/L) acct” field should contain a clearing account for incoming cash rather than the actual GL account for the bank.
3. Lockbox Addresses for House Banks (Transaction OB10)
» You can store different addresses, such as PO box numbers, for the lockbox to which customers mail their payments. The billing documents will then have the PO address rather than the bank street address. You must also maintain the lockbox field in the company code payment transaction screen in the customer master.
» Lockbox
» This is a 7 digit designation which you can define freely. It is suggested that you use the same name as the account id at the house bank in order to avoid confusion.
» Lbox No
» This is the number of the lockbox at your bank.
4. House Bank / EDI Partner (Transaction FI12) – Optional
» DME Section of the House Bank
» EDI Partner Profiles
» Partner No. – Use the ABA number to designate the partner number for the house bank.
» Partner Profile
» Header Information
» Partner Type – “B” for Bank
» Classification
» Partner Status – “A” for active
» Post Processing: Permitted Agents – The user entered in this area will receive messages in his or her inbox if there are problems with the import.
» Typ – “US” for User
» Lang. – “EN” for English
» User – user id for the SAP system
» Inbound Parameters
» Message Type – “LOCKBX” for Lockbox
» Inbound Options
» Process Code – “LOBX” for lockbox
» Trigger Immediately – the inbound IDOC is processed immediately
» Post Processing: Permitted Agents – The user entered in this area will receive messages in his or her inbox if there are problems with the import.
» Typ – “US” for User
» Lang. – “EN” for English
» User – user id for the SAP system
4a. ***EDI Port – an EDI port must be created in the system. This topic is not covered in this document.
5. Examples of possible user exits to increase hit rate.
» Cross-company postings. The bank account is actually owned by one company but the customers are in another company. The cash portion of the posting should be in one company code and the clearing of the customer item will be in the other. Since the posting rules for the lockbox are company code specific, you would need to have the user exit post the other side of the transaction to a GL in another company code.
» Alternate field search. The lockbox programs searches for document numbers (BELNR) and reference document numbers (XBLNR) to clear open items. With many customers, the billing document number is placed in the allocation field when the AR invoice is created. You could create a user exit which searches the allocation field in addition to the document and reference document fields. Post processing of the lockbox file relies on the document number when creating the payment advice. You could also have the user exit put the document number in the payment advice rather than the value which is in the allocation field since the system has already done the search for the allocation field.
6. Execute Program RFEBLB00 (BAI, BAI2) or RFEBLB30 (EDI)
» File Specifications (RFEBLB00)
» If you want to store the file in the system, you should check the box. If the file is either on the c drive of your PC or on a disk, you will need to check the box for PC upload and give the path name.
» Lockbox Data (RFEBLB30)
» The statements brought in to the system via EDI are processed with this transaction. Enter the origin, destination, lockbox, and statement date.
» Processing Parameters
» Invoice numbers
» You can tell the system which field to search for the invoice numbers. Your choices are document number, reference document numbers, or both. The order of the search can be specified.
» Enhanced Invoice number check
» This parameter ensures that invoices on a line item in the statement are only cleared from the same customer account. If the invoice number is transposed, for example, it could erroneously clear an invoice on another customer account.
» Algorithm: checks with and without advice
» You can tell the system to post on account those payments which are not able to clear an open item. If you choose the option to distribute by date, then the system will collect all payments which are on the customer account and try to clear the open items, beginning with the oldest item.
» Account Assignments
» The program can assign the value date to the postings based on the file date. If you enter a profit center or business area, the program will assign it to every document in the ledger and subledger.
» Output Control
» You can, and typically do, print the posting log from the program run.
7. Post Processing (Transaction FLB1)
» Enter specific data for the lockbox selection or select the Lockbox Overview button to view all existing bank files. After entering or selecting the file, you see the status of the checks by batch number. Checks are categorized as follows:
» Applied: The customer was identified and the check has cleared all document numbers provided.
» No further processing is necessary. You can not look at the payment advice because the system automatically deletes it.
» Partially Applied: The customer was identified and the check has cleared some of the documents. The remaining amount is posted on account for further manual processing.
» To process: choose the check and then press the post button. Clearing is done via standard SAP processing.
» On-Account: The customer was identified but none of the documents could be found. The full amount of the check is posted on the customer account for further processing with via payment advice.
» For this status, you must first change the payment advice. Select the check and you can insert or delete clearing information. You can also classify deductions with reason codes. After the changes, the advice must balance to zero. Save the advice and then post it.
» Unidentified: The customer was not identified. These are truly ‘unapplied cash’ and indicate inadequate customer identification either by MICR / Account number in the lockbox data or via invoice remittance information. The check remains in the unapplied payment clearing account. The payment advice is used to clear the item once the customer is identified.
» This is similar to the on-account status. You must first identify the customer in the payment advice before making other changes.
8. Test Lockbox Generation Programs RFEBLBT2 and RFEBLBT3.
These programs will generate customer open items and a lockbox file for processing. Utilize program RFEBKA96 to delete loaded test data. Refer to the online support system on this program for further information and extreme caution on its usage.
» File Name
» The program produces a BAI2 (or IDOC) file which is stored in UNIX. You can use any name you wish. Once the file is displayed on screen, a menu command allows PC download of it which facilitates repeated usage of the file with minor modification.
» Customer fields (6 Fields)
» You must enter customer numbers in the first four fields in order for the program to work. You can use the same customer number in all four fields if you wish. You can generate complex parent-child relationships which test the ‘worklist’ configuration via multiple customer entry.
» Dummy Account
» This is the offsetting account to the customer invoices and credit memos that the program creates.
» Deduction ($100 each Invoice)
» If you place an “X” here the program will generate a file in which all the amounts paid in the invoices differ by $100 from the actual invoice amount. In other words, the customer is paying $100 less on each invoice.
» Deduction not related to invoice
» If you insert an amount here, the program generates line items on the file for that amount which do not have a document number associated to them.
» Credit Memo
» If you place an “X” here, the program creates credit memos on the customer account which are half of the invoice amounts. No credit memo appears on the file.
» Credit Memo with Number
» If you place and “X” here, the program generates credit memos with numbers and puts them in the file also.
» Check Difference
» If you place an “X” here, the program generates line items which total more than the check amount.
» Run the Lockbox import program, using the filename which you chose for the test tool. Since the file is in the UNIX directory, make sure the “”PC upload” box is not checked.
Basic Steps in Configuring the Lockbox
» Maintain Control Parameters
» Maintain Posting Data
» Create Lockbox Addresses for House Banks
» Optional:
» For EDI processing: Create EDI Port, EDI Partner with Inbound Parameters
» Create user exit.
Menu Paths
The menu paths for setting up the lockbox:
» Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control ParametersorTransaction Code OBAY.
» Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Posting DataorTransaction Code OBAX.
» Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House BanksorTransaction Code OB10.
» Financial Accounting Bank Accounting Bank Accounts Define House BanksorTransaction Code FI12.
1. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control Parameters
2. Press the “New Entries” button.
3. Insert “LOCKBOX” as the procedure and either “BAI”, “BAI2”, “IDOC” as the record format.
4. For “BAI” record format, enter the document number length, and the number of documents in the 6 and 4 records.
5. Check the boxes “G/L Account Postings” and “Incoming Customer Payments”.
6. Choose whether you wish to update the general ledger with one posting per check or one posting per lockbox file in the “G/L account posting type” field. As of release 4.6, you also have the option to post per batch.
7. You can also choose whether to update the customer master records with bank details by clicking on the “Insert bank details” box and filling in a name for the batch input session.
8. The “Partial Payments” option is not recommended for customers with high volume.
9. Press the save icon.
10. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Posting Data
11. Press the “New Entries” button.
12. Enter the Destination and Origin information from the file which you received from the bank.
13. Enter the company code.
14. If the lockbox account has a currency other than the currency of the company code, you must maintain it as a house bank and and account id and enter that information here. Otherwise, you can leave it blank.
15. Enter the “Bank (G/L) acct” and “Bank clear.acct(A/R)” as descrbed above.
16. Maintain the posting parameters. The most common settings are indicated in the screen print to the right.
17. Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House Banks
18. Press the “New Entries” button.
19. Enter the company code, freely defined Lockbox (recommended to use the account id from the house bank), house bank, and Lbox no from the bank.
20. Financial Accounting Bank Accounting Bank Accounts Define House Banks
21. Choose the appropriate house bank from the list.
22. Press the DME button.
23. Enter the Partner Number. Common practice is to use the ABA number.
24. Press the Partner Profile Button.
25. Press the New Entries Button.
26. Enter the Partner number (same as previous screen).
27. Enter Partner type B for Bank.
28. The partner status is A for active.
29. Enter the data for the user who will be receiving error messages in the inbox.
30. Press Save.
31. Go back one menu.
32. Highlight your new entry and press the Inbound Parameters magnifying glass.
33. Press the New Entries button.
34. Leave Partn.funct., Message Code, and Message function blank.
35. Enter “LOCKBX” for the message type.
36. Enter “LOBX” for the process code.
37. Check the Syntax check box.
38. Choose the Trigger immediately radio button.
39. Enter the data for the user who will be receiving error messages in the inbox.
40. Press Save.
41. Accounting Treasury Cash Management Incomings Lockbox Import (RFEBLB00)
42. Check then “Import into bank data storage” to update the appropriate tables which store bank file data.
43. Click on “PC upload” if you are uploading the file from your PC.
44. Enter the path of the file you are going to import.
45. The procedure is “LOCKBOX”.
46. The Input record format is “BAI”, “BAI2”, or “IDOC”.
47. Choose the search rule for the invoice numbers from the drop down menu.
48. Check the “Enhanced invoice check” box if you wish to use it.
49. Choose the algorithms for checks with and without advice.
50. Click on “Assign value date” if you want the postings to have an associated value date.
51. Enter a business area and / or profit center if you wish.
52.
53Accounting Treasury Cash Management Incomings Lockbox Post (RFEBLB30)
53. This program is used for the EDI Process. EDI files are imported into the system and stored in the bank buffers. This program is then run to post. Follow the suggestions above except that you enter the destination, origin, and statement date rather than the lockbox procedure.
54.
55Accounting Treasury Cash Management Incomings Lockbox Postprocess
55. Enter specific data to a lockbox import or select the Lbox overview button to display all files.
56. Transaction SE38. Program name RFEBLBT2.
57. The function of each of the fields is explained in the previous section.
Related Documents
Appendix A – Tolerances and Reason Codes
User Exit Examples
Note 45436 - Lockbox Specific Transactions and Tables
OB55 - Worklist
Appendix A – Tolerances and Reason Codes
Overview
Tolerances
The use of tolerances is required by the system for clearing purposes. Tolerances can be set up for users and for Customer/Vendor payments. You can set up blank tolerance groups for customers, vendors, and users so that newly created customers and vendors will automatically be assigned this tolerance group. The system requires at least one tolerance group per company code. If you set up a blank tolerance group, then you don’t have to maintain that field in the customer and vendor master records. You can also set up a blank tolerance group for users. This way you don’t have to assign each user to a tolerance group. Users who are not specifically assigned to a tolerance group in transaction OB57 are automatically assigned to the blank tolerance group. Both sets of tolerances work together when clearing open items through the lockbox processing. The stricter of the rules will always control whether the item is cleared or not.
Reason Codes
The “4” record in the BAI Lockbox file may contain an external reason code indicating the reason for the payment difference. This external reason code must be linked to an internal reason code which is used to charge off the payment differences to a separate account. This allows you to clear customer items completely rather than having items posted on account which need to be post processed. If the payment difference is within the tolerances set, the difference will be posted to the charge off account. The external reason codes are linked to internal reason codes per a conversion version. The conversion version is assigned to the customer master record on the payment transaction screen.
Components
1. Define Customer/Vendor Tolerances (Transaction OBA3)
» Permitted Payment Differences
» This section refers to the total payment. In other words, you could be receiving one check which is paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances.
» Example:
Permitted Payment Differences
Amount
Percent
Gain
100.00
5.0 %
Loss
100.00
5.0 %
» The two fields amount and percent work in conjunction. Given the configuration above, and an invoice of 1000. The 5 percent would be used since 5 percent of 1000 is 50 which is lower than 100. The actual payment could be between 950 and 1050 to be within tolerance.
» Tolerances for Payment Advices
» This section refers to each invoice. In other words, each invoice is checked against these specifications. This section and the one described above work together, further restricting the clearing procedure.
» The fields work in conjunction exactly as the other set.
» Example:
Tolerances for Payment Advices
Amount
Percent
Outst.receiv.from
100.00
5.0 %
Outst.payable from
100.00
5.0 %
» It is possible that you could have 3 invoices which each are within tolerance and then be out of tolerance for the entire payment. Given the configuration above and 3 invoices for 1000 each. The payment received is for 880 (customer deducted 40 from each invoice). Each invoice is within tolerance because it is less than the 5 percent (50). Adding up the 3 invoices, however, we have a difference of 120. This is not within tolerance for “payment differences” because it is more than the 100 (amount). This is less than the 5 percent (150) but the program always uses the lower amount. In the example above, the percent was used because it was lower; in this example, the amount was lower.
2. Define Tolerance Groups for Employees (Transaction OBA4)
» Permitted Payment Differences
» This section refers to the total payment. In other words, you could be receiving one check which is paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances. These tolerances are used along with the tolerances from the customers and vendors to even further restrict the clearing process.
» Example:
Permitted Payment Differences
Amount
Percent
Gain
200.00
10.0 %
Loss
200.00
10.0 %
» The two fields amount and percent work in conjunction. The lower limit is the one which takes affect. Given the configuration above and an invoice for 3000. The amount of 200 would be used since 10 percent of 3000 is 300 which is higher than 200. The actual payment could be between 2800 and 3200 to be within tolerance.
» Tolerances defined here work with tolerances defined for customers and vendors. Again, the strictest tolerance will be used in the clearing procedure. Given the configuration above for both users and customers/vendors, the parameters in the customer/vendor tolerance configuration would be used since they are more restrictive than the configuration for the users.
3. Assign Users to Tolerance Groups (Transaction OB57)
» If you create a blank tolerance group in the step above, you can skip this step. Users will automatically be assigned to it. If you wish to have more than one tolerance group, you will have to assign users accordingly in this transaction.
4. Define Reason Codes (Transaction OBBE)
» The 4 record in the BAI file may contain an external reason code which indicates the reason for the payment difference. You can have the program automatically charge off the differences to other accounts.
» C – Charge off Difference
» This check box indicates whether the payment difference will be charged off to another GL account or charged back to the customer account as an open item. Checking the box means that you wish to charge it off to another account.
5. Define Accounts for Reason Codes ( Transaction OBXL)
» For transaction ZDI, you can define the charge off accounts by reason code.
6. Maintain Conversion Version for External Reason Codes (Transaction OBCR)
» Define here the versions for converting external reason codes to internal reason codes.
7. Assign External Reason Codes to Internal Reason Codes (Transaction OBCS)
» In this table you map internal reason codes to external reason codes by conversion version. It is possible to map different external reason codes from different conversion versions to the same internal reason code.
8. Change Customer Master Record ( Transaction FD02)
» In the company code data, payment transaction screen, enter the conversion version and tolerance group for each customer.
1. OBA3 – Define Customer/Vendor Tolerances
2. Enter tolerances for “permitted payment differences”.
3. Enter tolerances for “payment advices”.
4. OBA4 – Define Tolerance Groups for Employees
5. Enter tolerances for “permitted payment differences”.
6. OB57 – Assign Users to Tolerance Groups
7. Assign users to tolerance groups if necessary.
8. OBBE – Define Reason Codes
9. Check the “Charge off” box for each reason code you create.
10. OBXL – Define Accounts for Reason Codes
11. Assign GL accounts per reason code which will be posted for payment differences.
12. OBCR – Maintain Conversion Version for External Reason Codes
13. Create conversion versions which will be used to map external payment difference reason codes to internal reason codes.
14. OBCS – Assign Internal Reason Codes to External Reason Codes
15. Assign internal reason codes to external reason codes by conversion version.
16.
17
18FD02 – Change Customer Master Record
17. Enter the tolerance group for the customer.
18. Enter the conversion version for the customer.
OSS Note 45436 – Lockbox Transactions
R/3 note no. 45436 19.01.2000 Page 1
_______________________________________________________________________
Number 0045436
Version 0001 from 19.07.1996
Status Released for customer
Set by Gerhard Hafner on 19.07.1996
Language EN
Short text Lockbox / Advice: List of all transactions, tables
Administrator Gerhard Hafner
Component TR-CM-CM Basic Functions
_______________________________________________________________________
Long text
Symptom
This note contains a list of all the tables and transaction codes that
were used by the lockbox program.
Additional key words
FLB1, FLB2, FBE1, FBE2, FBE3, RFEBLB00, RFEBLB20, RFEBBU00
Cause and preconditions
-
Solution
Lockbox tables and transaction codes:
o FLB2 Import Lockbox File (RFEBLB00)
o FLB1 Postprocess Lockbox Data
o OBVS / T049A Posting Data
o OBVU / T049B General Parameters
Remittance advice tables and transaction codes
o FBE1 / FBE2 / FBE3 Create/change/display remittance advice
o OBBE / T053R: Reason codes
o OBXL / T030: Automatic posting (write off)
o OBCQ / T053G: Rem.Adv. types
o OBCW/T053D: Reason codes for clearing according to pay.advice
o OBCR / T053V: Reason codes conversion versions
o OBCS / T053E: Reason codes conversion (allocation external -
internal
o OBCT / T053A: Selection Rules
o OBCU/T053C: Selection sequence(allocation external -internal)
o OB57 / T043: Assign User - Tolerance group
o OBA4 / T043T: Tolerance groups for users
o OBA3 / T043G: Customer Tolerances
o OBXH / T041A: Posting keys for clearing transactions
SAP Lockbox
A company can create ‘lockbox’ accounts at a bank that are used as payment collection accounts for customer receivables. The company informs its customers that all payments should be submitted to one of its established bank lockbox accounts at a designated remittance address. A lockbox account is usually a designated post office box which has the company name but the customer payments are actually received by the bank.
SAP lockbox utilization results in two primary business benefits: funds collection and remittance information delivery. The major benefits are that the company is able to recognize the funds more quickly, and the customer’s check is cashed in a more timely manner. The bank collects the payments along with the customers’ remittance information which indicates the open items the customer is paying. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company in groups of checks called batches.
These electronic files are typically transferred nightly to the company which owns the lockbox. The files can be in one of two standard banking industry formats: BAI or BAI2. They can also be transmitted via EDI using the ANSI X.12 823 for lockbox remittances. A combination of the two is not uncommon where a BAI format is delivered within an EDI message.
Customer identification is the primary task of the initial (SAP) data processing of each lockbox payment. Finding the corresponding document clearing information is the second task. Lockbox programs RFEBLB00 for BAI and BAI2 formats and RFEBLB30 for EDI format attempt to identify the customer first by MICR number (ABA/bank account number combination) and then by invoice number. It is strongly recommended that companies maintain the bank details on their customer master records. The MICR numbers must be unique across banks configured within SAP. Additionally, the MICR and customer account number also need to uniquely identify a single customer within the system. If a customer is identified by the document number but the bank details do not correspond to the MICR number, they can be added via the optional batch input session. This allows the SAP system to ‘learn’ customer bank accounts via repeated use of the lockbox service. Processing statistics in future lockbox remittances will greatly improve with repeated use of this option.
BAI / BAI2 Formats
The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). BAI and BAI2 are the two defined lockbox transmission formats, however, BAI is considered outdated by the BAI organization and is no longer supported. Many banks still offer BAI format. Refer to note 118470 for contact information on the BAI institute from which formal documentation can be purchased. Banks which offer lockbox services frequently supply documentation on the formats they provide.
BAI and BAI2 formats differ primarily in their level of information detail. BAI does not subtotal the incoming check line items by invoice reference. One check total amount contains all invoices listed underneath it. Consequently, in BAI format files, the entire check must match the total amount for all invoices listed or be within configured payment difference tolerances. If it does not match or fall within tolerance limits, the entire check will enter into SAP as:
1. an “On Account” posting – the payment and invoice totals do not match or
2. an “Unprocessed” posting – no customer account or document could be identified from the transmission via MICR or invoice identification
The accounts receivable department will have to perform manual application to clear items which have received either of the statuses above. This is accomplished in the lockbox post-processing described below.
BAI2 splits the check total into separate invoice references and corresponding payment amounts per invoice. Each record type 4 contains only one invoice. It can also contain deduction amounts as well as the external reason code for the deduction. Within a payment targeted for multiple invoices, BAI2 format files can achieve a processing status of “Partially Applied” which means that some of the items within a check have been matched and cleared, and other invoices were not identified so their payment portion will be placed “On Account”. As a result, the hit rate or application rate percentage is higher when using BAI2 format than when using BAI format.
The decision of which format to use (given that your bank is able to supply BAI), is dictated by a cost-benefit analysis. The BAI2 format is more detailed so it costs more for the lockbox bank to enter and deliver the data. The BAI format is cheaper, but may not offer a suitable hit rate. The BAI2 format is recommended for large volume, multiple invoice payments and scenarios where deductions and short payments are taken. The BAI format is probably adequate if only a small portion of customer payments are received via lockbox transmission. In general, a high percentage of checks achieving a status of at least ‘on-account’ is targeted to reduce the intervention by post-processing analysts and achieve an acceptable ‘cash application’ rate.
ANSI X.12 823 (EDI)
Using EDI, the bank file is brought into the system using the FINSTA01 IDOC with the logical message type LOCKBX and process code LOBX. This process is slightly different to the BAI2 process which uploads the statement and posts it immediately. With EDI, the IDOC inserts the statements into the bank tables and then the posting program, RFEBLB30, is executed to post the statements. The information received in this format is identical to that which is received in BAI2 and is particularly effective in scenarios where extremely large remittance information is passed with a single payment. As with all EDI services delivering data to the SAP system, this format will require a translation mechanism for mapping the bank file in an ANSI format to the SAP IDOC format. This translation is done by an EDI subsystem. You can find a list of vendors which offer this service in the Complementary Software Program Directory. While the intent of this process is to translate ANSI X.12 823 files into the IDOC format, you could also translate the BAI2 file into the IDOC format. Companies which want to use the IDOC format for all external file transfer may choose to do this. Additional SAP configuration not described in this document is required if you wish to use the EDI process within the SAP system.
Benefits
» Better control of customer check float time and customer credit management.
» Accelerated collection and deposit of checks benefits the payee and allows for better and more efficient cash management.
» The automated lockbox system can reduce your own internal processing costs by automatically updating your cash postings and cash application to the subledger. Additionally your customer requirement to maintain data entry staff should be reduced.
Components of the SAP Lockbox
1. Control Parameters (Transaction OBAY)
» Procedure
» The procedure for payment processing. The system currently only supports the procedure LOCKBOX.
» Record Format
» The standardized record format of the file which you receive from the bank. The only supported formats are BAI, BAI2 and IDOC. For record format BAI only, you must also tell the system the length of the document and the maximum number of invoices which can be contained in record types 4 and 6. For the BAI format, record type 6 contains the detail per check. If there are more than 3 invoices being paid by a check, then a record type 4 is required. Record type 4 is the overflow record. The BAI data needs to conform strictly to this format creating a new ‘overflow’ record only when the prior record is filled with the number of entries indicated in the configuration. For the BAI2 and IDOC formats, it is not necessary to specify this information.
» G/L Account Posting Type
» You have two options when posting to the GL. You can choose to post one line item per check in both the clearing account and the GL bank account or you can choose to post one line item per check in the clearing account and only one line item for the total lockbox amount in the bank account. This reduces the number of postings to the GL bank account. As of release 4.6, you will also have the option to post one line item per batch. In the case where you have a file with three batches, each containing 50 checks, you would have 150 line items to the clearing account and 3 line items to the GL bank account. It is generally accepted to enable this compression on the GL account either at the bank or the batch level.
» Partial Payments
» The “Partial Payments” option is not recommended for customers with high volume. This box changes the default behavior of the program to post partial payments rather than creating residual items. The result is an “on account” posting with a reference to the original. This increases the number of open items on the customer account since nothing was cleared. Note that new SAP customers are typically accustomed to ‘partial payments’ in their view of the lockbox cash application. Residual item creation and the clearing of the initial customer invoice offers similar processing and capability along with the reduction of open items on the customer account. Additionally, the link is maintained between the residual item created and the original customer invoice from which it was created.
» Insert Bank Details
» The execution of the lockbox program allows you also to create a batch input session which will update your customer master records with bank account information, allowing the system to ‘learn’ customer bank information and improve processing statistics.
2. Posting Data (Transaction OBAX)
» Destination / Origin
» The Destination and Origin can be almost anything and are agreed upon with the lockbox bank as to their values. In some cases one of them may be the ABA number of the lockbox bank and the destination may be a cash account to which lockbox remittances are eventually transferred. They are both contained in record 1 of the file. The destination is in fields 4 to 13 and the origin is in fields 14 to 23.
» House Bank / Account ID
» If the lockbox is receiving payments which are of a currency other than the company code currency, then you have to create a house bank and account id for the lockbox account and specify the alternate currency in the house bank account. Canadian companies may have a US dollar lockbox for example. Note that lockbox accounts for each currency of receipt need to be configured. You can not have multiple currencies in the same file.
» Bank (G/L) Account / Bank Clearing Account (A/R)
» The automated lockbox posting program uses a two-step posting process. In step one, it posts to a GL account which is a bank account (House Bank / Account ID) and also to an AR clearing account commonly called an ‘unapplied cash’ account. In step two, the program attempts to clear a customer open item. If successful, it clears the customer open item and also the item in the clearing account (unapplied cash) which was posted in the first step. *** If you are using the cash management module, then the GL account in the “Bank (G/L) acct” field should contain a clearing account for incoming cash rather than the actual GL account for the bank.
3. Lockbox Addresses for House Banks (Transaction OB10)
» You can store different addresses, such as PO box numbers, for the lockbox to which customers mail their payments. The billing documents will then have the PO address rather than the bank street address. You must also maintain the lockbox field in the company code payment transaction screen in the customer master.
» Lockbox
» This is a 7 digit designation which you can define freely. It is suggested that you use the same name as the account id at the house bank in order to avoid confusion.
» Lbox No
» This is the number of the lockbox at your bank.
4. House Bank / EDI Partner (Transaction FI12) – Optional
» DME Section of the House Bank
» EDI Partner Profiles
» Partner No. – Use the ABA number to designate the partner number for the house bank.
» Partner Profile
» Header Information
» Partner Type – “B” for Bank
» Classification
» Partner Status – “A” for active
» Post Processing: Permitted Agents – The user entered in this area will receive messages in his or her inbox if there are problems with the import.
» Typ – “US” for User
» Lang. – “EN” for English
» User – user id for the SAP system
» Inbound Parameters
» Message Type – “LOCKBX” for Lockbox
» Inbound Options
» Process Code – “LOBX” for lockbox
» Trigger Immediately – the inbound IDOC is processed immediately
» Post Processing: Permitted Agents – The user entered in this area will receive messages in his or her inbox if there are problems with the import.
» Typ – “US” for User
» Lang. – “EN” for English
» User – user id for the SAP system
4a. ***EDI Port – an EDI port must be created in the system. This topic is not covered in this document.
5. Examples of possible user exits to increase hit rate.
» Cross-company postings. The bank account is actually owned by one company but the customers are in another company. The cash portion of the posting should be in one company code and the clearing of the customer item will be in the other. Since the posting rules for the lockbox are company code specific, you would need to have the user exit post the other side of the transaction to a GL in another company code.
» Alternate field search. The lockbox programs searches for document numbers (BELNR) and reference document numbers (XBLNR) to clear open items. With many customers, the billing document number is placed in the allocation field when the AR invoice is created. You could create a user exit which searches the allocation field in addition to the document and reference document fields. Post processing of the lockbox file relies on the document number when creating the payment advice. You could also have the user exit put the document number in the payment advice rather than the value which is in the allocation field since the system has already done the search for the allocation field.
6. Execute Program RFEBLB00 (BAI, BAI2) or RFEBLB30 (EDI)
» File Specifications (RFEBLB00)
» If you want to store the file in the system, you should check the box. If the file is either on the c drive of your PC or on a disk, you will need to check the box for PC upload and give the path name.
» Lockbox Data (RFEBLB30)
» The statements brought in to the system via EDI are processed with this transaction. Enter the origin, destination, lockbox, and statement date.
» Processing Parameters
» Invoice numbers
» You can tell the system which field to search for the invoice numbers. Your choices are document number, reference document numbers, or both. The order of the search can be specified.
» Enhanced Invoice number check
» This parameter ensures that invoices on a line item in the statement are only cleared from the same customer account. If the invoice number is transposed, for example, it could erroneously clear an invoice on another customer account.
» Algorithm: checks with and without advice
» You can tell the system to post on account those payments which are not able to clear an open item. If you choose the option to distribute by date, then the system will collect all payments which are on the customer account and try to clear the open items, beginning with the oldest item.
» Account Assignments
» The program can assign the value date to the postings based on the file date. If you enter a profit center or business area, the program will assign it to every document in the ledger and subledger.
» Output Control
» You can, and typically do, print the posting log from the program run.
7. Post Processing (Transaction FLB1)
» Enter specific data for the lockbox selection or select the Lockbox Overview button to view all existing bank files. After entering or selecting the file, you see the status of the checks by batch number. Checks are categorized as follows:
» Applied: The customer was identified and the check has cleared all document numbers provided.
» No further processing is necessary. You can not look at the payment advice because the system automatically deletes it.
» Partially Applied: The customer was identified and the check has cleared some of the documents. The remaining amount is posted on account for further manual processing.
» To process: choose the check and then press the post button. Clearing is done via standard SAP processing.
» On-Account: The customer was identified but none of the documents could be found. The full amount of the check is posted on the customer account for further processing with via payment advice.
» For this status, you must first change the payment advice. Select the check and you can insert or delete clearing information. You can also classify deductions with reason codes. After the changes, the advice must balance to zero. Save the advice and then post it.
» Unidentified: The customer was not identified. These are truly ‘unapplied cash’ and indicate inadequate customer identification either by MICR / Account number in the lockbox data or via invoice remittance information. The check remains in the unapplied payment clearing account. The payment advice is used to clear the item once the customer is identified.
» This is similar to the on-account status. You must first identify the customer in the payment advice before making other changes.
8. Test Lockbox Generation Programs RFEBLBT2 and RFEBLBT3.
These programs will generate customer open items and a lockbox file for processing. Utilize program RFEBKA96 to delete loaded test data. Refer to the online support system on this program for further information and extreme caution on its usage.
» File Name
» The program produces a BAI2 (or IDOC) file which is stored in UNIX. You can use any name you wish. Once the file is displayed on screen, a menu command allows PC download of it which facilitates repeated usage of the file with minor modification.
» Customer fields (6 Fields)
» You must enter customer numbers in the first four fields in order for the program to work. You can use the same customer number in all four fields if you wish. You can generate complex parent-child relationships which test the ‘worklist’ configuration via multiple customer entry.
» Dummy Account
» This is the offsetting account to the customer invoices and credit memos that the program creates.
» Deduction ($100 each Invoice)
» If you place an “X” here the program will generate a file in which all the amounts paid in the invoices differ by $100 from the actual invoice amount. In other words, the customer is paying $100 less on each invoice.
» Deduction not related to invoice
» If you insert an amount here, the program generates line items on the file for that amount which do not have a document number associated to them.
» Credit Memo
» If you place an “X” here, the program creates credit memos on the customer account which are half of the invoice amounts. No credit memo appears on the file.
» Credit Memo with Number
» If you place and “X” here, the program generates credit memos with numbers and puts them in the file also.
» Check Difference
» If you place an “X” here, the program generates line items which total more than the check amount.
» Run the Lockbox import program, using the filename which you chose for the test tool. Since the file is in the UNIX directory, make sure the “”PC upload” box is not checked.
Basic Steps in Configuring the Lockbox
» Maintain Control Parameters
» Maintain Posting Data
» Create Lockbox Addresses for House Banks
» Optional:
» For EDI processing: Create EDI Port, EDI Partner with Inbound Parameters
» Create user exit.
Menu Paths
The menu paths for setting up the lockbox:
» Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control ParametersorTransaction Code OBAY.
» Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Posting DataorTransaction Code OBAX.
» Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House BanksorTransaction Code OB10.
» Financial Accounting Bank Accounting Bank Accounts Define House BanksorTransaction Code FI12.
1. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control Parameters
2. Press the “New Entries” button.
3. Insert “LOCKBOX” as the procedure and either “BAI”, “BAI2”, “IDOC” as the record format.
4. For “BAI” record format, enter the document number length, and the number of documents in the 6 and 4 records.
5. Check the boxes “G/L Account Postings” and “Incoming Customer Payments”.
6. Choose whether you wish to update the general ledger with one posting per check or one posting per lockbox file in the “G/L account posting type” field. As of release 4.6, you also have the option to post per batch.
7. You can also choose whether to update the customer master records with bank details by clicking on the “Insert bank details” box and filling in a name for the batch input session.
8. The “Partial Payments” option is not recommended for customers with high volume.
9. Press the save icon.
10. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Posting Data
11. Press the “New Entries” button.
12. Enter the Destination and Origin information from the file which you received from the bank.
13. Enter the company code.
14. If the lockbox account has a currency other than the currency of the company code, you must maintain it as a house bank and and account id and enter that information here. Otherwise, you can leave it blank.
15. Enter the “Bank (G/L) acct” and “Bank clear.acct(A/R)” as descrbed above.
16. Maintain the posting parameters. The most common settings are indicated in the screen print to the right.
17. Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House Banks
18. Press the “New Entries” button.
19. Enter the company code, freely defined Lockbox (recommended to use the account id from the house bank), house bank, and Lbox no from the bank.
20. Financial Accounting Bank Accounting Bank Accounts Define House Banks
21. Choose the appropriate house bank from the list.
22. Press the DME button.
23. Enter the Partner Number. Common practice is to use the ABA number.
24. Press the Partner Profile Button.
25. Press the New Entries Button.
26. Enter the Partner number (same as previous screen).
27. Enter Partner type B for Bank.
28. The partner status is A for active.
29. Enter the data for the user who will be receiving error messages in the inbox.
30. Press Save.
31. Go back one menu.
32. Highlight your new entry and press the Inbound Parameters magnifying glass.
33. Press the New Entries button.
34. Leave Partn.funct., Message Code, and Message function blank.
35. Enter “LOCKBX” for the message type.
36. Enter “LOBX” for the process code.
37. Check the Syntax check box.
38. Choose the Trigger immediately radio button.
39. Enter the data for the user who will be receiving error messages in the inbox.
40. Press Save.
41. Accounting Treasury Cash Management Incomings Lockbox Import (RFEBLB00)
42. Check then “Import into bank data storage” to update the appropriate tables which store bank file data.
43. Click on “PC upload” if you are uploading the file from your PC.
44. Enter the path of the file you are going to import.
45. The procedure is “LOCKBOX”.
46. The Input record format is “BAI”, “BAI2”, or “IDOC”.
47. Choose the search rule for the invoice numbers from the drop down menu.
48. Check the “Enhanced invoice check” box if you wish to use it.
49. Choose the algorithms for checks with and without advice.
50. Click on “Assign value date” if you want the postings to have an associated value date.
51. Enter a business area and / or profit center if you wish.
52.
53Accounting Treasury Cash Management Incomings Lockbox Post (RFEBLB30)
53. This program is used for the EDI Process. EDI files are imported into the system and stored in the bank buffers. This program is then run to post. Follow the suggestions above except that you enter the destination, origin, and statement date rather than the lockbox procedure.
54.
55Accounting Treasury Cash Management Incomings Lockbox Postprocess
55. Enter specific data to a lockbox import or select the Lbox overview button to display all files.
56. Transaction SE38. Program name RFEBLBT2.
57. The function of each of the fields is explained in the previous section.
Related Documents
Appendix A – Tolerances and Reason Codes
User Exit Examples
Note 45436 - Lockbox Specific Transactions and Tables
OB55 - Worklist
Appendix A – Tolerances and Reason Codes
Overview
Tolerances
The use of tolerances is required by the system for clearing purposes. Tolerances can be set up for users and for Customer/Vendor payments. You can set up blank tolerance groups for customers, vendors, and users so that newly created customers and vendors will automatically be assigned this tolerance group. The system requires at least one tolerance group per company code. If you set up a blank tolerance group, then you don’t have to maintain that field in the customer and vendor master records. You can also set up a blank tolerance group for users. This way you don’t have to assign each user to a tolerance group. Users who are not specifically assigned to a tolerance group in transaction OB57 are automatically assigned to the blank tolerance group. Both sets of tolerances work together when clearing open items through the lockbox processing. The stricter of the rules will always control whether the item is cleared or not.
Reason Codes
The “4” record in the BAI Lockbox file may contain an external reason code indicating the reason for the payment difference. This external reason code must be linked to an internal reason code which is used to charge off the payment differences to a separate account. This allows you to clear customer items completely rather than having items posted on account which need to be post processed. If the payment difference is within the tolerances set, the difference will be posted to the charge off account. The external reason codes are linked to internal reason codes per a conversion version. The conversion version is assigned to the customer master record on the payment transaction screen.
Components
1. Define Customer/Vendor Tolerances (Transaction OBA3)
» Permitted Payment Differences
» This section refers to the total payment. In other words, you could be receiving one check which is paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances.
» Example:
Permitted Payment Differences
Amount
Percent
Gain
100.00
5.0 %
Loss
100.00
5.0 %
» The two fields amount and percent work in conjunction. Given the configuration above, and an invoice of 1000. The 5 percent would be used since 5 percent of 1000 is 50 which is lower than 100. The actual payment could be between 950 and 1050 to be within tolerance.
» Tolerances for Payment Advices
» This section refers to each invoice. In other words, each invoice is checked against these specifications. This section and the one described above work together, further restricting the clearing procedure.
» The fields work in conjunction exactly as the other set.
» Example:
Tolerances for Payment Advices
Amount
Percent
Outst.receiv.from
100.00
5.0 %
Outst.payable from
100.00
5.0 %
» It is possible that you could have 3 invoices which each are within tolerance and then be out of tolerance for the entire payment. Given the configuration above and 3 invoices for 1000 each. The payment received is for 880 (customer deducted 40 from each invoice). Each invoice is within tolerance because it is less than the 5 percent (50). Adding up the 3 invoices, however, we have a difference of 120. This is not within tolerance for “payment differences” because it is more than the 100 (amount). This is less than the 5 percent (150) but the program always uses the lower amount. In the example above, the percent was used because it was lower; in this example, the amount was lower.
2. Define Tolerance Groups for Employees (Transaction OBA4)
» Permitted Payment Differences
» This section refers to the total payment. In other words, you could be receiving one check which is paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances. These tolerances are used along with the tolerances from the customers and vendors to even further restrict the clearing process.
» Example:
Permitted Payment Differences
Amount
Percent
Gain
200.00
10.0 %
Loss
200.00
10.0 %
» The two fields amount and percent work in conjunction. The lower limit is the one which takes affect. Given the configuration above and an invoice for 3000. The amount of 200 would be used since 10 percent of 3000 is 300 which is higher than 200. The actual payment could be between 2800 and 3200 to be within tolerance.
» Tolerances defined here work with tolerances defined for customers and vendors. Again, the strictest tolerance will be used in the clearing procedure. Given the configuration above for both users and customers/vendors, the parameters in the customer/vendor tolerance configuration would be used since they are more restrictive than the configuration for the users.
3. Assign Users to Tolerance Groups (Transaction OB57)
» If you create a blank tolerance group in the step above, you can skip this step. Users will automatically be assigned to it. If you wish to have more than one tolerance group, you will have to assign users accordingly in this transaction.
4. Define Reason Codes (Transaction OBBE)
» The 4 record in the BAI file may contain an external reason code which indicates the reason for the payment difference. You can have the program automatically charge off the differences to other accounts.
» C – Charge off Difference
» This check box indicates whether the payment difference will be charged off to another GL account or charged back to the customer account as an open item. Checking the box means that you wish to charge it off to another account.
5. Define Accounts for Reason Codes ( Transaction OBXL)
» For transaction ZDI, you can define the charge off accounts by reason code.
6. Maintain Conversion Version for External Reason Codes (Transaction OBCR)
» Define here the versions for converting external reason codes to internal reason codes.
7. Assign External Reason Codes to Internal Reason Codes (Transaction OBCS)
» In this table you map internal reason codes to external reason codes by conversion version. It is possible to map different external reason codes from different conversion versions to the same internal reason code.
8. Change Customer Master Record ( Transaction FD02)
» In the company code data, payment transaction screen, enter the conversion version and tolerance group for each customer.
1. OBA3 – Define Customer/Vendor Tolerances
2. Enter tolerances for “permitted payment differences”.
3. Enter tolerances for “payment advices”.
4. OBA4 – Define Tolerance Groups for Employees
5. Enter tolerances for “permitted payment differences”.
6. OB57 – Assign Users to Tolerance Groups
7. Assign users to tolerance groups if necessary.
8. OBBE – Define Reason Codes
9. Check the “Charge off” box for each reason code you create.
10. OBXL – Define Accounts for Reason Codes
11. Assign GL accounts per reason code which will be posted for payment differences.
12. OBCR – Maintain Conversion Version for External Reason Codes
13. Create conversion versions which will be used to map external payment difference reason codes to internal reason codes.
14. OBCS – Assign Internal Reason Codes to External Reason Codes
15. Assign internal reason codes to external reason codes by conversion version.
16.
17
18FD02 – Change Customer Master Record
17. Enter the tolerance group for the customer.
18. Enter the conversion version for the customer.
OSS Note 45436 – Lockbox Transactions
R/3 note no. 45436 19.01.2000 Page 1
_______________________________________________________________________
Number 0045436
Version 0001 from 19.07.1996
Status Released for customer
Set by Gerhard Hafner on 19.07.1996
Language EN
Short text Lockbox / Advice: List of all transactions, tables
Administrator Gerhard Hafner
Component TR-CM-CM Basic Functions
_______________________________________________________________________
Long text
Symptom
This note contains a list of all the tables and transaction codes that
were used by the lockbox program.
Additional key words
FLB1, FLB2, FBE1, FBE2, FBE3, RFEBLB00, RFEBLB20, RFEBBU00
Cause and preconditions
-
Solution
Lockbox tables and transaction codes:
o FLB2 Import Lockbox File (RFEBLB00)
o FLB1 Postprocess Lockbox Data
o OBVS / T049A Posting Data
o OBVU / T049B General Parameters
Remittance advice tables and transaction codes
o FBE1 / FBE2 / FBE3 Create/change/display remittance advice
o OBBE / T053R: Reason codes
o OBXL / T030: Automatic posting (write off)
o OBCQ / T053G: Rem.Adv. types
o OBCW/T053D: Reason codes for clearing according to pay.advice
o OBCR / T053V: Reason codes conversion versions
o OBCS / T053E: Reason codes conversion (allocation external -
internal
o OBCT / T053A: Selection Rules
o OBCU/T053C: Selection sequence(allocation external -internal)
o OB57 / T043: Assign User - Tolerance group
o OBA4 / T043T: Tolerance groups for users
o OBA3 / T043G: Customer Tolerances
o OBXH / T041A: Posting keys for clearing transactions
