Authorizations in HR PDF

SAP Online Help
16.04.2002
HELP.HRAUTH
Authorizations in mySAP HR
Release 46C
50A
SAP Online Help
16.04.2002
Copyright
Copyright 2001 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without
the express permission of SAP AG. The information contained herein may be changed without prior
notice.
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered
trademarks of Microsoft Corporation.
IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390,
AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation.
ORACLE is a registered trademark of ORACLE Corporation.
INFORMIX-OnLine for SAP and INFORMIX Dynamic ServerTM are registered trademarks of
IBM Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame,
MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web
Consortium, Massachusetts Institute of Technology.
JAVAis a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP
EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and other SAP
products and services mentioned herein as well as their respective logos are trademarks or
registered trademarks of SAP AG in Germany and in several other countries all over the world.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One.
All other product and service names mentioned are the trademarks of their respective owners.
50A
SAP Online Help
16.04.2002
Contents
Authorizations in mySAP HR .........................................................6
1 General Authorization Check....................................................6
1.1
Setting Up General Authorization Checks................................................................... 7
2 Structural Authorization Check .................................................9

2.1
Structural Profiles ...................................................................................................... 10
2.1.1
Definition of Structural Authorizations ................................................................ 12
2.1.2
Assignment of Structural Authorizations ............................................................ 17
3 Technical Aspects ..................................................................18

3.1
Authorization Objects ................................................................................................ 18
3.1.1
P_CH_PK (HR-CH: Pension Fund: Account Access)........................................ 20
3.1.2
P_DE_BW (HR-DE: Statements SAPScript) ..................................................... 20
3.1.3
P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)......... 21
3.1.4
P_PYEVDOC (HR: Posting Document) ............................................................. 21
3.1.5
P_OCWBENCH (HR: Activities in the Off-Cycle Workbench) ........................... 22
3.1.6
P_BEN (HR: Benefit Area) ................................................................................. 22
3.1.7
P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check) ........... 23
3.1.8
P_PE02 (HR: Authorization for Personnel Calculation Rule) ............................ 24
3.1.9
P_PE01 (HR: Authorization for Personnel Calculation Schemas)..................... 24
3.1.10
P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)24
3.1.11
P_HRF_META (HR: Authorization Check Master Data Maint. for HR Forms) .. 25
3.1.12
P_CERTIF (HR: Statements) ............................................................................. 25
3.1.13
P_APPL (HR: Applicants) .................................................................................. 26
3.1.14
P_PYEVRUN (HR: Posting Run) ....................................................................... 27
3.1.15
P_PCLX (HR: Clusters)...................................................................................... 28
3.1.16
P_DBAU_SKV (HR: DBAU: Construction Pay Germ. /Social Fund Procedure) 28
3.1.17
P_PCR (HR: Payroll Control Record) ................................................................ 29
3.1.18
P_ABAP (HR: Reporting) ................................................................................... 30
3.1.19
P_ORGIN (HR: Master Data)............................................................................. 32
3.1.19.1
Example of Period Determination Using P_ORGIN
33
3.1.20
P_PERNR (HR: Master Data Personnel Number Check) .............................. 34
3.1.21
P_ORGXX (HR: Master Data Extended Check) ............................................. 37
3.1.22
P_TCODE (HR: Transaction Code) ................................................................... 37
3.1.23
P_USTR (HR: US Tax Reporter) ....................................................................... 38
3.1.24
PLOG (Personnel planning) ............................................................................... 39
3.1.25
S_MWB_FCOD (BC-BMT-OM: Allowed Funct. Codes for Managers Desktop)40
3.1.26
P_NNNNN (Master Data: Customer-Specific Authorization Object).................. 40
3.1.27
Creating a Customer-Specific Authorization Object........................................... 41
3.1.28
Cross-Application Authorization Objects............................................................ 41
50A
SAP Online Help
3.2
16.04.2002
3.1.28.1
S_TABU_DIS (Table Maint. (Using Standard Tools Such as SM30))
42
3.1.28.2
S_TMS_ACT (TemSe: Actions on TemSe Objects)
42
HR: Authorization Main Switches .............................................................................. 43
3.2.1
AUTSW ORGIN (HR: Master Data) ................................................................... 44
3.2.2
AUTSW ORGXX (HR: Master Data Extended Check) ................................... 44
3.2.3
AUTSW NNNNN (HR: Customer-Specific Authorization Check)....................... 44
3.2.4
AUTSW ADAYS (Tolerance Time for Authorization Check) .............................. 44
3.2.5
AUTSW PERNR (HR: Master Data Personnel Number Check)..................... 45
3.2.6
AUTSW APPRO (HR: Test Procedures) ........................................................... 45
3.2.7
AUTSW ORGPD (HR: Structural Authorization Check)..................................... 45
3.3
AUTHC (Authorization Level) .................................................................................... 46
3.4
VDSK1 (Organizational Key) ..................................................................................... 47
3.5
Time Logic ................................................................................................................. 49
3.6
Periods of Responsibility ........................................................................................... 49
3.7
Control Mechanisms (Double Verification Principle, Test Procedures, etc).............. 50
3.7.1
Asymmetrical Double Verification Principle ....................................................... 50
3.7.2
Symmetrical Double Verification Principle ......................................................... 51
3.7.3
Test Procedures ................................................................................................. 51
3.7.4
Creation of Infotype Log..................................................................................... 52
4 Processes and Flowcharts of the Authorization Check ...........52

4.1
Process of the General Authorization Check ............................................................ 53
4.1.1
4.2
Process of the Authorization Check by Personnel Number ...................................... 56
4.2.1
4.3
Flowchart of the General Authorization Check .................................................. 55

Flowchart of the Authorization Check by Personnel Number ............................ 58
Process of Determining the Periods of Responsibility .............................................. 59
4.3.1
Process of Determining the Period of Responsibility According to

Organizational Structure..................................................................................... 59
4.3.1.1 Flowchart of Determining the Period of Responsibility According to

Organizational Structure
61
4.3.2
Process of Determining the Period of Responsibility According to the

Structural Authorization Check........................................................................... 62
4.3.3
Process of Determining the Period of Responsibility According to

Organizational Assignment ................................................................................ 65
4.3.3.1.1
Flowchart of Determining the Period of Responsibility According to

Organizational Assignment
67
4.3.4
Process of the Authorization Check Using P_ORGIN, P_ORGXX

and P_NNNNN ................................................................................................... 68
4.3.5
Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX

and P_NNNNN ................................................................................................... 70
4.4
Process of Time Logic ............................................................................................... 70
4.4.1
4.5
Flowchart of the Time Logic ............................................................................... 73
Process of the Test Procedures ................................................................................ 74
50A
SAP Online Help

4.5.1
4.6
16.04.2002
Flowchart of the Test Procedures ...................................................................... 76
Process of Determining the Date After Which Changes Are Permitted for
Test Procedures ........................................................................................................ 77
4.6.1
Flowchart of Determining the Date After Which Changes Are Permitted

for Test Procedures............................................................................................ 79
5 Interaction of General and Structural Authorizations...............80

6 Examples ...............................................................................81
6.1
Example: Employee Self-Service .............................................................................. 81
6.2
Example: Administrator Should Not Be Allowed to Edit Own Data........................... 82
6.3
Example: Administrator Should Not Be Allowed to Enter Data Alone....................... 82
6.4
Example: Decentralized Time Recording .................................................................. 83
6.5
Example: Telephone List ........................................................................................... 84
6.6
Example: Payroll........................................................................................................ 84
6.7
Example: Transaction-Dependent Authorizations..................................................... 84
6.8
Example: Structural Authorization Profiles ................................................................ 85
7 Customer Enhancements .......................................................86

7.1
HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks) ........... 86
7.1.1
Examples of the HRPAD00AUTH_CHECK BAdI .............................................. 90
7.1.2
Example of the Implementation of HRPAD00AUTH_CHECK ........................... 91
7.2
HRBAS00_STRUAUTH (BAdI: Structural Authorization).......................................... 97
8 Troubleshooting Authorization Problems ................................99

9 Constraints ...........................................................................100
9.1
Specific Processing of the Authorization Check in Dialog (Master Data) ............... 100
9.2
Special Features of the Authorization Check in Reporting (Master Data) .............. 101
9.3
Performance Aspects .............................................................................................. 102
9.3.1
Redundant Read of Objects............................................................................. 103
9.3.2
Evaluation Paths with Non-Specified Target Object Types ............................. 104
9.4
Context Problems in HR Authorizations .................................................................. 104
10 Additional Functions for Authorization Checks ...................107

10.1
Report RHPROFL0.................................................................................................. 107
10.2
RHBAUS00 Report (Regeneration INDX for Structural Authorization) ................... 107
10.3
RHBAUS01 Report (Output of Views on Objects in the Structural Authorization) .. 108
10.4
RHBAUS02 Report (Check and Compare T77UU (User Data in SAP Memory))... 108
10.5
RPUACG00 Report (Code Generation: HR Infotype Authorization Check)............ 109
11 Glossary.............................................................................110
12 Index ..................................................................................113
50A
SAP Online Help
16.04.2002
Purpose
Authorizations control system users access to system data and are therefore a fundamental
prerequisite for the implementation of business software.
In Human Resources, authorizations play a significant role as access to HR data must be strictly
controlled. There are two main ways to set up authorizations for mySAP Human Resources:
You can set up general authorizations that are based on the SAP-wide authorization concept or you
can set up HR-specific structural authorizations that check by organizational assignment if a user is
authorized to perform an activity.
Note
All information refers to the SAP standard release 4.6C unless otherwise stated.
Implementation Guidelines
To decide how best to set up your authorization requirements, see Technical Aspects [page 18] for
all relevant technical information about both authorization types.
Integration
You can set up both authorization types (general access authorizations and structural
authorizations) simultaneously. This can lead to a complex interaction of authorizations. For more
information, see Interaction of General and Structural Authorizations [page 80].
Features
This documentation explains for each authorization type the characteristics you should single out
and how you can use them to set up authorizations. For more information about the authorization
types, see General Authorization Check [page 6] and Structural Authorization Check [page 9].
For more information about the customer enhancements available for HR Authorizations, see also
Customer Enhancements [page 86].
For help with setting up authorizations and information about important help and tool reports for
authorizations, see Additional Functions for Authorization Checks [page 107].
Constraints
For information about the known problems and suggestions for solving problems, see Constraints
[page 100].
Example
Simple examples [page 81] demonstrate how you can accommodate different authorization
requirements.
General Authorization Check
Use
The general authorization check for mySAP HR controls access to Human Resources infotypes.
Integration
This authorization type applies to the general SAP authorization check, which is set up using the
transaction PFCG. The authorization objects that are used only in mySAP HR are HR-specific
authorization objects.
50A
SAP Online Help
16.04.2002
Features
Authorizations are defined by authorization objects. An authorization object specifies the fields that
occur in an authorization. The system checks if a user has the corresponding authorization for
certain field specifications in the user master record.
Authorizations are grouped together in authorization profiles.
A users authorizations for the different authorization objects in the system are determined from the
authorization profiles assigned to the user in the master data record.
There are a number of authorization objects you can use to define authorizations for mySAP HR.
You can call up these authorization objects using transaction SU21 (HR object class) in the SAP
system. For more information, see Authorization Objects [page 18].
The authorization main switch controls the use of authorization objects. For more information about
the authorization main switches, see HR: Authorization Main Switches [page 43].
In addition to the authorization objects and the main authorization switches, the following technical
aspects are important for general authorizations in mySAP HR:
Authorization Level [page 46] (AUTHC field) - this field controls the access mode (read, write, ...)
in HR authorization objects. It can have different specifications according to the authorization
object.
Organizational Key [page 47] (VDSK1 field) - this field is only contained in the P_ORGIN
authorization object. You can use this object to carry out a differentiated authorization check by
organizational assignment.
Time Logic [page 49]
Periods of Responsibility [page 49]
Control Mechanisms [page 50] (Double Verification Principle, Test Procedures, etc.)
For a description of the process of general authorization checks in mySAP HR (and of all relevant
substeps in this process), see Processes and Flowcharts of the Authorization Check [page 52].
Activities
For general information about setting up authorizations for SAP applications, see Setting up
General Authorization Checks [page 7].
Example
The following examples demonstrate how you can accommodate simple authorization requirements
for the general authorization check:
Employee Self-Service [page 81]
Administrator Should Not Be Allowed to Edit Own Data [page 82]
Administrator Should Not Be Allowed to Enter Data alone [page 82]
Decentralized Time Recording [page 83]
Telephone List [page 84]
Payroll [page 84]
Transaction-Dependent Authorizations [page 84]
1.1 Setting Up General Authorization Checks

Use
You set up authorizations in the form of roles using role maintenance (transaction PFCG). Roles
provide a business perspective by representing the tasks and activities that a user is authorized to
50A
SAP Online Help
16.04.2002
perform in the system. Authorizations are parts of roles and are stored as an authorization profile
for the role. Role maintenance generates one part of the authorization profile (functional part)
automatically; you must define the part of the profile that controls which data a user has access to
manually. You can generate several authorization profiles for each role. When you generate roles,
you also define the authorization objects with the necessary field specifications.
User menus provide access to the transactions, reports or web-based applications contained in the
roles. A user menu should therefore contain only the functions that are required by a specific user
with a specific task profile for daily work.
Note
Authorizations were set up using the transactions SU01 and SU03 up to release 4.6A.
Up until then, the common term used to describe roles was activity groups.
Procedure
To create roles and to generate authorization profiles, proceed as follows:
1. To create or change a role, choose Role Maintenance using transaction PFCG. If you want to
create your own user roles, make sure you do not use the SAP namespace (all roles delivered
by SAP have the prefix SAP_).
2. In the Menu tab page, assign transactions, reports, and/or web addresses to the role. By doing
this, you set the user menu that is automatically called up when the user assigned to this role
logs on to the SAP system. When you assign transactions and so on, the users role or task
profile is defined. The transactions defined in Menu tab page are then used by the system to
create authorizations automatically.
3. You can change the authorizations that were automatically created by the system if you need to
by setting the menu in the Authorizations tab page. To do so, choose the Expert Mode option
under Maintain Authorization Data and Generate Profile in this tab page.
You can create additional authorizations when you change the authorizations that you have
already created by choosing additional authorization objects and so on, for example.
4. In the Authorizations tab page , also generate the authorization profile belonging to the role
when you have finished any post-processing work on the automatically created authorizations.
5. In the User tab page, assign users to the newly generated role.
Note
You can also assign users to roles by user groups and by objects (for example, job) in
Organizational Management. You cannot use the profile generator for this type of
assignment; you must use transaction SU10 (User Maintenance: Mass Changes) in
Organizational Management.
Caution
The generated profile is only entered in the user master record once a user comparison
has taken place. A comparison is also required if changes are made to the users
assigned to the role and if an authorization profile is generated.
For more information about setting up authorization profiles, see the Implementation Guide (IMG)
for Personnel Administration under Tools Authorization Management Maintain Profiles.
In addition, you can find all relevant and non-HR-specific information on authorization maintenance
(Role Maintenance) in the SAP Library under Basis Computing Center Management System
(BC-CCM) Users and Roles (BC-CCM-USR).
50A
SAP Online Help
16.04.2002
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 [page 80].
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 [page 10].
Activities
For information on how to set up structural authorizations, see Definition of Structural
Authorizations [page 12].
Example
The following example illustrates the advantages of structural authorizations for access to data in
time-dependent structures:
50A
SAP Online Help
16.04.2002
O1
O2
O5
O11
O3
O6
O7
O4
O8
O9
O10
O12
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
[page 85].
2.1 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:
50A
10
SAP Online Help
16.04.2002
Graphic 1: Diagram of an
organizational structure using
objects and relationships
A002: reports to
O0
O1
O2
O3
O6
S5
A003:
belongs to
S1
O4
B008:
Holder
O5
A003: belongs
to
P1
B008:
Holder
S2
S3
S4
P2
P3
P4
P5
B008:
Holder
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.
Example
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:
50A
11
SAP Online Help
16.04.2002
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 [page 9]
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 [page 12] for more information on these fields and how to
create structural profiles.
Note
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:
2.1.1
PLOG (Personnel Planning) [page 39]: Importance of the PLOG authorization

object for the structural authorization check
AUTSW ORGPD (HR: Structural Authorization Check) [page 45]: Importance of the
ORGPD authorization main switch
Flowchart: Example of Period of Responsibility According to Structural

Authorization Check [page 62]
Interaction of General and Structural Authorizations [page 80]
Example: Structural Authorization Profiles [page 85]
HRBAS00_STRUAUTH (BAdI: Structural Authorization) [page 97]
Performance Aspects [page 102]
Redundant Read of Objects [page 103]
Evaluation Paths with Non-Specified Target Object type [page 104]
Context Problems in HR Authorizations [page 104]
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).
50A
12
SAP Online Help
16.04.2002
There are
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 [page 80] 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 [page 17].
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 [page
10].
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.
50A
13
SAP Online Help
16.04.2002
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
[page 102].
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.
Graphic 2: Effect of the Display
Depth parameter:
A structural authorization with display
depth 2 only includes objects up to level
2 of the hierarchy (from the start object)
in this authorization.
Level 1
O1
Level 2
O2
O3
S4
Level 3
S1
S2
S3
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.
50A
14
SAP Online Help
16.04.2002
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
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
[page 49]. 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 [page 62] for a description of how the
period of responsibility is determined for the general authorization check.
Graphic 3: How the Period Field Works

in Structural Profiles
O1
01.01.1999 - 31.12.9999
S1
01.01.1999 - 31.12.2000
S2
01.01.1999 - 31.12.9999
P1
P2
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
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.
50A
15
SAP Online Help
16.04.2002
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, the
number of entries in the T77PR table can be reduced significantly by setting up function
modules.
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.
Graphic 4: How the

RH_GET_MANAGER_ASSIGNMENT
Function Module Works:
O0
The function module determines the

organizational unit assignment to a
user/person from a user's assignment to a
personnel number or position. The structural
profile uses this organizational unit as the
root object,if the position determined by the
function module is a manager position. In the
structure on the right, for example, user 1
(US1) has organizational unit O1 as root
object of his or her structural authorization.
US1
User 2 (US2) has no root object (with the
same profile) and therefore has no structural
authorization.
O2
A003
S1
B008
A268
S2
P1
B008
US2
O1
A012 = "is
manager of"
A268
P2
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.
50A
16
SAP Online Help
16.04.2002
Graphic 5: How the

RH_GET_ORG_ASSIGNMENT Function
Module Works:
O0
A003
The function module determines the

organizational unit assignment to a user/person
from a users assignment to a personnel
number or position. The structural profile uses
this organizational unit as the root object: If two
users have the same structural profile, O2 is
determined for user 1 (US1) and for user 2
(US2), O2 is determined as the root object.
Even if U1 was moved to a position under O2,
the same profile would return the desired result. US1
O1
S1
B008
A268
S2
P1
B008
US2
2.1.2
O2
A268
P2
Assignment of Structural Authorizations
Use
You can use this function to assign structural profiles to users.
Integration
Structural profiles are not assigned in the same way as general authorization profiles. Whereas
general authorization profiles are assigned using the Profile Generator (PFCG transaction), you
assign structural profiles using table T77UA (User Authorizations = Assignment of Profile to User).
Note
You can edit this table in the Implementation Guide (IMG) for Organizational
Management under Basic Settings Authorization Management Structural
Authorization Assign Structural Authorization.
Activities
You can assign users to structural profiles using table T77UA or the OOSB transaction.
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.
Note
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.
50A
17
SAP Online Help
16.04.2002
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 [page 18]
HR: Main Authorization Switch [page 43]
AUTHC (Authorization Level) [page 46]
VDSK1 (Organizational Key) [page 47]
Periods of Responsibility [page 49]
Control Mechanisms (Double Verification Principles, Test Procedures, etc.) [page 50]
3.1 Authorization Objects

