Select language:

Structural Authorization Check

Use
Structural authorizations perform exactly the same function, from a business point of view,
as general authorizations in mySAP HR and in other SAP components. They control access
specifically to data that is stored in time-dependent structures (organizational structures,
business event hierarchies, qualifications catalog, etc.).

Integration
You can integrate the structural authorization check with the general authorization check.
Note that if you do so, the authorizations entered for each authorization type may influence
one another. For more information, see
Interaction of General and Structural Authorizations.

Prerequisites
The data that you want to protect must be stored in a hierarchical structure of one of the
Human Resources components (Organizational Management, Personnel Development,
Training and Event Management, etc.)

Features
You can grant authorizations for objects that are stored in a hierarchical structure using the
structural authorization check. If you specify a root object, you can determine that all objects
in the hierarchy under this specified object may also be changed, for example.
This concept guarantees that the maintenance of structural authorizations is kept to a
minimum, even if a change is made within the structure, and at the same time that users
still only have access to objects that they are responsible for.
This flexibility is achieved in two steps. First by using the (initial) structure built
in Organizational Management to define the authorization profiles. And second by using a
concept to store authorization profiles that reacts automatically/dynamically to changes in
the organizational structure, or in other words a concept that automatically adjusts to the
different profiles.
For more information about the structural authorization concept, see
Structural Profiles.

Activities
For information on how to set up structural authorizations, see
Definition of Structural Authorizations.

Example
The following example illustrates the advantages of structural authorizations for access to
data in time-dependent structures:

An organizational structure divides into three subtrees (organizational units O2, O3, and O4)
on the second level, for example. The authorizations of the persons responsible for each
organizational unit are also divided up accordingly for each subtree. A user needs three
profiles for this organizational structure that allow him or her to read/change data in O1, O2
or O3 AND in all lower level organizational units.
If you were to use the general authorization concept (values in fields) here, you would have
to enter all objects under the initial object in every authorization profile.
For the O2 profile and lower level objects, for example, you would have to enter the
following objects in the profile:

O2

O5

O6
In other words, you would have to enter ALL objects under O2 in the profile.
You would have to follow the same procedure for all other profiles, which would involve
considerable maintenance work to the initial profile and to the organizational structure if
changes were made to it.
If the organizational structure was expanded to include the organizational units O11 and
O12, for example, you would have to add the O2 and lower level objects profile to include
011 and 012 manually.
Structural profiles, on the other hand, allow you to copy profiles, such as the O2 and lower
level objects profile, by entering a start object (in this case, O1) and an
evaluation path. This requires minimal time and effort.
For more examples about structural authorizations, see
Example: Structural Authorization Profiles.

Select language:

Structural Profiles
Structure
Structural profiles use the data model of the Personnel Management
components Organizational Management, Personnel Development and Training and Event
Management to build hierarchies using objects and relationships. Different types of objects
(Object Types) and different types of relationships are used in this process. The
organizational structure of a company is illustrated in the following way:

The central elements of this data model are used to manage the authorizations for the
model effectively:

Objects (such as O (Organizational Unit), S (Position), P (Person))

Relationships (such as A003 (belongs to))

Evaluation Paths (such as O-S-P)

Evaluation paths "collect" objects from a start object in an existing structure according to
their definition: The definition of an evaluation path determines the start object and which
object types using which relationships are selected.
The evaluation path O-S-P (Staffing Assignments along Organizational
Structure) is an example of an evaluation path (and also a standard evaluation
path that plays a central role in Authorizations) that is defined as follows:
Object Type

Relationship

Relationship Name

Related Object Type

B002

is line supervisor of

B003

incorporates

A008

holder

This evaluation path starts selection from an organizational unit (O) that is
used as the start object (the organizational unit O1 from graphic 1 is used in
the following example). The evaluation path first selects all organizational
units from row 1 of the definition (O B002 O).
The following organizational units are selected for the structure in the above
example:
O1, O4, O5
Second, the evaluation paths starts selection from the selected organizational
units according to row 2 of the definition (O B003 S) and selects the following
positions:
S1, S2, S3
Last, the evaluation path starts selection from the selected positions
according to row 3 of the definition (S A008 P) and selects all persons:
P1, P2, P3
In total, the following objects are selected using the O-S-P evaluation path and
the start object O1:
O1, O4, O5, S1, S2, S3, P1, P2, P3
A combination of start object and evaluation path returns a specific number of objects from
an existing structure. This exact combination or the objects returned by this combination,
represents a users structural profile. Note that neither the number of objects nor the
specific objects that are returned by a structural profile are constant, nor is this desirable.
The concrete objects that are returned by a structural profile change as the organizational
structure (under the start object) changes.
See also:
Example
in Structural Authorization Check
There are several fields besides the central fields Start Object and Evaluation Path that can
be used to define structural profiles. These fields simply allow you to add more detail about
frequently occurring standard cases, but use the basic principle of "start object plus
evaluation path". See

