Martin Esch, Anja Junold

Authorizations in SAP

HR
Bonn Boston
ch00_FM_5131.indd 3 6/4/08 [Link] AM
[Link]
Contents at a Glance
1 Process-Oriented Authorization Concept ................... 21
2 General Authorization Check ...................................... 41
3 Structural Authorization Check ................................... 115
4 Context-Dependent Authorization Check ................... 141
5 Authorization Roles in SAP HCM Components .......... 151
6 Implementing an Authorization Concept .................... 225
7 Reports for the Authorization System ........................ 245
8 Authorizations in Programming .................................. 259
9 Troubleshooting .......................................................... 275
10 Selected Problem Areas and Their Solutions .............. 287
A Transactions for Authorization Management ............. 315
B Authorization Objects of the SAP HCM System ......... 317
C Authorization Switches ............................................... 319
D Business Add-Ins ......................................................... 321
E Glossary ....................................................................... 323
F Recommended Reading ............................................... 327
G The Authors ................................................................. 329
ch00_FM_5131.indd 5 6/4/08 [Link] AM
[Link]
7
Contents
Acknowledgments ....................................................................... 13
Introduction ................................................................................ 15
1 Process-Oriented Authorization Concept ................... 21
1.1 Requirements for Authorization Concepts ..................... 22
1.1.1 Interest Groups ................................................... 22
1.1.2 Content Requirements ........................................ 24
1.2 Process Analysis ............................................................ 26
1.3 Role Denition ............................................................. 34
1.4 Naming Conventions .................................................... 35
1.5 Critical Success Factors ................................................. 38
2 General Authorization Check ....................................... 41
2.1 Elements ....................................................................... 41
2.2 Role Maintenance ......................................................... 43
2.2.1 Role Assignment ................................................. 48
2.2.2 Composite Roles ................................................. 53
2.2.3 Reference Roles .................................................. 55
2.3 Authorization Objects ................................................... 60
2.3.1 Transaction Authorizations ................................. 61
2.3.2 Infotype Authorization in Personnel
Administration ................................................... 64
2.3.3 Additional Authorization Objects for Master
and Time Data .................................................... 69
2.3.4 HR: Cluster Cluster Authorization Object
(P_PCLX) ............................................................ 72
2.3.5 Personnel Planning (PLOG) ................................. 74
2.4 Required System Authorizations .................................... 77
2.4.1 Checks when Calling Reports .............................. 77
2.4.2 Access to InfoSets and Queries ........................... 81
2.4.3 Table Maintenance ............................................. 83
ch00_FM_5131.indd 7 6/4/08 [Link] AM
[Link]
8
Contents
2.4.4 Customizing Authorizations in the
Implementation Guide (IMG) ............................. 85
2.4.5 Batch Input Authorizations ................................. 86
2.4.6 Authorization for Download and Upload ............ 86
2.4.7 Number Range Maintenance .............................. 87
2.4.8 HCM-Specic Authorizations for System
Administrators .................................................... 87
2.5 Customizing the Prole Generator ................................ 88
2.6 Period of Responsibility and Time Logic ........................ 94
2.7 Test Procedures (Infotype 0130) .................................... 99
2.7.1 Necessity and Functionality ................................ 99
2.7.2 Customizing ....................................................... 101
2.7.3 Authorization Assignment .................................. 102
2.7.4 Automatic Writing of the Test Procedure
Infotype ............................................................. 103
2.8 Extensions .................................................................... 104
2.8.1 The Authorization Object P_NNNNN ................. 104
2.8.2 Customer-Specic Authorization Object ............. 107
2.8.3 BAdI for General Authorization Checks ............... 108
2.9 Critical Success Factors ................................................. 113
3 Structural Authorization Check ................................... 115
3.1 Structural Authorization Check in Organizational
Management ................................................................ 116
3.2 Maintaining the Structural Proles ................................ 118
3.3 Function Modules ......................................................... 121
3.4 Transfer to Other Structures in SAP ERP HCM ............... 123
3.5 Use in Personnel Administration ................................... 125
3.6 Assigning Structural Proles to Users ............................ 126
3.7 Period of Responsibility and Time Logic ........................ 128
3.8 How the Structural Authorization Check Handles
Nonintegrated Persons .................................................. 133
3.9 Performance Optimization ............................................ 134
3.10 Extensions .................................................................... 137
3.11 Critical Success Factors ................................................. 140
ch00_FM_5131.indd 8 6/4/08 [Link] AM
[Link]
9
Contents
4 Context-Dependent Authorization Check ................... 141
4.1 Functionality ................................................................. 141
4.2 Setup and Maintenance ................................................ 145
4.3 Other Context-Dependent Authorization Objects ......... 148
4.4 Critical Success Factors ................................................. 149
5 Authorization Roles in SAP HCM Components ........... 151
5.1 Payroll and Subsequent Activities .................................. 152
5.1.1 Authorizations for Controlling Payroll and Its
Subsequent Activities ......................................... 153
5.1.2 Authorizations for Maintaining and Displaying
Forms ................................................................. 156
5.1.3 Authorizations for Auditors ................................ 157
5.1.4 Authorization for Deleting Payroll Results ........... 157
5.2 Appraisal System ........................................................... 158
5.3 Position Budgeting and Control ................................... 160
5.4 Cross Application Time Sheet (CATS) ............................. 163
5.5 E-Recruiting .................................................................. 166
5.5.1 SAP Roles ........................................................... 166
5.5.2 Authorization Objects ........................................ 168
5.5.3 User Types .......................................................... 174
5.6 SAP Expert Finder ......................................................... 176
5.7 HR Administrative Services ........................................... 178
5.8 Management of Global Employees ................................ 180
5.9 Managers Desktop ....................................................... 181
5.10 Organizational Management (OM) ................................ 182
5.11 Performance Management ............................................ 184
5.12 Personnel Administration and Time Management ......... 190
5.13 Recruitment (Classic) .................................................... 194
5.14 Shift Planning ............................................................... 198
5.15 Personnel Development ................................................ 201
5.16 Human Resources Information System/Reporting .......... 207
5.16.1 Logical databases ................................................ 207
5.16.2 SAP Reports Without Logical Database ............... 208
5.16.3 The Authorization Object P_ABAP ...................... 209
5.16.4 Reporting Basics ................................................. 210
ch00_FM_5131.indd 9 6/4/08 [Link] AM
[Link]
10
Contents
5.17 Personnel Cost Planning ................................................ 211
5.18 Self Services .................................................................. 212
5.19 Travel Management ...................................................... 215
5.20 Training and Event Management/SAP Learning
Solution ........................................................................ 218
5.20.1 Overview of the Authorization Objects ............... 218
5.20.2 Important Standard Roles ................................... 223
5.21 Summary ...................................................................... 224
6 Implementing an Authorization Concept .................... 225
6.1 Preparations in the System ............................................ 226
6.1.1 Central User Administration ................................ 226
6.1.2 Authorization Administrators .............................. 229
6.1.3 Initial Installation of the Prole Generator .......... 233
6.1.4 Creating Organizational Levels ............................ 237
6.2 Creating and Testing Roles ............................................ 237
6.3 Transport ...................................................................... 238
6.4 Documentation and Redesigning .................................. 241
6.5 Critical Success Factors ................................................. 243
7 Reports for the Authorization System ......................... 245
7.1 Analysis of Users with Critical Authorizations ................ 246
7.2 Overview of the Most Vital Authorizations of a User ..... 250
7.3 Overview of all Authorization Objects of a User ............ 251
7.4 Roles by Complex Selection Criteria .............................. 253
7.5 Assignment of Single Roles to Composite Roles ............ 256
7.6 Additional Reports ........................................................ 257
7.7 Critical Success Factors ................................................. 258
8 Authorizations in Programming .................................. 259
8.1 Authorizations in Reports Without Logical
Databases .................................................................... 259
8.1.1 SAP Function Modules with Authorization
Check ................................................................. 260
ch00_FM_5131.indd 10 6/4/08 [Link] AM
[Link]
11
Contents
8.1.2 Deactivating the Authorization Check using SAP
function modules ............................................... 260
8.1.3 Authorization Check Directly in Coding .............. 264
8.2 How the Logical Databases Handle Missing
Authorizations .............................................................. 266
8.3 Enterprise-Specic Database with Own Authorization
Check ........................................................................... 267
8.4 Authorizations for Programmers .................................... 269
8.5 Downloading from Reports ........................................... 270
8.6 Critical Success Factors ................................................. 272
9 Troubleshooting ........................................................... 275
9.1 Troubleshooting in General Authorizations .................... 275
9.1.1 Authorization Error Analysis Using
Transaction SU53 ................................................ 275
9.1.2 Authorization Trace ............................................ 277
9.1.3 Manual Troubleshooting ..................................... 280
9.2 Troubleshooting in Structural Authorizations ................. 282
9.3 Troubleshooting in Context-Dependent
Authorizations .............................................................. 284
9.4 Summary and Critical Success Factors ............................ 285
10 Selected Problem Areas and Their Solutions ............... 287
10.1 Authorizations from Organizational Management
(Schaefer KG) .............................................................. 287
10.2 Starting Reports via Customer Programs
(ThyssenKrupp Steel AG) .............................................. 292
10.3 Minimizing the Number of Roles and Decentralized
Assignment (B. Braun) ................................................... 295
10.4 Hiding Specic Fields in Infotypes ................................. 300
10.5 Supporting the Workow with the Double-Verication
Principle ....................................................................... 302
10.6 Authorization-Relevant Switches in Queries .................. 304
10.7 Transaction Variants ...................................................... 306
10.8 Summary ...................................................................... 312
ch00_FM_5131.indd 11 6/4/08 [Link] AM
[Link]
12
Contents
Appendices .......................................................................... 575
A Transactions for Authorization Management ........................... 315
B Authorization Objects of the SAP HCM System ...................... 317
C Authorization Switches ........................................................... 319
D Business Add-Ins .................................................................... 321
E Glossary ................................................................................. 323
F Recommended Reading ......................................................... 327
F.1 Books ........................................................................... 327
F.2 Websites ....................................................................... 327
G The Authors ........................................................................... 329
Index ............................................................................................. 331
ch00_FM_5131.indd 12 6/4/08 [Link] AM
[Link]
115
In SAP ERP HCM, many things dont work without a structural
authorization check or only if a great deal of maintenance
effort is involved. This chapter describes the benefts of structural
authorizations and where you can best use them.
3 Structural Authorization Check
The structural authorization check supplements the general authoriza-
tion check. It uses the arrangement and fexibility of structures in the
HCM system to simplify the authorization profles and increase their
dynamics. The structural authorization check is used in three essential
areas:
Display and maintenance of objects in Organizational Management
E
(OM)
Display and maintenance of all other HCM objects that are stored in
E
tables of the HRP* structure
Organizational restrictions for the display and maintenance of per-
E
sonnel administration data
A structural authorization check as it is described here exists only in
SAP ERP HCM. The following sections frst introduce the concept of
structural authorizations in Organizational Management. After dem-
onstrating how you can confgure a structural authorization, we will
describe additional felds of application. The section on the maintenance
of structural authorizations ends with the description of how you can
assign structural authorizations to users. Then, some specifc problems
are specifed and, fnally, well again focus on the extension options of
the tool.
Only in SAP ERP
HCM
165 [Link] 115 6/4/08 [Link] AM
[Link]
116
3 Structural Authorization Check
Structural Authorization Check in 3.1
Organizational Management
When examining the PLOG object, its apparent that it doesnt provide
the option to exclude or permit access to certain objects. For example,
if the authorization for Infotype 1000 of object type S is granted, it
applies to all positions of the enterprise. The PLOG authorization object
doesnt enable you to determine for which areas of the enterprise posi-
tions may be displayed or managed. But this can be done using the struc-
tural authorization check.
Basically, the structural authorization uses the means of the evaluation
paths . Based on a root object, which is defned by its eight-digit object
ID, the evaluation path determines all objects under the root object in
the structure. The authorization is issued for all of these objects.
Tip
For more information, refer to the SAP PRESS book, HR Personnel Planning
and Development Using SAP.
Figure 3.1 illustrates the O-O-S evaluation path as an example. This path
lets you access all positions located under a hierarchy of organizational
units.
O-O-S Evaluation Path Figure 3.1
Figure 3.2 shows a structure of organizational units (object type O), posi-
tions (object type S), and persons (object type P) as an example. The
O-O-S evaluation path describes exactly these object types.
If root object 80000815 is linked to the O-O-S evaluation path, all
objects illustrated in Figure 3.2 are permitted. If you specify root object
80004711, an authorization is only issued for the white objects.
PLOG doesnt
check the content
OM tool:
evaluation path
165 [Link] 116 6/4/08 [Link] AM
[Link]
117
Structural Authorization Check in Organizational Management 3.1
O
O
O
S
O
S
O
O
O
S
O
S
O
O
O
S
O
S
Object ID 80000815
Object ID 80004711
O
Example of a Structural Authorization Check Figure 3.2
Such an authorization check is completely fexible regarding changes to
the structure. For example, if a new organizational unit is directly or
indirectly assigned to the root object on April 1, 2008, this organiza-
tional unit and all linked positions are permitted objects as of April 1,
2008.
Skipping Object Types
What would you have to do if the authorization was supposed to be issued
for the positions but not for the organizational units? And what if you must
access the structure via the organizational units because the positions are not
hierarchically linked? In this case, you could use the Skip indicator for the
evaluation path. If you check the Skip fag in the frst row of the O-O-S evalu-
ation path (or in a copy), only the positions (object type S) are permitted, but
not the organizational units.
Figure 3.3 provides an overview of the interaction of the general and
structural authorization check. Every time objects of the HRP* database
table are accessed, the structural and general authorization checks are
performed. Only if both checks return a positive result will the authori-
zation be issued.
Now that weve explained the concept of the structural authoriza-
tion, the following section describes how you can confgure structural
authorizations.
Flexibility of the
structural check
165 [Link] 117 6/4/08 [Link] AM
[Link]
118
3 Structural Authorization Check
General
Authorization
Structural
Authorization
Controls Access
to Data (e.g., Infotypes)
Controls Access
to Objects (e.g., Positions)
Interaction of the General and Structural Authorization Checks Figure 3.3
Maintaining the Structural Profiles 3.2
You must maintain the structural profles outside of the role maintenance
(Transaction PFCG) in a specifc Transaction called Authorization Profles
(OOSP). Here, the profles are initially created independently of the users
and then, in a second step, assigned to the users (see Section 3.6, Assign-
ing Structural Profles to Users).
Figure 3.4 shows the maintenance parameters in the authorization profle
maintenance. The felds not shown in the fgure are described below:
Plan Version|
E
Can be left empty and if so, applies to all plan versions.
Object Type
E
(Almost) only internal object types of the HCM system including P
(Person) and AP (Applicant). For external objects, structural authori-
zation checks are only performed in exceptional cases (for example,
LW Logistics work center)
Transaction OOSP
Maintenance
parameters in
authorization
profle
maintenance
165 [Link] 118 6/4/08 [Link] AM
[Link]
119
Maintaining the Structural Profles 3.2
Profile No. PV Obj.
Type
Obj.
ID
Mainte-
nance
Eval.
Path
Status
Vector
Depth +/-
Sign
Period FM
i
abc 01 O 100 X O-S-P 1234 1 - F
i
xyz 1 01 O O-S-P 3 RH
i
xyz 2 01 C X
Plan Version Function Module
Processing Type
1 = active
2 = planned
3 = requested
4 = approved
5 = rejected
blank = all
D = Key Date
M = Current Month
Y = Current Year
P = Past
F = Future
Maintenance Parameters in Authorization Profle Maintenance Figure 3.4
External Object Types in Structural Authorizations
To determine whether a structural authorization check is performed for an
external object, you should use the following path in the IMG: Person-
nel management

