During my years of SAP HR experience, I have repeatedly encountered two issues when it comes to maintaining personnel records in the Personnel Administration (PA) module’s employee master. Both are related to the way users maintain employee records.

The first problem occurs when you maintain employee master data in PA30, which does not leave a history of the change being performed. The second problem is when you use the change icon instead of the copy icon to edit employee master data, which could introduce erroneous or outdated employee records.

Based on my experience, I’ll show you how to avoid such issues and improve the process of maintaining personnel records with a few rules and a step-by-step procedure to configure master data change actions using transaction PA40 (personnel actions). In this article, I’ll walk you through the two common errors in detail and explain the importance of time constraints when you maintain employee master data, provide the steps required to configure PA40 actions, compare when you should use PA30 instead of PA40, give an example of a daily activity report that displays all infotype changes, and advice you on a couple cautions to keep in mind. In a future article, I’ll provide instructions on how to configure your system to automatically route daily activity reports to the email or SAP inbox of an HR manager or other individual. The manager then can monitor users’ HR data maintenance in the system.

Common Errors

The first error is that the users maintain employee records directly through transaction PA30 (maintain HR master data). By doing so, they leave no history in infotype 0000 (actions) of the action or the change being performed on the employee record, unless the audit trail functionality is configured and switched on. Although audit trail functionality is standard in an SAP system from releases 3.x onwards, in most cases it is not turned on, primarily because of the excessive volume of data it generates on the server. This is especially the case when it comes to frequent transactional data, such as personnel actions and employee master data maintenance.

A second common mistake when using transaction PA30 is that as users maintain employee records, they often use the change icon to change or modify information on a specific infotype, which is supposedly a change in the employee’s information as of a certain date. The user instead should select the copy function icon to copy the previous record of the infotype. Doing that brings the information from the previous record into the new record, updates the new validity start and end dates (as well as other information), and saves the revised record.

This creates a history of the previous record by delimiting it to the end date right before the start date of the new record. Then when users display the history of the infotype records, they see the previous record in the history. If the user simply changes the record, no history is kept. This could lead to erroneous results when processing time-sensitive data that uses that particular infotype. For more information on functions, see the sidebar “Comparison of Delimit, Change, and Copy Functions.”

Time Constraints

Understanding the concept of the different time constraints is crucial during data maintenance. A time constraint indicates whether more than one infotype record can be available at the same time. Time constraints play an important role in maintaining employee master data and they ensure that vital employee information is available to the company at all times.

On the other hand, non-critical information has gaps in time periods and the data is available when the records change. The following time constraint settings are:

• An infotype record must be available at all times. This record may have no time gaps. You cannot delete the record last stored on the database because all records of this infotype would also be deleted.
• Only one record may be available at one given time, but time gaps are permitted
• Any number of records may be valid at one time and time gaps are permitted

To avoid several common mistakes that occur when users maintain employee master data via transaction PA30, I advise using personnel actions via transaction PA40 instead. In this method, users are guided through the sequence and maintenance modes (such as change, copy, delimit) of predetermined infotypes. The following sections describe how to configure PA40 actions and evade potential errors in your master data.

Configure PA40 Actions

This section describes the various steps required to configure PA40 actions successfully. You must define the info group, maintain the info group, create an action reason, define an info group modifier, and set up the personnel action. The implementation team should configure personnel actions for all kinds of employee master data maintenance. Users can then access the personnel actions using transaction PA40 instead of using transaction PA30.

Define Info Group

Follow IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Define Infogroups to define the info group you want to include in the action.

In the screen shown in Figure 1, you must specify which infotypes should be part of the personnel action, in which sequence they should appear (shown in column N. [number]), and their operation mode (such as display, copy, change, or delimit). Then, when the user executes an action, the infotypes appear one after the other in the pre-defined manner. This step also ensures that the infotype is maintained in the correct data maintenance mode.

Figure 1

Maintain an info group

Here are some of the fields you need to define in this step:

Info group: Enter the number and name of the info group you are configuring, such as 04 Maintain Master Data

User group-dependent: Select this check box if the definition of the action is dependent on the user group. When an action is dependent on a user group, it enables your implementation team to configure actions that depend on the type of user. You define a user group if different types of users require different info groups to be defined.

For example, within the HR department one user group maintains payroll data and another user group maintains benefits data. Both user groups may require infotypes in an action to appear in a specific sequence that corresponds to their data maintenance. The info group defines the unique infotype sequence relevant to a particular user group. If the info group is not user-group dependent, select the Reference user group check box.

