Show TOC

 Definition of Structural Authorizations

Use

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, and Training 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.

Integration

To assign profiles, use the T77UA table ( User Authorizations = Assignment of Profile to Users ). For more information, see Assignment of Structural Authorizations .

Prerequisites

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 .

Features

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.

    Note Note

    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.

    End of the note.

    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.

    Example Example

    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.

    End of the example.

  • 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.