Organizational Management

Basic Settings

Data
Model Enhancement

Maintain Object Types

External Object Types. Only

if PKEYS is entered in the Key structure feld and if the Inverse Relationship
fag is checked can you use this external object type in a structural authoriza-
tion. If you check this, for example, for the cost center, you will determine
that you cannot perform a structural authorization check for the cost center
in the standard version.
Maintenance
E

You can display the object and also maintain its respective infotypes.
Table T77FC indicates which functions are supposed to be considered
as maintenance functions. The check is only relevant if the mainte-
nance process is also permitted in the general authorization.
Depth
E

If the feld has the value 0 or is left blank, it indicates that all levels
under the root object are permitted; a number refers to the number
of the levels permitted under the root object (Figure 3.5).
Plus/Minus Sign
E

Reverses the direction for counting the depth (Figure 3.5).
165 [Link] 119 6/4/08 [Link] AM
[Link]
120
3 Structural Authorization Check
O
O O
S
P
O
S
P
Profile Evaluation Path Depth +/- Sign
A O-S-P
B O-S-P 1
C O-S-P 4
D O-S-P 1 -
O
O O
S
P
O
S
P
O
O O
S
P
O
S
P
Profile A Profile B Profile C
O
O O
S
P
O
S
Profile D
!
Effects of Depth and Plus/Minus Sign Figure 3.5
Period
E

