Start of Content Area

Process documentation Process of the Authorization Check by Personnel Number Locate the document in its SAP Library structure

Call Parameters

A user attempts to call an employee’s infotype record. As a result, the authorization check is called using the following parameters:

LEVEL

Authorization Level

TCLAS

Transaction Class = Difference Personnel Number/Applicant Number

PERNR

Personnel Number (or Applicant Number)

INFTY

Infotype

SUBTY

Subtype

The BEGDA and ENDDA parameters are not needed as the user’s current assignment to a personnel number is always evaluated. As soon as the system recognizes that a personnel number belongs to a user, the data is differentiated using only the infotype/subtype parameter. A differentiation based on time does not take place.

Process Flow

The system performs all the following steps of the authorization check.

  1. The transaction class is evaluated. If the check is on an applicant number, the check is ended with the result undecided.
  2. The PERNR authorization main switch is evaluated. If the switch is deactivated, the check is ended with the result undecided.
  3. The personnel number belonging to the user is determined (in the standard system from the 0105 infotype, subtype 0001, in earlier releases from the T513A table User Values).
  4. If the personnel number does not concur with the personnel number to be checked or if no personnel number is found, the check is ended with the result undecided. (This is why authorization settings for the P_PERNR authorization object can never affect the authorization check by personnel number on personnel numbers that are not assigned to the user.)
  5. An authorization check is performed for the P_PERNR authorization object:

    6. AUTHORITY-CHECK OBJECT 'P_PERNR'

    ID 'AUTHC' FIELD LEVEL

    ID 'PSIGN' FIELD '*'

    ID 'INFTY' FIELD INFTY

    ID 'SUBTY' FIELD SUBTY.

  6. If this check is successful (SY-SUBRC = 0), the outcome is authorized.
  7. A second authorization check is performed for the P_PERNR authorization object:

    8. AUTHORITY-CHECK OBJECT 'P_PERNR'

    ID 'AUTHC' FIELD LEVEL

    ID 'PSIGN' FIELD 'E'

    ID 'INFTY' FIELD INFTY

    ID 'SUBTY' FIELD SUBTY.

  8. If this check is successful (SY-SUBRC = 0), the outcome is not authorized.
  9. A third authorization check is performed for the P_PERNR authorization object:

    10. AUTHORITY-CHECK OBJECT 'P_PERNR'

    ID 'AUTHC' FIELD LEVEL

    ID 'PSIGN' FIELD 'I'

    ID 'INFTY' FIELD INFTY

    ID 'SUBTY' FIELD SUBTY.

  10. If this check is successful (SY-SUBRC = 0), the outcome is authorized.
  11. If none of the checks performed were successful, the outcome is undecided.

Note

The check using P_PERNR with PSIGN = * was not carried out in earlier releases. A user with * authorization for P_PERNR in the PSIGN field is was always denied access for this reason. This meant, amongst other things, that users with full authorizations were unable to access their own personnel number during active authorization checks by personnel number.

Why not, therefore, simply switch the check to PSIGN E or I? A user with E and I authorization should be able to access and unable to access his or her own personnel number. Since the system cannot interpret this in a meaningful way, it should deny the authorization according to the strategy "when in doubt, no authorization". This immediately rules out switching the E and I checks. The additional PSIGN = * checks were introduced to ensure that users with SAP_ALL authorization always have the authorization to access their own personnel numbers.

See also:

Flowchart of the Authorization Check by Personnel Number

 

 

 End of Content Area