In certain contexts, you may need several authorizations to perform an operation in the SAP
system. The resulting contexts can be very complex. The SAP authorization concept has been
realized on the basis of authorization objects to provide an understandable and easy-to-follow
procedure. Several system elements that are to be protected form an authorization object.
Authorization objects enable complex checks of an authorization that allows a user to carry out an
action. An authorization object groups up to ten authorization fields that are checked in an AND
relationship.
For an authorization check to be successful, all field values of the authorization object must be
maintained in the user master data.
Authorization objects are assigned to object classes for purposes of clarity. The authorization
objects for mySAP HR belong to the HR (Human Resources) object class.
You can display or edit the authorization objects and their fields using transaction SU21. You can
also use this transaction to create new object classes and authorization objects.
The authorization objects of the HR (Human Resources) object class have, as with all SAP
authorization objects, up to ten fields which are read by the system during an authorization check.
Example
The P_ORGIN [page 32] authorization object (HR: Master Data), which is used in the
standard system, consists of the following fields:
Authorization Field
Long Text
INFTY
Infotype
SUBTY
Subtype
AUTHC
Authorization Level
PERSA
Personnel Area
PERSG
Employee Group
PERSK
Employee Subgroup
VDSK1
Organizational Key
50A
18
SAP Online Help
16.04.2002
You can therefore assign authorizations for personnel data in Human Resources at
infotype/subtype level according to the employees personnel area, employee group,
employee subgroup, and organizational key.
The following sections describe the authorization objects for the HR (Human Resources) object
class and selected authorization objects from the BC_A (Basis - Administration) object class that
also play an important part in mySAP HR.
Note
In most cases, the individual fields of the authorization objects are described by means
of examples. An exception to this is the field that contains the access authorization for
an authorization object (normally AUTHC [page 46] or ACTVT). This field or in other
words fields that are based on a special logic are described in more detail for each
authorization object.
Authorization objects for the HR object class:
P_CH_PK (HR-CH: Pension Fund: Account Access) [page 20]
P_DE_BW (HR-DE: Statements SAPScript) [page 20]
P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company) [page 21]
P_PYEVDOC (HR: Posting Document) [page 21]
P_OCWBENCH (HR: Activities in the Off-Cycle Workbench) [page 22]
P_BEN (HR: Benefit Area) [page 22]
P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check) [page 23]
P_PE02 (HR: Authorization for Personnel Calculation Rule) [page 24]
P_PE01 (HR: Authorization for Personnel Calculation Schemas) [page 24]
P_HRF_INFO (HR: Authorization Check InfoData Maintenance HR Forms) [page 24]
P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms) [page 25]
P_CERTIF (HR: Statements) [page 25]
P_APPL (HR: Applicants) [page 26]
P_PYEVRUN (HR: Posting Run) [page 27]
P_PCLX (HR: Clusters) [page 28]
P_DBAU_SKV (HR: DBAU: Construction Pay Germany Social Fund Procedure) [page 28]
P_PCR (HR: Payroll Control Record) [page 29]
P_ABAP (HR: Reporting) [page 30]
P_ORGIN (HR: Master Data) [page 32]
P_PERNR (HR: Master Data Personnel Number Check) [page 34]
P_ORGXX (HR: Master Data Extended Check) [page 37]
P_TCODE (HR: Transaction Code) [page 37]
P_USTR (HR: US Tax Reporter) [page 38]
PLOG (Personnel Planning) [page 39]
S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for Managers Desktop) [page 40]
P_NNNNN (Customer-Specific Authorization Object) [page 40]
The following authorization objects are also important for mySAP HR:
S_TABU_DIS (Table Maintenance (Using Standard Tools such as SM30)) [page 42]
50A
19
SAP Online Help
16.04.2002
S_TMS_ACT (TemSe: Actions on TemSe Objects) [page 42]
3.1.1
P_CH_PK (HR-CH: Pension Fund: Account Access)
Definition
Authorization object that is used during the authorization check for access to pension fund accounts
(PF Accounts). This check takes place in transactions or reports that process account data.
Structure
The P_CH_PK authorization object contains the following fields which, are tested during an
authorization check:
Authorization Field
Long Text
KONNR
Number of Individual PF Account
AUTGR
HR-CH: Authorization for PF Accounts
PKKLV
HR-CH: Pension Fund: Authorization Level for Account Access
More Information About the Fields
The KONNR field specifies which pension fund accounts an administrator is authorized to
access.
The AUTGR field specifies the permissible authorization groups for the authorization check.
The PKKLV field specifies which operations (authorization level) the user is authorized to
perform in pension fund accounts. The following values are possible:
-: No Access
R: Read authorization
W: Write authorization
X: Extended authorization (for example, offsetting entries for postings or changing the lock
date)
3.1.2
P_DE_BW (HR-DE: Statements SAPScript)
Definition
Authorization object that enables you to determine the authorization check within statements (with
SAPScript) for Payroll Germany.
Use
Only edit this authorization object if you have first set up statements with SAPScript. You can do
this as of Release 4.6B.
If you use statements without SAPScript, you must use the P_CERTIF (HR: Statements) [page 25]
Structure
The P_DE_BW authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
BEWID
Statement Identifier
BSUBJ
InfoSet Identification for Statements
BACT
Activities for Statements in Authorization Check
50A
20
SAP Online Help
16.04.2002
The BEWID field contains the statement identifier for statements in Payroll Germany that should
be tested during an authorization check.
The BSUBJ field contains the functional area identification (ID) for statements. The functional
area represents a logical breakdown of the statements according to individual subject areas.
Note that you can define the access using the parameter ID (PID or user parameter) BSUBJ. By
predefining the values for a function area, the correct authorization is used when you call up the
application for the first time.
Example
The administrator only has authorization for functional areas 03 and 04. In this case,
the BSUBJ user parameter must be set as one of the two values. The administrator is
therefore only authorized to navigate within these two functional areas.
If an administrator has authorization for all functional areas, the user parameters can only
be used to simplify coordination since the initial access branches directly to this functional
area.
You can configure up to 30 functional areas.
The BACT field contains the activities for statements that are valid as part of the authorization
check. The following values are possible:
E: Creation of statements
A: Asynchronous archiving
S: Fast entry/Ad Hoc Query
V: Administration of archived statements
3.1.3
P_DK_PBS (HR-DK: Authorization Check for Access to

PBS Company)
Definition
Authorization object that is used during authorization checks for PBS companies.
Structure
The P_DK_PBS authorization object contains the following field that is tested during an
Authorization Field
Long Text
PBSFIRMA
HR_DK: Company Used for PBS
3.1.4
P_PYEVDOC (HR: Posting Document)
Definition
Authorization object that is used to protect actions on posting documents.
Structure
The P_PYEVDOC authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
BUKRS
Company Code
ACTVT
Activity
50A
21
SAP Online Help
16.04.2002

The ACTVT field contains the activities for posting documents that are possible as part of the
authorization check. The ACTVT field can have the following values:
03: Display
10: Post
28: Display Line Item
43: Release
3.1.5
P_OCWBENCH (HR: Activities in the Off-Cycle

Workbench)
Definition
Authorization object that is used during the authorization check for the off-cycle workbench. The
P_OCWBENCH authorization object ensures that each administrator sees only the off-cycle
activities that he or she is authorized to perform.
Structure
The P_OCWBENCH authorization object contains the following field which is tested during an
Authorization Field
Long Text
P_OCTYP
Type of Off-Cycle Activity

The P_OCTYP field contains the activities for the off-cycle workbench that are possible as part of the
authorization check. The field can have the following values:
OC: Run Off-Cycle Payroll
HI: Display History
PR: Replace Payment
AC: Assign Check Number
PV: Reverse Payment
3.1.6
P_BEN (HR: Benefit Area)
Definition
Authorization object that is used during the authorization check for benefits. This check takes place
when benefit tables are edited or read.
Structure
The P_BEN authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
PBEN_AREA
Benefit Area
ACTVT
Activity

The ACTVT field contains the activities for benefits that are possible as part of the authorization
check. The field can have the following values:
50A
22
SAP Online Help
16.04.2002
02: Change
03: Display
3.1.7
P_CATSXT (HR: Time Sheet for Service Providers

Type/Level Check)
Definition
Authorization object that is used during the authorization check for task type and task level in the
Time Sheet for Service Providers.
Use
The P_CATSXT authorization object is used for the following checks in the CATSXT and
CATSXT_ADMIN transactions:
Fill the Drop Down F4 Help for task type and level
Request data records from the history for editing, copying or deleting
Save and check new/changed data records
You can use this object to restrict the task types and levels that employees can use in time
recording according to different organizational perspectives.
Structure
The P_CATSXT authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
CATS_AUTHP
Personnel Number Check
TASKLEVEL
Task Level
TASKTYPE
Task Type
BUKRS
Company Code
PERSA
Personnel Area
KOSTL
Cost Center
PERSG
Employee Group
PERSK
Employee Subgroup
ORGEH
Organizational Unit
ACTVT
Activity
The CATS_AUTHP field contains the processing mode that is permitted for the authorization
check. The following values are possible:
E: Processing your own personnel ID
O: Processing a different personnel ID
Note
To determine your own personnel ID, infotype 105 must be defined in the system.
The ACTVT field contains the permitted activities. The following values are possible:
01: Add (currently not used)
50A
23
SAP Online Help
16.04.2002
02: Change (edit or copy data from the history)

03: Display (currently not used)
06: Delete (delete data from history)
71: Evaluate (currently not used)
3.1.8
P_PE02 (HR: Authorization for Personnel Calculation Rule)
Definition
Authorization object that is used during the authorization check for personnel calculation rules.
Structure
The P_PE02 authorization object contains the following field, which is tested during an
Authorization Field
Long Text
P_AUTHPE02
Personnel Calculation Rule: Authorization
3.1.9
P_PE01 (HR: Authorization for Personnel Calculation

Schemas)
Definition
Authorization object that is used during the authorization check for personnel calculation schemas.
Structure
The P_PE01 authorization object contains the following field, which is tested during an
Authorization Field
Long Text
P_AUTHPE01
HR Schema: Authorization
3.1.10 P_HRF_INFO (HR: Authorization Check InfoData

Maintenance for HR Forms)
Definition
Authorization object that is used during the authorization check for the processing of infotypes for
HR Forms.
Structure
The P_HRF_INFO authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
MOLGA
Country Grouping
P_HRF_INET
HR Forms: InfoNet
ACTVT
Activity

The ACTVT field contains the activities for the InfoData maintenance of HR Forms that are possible
as part of the authorization check. This field can have the following values:
02: Change
50A
24
SAP Online Help
16.04.2002
03: Display
3.1.11 P_HRF_META (HR: Authorization Check Master Data

Maintenance for HR Forms)
Definition
Authorization object that is used during the authorization check for HR Forms.
You can carry out different actions in the HR Forms application. You can use this authorization
object to restrict the actions a user can carry out.
Structure
The P_HRF_META authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
P_HRF_TYP
HR Forms: Object Type
MOLGA
Country Grouping
P_HRF_MOBJ
HR Forms: MetaData Object
ACTVT
Activity

The ACTVT field contains the activities for the MetaData maintenance of HR Forms that are
possible as part of the authorization check. This field can have the following values:
02: Change
03: Display
3.1.12 P_CERTIF (HR: Statements)

Definition
Authorization object that is used in Statements to check which tasks an administrator is authorized
to perform.
Use
This object is used only in Statements. Only edit this authorization object if you have first set up
statements without SAPScript. If you use statements with SAPScript, you must use the P_DE_BW
[page 20] authorization object. This object is used in screen control and in report creation.
In screen control, this object determines whether an administrator is authorized to perform a certain
task.
In report creation, this object determines whether an administrator is authorized to make changes
when displaying statements that have already been created (this corresponds to individual
creation).
Structure
The P_CERTIF authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
MOLGA
Country Grouping
BESNR
Statement Number
AUTHC
Authorization Level
50A
25
SAP Online Help
16.04.2002
The MOLGA field defines the countries for which an administrator is authorized to process
statements. The countries must correspond to the country modifier.
The BESNR field defines which statements an administrator is authorized to access using a
number interval. The specified numbers must correspond to the existing statements.
The AUTHC field contains the access mode for the authorization (for example, Display). The
following values are possible:
E: Create statements using the Single Record Entry option
S: Create statements using the Fast Entry option
A: Display statements using the Print Statement option
D: Print statements using the Print Statement option
L: Delete statements using the Print Statement option
F: Release statements using the Print Statement option
Example
You want to assign an administrator the following authorizations:
Create all German statements
Delete all German statements between 1 and 10
Display and print all Austrian statements
Define three authorizations and group these into one profile. Assign this profile to the administrator
by user assignment:
Authorization
Country Grouping
Statement Number
Authorization Level
P_CRF_ALD
01
ES
P_CRF_TENLD
01
01-10
P_CRF_DRUA
03
AD
3.1.13 P_APPL (HR: Applicants)

Definition
Authorization object that is used during the authorization check of Recruitment infotypes. The
checks take place when applicant infotypes are edited or read.
Structure
The P_APPL authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
INFTY
Infotype
SUBTY
Subtype
AUTHC
Authorization Level
PERSA
Personnel Area
APGRP
Applicant Group
APTYP
Applicant Range
VDSK1
Organizational Key
50A
26
SAP Online Help
16.04.2002
Responsible Personnel Officer
RESRF
The AUTHC field contains the access mode for the authorization (for example, R = Read). See
authorization level [page 46] for a detailed description of the possible specifications (M, R, S, E,
D, W, *) for this field.
The PERSA, APGRP, APTYP, VDSK1 and RESRF 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. A
users period of responsibility is represented by all the time intervals for which he or she has
P_APPL authorizations (see also example of the period of responsibility using P_ORGIN [page
33]).
Note
Unlike the P_ORGIN and P_ORGXX authorization objects, the check on this
authorization object cannot, in principle, be deactivated (that is, there is no
corresponding authorization main switch).
3.1.14 P_PYEVRUN (HR: Posting Run)

Definition
Authorization object that is used during the authorization check for posting runs.
Structure
The P_PYEVRUN authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
P_EVTYP
Run Type
P_EVSIMU
Posting Run: Simulation Indicator
ACTVT
Activity
The P_EVTYP field contains the run type that is to be tested during the authorization check. The
PP: Payroll Posting
TP: Posting Third-Party Remittance
AP: Posting Tax/SI Austria
The P_EVSIMU field specifies whether the authorization check should be carried out for
simulation or live runs.
The AUTHC field contains the activity for the authorization (for example, Display). The following
values are possible:
01: Add or Create
03: Display
06: Delete
10: Post
85: Reverse
50A
27
SAP Online Help
16.04.2002
3.1.15 P_PCLX (HR: Clusters)

Definition
Authorization object that is used during the authorization check for access to PCLx HR files (x = 1,
2, 3, 4) using the PCLx buffer (interface supported by HR).
Structure
The P_PCLX authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
RELID
Area Identifier for Clusters in Tables
AUTHC
Authorization Level
The possible specifications for the RELID field are the fixed values of the RELID_PCL domain.
The fixed values and their meaning are stored in the T52RELID table (HR: Description of
Clusters in PCLx Tables).
The AUTHC field contains the activity for the authorization but uses a different logic for P_PCLX
than for other authorization objects. The following specifications are possible:
R: Read
U: Write (update) this includes the authorizations of authorization level S but not
authorization level R
S: Write data to internal buffer but not to database (simulation)
3.1.16 P_DBAU_SKV (HR: DBAU: Construction Pay Germany

Social Fund Procedure)
Definition
Authorization object that is used exclusively in Construction Pay Germany for reports on the Social
Fund Procedure.
Use
This authorization object determines which reports with which parameters or which processing
steps an administrator is allowed to run or carry out.
The RPCBLFD0 report (Construction Pay: Evaluations of the Social Fund Procedure) defines which
activities an administrator is allowed to perform:
Display posting runs already created
Create new posting runs
Delete the last posting run to be carried out
Structure
The P_DBAU_SKV authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
REPID
ABAP Report Name
ZVKAS
Social Fund
RZNUM
Data Processing Center Number for Constr.Ind.SI Fund
50A
28
SAP Online Help
16.04.2002
Activity
ACTVT
The REPID field contains the name of a report that is used to check an authorization object, for
example the evaluation report for the social fund procedure. A granted authorization refers,
however, only to this report.
The ZVKAS field specifies the social funds for which a granted authorization should be valid.
The RZNUM field specifies the data processing center number that a granted authorization
should refer to.
01: Add or Create
03: Display
06: Delete
Example
An administrator should have the following authorizations regarding the evaluation report for the
social fund procedure:
Display posting runs already created
Create all posting runs for social fund 02
Delete a posting run of the 02 social fund for the data processing center number 12345678
(providing the posting run is the last posting run to have been created)
Define three authorizations and group these into one profile. Assign this profile to the administrator
by user assignment:
Authorization
Report Name
Social Fund
Data Center
Activity
P_DBAU_SKV_A
RPCBLFD0
03
P_DBAU_SKV_E
RPCBLFD0
02
01
P_DBAU_SKV_L
RPCBLFD0
02
12345678
06
3.1.17 P_PCR (HR: Payroll Control Record)

Definition
Authorization object that is used during the authorization check for payroll control record.
Use
This check takes place when the control record is displayed using transaction PA03, or when the
control record is maintained. The check also takes place during maintenance using the payroll
menu.
Structure
The P_PCR authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
ABRKS
Payroll Area
ACTVT
Activity
50A
29
SAP Online Help
16.04.2002

01: Add or Create
02: Change
03: Display
06: Delete
3.1.18 P_ABAP (HR: Reporting)

Definition
Authorization object that is used during the authorization check for HR Reports.
Use
This authorization object is used to:
Run reports in HR Reporting (with reports that are based on the logical databases SAPDBPNP
or SAPDBPAP)
Evaluate logged changes in infotype data
Process person-related data using payment medium programs from Accounting
Structure
The P_ABAP authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
COARS
Degree of Simplification of the Authorization Check
REPID
ABAP Report Name
Using P_ABAP in HR Reporting:

You can use the relevant authorizations for this object to control how the objects P_ORGIN,
P_ORGXX, and the customer-specific authorization object P_NNNNN are used in the specified
reports to check the authorization of HR infotypes. You can also use reports to control the infotype
authorization check. This can be useful for functional reasons or to improve performance at runtime
of the corresponding reports.
For this object, enter the report name(s) in the REPID field and the degree of simplification to be
used for the authorization check in the COARS field.
The following degrees of simplification are possible:
Authorization using COARS = <BLANK> or no authorization. The authorization checks are to

be processed as in
Authorization using COARS = 1.The authorization checks for the

infotype/subtype combination and for organizational assignment are to
be checked separately. This means that a user is authorized to read a personnel number
when he or she has a read authorization for all the infotypes (subtypes) requested by the
program and that the user has a read authorization for the organizational assignment of the
personnel number.
Authorization using COARS = 2. The authorization check is inactive.
50A
30
SAP Online Help
16.04.2002
Notes
Note that an ABAP authorization for report SAPDBPNP with COARS = 2 means that all
HR reports based on the logical databases PNP or PAP (nearly all reports) cannot
perform any more authorization checks. In general, you will only want to deactivate the
authorization checks for a very small number of Reports. In case of doubt, do not
assign your users authorizations for the P_ABAP object.
Furthermore, note that this authorization object differs from the object S_PROGRAM
(ABAP: Program Run Checks). The latter is used for general program authorization
checks. In HR reports, these checks are carried out in addition to the HR infotype
authorization check. HR Reporting, however, overrides the HR infotype authorization
check for selected reports, with the result that the authorization checks are weakened
or completely switched off.
Examples
In your company, the authorization for infotypes is set up independently of the authorization
for specific organizational units. For example, an administrator is authorized to access
address, personal, and education data and is responsible only for personnel area 0101.
This does mean that the administrator would be authorized to access addresses in
personnel area 0101 and persona data in personnel area 0102. If you enter 1 in the COARS
(Degree of Simplification) field, the authorization check takes account of how the
authorization has been set up by reading the Reports entered in the REPID (Report Name)
field, and the authorization check for a user with this authorization runs more quickly.
If certain HR reports are not critical (telephone lists and so on) and authorization protection
is not required, enter the report name and * in the Degree of Simplification field. The
system then checks the specified reports to see whether the user is authorized to start
the report (S_PROGRAM (ABAP: Program Run Checks) authorization object), but perform
no other authorization checks.
In your company, one user has access to all HR infotype data. Assign this user an
additional authorization for the existing object by entering* in the REPID and COARS fields
Consequently, the system only checks if this user is authorized to start the report. It does
not check whether this user is authorized to display the requested HR infotype data. The
fact that the user has unlimited authorization does not change the results of the
authorization check, but does affect the runtime required to produce the result is authorized
to. The reports are processed more quickly.
A time administrator carries out time evaluations using the RPTIME00 report (HR: Time Time Evaluation) for employees assigned the organizational key 0001TIMEXXX. To obtain
certain additional information that is required internally and that the program user cannot
see or can see only partially, the system must read the Basic Pay (0008) infotype, amongst
others, during time evaluation. To be able to carry out time evaluation, the time
administrator must have a display authorization for the Basic Pay (0008) infotype. On the
other hand, the user should not have general display authorization for the Basic Pay (0008)
infotype. To restrict the read authorization for the Basic Pay (0008) infotype for employees
with the 0001TIMEXXX organizational key in the RPTIME00 report, use the following
authorizations:
P_ORGIN (HR: Master Data) two authorizations:
INFTY = 0008
SUBTY = *
AUTHC = R
VDSK1 = <Blank>
...
INFTY = <Blank>
SUBTY = <Blank>
50A
31
SAP Online Help
16.04.2002
AUTHC = <Blank>
VDSK1 = 0001TIMEXXX
...
Object P_ABAP (HR: Reporting):
REPID = RPTIME00
COARS = 1
A simple check is carried out for the infotype authorization check in conjunction with the
RPTIME00 report (HR: Time Time Evaluation): The system independently checks
infotype, subtype, and level on the one hand, and organizational assignment (in the
example, the VDSK1 field (Organizational Key)) according to degree
of simplification 1. The Basic Pay (0008) infotype can also be read in the
RPTIME00 report (HR: Time Time Evaluation).
However, if the check is not in conjunction with the RPTIME00 report (HR: Time Time
Evaluation), all fields of the object P_ORGIN (HR: Master Data) are checked together. This
check does not result in read authorization for the Basic Pay (0008) infotype.
Using P_ABAP to evaluate logged changes in infotype data:

Evaluations of the logged changes in infotype data are subject to infotype authorization checks. The
person who starts this kind of evaluation normally has extensive infotype authorizations. In this
case, it makes more sense to assign the user a global authorization using the RPUAUD00 report
(Logged Changes to Information Types Data) rather than to check individual data. To do so, use an
authorization for the existing object that has the value RPUAUD00 in the REPID field (ABAP
Report Names) and the value 2 in the COARS field (Degree of Simplification).
Using P_ABAP to process personal data using payment medium programs in

Accounting:
The payment medium programs in Accounting specifically process extremely sensitive personal
data. As an additional security measure, the system checks whether the user has a corresponding
authorization for the existing object and checks whether the user is authorized to start the program.
You must enter the name of the payment medium program in the REPID field (ABAP Report
Names) and the value 2 (or *) in the COARS field (Degree of Simplification).
3.1.19 P_ORGIN (HR: Master Data)