Definition of Structural Authorizations for more information on these fields and how to create structural
profiles.
Not all aspects of the structural authorization check can be discussed in one
section. See the following for more detailed information on the different
aspects:

PLOG (Personnel Planning) Importance of the PLOG authorization object for the structural authorization
check
AUTSW ORGPD (HR: Structural Authorization Check): Importance of the ORGPD authorization main
switch
Flowchart: Example of Period of Responsibility According to Structural Authorization Check
Interaction of General and Structural Authorizations
Example: Structural Authorization Profiles
HRBAS00_STRUAUTH (BAdI: Structural Authorization)
Performance Aspects
Redundant Read of Objects
Evaluation Paths with Non-Specified Target Object Type
Context Problems in HR Authorizations

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

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 managers 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 Typefields.
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.

Assignment of Structural
Authorizations
Use
You can use this function to assign structural profiles to users using table T77UA.

Integration
In contrast to general authorization profiles, which are assigned using the Profile Generator
(PFCG transaction), you use table T77UA (User Authorizations = Assignment of Profile to
User) to assign structural profiles.

You can edit this table in the Implementation Guide (IMG) for Organizational
Management underBasic Settings Authorization Management Structural
Authorization Assign Structural Authorization.
Alternatively, you can use the HRBAS00_GET_PROFL Business Add-In (BAdI). This BAdI
enables you to implement an alternative determination of structural profiles.

Activities
You can assign users to structural profiles using table T77UA or transaction OOSB.

The system first searches for entries for the current user in the T77UA table (User
Assignments). If one or more entries exist, the set of objects is mapped according to the
profile definition. The set of objects is then checked against the concrete object and the
action (Display or Edit). The authorization is granted only if the object to be checked exists
with the necessary processing indicator in the set of objects.
If there is no entry in the T77UA table (User Authorizations) for the current
user, the above check takes place within the T77UA table for the entry SAP*. If
still no entry exists, the authorization is denied. In the standard system, there
is an entry for user SAP* with the profile ALL. This means that when you first
implement mySAP HR, all users have complete authorization as far as
structural authorization is concerned
See also:
HRBAS00_GET_PROFL (BAdI: Determine Assigned Structural Profiles)

Technical Aspects
The following paragraphs explain how you set up general and structural authorizations and
provide you with an outline of the technical aspects of authorizations, in other words, of all
the technical objects, checks, and additional setting options that play a part in setting up
these authorization types.
See also:
Authorization Objects
HR: Main Authorization Switch
AUTHC (Authorization Level)
VDSK1 (Organizational Key)
Time Logic
Periods of Responsibility
Control Mechanisms (Double Verification Principles, Test Procedures, etc.)

P_ORGINCON (HR: Master Data with

Context)
Definition
Authorization object that is used during the authorization check for HR data. This check
takes place when HR infotypes are edited or read.

Use
You can map user-specific contexts in HR Master Data using P_ORGINCON.
In the standard system, the check of this object is not active. You can use the AUTSW
INCON authorization main switch to control the use of P_ORGXXCON.

Structure
The P_ORGINCON authorization object consists of the same fields as P_ORGIN and also
contains the PROFLfield:
Authorization Field

Long Text

INFTY

Infotype

SUBTY

Subtype

AUTHC

Authorization Level

PERSA

Personnel Area

PERSG

Employee Group

PERSK

Employee Subgroup

VDSK 1

Organizational Key

PROFL

Authorization Profile

More Information About the Fields

