A Cross-Application Time Sheet (CATS) implementation is often part of a larger project that involves multiple SAP modules such as Project System (PS) or Plant Maintenance (PM). The dependence of CATS on employee numbers requires a certain amount of HR functionality to drive it successfully. This HR functionality requires authorizations to be set up to restrict access.

The complexities of HR security often prove to be a challenge. For companies that already have other HR components implemented, CATS security requirements can be lost in (or conflict with) settings for other authorizations that use the same objects. For companies implementing HR only to support CATS, insufficient consideration of HR authorization configuration results in embarrassing security lapses.

Without adequate thought and analysis, HR authorizations can jeopardize the implementation of an SAP project. Typical issues in a post-go-live list of problems include:

• Employees who can see others’ Social Security numbers
  
  
• Employees who can view others’ salary information or dates of birth
  
  
• Employees who cannot see their own information

HR authorization is a complex area with potentially complex business requirements that need to be analyzed, modeled, specified, developed, and tested. By describing the typical SAP authorization requirements for a CATS implementation, I hope to make it easier for you to set up HR security specifically for CATS and to help you minimize conflicts with authorizations for other HR components.

Authorizations in R/3 are based on two fundamental components: roles and authorization objects. I assume that you are already familiar with SAP authorization concepts. After discussing the fundamental requirements, I will outline role-building strategies using standard SAP authorization objects to meet them. All examples are based on Release 4.6C.

A Typical CATS Security Challenge

What are some of the complex authorization requirements for a CATS implementation? Common ones include:

• An employee may see his/her own time-based salary details but not anybody else’s
  
  
• A timekeeper may enter time for a specific group of people
  
  
• A supervisor may approve time for employees who report to him/her
  
  
• A supervisor may not approve his/her own time

You can address these requirements with the following role models:

• A general user role that provides a user access to his/her own HR data and nobody else’s. This enables users to view their own master data, salary, or time information.
  
  
• A central timekeeper role that allows a person access to timesheets of personnel for whom this person enters time
  
  
• A supervisor role that allows the approval of time entered by his/her subordinates

The General User Role

The general user role provides a user access to his/her own HR data only. This type of role should be planned for every individual of the organization because it typically applies to everyone. Since roles are cumulative, any other roles required by an individual to perform his/her duties (such as access to other people’s time sheets), can be separately created and granted depending upon the function performed. This makes the design modular and ensures that it works as intended in combination with any other role.

Access relative to oneself is usually described using the P_PERNR authorization object. Consider this example of the general user role using this object: User ABC is allowed to read only his/her own attendance and absence records. His/her P_PERNR setting will look somewhat like what you see in Table 1.

This enables user ABC to read (AUTHC = R) infotypes 2001 and 2002: his/her own attendance and absence records. Delving deeper into the role restrictions for an individual, you would expect individual time users to be able to:

• Display and enter their own time
  
  
• Display their own employee master information

Also, you would expect these individuals to not be able to:

• Update their own pay-related records
  
  
• Approve their own time

These requirements can be regrouped into two categories:

• Master data (individuals display but do not update their own master data)
  
  
• Time data (individuals enter but do not approve their own time)

What follows is how you could model the time data requirements to allow entry and disallow approval. (Master data requirements modeling would go through a similar thought process. I have not discussed it here to avoid repetition.)

Time entry is controlled by the P_PERNR authorization. The setting shown in Table 2 enables the entry, display, and approval of a user’s own time.

The P_PERNR setting also allows time approval if the user has access to the approval transaction (CAPS) through another role. Since you do not want the general user role to have the ability to approve his/her own time, you need to find a way to remove this access. Not giving access to CAPS may be the easiest solution, but that cannot be guaranteed since the general user could also be a supervisor or a central timekeeper who may not be approving his/her own time, but would need to approve other people’s times.

You can use a P_PERNR setting with PSIGN = E to disallow approval. A simple variation of the P_PERNR setting shown in Table 2, with PSIGN changed from I to E, achieves this (Table 3). Combined with the P_PERNR authorization, it ensures that the supervisor is not able to approve his/her own time.

It has an unintended consequence, though. The supervisor is now unable to enter his/her own time. This is caused by conflicting PSIGN settings. Authorizations are cumulative. Two roles assigned to the same user both influence the user’s security. With both the authorizations I and E turned on for the same user through the two roles, authorization E always takes precedence over I.