Definition
Authorization object that is used during the authorization check for HR infotypes. The check takes
place when HR infotypes are edited or read.
Structure
P_ORGIN contains the following fields, which are tested during an authorization check:
Authorization Field
Long Text
INFTY
Infotype
SUBTY
Subtype
AUTHC
Authorization Level
PERSA
Personnel Area
PERSG
Employee Group
PERSK
Employee Subgroup
VDSK1
Organizational Key
50A
32
SAP Online Help
16.04.2002
AUTHC (Authorization Level) [page 46] for a detailed description of the different authorization
levels possible (M, R, S, E, D, W, *).
The VDSK1 field is used in several authorization objects and is therefore described in detail in
VDSK1 (Organizational Key) [page 47].
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.
Note
The time dependency of infotypes is stored in table T582A (Infotypes CustomerSpecific Settings) in the VALDT field.
A users period of responsibility is represented by all the time intervals for which he or she
has P_ORGIN authorizations.
See also:
Example of Period Determination Using P_ORGIN [page 33]
3.1.19.1
Example of Period Determination Using P_ORGIN
Authorization check using P_ORGIN for:

INFTY = 0014
SUBTY = M120
AUTHC = R
The data available in the Organizational Data infotype (0001):
01.01.2000 31.12.2000:
01.01.2001 31.12.2001:
01.01.2002 31.12.9999:
PERSA = DE01
PERSA = US01
PERSA = DE01
PERSG = 1
PERSG = 1
PERSG = 1
PERSK = DA
PERSK = DA
PERSK = DB
VDSK1 = 42
VDSK1 = 42
VDSK1 = 42
The users authorizations available in the user master record:

INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = DE01
PERSG = 1
PERSK = *
VDSK1 = *
as well as
INFTY = 0015
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
50A
33
SAP Online Help
16.04.2002
PERSK = *
VDSK1 = *
The following authorization checks are performed by the system:
For the period January 1, 2000 December 31, 2000:
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = DE01
PERSG = 1
PERSK = DA
VDSK1 = 42
Due to the first authorization in the user master record, the authorization check is successful. The
period belongs to the period of responsibility.
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = US01
PERSG = 1
PERSK = DA
VDSK1 = 42
The first authorization in the user master record denies access to PERSA = US01, the second
denies access to INFTY = 0014. The authorization check is unsuccessful and the period does not
belong to the period of responsibility.
INFTY = 0014
SUBTY = M120
AUTHC = R
PERSA = DE01
PERSG = 1
PERSK = DB
VDSK1 = 42
Due to the first authorization in the user master record, the authorization check is successful. The
period belongs to the period of responsibility.
Result
In this example, the period of responsibility consists of the periods January 1, 2000 December
31, 2000 and January 1, 2002 December 31, 9999.
3.1.20 P_PERNR (HR: Master Data Personnel Number Check)

Definition
Authorization object that is used to assign users different authorizations for accessing their own
personnel number. These authorizations differ from those defined in users P_ORGIN profiles. If
50A
34
SAP Online Help
16.04.2002
this check is active and the user has been assigned a personnel number in the system, it can
directly override all other checks with the exception of the test procedures. This check does not
take place if the user has not been assigned a personnel number, or if the user accesses a
personnel number other than his or her own.
Note
You can assign a user a personnel number using infotype 0105, subtype 0001 (in
earlier releases using the V_T513A view).
Structure
The P_PERNR authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
AUTHC
Authorization Level
PSIGN
Interpretation of Assigned Authorization
INFTY
Infotype
SUBTY
Subtype

The PSIGN field (Interpretation of Assigned Authorization) can have the following values:
I: include (for additional authorizations)
E: exclude (for authorizations that are to be removed)
Example
The authorization checks for P_ORGIN and P_PERNR are activated in the system. In addition,
there are user assignments for some personnel numbers.
The user in our example is assigned a personnel number and is administrator responsible for the
Basic Pay infotype (0008) of a personnel area (that is, the user has the corresponding P_ORGIN
[page 32] authorization). The employee should also be able to display his or her own data but not
change his or her basic pay, irrespective of the personnel area for which the employee is
responsible. The corresponding authorizations for the P_PERNR authorization object must be set
up as follows:
AUTHC = R, M
PSIGN = I
INFTY = *
SUBTY = *
AUTHC = W, S, D, E
PSIGN = E
INFTY = 0008
SUBTY = *
The first authorization grants the employee read authorization for all infotypes that are stored under
the employees personnel number. The second authorization denies write authorization for all data
records of the Basic Pay infotype (0008) stored under the employees personnel number.
The authorization checks for all other personnel numbers and for write authorizations for all
infotypes (except Basic Pay (0008)) run according to P_ORGIN.
50A
35
SAP Online Help
16.04.2002
Caution
As the following examples illustrate, inconsistent authorizations can be granted:
Example 1:
AUTHC = *
PSIGN = I
INFTY = 0014
SUBTY = M*
AUTHC = W, S, D, E
PSIGN = E
INFTY = 0014
SUBTY = *
The first authorization grants the employee read authorization (AUTHC = R) for the
Recurrent Payments/Deductions infotype (0014), subtype M120, which allows the
employee to access the data stored under his or her personnel number. In this case,
the second authorization is irrelevant.
The first authorization grants the employee write authorization (AUTHC = W) for the
Recurrent Payments/Deductions infotype (0014), subtype B030, which denies the
employee access to the data stored under his or her personnel number. In this case,
the first authorization is irrelevant.
The first authorization grants the employee write authorization for the Recurrent
Payments/Deductions infotype (0014), subtype M120, the second authorization denies
the employee this authorization. The desired system response is unclear from this
example. According to the documentation, the system response is undefined in such
situations. In reality, the authorization check always denies authorization in unclear
situations, that is E is stronger than I and therefore the authorization is not granted.
Example 2:
AUTHC = *
PSIGN = *
INFTY = *
SUBTY = *
This type of authorization is required by superusers with unlimited access, for example.
The above authorization is appropriate if an employee wants to access an infotype.
However, since PSIGN = * and * can be substituted for any value, PSIGN and E can
also be interpreted as I. This can also lead to an undefined situation. In earlier
releases, the authorization was denied on the basis of the rule E is stronger than I.
This meant that superusers with assigned personnel numbers were not able to access
their own personnel number. The programs have since been changed and now * is
interpreted as I and is stronger than E. In other words, * is stronger than E and E is
stronger than I, whereby * is interpreted as I.
Recommendations
As already indicated in Example 1, the combination of different authorizations can
produce a complicated result. We therefore recommend that you avoid combinations
where P_PERNR authorizations can be interpreted differently for the same combination
of AUTHC (Authorization Level), INFTY (Infotype) and SUBTY (Subtype).
Misunderstandings arising from the complex situations described above are not the
most frequent causes of customer inquiries, however. The most frequent cause is the
50A
36
SAP Online Help
16.04.2002
incorrect assumption that authorizations by personnel number affect authorizations for

non-assigned personnel numbers. This is not the case at all.
If you use authorizations by personnel number, you should always first set up all nonpersonnel number-related authorizations. As soon as you have done this, you should
create different access authorizations for the personnel numbers that are assigned to
users using appropriate P_PERNR authorizations. This is always possible since the
P_PERNR authorizations override all other authorizations directly (except test
procedures [page 51]).
P_PERNR authorization checks cannot bypass test procedures directly. For instance, a
test procedure is only carried out on the Recurring Payments/Deductions infotype
(0014) if a corresponding P_PERNR authorization (with PSIGN = I) exists. If an
appropriate authorization for the corresponding subtype of the infotype 0130 exists, it
can be used effectively to carry out the test procedures.
3.1.21 P_ORGXX (HR: Master Data Extended Check)

Definition
Authorization object that is used during the authorization check for HR infotypes. The check takes
place when HR infotypes are edited or read.
Structure
P_ORGXX contains the following fields, which are tested during an authorization check:
Authorization Field
Long Text
INFTY
Infotype
SUBTY
Subtype
AUTHC
Authorization Level
SACHA
Payroll Administrator
SACHP
Master Data Administrator
SACHZ
Time Recording Administrator
SBMOD
Administrator Group
AUTHC (Authorization Level) [page 46] for a detailed description of the different authorization
levels possible (M, R, S, E, D, W, *).
The SACHA, SACHP, SACHZ, and SBMOD 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. A users period of
responsibility is represented by all the time intervals for which he or she has P_ORGXX
authorizations.
See also:
Example of Period Determination Using P_ORGIN [page 33]
3.1.22 P_TCODE (HR: Transaction Code)

Definition
Authorization object that is used to check whether a user is authorized to start the different HR
transactions. The transaction code is checked.
50A
37
SAP Online Help
16.04.2002
Use
The P_TCODE authorization object is not used in all HR transactions. We distinguish between:
HR transactions with natural (own) authorization objects, such as persons (employees,

applicants), statements, or similar.
In transactions of this type, these natural authorization objects (HR: Master Data, HR:
Applicants, and HR: Statements) are used for the check. When a user starts a transaction,
the system uses the same object to check minimum authorizations. For example, a user
must have at least a read authorization to be able to edit employee data, that is R in the
Authorization Level field of the HR: Master Data object.
HR transactions without natural authorization objects, such as processing system settings

(cycles, features) and personnel control records, and so on.
In transactions of this type, differentiated authorization checks do not take place: The
system only checks whether or not the user is authorized to start the transaction. These HR
transactions are protected by the HR: Transaction Codes check object. You can find a list
of these transactions as follows:
a. Choose Tools ABAP Workbench Development Other Tools Transactions.
b. Then choose Utilities Find and finally Edit All Selections.
c.
Enter P* as the transaction code in the Transaction field.
d. Enter the authorization object P_TCODE in the Test Object field.

e. Choose Program Execute.
Structure
The P_TCODE authorization object contains the following field, which is tested during an
Authorization Field
Long Text
TCD
Transaction Code
Integration
You can also use authorizations for the S_TCODE authorization object (Check Transaction Code at
Start of Transaction) to protect the HR transactions. In this context, note that the P_TCODE
authorization object was implemented before the S_TCODE authorization object. The P_TCODE
authorization object was maintained as an additional protection measure given the increased need
for the protection of person-related data.
3.1.23 P_USTR (HR: US Tax Reporter)

Definition
Authorization object that is used during the authorization check for simulation and update runs of
the US Tax Reporter (Transaction PU19).
Use
To carry out simulation or update runs of the US Tax Reporter, you must enter the authorization to
add or create ...(value 01 see below) using the P_USTR authorization object.
Structure
The P_USTR authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
ACTVT
Activity
50A
38
SAP Online Help
16.04.2002
PERSA
Personnel Area
BTRTL
Personnel Subarea
You specify the tax company that you want to perform the authorization check of the US Tax
Reporter for using the fields PERSA and BTRTL.
Enter the activities that you want to assign authorizations for using the ACTVT field. The
01: Add or Create
03: Display
06: Delete
3.1.24 PLOG (Personnel planning)

Definition
Authorization object that is used to check the authorization for specific fields in the Personnel
Management components (Organizational Management, Personnel Development, Training and
Event Management, ...).
Structure
The PLOG authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
PLVAR
Plan Version
OTYPE
Object Type
INFOTYP
Infotype
SUBTYP
Subtype
ISTAT
Planning Status
PPFCODE
Function Code
The PLVAR field specifies which plan version(s) the user is authorized to access.
The OTYPE field specifies which object types the user is authorized to access.
The INFOTYP field specifies which infotypes the user is authorized to access.
The SUBTYP field specifies which subtypes of given infotypes the user is authorized to access.
The ISTAT field specifies the planning status in which the user is authorized to access
information.
The PPFCODE field specifies the processing mode for which the user has authorization (Display,
Change and so on).
Integration
If you use the PLOG authorization object, you must also set up a structural authorization profile for
the user. Users of the Personnel Management components (Organizational Management,
Personnel Development, Training and Event Management, ...) can access data only if they have a
profile for the PLOG authorization object and a structural authorization profile.
50A
39
SAP Online Help
16.04.2002
A structural authorization profile is also necessary if you do not want to limit users access
authorization by the structural authorization check. If this is the case, you must assign the user a
structural profile that grants the user access to the whole structure.
For more information, see Definition of Structural Authorizations [page 12].
3.1.25 S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for

Managers Desktop)
Definition
Authorization object that is used to restrict the actions a user can carry out in the Managers
Desktop application.
Structure
The S_MWB_FCOD authorization object contains the following field, which is tested during an
Authorization Field
Long Text
MWBFCODE
Function Code

The MWBFCODE check field refers to table T77MWBFCD (Function Codes for Managers Desktop).
3.1.26 P_NNNNN (Master Data: Customer-Specific 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 [page 32] and P_ORGXX [page
37] 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
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.
50A
40
SAP Online Help
16.04.2002
Note
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 [page
33].
See also:
Creating a Customer-Specific Authorization Object [page 41]
3.1.27 Creating a Customer-Specific Authorization Object

Procedure
1. To create the authorization object, choose the SU21 transaction.
2. First double-click an object class to select it, for example HR (Human Resources Department).
3. Then choose Create on the following screen (F5). To be able to use the new authorization
object you have created in the master data authorization check, the object must contain the
following fields:
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 provided 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.
4. After you have created the authorization object, start the RPUACG00 [page 109] report. This
report overwrites the MPPAUTZZ standard include with the code that is needed to evaluate the
authorization object you created. Note: Technically speaking, this involves a modification.
However, SAP fully supports this procedure. And you should not have more maintenance work
as a result of this modification. To ensure that the report actually writes the program code,
deselect the Test field. Enter your user as the password.
5. Activate your checks by switching the corresponding authorization main switch NNNNN [page
44] to 1.
See also:
P_NNNNN (HR: Master Data: Customer-Specific Authorization Object) [page 40]
3.1.28 Cross-Application Authorization Objects

See the following for a description of additional authorization objects that are also important for
mySAP HR:
S_TABU_DIS (Table Maintenance (Using Standard Tools)) [page 42]
S_TMS_ACT (TemSe: Actions on TemSe Objects) [page 42]
50A
41
SAP Online Help
16.04.2002
3.1.28.1 S_TABU_DIS (Table Maintenance (Using Standard Tools Such as

SM30))
Definition
Authorization object that is used to check the authorization for displaying and maintaining table
contents. This object controls users access to data only if they access the data using Standard
Table Maintenance (transaction SM31), Extended Table Maintenance (SM30), the Data Browser or
through Customizing.
Use
You can use this authorization object to limit users access authorization so that, for example, users
with authorization for the se16 transaction (for all Data Dictionary objects) can only access data
You can also deny system administrators specific access to application data, for example. As soon
as you have set up this authorization object, you can edit or change only the table entries for which
corresponding authorization has been granted explicitly by S_TABU_DIS.
Structure
The object consists of the following fields:
Authorization Field
Long Text
DICBERCLS
Authorization Group
ACTVT
Activity
The DICBERCLS field contains the authorization for tables by authorization class according
to table TDDAT. Specify the names of the permitted classes in this field. Table classes are
defined in the TBRG table.
The ACTVT field contains the permitted operations. The following values are possible:
02: Change (add, change or delete table entries)
03: Display table contents
3.1.28.2
S_TMS_ACT (TemSe: Actions on TemSe Objects)
Definition
Authorization object that is used to determine who is authorized to perform which operations on
which TemSe Objects (objects with temporary sequential data).
Use
Authorizations using S_TMS_ACT only control direct access. TemSe files are protected from
applications that access their data indirectly, such as the spooler or background request
management, by their own authorization checks.
Structure
The S_TMS_ACT authorization object contains the following fields, which are tested during an
Authorization Field
Long Text
STMSACTION
TemSe: Action ID for Authorizations
STMSOWNER
TemSe: Owner Group for Authorizations
STMSOBJECT
TemSe: Generic Object Name for Authorizations
50A
42
SAP Online Help
16.04.2002
The STMSACTION field is used to define the permitted operations. The following values are
possible:
CRE: Create TemSe object
REA: Read TemSe object
DEL: Delete TemSe object
APP: Append TemSe object
MOD: Modify TemSe object. This currently applies only to attributes as the data of the TemSe
objects cannot be changed in the current version.
The STMSOWNER field is used to define the objects for which a user has authorization. The
OWN: Own TemSe objects
GRP: External TemSe objects in own client
OCL: TemSe objects in external clients
The STMSOBJECT field is used to specify the names of the TemSe objects that are to be tested
during the authorization check.
Notes
TemSe objects have names. The name is specified partly generically (that is with a (*)
at the end).
TemSe objects can have any names. However, naming conventions are used, which
are defined in the TST07 table (Naming Conventions for TemSe Objects). The spooler,
for example, currently uses SPOOLnnnnn, where nnnnn is the spool request number.
3.2 HR: Authorization Main Switches

You can use the authorization main switches stored in table T77S0 (System Table) under the group
name AUTSW to tailor the behavior of the authorization check on HR infotypes to your
requirements. Up to Release 4.5B the switches were stored in the MPPAUTSW include. Storing the
authorization main switches in the T77S0 table is advantageous because the switches can be
defined differently at client level.
Note
For more information on the authorization main switches, see the Implementation
Guide (IMG) for Personnel Administration under Tools Authorization Management
Maintain Profiles.
See also:
AUTSW ORGIN (HR: : Master Data) [page 44]
AUTSW ORGXX (HR: Master Data Extended Check) [page 44]
AUTSW NNNNN (HR: Customer-Specific Authorization Check) [page 44]
AUTSW ADAYS (Tolerance Time for Authorization Check) [page 44]
AUTSW PERNR (HR: Master Data Personnel Number Check) [page 45]
AUTSW APPRO (HR: Test Procedures) [page 45]
AUTSW ORGPD (HR: Structural Authorization Check) [page 45]
50A
43
SAP Online Help
3.2.1
16.04.2002
AUTSW ORGIN (HR: Master Data)
Definition
Authorization main switch that controls whether the P_ORGIN [page 32] authorization object should
be used in the authorization check.
Values
In the standard system, this switch is set to 1. If you want to activate the authorization check, set
the switch to 0.
3.2.2
AUTSW ORGXX (HR: Master Data Extended Check)
Definition
Authorization main switch that controls whether the P_ORGXX [page 37] authorization object
should be used in the authorization check.
Values
the switch to 1.
3.2.3
AUTSW NNNNN (HR: Customer-Specific Authorization

Check)
Definition
Authorization main switch that controls whether a customer-specific authorization object [page 40]
Values
the switch to 1.
Caution
Carry out the steps described in Creating a Customer-Specific Authorization Object
[page 41] before you activate this check. If you fail to do this, the response of the
authorization check is undefined.
3.2.4
AUTSW ADAYS (Tolerance Time for Authorization Check)
Definition
Authorization main switch that is used to specify the tolerance time of the authorization check in the
event of an organizational change. You can use this switch to set up how long an administrator has
access to the data he or she has created as long as this employee already has an organizational
assignment outside his or her own authorization.
Values
Enter the tolerance time of time logic for master data infotypes in calendar days. In the standard
system, this switch is set to 15 (= 15 calendar days). If this switch is active, that is if it contains a
value greater than zero, the organizational changes that cause users to lose authorization are
delayed significantly by the tolerance time.
Example
ADAYS is set to 15. Only checks using P_ORGIN are activated in the system. Administrator A has
write and read authorization for data in personnel area A; administrator B has the same
50A
44
SAP Online Help
16.04.2002
authorizations for personnel area B. In addition, it is assumed that the time dependency of the
authorization check (T582A-VALDT switch) is activated for all infotypes.
A personnel number was assigned to personnel area A until the December 31, 1999. From January
1, 2000, it is assigned to personnel area B. Administrator As period of responsibility finishes on
December 31, 1999 but she has unlimited write and read authorization until January 15, 2000 (up to
and including) because of the tolerance time. From January 16, 2000, administrator A loses write
authorization. She is, however, still authorized to display all the data records that have a validity
date (begin date) before December 31, 1999.
3.2.5
AUTSW PERNR (HR: Master Data Personnel Number

Check)
Definition
Authorization main switch that controls whether the P_PERNR [page 34] authorization object
Values
In the standard system, this switch is set to 1. If you want to deactivate the authorization checks on
the personnel number assigned to a user, set the switch to 0.
3.2.6
AUTSW APPRO (HR: Test Procedures)
Definition
Authorization main switch that controls whether test procedures [page 51] ] should be used.
Test procedures can be used if certain entries are to be checked centrally and should not be
changeable after the check without further action.
Values
In the standard system, this switch is set to 0. If you want to activate the test procedures, set the
switch to 1.
3.2.7
AUTSW ORGPD (HR: Structural Authorization Check)
Definition
Authorization main switch that controls whether the organizational structure should also be included
in the authorization check in Personnel Administration.
Values
In the standard system, the switch is set to 0 .If you want to activate the structural authorization
check, set the switch to 1, 2, 3 or 4.The different switch settings specify how the system should
react to personnel numbers that are not linked to the organizational structure (in other words,
personnel numbers that have position entered as the default position in the Organizational
Assignment infotype (0001)).
For these personnel numbers, you may want to refer to the organizational unit stored in the
Organizational Assignment infotype (0001) for the authorization check (if the organizational unit
exists). If you want to do so, you must set the main switch to 1 or 3, otherwise to 2 or 4.
If the person is assigned the default position and no organizational unit is specified in the
Organizational Assignment infotype (0001), which means that it should not be evaluated, no
authorization check by organizational assignment can take place. In this case, you can specify in
the settings whether the system should grant or deny the authorization by default. If you want to
deny the authorization by default, set the main switch to 1 or 2, otherwise to 3 or 4. The following
combinations are possible for the switch settings:
50A
45
SAP Online Help
16.04.2002
Evaluate Organizational
Unit (if available)
Never Evaluate
Organizational Unit
Deny Authorization by Default
Grant Authorization by Default
3.3 AUTHC (Authorization Level)

