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

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)

‍

‍

‍

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.

‍

‍

‍

• 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).

‍

Fazit

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.