Quick Do-It-Yourself Analysis of SoD Violations in Your SAP System

October 24, 2024

Jens Kettler

SAPAuthorization

SAPCompliance

Using SQVI for Segregation of Duties (SoD) Conflict Detection on a Document Level

This guide will walk you through the process of creating an SAP QuickViewer Report (SAP standard transaction SQVI) to identify Segregation of Duties (SoD) conflicts on the document level.

So the analysis is not on the level of user authorization (CAN DO), but actually will detect documents that were created violating a SoD rule, with an associated business risk (DID DO).

This blog post is therefore further detailing our previous blog (<-link to other blog about the webinar) and our recent webinar on ACCESS VIOLATION MANAGEMENT: MITIGATING CONTROLS FOR RISKS IN SAP GRC.

This is a useful tool for SAP authorization consultants, internal auditors, and even business users, to detect and mitigate business risks associated with a lack of segregation of duties.

‍

Important Disclaimer

This analysis is a simple and quick analysis, but it can have false negative results, i.e. some cases are not covered by this approach:

The tables used in this example store the user name of the user who created the document and vendor. Later changes are recorded in change documents and not considered in this simple analysis.

See also the remarks in our webinar, and we will follow up on this issue in one of our next blogs.

‍

Example and Do-It-Yourself Guide

Here we are looking at the case where a user both created a vendor and created a purchase order (PO). The risks is that a user creates a bogus vendor and with the PO requests unauthorized goods that the company will pay.

The conflict detection will be based on two SAP tables: LFA1 (Vendor Master) and EKKO (PO Header).

Prerequisites

Basic knowledge of SAP and navigating the SQVI transaction.
SAP authorization to access SQVI, and the relevant tables: LFA1 and EKKO.

‍

Step-by-Step Guide

1. Access SQVI

Log in to your SAP system.
In the SAP Easy Access menu, enter SQVI in the command field and press Enter.

2. Create a New QuickViewer Query

In the QuickViewer: Initial Screen, click on the Create button.
Enter a name for your query (e.g., SOD_VENDOR_PO_CONFLICT).
Provide a brief description of your query (e.g., Vendor Creation and PO Creation Conflict).
Under Data Source, select Table Join since we are joining two tables.

‍

‍

3. Define the Tables (LFA1 and EKKO)

In the next screen (Table Join Definition), you will define the two tables you need for this query:
- Enter LFA1 in the first table field (this is the Vendor Master table).
- Enter EKKO in the second table field (this is the Purchase Order Header table).

4. Define the Join Conditions

Once the tables are added, you need to define how these tables are related:
- Click on the Join Conditions button.
- In the Join Condition screen, connect the common fields between the tables.
  - The key fields for this conflict analysis are Created By (in LFA1: field ERNAM) and Created By (in EKKO: field ERNAM).
  - ERNAM is the field that captures the user who created the record in both tables.
Ensure the join type is set to an Inner Join, which means the result will include only records where a user appears in both the vendor creation and PO creation activities.

‍

5. Selecting the Fields for Display

After defining the join between the LFA1 (Vendor Master) and EKKO (Purchase Order Header) tables, the next step is to select which fields will appear in your query output. Here's a step-by-step breakdown:

Location on the Screen: On the left side of the screen, you will see both the LFA1 and EKKO tables listed.
Each table will have a list of fields (columns) that belong to it.
Selecting Fields: To choose the fields you want to display in your query output, follow these steps:
1. Expand the table name (either LFA1 or EKKO) by clicking the plus icon next to the table.‍
2. A list of all the fields in that table will appear.‍
3. Select the fields by clicking the checkbox next to each field.
  - From LFA1 (Vendor Master), choose:‍‍
    - LIFNR (Vendor Number)
    - ERNAM (Created By - User ID)
    - ERDAT (Created On - Date of Creation)

‍

From EKKO (Purchase Order Header), choose:
- EBELN (Purchase Order Number)
- ERNAM (Created By - User ID)
- AEDAT (Created On - Date of Creation)

