You can use this function to define structural authorizations. You can define structural authorizations using the T77PR table (Definition of Authorization Profiles).
There are two cases for using structural authorizations:
· Structural authorizations for the Organizational Management, Personnel Development, andTraining and Event Management components – described in this section.
· Structural authorizations that should be used for more specific authorization checks (on account of the organizational structure) during the processing of HR master data. See Interaction of General and Structural Authorizations for detailed information.
To assign profiles, use the T77UA table (User Authorizations = Assignment of Profile to Users). For more information, see Assignment of Structural Authorizations.
To be able to understand and set up structural authorizations, you must have knowledge of the Personnel Development data models (Organizational Management, Personnel Development, Training and Event Management, and so on). For more information, see Structural Profiles.
You can use the following fields in the T77PR table (Definition of Authorization Profiles) to define authorizations for HR objects (the fields are described according to their sequence in the maintenance screen; they are not prioritized in any way).
· Plan Version
You can use this field to determine the plan version for which the defined profile is valid. If you use a system that integrates the Personnel Administration (PA-PA) and Organizational Structure (PA-OS) components, note that plan version 01 is generally the integrated plan version.
· Object Type
You can use this field to determine the object types for which the defined profile is valid. Note that you can only specify object types that have a key with a NUMC (8) format. In general, structural authorization checks are not carried out for external objects with a different key (for example, cost centers). Technically speaking, this includes all authorization objects that are entered in the T77EO table (External Object Types) but that do not have an inverse relationship ( INREL = <Blank>). You can use the general authorization check of the relevant application for external objects without an inverse relationship.
· Object ID
You can use this field to define the start object using evaluation paths.
· Maintenance (Processing Mode)
You can use this field to control whether a read or write authorization should be assigned to a user for the corresponding set of objects. This field in the T77PR table (Definition of Authorization Profiles) corresponds to the MAINT field in the T77FC table (Function Codes HR-PD). All function codes that have an X in this field can be processed.
· Evaluation Path
By entering a specific evaluation path in this field, you can determine that the user is only authorized to access objects along this evaluation path.
You must also assign a root object for the structure when you use an evaluation path. This root object can either be entered directly in the corresponding field of the T77PR table (Definition of Authorization Profiles), or determined dynamically using a suitable function module.
The choice of evaluation path has a decisive influence on the overall performance of the system. Refer to the notes on avoiding performance problems in Performance Aspects.
· Status Vector
You can use this field to determine which relationships are considered when the structure is created. If you define the status vector as 12, for example, all relationships that have the status active or planned are evaluated. The choice of status vector has no real effect on the status of objects. The status vector simply refers to the status of the relationships. You can find the defined statuses for mySAP HR in the T778S table (Plan Status).
· Depth (Display Depth)
You can use this field to determine which level of a hierarchical structure a user is authorized to access.
If you enter
0 as the value for the display depth, the
corresponding tree is completely built, that is there is no limit to the depth
of the tree.
·
Sign By entering a
– sign in this field, you can determine that structural authorization
profiles should be created which process the structure “bottom
up”. If you make
no entry in this field (default value
<Blank>) or
enter a + sign, the structure is processed in the normal
“top down” manner.
·
Period In this
field, you can define the profile according to the validity period of the
structure. You can enter the following options: Key date, all, and different
periods such as current year, current month and so on. If you select
the entry
D (current day), the
structural authorization is limited to the structures valid on the current
day. If you define
a structural authorization for a manager using period D, the manager is authorized to access data on all
persons who are currently in the manager’s group. If you do not
make an entry (default value
<Blank>), the
structure is not limited by validity period. If you define the profile using
the
<Blank> period, the manager is authorized to access data on
former or future employees in addition to the authorization in the above
example. The
Period field has, therefore, no influence on the period for which a
user is authorized to access a specific object. In other words, the structural
authorization check, unlike the general authorization check, does not return
periods of responsibility. Instead, the system outputs whether or not the user
has authorization for a specific object.
The
Period field in the definition of the structural authorization check
does not affect the time logic of the general authorization check. For more
information, see Time Logic. The
Period field is used in structural authorizations to determine the set
of objects for which authorization exists or which is passed on to the general
authorization check for further processing. See Flowchart of
Determining the Period of Responsibility According to Structural Authorization
Check for a description of
how the period of responsibility is determined for the general authorization
check.
Due to
different values in the Period field, the user is authorized to access
different sets of objects for the data in the above diagram.
For the
following two examples, which refer to graphic 3, the system date is set to
February 6, 2002. Example
1: Period:
D (= Key date) If you enter
D, the user is only authorized to access P2 because
he or she only has authorization to access objects in the structure that is
valid on February 6, 2001 and the relationship between S1 and P1 ends before
February 6, 2001. Example
2: Period:
<BLANK> (= all) If you enter
<BLANK> (= All), the user is granted access to P1
and P2.
·
Function
Module You can use
this field to specify a function module that determines the root object
dynamically at runtime. Do not make an entry in the Object ID field.
However, you must specify the Plan Version and Object Type
fields. The advantage
of using function modules is that each time you define an authorization
profile, the function module generates a user-specific profile for each user
at runtime. If a manager
changes department, for example, the corresponding profile in the T77PR table
(Definition of Authorization Profiles) does not need to be changed.
What is more, setting up function modules can reduce the number of entries in
the T77PR table significantly. Two function
modules are delivered in the standard system:
¡
RH_GET_MANAGER_ASSIGNMENT (Determine Organizational Units for
Manager) When you use
this function module, the organizational unit that is assigned to the user as
manager by position and by relationship A012 (is manager of) is
determined as the root object. This
function module is key date-related, that is only the organizational units
that are assigned to the user as manager on the current system date are
determined as root objects for that user.
¡
RH_GET_ORG_ASSIGNMENT (Organizational Assignment) When you use
this function module, the organizational unit that is organizationally
assigned to the user is determined as the root object.