How to use authorization object P_PERNR ?

Question

Hi, Gurus~
In our system, there is a user whose User ID is "00041", and she can modify her own 0008, we want to control it so that she can only display her own 0008, but process 0008 for all other employees
So, i use the authorization object P_PERNR to do this, i set the fields value like this (totally copy from the SAP help for P_PERNR....):
Authorization level:  W,S,D,E
Infotype: 0008
Interpretation of assignment personnel number: E
Subtype: *
and then, i maintain her master data 0105's subtype 0001-system user name as 00041
i think she shouldn't maintain her own 0008 now ,but she still can maintain it
i want to know why and how to solve it, did i do it in the right way?
Thank you in advance!

Answer 1

P_PERNR   HR: Master Data - Personnel Number Check
You use the HR: Master Data - Personnel Number Check authorization object if you want to assign users different authorizations for accessing their own personnel number. If this check is active and the user is assigned a personnel number in the system, it can directly override all other checks with the exception of the test procedures.
The following values are possible for the PSIGN field:
I   =          Authorization for personnel number assigned, that is for own personnel number
E  =          Authorization for all personnel numbers excluding own personnel number
You can assign a user a personnel number using infotype 0105, subtype 0001 (in earlier releases using the V_T513A view).
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. In other words, this check is completely irrelevant for personnel numbers that are not assigned to the user.
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: AUTHC = R, M
PSIGN = I
INFTY = *
SUBTY = * AUTHC = W, S, D, E
PSIGN = E
INFTY = 0008
SUBTY = *
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:
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.