Definition
Field in authorization objects, which defines a users access mode (activity).
Use
The AUTHC field is used in the following authorization objects:
P_ORGIN (HR: Master Data) [page 32]
P_ORGXX (HR: Master Data Extended Check) [page 37]
P_PERNR (HR: Master Data Check by Personnel Number) [page 34]
P_NNNNN (HR: Master Data: Customer-Specific Authorization Object) [page 40]
P_PCLX (HR: Clusters) [page 28]
Values
Authorization Level for Accessing Master Data:
The following authorization levels are possible for the P_ORGIN, P_ORGXX, and P_PERNR
authorization objects and for the customer-specific authorization object, P_NNNNN:
R (Read) for read access
M (Matchcode) for read access to entry helps
W (Write) for write access
E (Enqueue) for write access using the Asymmetrical Double Verification Principle. E enables
you to create and change locked records
D (Dequeue) for write access using the Asymmetrical Double Verification Principle. D enables
you to change the lock indicator.
S (Symmetric) for write access using the Symmetric Double Verification Principle
* (all operations). * includes all authorization levels simultaneously, that is it has the same
meaning as R, M, W, E, D and S.
Problems can arise in some programs when write authorizations exist but no read authorizations.
To avoid this, you should always specify R along with the authorization levels W, E, D, and S.
This applies for authorizations with PSIGN = I in the P_PERNR authorization object. In certain
cases, it is appropriate not to enter read authorizations for authorizations with PSIGN = E. This is
not an exception to the rule. PSIGN = E can be used to deny authorizations, which is, of course,
allowed. This can occur, for example, if you have specified an authorization using P_ORGIN and
authorization level *, and then use P_PERNR to determine that the user should be authorized to
display his or her own data but not change the data. In this case, you would specify an
authorization for P_PERNR with AUTHC = W, E, D, S and PSIGN = E.
Authorization Level for Accessing Clusters

The following authorization level specifications are possible for the P_PCLX (HR: Clusters) [page
28] authorization object:
50A
46
SAP Online Help
16.04.2002
R (Read) for read access
U (Update) for write access. This includes the authorizations of authorization level S but not
authorization level R
S (Simulation) to write data to internal buffer but not to database
Integration
You are probably familiar with the ACTVT (Activity) field from other components of the SAP R/3
System, not with the authorization level and wonder why ACTVT is not used in mySAP HR. The
field is not used in mySAP HR because the authorization objects that contain the AUTHC field
(Authorization Level) were already in use before it was decided to switch to the ACTVT field. The
decision up until now has been to continue to use the AUTH field to ensure existing customers
remain compatible in this area and to avoid the adjustment and corresponding implementation that
a switch would involve.
3.4 VDSK1 (Organizational Key)

Definition
Field in authorization objects that is used to run diverse authorization checks by organizational
assignment (using the P_ORGIN [page 32]) 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.
Structure
Controlling the Creation and Validation of the Organizational Key
The VDSK1 feature (Organizational Key) and the T527 (Organizational Key: Control), T527A
(Organizational Key: Rules for Creating Organizational Keys), and T527O (Organizational Key:
Validation) tables control the creation and validation of the organizational key.
A variable key, VARKY, is determined for this purpose using the VDSK1 feature. This key is used
according to the T527 table to determine how the VDSK1 (Organizational Key) should be created or
validated. The OFLAG (Default/Validation) and RULID (Rule for Creating Organizational Keys) fields
are evaluated for this. The OFLAG (Default/Validation) field can have the following specifications:
1: optional entry without validation
2: optional entry with validation
3: required entry with validation
4: default that cannot be overwritten without validation
5: default that can be overwritten without validation
6: default that can be overwritten with validation
7: default that cannot be overwritten with validation
If you make an entry in the OFLAG field (Default/Validation) which causes a default value to be
created (specifications 4, 5, 6 or 7), you must also maintain the RULID field (Rule for Creating
Organizational Key). This entry is then used to determine the corresponding rule for the
organizational key in the T527A table (Organizational Key: Rule for Creating Organizational Key).
If you make an entry in the OFLAG field (Default/Validation) which causes the organizational key to
be validated, you must enter the values that should be recognized by the system as permitted in the
T527O table (Organizational Key Validation).
50A
47
SAP Online Help
16.04.2002
Note
If an entry for OFLAG (Default/Validation) is not permitted (that is, the number is not
between 1-7), the system always responds as if 1 had been entered in the field.
Example
Example of an entry in table T527:
VARKY
TEST
OFLAG
RULID
XY
If the VDSK1 feature returns the TEST key, the organizational key is created according to the entries
in table T527A that belong to XY. In addition, the organizational key is validated against the entries
in table T527O.
Creating the Organizational Key

The T527A table (Organizational Key: Rule for Creating Organizational Keys) controls the creation
of the organizational key.
You can create one or several rows for each rule. The rows are always sorted according to SEQNO
(sequence number). SNAME (Field Name) specifies the field of the Organizational Assignment
infotype (0001) from which data should be included in the organizational key. Using the LNGTH
(Length) and OFFST (Offset) fields, you can also specify that only data from certain places in the
specified fields should be transported. OFFST defines the number of places that should be skipped
(from the left). LNGTH specifies the number of places that should be included. The fields, or parts of
fields, that have been determined for each row are placed after each other in the organizational
key.
Example
Example of entries in table T527A:
RULID
SEQNO
SNAME
LNGTH
OFFST
01
10
P0001-KOSTL
XY
01
P0001-KOSTL
XY
04
P0001-PERNR
XY
05
P0001-KOSTL
ZZ
01
P0001-KOSTL
If the organizational key should be created according to RULID (Rule) 01, the first 5
places of the cost center are always entered in the organizational key, for example,
12345 is entered in the organizational key for cost center 1234567890.
If the organizational key should be created according to RULID (Rule) XY, the first
place is the first number of the cost center, the fourth and fifth places are the fourth and
fifth numbers of the personnel number, and the tenth place is the tenth number of the
cost center. For example, 1450 is entered in the organizational key for cost center
1234567890 and personnel number 12345678.
If the organizational key should be created according to RULID (Rule) ZZ, the last five
places of the cost center are entered in the organizational key. For example, 67890 is
entered in the organizational key for the cost center 1234567890.
Validating the Organizational Key

The T527O table (Organizational Key: Validation) contains a list of the permitted entries for the
VDSK1 field (Organizational Key). Only entries with HIRAR (Hierarchy) = 1 are relevant for
validations. All other entries are ignored when validating the organizational key.
50A
48
SAP Online Help
16.04.2002
The ORGKY column (Organizational Key) contains the organizational key that should be permitted
during the validation. All other columns are irrelevant for the validation.
In the TEXT1 (Short Name) and TEXT2 (Name) columns, you can store a short text or a
description for each organizational key. The texts appear when you press the input help for the
Organizational Key field. The texts are irrelevant for the actual validations.
The NODTY column (Organizational Element) is no longer of significance. The column is still
included in the T527O table for reasons of downward compatibility but is no longer displayed in the
table view.
Example
Example of entries in table T527O:
HIRAR
ORGKY
NODTY
TEXT1
TEXT2
ADM
Adm.
Administration
PRO
Prod.
Production
PRO
Test
Test
TEST
Test
Test
The organizational keys PRO and ADM are permitted organizational keys due to the first
two rows of the table. The entries with the text Test are all irrelevant because they
have an entry unequal to 1 in the HIRAR field. If there are no more entries in the T527O
table, TEST, in particular, is not a permitted organizational key.
3.5 Time Logic

Use
Time Logic is a principle that checks whether access authorizations already exist for a user using
his or her period of responsibility, the validity period of a data record, and the desired access mode
(read or write).
Example
The exact process of the time logic is described in Process of Time Logic [page 70].
3.6 Periods of Responsibility

Use
Checking the period for which an employee has authorizations for an infotype or for a combination
of infotype and subtype is an important element in the authorization check.
Features
Periods of responsibility can be determined:
according to structural authorization profiles and position or organizational unit
according to the structural authorization check
according to organizational assignment
See also:
Process of Determining the Period of Responsibility [page 59]
50A
49
SAP Online Help
16.04.2002
3.7 Control Mechanisms (Double Verification Principle,

Test Procedures, etc)
The following are additional methods you can use to protect especially critical data when you create
or change data.
Asymmetrical Double Verification Principle [page 50]
Symmetrical Double Verification Principle [page 51]
Test Procedures [page 51]
Change Document [page 52]
Recommendation
Note that you can combine the symmetrical and asymmetrical double verification
principles as long as they are used for different infotypes (or different subtypes of an
infotype). It is not advisable to combine the asymmetrical and symmetrical double
verification principles for the same infotype/subtype because the system response is
undefined for this type of combination.
The test procedures and the change document are, in comparison, independent
mechanisms. You can, therefore, use any combination of these mechanisms and in
conjunction with the double verification principle.
3.7.1
Asymmetrical Double Verification Principle
Use
This process controls access to infotypes by stipulating that two users are always required to create
or change infotype data. The users do not have the same authorizations, which is why the process
is called asymmetrical.
Features
The process proceeds as follows:
User A is granted authorizations with the authorization level E (enqueue), R (read) and M
(matchcode) for the P_ORGIN (or P_ORGXX) authorization object instead of complete write
authorizations (authorization level [page 46] W or *). These authorizations allow user B to
create, change or delete locked records only.
User B is granted authorizations with the authorization level D (dequeue), R and M for the
authorization object P_ORGIN (or P_ORGXX) instead of complete write authorizations. These
authorizations allow user B to unlock locked records (or lock unlocked records) only.
Activities
User A enters new data and user B unlocks the new data.
Existing data can be changed in two ways:
User B locks the data, user A changes the data, and user B unlocks the data.
Alternatively, user A creates a locked copy from the unlocked data and changes this copy.
User B then unlocks the data.
To delete unlocked data, user B locks the data which is then deleted by user A
In this process, user A is always responsible for entering and changing data and user B for
approving the changes.
50A
50
SAP Online Help
3.7.2
16.04.2002
Symmetrical Double Verification Principle
Use
This process controls access to infotypes by stipulating that two users are always required to create
or change infotype data. The users have the same authorizations, which is why the process is
called symmetrical.
Features
The process functions as follows:
Both users are granted authorizations with the authorization level S (symmetric), R (read) and M
(matchcode) for the P_ORGIN (or P_ORGXX) authorization object instead of complete write
authorizations (authorization level [page 46] W or *). These authorizations allow each user to
create locked data records, change locked data records, and relock unlocked data records.
In addition, each user can unlock data as long as he or she is not the last person to have
changed the locked data.
Neither user can delete data.
Activities
User A (or user B) creates new data and user B (or user A) unlocks the new data.
To change existing data, user A (or user B) locks and changes the data and user B (or user A)
unlocks the data.
Another user must be consulted to delete existing data.
3.7.3
Test Procedures
Use
You can use the test procedures to create test data for specified infotypes.
Integration
The test procedures are similar to the asymmetrical double verification principle. The difference is
that the entered data is payroll-relevant even if it has not yet been checked. It can, however, only
be changed after a successful authorization check by a user with special authorization.
Features
This control mechanism functions as follows: You can specify a test procedure for the given
infotype (or subtype) in the T584A and V_T584A tables (Test Procedures Infotype Assignment).
For infotypes without subtypes, always specify <BLANK> as the subtype. For infotypes that support
subtypes, you must explicitly specify each subtype to be checked.
When you have made this entry, you can create a data record of the Test Procedures infotype
(0130). The subtype of this data record is the test procedure specified in T584A. This data record
contains the check date amongst other things. As soon as this check date has been entered in the
data record, a user, who is not authorized to change the check date (that is the subtype of the 0130
infotype), cannot make any changes that are before the check date to the infotype to be checked.
Example
In the framework of decentralized time recording, the time administrator records certain absences.
An inspector should check the entered data. Time administrators should not be able to change the
data once it has been checked.
You can set up a test procedure for the attendances and absences that are to be checked in table
T584A. If you want to check all attendances and absences together, it is sufficient to set up one test
procedure that can be used for all subtypes of the Attendances infotype (2002) to be checked. If
you want to check the attendances and absences separately, you need to set up various test
procedures.
50A
51
SAP Online Help
16.04.2002
At first, the time administrators can create and change any data within the scope of their
authorizations. If a tester checks the entered data at a later date, he or she sets the check date for
each personnel number checked in the corresponding subtype of the Test Procedures infotype
(0130) to the date on which he or she finished the checks. This date is normally in the past but it
can also be the current date. It would also be technically possible to have a date in the future but
this makes little business sense.
As soon as the tester has set a check date, the time administrators can only enter data that is after
the check date and within their scope of authorizations. Only time administrators who also have
authorization to change the check date (that is, to change the corresponding subtype of the Test
Procedures infotype), can still change data that is before the check date.
If the tester does not have write authorization for the data to be checked and the time administrator
does not have authorization for the test procedures, data checks and data entry take place
completely separately from each other.
3.7.4
Creation of Infotype Log
Use
If you want or need to protect especially critical data, it may be advisable to activate the change
document for this data. This function logs changes made to infotype records.
Integration
The change document has nothing to do with the authorization check. It does not prevent
unauthorized users from accessing data. Rather it logs attempts made by unauthorized users to
access data. You can evaluate the changes using the RPUAUD00 report (Logged Changes in
Infotype Data).
Note
You can activate the change document in the Implementation Guide (IMG) for
Personnel Management under Personnel Administration Tools Revision Set up
change document. For more information about the change document, see the
documentation on this IMG activity.
Processes and Flowcharts of the Authorization

Check
This section provides you with an overview of the complete process of an authorization check (see
Process of the General Authorization Check [page 53]) and describes the (possible) individual
steps in an authorization check. Each process is also represented graphically.
See also:
Process of the Authorization Check by Personnel Number [page 56]
Process of Determining the Periods of Responsibility [page 59]
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 68]
Process of the Time Logic [page 70]
Process of the Test Procedures [page 74]
Process of Determining the Date After Which Changes Are Permitted for Test Procedures [page 77]
50A
52
SAP Online Help
16.04.2002
4.1 Process of the General Authorization Check

Call Parameters
A user attempts to call an employees 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 [page 49] 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 [page 58]). 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 users period of responsibility is determined
from the organizational structure (see also Flowchart 3 [page 61]). If the defined period of
responsibility is empty, the authorization is denied immediately.
3. The users 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 [page 67]). If
the defined period of responsibility is empty, the authorization is denied immediately.
4. The intersection of both periods of responsibility is determined and is transferred as the period
of responsibility to the time logic [page 49] (see following graphic, Graphic 1):
Graphic 1:
Determining the Period of Responsibility
Period 1
Period 2
Result
50A
53
SAP Online Help
16.04.2002
5. The time logic compares the defined period of responsibility with the validity period of BEGDA to
ENDDA (see also Flowchart 6 [page 73]). 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 [page 76]). 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 [page 55]
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 [page 56]
Process of Determining the Periods of Responsibility [page 59]
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 70]
Process of the Time Logic [page 70]
Process of the Test Procedures [page 74]
Process of Determining the Date After Which Changes Are Permitted for Test Procedures [page 77]
50A
54
SAP Online Help
4.1.1
16.04.2002
Flowchart of the General Authorization Check

Start authorization check
Authorization check by
personnel number
authorized
Flowchart 1:
Process of an Authorization Check
not authorized
still no response
Determine period of responsibility

according to structural authorization check
not authorized
authorized

according to P_ORIGIN, P_ORGXX,
customer-specific authorization object
not authorized
authorized
Determine intersection from period of
responsibility according to structural
authorization check and period of
responsibility according to authorization
objects
Time logic
not authorized
authorized
Test procedures authorization check,

change date = start date of data
record to be checked
End, user is authorized
50A
not authorized
End, user is not authorized
55
SAP Online Help
16.04.2002
4.2 Process of the Authorization Check by Personnel

Number
Use
Within the General Authorization Check [page 6], this process performs an authorization check
based on a personnel number (that is, based on an authorization object P_PERNR [page 34]).
Call Parameters
A user attempts to call an employees 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
PERNR
INFTY
Infotype
SUBTY
Subtype
The BEGDA and ENDDA parameters are not needed as the users current assignment to a
personnel number is always evaluated. As soon as the system recognizes that a personnel
number belongs to a user, the data is differentiated using only the infotype/subtype parameter. A
differentiation based on time does not take place.
Process Flow
The system performs all the following steps of the authorization check:
1. The transaction class is evaluated. If the check is on an applicant number, the check is ended
with the result undecided.
2. The PERNR [page 45] authorization main switch is evaluated. If the switch is deactivated, the
check is ended with the result undecided.
3. The personnel number belonging to the user is determined (in the standard system from the
0105 infotype, subtype 0001, in earlier releases from the T513A table User Values).
4. If the personnel number does not concur with the personnel number to be checked or if no
personnel number is found, the check is ended with the result undecided. (This is why
authorization settings for the P_PERNR authorization object can never affect the authorization
check by personnel number on personnel numbers that are not assigned to the user.)
5. An authorization check is performed for the P_PERNR authorization object:
AUTHORITY-CHECK OBJECT 'P_PERNR'
ID 'AUTHC' FIELD LEVEL
ID 'PSIGN' FIELD '*'
ID 'INFTY' FIELD INFTY
ID 'SUBTY' FIELD SUBTY.
6. If this check is successful (SY-SUBRC = 0), the outcome is authorized.
7. A second authorization check is performed for the P_PERNR authorization object:
ID 'PSIGN' FIELD 'E'
50A
56
SAP Online Help
16.04.2002
8. If this check is successful (SY-SUBRC = 0), the outcome is not authorized.

9. A third authorization check is performed for the P_PERNR authorization object:
ID 'PSIGN' FIELD 'I'
10. If this check is successful (SY-SUBRC = 0), the outcome is authorized.
11. If none of the checks performed were successful, the outcome is undecided.
Note
The check using P_PERNR with PSIGN = * was not carried out in earlier releases.
A user with * authorization for P_PERNR in the PSIGN field is was always denied
access for this reason. This meant, amongst other things, that users with full
authorizations were unable to access their own personnel number during active
authorization checks by personnel number.
Why not, therefore, simply switch the check to PSIGN E or I? A user with E and I
authorization should be able to access and unable to access his or her own personnel
number. Since the system cannot interpret this in a meaningful way, it should deny
the authorization according to the strategy when in doubt, no authorization. This
immediately rules out switching the E and I checks. The additional PSIGN = *
checks were introduced to ensure that users with SAP_ALL authorization always have
the authorization to access their own personnel numbers.
See also:
Flowchart of the Authorization Check by Personnel Number [page 58]
50A
57
SAP Online Help
4.2.1
16.04.2002
Flowchart of the Authorization Check by Personnel

Number
Flowchart 2:
Authorization Check by
Personnel Number
Start authorization check by

personnel number
Personnel number?
no
yes
Main switch PERNR active?
no
yes
Determine personnel numbers belonging
to current user
(from infotype 0105, subtype 0001).
Personnel number
belongs to user?
no
yes
Authorization check using P_PERNR for
transferred combination of AUTHC,
INFTY, SUBTY with PSIGN = *
Authorized?
yes
no
transferred connotation of AUTHC,
INFTY, SUBTY with PSIGN = E
Authorized?
no
yes

transferred connotation of AUTHC,
INFTY, SUBTY with PSIGN = I
yes
Authorized?
nein
End, authorization is unclear
50A
58
SAP Online Help
16.04.2002
4.3 Process of Determining the Periods of

Responsibility
Use
In this process, the periods of responsibility [page 49] for the general authorization check are
determined.
This process includes the following subprocesses:
Process of Determining the Period of Responsibility According to Organizational Structure

[page 59]
Process of Determining the Period of Responsibility According to Structural Authorization

Check [page 62]
Process of Determining the Period of Responsibility According to Organizational Assignment

[page 65]
The authorization check determines an intersection from the periods of responsibility returned by
this process. This intersection is transferred to time logic as the period of responsibility.
See also:
4.3.1
Process of Determining the Period of Responsibility

According to Organizational Structure
Use
Within the General Authorization Check [page 6], this process determines the period of
responsibility according to organizational structure.
Call Parameters
The determination of the period of responsibility is called up using the following parameters:
LEVEL
Authorization Level
TCLAS
PERNR
INFTY
Infotype
SUBTY
Subtype
Process Flow
The system performs all the following steps of this process:
1. The ORGPD [page 45] authorization main switch is evaluated. If the switch is deactivated,
January 1, 1800 to December 31, 9999 is returned as the period of responsibility and the
check is ended.
2. If the current access check is for write access to the Reference Personnel Numbers infotype
(0031), January 1, 1800 to December 31, 9999 is set as the period of responsibility and the
check is ended prematurely. (This situation never occurs for applicant numbers.)
3. The period of responsibility is determined according to the structural authorization profiles (the
T77UA table User Authorizations and the T77PR table - Definition of Authorization Profiles).
4. The default position is determined (T77SO table System Tables, PLOGI PRELI entry). If the
default position cannot be determined (for example, because no entry was found in the T77S0
50A
59
SAP Online Help
16.04.2002
table), it is not possible to perform the comparisons of position and default position listed
below. In this case, the comparisons always return the result is unequal.
5. The organizational assignments of the personnel number are imported (data records of the
Organizational Assignment infotype 0001).
The following steps are carried out for each organizational assignment (data record of
infotype 0001):
If the position and default position do not concur, the organizational assignment is not
evaluated further and the system moves to the next organizational assignment.
If the position and default position concur, the organizational assignment is further
evaluated.
If an organizational unit can be determined from the organizational assignment and if