‍

‍

Once selected, these fields will move to the Display Fields section on the right-hand side of the screen.
- Purpose: The fields selected from LFA1 will allow you to see information about the vendors, while the fields from EKKO will give you data about purchase orders created by the same user. This is essential for identifying if the same user is involved in both processes, indicating a potential SoD conflict.

‍

6. Defining Selection Criteria

Selection criteria allow users to narrow down the data they want to view by applying filters. For example, a user may want to see records for a specific date range or check records created by a specific user.

Location on the Screen: On the same screen where you select fields for display, you will find a Selection Fields section in the middle-left of the screen. This is where you define which fields can be used for filtering the data.
How to Define Selection Criteria:
1. In the Field Selection section (where the fields from LFA1 and EKKO are listed), you can also check the box for fields that you want to make available as Selection Criteria. These fields will allow the end-user to input values before executing the query.
2. For example, if you want to filter by the user who created the vendor or purchase order
  - Select the ERNAM field from both LFA1 and EKKO.
  - By checking these fields as selection criteria, users will be able to enter a specific user ID before running the report to narrow down the results.

‍

If you want to filter by creation date:
- Select the ERDAT field from both LFA1 and EKKO.
- This will allow users to input a date or range of dates (e.g., showing all records created within a certain time frame).

‍

‍

Why Use Selection Criteria: The selection criteria make your query dynamic and more user-friendly, allowing others to filter results by specific users or date ranges without needing to modify the query directly. It ensures the query is reusable across different scenarios.

With these additional details, your query will be more flexible and usable by a variety of users with different requirements for SoD conflict analysis.

7. Save and Execute the Query

Once the fields and selection criteria are defined, click Save to store your query.
Now, click Execute (F8) to run the query.

‍

‍

8. Analyze the Results

The output will display a list of vendors and purchase orders, showing any users who created both a vendor and a PO, based on your join condition (matching the same Created By user ID in both tables).
Review the output for potential SoD conflicts.

‍

‍

9. Optional: Enhance with Additional Fields or Filters

You can enhance the query further by adding more fields, such as:
- Vendor Name (LFA1-NAME1) for more user-friendly identification of vendors.
- Purchase Order Type (EKKO-BSART) to filter specific types of POs.
If desired, you can also save the query as a variant for specific departments or users.

Troubleshooting

If the query doesn’t show expected results, check the join conditions to ensure they are correct.
Ensure that the data in LFA1 and EKKO tables is populated, and the users have performed both actions (vendor creation and PO creation).

‍

Conclusion

By following this guide, you will be able to create a custom SQVI query to detect SoD conflicts where a user has both created a vendor and a purchase order. This query can be further customized to suit specific reporting or compliance needs.

The same approach works for other potential SoD violations.

The analysis performed here is limited to the users who created the vendor/document, not taking into account changes that might occur later.

In many real-life fraud scenarios, this is a reasonable assumption. One could even argue, that if another user makes changes to the (bogus?) vendor after it was created, then a 4-eyes principle is effectively established because another user had a chance to review the vendor.

So while being incomplete, it is effective in many cases, and very easy to implement.

Note the SQVI query created can be executed at any later time, so a periodical review is easy and can help address and reduce risks from a lack of segregation of duties.

ABOUT THE AUTHOR

Jens Kettler

Jens has 20+ years of experience in SAP security, compliance and internal controls. He is an ex-auditor, always curious, willing to learn and to share knowledge. At VOQUZ Labs Jens is responsible for our risk and compliance products. He enjoys interacting with customers and finding quick and simple ways to improve our products to deliver value to customers. Pragmatic and customer-focused? Then Jens :)

SEND US A MESSAGE

Do you have any questions or something to add? Just leave us a message, please! Your message will be delivered by e-mail to us and will not be published.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Quick Do-It-Yourself Analysis of SoD Violations in Your SAP System

Using SQVI for Segregation of Duties (SoD) Conflict Detection on a Document Level

Important Disclaimer