Here, you defne how the responsibility of the structural authorization
is checked; for example, whether the user has to be authorized for
exactly this key date or only for the year in which he or she accesses
the data. See Section 3.7, Period of Responsibility and Time Logic, for
more detailed information.
Function module
E

The function module is maintained instead of the object ID; for more
information, see Section 3.3, Function Modules.
You can fnd the button next to the profle description. This button
calls the RHAUTH01 report. This report lists the objects that are included
in the structural profle and indicates the total number. The button pro-
vides an excellent check for whether the structural profle contains all
expected object types and object IDs. However, note that the personnel
number in the development system or test system has to be assigned to a
respective person in Organizational Management if the structural profle
determines the permitted objects based on the logged-on user.
The next section describes how a structural profle can dynamically
determine the start object instead of entering a defned ID in the Object
ID feld.
Checking
permitted objects
165 [Link] 120 6/4/08 [Link] AM
[Link]
121
Function Modules 3.3
Function Module 3.3 s
The structural authorization is pretty fexible. However, entering a defned
object ID as a root object is a rigid process and, therefore, requires a lot
of maintenance work. Changing the responsibilities in the context of
organizational restructuring often affects the structural profles and par-
ticularly the object IDs in this case.
Consequently, when designing the structural authorization, you should
always ask yourself whether the number of permitted OM objects can
be determined in another way than described previously.
Two examples:
In this example, a manager who uses the Managers Desktop or Man-
ager Self-Service is supposed to access the data of the employees hes
responsible for.
Usually, the managers responsibility is already mapped in OM. He holds
a position that is linked as a chief position with the subordinate organi-
zational unit. Additional positions and perhaps additional organizational
units, including the respective positions, are linked to his organizational
unit. The employees for which the manager is responsible hold these
positions.
This information enables you to dynamically determine the number of
permitted persons, as well as the root object from OM. This is done by
the default function module, RH_GET_MANAGER_ASSIGNMENT . In the
structural profle, this function module is used instead of the object ID
(Figure 3.6).
Structural Profle with Function Module Figure 3.6
Every manager is provided with the same structural profle. The function
module determines the root object as follows:
Managers
165 [Link] 121 6/4/08 [Link] AM
[Link]
122
3 Structural Authorization Check
It determines the personnel number of the logged-on user via Info- 1.
type 0105 (Communication), subtype SAP User Name (usually 0001).
It reads the position held by the person. 2.
It determines the organizational unit with which the position is linked 3.
as a manager this organizational unit is then reported to the struc-
tural profle.
With the identifed object ID, it continues with the stored evaluation 4.
path, O-O-S-P in this example, which determines the organizational
units, positions, and persons that are linked to the root organizational
unit.
This tool considerably increases the fexibility of the structural authoriza-
tion, because it automatically considers all changes that are made under
the root object, and the profle can also remain unchanged when the
manager changes his position (as long as he is still a manager) or when
he or his position is responsible for a different organizational unit. More-
over, you only need one structural profle for all managers.
The second function module supplied by SAP for this purpose is called
RH_GET_ORG_ASSIGNMENT. It also determines an organizational unit
as a root object, but doesnt use a manager relationship. Instead, the root
object is defned by the simple assignment Position belongs to organi-
zational unit.
In this second example, time administrators are supposed to be autho-
rized to maintain data of the employees in their own organizational
unit.
If time administrators are also responsible for organizational units to
which they are not directly assigned, you must create a specifc func-
tion module. This is quite simple. First, create a new relationship (e.g.,
Is time administrator for) and use it to link the position of the time
administrator to another organizational unit. Then, create a new evalua-
tion path by copying the ORGASS default evaluation path and extending
it by the customer-specifc relationship. Finally, copy the default function
module RH_GET_ORG_ASSIGNMENT, and only change the evaluation
path in this function module.
Function modules
reduce the number
of profles
Time
Administrators
Customer-specifc
function modules
165 [Link] 122 6/4/08 [Link] AM
[Link]
123
Transfer to Other Structures in SAP ERP HCM 3.4
Such function modules can use any data from the HCM system or from
customer-specifc tables to determine the root object.
Tip
Function modules of this type can return more than one root object. This
enables you to determine all authorized objects via the function module, if
required, and you dont have to specify an evaluation path at all. The objects
can have any object type, which can also deviate from the object type entry
in the structural profle.
Transfer to Other Structures in SAP ERP HCM 3.4
Structural authorization checks are critical wherever data is stored in
HRP* tables. The use of the felds in the profle maintenance fully cor-
responds to the one described in Section 3.2, Maintaining the Structural
Profles. You can also use the function modules that were introduced in
this section.
The following HCM components outside OM use the structural
authorization:
Training and Event Management including Learning
E
Solution
Here, the business event catalog forms the structure. Figure 3.7 shows
a sample restriction of the access to a subcatalog.
Structural Profle with Restriction to Subcatalog Figure 3.7
In this case, the root object is a business event group with object ID
50000467; the object types are L (Business event group), D (Business
event type), and E (Course).
Components of the
HCM system with
structural check
165 [Link] 123 6/4/08 [Link] AM
[Link]
124
3 Structural Authorization Check
Qualifcations
E