the evaluation of the organizational unit is desirable (specification 1 or 3 of the
ORGPD [page 45]) authorization main switch), the system checks whether the user is
authorized to access the organizational unit for the validity period of the organizational
assignment according to the structural authorization profiles:
a. If the user is not authorized to access the organizational unit, the organizational
assignment is not evaluated further and the system moves to the next organizational
assignment.
b. If the user is authorized to access the organizational unit, the validity period of the
organizational assignment is added to the period of responsibility.
If no organizational unit can be determined from the organizational assignment or if

the evaluation of the organizational unit is not desirable (specification 2 or 4 of the
ORGPD authorization main switch), the default case occurs:
a. If the authorization should be denied in the default case (specification 1 or 2 of the

ORGPD authorization main switch), the organizational assignment is not evaluated further
and the system moves on to the next organizational assignment.
b. If the authorization should be granted in the default case (specification 3 or 4 of the
ORGPD authorization main switch), the validity period of the organizational assignment is
added to the period of responsibility.
6. When all the organizational assignments of the personnel number have been evaluated, the
period of responsibility is returned.
7. If the period of responsibility is empty, not authorized is returned as the result of the check.
Otherwise, the result is authorized.
Note
The specifications 1 or 2 of the ORGPD authorization main switch always deny
access authorization in the default case, that is if the structural assignment of the
authorization check is impossible. Consequently, a user can no longer access the
personnel numbers affected in this case. Since the organizational structure for users
with unrestricted structural authorization for personnel numbers is not evaluated,
these users can access all personnel numbers. This is due to the fact that the period
of responsibility of these users already had the maximum possible length before the
subsequent evaluation of the organizational assignment.
See also:
Flowchart of Determining the Period of Responsibility According to Organizational Structure [page
61]
50A
60
SAP Online Help
16.04.2002
4.3.1.1
Flowchart of Determining the Period of Responsibility According
to Organizational Structure
Start, determine period of
responsibility acc.to org. structure
Flowchart 3:
Determination of Period of Responsibility
According to Organizational Structure
no
Main switch ORGPD active?

yes
yes
Write access to infotype 0031?

no
for personnel number according to
organizational structure
Set 01.01.1800 to 12.31.9999 as

period of responsibility
Determine default position
Determine organizational
assignments (data records of
infotype 0001)
Loop using the organizational
assignments (data records of
infotype 0001)
no
Position = default position?

yes
Org. unit specifiedt?
yes
no
no
no
Authorized by default?
yes
yes
yes
Add validity period of checked
organizational assignments to
Check on org. unit required?
Authorization
for org.unit according
to org. structure?
no
End, return period of

responsibility
50A
61
SAP Online Help
4.3.2
16.04.2002

According to the Structural Authorization Check
Use
In this process, the system determines the period of responsibility according to the structural
authorization check. This process is described by means of examples.
See Structural profiles [page 10] for detailed information about the structural authorization check.
Note
If you use a combination of general and structural authorization check, an intersection
of the periods of responsibility from the structural authorization check and the
organizational assignment (evaluation of the data from the Organizational Assignment
infotype for the P_ORGIN, P_ORGXX and P_NNNNN authorization objects) is
transferred to the time logic of the general authorization check.
Prerequisites
Assume for all examples that the user has been assigned a structural authorization profile with the
following characteristics using table T77UA (User Authorizations) and table T77PR (Definition of
Authorization Profiles):
The Plan Version field is specified with the active plan version.
The Object Type field is always specified with the ID of the current root object from the current
example.
The Object ID field is specified as 1.
The Evaluation Path field is specified as O-S-P.
The Status Vector field is specified as 12345, which means that all relationships should be
taken into account.
The Depth field is specified as 0, which means that all levels of the structure should always be
evaluated.
The Sign field is not specified, which means that the structure should always be evaluated
from top to bottom.
The Period field is specified (the period is varied in the examples).
The Function Module field is not specified.
Process Flow
The following three examples illustrate the process of period determination in the structural
Example 1: The personnel number is located as follows in an organizational structure:
50A
62
SAP Online Help
16.04.2002
Example 1:
Period Determination for Structural
Authorization
O1
01.01.2000 - 31.12.9999
O2
01.01.1990 - 31.12.2002
01.01.1995 - 31.12.2005
Assume todays date is February 6, 2001.
Example 1a: <BLANK> ( = All) is entered as the period. When evaluating the structure, the
system first follows the relationships and forms intersections. The system starts with the period
January 1, 1900 December 31, 9999. After the first relationship (O1 O2) has been evaluated,
January 1, 2000 December 31, 9999 is initially returned as the period of responsibility. The
second relationship (O2 S) returns January 1, 2000 December 31, 2002 as the period. The
last relationship (S P) covers this period and January 1, .2000 December 31, 2002 remains
the period of responsibility. In other words, the system arrives at the personnel number with a full
period of responsibility. Once this has been successfully checked, the validity period of the last
relationship is always used as the period of responsibility, which would be the period January 1,
1995 December 31, 2005 in this example.
Example 1b: Y ( = current year) is entered as the period. In contrast to example 1a, the system
starts with the period January 1, 2001 December 31, 2001 to determine the period of
responsibility. Since all of the relationships affected cover this period, the period January 1, 2001
December 31, 2001 is still the intersection for personnel number P. The period of responsibility
is then determined, as in example 1a, from the period of responsibility of the last relationship,
which is the period January 1, 1995 December 31, 2005.
Example 2: The personnel number is located as follows in the organizational structure:
50A
63
SAP Online Help
16.04.2002
Example 2:
Period Determination for Structural
Authorization
O1
01.01.2005 31.12.9999
01.01.1995 31.12.9999
O2
01.01.1997 31.12.9999
01.01.1990 31.12.9999
S1
S2
01.01.2001 31.12.2005
S3
01.01.1996 31.12.2000
01.01.2001 31.12.2010

D ( = key date) is entered as the period. The system starts with February 6, 2001 and cannot,
therefore, move from O1 to O2. However, the system can reach P from O1 via S3. Therefore, the
period of the last relationship (S3 P) is used as the period of responsibility, which is January 1,
2001 December 31, 2010 in this example.
Example 3: The personnel number is located as follows in the organizational structure:

Example 3:
Period Determination for
Structural Authorization
01.06.1999 31.12.9999
01.06.2002 31.12.9999
01.01.1999 31.12.1999
01.01.2002 31.12.2002

The following periods of responsibility are determined depending on the settings of the period:
50A
64
SAP Online Help
16.04.2002
Period Setting
Period of Responsibility
<BLANK> ( = all)
01.01.1999 - 31.12.1999 und 01.01.2002 31.12.2002
D ( = key date)
no period
M ( = current month):
no period
Y ( = current year):
no period
P ( = past):
01.01.1999 - 31.12.1999
F ( = future):
01.01.2002 - 31.12.2002
4.3.3

According to Organizational Assignment
Use
Within the General Authorization Check [page 6], this process determines the period of
responsibility according to organizational assignment (based on P_ORGIN; P_ORGXX,
P_NNNNN).
Call Parameters
The determination of the period of responsibility is called up using the following parameters:
LEVEL
Authorization Level
TCLAS
PERNR
INFTY
Infotype
SUBTY
Subtype
Process Flow
1. The organizational assignments of the personnel number are determined (data records of the
Organizational Assignment infotype (0001)).
2. The following steps are carried out for each organizational assignment (data record of infotype
0001):
An authorization check for P_ORGIN [page 32] is performed: If there is no authorization,

the validity period of the organizational assignment does not belong to the users period of
responsibility.
An authorization check for P_ORGXX [page 37] is performed: If there is no authorization,

the validity period of the organizational assignment does not belong to the users period of
responsibility.
An authorization check for the customer-specific authorization object, P_NNNNN [page

40], is performed: If there is no authorization, the validity period of the organizational
assignment does not belong to the users period of responsibility.
3. If all the authorization checks run successfully, the validity period of the organizational
assignment is added to the users period of responsibility.
4. When all the organizational assignments of the personnel number have been evaluated, the
period of responsibility is returned.
5. If the period of responsibility is empty, not authorized is returned as the result. Otherwise, the
result is authorized.
50A
65
SAP Online Help
16.04.2002
Note
For applicant numbers (TCLAS = B), P_APPL [page 26] is checked instead of
P_ORGIN, P_ORGXX, and the customer-specific authorization object P_NNNNN.
See also:
Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 70]
50A
66
SAP Online Help
16.04.2002
4.3.3.1.1 Flowchart of Determining the Period of Responsibility According to

Flowchart 4:
Determination of Period of Responsibility According
to P_ORGIN, P_ORGXX, and the CustomerSpecific Authorization Object, P_NNNNN
Start, determine period of

responsibility according to P_ORGIN,
P_ORGXX, and P_NNNNN
Determine organizational assignments

(data records of infotype 0001)
Loop using the organizational assignments

(data records of infotype 0001)
not authorized
Authorization check using P_ORGIN

authorized
not authorized
Authorization check using P_ORGXX

authorized
Authorization check using customer-specific
authorization object P_NNNNN
not authorized
authorized
Transfer validity period of organizational
assignment to period of responsibility
not authorized
yes
Period of responsibility empty?

no
End, return period of responsibility
50A
67
SAP Online Help
4.3.4
16.04.2002
Process of the Authorization Check Using P_ORGIN,

P_ORGXX and P_NNNNN
Use
Within the General Authorization Check [page 6], this process performs an authorization check
based on the authorization objects P_ORGIN and P_ORGXX or the customers Authorization
Object P_NNNNN.
Call Parameters
A user attempts to call an employees infotype record. As a result, the authorization check is
called using the following parameters:
LEVEL
Authorization Level
P0001
Data Record of the Organizational Assignment Infotype (0001)
INFTY
Infotype
SUBTY
Subtype
Process Flow
1. The ORGIN [page 44] authorization main switch is evaluated.
2. If the main switch is not activated, the authorization check returns authorized immediately.
3. An authorization check takes place on the P_ORGIN [page 32] authorization object:
AUTHORITY-CHECK OBJECT 'P_ORGIN'
ID 'SUBTY' FIELD SUBTY
ID 'PERSA' FIELD P0001-WERKS
ID 'PERSG' FIELD P0001-PERSG
ID 'PERSK' FIELD P0001-PERSK
ID 'VDSK1' FIELD P0001-VDSK1.
a. If this check is successful (SY-SUBRC = 0), the outcome is authorized.
b. If this check is unsuccessful (SY-SUBRC <> 0), the outcome is not authorized.
The check for P_ORGXX [page 37] ] runs analogously. However, the ORGXX [page 44]
authorization main switch is evaluated and then the following check is processed:
AUTHORITY-CHECK OBJECT 'P_ORGXX'
ID 'SACHA' FIELD P0001-SACHA
ID 'SACHP' FIELD P0001-SACHP
ID 'SACHZ' FIELD P0001-SACHZ
ID 'SBMOD' FIELD P0001-SBMOD.
The NNNNN [page 44] authorization main switch is evaluated for the customer-specific
authorization object and then the form routine CHECK_ORGIN_ZZ of the generated MPPAUTZZ
include is processed.
There is no evaluation of an authorization main switch for the P_APPL [page 26] authorization
object (for applicants), since no such switch exists. The reason for this is that applicants do not
50A
68
SAP Online Help
16.04.2002
normally take part in the structural authorization check and consequently, it is not desirable to
switch off the checks of P_APPL. The following check is carried out for P_APPL:
AUTHORITY-CHECK OBJECT 'P_APPL'
ID 'PERSA' FIELD P0001-WERKS
ID 'APGRP' FIELD P0001-PERSG
ID 'APTYP' FIELD P0001-PERSK
ID 'VDSK1' FIELD P0001-VDSK1
ID 'RESRF' FIELD P0001-SACHP.
See also:
Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 70]
50A
69
SAP Online Help
4.3.5
16.04.2002
Flowchart of the Authorization Check Using P_ORGIN,

P_ORGXX and P_NNNNN
Start, authorization check using P_ORGIN (or
P_ORGXX or P_NNNNN)
Flowchart 5:
Authorization Check Using
P_ORGIN or P_ORGXX or
P_NNNNN (Customer-Specific
Object)
Read authorization main switch ORGIN (or

ORGXX or NNNNN)
Main switch active?
no
yes
AUTHORITY-CHECK P_ORGIN (or P_ORGXX

or P_NNNNN) using fields according to
organizational assignment
Authorized?
no
es
4.4 Process of Time Logic

Use
Within the General Authorization check [page 6], this process performs the time logic.
50A
70
SAP Online Help
16.04.2002
Call Parameters
The time logic is called up using the following parameters:
LEVEL
Authorization Level
TCLAS
INFTY
Infotype
BEGDA
Start Date of Infotype Record To Be Checked
ENDDA
End Date of Infotype Record To Be Checked
In addition, the period of responsibility [59] that has already been determined is transferred.
Process Flow
The system performs all the following steps of the time logic.
If the period of responsibility is empty, the time logic returns not authorized.
The time logic determines whether the authorization check should be performed on a datedependent basis (from T582A-VALDT) or not.
If the check should not be performed on a date-dependent basis, the time logic check returns
authorized.
If the check should be performed on a date-dependent basis, the following steps are carried
out:
1. The tolerance time (ADAYS [page 44] authorization main switch) is determined.
2. The check establishes whether the check is for read access (LEVEL = R or M).
If the check is for read access, the following steps are carried out:
a. The end date of the period of responsibility is determined (see also the following graphic,
2: Period Determination for Read Access):
If the current date (SY-DATUM) is not after the end date of the period of
responsibility by more than the tolerance time (ADAYS), the period January 1,
1800 to December 31, 9999 is set as the new period of responsibility.
If the current date is not after the end date of the period of responsibility by more
than the tolerance time, the period January 1, 1800 to end date of the old period
of responsibility is set as the new period of responsibility.
Graphic 2:
Period Determination for Read
Access
Possible Results
01.01.1800
31.12.9999
b. The check establishes whether the validity period BEGDA - ENDDA of the infotype has a
full intersection with the newly defined period of responsibility, that is whether there is at
least one day, which is in both periods:
50A
71
SAP Online Help
16.04.2002
If the intersection is not empty, the time logic check returns authorized.
If the intersection is empty, the time logic check returns not authorized.
If the check is for write access, the following steps are carried out (see also the following
graphic: 3: Period Determination for Write Access):
a. If the first day of the period of responsibility concurs with the first day of the organizational
assignment (BEGDA of the first infotype record of infotype 0001, normally the date of the
initial setting), the period of responsibility is extended to begin on January 1, 1800. (This is
necessary to ensure that users can access dates that are before the initial setting.)
b. If the current date (SY-DATUM) is within the period of responsibility or after the end of a
responsibility interval by no more than the tolerance time (ADAYS), the period January 1,
1800 to December 31, 9999 is set as the new period of responsibility.
Graphic 3:
Period Determination for
Write Authorization
Responsibility intervals
Tolerance Time
Interim Result: The period
of responsibility would be
extended to 01.01.1800
to 12.31.9999 for each
date in the graphic.
01.01.1800
c.
If the current date (SY-DATUM) is outside a responsibility interval and by more than the
tolerance time after the end of each responsibility interval, all responsibility intervals that
are before the current date are deleted.
d. The check establishes whether the validity period BEGDA - ENDDA of the infotype is
completely within the newly defined period of responsibility:
If the validity period is within the period of responsibility, the time logic check
returns authorized.
If the validity period is outside the period of responsibility, the time logic check
returns not authorized.
See also:
Time Logic in Flowchart 6 [page 73].
50A
72
SAP Online Help
16.04.2002
4.4.1 Flowchart of the Time Logic

Flowchart 6:
Process of the Time Logic
Start, time logic
no
Responsible for at least 1 day?

yes
Read switch for date-dependent
check (T582A-VALDT)
Check on date-dependent
basis?
no
ja
Read tolerance time ADAYS
Read access (level R, M)?

Read access
Write access
Determine end date of

If the first day of the period of responsibility

concurs with the first day of the first
organizational assignment, extend the
period of responsibility so that it begins on
01.01.1800
If the current date (SY-DATUM) is not

after the end date by more than the
tolerance time (ADAYS), set
01.01.1800 to 12.31.9999 as the new
If the current date is within a responsibility

interval or is not after a responsibility
interval by more than the tolerance time,
set 01.01.1800 to 12.31.9999 as the new
If the current date (SY-DATUM) is after

the end date by more than the tolerance
time (ADAYS), set 01.01.1800 to end
date as the new period of responsibility
If the current date is not within a

responsibility interval or is after the end of
all responsibility intervals by more than
the tolerance time, delete all responsibility
intervals that are before the current date
Is infotype record to be
checked in period just determined for
at least one day?
Is infotype record to be checked

completely in period just
determined?
no
yes
yes
no
50A
73
SAP Online Help
16.04.2002
4.5 Process of the Test Procedures

Use
Within the General Authorization Check [page 6], this process performs the Test Procedures
[page 51].
Call Parameters
The test procedures check is called up using the following parameters:
LEVEL
Authorization Level
TCLAS
PERNR
Personnel number
INFTY
Infotype
SUBTY
Subtype
BEGDA
Start Date of Infotype Record To Be Checked
Process Flow
The system performs all the following steps of the test procedures check.
The APPRO [page 45] authorization main switch is evaluated If the main switch is not
activated, the authorization check returns authorized immediately.
LEVEL is evaluated. If the check is for read access (authorization level R or. M), the
authorization check returns authorized immediately.
The check establishes which object the user should be authorized to access:
If the check is for access to an applicant number or to the Organizational Assignment
infotype (0001), the authorization check returns authorized immediately.
If the check is for access to the Test Procedures infotype (0130), the following steps are
carried out:
The date after which changes are permitted is determined. This date is taken as the
maximum.
If the check is for access to one of the different Test Procedures infotypes, the following
steps are carried out:
All the test procedures that are relevant for the infotype (from the T584A table (Test
Procedures Infotype Assignment)) are determined:
If no test procedures are found, the authorization check returns authorized

immediately.
If test procedures are found, the date after which changes are permitted is determined
for each test procedure (that is, for each subtype of infotype 0130). See also
Flowchart 8 [page 79]):
1. The maximum of the dates that have just been defined is determined.
2. The authorization check then establishes whether the start date of the infotype record
(BEGDA) is after the maximum determined by the system in the previous step:
If the date is after the maximum, the authorization check returns authorized.
If the date is before the maximum, the authorization check returns not authorized.
50A
74
SAP Online Help
16.04.2002
Notes
Applicant numbers are excluded from the test procedures for the following reason:
The test procedures were developed for decentralized entry scenarios such as
decentralized time evaluation where users evaluate time data outside the HR
department. The HR department is only involved in checking the data. In this
scenario, the test procedures should prevent other users from being able to change
data outside the HR department after it has already been checked. Since applicant
data is generally not changed outside of the HR department, such scenarios do not
normally occur and are therefore not supported.
Similar arguments could be put forward for the exclusion of the Organizational
Assignment infotype (0001) from the Test Procedures. The real reason for excluding
this infotype is the special function that it has in the authorization check. Since the
Organizational Assignment infotype (0001) controls the periods of responsibility for
other infotypes and in particular for the Test Procedures infotype (0130), test
procedures on the 0001 infotype often cause complications in the authorization check.
The 0001 infotype has therefore been excluded intentionally from the test procedures
to avoid this.
See also:
The process flow of the test procedures in Flowchart 7 [page 76].
Process of Determining the Date After Which Changes Are Permitted for Test Procedures [page
77].
50A
75
SAP Online Help
4.5.1
16.04.2002
Flowchart of the Test Procedures

Start test procedure
no
Flowchart 7:
Process of the Test Procedures
Main switch APPRO active?

ja
no
Write access to personnel

number and infotype
<> 0001?
yes
Infotype = 0130?
no
Determine all test procedures
relevant for infotype
(stored in T584A)
yes
no
Test procedure found?

yes
Determine date after which
changes are permitted for each
relevant test procedure
(that is, subtypes of infotype 0130)
Determine date after which changes

are permitted
Determine maximum of dates

just determined
Transfer date just determined

as maximum
Is change date after maximum just

determined?
no
ja
50A
76
SAP Online Help
16.04.2002
4.6 Process of Determining the Date After Which Changes

Are Permitted for Test Procedures
Use
Within the General Authorization Check [page 6], this process determines the date after which
changes are permitted for the Test Procedures [page 51].
Call Parameters
The system transfers the following parameters to determine the date after which changes are
permitted:
PERNR
Personnel Number
CKTYP
Test Procedures = Subtype of Test Procedures Infotype (0130)
Process Flow
The system performs all the following steps of this process.
The check date (RELDT) of the specified test procedure (data record of the subtype defined by CKTYP
of the Test Procedures infotype (0130)) is imported:
If no date is found, every change made as of January 10, 1800 (up to and including) is permitted,
that is, December 31, 1799 is taken as the date and processing is stopped at this point.
If a date is found, the following steps are carried out:

A personnel number check (with LEVEL = W, SUBTY = CKTYP) is performed for the test
procedure (CKTYP) for the Test Procedures infotype (0130):
a. If the check returns authorized, every change made as of January 1, 1800 (up to and
including) is permitted and processing is stopped at this point.
b. If the check returns not authorized, only changes after the check date are permitted and
processing is stopped at this point.
c.
If the check returns authorization unclear, processing continues:
The period of responsibility (for write access) is determined according to the

