I realise that there are still many topics worth exploring in the corpus of knowledge in finance with each SAP assignment that I complete. So, here is another another blog post on SAP’s bank statement functionalities.
A flexible way to establish GL accounts determination for bank statement activities is provided by the standard SAP system. A number of business scenarios can be mapped using the right posting rules and account symbols. Transaction OT83 provides access to these configuration parameters.
I’ll concentrate on account symbol configuration options and how account alterations can be used to improve GL account determination for bank operations in this blog.
2. Masking Capabilities
The masking functionality is frequently used during bank statement processing to produce accurate GL accounts. For instance, if the account symbol BANK has the mask “++++++++++” attached to it, the GL account linked to the house bank account will be returned (i.e., configuration in transaction FI12). It will be GL account 113100 in this instance.
Determining bank clearing GL accounts for incoming and outgoing operations is another common mask:
– The mask “+++++++++1” instructs SAP to derive the home bank GL account and change the final character with 1, for example, 113101. Example: BANK IN is the account sign.
– Mask “+++++++++2” will also result in GL account 113102. For instance, the account sign BANK OUT
Additionally, it is possible to set up various GL accounts for the bank operation’s currency. For example, have a look at how the account symbol BANK CHARGES is set up. The GL account 479000 is the default GL account for all currencies, as shown by the mask “+” in the currency field. However, the application will obtain a different GL, namely 479200, if the bank statement is in EUR.
3. Changes to Account
You won’t typically need to apply account adjustments to create a proper GL account. Since 2013, I’ve been a part of many projects, but I’ve never seen someone use this functionality. There were only two technical solutions available to me when I recently came across an intriguing business requirement: – Dramatically increase the number of account symbols and posting rules.
– Put into practise an improvement to derive GL accounts from account modifications.
The first alternative is significantly simpler from a technical standpoint, and any junior consultant can do it. It also has the benefit of not requiring any coding.
This solution ultimately won out and was put into practise. More than 150 posting rules had to be configured as a result, and they had to be shared throughout multiple house banks and transaction kinds.
I had to make a few adjustments to the posting assignment guidelines while I was under hypercare, and it took me a long time to get all the information I needed (e.g. which account symbols to adjust, which posting rules to add, what transaction types are impacted etc.).
This, in my perspective, is a fantastic illustration of technical debt, where a choice made during the implementation phase speeds up project delivery but ultimately leads to increased expenses during the support phase.
Resuming the subject. The assignment of GL accounts for the account symbol CLR IN is shown in the screenshot above. KREAG and UNIVB are the two keys I use for account modifications. These keys match the house bank IDs listed in FI12, which are as follows:
The logic’s basic premise is that the GL account for the account symbol CLR IN will be directly dependent on the house bank. For this situation, the posting rule Z+01 definition is as follows:
This logic has to be activated by one more step. House bank key must be entered during the upload and processing of the bank statement into field FEBEP-KFMOD. My recommendation is to use the BADI FIEB CHANGE BS DATA, method IF EX FIEB CHANGE BS DATACHANGE DATA, to implement the upgrade. Here is some sample code:
View the application log that is generated after uploading a KREAG house bank statement. As you can see, the account modification was used to calculate the GL account for house bank:
The main advantage of this strategy is that you can derive GL accounts for bank statements with more flexibility without configuring a large number of additional account symbols or posting rules. The main disadvantage is that it is founded on an improvement, yet this improvement’s logic is straightforward.
4. Additional Points to Take
There are a couple additional ways to input values into FEBEP-KFMOD. These choices include: The simplest solution to avoid development work is to maintain the search string with the appropriate update scenario (see post for more details).
– User exit EXIT RFEBBU10 001 and BADI FIEB CHANGE STATEMNT are more options.
– You can directly write the values to FEBEP-KFMOD in an XSLT transformation if you utilise an XML-based bank statement (see post for more details).
– You can use BADI FIEB GET BANK STMTS X to perform the same action if you use another bank-specific statement format, such as CSV (see post for more details).
Once you read this sentence, I hope you learned something beneficial. I’m eager to hear your thoughts and observations.