It also includes a catalog that defnes the structure: the qualifcation
catalog with object types QK (Qualifcation group), Q (Qualifcation),
and QB (Qualifcation block), if required.
Budget Planning and Position Control (Public Sector)
E

Object type BU (Budget Structure Element) has a hierarchical struc-
ture and can be structurally authorized via an evaluation path.
The HCM components mentioned so far each have their own hierarchi-
cal structure. The authorizations for these structures use the evaluation
path or function module. In addition, there are applications in SAP ERP
HCM that dont have a specifc structure, but nevertheless entries
without an evaluation path have to be made in the structural profles
(Figure 3.8). These are all subcomponents, which we havent mentioned
yet, for which the PLOG authorization object is responsible, namely:
Development plans with object type B (Development Plan)
E
Shift planning with object type SR (Planned staff requirement) (Figure
E
3.8)
Performance management with object type VA (Appraisal template)
E
VB (Criteria Group), and VC (Criterion)
E
Management of global employees with object type CP (Central
E
person).
Structural Authorization for Object Type SR (Requirement) Figure 3.8
In the HCM components described earlier, the structural authorization
is a required supplement to the single OM authorization object, Person-
nel Planning (PLOG, see Section 2.3.5). All data that is checked with this
object is also subject to the structural authorization check. You cannot
deactivate this check in the standard version.
The structural
check cannot be
deactivated here
165 [Link] 124 6/4/08 [Link] AM
[Link]
125
Use in Personnel Administration 3.5
However, you can deactivate it for personnel administration, because the
structural authorization check is only an option here. Well describe this
option in the next section.
Use in Personnel Administration 3.5
If the integration between OM and personnel administration is activated,
you can also use the structural authorizations for personnel administra-
tion (object type P). In this case, however, the ORGPD authorization
switch in the AUTSW group of Table T77S0 must have a value between
1 and 4 (Transaction OOAC (HR: Authorization main switch)). That
means, by assigning a value other than 0, you activate the structural
authorization for personnel administration. Section 3.8, How the Struc-
tural Authorization Check Handles Nonintegrated Persons, explains the
different meaning of the values 1 through 4.
The structural authorization check in personnel administration also uses
the fexibility of the structural authorization already described also for
personnel master data and time data. It represents an alternative for
using:
The Organizational Key feld in the P_ORGIN (HR: Master Data)
E
authorization object.
The different administrator IDs of Infotype 0001 in the P_ORGXX
E
(HR: Master Data Extended Check) authorization object.
As long as the organizational assignment of the persons is reliably main-
tained in OM, you dont have to maintain the mentioned felds in Info-
type 0001 if you use the structural authorization.
Example
Managers are only authorized to view a specifc selection of infotypes for the
employees of their organizational units.
For this purpose, the structural profle, MANAGER, described in Section 3.3,
Function Modules, is required. In the HR: Master Data object, you only have
to list the infotypes under INFTY and the R authorization level. No organiza-
tional restrictions are required.
Authorization main
switch
165 [Link] 125 6/4/08 [Link] AM
[Link]
126
3 Structural Authorization Check
You must consider the following aspects for maintaining the structural
profles in conjunction with the infotypes of personnel administration:
The evaluation path in the profle maintenance must include object
E
type P.
The combination of the structural authorization with the organiza-
E
tional felds of the authorization objects, HR: Master Data and HR:
Master Data Extended Check, is an AND link. That means the check of
the default object and the structural check both have to be successful
to assign an authorization.
Although the structural authorization is the preferred method for per-
sonnel administration in most cases, you must take the following into
account: The fully accurate maintenance of Organizational Management
is an essential prerequisite for a consistent structural authorization pro-
tection; however, the structural authorization is more complex than the
general authorization alone. Consequently, theres a great deal of learn-
ing effort involved for the affected administrators, as well as testing
effort for confguring and changing the authorizations.
Tip
You can also activate the structural authorization check in the (classic) recruit-
ment using a switch. See Chapter 5 for more detailed information.
Assigning Structural Profiles to Users 3.6
Transaction OOSB (User Authorizations), shown in Figure 3.9, is used to
assign the profles to users.
Assigning Profles to Users Figure 3.9
Disadvantages of
the structural
authorization
check
165 [Link] 126 6/4/08 [Link] AM
[Link]
127
Assigning Structural Profles to Users 3.6
In this transaction, the structural profles together with a validity
period are assigned to the users. A user may have several structural
profles.
If you check the Exclusion feld, the profle is negative, that is, it indi-
cates all objects that the user is not authorized to view or edit. The
Information button works in the same way as in profle maintenance: It
displays the permitted objects.
What happens if the table doesnt contain entries for a specifc user? In
that case, the authorization check uses the entry of the SAP* user. So, the
profle stored for this user is applicable if an entry has been left out. That
means you have two possible alternatives:
Leave everything as it has been provided by SAP: SAP* provides an ALL
profle that contains the full structural authorization for all object types.
This is advisable if you use the structural authorization only for a small
user community, and if the other users were assigned with an unre-
stricted structural authorization anyway.
If you want to avoid a user that isnt assigned to a profle at all, that is,
if you dont want a structural authorization to be issued in this case,
you must create an empty profle and assign it to the SAP* user. The
empty profle could, for example, contain only an object type that you
dont use. Alternatively, you can delete the entry for SAP*. In this case,
too, the user to which no structural profle is assigned doesnt have an
authorization.
These two variants are useful if you have to maintain multiple struc-
tural authorizations. They prevent you from assigning the SAP*
authorization to users by mistake that arent supposed to have this
authorization.
This becomes more important if Transaction OOSB (User Authorizations)
does NOT check the users input.
Fall-back to SAP*
Alternative 1
Alternative 2
165 [Link] 127 6/4/08 [Link] AM
[Link]
128
3 Structural Authorization Check
Assigning a Profle to the SAP* User
If most of the users are supposed to get the same profle, it may be useful to
assign this profle to the SAP* user.
Lets look at an example: All time administrators are authorized to edit
data of the employees in their own organizational unit. If an enterprise had
10,000 employees, approximately 100 time administrators would have the
same structural profle with the RH_GET_ORG_ASSIGNMENT function mod-
ule. If you assign the time profle instead of the 100 entries to the SAP*
user, you can avoid a great deal of maintenance effort. At the same time, it
would be a minimum fall-back profle for users who havent been assigned
by mistake.
Period of Responsibility 3.7 and Time Logic
In Organizational Management, all relationships have a validity period .
For example, if an employee changes the organizational unit and is trans-
ferred to a new position, a new relationship period for the new position
starts (Figure 3.10).
Stefanie Graf Changes the Organizational Unit as of 11/06/2007 Figure 3.10
165 [Link] 128 6/4/08 [Link] AM
[Link]
129
Period of Responsibility and Time Logic 3.7
When maintaining the structural profles (Transaction OOSP), you can
restrict the structures validity period to the current key date (Figure
3.11), current month, current year, past, or future (see Section 3.2, Main-
tenance of the Structural Profles).
The Analysis of All Persons the Manager is Responsible for is Carried out Figure 3.11
on the Key Date (D)
Therefore, for this restriction it is always checked whether there is an
intersection with the relationship period along the structure. If the check
can be carried out down to the lowest level the person the period
of responsibility is identical with the relationship period (between per-
son and position).
In the following section, the different values are described that the peri-
ods of responsibility for the leads of Org Units A1 and A2 can have in the
PERIOD column. You can also use Figure 3.12 for orientation. A struc-
tural profle as shown in Figure 3.11 and the system date 11/06/2007
are required:
Period = D (Key Date)
E
Only the manager of OrgUnit A2 can view the person (11/06/2007).
Period = F (Future)
E
Only the manager of OrgUnit A2 can view the person (11/06/2007
to 12/31/9999).
Period = M (Month)
E
Both leaders can view the person (11/01/2007 to 11/30/2007).
Period = Y (Year)
E
Both leaders can view the person (01/01/2007 to 12/31/2007).
Period = P (Past)
E
Only the manager of OrgUnit A1 can view the person (01/01/1800
to 11/05/2007).
165 [Link] 129 6/4/08 [Link] AM
[Link]
130
3 Structural Authorization Check
Period = Blank (All)
E
Both leaders can view the person (01/01/1800 to 12/31/9999).
OrgUnit A2
05/01/200012/31/9999 05/01/200012/31/9999
05/01/200012/31/9999
OrgUnit A
OrgUnit A1
05/01/200012/31/9999
01/01/200711/05/2007 11/06/200712/31/9999
Position A1
Person
Position A2
Organizational Change as of 11/06/2007 Diagram Figure 3.12
The PLOGI ADAYS authorization switch extends the validity period of
the structural profle. By default, the default value of the switch is blank
(Figure 3.13).
Standard Version of PLOGI ADAYS Figure 3.13
This setting in combination with the key date validity of the analysis of
the persons (see Figure 3.11) would mean that the leader, Franz Becken-
bauer (see Figure 3.10), can no longer view his employee, Stefanie Graf,
as of 11/06/2007. You can quickly check this by selecting the button
in the assignment of the profle to the user (Transaction OOSB) or start-
ing the RHAUTH01 (Show Authorization Views) report. The result is
shown in Figure 3.14.
Grace period for
structure period
165 [Link] 130 6/4/08 [Link] AM
[Link]
131
Period of Responsibility and Time Logic 3.7
The Manager Can No Longer View His Employee as of 11/06/2007 Figure 3.14
Set the grace period above the PLOGI ADAYS authorization switch to 20
days (Figure 3.15), for example. Then, Franz Beckenbauer can view his
employee again (Figure 3.16).
Grace Period of 20 Days Figure 3.15
Extension of the Relationship Using PLOGI ADAYS Figure 3.16
Maintaining PLOGI ADAYS
You wont fnd the PLOGI ADAYS authorization switch in the Maintain Au-
thorization Main Switches IMG activity, where the other switches of the
AUTSW group can be found. To maintain the PLOGI ADAYS switch, navigate
directly to the table maintenance of T77S0. Dont get confused by the docu-
mentation for this switch ((F1) help). Its incorrectly identical to the documen-
tation for the AUTSW ADAYS authorization switch (see Section 2.6, Period of
Responsibility and Time Logic). SAP Note 375216 explains the functionality
of this switch, which is available from Release 6.20 onward, in more detail.
165 [Link] 131 6/4/08 [Link] AM
[Link]
132
3 Structural Authorization Check
If you use the general and structural authorization with both authoriza-
tion switches, the following applies for our example of an organizational
change as of 11/06/2007, as well as the key date 11/06/2007:
As long as the manager, Franz Beckenbauer, cannot view his employ- 1.
ee, Stefanie Graf, via the structural profle, he cannot do anything.
If you extend the structural profle by a grace period using PLOGI 2.
ADAYS, the manager can view Stefanie Graf and read/analyze her data
for the past. However, he cannot maintain infotypes (for which the
access authorization in Table T582A is activated) for Stefanie Graf.
If the period of responsibility of the general authorization is addition- 3.
ally extended via AUTSW ADAYS, the manager can maintain info-
types for Stefanie Graf for this tolerance period.
Usually, a blank in the date feld is suffcient for the structural profles of
central areas. For decentralized profles, use Y for users with read access
and D for users with write access for further restrictions.
Lets summarize the essential aspects for the periods of responsibility
and time logic once again:
The period check of the structural authorization is executed prior to
E
the period check of the general authorization.
The period of responsibility of the structural authorization arises from
E
the last relationship period if the check has a positive result.
The period of responsibility is transferred to the general authorization
E
and further restricted, if required.
The period check can be extended by a tolerance period in the gen-
E
eral authorization using the AUTSW ADAYS authorization switch and
in the structural authorization using the PLOGI ADAYS authorization
switch.
Of course, the responsibility period and period checks can only be per-
formed for persons that are linked to the organizational structure. How-
ever, specifc person groups (for example, trainees or retirees) are often
not included in the organizational structure. The next section describes
how the system handles nonintegrated persons.
AUTSW ADAYS
and PLOGI ADAYS
combined
Best practice
Summary
165 [Link] 132 6/4/08 [Link] AM
[Link]
133
How the Structural Authorization Check Handles Nonintegrated Persons 3.8
How the Structural Authorization Check 3.8
Handles Nonintegrated Persons
In personnel administration, the structural authorization only records
persons that are integrated in Organizational Management. Persons that
are excluded from the integration via the PLOGI characteristic are not
considered in the structural check. This also applies to persons for which
no position has been entered in Infotype 0001, that is, the infotype still
contains the default position (usually 99999999).
Linking the nonintegrated persons with the organizational structure via
special evaluation paths such as the temporary assignment relationship
doesnt solve the problem. The structural check still ignores noninte-
grated persons.
To control how these persons are handled with regard to authorizations,
the authorization switches, AUTSW ORGPD and AUTSW DFCON, are
provided. Their values 1 to 4 have the same meanings. ORGPD controls
the normal authorization check while DFCON controls the context-sen-
sitive check. You can maintain the switches via IMG path Personnel
Management