The AUTHC field contains the access mode for the authorization (for example, R = Read).
See AUTHC (Authorization Level) for a detailed description of the different authorization
levels possible (M, R, S, E, D, W,*).
The VDSK1 (Organizational Key) field enables you to run diverse authorization checks by
organizational assignment (using the P_ORGINCON authorization object). The content of
the organizational key is either derived by the system from the fields of
the Organizational Assignment infotype (0001) or entered manually by the user.
The PERSA, PERSG, PERSK, and VDSK1 fields are filled from the Organizational
Assignment infotype (0001). Since this infotype has time-dependent specifications, an
authorization may only exist for certain time intervals depending on the users
authorization.
The time dependency of infotypes is stored in table T582A (Infotypes
Customer-Specific Settings) in the VALDT field.
All the time intervals for which a user has P_ORGINCON authorizations
constitute a users period of responsibility.
The PROFL field is used to determine which structural profiles the user is authorized to
access. Note that you can only enter structural profiles that are assigned to the user in
table T77UA (User Authorizations = Assignment of Profile to User) in this field.
If you use the HRBAS00_GET_PROFL (BAdI: Define Assigned Structural
Profiles) Business Add-In (BAdI), you do not have to maintain the entries in
table T77UA. This BAdI enables you to implement an alternative determination
of structural profiles.
See also:

Context Solution

Select language:

P_NNNNN (HR: Master Data: CustomerSpecific Authorization Object)

Definition
Authorization object that does not yet exist in the system and that is created by you.

Use
If you have requirements that cannot be met using the
P_ORGIN and P_ORGXX authorization objects (for example, because you want to build your
authorization checks on additional fields of the Organizational Assignment infotype (0001) that are
customer-specific), you can include an authorization object in the authorization checks yourself.

Structure
A customer-specific authorization object must contain the following fields:
Authorization Field

Long Text

INFTY

Infotype

SUBTY

Subtype

AUTHC

Authorization Level

You can use any of the fields in the Organizational Assignment infotype (0001) or in the
PA0001 structure. You can also use customer-specific additional fields as long as they are
CHAR or NUMC type fields.
In addition, you can use the following fields:
TCD: This field is always filled with the current transaction code (SY-TCODE). Note that when you use
this authorization object in reports, the TCD field is filled with the name of the transaction that calls up the
report and not with the report name.
INFSU: This field is 8 characters long. The first 4 characters contain the infotype, the last 4 characters
the subtype.
The system determines the period of responsibility for this object analogously
to the P_ORGIN and P_ORGXX objects.
For more information, see
Example of Period Determination Using P_ORGIN.

See also:
Creating a Customer-Specific Authorization Object
Overview
Structural authorizations are used to grant access to view information for personnel where HR has been
implemented. Access is granted to a user implicitly by the users position on the organizational plan.
Structural authorizations are not integrated into the standard authorization concept and structural
authorization profiles are not the same as standard authorization profiles.
Example
The use of structural authorizations can be illustrated by the following example. A manager can typically
view or maintain information on employees in her organizational unit but not employees in other
organizational units. When an employee moves from one unit to another his previous manager will no
longer be able to view or maintain information about them. Similarly if a manager moves from one unit to
another she will be able to see the employees in her new unit.
About this Document
This document shows how to set up a very simple example of structural authorizations that are assigned
to Organizational Units. All the steps of setting up a test environment are documented below so you can
try it too. There are some gotchas and design considerations listed up front and some additional
information listed in the many appendices at the end.
Graphical Overview of Structural Authorization Components and Setup
The graphic below shows the main components of structural authorizations at a high level. The setup of
structural authorizations is more complex than regular security authorizations. None of the main setup
steps can be omitted or incomplete. Structural authorizations setup is analogous to an electric circuit. If
there is a break anywhere in the circuit structural authorizations it will not work.

Considerations for Structural Authorization Implementation

Gotchas
Setting up structural authorizations has some dependencies so follow the order of the steps in this
document
for best results.
Structural authorization profiles are not related to standard security profiles in any way.
Unassigned Users: User IDs that have been linked to a Personnel Master Record via Infotype 105
MUST be
assigned a structural authorization profile regardless of whether they are assigned to a node on the
organizational plan or not. (See Appendix 3)
There is no way to trace structural authorization checks, and structural authorization checks that fail do
not
show in SU53. The closest thing to a trace is the information available in OOSP by clicking on the Blue I
icon
next to the profile. This lists the effect of the structural authorization when it is working.

 The HR Main switch: Tolerance time of the authorization check (ADAYS) which is 15 by default did not