structural authorization check.
The period of responsibility (for the corresponding subtype of infotype 0130,

authorization level W) is determined according to P_ORGIN, P_ORGXX and the
customer-specific authorization object, P_NNNNN.
The intersection of both periods of responsibility is determined and used as the

period of responsibility:
If the current date (SY-DATUM) and the check date (P0130-RELDT) are not after the end
of the period of responsibility, each change made as of January 1, 1800 (up to and
including) is permitted.
If the current date or the check date are after the end of the period of responsibility, only
changes after the check date (P0130-RELDT) are permitted.
The time logic for test procedures appears at first to function differently to the general time logic of
authorization checks. However, both follow the exact same process. The only difference is that when
you use test procedures, you already know that the check only returns authorization for write access
and that the data records of the 0130 infotype are always valid from January 1, 1800 to December 31,
9999. The time logic for test procedures is as follows:
If a user has write authorization for all subtypes of the Test Procedures infotype (0130), he or she
can change the check date for each test procedure and is, therefore, permitted to make changes
to other infotypes independent of the test procedures.
50A
77
SAP Online Help
16.04.2002
If the user has no write authorization for a subtype of the Test Procedures infotype (0130), he or
she cannot change the check date. The user is, therefore, only permitted to make changes that
are after the check date to the infotypes tested by this test procedure.
The general authorization check is always used to determine the date regardless of whether or
not the user has write authorization for a subtype of the Test Procedures infotype (0130).
See also:
See Flowchart 7 [page 76] for a graphical representation of the test procedures and Flowchart 8
[page 79] for a graphic of how the date after which changes are permitted is determined.
50A
78
SAP Online Help
4.6.1
16.04.2002
Flowchart of Determining the Date After Which Changes

Are Permitted for Test Procedures
Flowchart 8:
Determination of Date After Which
Changes Are Permitted
Start, determination of date after which

changes are permitted
Read check date of test procedure (that

is, of corresponding subtype of the 0130
infotype)
yes
No date found?
no
authorized
Authorization check by personnel

number
not authorized
still no response
according to structural authorization check
not authorized
authorized
Determine periods of responsibility
according to P_ORGIN, P_ORGXX,
P_NNNNN (customer-specific authorization
object)
not authorized
authorized
Determine intersection from period of
responsibility according to structural
authorization check and the period of
responsibility according to the
authorization objects
Intersection full
Determine the end date of period of
responsibility (that is, the intersection just
determined). Determine the maximum from the
check date and the current date (SY-DATUM)
yes
Is the end date not before the

maximum?
no
End, any change made as of

01.01.1800 (up to and including)
is permitted
End, any change made after

check date is permitted
50A
79
SAP Online Help
16.04.2002
Interaction of General and Structural

Authorizations
If you use both structural and general authorizations, a users overall profile is determined from the
intersection of his or her structural and general authorization profiles.
The structural profile determines which object in the organizational structure the user has access to.
The general profile determines which object data (infotype, subtype) and which access mode (Read,
Write, ...) the user has for those objects.
Struktural
Authorization Profiles
Authorization Profiles Using

HR Authorization Objects
Example
An overall profile could be put together as follows:
Overall Profile
Struktural
Profile
O1
S1
P1
SN
PN
Profile with
P_ORGIN
INFOTYP:
SUBTY:
AUTHC:
PERSA:
PERSG:
PERSK:
...
Profil 1 with PLOG
0-7
*
R,M
*
*
*
OTYPE:
INFOTYP:
ISTAT:
PLVAR:
PFCODE:
SUBTYP:
S
1000-1010
*
01
DISP
*
Profile 2 with PLOG

OTYPE:
INFOTYP:
ISTAT:
PLVAR:
PFCODE:
SUBTYP:
P
*
*
01
*
*
The following authorizations or restrictions apply to a user who has the overall profile illustrated
above:
50A
80
SAP Online Help
16.04.2002
The user has read authorization for positions S1 to SN in infotypes 1000 to 1010 (structural
profile and 1/PLOG profile).
The user is not authorized to access organizational units with this profile since the user has no
corresponding PLOG authorization.
The user has read authorization for persons P1 to PN in infotypes 0000 to 0007. (Structural
Profile and Profile/P_ORGIN). The period of responsibility for persons is determined in
accordance with the period of responsibility according to structural authorization. See
Determining the Period of Responsibility According to Structural Authorization [page 62].
For the user to be able to access data on persons, you need to assign the user a corresponding
PLOG authorization for persons. The infotype does not have to be specified. (Profile 2/PLOG)
Examples
These examples are intentionally simple. See the explanations of the individual authorization objects
and authorization checks for details on why these examples work.
See also:
Example: Employee Self-Service [page 81]
Example: Administrator Should Not Be Allowed to Edit Own Data [page 82]
Example: Administrator Should Not Be Allowed to Enter Data Alone [page 82]
Example: Decentralized Time Recording [page 83]
Example: Telephone List [page 84]
Example: Payroll [page 84]
Example: Transaction-Dependent Authorizations [page 84]
Example: Structural Authorization Profiles [page 85]
6.1 Example: Employee Self-Service

Requirement
Employees should be able to change their own address (infotype 0006) using SAP Employee SelfService. What is more, each employee should be authorized to access all master data stored under
his or her personnel number. Employees who are not HR administrators should not be able to access
other employees data under any circumstances.
Realization
At least one of the authorization main switches [page 43] (except for P_PERNR) must be active
to be able to prevent users access to other personnel numbers. Assume for this example that the
AUTSW ORGIN main switch is the only active main switch.
The AUTSW PERNR [page 45] main switch must be activated for the authorization check by
personnel number to take place.
The user assignment for all employees who use the SAP Employee Self-Service must be
maintained in infotype 0105.
Users who are not administrators should not be granted P_ORGIN authorizations. This means
that these users have no access authorization to HR master data for the time being.
Every employee who uses the SAP Employee Self-Service is granted the following two
authorizations for the P_PERNR [page 34] authorization object:
AUTHC = R, M
50A
81
SAP Online Help
16.04.2002
PSIGN = I
INFTY = *
SUBTY = *
and
AUTHC = *
PSIGN = I
INFTY = 0006
SUBTY = *
6.2 Example: Administrator Should Not Be Allowed to

Edit Own Data
Requirement
An administrator should not be able to edit his or her own salary or other salary-relevant data stored
under his or her own personnel number. For this reason, you want to deny all administrators who may
have access to their own personnel number write access to their own personnel number.
Realization
The AUTSW PERNR [page 45] main switch must be activated for the authorization check by
personnel number to take place.
The user assignment for the corresponding administrator must be maintained in infotype 0105.
Each employee affected is granted the following P_PERNR [page 34] authorization:
AUTHC = W, S, D, E
PSIGN = E
INFTY = *
SUBTY = *
6.3 Example: Administrator Should Not Be Allowed to

Enter Data Alone
Requirement
You want to ensure that the Additional Payments infotype (0015) can only be edited by two
administrators together. To achieve this, you want to set up the asymmetrical double verification
principle [page 50] where one of the administrators is responsible for recording the data and the other
administrator for controlling the process. For the sake of simplicity, assume that only the AUTSW
ORGIN [page 44] main switch is activated.
Realization
The time administrator requires the following authorization for the P_ORGIN [page 32]
authorization object:
INFTY = 0015
SUBTY = *
AUTHC = R, M, E
PERSA = *
50A
82
SAP Online Help
16.04.2002
PERSG = *
PERSK = *
VDSK1 = *
The time administrator requires the following authorization for the P_ORGIN authorization object:
INFTY = 0015
SUBTY = *
AUTHC = R, M, D
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
6.4 Example: Decentralized Time Recording

Requirement
You record working time decentrally. Once the time data has been recorded decentrally, it is checked
centrally. The time administrators should not be able to change data that has been checked. The
central time administrators, however, should still be able to change the data.
Realization
Activate the Test Procedures (AUTSW ORGIN [page 44]) authorization main switch) in addition to
the authorization checks using P_ORGIN (AUTSW APPRO [page 45] authorization main switch).
Create an entry in the T584A table (Test Procedures Infotype Assignment) for all time
management infotypes and subtypes. You can use one test procedure for all infotypes. You can
also use a different test procedure for each subtype or the same test procedure for several
subtypes only. The decision depends on whether the subtypes should each be checked together
or separately.
The time administrators need the following authorization for the P_ORGIN [page 32] authorization
object:
INFTY = 2*
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
The time administrators need the following authorization for the P_ORGIN authorization object:
INFTY = 0130
SUBTY = *
AUTHC = *
PERSA = *
PERSG = *
PERSK = *
VDSK1 = *
50A
83
SAP Online Help
16.04.2002
Note
If you have different time administrators for different test procedures, you must list each
test procedure instead of * in the SUBTY field.
The time administrators who should also be able to change time data need an additional
write authorization.
6.5 Example: Telephone List

Requirement
You want all system users to have unrestricted access to the ZTELEFON telephone list report, which
is based on the SAPDBPNP logical database.
Realization
Assign all users the following authorization for the P_ABAP [page 30] authorization object.
REPID = ZTELEFON
COARS = *
6.6 Example: Payroll

Requirement
You want to achieve the best possible performance of Payroll.
Realization
Assign the payroll administrator full authorization for the activated checks.
In addition, assign the payroll administrator full authorization for the P_ABAP [page 30]
6.7 Example: Transaction-Dependent Authorizations

Requirement
You want to ensure that certain authorizations are only granted when specific transactions are used.
In other words, you want to include the SY-TCODE field in the authorization check.
Realization
Create a customer-specific authorization object that contains the TCD field.
Use this authorization object instead of the standard objects, that is deactivate the AUTSW
ORGIN [page 44] and the AUTSW ORGXX [page 44] authorization main switches and activate
the AUTSW NNNNN [page 44] authorization main switch.
See also:
50A
84
SAP Online Help
16.04.2002
6.8 Example: Structural Authorization Profiles

Example 1
Field
Values
Plan Version
01
Authorization:
Due to the users authorization profile, he or she is authorized to access plan version 01.
Example 2
Field
Values
Plan Version
01
Object Type
O (Organizational Unit)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in plan
version 01.
Example 3
Field
Values
Plan Version
01
Object type
Object ID
Organizational Unit ID
Evaluation Path
ORGEH (Organizational
Structure)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in plan
version 01 from a root object (entry in the Object ID field) along the Organizational Structure
evaluation path.
Example 4
Field
Values
Plan Version
01
Object Type
Object ID
Organizational Unit ID
Evaluation Path
ORGEH (Organizational
Structure)
Period
D (current day)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in the
structure that is valid on the current day in plan version 01.
Example 5
Field
Values
Plan Version
01
50A
85
SAP Online Help
16.04.2002
Object Type
Object ID
0 = no restriction
Evaluation Path
SBESX (Staffing Assignments

Along Organizational Structure)
Function Module
RH_GET_MANAGER_ASSIGNM
ENT
Authorization:
Due to the users authorization profile, he or she is authorized to access objects along the Staffing
Assignments Along Organizational Structure evaluation path from a root object in plan version 01.
The root object is determined in this case using the function module, that is no entry should be made
in the Object ID field.
The user is then granted access authorization to the organizational unit he or she manages and to all
lower-level objects along the SBESX evaluation path.
See also:
Definition of Structural Authorizations [page 12]
Customer Enhancements
This section presents the possible customer enhancements for authorization checks using Business
Add-Ins in mySAP HR.
See also:
HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks) [page 86]
HRBAS00_STRUAUTH (BAdI: Structural Authorization) [page 97]
7.1 HRPAD00AUTH_CHECK (BAdI: Customer-Specific

Authorization Checks)
Definition
Business Add-In (BAdI) that you can use to replace the SAP standard authorization check with a
customer-specific authorization check for HR master data and infotypes.
Use
If your requirements of the authorization check for HR Master Data infotypes cannot be met by either
the standard system or by a customer-specific authorization object, you can replace the authorization
checks completely without modification (as of Release 4.6C). For this, you use Business Add-Ins
(BAdI). The BAdI for the master data authorization check is called HRPAD00AUTH_CHECK.
Notes
You can find the Business Add-In (BAdI) in the IMG for Personnel Management under
Personnel Administration Tools Authorization Management BAdI: Set Up
Customer-Specific Authorization Check. You can find information on implementing a
BAdI in the documentation of the corresponding IMG activity.
As soon as an implementation for this BAdI is active, all HR master data authorization
checks are stopped and instead only the activated implementation is performed.
You can implement this BAdI using the SE19 transaction.
50A
86
SAP Online Help
16.04.2002
In this context, note that access to documentation in this transaction does not work
properly sometimes. If this is the case, you can access the documentation using the
SE18 transaction and the corresponding BAdI (here: HRPAD00AUTH_CHECK) or using
the SE24 transaction and the corresponding interface (here:
IF_EX_HRPAD00AUTH_CHECK): Double-click an interface name to leave transaction
SE18 or SE19 and go to transaction SE24 where you can access the documentation of
each method.
In order to accommodate the numerous requirements of the authorization check, the
IF_EX_HRPAD00AUTH_CHECK is kept relatively open. The following methods are available and
must all be implemented:
CHECK_MAX_INFTY_AUTHORIZATION
CHECK_MAX_LEVEL_AUTHORIZATION
CHECK_MAX_SUBTY_AUTHORIZATION
CHECK_MIN_INFTY_AUTHORIZATION
CHECK_MIN_LEVEL_AUTHORIZATION
CHECK_MIN_SUBTY_AUTHORIZATION
SET_ORG_ASSIGNMENT
SET_PARTIAL_ORG_ASSIGNMENT
CHECK_AUTHORIZATION
CHECK_MAX_PERNR_AUTHORIZATION
CHECK_MIN_PERNR_AUTHORIZATION
CHECK_PERNR_AUTHORIZATION
DELAYED_CONSTRUCTOR
Recommendation
If you want to make only one change to a specific subfunction of the standard
authorization check (for example, a change to the time logic), simply copy the
CL_HRPAD00AUTH_CHECK_STD class used in the standard system, adjust the
(customer-specific) copy to your requirements, and then activate the copy as a BAdI (see
also example [page 91]). It is not advisable to adjust only the CHECK_AUTHORIZATION
method for this. This may be sufficient in certain cases but often this kind of adjustment
automatically requires changes to be made to the other methods.
Structure
This section explains the role played by the various methods of the IF_EX_HRPAD00AUTH_CHECK
interface during the authorization check. The method interfaces are stored in the system as
documentation of the corresponding methods. Review the method documentation of the
corresponding method if you are implementing a new method or changing method.
CHECK_AUTHORIZATION
This method is the central method of the authorization check on HR Master Data infotypes.
The CHECK_AUTHORIZATION method is processed during each authorization check at
single record level.
During implementation, ensure that this method is also processed when you perform hiring
actions. In particular cases, there are no data records available in the database for the
50A
87
SAP Online Help
16.04.2002
Actions (0000) and Organizational Assignment (0001) infotypes at the point when the method
is processed.
Also ensure that the correct interaction with the ..._ORG_ASSIGNMENT methods is achieved
during implementation.
SET_ORG_ASSIGNMENT
This method is called by applications that have already read all the data records of the
Organizational Assignment (0001) infotype and want to prevent this data from being read
again in the authorization check. This method should be used for performance tuning only.
SET_PARTIAL_ORG_ASSIGNMENT
Since the organizational assignment is only partly known during hiring actions, a normal
authorization check is not possible as the data required for this check is not yet available in
the system. To enable at least a rough check to be carried out, the application transfers the
currently known fields of the Organizational Assignment infotype (0001) to the authorization
check using this method.
CHECK_MAX_LEVEL_AUTHORIZATION
This method is called by applications that want to know if a user has maximum authorization
for an authorization level. In other words, if the user can access all infotypes and all
personnel numbers for the authorization level specified.
If this method returns the result IS_AUTHORIZED = TRUE, the calling applications do not
normally perform any more authorization checks. If this method returns the result
IS_AUTHORIZED = FALSE, the calling applications normally perform more specific
authorization checks.
The aim of this method call is performance tuning, that is the method should return a rough
result as quickly as possible. Apart from the performance point of view, it is unproblematic
from an authorization perspective if the method always returns IS_AUTHORIZED = FALSE
because the relevant applicants then perform additional checks. It can become critical, in
comparison, if the method delivers IS_AUTHORIZED = TRUE for users with insufficient
authorization because the system grants access without any additional authorization checks.
It is therefore particularly important that this method either is implemented in accordance with
the CHECK_AUTHORIZATION method or always returns IS_AUTHORIZED = FALSE.
What is more, the applications that call these methods assume that the response time is well
under a second. Implementations that check the authorizations of all personnel numbers in
the system are therefore especially inappropriate at this point.
CHECK_MAX_INFTY_AUTHORIZATION
This method is similar to the CHECK_MAX_LEVEL_AUTHORIZATION method. The only
difference is that it determines whether a user has maximum authorization for a given
infotype and a given authorization level. The remarks on the
CHECK_MAX_LEVEL_AUTHORIZATION are also valid here.
CHECK_MAX_SUBTY_AUTHORIZATION
The same applies for this method as for the CHECK_MAX_INFTY_AUTHORIZATION
method except that this method determines whether a user has maximum authorization for
the subtype of a given infotype and a given authorization level.
CHECK_MIN_LEVEL_AUTHORIZATION
This method is called by applications that want to determine whether a user has minimum
authorization for an authorization level. In other words, if the user can access at least one
(not necessarily existing) data record of an infotype for a personnel number for the
authorization level specified.
If this method returns the result IS_AUTHORIZED = FALSE, the calling applications do not
normally perform any more authorization checks.
The aim of this method call is to prevent users from accessing data as early as possible. In
other words, instead of being denied access to every function he or she performs, a user
50A
88
SAP Online Help
16.04.2002
should not be able to start the relevant transaction in the first place. As with checks for
maximum authorization, the check only needs to return a rough system response as quickly
as possible. Apart from performance and accessibility points of view, it is unproblematic from
an authorization perspective if the method always returns IS_AUTHORIZED = TRUE
because the relevant applicants then perform additional checks anyway. It is problematic if
the method returns IS_AUTHORIZED = FALSE for users who have appropriate
authorizations because the system denies access in the foreground. It is therefore particularly
important that you implement this method in accordance with the CHECK_AUTHORIZATION
method or that it always returns IS_AUTHORIZED = TRUE.
What is more, the applications that call these methods assume that the response time is well
under a second. Implementations that search this long for a data record of a personnel
number for which authorization exists are, therefore, particularly inappropriate at this point.
CHECK_MIN_INFTY_AUTHORIZATION
This method is similar to the CHECK_MIN_LEVEL_AUTHORIZATION method. The only
difference is that it determines whether a user has minimum authorization for a given infotype
and a given authorization level. The remarks on the CHECK_MIN_LEVEL_AUTHORIZATION
method are also valid here.
CHECK_MIN_SUBTY_AUTHORIZATION
The same applies for this method as for the CHECK_MIN_INFTY_AUTHORIZATION method
except that this method determines whether a user has minimum authorization for the
subtype of a given infotype and a given authorization level.
CHECK_PERNR_AUTHORIZATION
This method is called by applications outside HR master data that want to check if a user
should be granted access to a specific personnel number. This is problematic from a master
data point of view because the personnel number as such is not stored in HR master data as
an object. Master data management recognizes only infotypes. For this reason, the logic of a
check on the access authorization for a personnel number is unclear from a master data
perspective. Therefore, the standard system checks the authorization for the dummy infotype
<BLANK> if you use this method.
Instead of this method, some applications call one of the following methods:
CHECK_MAX_PERNR_AUTHORIZATION
This method is called by applications that want to determine whether access
authorization exists for all the infotypes/subtypes of a specified personnel number, that is
whether a full authorization for access to all data of a personnel number exists. The
standard system implements the check by specifying * in the INFTY and SUBTY fields for
the AUTHORITY-CHECK statement. The system does not check if users can access
each existing infotype but if users could access all conceivable infotypes (even if these
infotypes do not exist in the system).
CHECK_MIN_PERNR_AUTHORIZATION
This method is called by applications that want to determine whether access
authorization exists for one data record of the specified personnel number, that is
whether a minimum authorization for access to at least one data record of the personnel
number exists. The standard system implements the check by specifying DUMMY in the
INFTY and SUBTY fields for the AUTHORITY-CHECK statement. The system does not
check if users can access an existing infotype but if users could access any conceivable
infotype (even if this infotype does not exist in the system).
DELAYED_CONSTRUCTOR
The BAdI function does not allow the Constructor to be specified in the interface. The
DELAYED_CONSTRUCTOR method is used in the interface for this reason. The method is
always processed directly after the constructor. The method interface enables you to obtain
information about the environment of instance creation.
50A
89
SAP Online Help
16.04.2002
The parameters of this method are the result of very specific customer requirements that
were taken into account when the interface was developed. It is only meaningful in certain
special cases to evaluate these parameters. It is therefore advisable not to implement this
method in most cases and instead to use the normal constructor.
See also:
Examples of the HRPAD00AUTH_CHECK BAdI [page 90]
Example of the Implementation of HRPAD00AUTH_CHECK [page 91]
7.1.1
Examples of the HRPAD00AUTH_CHECK BAdI
The following examples are intentionally simple because a description of the complete, new
implementation of the HRPAD00AUTH_CHECK BAdI (Business Add-In) would be beyond the scope
of this documentation.
1. You have implemented the CHECK_... methods to return IS_AUTHORIZED = TRUE each time.
This means that all authorization checks on HR master data are always positive and
consequently, that all users can access all infotypes of all personnel numbers.
2. You have implemented the CHECK_... methods to return IS_AUTHORIZED = FALSE each time.
This means that all authorization checks on HR master data are always negative and
consequently, that no users can access any infotypes of any personnel numbers. However in
Reporting, users who have P_ABAP authorizations with simplification degree COARS = 2 would
be able to access infotypes because no authorization check takes place in this case.
3. You have activated the CL_HRPAD00AUTH_CHECK_STD class delivered in the standard
system as BAdI. The authorization checks behave in dialog as expected. In Reporting, the
authorization check would not, however, be simplified for reports for which a P_ABAP
authorization with COARS = 1 is stored. The reason for this is that the standard system uses two
classes for the authorization check:
CL_HRPAD00AUTH_CHECK_STD and CL_HRPAD00AUTH_CHECK_FAST. If no BAdI is
active, the second class is used for COARS = 1. If a BAdI is active, the system only checks
the authorization with COARS = 2.
4. You have implemented a class that carries out an authorization check in the constructor for SYCPROG and COARS = 1 and that delegates all method calls to the
CL_HRPAD00AUTH_CHECK_STD class if no authorization exists. If authorization exists, it
delegates all method calls to the CL_HRPAD00AUTH_CHECK_FAST class. In this case the
authorization checks would behave identically in dialog and in Reporting. When input helps are
processed, the authorization check normally processes the methods of the
CL_HRPAD00AUTH_CHECK_FAST class instead of the CL_HRPAD00AUTH_CHECK_STD
class for reports with COARS = 1.
5. You have requirements that cannot be met using the standard time logic and therefore want to
implement the following time logic in your system: The user who is responsible for a personnel
number on the current day, should be authorized to access all data on that personnel number.
Other users who are not responsible for this personnel number should not be authorized to
access any data. In addition, the test procedures used up to now should continue to function as
before. You do not use P_ABAP authorizations with COARS = 1 in your system:
The above-mentioned checks are in principle already contained in the
CL_HRPAD00AUTH_CHECK_STD class. You need only adjust the time logic. You do not
want to create a copy of the class and implement this copy because you want to use the
class to implement a complete customer-specific authorization check in your system. This
means that all corrections delivered by SAP would need to be integrated manually. Since the
CL_HRPAD00AUTH_CHECK_STD class already reacts correctly to all write accesses and
also to all read accesses on the current date, you continue to delegate your own checks to
this class. However, change the date each time beforehand to ensure the system returns the
desired result. Note the following diagram and the Example: Implementation of
HRPAD00AUTH_CHECK [page 91]:
50A
90
SAP Online Help
16.04.2002
IF_EX_HRPAD00AUTH_CHECK
CL_CUSTOMER_AUTH_CHECK
CL_HRPAD00AUTH_CHECK_STD
7.1.2
Example of the Implementation of HRPAD00AUTH_CHECK
PRIVATE SECTION.
DATA a_auth_check TYPE REF TO if_ex_hrpad00auth_check.
METHOD if_ex_hrpad00auth_check~check_max_infty_authorization.
CALL METHOD a_auth_check->check_max_infty_authorization
EXPORTING
level
= level
tclas
= tclas
infty
= infty
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
internal_error = 1
invalid
= 2.
CASE sy-subrc.
WHEN 1.
RAISE internal_error.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_level_authorization.
CALL METHOD a_auth_check->check_max_level_authorization
EXPORTING
level
= level
tclas
= tclas
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
50A
91
SAP Online Help
16.04.2002
internal_error = 1
invalid
= 2.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_subty_authorization.
CALL METHOD a_auth_check->check_max_subty_authorization
EXPORTING
level
= level
tclas
= tclas
infty
= infty
subty
= subty
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_infty_authorization.
CALL METHOD a_auth_check->check_min_infty_authorization
EXPORTING
level
= level
tclas
= tclas
infty
= infty
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
internal_error = 1
invalid
= 2.
50A
92
SAP Online Help
16.04.2002
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_level_authorization.
CALL METHOD a_auth_check->check_min_level_authorization
EXPORTING
level
= level
tclas
= tclas
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
internal_error = 1
invalid
= 2.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_subty_authorization.
CALL METHOD a_auth_check->check_min_subty_authorization
EXPORTING
level
= level
tclas
= tclas
infty
= infty
subty
= subty
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
50A
93
SAP Online Help
16.04.2002
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~set_org_assignment.
CALL METHOD a_auth_check->set_org_assignment
EXPORTING
tclas
= tclas
p0001_tab
= p0001_tab
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~set_partial_org_assignment.
CALL METHOD a_auth_check->set_partial_org_assignment
EXPORTING
tclas
= tclas
p0001
= p0001
fieldlist
= fieldlist
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_authorization.
DATA l_begda TYPE begda.
DATA l_endda TYPE endda.
50A
94
SAP Online Help
16.04.2002
IF level CA 'R M'.

