Monday 6 November 2023

Missing posting rules in FEB_BSPROC

This blog post describes a workaround that will be useful for those actively working with bank statement processing in SAP. This workaround deals with a known problem for which SAP issued a KBA OSS-note 2210038 – “FEB_BSPROC – Posting rules missing in F4 help”. Unfortunately, the KBA does not provide any recommendations or workarounds. That’s what I’m trying to address in this post.

Let’s start. The problem is very simple. When the user processes items in the bank statement via transaction FEB_BSPROC (i.e., newer version of the transaction FEBAN) and tries to adjust the posting rule for an item, he/she can see only a limited number of posting rules. Screenshot below shows that only 9 posting rules are available in the list:

SAP HANA, SAP HANA Career, SAP HANA Jobs, SAP HANA Prep, SAP HANA Preparation, SAP HANA Tutorial and Materials, SAP HANA Guides, SAP HANA Leaning, SAP HANA Certification

However, the list of relevant posting rules might be longer. The screenshot below shows the list of some of the posting rules defined in the system. But as you can see, only some of them were present on the list.

SAP HANA, SAP HANA Career, SAP HANA Jobs, SAP HANA Prep, SAP HANA Preparation, SAP HANA Tutorial and Materials, SAP HANA Guides, SAP HANA Leaning, SAP HANA Certification

The explanation provided by SAP is very simple. During post-processing, the user can see only those posting rules that were assigned to the relevant transaction type in transaction OT83. In this case, the bank account is assigned to the transaction type UA_KREAG. The screenshot below shows that the assignment of external BTC-codes uses only some of the posting rules and only these posting rules are available for the user during post-processing:

SAP HANA, SAP HANA Career, SAP HANA Jobs, SAP HANA Prep, SAP HANA Preparation, SAP HANA Tutorial and Materials, SAP HANA Guides, SAP HANA Leaning, SAP HANA Certification

The business reason behind this configuration is simple. For the purposes of this configuration, we rely on the list of external BTC-codes provided by the bank. If the bank provides a limited number of BTC-codes in the bank statement, you can assign only a limited number of posting rules. Of course, you can also assign a pair of default posting rules for miscellaneous operations. Please refer to my other blog post on this topic.

The technical explanation behind this limitation for selection of the posting rules is obvious and makes sense. All posting rules for bank statement are defined on a chart of account level. That means that they are global in nature and can be re-used across all company codes (and house banks) that share the same chart of accounts.

So, what’s the workaround? It is essentially quite simple. You can devise a list of dummy BTC and do the mapping for remaining posting rules. For example, if the bank provides BTC codes as a 3-digit numbers, you can devise your own numbering that is different than the one provided by the bank. Alternatively, you can even use the posting rule key as a BTC-code. See the example below:

SAP HANA, SAP HANA Career, SAP HANA Jobs, SAP HANA Prep, SAP HANA Preparation, SAP HANA Tutorial and Materials, SAP HANA Guides, SAP HANA Leaning, SAP HANA Certification

From business perspective, this configuration does not make sense, because the bank will never provide a bank statement with BTC code UA+T. But this workaround will address the requirement of the user to see all relevant posting rules in the list. See the revised list of posting rules in FEB_BSPROC below:

SAP HANA, SAP HANA Career, SAP HANA Jobs, SAP HANA Prep, SAP HANA Preparation, SAP HANA Tutorial and Materials, SAP HANA Guides, SAP HANA Leaning, SAP HANA Certification

One final remark, which is also highlighted in KBA article by SAP. The fact that the posting rule is not available in the F4-list in FEB_BSPROC does not mean that you cannot use it. Experienced users can type the posting rule key directly into the field and save the changes. SAP will not issue any error messages in such cases.

No comments:

Post a Comment