In the SAP system there are several possibilities to review changes made to critical or sensitive information, e.g. supplier master, customer master, accounting accounts, banks. These changes fall into the following categories: “Change Documents” and “Change Logs”.
The main features are:
- “Change Documents”. They are active in the system by default. For a change in a field to be reflected in “change documents”, the following is required:
-
- The field must be associated with a “Data Element” that has previously been marked for writing in “change documents”.
- The field must be associated to a table with a “change documents” object.
- The transaction/programme has to be prepared, at code level, to store change documents on critical fields. There may be Z transactions that do not record these changes as a standard transaction would. From the SCDO transaction, the generation of the code to be included in the program to record the changes in critical fields is performed.
- “Change Logs”. The “Change Logs” are deactivated by default. In order for a modification in a certain table to be reflected, the “rec/client” parameter must first be activated and then the tables in which a change log is to be recorded must be defined. “Log” activations on a table can be performed from transaction “SE13”. This functionality stores any type of change to any field in the same table, regardless of which transaction or program makes the change.
Once we have introduced the characteristics of each of the log types, let’s see in which tables each one is stored:
- Change Documents are generally reviewed on the basis of two tables:
-
- CDHDR: Summary table (header) of the change documents. General information about a certain change (user making the change, date, time and transaction from which the change was made) is indicated.
- CDPOS: Table containing the details of the “change documents”. The change made is indicated (the previous and new value of each of the modified fields is indicated, with the possibility of filtering at table and specific field level).
- The information in the Change Logs is reviewed on the basis of:
-
- Table DBTABLOG: Table that directly contains the change made in the tables marked as “Log”. In some cases, the direct interpretation of the change through this table is complex. Allows filtering at the level of the transaction with which the change has been made.
- Transaction SCU3: Transaction that interprets the changes that appear in the DBTABLOG. It shows in a more direct way the change without having to interpret it. Contrary to the DBTABLOG table, transaction SCU3 does not allow filtering at transaction level.
Automation in SAP GRC Process Control
SAP GRC Process Control contains all the elements to document and manage an Internal Control System, independent of the system in which the key business processes are located.
It allows us to automate a large part of the activities. One of them is the continuous monitoring through automatic controls (CCM), which helps to ensure that the different business processes remain faithful to the initial design.
For example, Continuous Control Monitoring (CCM) allows us to monitor whether a supplier’s bank account has been changed and, if so, by whom and when. This data is contained in different tables where it is necessary to review the changes that have been made to critical fields through, among others, “Change Logs” or “Change Documents”. CCM generates a report with all the changes that have been made so that, from this report, a trained user can determine whether the critical changes are legitimate (have been previously approved) or not.
The main differences between the two technologies for the construction of an automatic control system are summarised in the following table:
In summary, the great advantage of building an automatic change-based control from “Change Documents” is that the capacity to implement a certain logic is very large and therefore allows a much more efficient control to be achieved than by “Change Log”. However, before building a “Change Documents” based control, it is very important to ensure that all changes made to critical fields are recorded.
