Direct debit: Approach for customers/banks in non-SEPA countries

[Former Member]

Introduction

While fulfilling different payment scenarios requests for a customer, I ran into an interesting business situation: since Croatia is not yet adopting SEPA-DD (Single Euro Payment Area - Direct Debit) format, the functionality itself if supported by all banks that operate in this area, but every single one has a different implementation of the functionality.

After acquiring all needed documentation, I had to decide which way to go: try to implement and modify the built-in direct debit functionality or develop sets of programs. Either way, I had to do a blocks of three programs, which are also a three sections I will describe in this document:

• Bank to Customer: New and revoked direct debit contracts
• Customer to Bank: Invoices to charge
• Bank to Customer: Information about successfull and rejected payments

I decided to make a set of three programs, one for each phase, for each bank.

Prerequisites

• Configured incomming payment methods that will be used
• Entered banks that will be used
• Configured return lots

File 1: Bank to Customer: New and revoked direct debit contracts

Theory around this is quite easy: client comes to the bank and opens the direct debit contract. At defined date, bank send the file to the billing company. Usualy, the file consists of several data than can be easily connected with either client or one of its bills: last bills note to payee, client bank account, or even contract account it (for the banks that support that kind of identification).

Technical implementation in SAP is also quite easy. Ill explain it on one single client / line in the file.

First find out the contract account. You can do that by some of the sent data, as stated above. Most of the banks will give note to payee, from where you have several ways: if you used classification ID implementation, then you can easily read all data from the DFKKOP table, comparing the field OPORD with the given data. If you didnt do that implementation and still note to payee consists of either business partner or contract account, get that data. There isnt any universal solution, as it depends on the data you get and the configuration of your system. What matters is that the "Bank details" area on the business partner needs to be filled (transaction: BP).

Its wise to use a nomenclature for the bank data you will be writting into business partner (field BKVID of the BUT0BKtable). For example, start all direct debits with letter D and use two more letters for bank (DSB, DRF), or any other rule that fits your needs. That way the operater will easily visualy understand what this data is all about.

Next step is entering the Incomming payment method and Bank details for incomming payments, on Payments tab of Contract account master data (transaction: CAA1).

For ABAPers:

• Use  cl_gui_frontend_services=>gui_upload for file upload
• Use  BAPI_ISUACCOUNT_GETDETAIL to check current contract account details
• Use  BAPI_ISUACCOUNT_CHANGE to enter new incomming payment methods

Now that we have the business partner and contract account prepared, we can move on. We should process billing (or, which is very unlikely, enter invoices manualy) and run the payment run (transaction: FPY1) with the corresponding parameters (at least: enter Payment Methods, date ranges, contract account ranges (if any) and choose Open items). If everything goes well, you have a successful run with paid invoices, which we now need to process. We will create a file that bank needs to charge clients.

File 2: Customer to Bank: Invoices to charge

Theory is again quite easy: everything we need is already prepared in the payment run. Again, depending on the bank, and the file format they request, the important data is: client identification (either through bank account number, contract account, note to payee or the external ID that the bank gave us in first step), invoice identification (through document number, unique note to payee / classification key), invoice date and amount.

Technicaly its also quite nice: check DPAYH table, where most of the needed data are. You will not find classification ID there - in case you need it, make a link to the original document via clearing document (combine tables DPAYH and DFKKOP). Also, if the bank asks you for any additional info (like client bank account), in DPAYH you have the contract account from which you can work your way up to any other information you need (remember: you have dedicated nomenclature for bank ID, which helps you with this), even though this exact number is a part of the stated table.

For ABAPers:

• Use  WS_DOWNLOAD for downloading file to the client computer

File 3: Bank to Customer: Information about successfull and rejected payments

Here goes the tricky part. Theory is again simple (as it should always be): bank gives us the information about the successful or rejected payments. Not all banks give both information, but, the only thing we need are the rejected ones, and we get those from all banks. When we get the information from the bank that the bill wasnt successfuly payed (that it was rejected) we put it in a return lot, to reverse the clearing and reopen the original document.

Technicaly its a bit tricky. The bank wont always give you the document number, so we need to find it ourselves. If youre going through classification ID (field OPORD), then you have two documents, like in previous step: you will find the original (invoice) document by classification key, but for return lot you need to reference to the payment document (it means you need to find the payment document via payment document clearing).

Also, some banks will give you the amount (which is an additional check), while the others wont. That means you need to get that information aswell, in order to fill the list in the return lot.

Not all of the following BAPIs allow test run, which is important for checking the file and the data itself, before the actual run. This means you (or your development team) will have to make their own way of checking (either by checking all data separately, or simulating what the BAPIs do - this is up to you, and your business requirements; hint: banks usualy give very precise files).

For ABAPers:

• Use  FKK_REFUSAL_BATCH_CREATE to create the return lot (transaction FP09)
• Use  FKK_REFUSAL_BATCH_APPEND to fill in the rejected invoices
• Use  FKK_RLS_CLOSE to close the return lot
• Use  FKK_RLS_POST_LOT to post the payment lot

Conclusion

Due to large volume of different banks (and thus formats) I can not give you a cookbook for this. But, I hope I cleared the steps for the software architects and consultants and gave BAPIs for ABAPers to start your way in solving this issue, in case you run to it.