Detecting SOD Violations Using the SOD-Tool

As explained in How to analyze SOD violations in SAP ERP and S/4HANA: an overview there are 4 possible combinations where change data is stored in the SAP system, combinations of data in a table and/or change documents. In other articles we described how to analyze SOD violations using data from tables or a table and a change document. Here we will use an example to show how to detect SOD violations where a user changed object A and also changed a related object B, and data in both cases is stored in change documents.

One of the SOD conflicts that may occur in your SAP system, or any other ERP solution, is that a user can change a vendor (e.g. change the bank details), and change or approve a purchase order to the same vendor. (Note, the cases where a user creates a vendor or a procurement related document are already covered by the example of vendor bank changes and payments in article SOD Control for Vendor Bank Data and Payments.)
Changing a vendor and also changing a vendor PO can lead to couple of erroneous/fraudulent scenarios such as diverting money to another bank account, or manipulating payment terms.

In the example of vendor changes and changes to a PO, you can use remQ’s SOD tool, which you can access via the admin transaction or directly at /n/REM/SOD_CONFIG.

Vendors and purchase orders are SAP business objects for which changes are recorded in change documents. The change document classes for vendors and POs are KRED and EINKBELEG respectively.

So create a new rule and enter change doc. classes and texts (see help text for the tool here: Access Violation Management (SOD Tool).

The link table is required to make sure the results of the search will only contain SOD violations where the same user changed one vendor and changed a PO from the same vendor. This is different than analysis in SAP authorizations, that usually show users have SOD authorizations violations and that means the user can change vendors and POs in general. This can lead to situations where a user has an SOD risk but actually never executes changes for vendor A and POs for the same vendor A, but actually changes vendor A and changes POs for vendor B – in this context, authorization SOD violations result in many false positives.

Change documents only contain very basic information, you can look at change documents using report RSSCD100. If you look up changes docs with type KRED, you find they only contain the vendor number and company code, plus details of the change such as user, old value, new value. Change docs for POs, type EINKBELEG, contain the PO number and company code and other details.
In order to restrict search results in PO changes to those where a given vendor was changed, the POs have to be resolved and linked to a vendor.
PO numbers and vendor numbers are contained in table EKKO (for instance). a table that links PO and vendor numbers can be used to perform this filtering and restrict search results and make them very specific.

In the SOD tool there is an entry help that will help you determine suitable tables that can link objects.

Once you entered the information on the link table and all texts, you need to decide which time frame you want to search: risks in our scenario usually show when there is 1. a vendor change and then 2. a PO change. So the time horizon for changes ob the vendor objects should be larger than the time horizon for PO changes, for a continuous monitoring approach you can set the time ranges to e.g. 1000 days for vendors and 1 day for POs, as you run the check on a daily basis. In our example we use a larger time interval to catch more test data.

When you execute the SOD check, this will create alerts that you find in the alerts transaction.