SAP Online Help
16.04.2002
Authorizations in
mySAP HR
H T U A R H . P L E H
Release 46C
Authorizations in mySAP HR
50A
1
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 trad emarks 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. JAVA®is 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.
Authorizations in mySAP HR
50A
2
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 trad emarks 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. JAVA®is 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.
Authorizations in mySAP HR
50A
2
SAP Online Help
16.04.2002
Contents Authorizations Authorizations in mySAP HR .........................................................6 HR .........................................................6 1 General Authorization Authorization Check.................................................... 6 1.1
Setting Up General Authorization Checks................................................................... 7
2 Structural Structural Authorizati Authorization on Check 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 Technical Aspects Aspects .................................................................. 18 3.1
Authorization Objects ............................................................................. ................................................................................................ ................... 18
3.1.1
P_CH_PK (HR-CH: Pension Fund: Account Access)........................................ 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: (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 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 Number Check) .............................. 34
3.1.21
P_ORGXX (HR: Master Master Data – Extended Check) ............................................. 37
3.1.22
P_TCODE (HR: Transaction Code) 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 Manager’s 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
Authorizations in mySAP HR
50A
3
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 Procedur es) ........................................................... 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.1Flowchart 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
Authorizations in mySAP HR
50A
4
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
Authorizations in mySAP HR
50A
5
SAP Online Help
16.04.2002
Authorizations in mySAP HR Purpose Authorizations control system users’ access to system data and are therefore a f undamental 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 r elease 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.
1
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.
Authorizations in mySAP HR
50A
6
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 user’s authorizations for the different authorization o bjects 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 O wn Data [page 82]
•
Administrator Should Not Be Allowed to Ent er 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
Authorizations in mySAP HR
50A
7
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 user’s 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).
Authorizations in mySAP HR
50A
8
SAP Online Help
2
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:
Authorizations in mySAP HR
50A
9
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:
Authorizations in mySAP HR
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
O
B002
is line supervisor of
O
O
B003
incorporates
S
S
A008
holder
P
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:
Authorizations in mySAP HR
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 num ber of objects from an existing structure. This exact combination or the objects returned by this combination, represents a user’s 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).
Authorizations in mySAP HR
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 = ). 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.
Authorizations in mySAP HR
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 ) or enter a + sign, the structure is processed in the normal “top down” manner.
•
Period In this field, you can define the profile according to the validity period of the structure. You can enter the following options: Key date, all, and different periods such as current year, current month and so on. If you select the entry D (current day), the structural authorization is limited to the structures valid on the current day. If you define a structural authorization for a manager using period D, the manager is authorized to access data on all persons who are currently in the manager’s group. If you do not make an entry (default value ), the structure is not limited by validity period. If you define the profile using the period, the manager is authorized to access data on former or future employees in addition to the authorization in the above example.
Authorizations in mySAP HR
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: (= all) If you enter (= 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.
Authorizations in mySAP HR
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.
O1
A012 = "is manager of"
O2
A003 S1
B008
A268
S2
P1
B008
A268 US2
−
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.
Authorizations in mySAP HR
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 user‘s 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.
Authorizations in mySAP HR
50A
17
SAP Online Help
3
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] Time Logic [page 49] 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 car ry 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
Authorizations in mySAP HR
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 employee’s 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 Manager‘s 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]
Authorizations in mySAP HR
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] authorization object.
Structure The P_DE_BW authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
Long Text
BEWID
Statement Identifier
BSUBJ
InfoSet Identification for Statements
BACT
Activities for Statements in Authorization Check
Authorizations in mySAP HR
50A
20
SAP Online Help
16.04.2002
More Information About the Fields •
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 check:
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 check:
Authorization Field
Long Text
BUKRS
Company Code
ACTVT
Activity
Authorizations in mySAP HR
50A
21
SAP Online Help
16.04.2002
More Information About the Fields 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 check:
Authorization Field
Long Text
P_OCTYP
Type of Off-Cycle Activity
More Information About the Fields 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 check:
Authorization Field
Long Text
PBEN_AREA
Benefit Area
ACTVT
Activity
More Information About the Fields The ACTVT field contains the activities for benefits that are possible as part of the authorization check. The field can have the following values:
Authorizations in mySAP HR
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 check:
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
More Information About the Fields •
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)
Authorizations in mySAP HR
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 check:
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 check:
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. Forms.
Structure The P_HRF_INFO authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
Long Text
MOLGA
Country Grouping
P_HRF_INET
HR Forms: InfoNet
ACTVT
Activity
More Information About the Fields The ACTVT field contains the activities for the InfoData maintenance of HR Forms that Forms that are possible as part of the authorization check. This field can have the following values: 02: Change
Authorizations in mySAP HR
50A
24
SAP Online Help
16.04.2002
03: Display
3.1.11 P_HRF_META (HR: Authorization Authorization Check Master Data Maintenance for HR Forms) Definition Authorization object that is used during the authorization check for HR Forms. Forms. You can carry out different actions in the HR Forms application. 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 check:
Authorization Field
Long Text
P_HRF_TYP
HR Forms: Object Type
MOLGA
Country Grouping
P_HRF_MOBJ
HR Forms: MetaData Object
ACTVT
Activity
More Information About the Fields The ACTVT field contains the activities for the MetaData maintenance of HR Forms that 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] 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 check:
Authorization Field
Long Text
MOLGA
Country Grouping
BESNR
Statement Number
AUTHC
Authorization Level
Authorizations in mySAP HR
50A
25
SAP Online Help
16.04.2002
More Information About the Fields •
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
L
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 check:
Authorization Field
Long Text
INFTY
Infotype
SUBTY
Subtype
AUTHC
Authorization Level
PERSA
Personnel Area
APGRP
Applicant Group
APTYP
Applicant Range
VDSK1
Organizational Key
Authorizations in mySAP HR
50A
26
SAP Online Help
RESRF
16.04.2002 Responsible Personnel Officer
More Information About the Fields •
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 user’s authorization. A user’s 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 check:
Authorization Field
Long Text
P_EVTYP
Run Type
P_EVSIMU
Posting Run: Simulation Indicator
ACTVT
Activity
More Information About the Fields •
The P_EVTYP field contains the run type that is to be tested during the authorization check. The following values are possible: 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
Authorizations in mySAP HR
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 check:
Authorization Field
Long Text
RELID
Area Identifier for Clusters in Tables
AUTHC
Authorization Level
More Information About the Fields •
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 check:
Authorization Field
Long Text
REPID
ABAP Report Name
ZVKAS
Social Fund
RZNUM
Data Processing Center Number for Constr.Ind.SI Fund
Authorizations in mySAP HR
50A
28
SAP Online Help
16.04.2002
ACTVT
Activity
More Information About the Fields •
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.
•
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
Example An administrator should have the following authorizations regarding th e 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 check:
Authorization Field
Long Text
ABRKS
Payroll Area
ACTVT
Activity
Authorizations in mySAP HR
50A
29
SAP Online Help
16.04.2002
More Information About the Fields The AUTHC field contains the activity for the authorization (for example, Display). The following values are possible: 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 check:
Authorization Field
Long Text
COARS
Degree of Simplification of the Authorization Check
REPID
ABAP Report Name
More Information About the Fields
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 = 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.
Authorizations in mySAP HR
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 RPT IME00 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 = ... INFTY = SUBTY =
Authorizations in mySAP HR
50A
31
SAP Online Help
16.04.2002
AUTHC = 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
Authorizations in mySAP HR
50A
32
SAP Online Help
16.04.2002
More Information About the Fields •
The AUTHC field contains the access mode for the authorization (for example, R = Read). See 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 user’s authorization.
Note The time dependency of infotypes is stored in table T582A ( Infotypes – CustomerSpecific Settings) in the VALDT field. A user’s 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 user’s 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 = *
Authorizations in mySAP HR
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. For the period January 1, 2001 – December 31, 2001:
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. For the period January 1, 2002 – December 31, 9999:
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
Authorizations in mySAP HR
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 check:
Authorization Field
Long Text
AUTHC
Authorization Level
PSIGN
Interpretation of Assigned Authorization
INFTY
Infotype
SUBTY
Subtype
More Information About the Fields 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 employee’s personnel number. The second authorization denies write authorization for all data records of the Basic Pay infotype (0008) stored under the employee’s 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.
Authorizations in mySAP HR
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 dif ferent 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
Authorizations in mySAP HR
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
More Information About the Fields •
The AUTHC field contains the access mode for the authorization (for example, R = Read). See 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 user’s authorization. A user’s 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.
Authorizations in mySAP HR
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
b.
Then choose Utilities
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
→
→
→
→
Development → Other Tools
→
Transactions.
Find and finally Edit → All Selections.
Execute.
Structure The P_TCODE authorization object contains the following field, which is tested during an authorization check:
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 check:
Authorization Field
Long Text
ACTVT
Activity
Authorizations in mySAP HR
50A
38
SAP Online Help
16.04.2002
PERSA
Personnel Area
BTRTL
Personnel Subarea
More Information About the Fields •
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 following values are possible: 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 check:
Authorization Field
Long Text
PLVAR
Plan Version
OTYPE
Object Type
INFOTYP
Infotype
SUBTYP
Subtype
ISTAT
Planning Status
PPFCODE
Function Code
More Information About the Fields •
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.
Authorizations in mySAP HR
50A
39
SAP Online Help
16.04.2002
A structural authorization profile is also necessary if you do not want to lim it 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 Manager’s Desktop) Definition Authorization object that is used to restrict the actions a user can carry out in the Manager’s Desktop application.
Structure The S_MWB_FCOD authorization object contains the following field, which is tested during an authorization check:
Authorization Field
Long Text
MWBFCODE
Function Code
More Information About the Fields The MWBFCODE check field refers to table T77MWBFCD (Function Codes for Manager’s 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.
Authorizations in mySAP HR
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]
Authorizations in mySAP HR
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
More Information About the Fields •
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 ac cess. 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 check:
Authorization Field
Long Text
STMSACTION
TemSe: Action ID for Authorizations
STMSOWNER
TemSe: Owner Group for Authorizations
STMSOBJECT
TemSe: Generic Object Name for Authorizations
Authorizations in mySAP HR
50A
42
SAP Online Help
16.04.2002
More Information About the Fields •
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 following values are possible: 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) [pag e 45]
Authorizations in mySAP HR
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 In the standard system, this switch is set to 0. If you want to activate the authorization check, set 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] should be used in the authorization check.
Values In the standard system, this switch is set to 0. If you want to activate the authorization check, set 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
Authorizations in mySAP HR
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 un til the December 31, 1999. From January 1, 2000, it is assigned to personnel area B. Administrator A’s 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 should be used in the authorization check.
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:
Authorizations in mySAP HR
50A
45
SAP Online Help
16.04.2002
Evaluate Organizational Unit (if available)
Never Evaluate Organizational Unit
Deny Authorization by Default
1
2
Grant Authorization by Default
3
4
3.3 AUTHC (Authorization Level) Definition Field in authorization objects, which defines a user’s 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:
Authorizations in mySAP HR
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).
Authorizations in mySAP HR
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
6
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
5
0
XY
01
P0001-KOSTL
1
0
XY
04
P0001-PERNR
2
3
XY
05
P0001-KOSTL
1
9
ZZ
01
P0001-KOSTL
5
5
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.
Authorizations in mySAP HR
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
1
ADM
Adm.
Administration
1
PRO
Prod.
Production
2
PRO
Test
Test
2
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]
Authorizations in mySAP HR
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 unlock ed 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.
Authorizations in mySAP HR
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 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 adm inistrators 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.
Authorizations in mySAP HR
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 onl y 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 change document . For more information about the change document, see the documentation on this IMG activity.
4
→
Set up
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]
Authorizations in mySAP HR
50A
52
SAP Online Help
16.04.2002
4.1 Process of the General Authorization Check Call Parameters A user attempts to call an employee’s infotype record. As a resu lt, 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 user’s 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 user’s 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
Authorizations in mySAP HR
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]
Authorizations in mySAP HR
50A
54
SAP Online Help
4.1.1
16.04.2002
Flowchart of the General Authorization Check Startauthorization 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
Determine period of responsibility 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
Authorizations in mySAP HR
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 employee’s infotype record. As a resu lt, the authorization check is called using the following parameters:
LEVEL
Authorization Level
TCLAS
Transaction Class = Difference Personnel Number/Applicant Number
PERNR
Personnel Number (or Applicant Number)
INFTY
Infotype
SUBTY
Subtype
The BEGDA and ENDDA parameters are not needed as the user’s 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:
AUTHORITY-CHECK OBJECT 'P_PERNR' ID 'AUTHC' FIELD LEVEL ID 'PSIGN' FIELD 'E' ID 'INFTY' FIELD INFTY ID 'SUBTY' FIELD SUBTY.
Authorizations in mySAP HR
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:
AUTHORITY-CHECK OBJECT 'P_PERNR' ID 'AUTHC' FIELD LEVEL ID 'PSIGN' FIELD 'I' ID 'INFTY' FIELD INFTY ID 'SUBTY' FIELD SUBTY. 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]
Authorizations in mySAP HR
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 = *
yes
Authorized? no Authorization check using P_PERNR for transferred connotation of AUTHC, INFTY, SUBTY with PSIGN = E
Authorized? no yes Authorization check using P_PERNR for transferred connotation of AUTHC, INFTY, SUBTY with PSIGN = I
yes
Authorized? nein
End, user is authorized
Authorizations in mySAP HR
End, authorization is unclear
50A
End, user is not authorized
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: Time Logic [page 49]
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
Transaction Class = Difference Personnel Number/Applicant Number
PERNR
Personnel Number (or Applicant Number)
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
Authorizations in mySAP HR
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]
Authorizations in mySAP HR
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 Determine period of r esponsibility 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 period of responsibility
Check on org. unit required?
Authorization for org.unit according to org. structure?
no
End, return period of responsibility
Authorizations in mySAP HR
50A
61
SAP Online Help
4.3.2
16.04.2002
Process of Determining the Period of Responsibility 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 aut horization 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 authorization check:
Example 1: The personnel number is located as follows in an organizational structure:
Authorizations in mySAP HR
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
S
01.01.1995 - 31.12.2005
P
Assume today’s date is February 6, 2001.
Example 1a: ( = 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. T he 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:
Authorizations in mySAP HR
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
P
Assume today’s date is February 6, 2001. 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
O
01.06.1999 31.12.9999
01.06.2002 31.12.9999
S
S
01.01.1999 31.12.1999
01.01.2002 31.12.2002
P
Assume today’s date is February 6, 2001. The following periods of responsibility are determined depending on the settings of the period:
Authorizations in mySAP HR
50A
64
SAP Online Help
16.04.2002
Period Setting
Period of Responsibility
( = 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
Process of Determining the Period of Responsibility 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
Transaction Class = Difference Personnel Number/Applicant Number
PERNR
Personnel Number (or Applicant Number)
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 user’s 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 user’s 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 user’s period of responsibility.
3.
If all the authorization checks run successfully, the validity period of the organizational assignment is added to the user’s 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 .
Authorizations in mySAP HR
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]
Authorizations in mySAP HR
50A
66
SAP Online Help
16.04.2002
4.3.3.1.1 Flowchart of Determining the Period of Responsibility According to Organizational Assignment 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
Authorizations in mySAP HR
End, user is not authorized
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 customer’s Authorization Object P_NNNNN.
Call Parameters A user attempts to call an employee’s infotype record. As a resu lt, 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 'INFTY' FIELD INFTY ID 'SUBTY' FIELD SUBTY ID 'AUTHC' FIELD LEVEL 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 'INFTY' FIELD INFTY ID 'SUBTY' FIELD SUBTY ID 'AUTHC' FIELD LEVEL 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
Authorizations in mySAP HR
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 'INFTY' FIELD INFTY ID 'SUBTY' FIELD SUBTY ID 'AUTHC' FIELD LEVEL 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]
Authorizations in mySAP HR
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
End, user is authorized
End, user is not authorized
4.4 Process of Time Logic Use Within the General Authorization check [page 6], this process performs the time logic.
Authorizations in mySAP HR
50A
70
SAP Online Help
16.04.2002
Call Parameters The time logic is called up using the following parameters:
LEVEL
Authorization Level
TCLAS
Transaction Class = Difference Personnel Number/Applicant Number
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
Period of Responsibility Possible Results
01.01.1800
b.
31.12.9999
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:
Authorizations in mySAP HR
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
Organizational Assignment 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].
Authorizations in mySAP HR
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 period of responsibility
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 period of responsibility
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 period of responsibility
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 res ponsibility 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
End, user is authorized
Authorizations in mySAP HR
no
50A
End, user is not authorized
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
Transaction Class = Difference Personnel Number/Applicant Number
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 inf otype (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 .
Authorizations in mySAP HR
50A
74
SAP Online Help
16.04.2002
Notes Applicant numbers are excluded from the test procedur es 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].
Authorizations in mySAP HR
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
End, user is authorized
Authorizations in mySAP HR
50A
End, user is not authorized
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.
Authorizations in mySAP HR
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] 76] for a graphical representation of the test procedures and Flowchart 8 [page 79] 79] for a graphic of how the date after which changes are permitted is determined.
Authorizations in mySAP HR
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 t est procedure (that is, of corresponding subtype of the 0130 infotype)
yes
No date found? no
authorized
Authorization check by personnel personnel number
not authorized
still no response
Determine period of responsibility 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
Authorizations in mySAP HR
End, any change made after check date is permitted
50A
79
SAP Online Help
5
16.04.2002
Interaction of General and Structural Authorizations
If you use both structural and general authorizations, a user’s 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 Authorizatio n 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: AUT HC: PERSA: PERSG: PERSK: ...
Profil 1 with with PLOG
0 -7 * R,M * * *
OTYPE: INFOTYP: IST AT : PLVAR: PFCODE: SUBTYP:
S 1000-1010 * 01 DISP *
Profile 2 with PLOG OTYPE: INFOTYP: IST AT : PLVAR: PFCODE: SUBTYP:
P * * 01 * *
The following authorizations or restrictions apply to a user who has the overall profile illustrated above:
Authorizations in mySAP HR
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)
6
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
Authorizations in mySAP HR
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 o wn 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 = *
Authorizations in mySAP HR
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 = *
Authorizations in mySAP HR
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 ch ecks. In addition, assign the payroll administrator full authorization for the P_ABAP [page 30] authorization object.
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: Creating a Customer-Specific Authorization Object [page 41]
Authorizations in mySAP HR
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 user’s 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 user’s authorization profile, he or she is authorized to access organizational units in plan version 01.
Example 3 Field
Values
Plan Version
01
Object type
O (Organizational Unit)
Object ID
Organizational Unit ID
Evaluation Path
ORGEH (Organizational Structure)
Authorization: Due to the user’s 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
O (Organizational Unit)
Object ID
Organizational Unit ID
Evaluation Path
ORGEH (Organizational Structure)
Period
D (current day)
Authorization: Due to the user’s 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
Authorizations in mySAP HR
50A
85
SAP Online Help
16.04.2002
Object Type
O (Organizational Unit)
Object ID
0 = no restriction
Evaluation Path
SBESX (Staffing Assignments Along Organizational Structure)
Function Module
RH_GET_MANAGER_ASSIGNM ENT
Authorization: Due to the user’s 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]
7
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 author ization checks are stopped and instead only the activated implementation is performed. You can implement this BAdI using the SE19 transaction.
Authorizations in mySAP HR
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
Authorizations in mySAP HR
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_ASSIGN MENT 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
Authorizations in mySAP HR
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 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.
Authorizations in mySAP HR
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]:
Authorizations in mySAP HR
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
Authorizations in mySAP HR
50A
91
SAP Online Help
16.04.2002
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_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. RAISE internal_error. 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.
Authorizations in mySAP HR
50A
92
SAP Online Help
16.04.2002
CASE sy-subrc. WHEN 1. RAISE internal_error. 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. RAISE internal_error. 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. RAISE internal_error.
Authorizations in mySAP HR
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. RAISE internal_error. 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. RAISE internal_error. WHEN 2. RAISE invalid. ENDCASE. ENDMETHOD.
METHOD if_ex_hrpad00auth_check~check_authorization. DATA l_begda TYPE begda. DATA l_endda TYPE endda.
Authorizations in mySAP HR
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. RAISE internal_error. 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
Authorizations in mySAP HR
50A
95
SAP Online Help
16.04.2002
is_authorized
= is_authorized
EXCEPTIONS invalid
= 2
internal_error = 1. CASE sy-subrc. WHEN 1. RAISE internal_error. 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. RAISE internal_error. 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
Authorizations in mySAP HR
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. RAISE internal_error. 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.
Authorizations in mySAP HR
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 user’s 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.
Authorizations in mySAP HR
50A
98
SAP Online Help
8
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 user’s 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 personn el 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.
Authorizations in mySAP HR
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 unlock ing 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 SAP’s 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?
•
9
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] Redundant Read of Objects [page 103] 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
Authorizations in mySAP HR
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 buf fer 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 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 .
Recommendation The second option is preferable. In principle, users are not granted any unnecessary authorizations since the 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
Authorizations in mySAP HR
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, personn el 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
Authorizations in mySAP HR
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: •
Redundant Read of Objects [page 103]
•
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 an y 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
O
O
B002
S
S
A008
P
Evaluation Path O_O_S_C: O
B002
O
O
B003
S
S
A007
C
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
O
O
B003
S
Authorizations in mySAP HR
50A
103
SAP Online Help
16.04.2002
S
A008
P
S
A007
C
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 determ ine the permitted persons by organizational unit and position. You can use the SBESX evaluation path for this: Evaluation Path SBESX: O
B002
O
O
B002
S
S
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 t ypes 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
O
O
B002
S
S
A008
P
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.
Authorizations in mySAP HR
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
...
Mgr Benefits
Mgr Payroll
...
BenefitsDept
Payroll Dept
PC1
PC2
Emp
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 manager’s team
Full read and write authorization for infotypes 0000 to 0007
Business overall profile of the role Payroll Manager :
Objects
Type of Authorization
Employees in the organizational structure
Full read and write authorization for infotypes 0008 to 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.
Authorizations in mySAP HR
50A
105
SAP Online Help
16.04.2002
Structural Profile 1 (Role
Profile 1 using P_ORGIN (Role
Manager )
Manager )
O1
S1
SN
P1
Overall Profile for Manager 1
PN
+ Payroll Manager ) O2
P2
0-7 * W * * *
+
Structural Profile 2 (Role
S2
INFOTYP: SUBTY: AUTHC: PERSA: PERSG: PERSK: ...
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 user’s 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
Type of Authorization
All employees in the manager’s team and organizational structure
Full read and write authorization for infotypes 0000 to 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
Type of Authorization
Employee of organizational structure
Full read and write authorization for infotypes 0008 to 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 .
Authorizations in mySAP HR
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.
Authorizations in mySAP HR
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.
Authorizations in mySAP HR
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 For more information about this report, see the report documentation in the SAP system.
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 For more information about this report, see the report documentation in the SAP system.
See also: Creating a Customer-Specific Authorization Object [page 41]
Authorizations in mySAP HR
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).
Authorizations in mySAP HR
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 employee’s 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 structur al authorizations that a user has in the system.
Authorizations in mySAP HR
50A
111
SAP Online Help
16.04.2002
Period of Responsibility 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 user’s 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-base d 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.
Authorizations in mySAP HR
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
O
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
Authorizations in mySAP HR
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 Determining the Period of Responsibility According 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
