We have already come across PA (Personnel Admin) master data in our initial discussion of different types of the HR data. Out of the box, SAP provides three main authorization objects for securing PA master data, P_ORGIN, P_ORGXX and P_PERNR. Lets see how we can use each one of these in our security design landscape.

PA master data stored in different infotypes is essentially the attributes for the employees of the organisation. To store these attributes each employee is associated with an unique personnel number or PERNR. SAP HCM currently allows a person to have multiple pernrs as part of its extended configuration but that is beyond the scope of our discussion on basic HR security. The basic transaction for maintenance of PA master data is PA30. The first screenprint shows the initial screen of PA30 with the pernr and name of an employee.

In HR, the pernr similar in use to the system id used in the security system. In fact we use the infotype 0105 (communication), subtype 0001 to store the SAP system id corresponding to the pernr for an user. Later we will find that this link is mandatory for the use of the P_PERNR authorization object.

The first step in using any of the PA master data authorization objects is switching on the corrsonding authorization switches for them in the transaction OOAC. For ex, to switch on security checks for P_ORGIN and P_PERNR we need to set the authorization switches AUTSW-ORGIN and AUTSW-PERNR values to 1 respectively. Once switched on, any access to PA master data will check the user master for these authorization objects.

The most important infotype with regard to any discussion on PA master data security is the Organisation Assignment (0001) infotype. The screenprint below shows the IT 0001 screen with the different data contained in it. This infotype is important as the data fields of this infotype are also part of the general authorization objects and are checked during data access. For ex, Personnel Area, EE group, EE subgroup, Cost Center, Payroll Area and the three Administrator fields are all used in the authorization objects.

The three common authorization objects with their authorization fields are given below

P_ORGIN (HR: Master Data)

P_ORGXX (HR: Master Data – Extended Check)

P_PERNR (HR: Master Data – Personnel Number Check)

As you might have noticed, many of these fields were part of the org assignment infotype. Thus if a security concept is built around personnel area, employee group, employee subgroup we can switch on the check for P_ORGIN and use the auth object in our roles or if the security concept is based around the time, master data and payroll administrators we can use the P_ORGXX authorization object. In some rare scenarios we might even want to use both the authorization objects in our roles. A case where both of them might be used is a scenario where we have different master data administrators for a single personnel area. Here instead of creating of roles with all the different combinations for P_ORGIN (Personnel Area) and P_ORGXX (Administrators), we can reduce the number the of roles by separting out these two accesses into different roles. Finally a combination of the P_ORGIN and P_ORGXX roles will be assigned to a user to make up the total accesss of a HR rep. You would also notice that the standard authorization objects do not have any option to secure PA data at the level of the personnel sub area or cost center. A solution in such cases is provided by the Organization Key field. This is a 14 character field which can be configured to be derived from any of the IT 0001 fields or can be even manually entered by the administrator.

The P_PERNR authorization object is a bit different in functionality from the other two objects. The P_PERNR object provides one of the very few examples of negative authorization concept in SAP. The object is used to provide different authorization to an administrator when accessing his own PERNR. The most common example is of a compensation analyst having access to update the basic pay infotype. Though as part of his usual responsibility, hw would be expected to maintain the basic pay of other employees, we would not want him to give himself a raise. Its at this juncture that P_PERNR and its negative authorization comes to the rescue. The master data authorization of this person might typically be maintained as the following

P_ORGIN

INFTY 0008

PERSA *

AUTHC W, R, M

P_PERNR

INFTY 0008

PSIGN E

AUTHC W, D, S, E

In the above case, the P_ORGIN authorization gives the comp analyst access to maintain (AUTHC – W – Write) the basic pay (IT 0008) for others but when accessing his own pernr, the value of P_ORGIN is over-ridden by the access in P_PERNR. The value of PSIGN as E (Exclusive) denotes that while accessing IT 0008 for his own pernr, his access will exclude the values maintained for AUTHC (W, D, S, E). The only possible values for AUTHC which excludes the 4 given values are R (Read) and M (matchcode) and as a result the administrator only has display access to his own pay data.

Its very important to remember a few points when trying to use P_PERNR. Firstly P_PERNR can only be used to provide access to a person’s own pernr or personnel record. A corollary of this, is the requirement that for P_PERNR to work a valid system id should be maintained for IT 0105, subtype 0001. This is necessary as the SAP system needs to identify a personnel record with a user master record. Secondly, the only two possible values of the PSIGN field are E (Exclusive) and I (Inclusive). A value of * doesn’t make much in this case as by definition, a * value can be interpreted as either of the two possible values.