P_PERNR (HR: Master Data – Personnel Number Check)

Definition

Authorization object that is used to assign users different authorizations for accessing their own personnel number. These authorizations differ from those defined in users’ P_ORGIN profiles. If this check is active and the user has been assigned a personnel number in the system, it can directly override all other checks with the exception of the test procedures. This check does not take place if the user has not been assigned a personnel number, or if the user accesses a personnel number other than his or her own.

Note Note

You can assign a user a personnel number using infotype 0105, subtype 0001 (in earlier releases using the V_T513A view).

End of the note.

Structure

The P_PERNR authorization object contains the following fields, which are tested during an authorization check:

Authorization Field	Long Text
AUTHC	Authorization Level
PSIGN	Interpretation of Assigned Authorization
INFTY	Infotype
SUBTY	Subtype

More Information About the Fields

The PSIGN field ( Interpretation of Assigned Authorization ) can have the following values:

I: : include (for additional authorizations)

E: : exclude (for authorizations that are to be removed)

Example

The authorization checks for P_ORGIN and P_PERNR are activated in the system. In addition, there are user assignments for some personnel numbers.

The user in our example is assigned a personnel number and is administrator responsible for the Basic Pay infotype (0008) of a personnel area (that is, the user has the corresponding P_ORGIN authorization). The employee should also be able to display his or her own data but not change his or her basic pay, irrespective of the personnel area for which the employee is responsible. The corresponding authorizations for the P_PERNR authorization object must be set up as follows:

AUTHC = R , M

PSIGN = I

INFTY = *

SUBTY = *

AUTHC = W , S , D , E

PSIGN = E

INFTY = 0008

SUBTY = *

The first authorization grants the employee read authorization for all infotypes that are stored under the employee’s personnel number. The second authorization denies write authorization for all data records of the Basic Pay infotype (0008) stored under the employee’s personnel number.

The authorization checks for all other personnel numbers and for write authorizations for all infotypes (except Basic Pay (0008)) run according to P_ORGIN.

Caution Caution

As the following examples illustrate, inconsistent authorizations can be granted.

Example 1:

AUTHC = *

PSIGN = I

INFTY = 0014

SUBTY = M*

AUTHC = W , S , D , E

PSIGN = E

INFTY = 0014

SUBTY = *

The first authorization grants the employee read authorization ( AUTHC = R ) for the Recurrent Payments/Deductions infotype (0014), subtype M120 , which allows the employee to access the data stored under his or her personnel number. In this case, the second authorization is irrelevant.

The first authorization grants the employee write authorization ( AUTHC = W ) for the Recurrent Payments/Deductions infotype (0014), subtype B030 , which denies the employee access to the data stored under his or her personnel number. In this case, the first authorization is irrelevant.

The first authorization grants the employee write authorization for the Recurrent Payments/Deductions infotype (0014), subtype M120 , the second authorization denies the employee this authorization. The desired system response is unclear from this example. According to the documentation, the system response is undefined in such situations. In reality, the authorization check always denies authorization in unclear situations, that is E is stronger than I and therefore the authorization is not granted.

Example 2:

AUTHC = *

PSIGN = *

INFTY = *

SUBTY = *

This type of authorization is required by superusers with unlimited access, for example. The above authorization is appropriate if an employee wants to access an infotype. However, since PSIGN = * and * can be substituted for any value, PSIGN and E can also be interpreted as I . This can also lead to an undefined situation. In earlier releases, the authorization was denied on the basis of the rule E is stronger than I . This meant that superusers with assigned personnel numbers were not able to access their own personnel number. The programs have since been changed and now * is interpreted as I and is stronger than E . In other words, * is stronger than E and E is stronger than I , whereby * is interpreted as I .

As already indicated in Example 1, the combination of different authorizations can produce a complicated result. We therefore recommend that you avoid combinations where P_PERNR authorizations can be interpreted differently for the same combination of AUTHC ( Authorization Level), INFTY ( Infotype) and SUBTY ( Subtype ).

Misunderstandings arising from the complex situations described above are not the most frequent causes of customer inquiries, however. The most frequent cause is the incorrect assumption that authorizations by personnel number affect authorizations for non-assigned personnel numbers. This is not the case at all.

If you use authorizations by personnel number, you should always first set up all non-personnel number-related authorizations. As soon as you have done this, you should create different access authorizations for the personnel numbers that are assigned to users using appropriate P_PERNR authorizations. This is always possible since the P_PERNR authorizations override all other authorizations directly (except Test Procedures ).

P_PERNR authorization checks cannot bypass test procedures directly. For instance, a test procedure is only carried out on the Recurring Payments/Deductions infotype (0014) if a corresponding P_PERNR authorization (with PSIGN = I ) exists. If an appropriate authorization for the corresponding subtype of the infotype 0130 exists, it can be used effectively to carry out the test procedures.

End of the caution.