Personnel Administration

Tools

Authorization
Management

Maintain Authorization Main Switches

Maintain
Authorization Main Switches.
Initially, the four switch settings enable you to use the Organizational
Unit feld of Infotype 0001 for the authorization check. If you want
to use the settings, you must enter all authorized organizational units
separately into the structural profle (see example in Figure 3.17). Then,
you must decide whether the authorization is supposed to be rejected
or issued if an organizational unit is missing. This results in the follow-
ing combinations:
Switch setting 1: The organizational unit is analyzed, no authorization
E
is issued if it is not maintained.
Switch setting 2: The organizational unit is not analyzed, an authori-
E
zation for persons without an integrated position is generally rejected
(makes only sense if all persons are integrated).
Authorization main
switch
Rules for checking
nonintegrated
persons
165 [Link] 133 6/4/08 [Link] AM
[Link]
134
3 Structural Authorization Check
Switch setting 3: The organizational unit is analyzed, an authorization
E
is issued if it is not maintained.
Switch setting 4: The organizational unit is not analyzed, an authori-
E
zation for persons without an integrated position is generally issued.
Organizational Units for Nonintegrated Persons Figure 3.17
Exceptions for DFCON
While switch setting 0 of the ORGPD switch deactivates the structural au-
thorization check for personnel master data, the DFCON authorization switch
differentiates between 0 and 1 as follows (see SAP Note 647278):
1: Only users with unrestricted access (that is, * in all felds of the context-
dependent authorization object including the PROFL feld) can access non-
integrated persons whose organizational unit is not maintained.
0: Users with restricted master data access (for example, for personnel areas)
but * in the PROFL feld can also access nonintegrated persons whose
organizational unit is not maintained.
Performance Optimization 3.9
The performance of the structural authorization check results from the
number of read accesses required to determine whether a specifc object
is permitted or not. The larger the number of different object types with
different evaluation paths contained in the profle and the more objects
that exist under the root, the longer the access times.
If some object types may be viewed completely, such as the entire quali-
fcation catalog, the evaluation path shouldnt contain a root object and
evaluation path (Figure 3.18).
Use as few
evaluation paths as
possible
165 [Link] 134 6/4/08 [Link] AM
[Link]
135
Performance Optimization 3.9
Profle Without Evaluation Path Figure 3.18
An additional potential for optimization is to use as few evaluation paths
as possible. For example, combine all object types that you determine via
the organizational structure into one evaluation path. Have the structural
check read the organizational hierarchy only once in order to determine
all permitted organizational units, positions, persons, jobs if required,
work centers, and so on.
In addition, make sure that only evaluation paths with a specifed tar-
get object are used. The evaluation path illustrated in Figure 3.19, lists
all objects linked to the position. Depending on the system landscape,
this may include, for example, object types US (User) or BP (Business
Partner), which then would be unnecessarily included in the structural
check.
Evaluation Path With Nonspecifed Target Object Figure 3.19
The optimization measures described so far reach their limits when users
are authorized to view or edit a large quantity of objects of the structural
check. In this case, the structural check, which is carried out online on an
ongoing basis, leads to unacceptable response times. For these situations,
a procedure is provided by default. It enables you to store the informa-
tion on the permitted objects of a user in the SAP memory. Then, the
accesses to the SAP memory have a high performance.
Buffering large
data quantities
165 [Link] 135 6/4/08 [Link] AM
[Link]
136
3 Structural Authorization Check
As a prerequisite, you must enter the affected users (it doesnt have to
and shouldnt include all users) in Table T77UU. There are two possible
alternatives:
You can maintain Table T77UU manually in IMG activity Personnel
Management