affect
the structural authorizations in this example. In tests where a manger was moved from one organizational
unit to another the effect of the structural authorizations was immediate after running report
RHPROFL0. The
manager can no longer see information for anyone in their old organizational unit.
Overall Design Considerations
1. What level of the organizational plan to assign structural authorizations we use org units in this
example. This allows managers in the same org unit and same level to see each others information. If this
was not acceptable then a hybrid approach of organizational units and positions could be used. It seems
most efficient to attach structural authorizations to the highest node on the organizational plan possible.
Note that we create profiles with authorization for an organizational unit but we assign these profiles to
positions.
2. As mentioned in Gotchas above unassigned users linked to personnel master records with access to HR
transactions can see personnel data for any user. This has an impact on how you design both standard
roles and also procedures for creating roles. One way to make sure that unintended access does not occur
is to assign a dummy structural authorization to every user in the system with. The dummy structural
authorization should be empty. It is possible to control this using infotype 105 as well. Any user ID that is
not associated with a personnel master record will not be able to view other users information with the
correct standard authorizations assigned to the User ID.
Steps to Implement Structural Authorizations
1. Turn on PD PA Switch
Tcode: OOPS
Action: Ensure value registered for PLOGI ORGA is X. No other values need to be checked or changed.

Explanation: PD and PA sub modules of HR are not configured to share data by default in the SAP
delivered system. This switch must be on for data to flow between both modules.
Additional Info: None
Gotcha:

Do not create your Organizational Plan without this switch on.

If you do, structural authorizations will not work and some org and infotype setup will not work.

***You cannot turn the switch on and get structural authorizations on an organizational plan, that was

created while it was off, to work.***

2. Turn on Structural Authorizations Main Switches

Tcode: OOAC
Action: Ensure values for the main authorization switches in HR are set to the following Values
Group

Sem. abbr.

Value abbr.

Description

AUTSW

ADAYS

15

HR: tolerance time for authorization check

AUTSW

APPRO

HR: Test procedures

AUTSW

NNNNN

HR: Customer-specific authorization check

AUTSW

ORGIN

HR: Master data

AUTSW

ORGPD

HR: Structural authorization check

AUTSW

ORGXX

HR: Master data Extended check

AUTSW

PERNR

HR: Master data Personnel number check

Explanation: The SAP delivered system has similar values as above but PERNR = 0.
Gotcha: Make sure that ORGPD = 1 otherwise structural authorizations will not work.
Additional Info: Appendix 1
3. Create Organizational Plan
Tcode: PPOM_OLD
Action:
1. Create the root of your Organizational Plan
Organizational Plan > Create
Enter info and click Create

2. Create Organizational Units

Select the Organizational branch you want to build on and click Create
Fill in the abbreviations and names of the child structures (one level at a time) in the popup dialog box.

Example of the results:

3. Create and assign positions

Click on Staff Assignments button
Select the unit that the position will be part of, then click on Create Positions
In the popup dialog box select a job description in the Choose Describing Job field group, fill in the fields
in the Position field group and save.

Example of the results:

4. Designate Chief Positions

Select the Position which will be the managers position and Select Edit > Chief Position > Create
Select the position in the Create Chief Position dialog box and click on Save

Results:

Notice the position Manager of BC now has a Hat next to it and the name of the Chief is listed below the
Org Unit.
Explanation: Structural authorizations work based on this hierarchy (the Organizational Plan). This is
the structure in structural authorizations.
Gotcha:
Dont start this step without first ensuring the PD PA switch is on (the first step in this document).
If we want to use Managers Desktop we need to designate a position as Chief. The user(s) associated
with this position will only be able to access Managers Desktop if their position is designated as Chief.
Chief positions can have more than one person assigned, i.e. a single business unit can have more than
one manager at the same level.
SAPs documentation indicates that performance may be adversely affected by the complexity of
structural authorizations.
Additional Info: None

4. Create Personnel Master Record

Tcode: PA40
Action: Create a personnel master record and assign it to the organizational plan.
1. Ensure that Personnel no. field is empty. Select a hiring action from the bottom of the screen and Click
on execute.

2. Enter basic data for the master record.

 Enter a Start Date (current date is fine).

Enter Personnel Area, Employee Group and Subgroup.
Enter the Position Number to assign this employee to a node on the organizational plan.
Save

3. Enter more personal data.

