In R/3 Release 4.7, SAP introduced an audit log to track changes to Personnel Development (PD) infotypes. The audit log for PD infotypes provides similar functionality to the well-known Personnel Administration (PA) infotype log. You configure the PA audit log on tables T585A, T585B, and T585C and display it via program RPUAUD00. You configure the PD infotype change log in table T77CDOC_CUST and display it with program RHCDOC_DISPLAY. The PD audit log can track changes to infotypes 1000, 1001, and 1002. You may want to track changes to PD infotypes simply to ensure that everyone follows company guidelines, or you may need to implement this feature as part of a corporate governance policy. It also works in mySAP ERP Central Component (ECC).

I’ll explain the steps required to activate the PD audit log. Then I’ll describe how to view it. Finally, I’ll discuss some options available for enhancing the PD audit log through custom development.

Note
For more information about the PA infotype change log, see A.J. Whalen’s article “Ask the HR Expert: What’s the Difference Between Long- and Short-Term Documents in Report RPUAUD00?”

Note
If you want to display only the most recent change information for all PD infotypes, you can use transaction RH_RHRHAZ00. Refer to Janet McClurg’s article “Monitor Changes in Organizational Management Data with Report RHRHAZ00,” for a detailed explanation of this transaction.

PD Infotype Changes Configuration

You must perform some configuration to activate the PD infotype change log. The default SAP system does not record changes for any PD infotypes. Start by using transaction SM31 to update table T77CDOC_CUST. You create entries in this table to indicate which PD infotype changes the system should record in the log. This configuration does not yet have a step in the implementation guide (IMG).

Table T77CDOC_CUST contains several columns. You most likely want to use value 01 for the plan version. This is the active version of your planning database. Other versions are possible but since they are not the active version it is unlikely that you’ll require an audit of changes made to those versions.

As Figure 1 shows, the Object type column specifies which objects to monitor. The Infotype column identifies which infotypes to track. Infotype 1000 contains the basic definition of each object; infotype 1001 contains the relationships between objects; and infotype 1002 contains one or more long descriptions. The Subtype column has different meanings. For infotype 1001 the subtype allows you to limit the audit to certain relationship types. The subtype of infotype 1002 allows you to limit by type of description. Infotype 1000 has no subtypes. The Active check box turns infotype logging on and off, as the name suggests. This is handy if you wish to deactivate a logging entry without deleting it.

Figure 1

View of T77CDOC_CUST

PD Infotype Change Reporting

SAP provides program RHCDOC_DISPLAY for creating reports from the PD infotype change log. Figure 2 shows a sample of this report, which includes an icon column called OT for the object type. The example contains the symbol for position. Next is the Object ID column. SAP generally assigns this eight-digit number at the time a user creates a PD object (organizational units, jobs, or positions) by using Organizational Management (OM) transactions such as PP01, PP03, and PPOME. The name of the object and the infotype that changed are shown next, followed by the validity dates of the change. The Name column indicates the user who performed the change. The Date and Time columns show when the change occurred. Each field of the infotype that was modified appears as a row on this report. This gives a complete picture of the before and after status of this object in relation to the change activity.

Figure 2

Report RHCDOC_DISPLAY

You can access the PA audit log program, RPUAUD00, via transaction S_AHR_61016380. However, SAP does not provide a standard transaction for the PD audit program RHCDOC_DISPLAY. You can run the program directly in transaction SE38 or SA38. Many companies do not allow access to SE38 or SA38 in production systems. You can make the report available to select users by creating a custom transaction code. An ABAP programmer can create a Z transaction to run the RHCDOC_DISPLAY report. You must update the authorization roles for persons who should have access to this report to include the new transaction code.

Custom Programming Using PD Infotypes Change Log

Your company may find that the existing PD infotype change log is inadequate for your needs. Going beyond the standard audit log is possible but requires advanced programming skills. Table T77CDOC indicates the PD infotypes for which logging is possible and it also specifies the ABAP class used to record the changes. Figure 3 shows the standard delivered table T77CDOC. Activating logging for other PD infotypes would require a custom ABAP class containing the appropriate methods and logging logic. You can use the existing classes shown in Figure 3 as a model when developing custom classes in transaction SE24.

Figure 3

Table T77CDOC with three classes to use as models for creating a new class to implement logging activity

The standard log display program should satisfy most users, but you may want to create a custom report to show the PD infotype change log in a different format. Some users insist on having a much easier to read format for their change documents. One common user request is for a report that has only one line per changed record rather than a line for each changed field as in the standard report. If you plan to use custom development, you should not attempt to completely rebuild the logic on your own. Instead, you should incorporate the standard function modules as the foundation.

You can develop a custom program to read the data and generate any client-specific output format. R/3 stores the PD infotype log data in the CDCLS cluster table. Programmers familiar with accessing cluster tables may wish to read the table directly. Several standard function modules exist that can provide easier access to the data. Table 1 lists a couple of these function modules. Using these function modules in your custom code ensures accurate access to the change document information. It also allows your program to focus on the output format rather than the data access methods.

Clay Molinari

Clay Molinari has 20 years of experience in the IT industry and has been working as an SAP HR consultant since 1997. He is currently president of C&C Savant, Inc., an SAP consulting firm that specializes in combining standard SAP configuration and custom ABAP programming to help its clients solve unique or complicated requirements.

You may contact the author at claymolinari@comcast.ne.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.