Organizational Management

Basic Settings

Authorization Management

Structural Authorization

Save User
Data in SAP Memory. Here, you enter the number of days that are sup-
posed to pass between the automatic updates of the SAP memory for the
respective user. The date of the last update of the system is stored here
as well (Figure 3.20).
Maintaining Table T77UU User with SAP Memory Figure 3.20
Instead of maintaining Table T77UU manually, you can also use the
RHBAUS02 report (Check and Compare T77UU (User Data in SAP Mem-
ory)). In the standard system, you can start the report only via System

Services

Reporting (Transaction SA38). The report maintains Table

T77UU by means of a threshold value. The value results from the num-
ber of permitted objects that correspond to the structural authorization.
When the report is executed (as shown in Figure 3.21), the system enters
all users with an object quantity above 1,000 in Table T77UU or deletes
users with an object quantity below this value from the table.
RHBAUS02 Report Check and Compare T77UU Figure 3.21
Manual
maintenance in the
IMG
Automatic
maintenance using
RHBAUS02
165 [Link] 136 6/4/08 [Link] AM
[Link]
137
Extensions 3.10
Regardless of your entries in Table T77UU, if the Days feld is left empty,
the SAP memory is not automatically supplied. Instead, you must ensure
that the RHBAUS00 (Regeneration INDX for Structural Authorization)
report runs properly. You can start it in batch mode on a regular basis (for
example, hourly), or it can run online, if required. It runs for the users
that have been defned in the selection screen.
The consequence of all procedures of regular SAP memory updates
described previously is that changes to the objects, for example, the
organizational structure, for the defned users reach the authorizations
with a delay.
Tip
The online update of the SAP memory is not supported in the standard ver-
sion. SAP Note 421399 provides information on how you can modify the
standard settings.
There are situations in which even the SAP memory reaches its perfor-
mance limits. This is the case when the SAP memory area provided for
authorization purposes gets too small due to a considerably large num-
ber of users with a high quantity of permitted objects. In these cases,
the structural authorization check must be replaced by a customer-spe-
cifc authorization check for this user category. For this purpose, you
can use the Business Add-In (BadI) of the structural authorization check,
HRBAS00_STRUAUTH. This BAdI is described in greater detail in the
following section.
Extensions 3.10
BAdIs enable you to implement requirements for the authorization check
that exceed the SAP standard without having to modify it. They also
enable you to change the standard coding at places predefned by SAP
and implement customer-specifc checks. From Release 4.6C onward,
the authorization check provides a BAdI for the structural authorization
check.
The HRBAS00_STRUAUTH BAdI is called for any structural authorization
check before the check is actually executed. Then, the BAdI allows you
If nothing
else helps
165 [Link] 137 6/4/08 [Link] AM
[Link]
138
3 Structural Authorization Check
to issue or reject the structural authorization while avoiding the standard
checks.
You can fnd the BAdI in the IMG via Personnel Management

Organi-
zational Management

Basic Settings

Authorization Management

Structural Authorization

BAdI: Structural Authorization. The

corresponding documentation is also provided here.
The BAdI is comprised of six methods; two of them are described below
as examples:
CHECK_AUTHORITY_VIEW
E

This method serves to check the structural authorization of a user for
an object. This method is supposed to reduce runtime problems. As a
result of the check in this method, you obtain the information that the
user has or doesnt have authorization for a specifc object or that a
new object to be checked (CHECK_OBJECT_OUT) is transferred. In that
case, the standard check with the built-up view is used. You can control
this by setting the transferred EXIT_FLAG switch to initial. If you dont
want to use the standard coding, you must set the switch to X.
CHECK_AUTHORITY_SEARCH
E

