SAP Master Data Governance, SAP BTP, ABAP environment, SAP S/4HANA business partner, SAP S/4HANA

Improve BP master data with SAP MDG DQM to reduce superfluous costs in invoicing processes

Introduction:

In invoicing processes with suppliers and customers, bank account information such as account number and IBAN play an important role. If this information is not correctly maintained in the business partner master data, costs arise from faulty bank transactions, and business partner relationships may also be strained due to delayed payment processes.

With the help of SAP MDG DQM validations and derivations, such situations can be avoided. A fully automatic reconciliation between account numbers and IBAN can be carried out. Initially, erroneous data records are detected through a DQM validation rule and a DQM evaluation run. Subsequently, these data records can be automatically corrected via an MDG mass process.

Background:

Depending on the configuration and history of the SAP S/4HANA system, account information and IBAN numbers are stored in different database tables. Account numbers and other details are found in the BUT0BK table. Associated IBAN numbers are stored in the TIBAN table.

When new business partners are created using SAP S/4HANA and/or SAP MDG, the information is correctly written into the tables, and no action is required. However, due to the migration of legacy data, interfaces, and data transfers, it can happen that the IBAN numbers, which contain the account number, do not match the dedicated account numbers in the BUT0BK table. In payment transactions, incorrect or improperly formatted account numbers are then used, and bank transactions can fail.

With the help of the SAP MDG DQM validation rule explained here, such erroneous BUT0BK entries are detected. The DQM rule will use a standard function module via BRF+ to calculate the correct bank account numbers from the IBAN numbers. A DQM evaluation run will iterate over all BUT0BK entries and identify erroneous records according to the rule. The user can then send these erroneous records to a mass process. This will automatically correct the account number in BUT0BK through a derivation step. Here, too, the SAP standard function module for calculation is reused.

DQM Validation Rule

The validation rule is created using the SAP MDG app “Validations Rules for Business Partners.” The base table is the table BUT0BK, and the field being checked is BUT0BK-BANKN.

The following screenshot shows the rule in the app:

The scope of the rule defines which records are checked. It is important that only records with an IBAN in the bank details are checked. Therefore, the scope expression includes a BRF+ artifact to read the IBAN from TIBAN using the function module READ_IBAN_EXT through the parameters of the BUT0BK table. If an entry/IBAN is found, the record can be validated and is “in scope.”

The following screenshot shows this scope expression:

The condition expression itself compares the value from BUT0BK-BANKN with the result of the function module CONVERT_IBAN_2_BANK_ACCOUNT. If the values are different, it means that there is an error for this data record. The following screenshot shows the condition expression.

DQM Derivation Scenario / Rule

The derivation rule is very similar to the validation rule and uses the same function blocks. Instead of detecting an error, a derivation can also write or correct the value.

In this case, an extra derivation scenario was defined for this demo in the SAP MDG DQM app “Define Derivation Scenario for Business Partners.” The name is, for example, “Correct Bank Account Numbers.” The base table is BUT0BK, as in this case the BANKN field of this table is corrected. The scenario only requires one rule at the field level. Additional rules are not necessary.

As with the validation rule, the scenario scope can also act on the presence of an IBAN for the bank account number. This ensures that only relevant records are processed in the derivation scenario.

The rule on the BANKN field is relatively simple to define: There are no condition fields, and only the BANKN field is defined as the result field. The screenshot shows the rule in the app “Define Derivation Scenario for Business Partners.”

The decision table CALC_BANKN_FLD_DT generated by the SAP MDG framework also uses the SAP standard function modules to calculate the correct value for the bank account number via the IBAN. The following screenshot shows the details:

All DQM artifacts must be approved and activated after implementation. Additionally, the rule itself must be set to the status “Execution – YES”.

Running the scenarios

Execute Evaluation Run

If no automatic execution of the evaluation run is scheduled, it can be started via the SAP MDG app “Evaluate Data Quality.”

Review of the evaluation run

With the app “Evaluation Results for Business Partners,” the result can be examined in detail. By applying a filter to the rule, the erroneous data sets can be isolated and viewed. In the following screenshot, you can see that 7 business partners do not comply with the rule:

Remediation process with Mass Processing

To initiate a remediation process for one or more datasets, use the “Process” functionality directly from the “Evaluation Results for Business Partners” app.

In the following screenshot, 2 datasets are placed into a mass process.

In the following pop-up screen, the process template to be executed can be selected.

Info: This popup is only available in Cloud Ready Mode. In classic mode, the standard template is always used.

During the process, the derivation scenario is executed. The following screenshot shows the process after the derivation rule. It can be seen that the two incorrect bank accounts in BUT0BK have been corrected.

It is also apparent that a business partner has obviously defined multiple bank accounts, and one of them was already correct. Therefore, it was not overwritten.

Rerun the evaluation process.

If the evaluation run is triggered again, the data quality will have improved because the two corrected data sets will no longer be recognized as errors.

Compare the result with point 1: only 5 bank accounts are still incorrect.

Rating: 5 / 5 (1 votes)