Such a conflict occurs only with a full key match. This means a conflict situation is created only if AUTHC, INFTY, and SUBTY have identical values, while PSIGN has different ones. You can resolve this conflict simply by changing one of the subobject settings (AUTHC, INFTY or SUBTY). This is useful information in general for designing complex roles that have a tendency to overlap with each other and create a conflict.

In my example, observe the AUTHC value of “M,R,D,E” in the P_PERNR setting for time entry in Table 2. Since approval follows SAP’s double verification principle, D is required only for approval and not for time entry. This gives you an opportunity to re-model the entry and approval settings for P_PERNR (Table 4).

Now the two P_PERNR settings can coexist without conflicting with each other. This ensures that a supervisor who has been given the general user role can enter his/her own time as well as enter or approve other people’s times, but not approve his/her own time.

The Central Timekeeper Role

The central timekeeper role is a requirement for those individuals in the organization who specialize in entering time for others. A timekeeper is meant to enter time for several people in a company within one or many departments. Entering time data requires access to some key master data as well. The authorization object that provides or restricts access to master data is P_ORGIN. Table 5 is an example setting of P_ORGIN that will work.

• Infotypes 0000 and 0001 are required because they represent the organizational key of the employee record, which is used to search for that employee
  
  
• Infotype 0007 (work schedule rule) is required so that CATS can perform a standard validation of time entered against time planned for that day
  
  
• Infotype 0315 stores some default fields for timesheet purposes — activity type and cost center, for example. Although not mandatory, if these are available, a timesheet is prepopulated with the default values for the individual stored in this infotype.
  
  
• Infotype 0328 is really not required for time entry. It is needed because it provides the timekeeper access to timesheet reports.
  
  
• Infotypes 2001 and 2002 (absence and attendance records) simply check the authority of the role to enter attendance/absence data
  
  
• Infotype 2006 (absence quotas) is required so that any absences entered can be checked against a vacation or sickness quota for the individual
  
  
• Infotype 0316 provides a facility that restricts the fields a user can view or enter

A data entry profile must be used for entering time in the system and is therefore key to restricting the entries made in a timesheet. A data entry profile configuration (transaction CAC2) specifies which field should be enterable, which is display only, and which is hidden from view.

The definition of a data entry profile includes an authorization code you can set up in configuration via menu path Cross-Application Time Sheets>Authorization – Create Authorization Groups for Data Entry Profiles.

The subtype of infotype 0316 directly links with this authorization code, restricting the role to the use of only those data entry profiles that have this code. For example, using infotype 0316, a factory timekeeper may be given access to a data entry profile for entering work order times, while a payroll administrator is given access to wage types and other fields that have a direct monetary consequence (Figure 1).

Figure 1

Different subtype values for infotype 0316 representing access to different data entry profiles

The Supervisor Role

The supervisor role allows the approval of time entered by the supervisor’s subordinates. Group approval authorizations are set through the P_ORGIN object. A typical example for an approving supervisor is shown in Table 6.

You probably immediately noticed the striking similarity between this role and the central timekeeper role. The only difference is in the settings of the AUTHC subobject. The D, which was not available in the timekeeper role, ensures that the supervisor can approve time.

The setting shown in the example is generic. It does not restrict the supervisor to only the area that he or she supervises. With this setting, the supervisor is able to approve everybody’s time. This is not ideal in most situations.

You can impose restrictions by using the other subobjects. PERSA can limit the authorization to a few personnel areas. PERSG and PERSK can limit the employee groups and subgroups that the supervisor can approve.

However, even this may not be sufficient in some cases. You may want to restrict a supervisor just to his or her department. This is possible through structural authorization. This functionality in SAP allows the control of authorization down to the lowest organizational level, or to a position or job. You can read about structural authorization in SAP’s IMG documentation under Organizational Management in the section Authorization Management.

The three roles discussed in this article provide a basis for most roles that are commonly required for a successful CATS implementation. They are by no means the only roles required in an organization.

HR authorization can be compared to the lid on a jar of candy. With only a tiny micron of gap between the lid and the body of the container, an army of ants can invade and take over the goodies. As you saw in this article, authorizations can be set up in many different ways and often leave a gap elsewhere that is not easily discernible. Closing this gap requires a high level of skill and experience.

Deepankar Maitra

Deepankar Maitra has more than 25 years of consulting experience specializing in SAP-based solutions for human resources, supply chain, and reporting in multi-national companies around the world. He has successfully directed large implementation projects as solution architect, delivery manager, global lead, and country lead. His expertise lies in pragmatic harmonization of data and synthesis of processes using tools that improve process execution through quantum leaps in productivity.

You may contact the author at deepankar.maitra@accenture.com.

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