Example of Personnel Number Check P_PERNR

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:

• In our example, the user is an administrator responsible for the basic pay (infotype 0008) of a personnel area (since the administrator has the corresponding HR: Master Data authorization). The employee should also be able to display his or her own data at all times but not change his or her basic pay, irrespective of the personnel area for which the employee is responsible. You need to set up the appropriate authorizations for the HR: Personnel Number Check object as shown in this example.
• 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 access to all data records of infotype 0008 for the employee's own personnel number in case the administrator is responsible at some point in the future for the personnel area to which he or she belongs.

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

Example 1:

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.