*
read access --> alter data to get nonstandard behavior

l_begda = sy-datum.
l_endda = sy-datum.
ELSE.
write access --> standard time logic applies

l_begda = begda.
l_endda = endda.
ENDIF.
CALL METHOD a_auth_check->check_authorization

EXPORTING
level
= level
tclas
= tclas
pernr
= pernr
infty
= infty
subty
= subty
begda
= l_begda
endda
= l_endda
process_only_partial_checks = process_only_partial_checks
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error
= 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_max_pernr_authorization.
CALL METHOD a_auth_check->check_max_pernr_authorization
EXPORTING
level
= level
tclas
= tclas
pernr
= pernr
IMPORTING
50A
95
SAP Online Help

is_authorized
16.04.2002
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_min_pernr_authorization.
CALL METHOD a_auth_check->check_min_pernr_authorization
EXPORTING
level
= level
tclas
= tclas
pernr
= pernr
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_pernr_authorization.
DATA l_begda TYPE begda.
DATA l_endda TYPE endda.
IF level CA 'R M'.

*
read access --> alter data to get nonstandard behavior

l_begda = sy-datum.
l_endda = sy-datum.
ELSE.
write access --> standard time logic applies
50A
96
SAP Online Help
16.04.2002
l_begda = begda.
l_endda = endda.
ENDIF.
CALL METHOD a_auth_check->check_pernr_authorization

EXPORTING
level
= level
tclas
= tclas
pernr
= pernr
begda
= begda
endda
= endda
IMPORTING
is_authorized
= is_authorized
EXCEPTIONS
invalid
= 2
internal_error = 1.
CASE sy-subrc.
WHEN 1.
WHEN 2.
RAISE invalid.
ENDCASE.
ENDMETHOD.
METHOD if_ex_hrpad00auth_check~delayed_constructor.
ENDMETHOD.
METHOD constructor.
CREATE OBJECT a_auth_check TYPE cl_hrpad00auth_check_std.
ENDMETHOD.
7.2 HRBAS00_STRUAUTH (BAdI: Structural

Authorization)
Definition
Business Add-In (BAdI) that you can use to implement a customer-specific test procedure for the
structural authorization check.
50A
97
SAP Online Help
16.04.2002
Use
You can implement a customer-specific test procedure for general and structural authorization checks
using a Business Add-In (BAdI). The BAdI for the structural authorization check is called
HRBAS00_STRUAUTH.
Note
You can find the Business Add-In (BAdI) in the IMG for Personnel Management under
Organizational Management Basic Settings Authorization Management
Structural Authorization BAdI: Structural Authorization. You can find information on
implementing a BAdI in the documentation of the corresponding IMG activity.
For general information on Business Add-Ins and their implementation, see also Notes
under BAdI: Customer-specific authorization checks [page 86].
You can implement the BAdI using the following methods, all of which must be implemented:
CHECK_AUTHORITY_VIEW
FILL_DATE_VIEW
FILL_HYPER_VIEW
CHECK_AUTH_PLAN1
Structure
The following describes the individual methods, which are coordinated using the
IF_EX_AUTHORITY_BADI interface. The method interfaces are stored in the system as
documentation of the corresponding methods. Review the method documentation of the
corresponding method if you are implementing a new method or changing method.
CHECK_AUTHORITY_VIEW (Check Structural Authorization of an Object)

This method checks a users structural authorization for an object once the set of authorized
objects for this user (VIEW) is determined.
This implementation should reduce runtime problems if this user should be granted
authorization for large structures. This enables the check to be performed by object type or
by user. The authorization check can also be implemented independently of the VIEW.
FILL_DATE_VIEW (Fill Table of Authorization Ranges for an Object)

This method fills the interval tables for the intervals that a user has authorization to access an
object. The authorization check can also be performed independently of the VIEW created.
FILL_HYPER_VIEW (Fill Table of Authorization Relationships)

This method fills the relationship tables (HYPER_VIEW) for relationships that a user has
authorization for. The tables can be filled by object type or by user.
CHECK_AUTH_PLAN1 (Check Personnel Authorization)

This method checks the structural authorization from a personnel administration perspective
(for example, write or read access) and fills the period tables for which a user has
authorization accordingly.
Example
In the BAdI, you can display sample implementation code under Goto Display Sample Coding. You
can also view this sample code in the Class Builder (SE24), by displaying the
CL_EXM_IM_HRBAS00_STRUAUTH class and the corresponding methods.
50A
98
SAP Online Help
16.04.2002
Troubleshooting Authorization Problems
Use
The procedures described in this section are designed to help you analyze problems that arise in
connection with authorizations.
Determining Minimum Authorization

You can use the following two procedures to determine which authorizations a user requires to carry
out a transaction:
1. Set up authorizations for the relevant transaction and for the SU53 transaction for the user. Then
call up the transaction and wait until the authorization check denies you access. Finally, use the
SU53 transaction to see what type of authorization check was carried out. Add the missing
authorization and repeat the process. This procedure is simple but can be fairly lengthy.
2. Start an authorization trace using the ST01 transaction and carry out the transaction with a user
who has full authorizations. On the basis of the trace, you can see which authorizations were
checked.
Note
This procedure generally works well. However, sometimes the result is very surprising
because certain programs can and do ignore some authorization checks by using
preliminary checks and buffered results. In such cases, these methods are not very
effective. You can recognize these cases because certain fields of the corresponding
programs are specified with * or DUMMY at some point of the authorization check.
Analyzing authorization problems in an unknown program

The most frequently used method to analyze authorization problems in an unknown program involves
you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then
execute the program and analyze its behavior.
Determining all the authorizations a user has for an authorization object

When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a
specific authorization object. A simple method of reading these authorizations as raw data from the
user master record is to execute the GET_AUTH_VALUES function module in the SUSR function
group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for
output, but is very compact and easy to understand for authorization experts.
Analyzing an authorization problem that occurs for only one user

It is often the case that a certain authorization problem occurs for only one specific user. This kind of
authorization problem generally affects users with no Debugging authorization. If you want to assign a
user Debugging authorization without changing the HR authorizations, you can add the
S_A.DEVELOP authorization profile (if available) to the users authorization profiles. In production
systems, note that changes such as these to authorizations enable users (with relevant knowledge of
the development environment) to access any system data easily (especially in other clients).
Analyzing an authorization problem that occurs for only one personnel number
Authorization problems that occur for a single personnel number are caused almost always by
incorrect settings in the environment of the P_PERNR [page 34] authorization object.
Authorization problems that are user-independent and occur for a single personnel number are
caused almost always by a specialized organizational assignment (or even an incorrect
organizational assignment). In this case, you should check the data of the Actions (0000) and
Organizational Assignment (0001) infotypes and the relationships with the organizational structure
(actively integrated systems) thoroughly.
50A
99
SAP Online Help
16.04.2002
Analyzing authorization problems in connection with locking and unlocking infotype

records
Authorization problems that occur in connection with locking and unlocking infotype records are often
caused by the CHECK_AUTH_SET_ENQ (SAPFP50M) form.
Localizing the cause of authorization problems after the import of HR Support

Packages
The majority of code for the HR Master Data authorization check is localized in the
CL_HRPAD00AUTH_CHECK_STD and CL_HRPAD00AUTH_CHECK_FAST classes, the
SAPFP50P report, and the HRAC function group. You can also find smaller parts of code in the
SAPDBPAP, SAPDBPNP, and SAPFP50M reports. If authorization problems are caused by HR
Support Packages, a good place to start looking for changes to the code is in the above-mentioned
classes and reports.
Useful questions for solving authorization problems

Over 90% of SAPs incoming messages about authorization problems are consulting problems. What
is more, in many cases customers are convinced that an error is causing their problems when in fact
the problem is due to a misunderstanding of the functions of the corresponding protection
mechanism. When analyzing authorization problems, it is therefore important that you can answer the
following questions:
What data (which infotype/subtype) did the user access and how (using which transaction or
which function of a transaction)?
How did the system react (did it incorrectly allow or deny access)?
How should the system have reacted (should it have allowed or denied the user access)?
Which authorization main switches [page 43] are set up in the system?
How are the authorizations for the activated authorization checks set up?
Are the data records of the Organizational Assignment infotype (0001) as they should be for the
personnel number in question?
Constraints
In this section you can find information about known problems with the authorization check for
mySAP HR and solutions to help you overcome these problems.
See also:
Special Features of the Authorization Check in Dialog (Master Data) [page 100]
Special Features of the Authorization Check in Reporting (Master Data) [page 101]
Performance Aspects [page 102]
Evaluation Paths with a Non-Specified Target Object Type [page 104]
Context Problems in HR Authorizations [page 104]
9.1 Specific Processing of the Authorization Check in

Dialog (Master Data)
Problem Description I
In the dialog transactions for master data, authorization checks always run from top to bottom first.
This means that even if the check is for read access, the system checks whether write authorization
50A
100
SAP Online Help
16.04.2002
exists for the corresponding data record. The authorization level [page 46] is checked in the following
order:
1. W (Write) = write access
2. S (Symmetric) = write access using the Symmetric Double Verification Principle
3. E (Enqueue) = write access using the Asymmetrical Double Verification Principle. E also enables
you to create and change locked records
4. D (Dequeue) = write access using the Asymmetrical Double Verification Principle. D also enables
you to change the lock indicator.
5. R (Read) = read access
As soon as the authorization check has run successfully, the result is stored in the buffer and the
check is ended.
Consequently, all write authorizations in the dialog also work as read authorizations. However, since
there are special modules that check for read access directly, this can lead to an inconsistent system
response.
Solution I
Ensure that you always specify a read authorization together with the write authorization.
Problem Description II
The order in which the authorization level is checked can have the following additional effect: a user
with authorization levels E and D for a data record, actually needs authorization level E to access the
data record in question. Due to the business importance of authorizations, you would, however,
expect this user to have the same authorizations as a user with authorization level W. This is also the
case for users with the combinations E with S and in particular D with S.
Solution II
In future releases, it is planned to carry out this interpretation in a business-oriented sequence rather
than the present technically oriented sequence. For this reason, you should not implement any
authorization concepts that are based on the authorization level combination E, D or S for an infotype
for a user.
Problem Description III

The system always checks infotypes with subtypes using the corresponding specification of the
subtype field when it accesses the initial screen for single record maintenance. If you attempt to edit
an infotype record without specifying a subtype, the authorization check is performed using the
<BLANK> subtype. This often results in users with limited subtype authorizations being able to access
data records.
Solution III
There are two ways to avoid this:
1. Users always explicitly specify a subtype for which they have authorization.
2. Users are granted an additional authorization for the dummy subtype <BLANK>.
Recommendation
The second option is preferable. In principle, users are not granted any unnecessary
authorizations since the <BLANK> subtype does not exist and is always explicitly checked
when users access existing data records and when they create new data records.
9.2 Special Features of the Authorization Check in
50A
101
SAP Online Help
16.04.2002
Reporting (Master Data)

Problem Description
The SAPDBPNP and SAPDBPAP logical databases are used in many reports. In these reports, they
provide certain generic functions such as selection and the authorization check.
If there is no authorization for data selected on a personnel number, the logical databases cannot
determine what the optimal response to the special request is.
As long as nothing to the contrary is determined in the code, personnel numbers for which all data
records except one can be accessed by users are completely skipped.
Examples
1. A report that should output only address data can continue to run using partial data of a
personnel number.
2. A report that runs evaluations by personnel number generally works best if it can read all the data
requested on the personnel number concerned.
3. A report that generates a set of statistics yields a correct result only if all selected personnel
numbers are processed by the system.
Solution
You can use the following procedures if you want to change the behavior of the SAPDBPNP logical
database:
1. You can program the logical database not to skip personnel numbers. The data is, nevertheless,
only made available to the relevant reports for the authorization check There is no direct way to
access the data that was not read by the authorization check. This procedure is meaningful for
the first example, but not for the other two examples. The relevant report implements the setting
as follows:
INITIALIZATION.
PNP_SW_SKIP_PERNR = 'N'.
2. It is conceivable in examples 2 and 3 that the evaluation would be possible for a certain period
but not for a longer selection period. Normally, the logical database always selects all the data of
an infotype and checks the authorization. If you want the system to read and check only the data
of the selection period, you can use the RP_SET_DATA_INTERVALL macro (for the START-OFSELECTION period) for this.
3. The data is not requested immediately (addition MODE N for the INFOTYPES statement) and is
checked by the report itself. The report uses the HR_READ_INFOTYP and/or the
HR_CHECK_AUTHORITY_INFTY function modules from the HRAC group to check the data and
decides itself how to react to missing authorizations.
Note
Procedures 1 and 2 are available for SAPDBPNP and are not supported by SAPDBPAP.
Procedure 3 is always available. Procedure 3 is the only way of solving problems with the
authorization check if a report requires only one subtype of an infotype and if users
should not be able to access the other subtypes of the infotype.
9.3 Performance Aspects

Problem Description
The creation of the set of objects for the structural authorization check can be very time-intensive at
runtime if the evaluation paths are extensive and the organizational structures large. This is due to
the fact that the set of objects must be newly created each time a user starts or changes transaction
50A
102
SAP Online Help
16.04.2002
so that the system can evaluate organizational changes as soon as possible. Performance problems
often occur when structural authorizations are used.
Solution
Performance problems can be avoided for the most part by pre-generating profiles or by defining the
structural authorization profiles more clearly:
1. You can use the RHBAUS00 [page 107] report to work with pre-generated profiles.
2. When you define structural authorization profiles, avoid above all the following fields, which are
described in more detail together with solutions in:
Evaluation Paths with Non-Specified Target Object Types [page 104]
9.3.1
Redundant Read of Objects
Problem Description
Unnecessary performance losses can occur if there are redundancies after the structural
authorizations have been defined, that is if the entries in the T77PR table (Definition of Authorization
Profiles) overlap for a user. This is illustrated in the following example.
Example of an overall profile that leads to redundant checks:

Profile
Root Object
Evaluation Path
Profile 1:
O1
O-S-P (Staffing Assignment Along Organizational Structure)
Profile 2:
O1
O_O_S_C (Position per Organizational Unit)
This type of profile (several evaluation paths) is often used to implement authorization requirements
that cannot be met using a standard evaluation path.
In the present example, the profile needs to contain authorization for organizational units, positions,
jobs, and persons. This combination is not covered by any standard evaluation path, which is why the
two evaluation paths mentioned above are used.
However, the creation of the set of objects takes longer because specific objects (O, S) are read
several times:
Evaluation Path O-S-P:
O
B002
B002
A008
Evaluation Path O_O_S_C:

O
B002
B003
A007
If these two evaluation paths are used simultaneously, organizational units (O) and positions (S) are
read redundantly during the creation of the set of objects.
Solution
You can avoid this by defining your own evaluation path that meets all the requirements of the profile
and reads the necessary objects only once. In the present example, you could define a Z_O_S_C_P
evaluation path, for instance:
Evaluation Path Z_O_S_C_P:
O
B002
B003
50A
103
SAP Online Help
16.04.2002
A008
A007
9.3.2
Evaluation Paths with Non-Specified Target Object Types
Problem Description
The use of evaluation paths with an unspecified target object type of a relationship is an additional
cause of performance problems, even though the request on the authorization profile is limited to
certain (target) object types, as the following example illustrates:
Example
Assume that the authorization profile should determine the permitted persons by organizational unit
and position. You can use the SBESX evaluation path for this:
Evaluation Path SBESX:
O
B002
B002
A008
If you use this evaluation path, the objects linked with positions are not determined by the definition of
the evaluation path but according to the T77E table (Permitted Relationships).
As a result, all other objects that could be linked to a position (object types BP and US) are also
imported to the set of objects. This is NOT necessary for the current requirement.
Solution
To avoid this, an evaluation path with a specified target object type should be used:
The Z_SBESP evaluation path could be used for this example:
O
B002
B002
A008
9.4 Context Problems in HR Authorizations

Problem Description
The technical separation of general and structural authorization profiles can cause context problems
for users who perform different roles in a company (see graphic). This is due to the fact that you
cannot simply add any number of structural and general authorization profiles required for different
tasks (in different contexts) without overriding something.
50A
104
SAP Online Help
16.04.2002
CEO
Board
CFO
Dir.Auto
Dir.Trucks
Dir.HR
Finance
Automob.
Trucks
Corp.HR
...
...
Head Sv
Team lead
Team lead
Team lead
Team1
Team2
Team3
Emp Emp
Emp Emp
Emp Emp
...
Mgr Benefits
Mgr Payroll
...
BenefitsDept
Payroll Dept
PC1
PC2
Emp
Emp
Functions von Mgr Payroll:

a) Manager
b) Payroll Manager
Example
A user (referred to as manager 1 in this example) is the manager of a team and should be allowed to
edit infotypes 0000 0007 for the employees in his or her team.
Manager 1 is also Payroll Manager for another organizational structure. In this second role, manager
1 has access to all payroll-relevant infotypes (0008 and 0015) for the employees in this organizational
structure.
The business requirements of the roles Manager and Payroll Manager are represented again in the
following overview table:
Business overall profile of the role Manager:
Objects
Type of Authorization
All employees in the

managers team
Full read and write authorization for infotypes 0000 to

0007
Business overall profile of the role Payroll Manager:
Objects
Employees in the

0015
This cannot be illustrated using the existing HR authorization concept because there is no
relationship of any kind between an individual structural profile and an individual basis authorization.
This leads to overriding.
50A
105
SAP Online Help
16.04.2002
Structural
Profile 1 (Role
Manager)
O1
S1
SN
P1
Overall
Profile for
Manager 1
PN
+
Payroll Manager)
O2
P2
Manager)
INFOTYP:
SUBTY:
AUTHC:
PERSA:
PERSG:
PERSK:
...
0-7
*
W
*
*
*
Structural
Profile 2 (Role
S2
Profile 1 using
P_ORGIN (Role
SM
PM
Overriding!
Profile 2 using
P_ORGIN (Role
Payroll Manager)
INFOTYP:
SUBTY:
AUTHC:
PERSA:
PERSG:
PERSK:
...
8,15
*
W
*
*
*
You cannot create an assignment between a users specific structural profile (here, for example,
structural profile 2) and a specific general profile (profile with P_ORGIN).
What in fact happens is that the structural profiles (that is, the set of objects) and the general profiles
are added (in this case, using P_ORGIN) to give the overall profile. Consequently, the following effect
occurs in the above example: Manager 1 has complete read and write authorization for all objects in
both structural profiles. When the authorization profiles are added together, the following overall
profile is produced:
Objects
All employees in the

managers team and

0008 and for 0015
Solution
If you use a separate user for each context, it is easier to map different contexts (roles) with the
correct authorization.
For example, if Manager 1 wants to carry out his activities as Manager of his team, he simply uses his
user name. As soon as he wants to perform his role as Payroll Manager, he needs a second system
user (with the respective authorization as in the above example).
To map the roles with the correct authorizations, you must create a second system user (such as
Payroll_Manager) for Manager 1 with the following overall profile.
Overall profile for system user Payroll_Manager:
Objects
Employee of organizational
structure

0015
If Manager 1 wants to carry out his or her role as Payroll Manager for the organizational structure, he
or she must log on to the system with the system user Payroll_Manager.
50A
106
SAP Online Help
16.04.2002
10 Additional Functions for Authorization Checks

In this section you can find information on the most important reports that play a role for mySAP HR
in the context of authorizations.
See also:
Report RHPROFL0 [page 107]
Report RHBAUS00 (Regeneration INDX for Structural Authorization) [page 107]
Report RHBAUS01 (Output of Views on Objects in the Structural Authorization) [page 108]
Report RHBAUS02 (Check and Compare T77UU (User Data in SAP Memory)) [page 108]
Report RPUACG00 (Code Generation: HR Infotype Authorization Check) [page 109]
10.1 Report RHPROFL0

Use
You can use this report to create authorization profiles for users within an organizational plan. This
applies to standard authorization profiles and to authorization profiles for structural authorizations. In
addition, this report assigns user roles and their profiles.
Features
Using the PROFL0 start evaluation path, the system searches for all users found in the structure
and saves them temporarily. On a key date, starting from these users, the system reads all linked
objects that have valid relationships at this point and for which the Standard Authorization Profile
infotype (1016) and/or the Authorization Profile for Structural PD Authorizations infotype (1017) is
stored. The system reads all such objects up to the next highest organizational unit. This means
that the higher-level organizational units are not taken into account.
The relevant object types are jobs (C), positions (S), organizational units (O), tasks (T), task
groups (TG), workflow template (WS), workflow tasks (WF), standard tasks (TS), work centers (A)
and responsibilities (RY). In addition, all user roles (AG) and their standard authorization profiles
are included.
Then, the report checks whether the users found have already been created in the system. This
is necessary because in the Communication infotype (0105), subtype System user name (0001)
of a person, users can be entered that are not created in the system.
If a user does not exist in the system, it is automatically created. The authorization profiles for all
users found in the organizational plan are then entered.
6. You can check the results for the standard authorization profiles and user roles using the SU01
transaction. You can display the structural authorizations using the OOSB transaction.
Note
For more information about this report, such as setting the report parameters, see the
documentation for the RHPROFL0 in the SAP system.
10.2 RHBAUS00 Report (Regeneration INDX for Structural

Authorization)
Use
You can use this report to generate indexes for structural authorization profiles for selected users. By
generating indexes, you achieve much better performance values for users with structural profiles, for
which the system must read a large set of objects.
50A
107
SAP Online Help
16.04.2002
Prerequisites
You can use this report only for users who are entered in the T77UU table (Save User Data in SAP
Memory) as a user. You can make this entry in the Customizing activity Save User Data in SAP
Memory (in the Implementation Guide (IMG) for Personnel Management under Organizational
Management Basic Settings Authorization Management Structural Authorizations). Indexes
for quick access to the organizational structures are available only for these users.
Note
For information about checking and editing entries in the T77UU table, see also the
RHBAUS02 [page 108] report.
Features
Generating indexes for structural authorization profiles for selected users. You should have the
system regenerate the indexes at night using a batch job for executing the existing report.
Recommendation
SAP recommends that you execute the report manually for a direct regeneration if you
have made changes to the organizational structure since the last automatic regeneration.
Creating a log that contains a list of the users whose index was regenerated and the number of
objects that were included in the index for a user.
Note
For more information about this report, see the report documentation in the SAP system.
10.3 RHBAUS01 Report (Output of Views on Objects in the

Structural Authorization)
Use
You can use this report to perform a comparison of the INDX (INDX System Tables ) and T77UU
(Save User Data in SAP Memory) tables.
Features
The report generates a list of users who have data of the structural authorization in the SAP
Memory but who are no longer entered in the T77UU table.
The report also enables you to delete the entries of the users no longer in the T77UU table from
the INDX table.
10.4 RHBAUS02 Report (Check and Compare T77UU (User

Data in SAP Memory))
Use
You can use this report to enter users with authorization for a large number of objects in the T77UU
table (User Data in SAP Memory). This improves performance because the system saves the objects
of the structural authorization in SAP Memory for the users entered in this table, which makes the
authorization check run quicker.
50A
108
SAP Online Help
16.04.2002
Note
It is only meaningful to enter users in this table who have authorization for a large number
of objects.
Features
The existing report enters users in the T77UU table or deletes users from this table if they have too
small a number of objects depending on a threshold value. You can define the threshold value for the
report.
The report can then automatically perform the Save User Data in SAP Memory Customizing activity.
Note
10.5 RPUACG00 Report (Code Generation: HR Infotype

Authorization Check)
Use
You can use this report to generate the necessary ABAP coding for a customer-specific authorization
object that is to be included in the HR infotype authorization check (using the MPPAUTZZ report).
Note
See also:
50A
109
SAP Online Help
16.04.2002
11 Glossary
Authorization
Authority to carry out a particular activity in the system.
The system always grants an authorization for a specific authorization object and stores it in the user
master record of a user. You can think of an authorization as a key that fits the locks of a specific lock
system (to build up the authorization object).
Just as there are master keys and general keys to the locks in a lock system, there are authorizations
that enable authorization checks to exist. However, the authorizations and checks must always
belong to the same authorization object (that is to the same key system).
Authorization Check
Point in the program at which the systems asks for a specific authorization. You can think of the
authorization check as the lock to a lock system.
Authorization Level
Access mode used by the user to access system data.
Possible specifications of an authorization level are:
M: Read entry helps
R: Read
E: Write locked data records
D: Maintain lock indicators
W: Write data records
*: All operations
Authorization Main Switch

Collective term for the AUTSW group entries from table T77S0 (System Table) that are connected
with HR authorizations. You can generally control the use of an authorization object during the
authorization check using this switch.
Example: The ORGIN entry controls the use of the P_ORGIN authorization object.
The AUTSW ADAYS [page 44] switch, which you can use to set up the tolerance time for the validity
of authorizations in case of an organizational change, is an exception to this. Another exception is the
AUTSW APPRO [page 45] switch, which you can use to control the test procedures [page 51].
Authorization Object
Technical tool used to carry out authorization checks.
From a system point of view, an authorization object primarily determines the technical context for the
authorization check. In other words, which fields with which field specifications the system should
consider during the corresponding authorization check. You can specify a maximum of ten fields per
authorization object. The actual check and the business meaning of this check are determined by a
program of the corresponding application.
You can think of an authorization object as the building instructions for the locksmith of a lock system.
The object does not determine which authorizations you need at a position (which keys fit in which
locks), instead it determines which fields are used as part of the authorization check (what the keys or
locks look like). In addition, the object does not determine which programs access it (where a lock is
built) and how the programs react after the corresponding authorization checks (what happens when
you turn the key).
50A
110
SAP Online Help
16.04.2002
Authorization Profile
Grouping of authorizations. Analogy: Bunch of keys (where a key = an authorization)
Business Add-In (BAdI)

Function that creates the flexibility to realize customer enhancements. A BAdI is a location defined by
SAP in a program at which delivered software layers (industries, partners, customers, and so on) can
insert code without modifying the original object. Business Add-Ins can be created at every level of a
multi-level system infrastructure (for example, SAP, country version, IS solutions, partners, and
customers). Implementations can also be created and delivered in all software layers.
The enhancement technique with Business Add-Ins distinguishes between enhancements that can
have at most one implementation and those that can be actively used by any number of customers at
the same time. Business Add-Ins can also be defined independently of a filter value. Enhancements
to the program code are implemented with ABAP objects.
You create BAdIs using the SE18 transaction. You can perform BAdI implementations using the
SE19 transaction.
Double-Verification-Principle
Method that requires at least two users to create or change data.
You can define authorizations for infotypes so that one user is authorized to create data records and
write locked data records, and another user to edit the lock indicators (set and delete). Data entry is
therefore controlled by both users.
The Double Verification Principle ensures that one person alone cannot change particularly critical
information (for instance, the information on an employees salary stored in the Basic Pay infotype
(0008)).
Evaluation Path
Chain of relationships that exists between objects in an hierarchical structure.
The evaluation path O-S-P, for example, describes the relationship chain organizational unit
position person.
Evaluation paths are used, for instance, to select objects during evaluations. You choose an
evaluation path and the system evaluates the structure along this evaluation path. The report takes
account only of the objects that lie along the specified evaluation path.
Feature
Technical tool used to create a decision tree in Customizing. From a technical perspective, a feature
is a CASE statement that has been nested several times. You can process features using the
Features: Initial Screen transaction (PE03).
Features are frequently used in HR. Features are most frequently used to:
Define default values
Control system process flows
Control the display of lists in evaluations
Organizational Key
Field (technical name P0001-VDSK1) that is used to run diverse authorization checks by
organizational assignment (using the P_ORGIN 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.
Overall Profile
All the authorization profiles from general and structural authorizations that a user has in the system.
50A
111
SAP Online Help
16.04.2002
Period for which a user is authorized to access an infotype or a combination of infotype and subtype.
The validity period of a data record may only partly be in a users period of responsibility. For this
reason, there is a time logic, which then decides on the authorization.
Role
Group of activities that a user with a specific task profile carries out.
A role is defined by the transactions, reports, web-based applications and so on that it contains. User
menus provide access to the activities contained in roles.
Test Procedures
Method that protect infotype data by checking for the presence of the Test Procedures infotype
(0103).
Time Logic
Method that determines within the general authorization check whether access authorizations already
exist for a user using the period of responsibility of the user, the validity period of a data record, and
the desired access mode (read or write).
*-Entry
Input value that you can enter instead of concrete values when assigning authorizations.
A * can substitute any value. If XY* is entered in a field as part of an authorization, the corresponding
authorization check will be successful for XY, XYA, XYB, XYZ, XY1, for example, but not for ABC. If * is
entered in a field, the corresponding authorization check will always be successful.
50A
112
SAP Online Help
16.04.2002
12 Index
A
ADAYS........................................................................ 44
APPRO......................................................................... 45
Assignment of Structural Authorizations ..................... 17
Asymmetrical Double Verification Principle ............... 50
AUTHC ........................................................................ 46
Authorization Check
Flowcharts................................................................ 52
Processes.................................................................. 52
Reports................................................................... 107
Authorization Check by Personnel Number
Flowchart ................................................................. 58
Process ..................................................................... 56
Authorization Level...................................................... 46
Accessing Clusters ................................................... 46
Accessing Master Data ............................................ 46
Authorization Main Switches ....................................... 43
Authorization Objects................................................... 18
Authorization Problems................................................ 99
Authorizations ................................................................ 6
AUTSW ADAYS......................................................... 44
AUTSW APPRO.......................................................... 45
AUTSW NNNNN ........................................................ 44
AUTSW ORGIN .......................................................... 44
AUTSW ORGPD ......................................................... 45
AUTSW ORGXX ........................................................ 44
AUTSW PERNR.......................................................... 45
B
BAdI HRPAD00AUTH_CHECK
Examples.................................................................. 90
G
General authorization check
Process .....................................................................53
General Authorization Check ......................................... 6
Flowchart..................................................................55
Setting Up...................................................................7
H
HRBAS00_STRUAUTH..............................................97
HRPAD00AUTH_CHECK ..........................................86
Example of the Implementation ...............................91
I
Infotype
0130..........................................................................51
Interaction of General and Structural Authorizations ...80
M
Minimum Authorization
Determining..............................................................99
C
Context Problems ....................................................... 104
Control Mechanisms .................................................... 50
Creation of Infotype Log.............................................. 52
Customer Enhancements .............................................. 86
N
NNNNN........................................................................44
D
Definition of Structural Authorizations........................ 12
Double Verification Principle
Asymmetrical........................................................... 50
Double Verification Principle
Symmetrical ............................................................. 51
Organizational Key.......................................................47
Organizational Key
Controlling Creation and Validation ..................47
Creation ..................................................................48
Validation ...............................................................48
ORGIN .........................................................................44
ORGPD.........................................................................45
ORGXX........................................................................44
E
Employee Self-Service ................................................. 81
Evaluation Paths with Non-Specified Target Object
Types ..................................................................... 104
Examples ...................................................................... 81
F
Flowchart
Authorization Check by Personnel Number .............58

Authorization Check Using P_ORGIN, P_ORGXX
and P_NNNNN ....................................................70
Determining the Period of Responsibility According
to Organizational Assignment..............................67
to Organizational Structure ..................................61
Test Procedures ........................................................76
Determining the Date After Which Changes Are
Permitted .........................................................79
Time Logic ...............................................................73
50A
P
P_ABAP .......................................................................30
P_APPL ........................................................................26
P_BEN..........................................................................22
P_CATSXT ..................................................................23
P_CERTIF ....................................................................25
113
SAP Online Help
16.04.2002
P_CH_PK..................................................................... 20
P_DBAU_SKV ............................................................ 28
P_DE_BW.................................................................... 20
P_DK_PBS................................................................... 21
P_HRF_INFO .............................................................. 24
P_HRF_META ............................................................ 25
P_NNNNN ................................................................... 40
Process of the Authorization Check ......................... 68
P_OCWBENCH........................................................... 22
P_ORGIN..................................................................... 32
Period Determination ............................................... 33
P_ORGXX ................................................................... 37
P_PCLX ....................................................................... 28
P_PCR.......................................................................... 29
P_PE01......................................................................... 24
P_PE02......................................................................... 24
P_PERNR..................................................................... 34
P_PYEVDOC............................................................... 21
P_PYEVRUN............................................................... 27
P_TCODE .................................................................... 37
P_USTR ....................................................................... 38
Performance Aspects.................................................. 102
Organizational Structure .......................................... 59
Periods of Responsibility.............................................. 49
Process of Determining............................................ 59
PERNR......................................................................... 45
PLOG ........................................................................... 39
Process
Authorization Check by Personnel Number............. 56
Authorization Check Using P_ORGIN, P_ORGXX
and P_NNNNN.................................................... 68
to Organizational Assignment ............................. 65
to Organizational Structure.................................. 59
to the Structural Authorization Check ................. 62
Determining the Periods of Responsibility .............. 59
Test Procedures........................................................ 74
Determining the Date After Which Changes Are
Permitted ......................................................... 77
Time Logic............................................................... 70
Processes and Flowcharts of the Authorization Check. 52
R
Redundant Read of Objects ........................................103
Reports
Authorization Check...............................................107
RH_GET_MANAGER_ASSIGNMENT .....................16
RH_GET_ORG_ASSIGNMENT .................................16
RHBAUS00 ................................................................107
RHBAUS01 ................................................................108
RHBAUS02 ................................................................108
RHPROFL0 ................................................................107
RPUACG00 ................................................................109
S
S_MWB_FCOD ...........................................................40
S_TABU_DIS...............................................................42
S_TMS_ACT................................................................42
Setting Up General Authorization Checks ......................7
Structural Authorization Check
Determining the Period of Responsibility ................62
Structural Authorization Check ...................................... 9
Structural Authorizations
Assignment...............................................................17
Definition .................................................................12
Structural Profiles ......................................................... 10
Symmetrical Double Verification Principle..................51
T
Test Procedures.............................................................51
Flowchart..................................................................76
Flowchart of Determining the Date After Which
Changes Are Permitted ........................................79
Process .....................................................................74
Process of Determining the Date After Which
Changes Are Permitted ........................................77
Time Logic ...................................................................49
Flowchart..................................................................73
Process .....................................................................70
Tolerance Time for Authorization Check .....................44
Troubleshooting Authorization Problems .....................99
V
VDSK1 .........................................................................47
50A
114

Authorizations in HR PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Authorizations in HR PDF

Enviado por

Direitos autorais:

Formatos disponíveis

SAP Online Help

SAP Online Help

SAP Online Help

Setting Up General Authorization Checks................................................................... 7

2 Structural Authorization Check .................................................9

Structural Profiles ...................................................................................................... 10

Definition of Structural Authorizations ................................................................ 12

Assignment of Structural Authorizations ............................................................ 17

3 Technical Aspects ..................................................................18

Authorization Objects ................................................................................................ 18

P_CH_PK (HR-CH: Pension Fund: Account Access)........................................ 20

P_DE_BW (HR-DE: Statements SAPScript) ..................................................... 20

P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)......... 21

P_PYEVDOC (HR: Posting Document) ............................................................. 21

P_OCWBENCH (HR: Activities in the Off-Cycle Workbench) ........................... 22

P_BEN (HR: Benefit Area) ................................................................................. 22

P_PE02 (HR: Authorization for Personnel Calculation Rule) ............................ 24

P_PE01 (HR: Authorization for Personnel Calculation Schemas)..................... 24

P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)24

P_HRF_META (HR: Authorization Check Master Data Maint. for HR Forms) .. 25

P_CERTIF (HR: Statements) ............................................................................. 25

P_APPL (HR: Applicants) .................................................................................. 26

P_PYEVRUN (HR: Posting Run) ....................................................................... 27

P_PCLX (HR: Clusters)...................................................................................... 28

P_DBAU_SKV (HR: DBAU: Construction Pay Germ. /Social Fund Procedure) 28

P_PCR (HR: Payroll Control Record) ................................................................ 29

P_ABAP (HR: Reporting) ................................................................................... 30

P_ORGIN (HR: Master Data)............................................................................. 32

Example of Period Determination Using P_ORGIN

P_PERNR (HR: Master Data Personnel Number Check) .............................. 34

P_ORGXX (HR: Master Data Extended Check) ............................................. 37

P_TCODE (HR: Transaction Code) ................................................................... 37

P_USTR (HR: US Tax Reporter) ....................................................................... 38

PLOG (Personnel planning) ............................................................................... 39

S_MWB_FCOD (BC-BMT-OM: Allowed Funct. Codes for Managers Desktop)40

P_NNNNN (Master Data: Customer-Specific Authorization Object).................. 40

Creating a Customer-Specific Authorization Object........................................... 41

Cross-Application Authorization Objects............................................................ 41

SAP Online Help

S_TABU_DIS (Table Maint. (Using Standard Tools Such as SM30))

S_TMS_ACT (TemSe: Actions on TemSe Objects)

HR: Authorization Main Switches .............................................................................. 43

AUTSW ORGIN (HR: Master Data) ................................................................... 44

AUTSW ORGXX (HR: Master Data Extended Check) ................................... 44

AUTSW NNNNN (HR: Customer-Specific Authorization Check)....................... 44

AUTSW ADAYS (Tolerance Time for Authorization Check) .............................. 44

AUTSW PERNR (HR: Master Data Personnel Number Check)..................... 45

AUTSW APPRO (HR: Test Procedures) ........................................................... 45

AUTSW ORGPD (HR: Structural Authorization Check)..................................... 45

AUTHC (Authorization Level) .................................................................................... 46

VDSK1 (Organizational Key) ..................................................................................... 47

Time Logic ................................................................................................................. 49

Periods of Responsibility ........................................................................................... 49

Control Mechanisms (Double Verification Principle, Test Procedures, etc).............. 50

Asymmetrical Double Verification Principle ....................................................... 50

Symmetrical Double Verification Principle ......................................................... 51

Test Procedures ................................................................................................. 51

Creation of Infotype Log..................................................................................... 52

4 Processes and Flowcharts of the Authorization Check ...........52

Process of the General Authorization Check ............................................................ 53

Process of the Authorization Check by Personnel Number ...................................... 56

Flowchart of the General Authorization Check .................................................. 55