Reaction: This field defines how the system should react if the user group is not maintained. If the info group is not user-group dependent, then the system reacts in one of the following ways: ‘ ’: no message — the menu for the specified reference user group is displayed; W: warning — the menu for the specified reference user group is displayed; or E: error — no menu is displayed.

Infogrmodi: Info group modifiers allow the implementation team to configure the action’s info group based on criteria, such as company code, personnel area, employee group, action type, or action reason. To use the info group modifier, you must use the feature IGMOD (info group modifier). In this example, the return values based on the decisions created in feature IGMOD represent the value entered in field Infogrmodi. Refer to the section “Set Up Personnel Action” for more information on defining info group modifiers.

N.: Sequence number of the infotype

Operation: This is the mode of the infotype that appears in the personnel action, such as COP (copy), DEL (delete), INSS (insert or create), DIS (display only), or LIS9 (delimit)

S.: This particular field contains the infotype screen control, which enables you to assign more than one infotype text. For example, you use this field in the attendance infotype to maintain cost assignment in the subscreen.

Maintain Info Group

Once the feature IGMOD is maintained properly, the return value from the feature can now be maintained in the info group maintenance screen. To maintain the info group, follow IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Define Infogroups > Info group.

It is not necessary to enter the info group modifiers (such as ADDR, BANK, and PERS) in this screen for basic maintenance purposes. However, if you choose to configure the action info group differently based on certain key fields (for example, personnel area, employee group, or employee subgroup), enter the info group modifiers shown in Figure 1.

When you implement the info group described in the “Define Info Group” section using the IGMOD feature, the system generates the specified infotype for maintaining the employee’s address in the preconfigured sequence of the info group automatically. In this example, the address infotype (0006) appears when the user selects the action Maintain Master Data using transaction PA40 and then selects the Maintain Address action reason. If you have defined a subtype of that infotype, then the system takes the user directly to that subtype as well.

For example, the implementation team could configure the maintenance of only the permanent address during the maintain master data action. The specific subtype permanent address could be maintained in the Subtype field. Select action maintain master data in transaction PA40 and the action reason code Maintain Address (based on the info group configuration) and the system opens the address infotype (0006) and its specific subtype, permanent address.

Create Action Reason

To create an action reason, follow IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Create reasons for personnel actions (Figure 2). Action reasons correspond to the type of data maintenance. For example, reason 01 indicates personal data maintenance and reason 02 relates to address maintenance.

Figure 2

Maintain actions reasons for action types

Using the SAP feature IGMOD, define a specific variable key for each infotype based on MASSN (action) and MASSG (action reason) fields. For example, use action type code 04 (maintain master data) and action reason code 02 (change of address), to a decision in the feature IGMOD. ADDR is the info group modifier used to maintain addresses in master data. Now you could configure action Change of Address to display only the address infotype (0006) in the Maintain Master Data action. The next section describes how to define the info group modifer with feature IGMOD.

Define Info Group Modifier

Follow IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Define Infogroups > Infogroup Modifier. The Edit Feature IGMOD screen appears (Figure 3).

Figure 3

Maintain feature IGMOD

Thereafter, using info group 04, define the infotypes that should be included in the maintain master data action for each value of the IGMOD variable key values. In this example, for the feature return value &IGMOD and variable key value ADDR, you define the info group only with infotype 0006 (address). You can also define infotype subtypes for addresses, such as permanent address or office address.

Set Up Personnel Action

Several actions may be configured for maintaining the data, depending on your organization’s specific requirements. In this particular example, I use one action with various action reasons to denote the different kinds of data that are being maintained.

To create a personnel action that maintains master data in PA40, follow IMG menu path Personnel Management > Personnel Administration > Customizing Procedures > Actions > Set up personnel actions (Figure 4).

Figure 4

Set up personnel actions

In this step, you primarily define what statuses the action should trigger — for example, the action could trigger a withdrawn status for a termination, active status for hiring, or inactive status for a leave of absence. You also define the info group modifier maintained in the previous step and determine whether the action is stored in infotype 0302 (additional action). Here are some of the fields you need to define in this step:

Actio...: This is the type or name of the action that the user is performing, such as hiring or maintaining master data

F..: This is the function character for action field, which denotes whether the action is an initial hiring action (1) or any other action (0)