Enter First and Last Name
Select Gender
Enter SIN number 000000000
Enter birthday
Save

4. Enter Information on one more screen.

Enter the Payer Area and Subarea
Save.

5. End maintenance for this action

Back out of the above screen
Yes to this message
Record the Personnel Number on the next screen

Results:

Explanation: User IDs are not assigned directly to the organizational plan. The User Master Record
(User ID) is relatively simple and is mostly used to give access to the SAP system. In SAP a personnel
master record is created and assigned to the organizational plan. The Personnel Master Record is then
linked to the User ID, which is the next step in building structural authorizations.
Gotcha:
Ordinarily all personnel master records will be assigned to a node on the Organizational Plan. See
Unassigned Users in the Gotchas in the Overview at the beginning of this document for more on this
issue.

 The sequence of the screens in this action can vary

Additional Info: None
5. Create User IDs
Tcode: SU01 or SU10 (Mass Create)
Action: Create users (Suggest creating users with a name similar to the Personnel Master employee
name)
Explanation: User master records must exist before you can proceed to the next step.
Gotcha: If you use mass create make sure that request with log and print or save the log so you know
what the initial password is for each user.
Additional Info: None
6. Create Infotype 105
Tcode: PA30
Action: Create Infotype 105 for each Personnel Master Record
1. Enter Personnel ID, Info Type 105 and Subtype 0001.

2. Enter the User ID in the ID/Number field

Explanation: The user master record and the personnel number have to be linked because it is the
personnel number that is associated with the Organizational Plan. When the user logs on SAP needs to
know which personnel number is associated with that user ID in order to grant structural authorizations.
Gotcha: None
Additional Info: None
7. Create Structural Authorization Profiles
Tcode: OOSP
Action: Create structural authorization profiles and then define the details of the authorization profile.
1. Click new entry. Enter the authorization profile names, and descriptions. Click Save. (If you dont save
here you wont be able to see the profile in the selection list of the next step)

Check the information for a profile e.g. Manager West.

Note: No organizational plan units are shown in the list.

2. Define the structural authorization profile.
Select a profile and click on Authorization Maintenance on the left side
Click on New Entry
Enter the following:
Field

Value

Profile:

Select a structural authorization profile

No.

Choose an interval e.g. 10

Plan vers.

Select a plan version probably 01

Obj. type

In this case we are securing by Org unit. Enter O

Object ID

In this case we are securing by Org unit. So enter the Org unit number

Maintenance

Check this on

Eval.path

Recommend O-S-P

Status vec

Recommend 12

Depth

Recommend no entry

Sign

Recommend no entry

Period

Recommend no entry

Function module

Recommend no entry

Explanation: We are creating structural authorization profiles here. In order to limit a users access to
information according to the structure of the organization plan, you must define the place on the
organizational structure below which a user can see personnel information.
Gotcha: Check the info button on the profile to make sure that the profile a) gives access to something
and b) gives access to the right thing.
Additional Info: Appendix 2
8. Create Infotype 1017

Tcode: PO10 (Organizational Unit) or PO13 (Position)

Action: Create Infotype 1017 for all relevant nodes on the Organizational Plan. In this case all Positions
(Tcode PO13)
1. Select the position

2. Select the PD Profile infotype from the scrollable list and click on Create button

3. Enter the profile name in the Profile field and click on the Save button

Explanation: This infotype links the structural authorization profile to a node on the organizational
plan. In our example we use PO13 to assign the authorization to a Position. Note we can assign the
structural authorization profile to other types of nodes e.g. an organizational unit but we must use
different transactions for each different node type.
Gotcha: This has to be done manually. SAP documentation may seem to indicate that report RHPROFL0
will do this, it doesnt, this step must be done manually.
Additional Info: None
9. Assign Structural Authorization Profiles to User IDs
Tcode: SE38
Action: Use report RHRPROFL0 to automatically assign the appropriate structural authorization profile
to each User ID. This program will update the table in transaction OOSB.
1. Execute the report

2. Enter the following data, the Object ID should be the object ID for the root of the Organizational Plan.
Field

Value

Organizational Unit

Object ID

e.g.50000753

Evaluation Path
Test Session

PROFL0
(check on)

Leave all other defaults as they are.

3. Execute in test mode

Note: The lights in the left margin of the report are yellow. This is because the assignment has NOT been
made yet.
4. Back out of this screen. Uncheck Test Session and then Execute to have the changes made.

