Report RPUAUD00 (logged changes in infotype data report) is a very useful report for tracking and auditing changes to key infotypes or groups of fields on infotypes for employee master data or applicant data. Modifications to infotypes you have chosen to track are easily reportable based on a variety of selection or sort criteria, including the ID of the user who made the change, the date/time stamp of the change, personnel number of the changed record, and infotype number.

You have the flexibility to configure infotypes or groups of fields to be tracked and to determine dependencies between the field groups. You can track and report on changes to infotype and field data using either long- or short-term documents. I’ll explain the difference between the two types of documents and give examples of when you might want to use each, along with configuration instructions.

Definitions

The primary difference between long- and short-term documents is the way in which the revision information is stored in the database. (Note that the terminology does not relate to the amount of time the documents are kept in the system.) Long-term documents are stored in the database by personnel ID and by infotype being tracked. The main purpose of the long-term document is to audit who did what. Thus, the sort order of the change data in the database makes sense for this purpose. Typically, the long-term documents are used for internal audits and to view a history of changes, including deletions of key infotype data, by user ID.

Short-term documents differ from long-term in the way that they are stored. The main purpose of short-term documents is to track very specific changes to certain infotypes or groups of fields within infotypes. Because the purpose is to monitor when something changes (rather than the who and what of the long-term document), the most important thing to understand about short-term documents is that they track the “when” of changes by storing the data by the date/time of the last change. One of the most common uses of short-term documents is to develop custom programs (such as data extracts) that monitor and report changes to specific infotype and field groupings in order to report those changes to an external program or vendor. By using short-term documents in this case, you can look for changes to groups of fields in one entry rather than tracking multiple fields separately.

Configure Change Documents

To use short- and long-term documents via RPUAUD00 or your own custom programs, you must first configure R/3 to monitor and track the specific infotypes and field groupings that you determine to be critical. To do this, use IMG menu path Personnel Management>Personnel Administration>Tools>Revision>Set up change document. You take three steps to configure change documents for infotype audits. First, you determine the infotypes to be logged in your system (Figure 1). In this step, you identify the infotypes that will be tracked via either long- or short-term documents. You must also define the type of transaction class to be recorded. Transaction class A is for HR master data and transaction class B is for applicant data. You must specify an entry for both classes per infotype if you wish to capture employee and applicant data for the same infotype.

Figure 1

IMG configuration for infotypes to be logged

In the next step (Figure 2), determine whether you are going to track changes for all fields in a given infotype or for specific groupings of fields. To track all fields on an infotype, enter the infotype, a sequential field group number (two digits), and an asterisk in the field name column. To create field groups that track changes for a specific grouping of fields within an infotype, specify the fields in the field name column, along with a field grouping. You use field groupings for either short- or long-term documents.

Figure 2

Configuration for field group definition

After defining the field groups, your final configuration step is to determine the characteristics of the field groups (Figure 3). Here, you assign a document type to each combination of infotype and field group to determine which type of change document is valid for each group. The final piece to the field group characteristics is the ability to define supplementary field groups. Supplementary field groups allow you to store change records for a second set of fields only in the event of a change in a trigger field group. Say for example that you have a field group of 01 tied to infotype 0009 and you add a supplemental field group of 02 to that entry. Each time a change occurs in field group 01 that causes the revisions to be written to the database, the fields contained in field group 02 are also written. This relationship is one-way, however. If the change occurs only in your supplementary field group of 02, the trigger field group of 01 is not written.

Figure 3

Configuration for field group definition

A.J. Whalen

A.J. Whalen has successfully combined more than two decades of global business expertise with in-depth experience in the strategic development, management, and delivery of large-scale projects and education for SAP ERP HCM. Prior to his current role as SAP Marketing Director at Velocity Technology Solutions, he served as lead consultant for several global SAP implementations and engagements as well as an SAP Conference Producer for Wellesley Information Services. A.J. has been invited to speak at nine annual SAP educational events and holds an MBA degree from the Stern School of Business at New York University.

You may contact the author at whalen.aj@gmail.com.

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