Hello, SAPers!
Search string represents very useful functionality that is used to enhance the efficiency of standard EBS interpretation mechanisms. There are different instances when this functionality might be applicable e.g. for clearing purposes, for filling different fields with input values etc. I think that this functionality is especially useful for bank statement in MT940 format with unstructured field 86. However, content (both official documentation and user documents on SCN and similar resources) related to the configuration of this functionality is limited. Among those limited sources, I would like to recommed a great document on search string for EBS by Nitesh Patel: Search String for EBS (Electronics bank statement). At the same time, I would like to share my own experience of search string configuration, which might be useful for some of you.
1) Change of posting rule depending on the fixed text in the line items
Standard functionality of EBS implies that you have performed mapping and assigned external Business Transaction Codes (hereinafter referred to as BTC codes) to internally defined posting rules. However, some banks cannot provide you with the list of BTC codes or use just one BTC code for all transactions. For instance, one of the Ukrainian banks uses BTC code 110 for all operations (however, they do not call it BTC code, they just say that this is some kind of constant without any business logic behind it:). Nonetheless, this constant can be used as BTC code. We can assign this BTC code to two internally defined posting rules with different signs for example:
As you can see, BTC code has been assigned to two posting rules associated with incoming payments from customers and outgoing payments to vendors. Standard interpretation mechanisms can distinguish between different transactions depending on the transaction sign from the bank statement and deploy either one posting rule or another. However, you are limited only to two posting rules and consequently you’ll have to perform a lot of post processing to post all transactions. Therefore, you’ll have to analyze separate lines of bank statement and define some patterns that will enable you to apply search string functionality. You can find an example of line item with commission payments below.
As you can see, note to payee of this line item contains the word “COMMISSION053”. Consequently, we can use this word for configuration of search string. In order to configure search string use the transaction OTPM or following menu path:
SPRO→ Financial Accounting (new) → Bank Accounting → Business Transactions → Payment Transactions → Electronic Bank Statement → Define Search String for Electronic Bank Statement.
In this transaction, specify the name of search string e.g. BANK_COM, short description and the content of search string. Afterwards, go to mapping part of the menu, clear all entries in the column “Target” and write instead of these entries UA-B, which represents a posting rule for bank charges (please, refer to the figure below):
In order to test your search string, enter your sampe text (note to payee from bank statement) in the Entry text box and press the button Test. If you've configured search string correctly, it will return the UA-B or another configured custom value. Afterwards, go to tab Search string use and add the following entry:
Please, specify on this tab for which combination of company code, house bank and account ID this posting rule will be applicable. Afterwards, specify 110 (or another BTC code) as external transaction code, sign of the transaction (positive or negative), as well as interpretation algorithm assigned to target posting rule (e.g. to posting rule UA-B). In my case, we do not use any algorightms, therefore this field was left blank. Then specify search string name and “Posting rule” in Target field column. Do not forget to activate check box active. Leave the columns Mapping prefix and Partner ID blank.
Thus, the logic behind this search string functionality is as follows: when search string finds the word “COMMISSION053” in the text of note to payee it identifies this transaction as payment of bank commission and triggers posting rule UA-B that posts bank commission.
2) Identification of business parterns via tax number 2
Short intro: sometimes companies decide to use tax numbers as customers/vendors key. This approach has its advantage, because normally there should not be another company with the same tax number 1 or 2. Another advantage is as follows: sometime it is legally required to write your business partern tax number 1 or 2 as requisite of your payment order. For example, in Ukraine there is a legal requirement that payment order should containt tax number 2 as mandatory requisite.
If house bank provides you with a well standardized bank statement (e.g. in MT940 format with all BTC codes), standard interpretation algorithms work perfectly and SAP is able to post all mapped transactions without problem. However, sometime banks apply their own rules (or dialects) that do not comply with SWIFT MT940 format. For instance, if you analyze structured field 86 in MT940 statement (note to payee) you should be able to find customer’s/vendor’s bank key and bank account in the subfields 30 and 31 respectively (at least in Ukraine and/or Russia):
However, sometimes banks apply their own rules and their statement look somewhat different e.g. below you can find sample of MT940 statement from Ukrainian banks. As you can see, customer’s bank account can be found in the subfield 33 whereas subfield 23 contains bank key and other information (MFO – local abbreviation for bank key, EDRPOU/OKPO – local reference to tax number 2 etc).
Therefore, if you try to upload bank statement without any changes you will face the similar error:
However, the company uses tax number 2 of customers and vendors as their key. Therefore, in order to recognize this customer key the following search string has been configured:
Afterwards, the following search string use has been configured on the tab Use of search string:
The combination of company code, house bank and account ID for which this search string will be applicable was specified. Afterwards 110 was specified as external transaction code and + as transaction sign. There was no interpretation algorithm assigned to posting rule associated with incoming payments, therefore the respective column was left blank. Afterwards search string name was specified in the respective column and “Account number” was chosen in the Target field column. Check box “Active” was activated. The columns Mapping prefix and Partner ID were left blank.
Thus, the logic behind this search string functionality is as follows: when search string finds the combination of words “ОКПО ########” in the text of note to payee it identifies ######## as customer key and triggers posting rule associated with incoming payments that posts this payment directly to customer account.
I hope this information will be useful for some of you. I also hope that I'll be able to post another document of search string definition in the near future. All suggestions are welcome!
Best regards,
The Wirtschaftsmann