In this blog, we’ll focus on the possbile ways to log and trace user activities in SAP HCM system for Infotype changes, transactions, programs, tables, user activities,…

Log for Personnel Administration – Infotypes Changes (PA)

This log is used to get history of the PA infotypes. When you delimit or create a new infotype, the records are still existing in the database. But when you modify or delete records, the information is gone. This applies to R/3 activities and ESS/MSS or portal activities.

Solution is to log all the infotype changes with a view on the old and new data.

The customizing can be done for a change on the infotype or at a field level.

• Configuration Views: V_T585A, V_T585B, V_T585C
• Display Result Program: RPUAUD00
• Display Result Transactions: PC00_M16_UAUD, S_AHR_61015505, S_AHR_61016380, S_ALR_87014081
• Data are stored in Cluster PCL4

Remark: Read or Display access is not taken into account in this log. Solution would be a custom enhancement in the infotype user-exit (ZXPADU01 or BADI).

This log is “technically” actived by default on the system level but not running until the config tables are filled.

Log for Organizational Management and Personnel Development – Infotypes Changes (OM/PD)

Infotype changes for objects (e.g. O, S, P, C, K,…) is also possible. This means that we can trace, for example, the object creation or the relationships modifications.

Technically this means all data under the HRP* tables.

• Configuration Views: T77CDOC_CUST
• Display Result Program: RHCDOC_DISPLAY

The same remark applies here as for the PA log.

Program Log

In specific cases, we want to monitor some specific programs. Reports that are needed on the system but that are “dangerous”, accessing directly tables, providing mass process, etc

For each logged report, you can decide to trace dialog activities (foreground) or batch activities (background).

By default, more or less a thousand of standard reports are in the table but not active. You should also add your critical customer reports there.

• Configuration Table T599R or View V_T599R

• Display result Program: RPUPROTD
• Display result Transactions: S_AHR_61015506, S_AHR_61016381, S_ALR_87014082

Table Log

In some cases, reports change directly tables. Sometimes, we don’t know which report/transaction and user modified a table.

It is possible to trace all activities related to a database table using the technical log.

• Set the parameter “rec/client” in the system profile. (Transaction RZ10 or RZ11)
• Activate the log (“Log data changes”) in the “Technical Details” of the DB table definition (transaction SE11)

• Display the results with transaction SCU3 & Select Evaluated Logs, then the table with option “evaluation for Table”

I have faced 2 specific uses of this log:

1. For the Sarbanes-Oxley (SOX) audit, we had to log the T000 table. Because this table changes the system type (Prod, Dev, Test,…) and there are several ways to changed the values: SCC4, SE16N, …
2. Table PA0003 is the technical table behind the infotype 0003 “Payroll Status”. Altough the infotype was logged with the PA log, some changes were made to the infotypes. How was this possible? This is because this particular infotype is not really modified by users in dialog mode but by programs. The Payroll program (RPCALC*), the Time program (RPTIME00) and the mass update program (RPUTRBK0) are directly accessing the database table. With this trace we could find from which source the change came: Infotype changes (payroll or time relevant), payroll or time run, etc

User Log

The user log is really often by default actived on the system. What depends is the logging period. Most of the time, the period is set to the 3 last months.

With this log we can know what program or transcation each user started.

• Transaction ST03N in Expert Mode, Workload on Total, User Profile

• Function Module SAPWL_WORKLOAD_GET_STATISTIC is retriving all results as raw data

This is a nice way to retrieve log for one user at a time. Because we have to double-click on each line and there is also a mix of report and program, so not really usable as report.

An alternative would be to create a custom report based on this function module such as this one:

This is a really nice tool to play Big Brother 😉

We used this functionnality for the SOX audit and the GRC Segragation of duties. In order to decrease the number of conflicts, we used this log for a year, saving the results by user, user group, date (month) and transaction. We did a reengineering of the roles. We grouped the users by type of job/roles and compare their accesses, tranaction in the roles with the transaction that they really used.

This was a long process but with this we solved 95% of the conflicts without impacting (too much) the users and the company processes.