Posted
February 11, 2021
Updated
February 11, 2021
This article will guide you through the process of setting up SOD controls using remQ’s single action tool, the SOD tool, and using SQVI queries with the SQVI2CHECK tool.
As an example, we use a control that monitors SOD violations for changing vendors’ bank data and initiating a payment (starting a payment run).
The data required for this is logged by the SAP system in change documents and tables, and that means we will have to set up the control in 2 steps:
1. create intermediary data from events in change documents and save the data in a table, and
2. create SQVI queries that map events for changes of bank data and starting a payment run;
finally, we will map and format the output of the second step so that you get a formatted remQ control and you can decide which fields etc. you want to see in the alerts.
Note, payments are saved in tables REGUP and REGUH and changes to that data is not logged in the system. You could enable logging by switching on table logging or creating change objects for that data, and adding another rule to the configuration described here.
Step 1 — use the single action tool and create log data for changes of vendor bank data
From the admin transaction go to the single action tool, or directly start /REM/SINGLE_ACTION. Create a new rule:
In the rule ID we enter PP53 (as an example), select Active CM (this defines in which mode the results will be generated), then we enter the Change Object KRED for all vendor changes.
Now we define the table LFBK as a table we want to monitor.
The results are just intermediary and we do not want to display them in the /REM/ALERTS transaction, but they will be saved in the /REM/TMDATA table. To hide alerts from this single action check, define a special status of the check’s alerts, in our example N.
You can now run the single action check directly from the single action setup transaction, or from the admin transaction, or directly schedule it to run in intervals.
Step 2 — creating SQVI queries to map creation/change of vendor data and posting payments
All SQVI queries that you want to use in remQ must start with precursor REM_<any name>, the second part of the query name can be chosen freely.
We are setting two SQVI queries,
REM_LS02, User created Vendor and posted Payment
REM_LS021, User changed Vendor and posted Payment
2.1 We start with REM_LS02:
Go to transaction SQVI and create a new query, after you have entered the name (remember, needs to start with REM_) you need to select data source = Table join.
On the next screen, Choose Data Source, please add the following tables: LFA1, REGUH, BKPF.
Now add the mapping between the selected tables as shown here:
Next you need to add the selection field and fields that will be displayed in the output of the SQVI report:
On the next screen, create a variant:
The date range can be dynamic.
Save the SQVI query.
2.2 REM_LS021, User changed Vendor and posted Payment
Create a new query, name=REM_LS021, using tables REGUH, BKPF, and /REM/TMDATA.
What has the TMDATA table to do here? In the first step you created alerts using the single action tool, and alerts are saved in that table /REM/TMDATA. We now combine those alerts with data from REGUH and BKPF to detect SOD actions.
Define mapping as shown below:
Select fields for the SQVI output (those fields will be available for the remQ alert later):
On the next screen, create a variant and define selection parameters:
as Check ID add the Single Action Tool Rule ID which we used at the start of the article.
The output of this SQVI query can be used as input for a remQ alert. We need to set the frame for an alert and select fields for the layout of the alert details.
This is done in transaction /REM/QV2CHECK. Here select the SQVI query we just defined from the left query column, to get the mapping cockpit.
Assign unique REM_IDs for all 2 queries in order for the system to display them under the same alert ID.
In the MESSAGE_NAME field enter the name that will be displayed in the alerts transaction – this should be the same for all of them.
In MESSAGE_TEXT enter the name of the query – this can be different for each query.
Next step is to map the fields from the SQVI output to the alert details; click on input help in a field in order to get the parameters that can be selected:
Now you can run and schedule the check and it will create alerts based on the data and executed SOD transactions.