This method serves to check the structural authorization within the
Search Function or the input help. For this purpose, the hit list
is transferred for clean-up purposes. The plan version that is sup-
posed to be checked and the permitted object types are transferred
to the method in the PLVAR and OTYPES parameters. In addition,
the complete hit list is available in the OBJECTS table that can be
changed if required. The check deletes all entries from the hit list
for which the user doesnt have a structural authorization.
If you set the SKIP_STANDARD switch to X upon return, the search
function doesnt execute another structural authorization. If you set
the SKIP_STANDARD switch to (blank), the standard check of the
structural authorization is performed.
At this point, we want to provide some examples of how you can use
BAdIs.
For users with central authorizations in Organizational Management, the
response times were insuffcient although the SAP memory was used.
This was probably caused by the large number of this category of users.
Examples
Insuffcient SAP
memory
165 [Link] 138 6/4/08 [Link] AM
[Link]
139
Extensions 3.10
Consequently, for a specifc user community within the BAdIs, the struc-
tural authorization check was deactivated and replaced by a customer-
specifc authorization check. In the maintenance of the structural pro-
fles, the respective users were identifed by a specifc profle. Because
this profle issues unrestricted structural authorizations, it doesnt fll the
table of the permitted objects.
The BAdI recognizes that the structural check hasnt been performed by
the name of the profle and navigates to the check of a customer-specifc
authorization object. This object contains the company codes for which
the user is authorized. The BAdI checks whether the object of Organi-
zational Management that is supposed to be checked is linked with a
permitted company code.
The company code is a standard object type of OM called IC. The rela-
tionship to the company code is written with a customer-specifc pro-
gram, which is continuously running.
To enable administrators or assistants to book a business event for an
employee, they require a maintenance authorization for the event. How-
ever, if the business event catalog is exclusively maintained centrally,
a confict in the authorization assignment arises. The HRBAS00_STRU-
AUTH BAdI must be used in order to allow for access to specifc person
groups regardless of the action to be performed (for example, book-
ing an event for all employees, analyses and follow-up processing only
for a selection of employees). In general, the structural authorization
is granted if all actions are allowed for a group of employees. In other
cases, the BAdI controls the access to employees depending on the trans-
action. It may cause problems that different actions in SAP Training and
Event Management are sometimes executed with identical transactions.
As an alternative, you can defne in the BAdI that the structural autho-
rization is only supposed to be assigned to employees with restricted
actions, and that the access authorization for these employees is with-
drawn for other transactions.
Assistants are supposed to maintain business trips for selected per-
sons. However, they dont use Organizational Management. That
means, it is no longer possible to check any authorization via the orga-
nizational structure. The permitted personnel numbers are assigned
Training and Event
Management
Missing
Organizational
Management
165 [Link] 139 6/4/08 [Link] AM
[Link]
140
3 Structural Authorization Check
to the assistant in a Customizing table. This table is queried by BAdI
HRBAS00_STRUAUTH.
Tip
For BAdI HRBAS00_STRUAUTH, you must always implement all methods.
Immediately after creating the implementation, you can fnd a sample cod-
ing in the menu via Goto

Sample Code

Display or in the CL_EXM_IM_