Note: The lights in the left margin of the report are green now. This indicates that the assignment has
been made.
Explanation: This report assigns a structural authorization profile to the user ID based on the
Organizational Plan. If we had not first completed all the main steps listed above this report would be
empty. The report is a positive indicator that some of the steps to setup structural authorizations have
been completed successfully. It is possible however, to have results with this report and yet have
structural authorizations that do NOT work.
Gotcha:
Dont forget to execute the report with Test Session unchecked!
This report should be run daily to update the authorizations of users based on changed made in the
Organizational Plan.
Ensure that the Infotype 1017 has been populated for all relevant nodes on the Organizational Plan.
Additional Info: None
10. Setup Regular Security
Tcode: PFCG
Action: Create regular security role and assign to User ID
1. Create a role that gives access to regular HR transactions for all employees. E.g. Time Entry CAT2,
PA20, PR20 Enter expenses

2. Create a role that gives access to manager HR transactions. E.g. Time Approval CADO , PPMDT
Managers Desktop, PR05 Approve Expenses
Explanation: Structural authorizations are used in addition to standard security. Setup two roles to do
positive and negative tests.
Gotcha: None
Additional Info: None
Appendix 1
Authorization Main Switches
Gotcha: This is SAP delivered information. It is not that easy to understand. The bottom line is make sure
the Structural authorization switch and the P_PERNR switch are on.
Maintain Authorization Main Switches
In this step you maintain the authorization switch and adapt, if necessary, the profile generator
specifications. You must process the profile generator specifications if you intend to make changes to the
main switch settings.
You can process the authorization main switch using transaction HR: Authorization main switch (OOAC).
Using the Auth.object check under transactions transaction (SU24) you maintain whether a transaction
checks an authorization and/or whether the relevant authorizations are offered in the profile generator for
maintenance.
The profile generator recognizes whether authorization objects are used in transactions using the legal
check status. You can process this manually, also using the Auth.object check under transactions
transaction (SU24). Also check the individual authorization objects under Process check status in all
transactions. Ensure that the following check indicators are set:
When you switch on the HR: Master data (P_ORGIN), HR: Master data extended check (P_ORGXX)
and HR: Master data personnel number check (P_PERNR) authorization objects, you must set the
relevant check/maintain check status in the primary transaction that accesses these objects. You
recognize these in the standard system, because the check indicator is set to check/maintain (PP) for the
HR: Master data (P_ORGIN) object. In addition to this, please note the example below.
When you switch off the HR: Master data (P:ORGIN) authorization object, you must reset the check
indicator for the HR: Master data (P_ORGIN) authorization object from check/maintain (PP) to check
(P).
Example (1):
The HR: Master data (P_ORGIN) object is switched on, the HR: Master data extended check
(P_ORGXX) and Master data personnel number check (P_PERNR) objects are switched off.
No customer action is necessary.
Example (2):
The HR:Master data extended check (P_ORGXX) object is switched on, the HR: Master data
(P_ORGIN) and HR: Master data personnel number check (P_PERNR) objects are switched on. You
must set the following check status:
For the HR:Master data extended check (P_ORGXX) object, copy the default check indicator of the HR:
Master data (P_ORGIN) object. Then change the check indicator of the HR: Master data (P_ORGIN)
object from check/maintain (PP) to check (P). Leave the given check status for the HR: Master data
personnel number check (P_PERNR) object as it is.

