Start of Content Area

Process documentation Process of the General Authorization Check 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 (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.

Process Flow

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

  1. 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.
  2. 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.
  3. 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.
  4. 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):

    5. This graphic is explained in the accompanying text

  5. 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.
  6. 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 Time Logic

Process of the Test Procedures

Process of Determining the Date After Which Changes Are Permitted for Test Procedures

 

 

End of Content Area