Cus....: The customer-specific status could be configured and triggered for different actions and used later to process time evaluation or payroll. For example, if an action is executed when the employee goes on a maternity leave, then a pre- configured customer-specific status could be triggered and payroll processing would be performed accordingly.

Emp...: The employment status field contains the standard value for this status, such as 0 (the employee is not with the company); 1 (the employee is with the company, but inactive); 2 (the employee is with company, but is retired); or 3 (the employee is active in company).

Spe...: Special payment status in your SAP system is standard for Austria and Spain only and is typically not used for other countries

Check: When an action is created, the system checks whether the attributes of the current action match the attributes of the previous action. The name of the feature you enter in this field controls the performance of this check. For example, when you execute the Termination action, the system performs a check to determine whether the employee is presently active because only an active employee can be terminated. Standard system features include MSN20 for withdrawal, MSN21 for re-entry, and MSN32 for early retirement/retirement.

D.: This field (date control) indicates when the new record should become valid when the user enters the start date. If the field is blank, the specified start date is defaulted to the standard start date used for new records. 1, commonly used for terminations, designates the end date of the old record is now the day before the start date of the new record. For example, say the termination action date is 31 July 2007. If you specify 1 in this field, 31 July 2007 is used as the end date of the previous record and 1 August 2007 is now the start date of the termination action.

U0000: Select this check box to ensure that the action will be stored in infotype 0000 (actions) infotype. If you don’t, no history remains for this action.

U0302: Select this check box to store the action in infotype 0302. For example, if there is more than one action being performed on the same day, the actions can be stored in infotype 0302 as long as the actions are non-status changing, meaning that the employee remains active the entire time. Say an employee goes through an organizational reassignment action and his employment status is set to 3 (active). On the same day, a salary change action is also performed. In this case, because the second action is a non-status changing action, in which the employee still remains active, the system maintains infotype 0302 because it cannot execute two actions on the same day in infotype 0000.

C.: The country reassignment action indicator allows the user to perform an entry action and a leaving action in one step. For example, select this check box if an employee is moving to another country or company code. The employee must be terminated from one country and company code and hired in another country and company code, with a new personnel number.

Data Maintenance Using PA40

From the business perspective, you should perform all the routine data maintenance transactions on employee master data using transaction PA40 rather than PA30. This forces the user to go through a sequence of predetermined screens which leaves a history in infotype 0000 of what type of maintenance was performed by the user on the employee master record. Furthermore, this process ensures that the appropriate infotype mode of operation (copy or display mode, rather than simply change) is used.

When Should I Use PA30?

Certain circumstances merit the use of PA30 instead of PA40. For example, if a user makes a mistake in data entry while performing an action, it is best to use transaction PA30 and go directly to the infotype in question to correct the data immediately.

In other situations where the change in master data is not critical enough to execute through an action, such as in infotypes internal control (0032) or company instructions (0035), there is no danger involved in using transaction PA30 and a log of history is not required.

You may be wondering which changes are considered critical enough to use an action and which changes are suitable for PA30. One standard that you could use to determine whether the infotype should be tracked through an action or not is to evaluate your HR department’s reporting requirements. For example, if your HR department requires reports for all changes made to the salary details of an employee in infotype 0008, you must set up an action to perform these changes or you cannot trace a log report. If there is no reporting requirement for non-critical data, then it is not necessary to make such changes through an action.

To reiterate, if every possible change made to the employee master data is logged through an action, you end up with an excessive list of historical records in the actions infotype. Of course, every organization is different. Discuss your company’s requirements with your implementation team to determine the best approach for common changes made in employee master data.

Daily Activity Report

I have seen many times that it is very important, and in some cases essential, for the HR department to review the type of changes done to the HR master data. For this purpose, you can create an SAP Query using information from infotype 0000. Table 1 shows a sample output of an activity report.

Caution

There are several different types of master data changes that are performed in employee master data that the HR department might not want to specify an action reason for each of those changes. For example, changes such as email addresses in infotype 0105 (communications) or date specifications in infotype 0041 do not require action reasons. If you do add action reasons for these small changes, the end result is a lengthy and confusing list of action types that you must filter through every time you make simple maintenance changes.

In these situations, all infotypes should be grouped together in the maintain master data action under a generic action reason called Other Changes. I recommend only adding action reasons for crucial HR master data edits, such as change of address, change of family members, and bank details because these changes require report logs for tracking purposes.