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 (A = Employee, B = Applicant) |
PERNR |
Personnel Number (or Applicant Number) |
INFTY |
Infotype |
SUBTY |
Subtype |
BEGDA |
Start Date |
ENDDA |
End Date |
Note
Note that BEGDA and ENDDA always indicate the start or end date of a data record for which the authorization should be checked. The start and/or end date of a period for which the authorization should be checked is never transferred. This ensures that the users who call up the authorization check do not have to decide which authorization to give the administrator who has access authorization only for a part of the validity period of a data record. Instead, this is determined by the time logic of the authorization check.
The system performs all the following steps of the authorization check.
First the authorization check by personnel number (for LEVEL , TCLAS , PERNR , INFTY , SUBTY ) is processed (see also
Flowchart 2
). If this check returns the result
not authorized
, the authorization is immediately denied. If, however, the check returns the result
authorized
, all further steps in the authorization check, with the exception of test procedures, are skipped.
If you use the structural authorization check, the user’s period of responsibility is determined from the organizational structure (see also. Flowchart 3 ). If the defined period of responsibility is empty, the authorization is denied immediately.
The user’s period of responsibility is determined according to the PA authorization objects (P_ORGIN, P_ORGXX, customer-specific authorization object) using organizational assignments (
Organizational Assignment
infotype (0001)) (see also
Flowchart 4
). If the defined period of responsibility is empty, the authorization is denied immediately.
The intersection of both periods of responsibility is determined and the time logic is transferred as the period of responsibility (see following graphic, Graphic 1):
The time logic compares the defined period of responsibility with the validity period of BEGDA to ENDDA (see also
Flowchart 6
). If the time logic returns the result
not authorized
, the authorization is denied immediately.
The check establishes whether a test procedure exists that prevents the data record from being changed (see also Flowchart 7 ). If this is the case, the authorization is denied. Otherwise, the user is authorized to access the data record.
See also:
Flowchart of the General Authorization Check
The individual steps of an authorization check are described one by one and presented graphically in the following:
Process of the Authorization Check – Personnel Number Check
Process of Determining the Period of Responsibility
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN
Process of the Test Procedures
Process of Determining the Date After Which Changes Are Permitted for Test Procedures