Standard Settings
In the standard system the authorization main switches and settings are defined as follows:
Switch Setting
HR: Tolerance time of the authorization check (ADAYS)15
HR: Check procedure (APPRO) 0
HR: Customer authorization check (NNNNN) 0
HR: Master data (ORGIN) 1
HR: Structural authorization check (ORGPD) 1
HR: Master data extended check (ORDXX) 0
HR: Master data personnel number check (PERNR) 0
Further Notes
When you use a customer authorization object (P_PNNNN) you must maintain it in the Auth. object
check under transactions transaction, analogous to the HR: Master data (P_ORGIN), HR: Master data
extended check (P_ORGXX) and HR: Master data personnel number check (P_PERNR) objects.
Example:
When the switch is off for the HR: Master data (P_ORGIN) and HR: Master data extended check
(P_ORGXX) objects and is on for the customer object (PNNNN) and HR: Master data personnel
number check (P_PERNR) object, you must reset the check status for these corresponding to the setting
of the HR: Master data object (P_ORGIN) in the standard system to check/maintain (PP), and for the
HR: Master data (P_ORGIN) and HR: Master data extended check (P_ORGXX) to check.
Appendix 2
PD Authorization configuration fields
Auth Profile:
Chose an authorization profile. For this example we always selected the authorization profile that we were
editing. Gotcha: The profiles that have not been saved will not show in the list.
Line Number:
Enter a line number for each authorization. (Each line in this screen is a separate authorization.) This is a
unique identifier for the authorization. Choose any number, we chose 10 for our first authorization. The
second authorization would be 20
Plan Version:
Specify the current Plan version. Usually 01 (the active plan)
Object Type:
Specify object type We used O for Organizational Unit but you can assign authorizations to positions tasks
and standard tasks too.
Object ID:
Specify the object ID of the object in the Object ID field.
Maintenance:
Two types of function codes exist. A function codes with maintaining and a code with non-maintaining
attributes. The maintenance function code is linked to T77FC and is activated by flagging the Maintenance
field. If the Maintenance field is flagged, maintenance is possible for the authorized objects defined in the
PD Profiles.
Evaluation Path:
Select path from the list of delivered evaluation paths. Note: You can create a custom path via the IMG
Maintain evaluation paths. (O-S-P).

Status Vector:
Select the planning status (1-Active, 2-Planned, etc).
Depth:
Leave blank or specify the descending level of organizational units to access.
Sign: Controls access of structure direction. (+) or blank (default) Structure is viewed from root object and
down. (-) Structure is viewed in reverse from root object.
Time Period:
Use this field if you want to restrict the auth. according to the validity period of the structure. If you select
the entry D the authorization is limited to structures valid on the current day. Possible entries:Blank All,
D Current Day, M Current Month, Y Current Year, P Past, F Future
Function Module:
This field allows you to specify a function module to determine the root object of the structural
authorization. Possible entries: RH_GET_MANAGER_ASSIGNMENT (Determine organizational units
for manager).This function module finds the root organizational unit with which the user is related via the
position and relationship A012 (manages). RH_GET_ORG_ASSIGNMENT (Organizational assignment)
This function module finds the root organizational unit to which the user is organizationally assigned.
Appendix 3
Assign Structural Authorization Profile to User ID Manually
Unassigned Users: User IDs that have been linked to a Personnel Master Record via Infotype 105
MUST be assigned a structural authorization profile regardless of whether they are assigned to a node on
the organizational plan or not.
Why? Users in this situation will be able to see HR data for any Personnel Master Record as long as they
have the standard authorization profiles that give access to transactions where HR data can be seen, and
which give access to HR data to see other peoples data.
Solution: If the user is not on the Organizational Plan we need to assign the profile manually. If the user
is assigned to a node on the Organizational Plan AND that node has a structural authorization profile
assigned to it, we need to run report RHPROFL0 and we need to make sure the user does not log on. If the
user is assigned to a node AND that node does not have a structural authorization profile assigned to it we
need to assign the profile manually.
It is possible to assign a structural authorization directly to a user instead of having the profile assigned
indirectly by virtue of the users assignment in the Organizational Plan and the structural authorization
profile that is assigned to the same node as the user. This is not the recommended approach because it
will require increased maintenance. Assigning one or more structural authorizations directly to a User ID
means that we are not taking advantage of SAP delivered functionality which allows implicit assignment
of HR authorizations. If this approach is used then when the user is promoted for example, maintenance
will have to be done on both the Organizational Plan and in Transaction OOSB. Assigning structural
authorizations to users may be useful for temporary assignments, or testing.
Tcode: OOSB
Action: Assign structural authorization profile (created in OOSP) to the UserID
1. Click on New Entries button and enter the Name of the user, the name of the profile the start date, end
date. And save

2. Check to see that the profile is giving access to the appropriate Organizational units Positions etc

Explanation: This is analogous to assigning a profile generator role to a user ID. SAP needs to know
what structural authorization profiles a user takes advantage of .
Gotcha: You need to assign every user in the system at least one structural authorization profile
including consultants. Create a dummy authorization profile and assign it.
Additional Info: start date, end date limit the validity of the authorization so if the authorization has an
end date of June 30 then on July 01 they will no longer be able to see information on their subordinates.