Hello SAPers!
With every passing project involving SAP I understand that the body of knowledge in finance is still full of areas worth exploration. So here is another blog post on the functionalities related to bank statement in SAP.
1. Introduction
Standard SAP system provides a flexible mechanism to configure GL accounts determination for bank statement operations. You can map a variety of business scenarios by proper design of posting rules & accounts symbols associated with them. These configuration options are accessible via transaction OT83.
In this blog I’ll focus on the configuration options of account symbols and how account modifications can be used to enhance determination of GL accounts for bank operations.
2. Masking Functionality
Processing of bank statements relies heavily on the masking functionality to derive proper GL accounts. For instance, a mask “++++++++++” assigned to account symbol BANK will retrieve GL account associated with house bank account (i.e., configuration in transaction FI12). In this example, it will be GL account 113100.
Other typical masks involve determination of bank clearing GL accounts for incoming and outgoing operations:
- Mask “+++++++++1” means that SAP will derive house bank GL account and replace the last character by 1 e. g. 113101. Example – account symbol BANK_IN.
- Similarly, mask “+++++++++2” will derive GL account 113102. Example – account symbol BANK_OUT.
It is also possible to configure different GL accounts per currency of the bank operation. See for instance the configuration of account symbol BANK_CHARGES. Mask “+” in the field currency means that GL account 479000 is default GL account for all currencies. However, when it is the bank statement in EUR – the program will retrieve different GL i.e., 479200.
3. Account Modification
In most cases, you will not need to use account modifications to derive proper GL account. I was involved in numerous projects since 2013 and I never saw anyone using this functionality before. However, recently I stumbled upon an interesting business requirement and there were just two technical options to solve it:
- Drastically increase the number of account symbols / posting rules.
- Implement enhancement to derive GL accounts based on account modification.
From technical perspective the first option is much easier, and it can be handled by any junior consultant. Another advantage is that it does not require any coding. At the end this solution prevailed and got implemented. It resulted in configuration of over 150 posting rules which had to be shared across several house banks / transaction types.
During hypercare I had to do a few changes to the assignment of posting rules and it took me a lot of time to prepare all necessary details for these changes (e.g. which account symbols to adjust, which posting rules to add, what transaction types are impacted etc.).
In my opinion this is a good example of a technical debt – where a decision during implementation phase expedites the delivery of the project, but eventually results in higher costs in the support phase.
Back to the topic. The screenshot above shows the assignment of GL accounts for account symbol CLR_IN. I use two keys i.e., KREAG and UNIVB as account modifications. These keys correspond to the house bank IDs as defined in FI12:
The idea behind the logic is simple: GL account for account symbol CLR_IN will depend directly on the house bank. Definition of the posting rule Z+01 for this case looks as follows:
There is one more step to trigger this logic. House bank key should be transferred into field FEBEP-KFMOD during upload / processing of bank statement. The best option in my opinion is to implement an enhancement via BADI FIEB_CHANGE_BS_DATA, method IF_EX_FIEB_CHANGE_BS_DATA~CHANGE_DATA. See sample code below. Also please check out another blog post, where I describe this BADI in depth.
See the resulting application log after upload of bank statement for house bank KREAG. As you can see, the GL account for house bank was determined based on the account modification:
Main benefit of this approach: you have additional flexibility to derive GL accounts for bank statement without configuration of huge number of additional account symbols & posting rules. Main drawback – it is based on an enhancement, but the logic behind this enhancement is not complicated.
4. Additional Considerations
There are a few other options to fill FEBEP-KFMOD with values. These options are:
- Maintain search string with appropriate update scenario – this is the easiest way that doesn’t require any development efforts (see post for more details).
- You can also use user exit EXIT_RFEBBU10_001 or BADI FIEB_CHANGE_STATEMNT.
- If you use XML-based bank statement, you can write the values to FEBEP-KFMOD directly in XSLT-transformation (see post for more details).
- If you use other bank specific statement format e.g. CSV-format, you can do the same in BADI FIEB_GET_BANK_STMTS_X (see post for more details).
I hope that you have learn something useful once you reached this sentence. I’m looking forward to your comments and remarks.
Regards,
Bohdan Petrushchak
With every passing project involving SAP I understand that the body of knowledge in finance is still full of areas worth exploration. So here is another blog post on the functionalities related to bank statement in SAP.
1. Introduction
Standard SAP system provides a flexible mechanism to configure GL accounts determination for bank statement operations. You can map a variety of business scenarios by proper design of posting rules & accounts symbols associated with them. These configuration options are accessible via transaction OT83.
In this blog I’ll focus on the configuration options of account symbols and how account modifications can be used to enhance determination of GL accounts for bank operations.
2. Masking Functionality
Processing of bank statements relies heavily on the masking functionality to derive proper GL accounts. For instance, a mask “++++++++++” assigned to account symbol BANK will retrieve GL account associated with house bank account (i.e., configuration in transaction FI12). In this example, it will be GL account 113100.
Other typical masks involve determination of bank clearing GL accounts for incoming and outgoing operations:
- Mask “+++++++++1” means that SAP will derive house bank GL account and replace the last character by 1 e. g. 113101. Example – account symbol BANK_IN.
- Similarly, mask “+++++++++2” will derive GL account 113102. Example – account symbol BANK_OUT.
It is also possible to configure different GL accounts per currency of the bank operation. See for instance the configuration of account symbol BANK_CHARGES. Mask “+” in the field currency means that GL account 479000 is default GL account for all currencies. However, when it is the bank statement in EUR – the program will retrieve different GL i.e., 479200.
3. Account Modification
In most cases, you will not need to use account modifications to derive proper GL account. I was involved in numerous projects since 2013 and I never saw anyone using this functionality before. However, recently I stumbled upon an interesting business requirement and there were just two technical options to solve it:
- Drastically increase the number of account symbols / posting rules.
- Implement enhancement to derive GL accounts based on account modification.
From technical perspective the first option is much easier, and it can be handled by any junior consultant. Another advantage is that it does not require any coding. At the end this solution prevailed and got implemented. It resulted in configuration of over 150 posting rules which had to be shared across several house banks / transaction types.
During hypercare I had to do a few changes to the assignment of posting rules and it took me a lot of time to prepare all necessary details for these changes (e.g. which account symbols to adjust, which posting rules to add, what transaction types are impacted etc.).
In my opinion this is a good example of a technical debt – where a decision during implementation phase expedites the delivery of the project, but eventually results in higher costs in the support phase.
Back to the topic. The screenshot above shows the assignment of GL accounts for account symbol CLR_IN. I use two keys i.e., KREAG and UNIVB as account modifications. These keys correspond to the house bank IDs as defined in FI12:
The idea behind the logic is simple: GL account for account symbol CLR_IN will depend directly on the house bank. Definition of the posting rule Z+01 for this case looks as follows:
There is one more step to trigger this logic. House bank key should be transferred into field FEBEP-KFMOD during upload / processing of bank statement. The best option in my opinion is to implement an enhancement via BADI FIEB_CHANGE_BS_DATA, method IF_EX_FIEB_CHANGE_BS_DATA~CHANGE_DATA. See sample code below. Also please check out another blog post, where I describe this BADI in depth.
See the resulting application log after upload of bank statement for house bank KREAG. As you can see, the GL account for house bank was determined based on the account modification:
Main benefit of this approach: you have additional flexibility to derive GL accounts for bank statement without configuration of huge number of additional account symbols & posting rules. Main drawback – it is based on an enhancement, but the logic behind this enhancement is not complicated.
4. Additional Considerations
There are a few other options to fill FEBEP-KFMOD with values. These options are:
- Maintain search string with appropriate update scenario – this is the easiest way that doesn’t require any development efforts (see post for more details).
- You can also use user exit EXIT_RFEBBU10_001 or BADI FIEB_CHANGE_STATEMNT.
- If you use XML-based bank statement, you can write the values to FEBEP-KFMOD directly in XSLT-transformation (see post for more details).
- If you use other bank specific statement format e.g. CSV-format, you can do the same in BADI FIEB_GET_BANK_STMTS_X (see post for more details).
I hope that you have learn something useful once you reached this sentence. I’m looking forward to your comments and remarks.
Regards,
Bohdan Petrushchak
- SAP Managed Tags:
6 Comments