HRBAS00_STRUAUTH class.
Critical Success Factors 3.11
The following section describes some critical success factors that you
must take into account when using the structural authorization check:
Keep your Organizational Management reliably maintained and up-
E
to-date. Maintenance is reliable only if Organizational Management
is integrated with personnel administration. As soon as the structural
authorization is used, the maintenance in Organizational Manage-
ment can directly affect the authorizations.
In the structural authorization check, you should use as many func-
E
tion modules as possible and simplify the maintenance in this way.
For this purpose, it is always useful to use the existing information of
Organizational Management via function modules.
Pay attention to the response times, particularly for users that can
E
access multiple objects. If required, use the optimization options
described in Section 3.9, Performance Optimization. As your Organi-
zational Management usually grows along with the increasing number
of components you implement and the longer it is in use, you should
check the performance for critical users carefully at regular intervals.
Cautiously determine which of the variants of handling SAP* described
E
in Section 3.6, Assigning Structural Profles to the Users, you want to
select. In any case, make sure that not too many authorizations are
assigned by mistake.
Dont forget to implement appropriate authorization protection for
E
people not integrated with Organizational Management (see Section
3.8, How the Structural Authorization Check Handles Nonintegrated
Persons).
165 [Link] 140 6/4/08 [Link] AM
[Link]
331
Index
A
Administrative services, 178
Administrator, 70
ALL (Profle), 127
Analysis of users with critical
authorizations, 246
Applicant, 195
Applicant management, 195
Application Link Enabling (ALE), 226
Appraisal, 173, 185, 222
Appraisal system, 158
Appraisal template, 185
Assigning structural profles, 126
Attendance
following up, 222
attendances, 222
Auditor, 157
AUTHORITY-CHECK, 264
Authorization, 292
critical, 246
execute programs in the background,
292
missing, 266
overview of the most vital ones of a
user, 250, 258
Authorization administrator, 22, 229
Authorization administrators, 16
Authorization check
context-dependent, 141, 323
deactivate using SAP function
modules, 260
directly in coding, 264
general, 41, 323
SAP function modules with, 260
structural, 115, 325
Authorization checks
programming, 259
Authorization concept, 21
redesign, 241
Authorization data administrator, 231
Authorization error
analysis, 275
Authorization errors
check, 252
Authorization feld, 47
Authorization level, 65
Authorization (main) switch, 323
Authorization object, 42, 60, 323
customer-specific, 107
Authorization object class, 42
Authorization profle, 43, 144, 323
Authorization profle administrator, 231
Authorization trace, 277, 323
Authorization value, 47
AUTSW ADAYS, 131
AUTSW DFCON, 133
AUTSW ORGPD, 133
B
B2A Manager, 155
Background user for workfow, 176
BAdI, 323
HRBAS00_GET_PROFL, 147
HRBAS00_STRUAUTH, 137, 203
HRHAP00_AUTHORITY, 189
HRPAD00AUTH_CHECK, 108
HRPAD00CHECK_TIME, 98
HR_PY_AUTH_PU01, 157
Batch input sessions, 86
B_BUPA_ATT, 170
B_BUPA_FDG, 170
B_BUPA_GRP, 170
B_BUPA_RLT, 171
Budget planning, 160
Buffer, 251
Business event catalog, 123
Business partner, 170
Index
165 [Link] 331 6/4/08 [Link] AM
[Link]
332
Index
C
CALL TRANSACTION, 200
Candidate
external, 168, 175
internal, 168
CATS, 163
Central personnel number, 181
Central system, 226
Central user administation, 35
Central user administration, 226, 287
Change documents, 258
Child system, 226
Cluster, 72, 152
Collaboration Projects, 206
Commitment creation, 162
Communication user, 175
Comparison of users from different
systems, 257
Component supervisor, 77
Composite role, 53, 324
Composite roles, 256
Content management, 222
Content Management, 224
Context authorization object, 144
Context-sensitive authorization check
<Pfeil>R<Normal> see Authorization
check, 323
Cost planning, 211
Course Content Player, 223
Customizing authorization, 85
D
Data entry profle, 163
Data protection offcer, 17
Decision-maker, 16
Default position, 133
Default value, 90
Document access, 172, 177
Document set, 177
Document Set, 171
Download authorization, 86, 270
Double-verifcation principle, 25, 65, 302
Duet, 214
Dynamic action, 302
E
Emergency user, 269
Employee Self Service, 206, 214
employment period calculation, 210
E-recruiting, 166
Evaluation path, 116
Excel download, 270
Execute programs in the background, 80
External object types in structural
authorizations, 119
F
Financing, 162
Financing rule, 162
Following up attendances , 222
Form, 156
F_TRAVL, 216
Full authorization, 48
Function code, 76
Function module, 120, 121, 125
G
Global employee, 180
Grace period, 131
H
HR Admin, 178
HR-Forms, 156
HR Reporting with SAP, 45
HR service catalog, 31
Human Resources Information System,
207
165 [Link] 332 6/4/08 [Link] AM
[Link]
333
Index
I
Indirect user assignment, 235
Information system, 245
InfoSet, 81
switch, 304
Infotype
Vacancy, 192
virtual, 163
Infotype screen control, 300
Inheriting a menu, 57
Interaction of the general and structural
authorization check, 141
Internet Communication Framework,
171
J
Job scheduling, 79
L
LDAP directory access, 177
Logical database, 207, 267
customer-specific, 267
enterprise-specific, 267
handling of missing authorizations,
266
with own authorization check, 267
logische Datenbank, 266
M
Maintain time data, 200
Management of global employees, 181
Managers Desktop, 180
Manager Self Service, 214
Mass comparison , 240
Mass transport of roles, 239
Memory overfow, 263
Menu, 44
N
Naming convention, 35, 54
Non-integrated persons, 133
Number range maintenance, 87
O
Object manager, 192
Object type, 117
skip, 116
Organizational key, 68
Organizational level, 56, 60, 147, 237,
324
Organizational level feld, 59
Organizational management, 161, 182
Overview
of all authorization objects of a user,
251
of the most vital authorizations of a
user, 250, 258
P
P_ABAP, 209
P_APPL, 195, 204
P_ASRCONT, 178
Payroll, 152, 161
Payroll Process Manager, 154
Payroll result, 157
delete, 157
Payroll results, 211
P_B2A, 155
P_CATSXT, 165
P_DEL_PERN, 88
P_ENCTYPE, 162
P_ENGINE, 162
Performance management, 184, 205,
222
Performance optimization, 134, 140,
261, 298, 324
Period of responsibility, 94, 120, 128
Period of Responsibility, 41
165 [Link] 333 6/4/08 [Link] AM
[Link]
334
Index
Personnel administration, 178, 190,
205, 207, 211, 221
Personnel control record, 153
Personnel cost planning, 211
Personnel development, 201
Personnel number check, 71
Personnel planning, 182
P_EXMGRP, 162
P_FINADM, 162
P_HAP_DOC, 148, 173, 185, 222
context-dependent check in, 187
P_HRF_INFO, 156
P_HRF_META, 157
PLOG, 67, 74, 116, 182
PLOG_CON, 148
PLOGI ADAYS, 130
P_LSO_FOUP, 222
P_LSO_TU, 224
P_NNNNN, 68, 104
P_NNNNNCON, 145
P_ORGIN, 64
P_ORGINCON, 144
P_ORGXX, 69
P_ORGXXCON, 145
Portal, 189, 214
Posting document, 154
Posting run, 154, 212
P_PBSPWE, 154
P_PCLX, 72, 207
P_PCR, 153
P_PEPSVAR, 201
P_PERNR, 71, 280
P_PYEVDOC, 154
P_PYEVRUN, 154, 212
P_RCF_ACT, 174
P_RCF_APPL, 174
P_RCF_POOL, 174
P_RCF_STAT, 174
P_RCF_VIEW, 174
P_RCF_WL, 174
Printout, 80
Process analysis, 26
Process Workbench Engine, 154
Profle Generator, 43, 88, 324
Customizing switch, 235
initial installation, 233
Profle name, 230
Profle parameter, 234
PROFL, 107
Programmer
authorizations for, 269
Programmers, 16
Programming, 259
Programming guidelines, 270
Project managers, 16
Project team member, 16
P_TRAVL, 216, 298
Q
Qualifcation catalog, 124
Query, 81
switch, 304
R
Read access, 96
Receiving system, 228
Recruitment, 194, 207
Redesign, 22
Redesigning an authorization concept,
241
Reference model, 32
Reference role, 55, 242
Reference user, 175, 324
Relationship period, 129
Report
according to logon date and password
change, 257
call, 77
change documents for users, 258
comparisons, 257
customer-specific, 259
downloading from, 270
PFCG_TIME_DEPENDENCY, 289
RHAUTHUPD_NEW, 289
start, 292
without logical database, 208, 259
Reporting, 207, 267
Return code, 278
RFC authorization, 154, 222
RHBAUS00, 137
165 [Link] 334 6/4/08 [Link] AM
[Link]
335
Index
RH_GET_MANAGER_ASSIGNMENT,
121
RH_GET_ORG_ASSIGNMENT, 122, 128
Role, 43, 323
inheritance, 324
mass transport, 239
test, 233, 237
transport, 233
Role assignment
direct, 48
in Organizational Management, 53
Roles by complex selection criteria, 253
Root object, 121
S
SAP_ALL, 146, 235
SAP Expert Finder, 176, 206
SAP function modules, 260
SAP Learning Solution, 205, 218
SAP memory, 135, 138
SAP NetWeaver portal, 212
SAP NetWeaver Portal, 178
SAP* (user), 127, 298
S_BDC_MONI, 86
S_BDS_D, 172, 177
S_BDS_DS, 171, 177
Screen modifcation, 300
S_DEVELOP, 269
Self Services, 212
Sending emails, 303
Service user, 176
S_GUI, 86, 270
Shift plan, 200
Shift planning, 198, 206
S_ICF, 171
Single role, 44, 53, 256
Single sign-on, 214
S_LDAP, 177
S_MWB_FCOD, 180
S_NUMBER, 87
S_OC_SEND, 156
Spool access, 80
S_PROGRAM, 77
S_PROJECT, 85
S_QUERY, 82
S_RFC, 222, 223
S_RFCACL, 172
ST01, 277
S_TABU_DIS, 83
S_TABU_LIN, 84
S_TMS_ACT, 153
Structural authorization check
dynamic start object, 30
static start object, 34
Structural profle, 118
maintain, 118
Structure search, 192
SU53, 275
Substitution rule, 23
Support package, 281
S_USER_AGR, 231
S_USER_AUT, 231
S_USER_GRP, 232
S_USER_PRO, 232
S_USER_SAS, 233
S_USER_SYS, 227
S_USER_TCD, 232
S_USER_VAL, 232
System administrator, 77
System authorization, 77
System trace, 277
T
Table maintenance, 83
Talent Pool, 174
Template, 230
TemSe object, 153
Testing roles, 237, 241
Test procedure, 99, 324
Time logic, 94, 128
Time management, 190
Time sheet, 165
for service providers, 165
Time statement, 208
To-do list, 174
Tolerance period, 95, 281
Training and Event Management, 205,
218
Transaction authorization, 61
Transaction variant, 306
165 [Link] 335 6/4/08 [Link] AM
[Link]
336
Index
Travel management, 215, 298, 299
Travel planning, 216
Travel Planning, 216
Troubleshooting, 275
U
UGR user parameter, 300
Unsolicited application, 196
Updating in FI/CO, 154
User, 323
User administrator, 231
User assignment
indirect, 51
User group, 232
User Management Engine (UME), 214
User master comparison, 240
User type, 174
V
Vacancy, 192
Validity period, 128
Variant maintenance, 80
Variant transaction, 306
W
Write access, 96
165 [Link] 336 6/4/08 [Link] AM
[Link]