Sorun Cevaplayalım

İşinizle ilgili öngörüler edinin, gerçek zamanlı bilgilere göre karar alın.

SAP Eğitim ve Sertifika Dönemleri

Uzmanlığınızı ve deneyiminizi SAP çözümleri kullanarak tasdik edin.

Çözüm Ekibi Başvurusu

Kullanıcılara hızlı ve pratik çözümler üreterek görev almak isteyenler.

SAP BLOG Preprocessing of bank statements during upload

SAP Blog

Kayıtlı Üye
Katılım
22 Ara 2017
Mesajlar
609
Tepki Puanı
5
Puanları
6
Hello SAPers!

Best practice approach to processing of electronic bank statements implies that we load them “as is” without any modification (either manual or automatic). However, sometimes banks provide electronic bank statements that are not fully compliant with MT940-format and you are not able to load them without preliminary modifications. I’ll present some typical cases and elaborate how they can be resolved with minimal efforts and a bit of ABAP of course:).

Long (alternative) bank account numbers

SAP recommends maintaining alternative bank account number, if bank account number in bank statement differs from bank account number in customizing (i.e. FI12). However, the length of this field is restricted to 24 characters. Therefore, if alternative bank account number is longer, you’re not able to maintain it.



I faced similar issue recently with regards to introduction of IBAN-accounts in Ukraine. Client managed multicurrency bank accounts at local bank and this bank provided bank account numbers in MT940 as concatenation of bank account + currency:

  • UA203003790000002600354456789UAH
  • UA203003790000002600354456789USD
  • UA203003790000002600354456789EUR

As a side note, multicurrency account is special type of bank account that allows the company to manage funds in different currencies while bank account number remains the same. See OSS-note 1978526 for recommendations on how to manage such accounts in SAP .

Before introduction of IBAN, bank account was shorter (e.g. 2600354456789UAH) and it was possible to maintain it in SAP . Currently it has length of 37 characters, and it is no longer possible to maintain it.

The following solution can be used to deal with this issue. New customizing table should be created to store mapping between source bank account and alternative bank account number from customizing.



Mapping between account numbers should be configured:



Custom logic should be implemented within user exit EXIT_RFEKA400_001 / include ZXF01U06. Source code can be found below:

FUNCTION EXIT_RFEKA400_001.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" TABLES
*" T_RAW_DATA STRUCTURE RAW_DATA
*" EXCEPTIONS
*" ERROR_OCCURED
*"----------------------------------------------------------------------

INCLUDE ZXF01U06 .

ENDFUNCTION.

*&---------------------------------------------------------------------*
*& Include ZXF01U06
*&---------------------------------------------------------------------*

constants: lc_acc_no_pattern type string value '\:25\:([a-zA-Z0-9\/]+)'.

data:
lv_src_acc_no type char50,
lv_alt_acc_no type bnkn2.

field-symbols: <raw_line> type raw_data.

loop at t_raw_data assigning <raw_line>.
clear: lv_src_acc_no, lv_alt_acc_no.

" Checking if line contains pattern for bank account number
find regex lc_acc_no_pattern in <raw_line>-line
ignoring case
submatches lv_src_acc_no.

if sy-subrc is initial.
" Select alternative bank account number from custom table
select single bnkn2
into lv_alt_acc_no
from zsfin_bank_accs
where zsrc_bnkn = lv_src_acc_no.

if sy-subrc is initial.
replace first occurence of lv_src_acc_no in <raw_line>-line with lv_alt_acc_no.
endif.

endif.

endloop.

The logic behind enhancement is as follows:

  • The program is looking for a statement line that begins with fixed value “:25:” (line, which stores bank account number in MT940 bank statement) and retrieves bank account number.
  • Once bank account number was identified, it checks if there is a mapping in custom table with alternative bank account number;
  • If mapping is maintained, the program replaces bank account number in bank statement with bank account number from custom table.

Once this logic was executed, we no longer need to do anything. Standard interpretation mechanisms will take care of everything else.

Wrong format of bank account number

Field :25: might contain bank key. Standard upload program will recognize bank key / bank account number if they are provided in format BANK_KEY/BANK_ACCOUNT. however, sometimes banks provide this information in different formats (see examples below):

  • BANK_KEY-BANK_ACCOUNT – this format is not supported by SAP;
  • SWIFT_CODE/BANK_ACCOUNT – this format is also not supported.



If your bank provides bank account number in wrong format you can also use the approach with custom mapping table presented above. Alternatively, you can implement your own logic that will search for special characters and replace them or remove unnecessary information altogether (e.g. SWIFT code).

One final tip for troubleshooting. I’ve stumbled upon a lot of questions on SAP -related forums inquiring why this user exit is not triggered during bank statement upload at all. If you do new implementation, make sure that enhancement FEB00004 is activated. Go to transaction SMOD, indicate enhancement and press “Test” button:



Check if user exit is activated (has green indicator) and if it is not, activate it.



Before you implement any enhancements get in touch with technical department of respective bank and clarify if bank can change anything in presentation of field values in MT940 bank statements. In my experience, banks can usually customize format of this field so that it will contain correct values recognized by SAP .

Examples in this post might seem trivial and you might wonder why we need this post at all. The trouble is that sometimes functional consultants are not fully aware of all enhancement options and simply pass on the requirement to ABAP consultants. On one of my previous projects I’ve stumbled upon similar requirement and was quite surprised that the solution in legacy system involved development of new transaction code and new custom program, which was reading the file, updating it and then passing it on to standard upload program. At the end it turned out that bank could have simply adjusted the format of account without any development at all. The solution was literally one mail away…

I hope you will find this post useful! Your suggestions and comments are welcome!



Best regards,

Bohdan Petrushchak



P.S. Disclaimer.

All sensitive information (bank accounts, company names etc.) used in this example was invented. If there is some coincidence with real-life companies, it is a purely accidental one.

Okumaya devam et...
 
Üst