Authorizations in mySAP HR 46C PDF

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

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

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

4.1 4.2 4.3 Process of the General Authorization Check ............................................................ 53 Flowchart of the General Authorization Check .................................................. 55 Flowchart of the Authorization Check by Personnel Number ............................ 58 Process of Determining the Period of Responsibility According to Organizational Structure..................................................................................... 59 61 Process of the Authorization Check by Personnel Number ...................................... 56 Process of Determining the Periods of Responsibility .............................................. 59 4.1.1 4.2.1 4.3.1
4.3.1.1 Flowchart of Determining the Period of Responsibility According to Organizational Structure 4.3.2 4.3.3
Process of Determining the Period of Responsibility According to the Structural Authorization Check........................................................................... 62 Process of Determining the Period of Responsibility According to Organizational Assignment ................................................................................ 65 Flowchart of Determining the Period of Responsibility According to Organizational Assignment 67
4.3.3.1.1 4.3.4 4.3.5 4.4 4.5
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN ................................................................................................... 68 Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN ................................................................................................... 70 Flowchart of the Time Logic ............................................................................... 73
Process of Time Logic ............................................................................................... 70 Process of the Test Procedures ................................................................................ 74
4.4.1
50A
SAP Online Help 4.5.1 4.6
16.04.2002
Flowchart of the Test Procedures ...................................................................... 76
Process of Determining the Date After Which Changes Are Permitted for Test Procedures ........................................................................................................ 77 Flowchart of Determining the Date After Which Changes Are Permitted for Test Procedures............................................................................................ 79
4.6.1
5 Interaction of General and Structural Authorizations...............80 6 Examples ...............................................................................81

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

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

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

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

Use
You set up authorizations in the form of roles using role maintenance (transaction PFCG). Roles provide a business perspective by representing the tasks and activities that a user is authorized to
50A
SAP Online Help
16.04.2002
perform in the system. Authorizations are parts of roles and are stored as an authorization profile for the role. Role maintenance generates one part of the authorization profile (functional part) automatically; you must define the part of the profile that controls which data a user has access to manually. You can generate several authorization profiles for each role. When you generate roles, you also define the authorization objects with the necessary field specifications. User menus provide access to the transactions, reports or web-based applications contained in the roles. A user menu should therefore contain only the functions that are required by a specific user with a specific task profile for daily work.
Note
Authorizations were set up using the transactions SU01 and SU03 up to release 4.6A. Up until then, the common term used to describe roles was activity groups.
Procedure
To create roles and to generate authorization profiles, proceed as follows: 1. To create or change a role, choose Role Maintenance using transaction PFCG. If you want to create your own user roles, make sure you do not use the SAP namespace (all roles delivered by SAP have the prefix SAP_). 2. In the Menu tab page, assign transactions, reports, and/or web addresses to the role. By doing this, you set the user menu that is automatically called up when the user assigned to this role logs on to the SAP system. When you assign transactions and so on, the users role or task profile is defined. The transactions defined in Menu tab page are then used by the system to create authorizations automatically. 3. You can change the authorizations that were automatically created by the system if you need to by setting the menu in the Authorizations tab page. To do so, choose the Expert Mode option under Maintain Authorization Data and Generate Profile in this tab page. You can create additional authorizations when you change the authorizations that you have already created by choosing additional authorization objects and so on, for example. 4. In the Authorizations tab page , also generate the authorization profile belonging to the role when you have finished any post-processing work on the automatically created authorizations. 5. In the User tab page, assign users to the newly generated role.
Note
You can also assign users to roles by user groups and by objects (for example, job) in Organizational Management. You cannot use the profile generator for this type of assignment; you must use transaction SU10 (User Maintenance: Mass Changes) in Organizational Management.
Caution
The generated profile is only entered in the user master record once a user comparison has taken place. A comparison is also required if changes are made to the users assigned to the role and if an authorization profile is generated. For more information about setting up authorization profiles, see the Implementation Guide (IMG) for Personnel Administration under Tools Authorization Management Maintain Profiles. In addition, you can find all relevant and non-HR-specific information on authorization maintenance (Role Maintenance) in the SAP Library under Basis Computing Center Management System (BC-CCM) Users and Roles (BC-CCM-USR).
50A
SAP Online Help
16.04.2002
2
Use
Structural Authorization Check
Structural authorizations perform exactly the same function, from a business point of view, as general authorizations in mySAP HR and in other SAP components. They control access specifically to data that is stored in time-dependent structures (organizational structures, business event hierarchies, qualifications catalog, etc.).
Integration
You can integrate the structural authorization check with the general authorization check. Note that if you do so, the authorizations entered for each authorization type may influence one another. For more information, see Interaction of General and Structural Authorizations [page 80].
Prerequisites
The data that you want to protect must be stored in a hierarchical structure of one of the Human Resources components (Organizational Management, Personnel Development, Training and Event Management, etc.)
Features
You can grant authorizations for objects that are stored in a hierarchical structure using the structural authorization check. If you specify a root object, you can determine that all objects in the hierarchy under this specified object may also be changed, for example. This concept guarantees that the maintenance of structural authorizations is kept to a minimum, even if a change is made within the structure, and at the same time that users still only have access to objects that they are responsible for. This flexibility is achieved in two steps. First by using the (initial) structure built in Organizational Management to define the authorization profiles. And second by using a concept to store authorization profiles that reacts automatically/dynamically to changes in the organizational structure, or in other words a concept that automatically adjusts to the different profiles. For more information about the structural authorization concept, see Structural Profiles [page 10].
Activities
For information on how to set up structural authorizations, see Definition of Structural Authorizations [page 12].
Example
The following example illustrates the advantages of structural authorizations for access to data in time-dependent structures:
50A
SAP Online Help
16.04.2002
O1
O2
O3
O4
O5
O6
O7
O8
O9
O10
O11
O12
An organizational structure divides into three subtrees (organizational units O2, O3, and O4) on the second level, for example. The authorizations of the persons responsible for each organizational unit are also divided up accordingly for each subtree. A user needs three profiles for this organizational structure that allow him or her to read/change data in O1, O2 or O3 AND in all lower level organizational units. If you were to use the general authorization concept (values in fields) here, you would have to enter all objects under the initial object in every authorization profile. For the O2 profile and lower level objects, for example, you would have to enter the following objects in the profile: O2 O5 O6
In other words, you would have to enter ALL objects under O2 in the profile. You would have to follow the same procedure for all other profiles, which would involve considerable maintenance work to the initial profile and to the organizational structure if changes were made to it. If the organizational structure was expanded to include the organizational units O11 and O12, for example, you would have to add the O2 and lower level objects profile to include 011 and 012 manually. Structural profiles, on the other hand, allow you to copy profiles, such as the O2 and lower level objects profile, by entering a start object (in this case, O1) and an evaluation path. This requires minimal time and effort. For more examples about structural authorizations, see Example: Structural Authorization Profiles [page 85].
2.1 Structural Profiles

Structure
Structural profiles use the data model of the Personnel Management components Organizational Management, Personnel Development and Training and Event Management to build hierarchies using objects and relationships. Different types of objects (Object Types) and different types of relationships are used in this process. The organizational structure of a company is illustrated in the following way:
50A
10
SAP Online Help
16.04.2002
Graphic 1: Diagram of an organizational structure using objects and relationships
A002: reports to
O0
O1 A003: belongs to
O2
O3
S1 B008: Holder
O4
O5 A003: belongs to
O6
S5 B008: Holder
P1 B008: Holder
S2
S3
S4
P5
P2
P3
P4
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 O O S Relationship B002 B003 A008 Relationship Name is line supervisor of incorporates holder Related Object Type O S 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:
50A
11
SAP Online Help O1, O4, O5
16.04.2002
Second, the evaluation paths starts selection from the selected organizational units according to row 2 of the definition (O B003 S) and selects the following positions: S1, S2, S3 Last, the evaluation path starts selection from the selected positions according to row 3 of the definition (S A008 P) and selects all persons: P1, P2, P3 In total, the following objects are selected using the O-S-P evaluation path and the start object O1: O1, O4, O5, S1, S2, S3, P1, P2, P3 A combination of start object and evaluation path returns a specific number of objects from an existing structure. This exact combination or the objects returned by this combination, represents a users structural profile. Note that neither the number of objects nor the specific objects that are returned by a structural profile are constant, nor is this desirable. The concrete objects that are returned by a structural profile change as the organizational structure (under the start object) changes. See also: Example in Structural Authorization Check [page 9] There are several fields besides the central fields Start Object and Evaluation Path that can be used to define structural profiles. These fields simply allow you to add more detail about frequently occurring standard cases, but use the basic principle of start object plus evaluation path. See Definition of Structural Authorizations [page 12] for more information on these fields and how to create structural profiles.
Note
Not all aspects of the structural authorization check can be discussed in one section. See the following for more detailed information on the different aspects: 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]
2.1.1
Use
Definition of Structural Authorizations
You can use this function to define structural authorizations. You can define structural authorizations using the T77PR table (Definition of Authorization Profiles).
50A
12
SAP Online Help There are
16.04.2002
Structural authorizations for the Organizational Management, Personnel Development, and Training and Event Management components described in this section. Structural authorizations that should be used for more specific authorization checks (on account of the organizational structure) during the processing of HR master data. See Interaction of General and Structural Authorizations [page 80] for detailed information.
Integration
To assign profiles, use the T77UA table (User Authorizations = Assignment of Profile to Users). For more information, see Assignment of Structural Authorizations [page 17].
Prerequisites
To be able to understand and set up structural authorizations, you must have knowledge of the Personnel Development data models (Organizational Management, Personnel Development, Training and Event Management, and so on). For more information, see Structural Profiles [page 10].
Features
You can use the following fields in the T77PR table (Definition of Authorization Profiles) to define authorizations for HR objects (the fields are described according to their sequence in the maintenance screen; they are not prioritized in any way). Plan Version You can use this field to determine the plan version for which the defined profile is valid. If you use a system that integrates the Personnel Administration (PA-PA) and Organizational Structure (PA-OS) components, note that plan version 01 is generally the integrated plan version. Object Type You can use this field to determine the object types for which the defined profile is valid. Note that you can only specify object types that have a key with a NUMC (8) format. In general, structural authorization checks are not carried out for external objects with a different key (for example, cost centers). Technically speaking, this includes all authorization objects that are entered in the T77EO table (External Object Types) but that do not have an inverse relationship (INREL = <Blank>). You can use the general authorization check of the relevant application for external objects without an inverse relationship. Object ID You can use this field to define the start object using evaluation paths. Maintenance (Processing Mode) You can use this field to control whether a read or write authorization should be assigned to a user for the corresponding set of objects. This field in the T77PR table (Definition of Authorization Profiles) corresponds to the MAINT field in the T77FC table (Function Codes HR-PD). All function codes that have an X in this field can be processed. Evaluation Path By entering a specific evaluation path in this field, you can determine that the user is only authorized to access objects along this evaluation path. You must also assign a root object for the structure when you use an evaluation path. This root object can either be entered directly in the corresponding field of the T77PR table (Definition of Authorization Profiles), or determined dynamically using a suitable function module.
50A
13
SAP Online Help
16.04.2002
The choice of evaluation path has a decisive influence on the overall performance of the system. Refer to the notes on avoiding performance problems in Performance Aspects [page 102]. Status Vector You can use this field to determine which relationships are considered when the structure is created. If you define the status vector as 12, for example, all relationships that have the status active or planned are evaluated. The choice of status vector has no real effect on the status of objects. The status vector simply refers to the status of the relationships. You can find the defined statuses for mySAP HR in the T778S table (Plan Status). Depth (Display Depth) You can use this field to determine which level of a hierarchical structure a user is authorized to access.
Graphic 2: Effect of the Display Depth parameter: A structural authorization with display depth 2 only includes objects up to level 2 of the hierarchy (from the start object) in this authorization.
Level 1
O1
Level 2 O2 O3 S4
Level 3
S1
S2
S3
If you enter 0 as the value for the display depth, the corresponding tree is completely built, that is there is no limit to the depth of the tree. Sign By entering a sign in this field, you can determine that structural authorization profiles should be created which process the structure bottom up. If you make no entry in this field (default value <Blank>) or enter a + sign, the structure is processed in the normal top down manner. Period In this field, you can define the profile according to the validity period of the structure. You can enter the following options: Key date, all, and different periods such as current year, current month and so on. If you select the entry D (current day), the structural authorization is limited to the structures valid on the current day. If you define a structural authorization for a manager using period D, the manager is authorized to access data on all persons who are currently in the managers group. If you do not make an entry (default value <Blank>), the structure is not limited by validity period. If you define the profile using the <Blank> period, the manager is authorized to access data on former or future employees in addition to the authorization in the above example.
50A
14
SAP Online Help
16.04.2002
The Period field has, therefore, no influence on the period for which a user is authorized to access a specific object. In other words, the structural authorization check, unlike the general authorization check, does not return periods of responsibility. Instead, the system outputs whether or not the user has authorization for a specific object.
Note
The Period field in the definition of the structural authorization check does not affect the time logic of the general authorization check. For more information, see Time Logic [page 49]. The Period field is used in structural authorizations to determine the set of objects for which authorization exists or which is passed on to the general authorization check for further processing. See Flowchart of Determining the Period of Responsibility According to Structural Authorization Check [page 62] for a description of how the period of responsibility is determined for the general authorization check.
Graphic 3: How the Period Field Works in Structural Profiles
O1
01.01.1999 - 31.12.9999
S1
S2
01.01.1999 - 31.12.2000
01.01.1999 - 31.12.9999
P1
P2
Due to different values in the Period field, the user is authorized to access different sets of objects for the data in the above diagram.
Example
For the following two examples, which refer to graphic 3, the system date is set to February 6, 2002. Example 1: Period: D (= Key date) If you enter D, the user is only authorized to access P2 because he or she only has authorization to access objects in the structure that is valid on February 6, 2001 and the relationship between S1 and P1 ends before February 6, 2001. Example 2: Period: <BLANK> (= all) If you enter <BLANK> (= All), the user is granted access to P1 and P2. Function Module You can use this field to specify a function module that determines the root object dynamically at runtime. Do not make an entry in the Object ID field. However, you must specify the Plan Version and Object Type fields.
50A
15
SAP Online Help
16.04.2002
The advantage of using function modules is that each time you define an authorization profile, the function module generates a user-specific profile for each user at runtime. If a manager changes department, for example, the corresponding profile in the T77PR table (Definition of Authorization Profiles) does not need to be changed. What is more, the number of entries in the T77PR table can be reduced significantly by setting up function modules. Two function modules are delivered in the standard system: RH_GET_MANAGER_ASSIGNMENT (Determine Organizational Units for Manager) When you use this function module, the organizational unit that is assigned to the user as manager by position and by relationship A012 (is manager of) is determined as the root object. This function module is key date-related, that is only the organizational units that are assigned to the user as manager on the current system date are determined as root objects for that user.
Graphic 4: How the RH_GET_MANAGER_ASSIGNMENT Function Module Works: 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.
O0
A012 = "is manager of"
O1 A003
O2
B008
S1
A268
P1 B008
S2
US2
A268
P2
RH_GET_ORG_ASSIGNMENT (Organizational Assignment) When you use this function module, the organizational unit that is organizationally assigned to the user is determined as the root object.
50A
16
SAP Online Help
16.04.2002
Graphic 5: How the RH_GET_ORG_ASSIGNMENT Function Module Works: The function module determines the organizational unit assignment to a user/person from a users assignment to a personnel number or position. The structural profile uses this organizational unit as the root object: If two users have the same structural profile, O2 is determined for user 1 (US1) and for user 2 (US2), O2 is determined as the root object. Even if U1 was moved to a position under O2, the same profile would return the desired result. US1
O0 A003 O1
O2
B008 A268
S1
P1 B008
S2
US2
A268
P2
2.1.2
Use
Assignment of Structural Authorizations
You can use this function to assign structural profiles to users.
Integration
Structural profiles are not assigned in the same way as general authorization profiles. Whereas general authorization profiles are assigned using the Profile Generator (PFCG transaction), you assign structural profiles using table T77UA (User Authorizations = Assignment of Profile to User).
Note
You can edit this table in the Implementation Guide (IMG) for Organizational Management under Basic Settings Authorization Management Structural Authorization Assign Structural Authorization.
Activities
You can assign users to structural profiles using table T77UA or the OOSB transaction. The system first searches for entries for the current user in the T77UA table (User Assignments). If one or more entries exist, the set of objects is mapped according to the profile definition. The set of objects is then checked against the concrete object and the action (Display or Edit). The authorization is granted only if the object to be checked exists with the necessary processing indicator in the set of objects.
Note
If there is no entry in the T77UA table (User Authorizations) for the current user, the above check takes place within the T77UA table for the entry SAP*. If still no entry exists, the authorization is denied. In the standard system, there is an entry for user SAP* with the profile ALL. This means that when you first implement mySAP HR, all users have complete authorization as far as structural authorization is concerned.
50A
17
SAP Online Help
16.04.2002
Technical Aspects
The following paragraphs explain how you set up general and structural authorizations and provide you with an outline of the technical aspects of authorizations, in other words, of all the technical objects, checks, and additional setting options that play a part in setting up these authorization types.
See also:
Authorization Objects [page 18] HR: Main Authorization Switch [page 43] AUTHC (Authorization Level) [page 46] VDSK1 (Organizational Key) [page 47] 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 carry out an action. An authorization object groups up to ten authorization fields that are checked in an AND relationship. For an authorization check to be successful, all field values of the authorization object must be maintained in the user master data. Authorization objects are assigned to object classes for purposes of clarity. The authorization objects for mySAP HR belong to the HR (Human Resources) object class. You can display or edit the authorization objects and their fields using transaction SU21. You can also use this transaction to create new object classes and authorization objects. The authorization objects of the HR (Human Resources) object class have, as with all SAP authorization objects, up to ten fields which are read by the system during an authorization check.
Example
The P_ORGIN [page 32] authorization object (HR: Master Data), which is used in the standard system, consists of the following fields:
Authorization Field
INFTY SUBTY AUTHC PERSA PERSG PERSK VDSK1
Long Text
Infotype Subtype Authorization Level Personnel Area Employee Group Employee Subgroup Organizational Key
50A
18
SAP Online Help
16.04.2002
You can therefore assign authorizations for personnel data in Human Resources at infotype/subtype level according to the employees personnel area, employee group, employee subgroup, and organizational key. The following sections describe the authorization objects for the HR (Human Resources) object class and selected authorization objects from the BC_A (Basis - Administration) object class that also play an important part in mySAP HR.
Note
In most cases, the individual fields of the authorization objects are described by means of examples. An exception to this is the field that contains the access authorization for an authorization object (normally AUTHC [page 46] or ACTVT). This field or in other words fields that are based on a special logic are described in more detail for each authorization object. Authorization objects for the HR object class: P_CH_PK (HR-CH: Pension Fund: Account Access) [page 20] P_DE_BW (HR-DE: Statements SAPScript) [page 20] P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company) [page 21] P_PYEVDOC (HR: Posting Document) [page 21] P_OCWBENCH (HR: Activities in the Off-Cycle Workbench) [page 22] P_BEN (HR: Benefit Area) [page 22] P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check) [page 23] P_PE02 (HR: Authorization for Personnel Calculation Rule) [page 24] P_PE01 (HR: Authorization for Personnel Calculation Schemas) [page 24] P_HRF_INFO (HR: Authorization Check InfoData Maintenance HR Forms) [page 24] P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms) [page 25] P_CERTIF (HR: Statements) [page 25] P_APPL (HR: Applicants) [page 26] P_PYEVRUN (HR: Posting Run) [page 27] P_PCLX (HR: Clusters) [page 28] P_DBAU_SKV (HR: DBAU: Construction Pay Germany Social Fund Procedure) [page 28] P_PCR (HR: Payroll Control Record) [page 29] P_ABAP (HR: Reporting) [page 30] P_ORGIN (HR: Master Data) [page 32] P_PERNR (HR: Master Data Personnel Number Check) [page 34] P_ORGXX (HR: Master Data Extended Check) [page 37] P_TCODE (HR: Transaction Code) [page 37] P_USTR (HR: US Tax Reporter) [page 38] PLOG (Personnel Planning) [page 39] S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for Managers Desktop) [page 40] P_NNNNN (Customer-Specific Authorization Object) [page 40] S_TABU_DIS (Table Maintenance (Using Standard Tools such as SM30)) [page 42]
The following authorization objects are also important for mySAP HR:
50A
19
SAP Online Help S_TMS_ACT (TemSe: Actions on TemSe Objects) [page 42]
16.04.2002
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
KONNR AUTGR PKKLV
Long Text
Number of Individual PF Account HR-CH: Authorization for PF Accounts 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
BEWID BSUBJ BACT
Long Text
Statement Identifier InfoSet Identification for Statements Activities for Statements in Authorization Check
50A
20
SAP Online Help
16.04.2002

The BEWID field contains the statement identifier for statements in Payroll Germany that should be tested during an authorization check. The BSUBJ field contains the functional area identification (ID) for statements. The functional area represents a logical breakdown of the statements according to individual subject areas. Note that you can define the access using the parameter ID (PID or user parameter) BSUBJ. By predefining the values for a function area, the correct authorization is used when you call up the application for the first time.
Example
The administrator only has authorization for functional areas 03 and 04. In this case, the BSUBJ user parameter must be set as one of the two values. The administrator is therefore only authorized to navigate within these two functional areas. If an administrator has authorization for all functional areas, the user parameters can only be used to simplify coordination since the initial access branches directly to this functional area. You can configure up to 30 functional areas. The BACT field contains the activities for statements that are valid as part of the authorization check. The following values are possible: E: Creation of statements A: Asynchronous archiving S: Fast entry/Ad Hoc Query V: Administration of archived statements
3.1.3
P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)
Definition
Authorization object that is used during authorization checks for PBS companies.
Structure
The P_DK_PBS authorization object contains the following field that is tested during an authorization check:
Authorization Field
PBSFIRMA
Long Text
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
BUKRS ACTVT
Long Text
Company Code Activity
50A
21
SAP Online Help
16.04.2002

The ACTVT field contains the activities for posting documents that are possible as part of the authorization check. The ACTVT field can have the following values: 03: Display 10: Post 28: Display Line Item 43: Release
3.1.5
P_OCWBENCH (HR: Activities in the Off-Cycle Workbench)
Definition
Authorization object that is used during the authorization check for the off-cycle workbench. The P_OCWBENCH authorization object ensures that each administrator sees only the off-cycle activities that he or she is authorized to perform.
Structure
The P_OCWBENCH authorization object contains the following field which is tested during an authorization check:
Authorization Field
P_OCTYP
Long Text
Type of Off-Cycle Activity

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

The ACTVT field contains the activities for benefits that are possible as part of the authorization check. The field can have the following values:
50A
22
SAP Online Help 02: Change 03: Display
16.04.2002
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
CATS_AUTHP TASKLEVEL TASKTYPE BUKRS PERSA KOSTL PERSG PERSK ORGEH ACTVT
Long Text
Personnel Number Check Task Level Task Type Company Code Personnel Area Cost Center Employee Group Employee Subgroup Organizational Unit Activity

The CATS_AUTHP field contains the processing mode that is permitted for the authorization check. The following values are possible: E: Processing your own personnel ID O: Processing a different personnel ID
Note
To determine your own personnel ID, infotype 105 must be defined in the system. The ACTVT field contains the permitted activities. The following values are possible: 01: Add (currently not used)
50A
23
SAP Online Help 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)
16.04.2002
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
P_AUTHPE02
Long Text
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
P_AUTHPE01
Long Text
HR Schema: Authorization
3.1.10 P_HRF_INFO (HR: Authorization Check InfoData Maintenance for HR Forms)

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

The ACTVT field contains the activities for the InfoData maintenance of HR Forms that are possible as part of the authorization check. This field can have the following values: 02: Change
50A
24
SAP Online Help 03: Display
16.04.2002
3.1.11 P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms)
Definition
Authorization object that is used during the authorization check for HR Forms. You can carry out different actions in the HR Forms application. You can use this authorization object to restrict the actions a user can carry out.
Structure
The P_HRF_META authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
P_HRF_TYP MOLGA P_HRF_MOBJ ACTVT
Long Text
HR Forms: Object Type Country Grouping HR Forms: MetaData Object Activity

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

Definition
Authorization object that is used in Statements to check which tasks an administrator is authorized to perform.
Use
This object is used only in Statements. Only edit this authorization object if you have first set up statements without SAPScript. If you use statements with SAPScript, you must use the P_DE_BW [page 20] authorization object. This object is used in screen control and in report creation. In screen control, this object determines whether an administrator is authorized to perform a certain task. In report creation, this object determines whether an administrator is authorized to make changes when displaying statements that have already been created (this corresponds to individual creation).
Structure
The P_CERTIF authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
MOLGA BESNR AUTHC
Long Text
Country Grouping Statement Number Authorization Level
50A
25
SAP Online Help
16.04.2002

The MOLGA field defines the countries for which an administrator is authorized to process statements. The countries must correspond to the country modifier. The BESNR field defines which statements an administrator is authorized to access using a number interval. The specified numbers must correspond to the existing statements. The AUTHC field contains the access mode for the authorization (for example, Display). The following values are possible: E: Create statements using the Single Record Entry option S: Create statements using the Fast Entry option A: Display statements using the Print Statement option D: Print statements using the Print Statement option L: Delete statements using the Print Statement option F: Release statements using the Print Statement option
Example
You want to assign an administrator the following authorizations: Create all German statements Delete all German statements between 1 and 10 Display and print all Austrian statements
Define three authorizations and group these into one profile. Assign this profile to the administrator by user assignment:
Authorization
P_CRF_ALD P_CRF_TENLD P_CRF_DRUA
Country Grouping
01 01 03
Statement Number
* 01-10 *
Authorization Level
ES L 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
INFTY SUBTY AUTHC PERSA APGRP APTYP VDSK1
Long Text
Infotype Subtype Authorization Level Personnel Area Applicant Group Applicant Range Organizational Key
50A
26
SAP Online Help RESRF Responsible Personnel Officer
16.04.2002

The AUTHC field contains the access mode for the authorization (for example, R = Read). See authorization level [page 46] for a detailed description of the possible specifications (M, R, S, E, D, W, *) for this field. The PERSA, APGRP, APTYP, VDSK1 and RESRF fields are filled from the Organizational Assignment infotype (0001). Since this infotype has time-dependent specifications, an authorization may only exist for certain time intervals depending on the users authorization. A users period of responsibility is represented by all the time intervals for which he or she has P_APPL authorizations (see also example of the period of responsibility using P_ORGIN [page 33]).
Note
Unlike the P_ORGIN and P_ORGXX authorization objects, the check on this authorization object cannot, in principle, be deactivated (that is, there is no corresponding authorization main switch).
3.1.14 P_PYEVRUN (HR: Posting Run)

Definition
Authorization object that is used during the authorization check for posting runs.
Structure
The P_PYEVRUN authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
P_EVTYP P_EVSIMU ACTVT
Long Text
Run Type Posting Run: Simulation Indicator Activity

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
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
RELID AUTHC
Long Text
Area Identifier for Clusters in Tables Authorization Level

The possible specifications for the RELID field are the fixed values of the RELID_PCL domain. The fixed values and their meaning are stored in the T52RELID table (HR: Description of Clusters in PCLx Tables). The AUTHC field contains the activity for the authorization but uses a different logic for P_PCLX than for other authorization objects. The following specifications are possible: R: Read U: Write (update) this includes the authorizations of authorization level S but not authorization level R S: Write data to internal buffer but not to database (simulation)
3.1.16 P_DBAU_SKV (HR: DBAU: Construction Pay Germany Social Fund Procedure)
Definition
Authorization object that is used exclusively in Construction Pay Germany for reports on the Social Fund Procedure.
Use
This authorization object determines which reports with which parameters or which processing steps an administrator is allowed to run or carry out. The RPCBLFD0 report (Construction Pay: Evaluations of the Social Fund Procedure) defines which activities an administrator is allowed to perform: Display posting runs already created Create new posting runs
Delete the last posting run to be carried out
Structure
The P_DBAU_SKV authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
REPID ZVKAS RZNUM
Long Text
ABAP Report Name Social Fund Data Processing Center Number for Constr.Ind.SI Fund
50A
28
SAP Online Help ACTVT Activity
16.04.2002

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 the evaluation report for the social fund procedure: Display posting runs already created Create all posting runs for social fund 02 Delete a posting run of the 02 social fund for the data processing center number 12345678 (providing the posting run is the last posting run to have been created)
Define three authorizations and group these into one profile. Assign this profile to the administrator by user assignment:
Authorization
P_DBAU_SKV_A P_DBAU_SKV_E P_DBAU_SKV_L
Report Name
RPCBLFD0 RPCBLFD0 RPCBLFD0
Social Fund
* 02 02
Data Center
* * 12345678
Activity
03 01 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
ABRKS ACTVT
Long Text
Payroll Area Activity
50A
29
SAP Online Help
16.04.2002

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
COARS REPID
Long Text
Degree of Simplification of the Authorization Check ABAP Report Name
Using P_ABAP in HR Reporting:

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

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 users authorization.
Note
The time dependency of infotypes is stored in table T582A (Infotypes CustomerSpecific Settings) in the VALDT field. A users period of responsibility is represented by all the time intervals for which he or she has P_ORGIN authorizations.
See also:
Example of Period Determination Using P_ORGIN [page 33]
3.1.19.1
Example of Period Determination Using P_ORGIN
Authorization check using P_ORGIN for: INFTY = 0014 SUBTY = M120 AUTHC = R The data available in the Organizational Data infotype (0001):
01.01.2000 31.12.2000:
PERSA = DE01 PERSG = 1 PERSK = DA VDSK1 = 42
01.01.2001 31.12.2001:
PERSA = US01 PERSG = 1 PERSK = DA VDSK1 = 42
01.01.2002 31.12.9999:
PERSA = DE01 PERSG = 1 PERSK = DB VDSK1 = 42
The users authorizations available in the user master record: INFTY = 0014 SUBTY = M120 AUTHC = R PERSA = DE01 PERSG = 1 PERSK = * VDSK1 = * as well as INFTY = 0015 SUBTY = * AUTHC = * PERSA = * PERSG = *
50A
33
SAP Online Help 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
16.04.2002
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
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
AUTHC PSIGN INFTY SUBTY
Long Text
Authorization Level Interpretation of Assigned Authorization Infotype Subtype

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

Definition
Authorization object that is used during the authorization check for HR infotypes. The check takes place when HR infotypes are edited or read.
Structure
P_ORGXX contains the following fields, which are tested during an authorization check:
Authorization Field
INFTY SUBTY AUTHC SACHA SACHP SACHZ SBMOD
Long Text
Infotype Subtype Authorization Level Payroll Administrator Master Data Administrator Time Recording Administrator Administrator Group

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 users authorization. A users period of responsibility is represented by all the time intervals for which he or she has P_ORGXX authorizations.
See also:
Example of Period Determination Using P_ORGIN [page 33]
3.1.22 P_TCODE (HR: Transaction Code)

Definition
Authorization object that is used to check whether a user is authorized to start the different HR transactions. The transaction code is checked.
50A
37
SAP Online Help
16.04.2002
Use
The P_TCODE authorization object is not used in all HR transactions. We distinguish between: HR transactions with natural (own) authorization objects, such as persons (employees, applicants), statements, or similar. In transactions of this type, these natural authorization objects (HR: Master Data, HR: Applicants, and HR: Statements) are used for the check. When a user starts a transaction, the system uses the same object to check minimum authorizations. For example, a user must have at least a read authorization to be able to edit employee data, that is R in the Authorization Level field of the HR: Master Data object. HR transactions without natural authorization objects, such as processing system settings (cycles, features) and personnel control records, and so on. In transactions of this type, differentiated authorization checks do not take place: The system only checks whether or not the user is authorized to start the transaction. These HR transactions are protected by the HR: Transaction Codes check object. You can find a list of these transactions as follows: a. Choose Tools ABAP Workbench Development Other Tools Transactions. b. Then choose Utilities Find and finally Edit All Selections. c. Enter P* as the transaction code in the Transaction field. d. Enter the authorization object P_TCODE in the Test Object field. e. Choose Program Execute.
Structure
The P_TCODE authorization object contains the following field, which is tested during an authorization check:
Authorization Field
TCD
Long Text
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
ACTVT
Long Text
Activity
50A
38
SAP Online Help PERSA BTRTL Personnel Area Personnel Subarea
16.04.2002

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
PLVAR OTYPE INFOTYP SUBTYP ISTAT PPFCODE
Long Text
Plan Version Object Type Infotype Subtype Planning Status Function Code

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

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

The MWBFCODE check field refers to table T77MWBFCD (Function Codes for Managers Desktop).
3.1.26 P_NNNNN (Master Data: Customer-Specific Authorization Object)

Definition
Authorization object that does not yet exist in the system and that is created by you.
Use
If you have requirements that cannot be met using the P_ORGIN [page 32] and P_ORGXX [page 37] authorization objects (for example, because you want to build your authorization checks on additional fields of the Organizational Assignment infotype (0001) that are customer-specific), you can include an authorization object in the authorization checks yourself.
Structure
A customer-specific authorization object must contain the following fields:
Authorization Field
INFTY SUBTY
Long Text
Infotype Subtype
You can use any of the fields in the Organizational Assignment infotype (0001) or in the PA0001 structure. You can also use customer-specific additional fields as long as they are CHAR or NUMC type fields. In addition, you can use the following fields: TCD: This field is always filled with the current transaction code (SY-TCODE). Note that when you use this authorization object in reports, the TCD field is filled with the name of the transaction that calls up the report and not with the report name. INFSU: This field is 8 characters long. The first 4 characters contain the infotype, the last 4 characters the subtype.
50A
40
SAP Online Help
16.04.2002
Note
The system determines the period of responsibility for this object analogously to the P_ORGIN and P_ORGXX objects. For more information, see Example of Period Determination Using P_ORGIN [page 33].
See also:
Creating a Customer-Specific Authorization Object [page 41]
3.1.27 Creating a Customer-Specific Authorization Object

Procedure
1. To create the authorization object, choose the SU21 transaction. 2. First double-click an object class to select it, for example HR (Human Resources Department). 3. Then choose Create on the following screen (F5). To be able to use the new authorization object you have created in the master data authorization check, the object must contain the following fields: INFTY: Infotype SUBTY: Subtype AUTHC: Authorization Level You can use any of the fields in the Organizational Assignment infotype (0001) or in the PA0001 structure. You can also use customer-specific additional fields provided they are CHAR or NUMC type fields. In addition, you can use the following fields: TCD: This field is always filled with the current transaction code (SY-TCODE). Note that when you use this authorization object in reports, the TCD field is filled with the name of the transaction that calls up the report and not with the report name. INFSU: This field is 8 characters long. The first 4 characters contain the infotype, the last 4 characters the subtype.
4. After you have created the authorization object, start the RPUACG00 [page 109] report. This report overwrites the MPPAUTZZ standard include with the code that is needed to evaluate the authorization object you created. Note: Technically speaking, this involves a modification. However, SAP fully supports this procedure. And you should not have more maintenance work as a result of this modification. To ensure that the report actually writes the program code, deselect the Test field. Enter your user as the password. 5. Activate your checks by switching the corresponding authorization main switch NNNNN [page 44] to 1.
See also:
P_NNNNN (HR: Master Data: Customer-Specific Authorization Object) [page 40]
3.1.28 Cross-Application Authorization Objects

See the following for a description of additional authorization objects that are also important for mySAP HR: S_TABU_DIS (Table Maintenance (Using Standard Tools)) [page 42] S_TMS_ACT (TemSe: Actions on TemSe Objects) [page 42]
50A
41
SAP Online Help
16.04.2002
3.1.28.1 S_TABU_DIS (Table Maintenance (Using Standard Tools Such as SM30)) Definition
Authorization object that is used to check the authorization for displaying and maintaining table contents. This object controls users access to data only if they access the data using Standard Table Maintenance (transaction SM31), Extended Table Maintenance (SM30), the Data Browser or through Customizing.
Use
You can use this authorization object to limit users access authorization so that, for example, users with authorization for the se16 transaction (for all Data Dictionary objects) can only access data You can also deny system administrators specific access to application data, for example. As soon as you have set up this authorization object, you can edit or change only the table entries for which corresponding authorization has been granted explicitly by S_TABU_DIS.
Structure
The object consists of the following fields:
Authorization Field
DICBERCLS ACTVT
Long Text
Authorization Group Activity

The DICBERCLS field contains the authorization for tables by authorization class according to table TDDAT. Specify the names of the permitted classes in this field. Table classes are defined in the TBRG table. The ACTVT field contains the permitted operations. The following values are possible: 02: Change (add, change or delete table entries) 03: Display table contents
3.1.28.2 Definition
S_TMS_ACT (TemSe: Actions on TemSe Objects)
Authorization object that is used to determine who is authorized to perform which operations on which TemSe Objects (objects with temporary sequential data).
Use
Authorizations using S_TMS_ACT only control direct access. TemSe files are protected from applications that access their data indirectly, such as the spooler or background request management, by their own authorization checks.
Structure
The S_TMS_ACT authorization object contains the following fields, which are tested during an authorization check:
Authorization Field
STMSACTION STMSOWNER STMSOBJECT
Long Text
TemSe: Action ID for Authorizations TemSe: Owner Group for Authorizations TemSe: Generic Object Name for Authorizations
50A
42
SAP Online Help
16.04.2002

The STMSACTION field is used to define the permitted operations. The following values are possible: CRE: Create TemSe object REA: Read TemSe object DEL: Delete TemSe object APP: Append TemSe object MOD: Modify TemSe object. This currently applies only to attributes as the data of the TemSe objects cannot be changed in the current version. The STMSOWNER field is used to define the objects for which a user has authorization. The 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) [page 45]
50A
43
SAP Online Help
16.04.2002
3.2.1
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
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
Caution
Carry out the steps described in Creating a Customer-Specific Authorization Object [page 41] before you activate this check. If you fail to do this, the response of the authorization check is undefined.
3.2.4
AUTSW ADAYS (Tolerance Time for Authorization Check)
Definition
Authorization main switch that is used to specify the tolerance time of the authorization check in the event of an organizational change. You can use this switch to set up how long an administrator has access to the data he or she has created as long as this employee already has an organizational assignment outside his or her own authorization.
Values
Enter the tolerance time of time logic for master data infotypes in calendar days. In the standard system, this switch is set to 15 (= 15 calendar days). If this switch is active, that is if it contains a value greater than zero, the organizational changes that cause users to lose authorization are delayed significantly by the tolerance time.
Example
ADAYS is set to 15. Only checks using P_ORGIN are activated in the system. Administrator A has write and read authorization for data in personnel area A; administrator B has the same
50A
44
SAP Online Help
16.04.2002
authorizations for personnel area B. In addition, it is assumed that the time dependency of the authorization check (T582A-VALDT switch) is activated for all infotypes. A personnel number was assigned to personnel area A until the December 31, 1999. From January 1, 2000, it is assigned to personnel area B. Administrator As period of responsibility finishes on December 31, 1999 but she has unlimited write and read authorization until January 15, 2000 (up to and including) because of the tolerance time. From January 16, 2000, administrator A loses write authorization. She is, however, still authorized to display all the data records that have a validity date (begin date) before December 31, 1999.
3.2.5
AUTSW PERNR (HR: Master Data Personnel Number Check)
Definition
Authorization main switch that controls whether the P_PERNR [page 34] authorization object 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:
50A
45
SAP Online Help
16.04.2002
Evaluate Organizational Unit (if available) Deny Authorization by Default Grant Authorization by Default
1 3
Never Evaluate Organizational Unit

2 4
3.3 AUTHC (Authorization Level)

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

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

Definition
Field in authorization objects that is used to run diverse authorization checks by organizational assignment (using the P_ORGIN [page 32]) authorization object). The content of the organizational key is either derived by the system from the fields of the Organizational Assignment infotype (0001) or entered manually by the user.
Structure
Controlling the Creation and Validation of the Organizational Key The VDSK1 feature (Organizational Key) and the T527 (Organizational Key: Control), T527A (Organizational Key: Rules for Creating Organizational Keys), and T527O (Organizational Key: Validation) tables control the creation and validation of the organizational key.
A variable key, VARKY, is determined for this purpose using the VDSK1 feature. This key is used according to the T527 table to determine how the VDSK1 (Organizational Key) should be created or validated. The OFLAG (Default/Validation) and RULID (Rule for Creating Organizational Keys) fields are evaluated for this. The OFLAG (Default/Validation) field can have the following specifications: 1: optional entry without validation 2: optional entry with validation 3: required entry with validation 4: default that cannot be overwritten without validation 5: default that can be overwritten without validation 6: default that can be overwritten with validation 7: default that cannot be overwritten with validation If you make an entry in the OFLAG field (Default/Validation) which causes a default value to be created (specifications 4, 5, 6 or 7), you must also maintain the RULID field (Rule for Creating Organizational Key). This entry is then used to determine the corresponding rule for the organizational key in the T527A table (Organizational Key: Rule for Creating Organizational Key). If you make an entry in the OFLAG field (Default/Validation) which causes the organizational key to be validated, you must enter the values that should be recognized by the system as permitted in the T527O table (Organizational Key Validation).
50A
47
SAP Online Help
16.04.2002
Note
If an entry for OFLAG (Default/Validation) is not permitted (that is, the number is not between 1-7), the system always responds as if 1 had been entered in the field.
Example
Example of an entry in table T527:
VARKY TEST OFLAG 6 RULID XY
If the VDSK1 feature returns the TEST key, the organizational key is created according to the entries in table T527A that belong to XY. In addition, the organizational key is validated against the entries in table T527O.
Creating the Organizational Key The T527A table (Organizational Key: Rule for Creating Organizational Keys) controls the creation of the organizational key.
You can create one or several rows for each rule. The rows are always sorted according to SEQNO (sequence number). SNAME (Field Name) specifies the field of the Organizational Assignment infotype (0001) from which data should be included in the organizational key. Using the LNGTH (Length) and OFFST (Offset) fields, you can also specify that only data from certain places in the specified fields should be transported. OFFST defines the number of places that should be skipped (from the left). LNGTH specifies the number of places that should be included. The fields, or parts of fields, that have been determined for each row are placed after each other in the organizational key.
Example
Example of entries in table T527A:
RULID SEQNO SNAME LNGTH OFFST
01
XY XY XY ZZ
10
01 04 05 01
P0001-KOSTL
P0001-KOSTL P0001-PERNR P0001-KOSTL P0001-KOSTL
5
1 2 1 5
0
0 3 9 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.
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 1 1 2 2 ORGKY ADM PRO PRO TEST NODTY TEXT1 Adm. Prod. Test Test TEXT2 Administration Production Test Test
The organizational keys PRO and ADM are permitted organizational keys due to the first two rows of the table. The entries with the text Test are all irrelevant because they have an entry unequal to 1 in the HIRAR field. If there are no more entries in the T527O table, TEST, in particular, is not a permitted organizational key.
3.5 Time Logic

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

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

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

Call Parameters
A user attempts to call an employees infotype record. As a result, the authorization check is called using the following parameters: LEVEL TCLAS PERNR INFTY SUBTY BEGDA ENDDA Authorization Level Transaction Class = Difference Personnel Number/Applicant Number (A = Employee, B = Applicant) Personnel Number (or Applicant Number) Infotype Subtype Start Date End Date
Note
Note that BEGDA and ENDDA always indicate the start or end date of a data record for which the authorization should be checked. The start and/or end date of a period for which the authorization should be checked is never transferred. This ensures that the users who call up the authorization check do not have to decide which authorization to give the administrator who has access authorization only for a part of the validity period of a data record. Instead, this is determined by the time logic [page 49] of the authorization check.
Process Flow
The system performs all the following steps of the authorization check. 1. First the authorization check by personnel number (for LEVEL, TCLAS, PERNR, INFTY, SUBTY) is processed (see also Flowchart 2 [page 58]). If this check returns the result not authorized, the authorization is immediately denied. If, however, the check returns the result authorized, all further steps in the authorization check, with the exception of test procedures, are skipped. 2. If you use the structural authorization check, the users period of responsibility is determined from the organizational structure (see also Flowchart 3 [page 61]). If the defined period of responsibility is empty, the authorization is denied immediately. 3. The users period of responsibility is determined according to the PA authorization objects (P_ORGIN, P_ORGXX, customer-specific authorization object) using organizational assignments (Organizational Assignment infotype (0001)) (see also Flowchart 4 [page 67]). If the defined period of responsibility is empty, the authorization is denied immediately. 4. The intersection of both periods of responsibility is determined and is transferred as the period of responsibility to the time logic [page 49] (see following graphic, Graphic 1):
Graphic 1: Determining the Period of Responsibility
Period 1 Period 2
Result
50A
53
SAP Online Help
16.04.2002
5. The time logic compares the defined period of responsibility with the validity period of BEGDA to ENDDA (see also Flowchart 6 [page 73]). If the time logic returns the result not authorized, the authorization is denied immediately. 6. The check establishes whether a test procedure exists that prevents the data record from being changed (see also Flowchart 7 [page 76]). If this is the case, the authorization is denied. Otherwise, the user is authorized to access the data record.
See also:
Flowchart of the General Authorization Check [page 55] The individual steps of an authorization check are described one by one and presented graphically in the following: Process of the Authorization Check Personnel Number Check [page 56] Process of Determining the Periods of Responsibility [page 59] Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 70] Process of the Time Logic [page 70] Process of the Test Procedures [page 74] Process of Determining the Date After Which Changes Are Permitted for Test Procedures [page 77]
50A
54
SAP Online Help
16.04.2002
4.1.1
Flowchart of the General Authorization Check

Start authorization check
Flowchart 1: Process of an Authorization Check
authorized
Authorization check by personnel number
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
not authorized
End, user is authorized
End, user is not authorized
50A
55
SAP Online Help
16.04.2002
4.2 Process of the Authorization Check by Personnel Number

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

Start authorization check by personnel number
Flowchart 2: Authorization Check by Personnel Number
Personnel number? yes Main switch PERNR active? yes Determine personnel numbers belonging to current user (from infotype 0105, subtype 0001).
no
no
Personnel number belongs to user? yes Authorization check using P_PERNR for transferred combination of AUTHC, INFTY, SUBTY with PSIGN = *
no
yes
Authorized? no Authorization check using P_PERNR for transferred connotation of AUTHC, INFTY, SUBTY with PSIGN = E
Authorized? no Authorization check using P_PERNR for transferred connotation of AUTHC, INFTY, SUBTY with PSIGN = I
yes
yes
Authorized? nein
End, authorization is unclear
50A
58
SAP Online Help
16.04.2002
4.3 Process of Determining the Periods of Responsibility

Use
In this process, the periods of responsibility [page 49] for the general authorization check are determined. This process includes the following subprocesses: Process of Determining the Period of Responsibility According to Organizational Structure [page 59] Process of Determining the Period of Responsibility According to Structural Authorization Check [page 62] Process of Determining the Period of Responsibility According to Organizational Assignment [page 65]
The authorization check determines an intersection from the periods of responsibility returned by this process. This intersection is transferred to time logic as the period of responsibility.
See also:
Time Logic [page 49]
4.3.1
Use
Process of Determining the Period of Responsibility According to Organizational Structure
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 TCLAS PERNR INFTY SUBTY Authorization Level Transaction Class = Difference Personnel Number/Applicant Number Personnel Number (or Applicant Number) Infotype Subtype
Process Flow
The system performs all the following steps of this process: 1. The ORGPD [page 45] authorization main switch is evaluated. If the switch is deactivated, January 1, 1800 to December 31, 9999 is returned as the period of responsibility and the check is ended. 2. If the current access check is for write access to the Reference Personnel Numbers infotype (0031), January 1, 1800 to December 31, 9999 is set as the period of responsibility and the check is ended prematurely. (This situation never occurs for applicant numbers.) 3. The period of responsibility is determined according to the structural authorization profiles (the T77UA table User Authorizations and the T77PR table - Definition of Authorization Profiles). 4. The default position is determined (T77SO table System Tables, PLOGI PRELI entry). If the default position cannot be determined (for example, because no entry was found in the T77S0
50A
59
SAP Online Help
16.04.2002
table), it is not possible to perform the comparisons of position and default position listed below. In this case, the comparisons always return the result is unequal. 5. The organizational assignments of the personnel number are imported (data records of the Organizational Assignment infotype 0001). The following steps are carried out for each organizational assignment (data record of infotype 0001): If the position and default position do not concur, the organizational assignment is not evaluated further and the system moves to the next organizational assignment. If the position and default position concur, the organizational assignment is further evaluated. If an organizational unit can be determined from the organizational assignment and if the evaluation of the organizational unit is desirable (specification 1 or 3 of the ORGPD [page 45]) authorization main switch), the system checks whether the user is authorized to access the organizational unit for the validity period of the organizational assignment according to the structural authorization profiles:
a. If the user is not authorized to access the organizational unit, the organizational assignment is not evaluated further and the system moves to the next organizational assignment. b. If the user is authorized to access the organizational unit, the validity period of the organizational assignment is added to the period of responsibility. If no organizational unit can be determined from the organizational assignment or if the evaluation of the organizational unit is not desirable (specification 2 or 4 of the ORGPD authorization main switch), the default case occurs:
a. If the authorization should be denied in the default case (specification 1 or 2 of the ORGPD authorization main switch), the organizational assignment is not evaluated further and the system moves on to the next organizational assignment. b. If the authorization should be granted in the default case (specification 3 or 4 of the ORGPD authorization main switch), the validity period of the organizational assignment is added to the period of responsibility. 6. When all the organizational assignments of the personnel number have been evaluated, the period of responsibility is returned. 7. If the period of responsibility is empty, not authorized is returned as the result of the check. Otherwise, the result is authorized.
Note
The specifications 1 or 2 of the ORGPD authorization main switch always deny access authorization in the default case, that is if the structural assignment of the authorization check is impossible. Consequently, a user can no longer access the personnel numbers affected in this case. Since the organizational structure for users with unrestricted structural authorization for personnel numbers is not evaluated, these users can access all personnel numbers. This is due to the fact that the period of responsibility of these users already had the maximum possible length before the subsequent evaluation of the organizational assignment.
See also:
Flowchart of Determining the Period of Responsibility According to Organizational Structure [page 61]
50A
60
SAP Online Help
16.04.2002
4.3.1.1 Flowchart of Determining the Period of Responsibility According to Organizational Structure

Start, determine period of responsibility acc.to org. structure
Flowchart 3: Determination of Period of Responsibility According to Organizational Structure

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

01.06.1999 31.12.9999
01.06.2002 31.12.9999
01.01.1999 31.12.1999
01.01.2002 31.12.2002
Assume todays date is February 6, 2001. The following periods of responsibility are determined depending on the settings of the period:
50A
64
SAP Online Help
16.04.2002
Period Setting
<BLANK> ( = all) D ( = key date) M ( = current month): Y ( = current year): P ( = past): F ( = future):
Period of Responsibility
01.01.1999 - 31.12.1999 und 01.01.2002 31.12.2002 no period no period no period 01.01.1999 - 31.12.1999 01.01.2002 - 31.12.2002
4.3.3
Use
Process of Determining the Period of Responsibility According to Organizational Assignment
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 TCLAS PERNR INFTY SUBTY Authorization Level Transaction Class = Difference Personnel Number/Applicant Number Personnel Number (or Applicant Number) Infotype Subtype
Process Flow
1. The organizational assignments of the personnel number are determined (data records of the Organizational Assignment infotype (0001)). 2. The following steps are carried out for each organizational assignment (data record of infotype 0001): An authorization check for P_ORGIN [page 32] is performed: If there is no authorization, the validity period of the organizational assignment does not belong to the users period of responsibility. An authorization check for P_ORGXX [page 37] is performed: If there is no authorization, the validity period of the organizational assignment does not belong to the users period of responsibility. An authorization check for the customer-specific authorization object, P_NNNNN [page 40], is performed: If there is no authorization, the validity period of the organizational assignment does not belong to the users period of responsibility.
3. If all the authorization checks run successfully, the validity period of the organizational assignment is added to the users period of responsibility. 4. When all the organizational assignments of the personnel number have been evaluated, the period of responsibility is returned. 5. If the period of responsibility is empty, not authorized is returned as the result. Otherwise, the result is authorized.
50A
65
SAP Online Help
16.04.2002
Note
For applicant numbers (TCLAS = B), P_APPL [page 26] is checked instead of P_ORGIN, P_ORGXX, and the customer-specific authorization object P_NNNNN.
See also:
Flowchart of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN [page 70]
50A
66
SAP Online Help
16.04.2002
4.3.3.1.1 Flowchart of Determining the Period of Responsibility According to Organizational Assignment

Start, determine period of responsibility according to P_ORGIN, P_ORGXX, and P_NNNNN
Flowchart 4: Determination of Period of Responsibility According to P_ORGIN, P_ORGXX, and the CustomerSpecific Authorization Object, P_NNNNN
Determine organizational assignments (data records of infotype 0001)
Loop using the organizational assignments (data records of infotype 0001)
Authorization check using P_ORGIN authorized
not authorized
Authorization check using P_ORGXX authorized Authorization check using customer-specific authorization object P_NNNNN authorized Transfer validity period of organizational assignment to period of responsibility
not authorized
not authorized
not authorized
Period of responsibility empty? no
yes
End, return period of responsibility
50A
67
SAP Online Help
16.04.2002
4.3.4
Use
Process of the Authorization Check Using P_ORGIN, P_ORGXX and P_NNNNN
Within the General Authorization Check [page 6], this process performs an authorization check based on the authorization objects P_ORGIN and P_ORGXX or the customers Authorization Object P_NNNNN.
Call Parameters
A user attempts to call an employees infotype record. As a result, the authorization check is called using the following parameters: LEVEL P0001 INFTY SUBTY Authorization Level Data Record of the Organizational Assignment Infotype (0001) Infotype 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
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]
50A
69
SAP Online Help
16.04.2002
4.3.5
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)
no
Main switch active?
yes
AUTHORITY-CHECK P_ORGIN (or P_ORGXX or P_NNNNN) using fields according to organizational assignment
Authorized?
no
es
4.4 Process of Time Logic

Use
Within the General Authorization check [page 6], this process performs the time logic.
50A
70
SAP Online Help
16.04.2002
Call Parameters
The time logic is called up using the following parameters: LEVEL TCLAS INFTY BEGDA ENDDA Authorization Level Transaction Class = Difference Personnel Number/Applicant Number Infotype Start Date of Infotype Record To Be Checked 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
31.12.9999
b. The check establishes whether the validity period BEGDA - ENDDA of the infotype has a full intersection with the newly defined period of responsibility, that is whether there is at least one day, which is in both periods:
50A
71
SAP Online Help If the intersection is not empty, the time logic check returns authorized. If the intersection is empty, the time logic check returns not authorized.
16.04.2002
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].
50A
72
SAP Online Help
16.04.2002
4.4.1 Flowchart of the Time Logic

Start, time logic
Flowchart 6: Process of the Time Logic
Responsible for at least 1 day? yes Read switch for date-dependent check (T582A-VALDT)
no
Check on date-dependent basis? ja Read tolerance time ADAYS
no
Read access (level R, M)? Read access Write access 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 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
Determine end date of period of responsibility
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 (SY-DATUM) is after the end date by more than the tolerance time (ADAYS), set 01.01.1800 to end date as the new period of responsibility
If the current date is not within a responsibility interval or is after the end of all responsibility intervals by more than the tolerance time, delete all responsibility intervals that are before the current date
Is infotype record to be checked in period just determined for at least one day? yes
no
Is infotype record to be checked completely in period just determined? yes
no
50A
73
SAP Online Help
16.04.2002
4.5 Process of the Test Procedures

Use
Within the General Authorization Check [page 6], this process performs the Test Procedures [page 51].
Call Parameters
The test procedures check is called up using the following parameters: LEVEL TCLAS PERNR INFTY SUBTY BEGDA Authorization Level Transaction Class = Difference Personnel Number/Applicant Number Personnel number Infotype Subtype Start Date of Infotype Record To Be Checked
Process Flow
The system performs all the following steps of the test procedures check. The APPRO [page 45] authorization main switch is evaluated If the main switch is not activated, the authorization check returns authorized immediately. LEVEL is evaluated. If the check is for read access (authorization level R or. M), the authorization check returns authorized immediately. The check establishes which object the user should be authorized to access: If the check is for access to an applicant number or to the Organizational Assignment infotype (0001), the authorization check returns authorized immediately. If the check is for access to the Test Procedures infotype (0130), the following steps are carried out: The date after which changes are permitted is determined. This date is taken as the maximum. If the check is for access to one of the different Test Procedures infotypes, the following steps are carried out: All the test procedures that are relevant for the infotype (from the T584A table (Test Procedures Infotype Assignment)) are determined: If no test procedures are found, the authorization check returns authorized immediately. If test procedures are found, the date after which changes are permitted is determined for each test procedure (that is, for each subtype of infotype 0130). See also Flowchart 8 [page 79]):
1. The maximum of the dates that have just been defined is determined. 2. The authorization check then establishes whether the start date of the infotype record (BEGDA) is after the maximum determined by the system in the previous step: If the date is after the maximum, the authorization check returns authorized. If the date is before the maximum, the authorization check returns not authorized.
50A
74
SAP Online Help
16.04.2002
Notes
Applicant numbers are excluded from the test procedures for the following reason: The test procedures were developed for decentralized entry scenarios such as decentralized time evaluation where users evaluate time data outside the HR department. The HR department is only involved in checking the data. In this scenario, the test procedures should prevent other users from being able to change data outside the HR department after it has already been checked. Since applicant data is generally not changed outside of the HR department, such scenarios do not normally occur and are therefore not supported. Similar arguments could be put forward for the exclusion of the Organizational Assignment infotype (0001) from the Test Procedures. The real reason for excluding this infotype is the special function that it has in the authorization check. Since the Organizational Assignment infotype (0001) controls the periods of responsibility for other infotypes and in particular for the Test Procedures infotype (0130), test procedures on the 0001 infotype often cause complications in the authorization check. The 0001 infotype has therefore been excluded intentionally from the test procedures to avoid this.
See also:
The process flow of the test procedures in Flowchart 7 [page 76]. Process of Determining the Date After Which Changes Are Permitted for Test Procedures [page 77].
50A
75
SAP Online Help
16.04.2002
4.5.1
Flowchart of the Test Procedures

Start test procedure
Flowchart 7: Process of the Test Procedures
no
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? ja
no
50A
76
SAP Online Help
16.04.2002
4.6 Process of Determining the Date After Which Changes Are Permitted for Test Procedures
Use
Within the General Authorization Check [page 6], this process determines the date after which changes are permitted for the Test Procedures [page 51].
Call Parameters
The system transfers the following parameters to determine the date after which changes are permitted: PERNR CKTYP Personnel Number Test Procedures = Subtype of Test Procedures Infotype (0130)
Process Flow
The system performs all the following steps of this process. The check date (RELDT) of the specified test procedure (data record of the subtype defined by CKTYP of the Test Procedures infotype (0130)) is imported: If no date is found, every change made as of January 10, 1800 (up to and including) is permitted, that is, December 31, 1799 is taken as the date and processing is stopped at this point. If a date is found, the following steps are carried out: A personnel number check (with LEVEL = W, SUBTY = CKTYP) is performed for the test procedure (CKTYP) for the Test Procedures infotype (0130): a. If the check returns authorized, every change made as of January 1, 1800 (up to and including) is permitted and processing is stopped at this point. b. If the check returns not authorized, only changes after the check date are permitted and processing is stopped at this point. c. If the check returns authorization unclear, processing continues: The period of responsibility (for write access) is determined according to the structural authorization check. The period of responsibility (for the corresponding subtype of infotype 0130, authorization level W) is determined according to P_ORGIN, P_ORGXX and the customer-specific authorization object, P_NNNNN. The intersection of both periods of responsibility is determined and used as the period of responsibility:
If the current date (SY-DATUM) and the check date (P0130-RELDT) are not after the end of the period of responsibility, each change made as of January 1, 1800 (up to and including) is permitted. If the current date or the check date are after the end of the period of responsibility, only changes after the check date (P0130-RELDT) are permitted.
The time logic for test procedures appears at first to function differently to the general time logic of authorization checks. However, both follow the exact same process. The only difference is that when you use test procedures, you already know that the check only returns authorization for write access and that the data records of the 0130 infotype are always valid from January 1, 1800 to December 31, 9999. The time logic for test procedures is as follows: If a user has write authorization for all subtypes of the Test Procedures infotype (0130), he or she can change the check date for each test procedure and is, therefore, permitted to make changes to other infotypes independent of the test procedures.
50A
77
SAP Online Help
16.04.2002
If the user has no write authorization for a subtype of the Test Procedures infotype (0130), he or she cannot change the check date. The user is, therefore, only permitted to make changes that are after the check date to the infotypes tested by this test procedure. The general authorization check is always used to determine the date regardless of whether or not the user has write authorization for a subtype of the Test Procedures infotype (0130).
See also:
See Flowchart 7 [page 76] for a graphical representation of the test procedures and Flowchart 8 [page 79] for a graphic of how the date after which changes are permitted is determined.
50A
78
SAP Online Help
16.04.2002
4.6.1
Flowchart of Determining the Date After Which Changes Are Permitted for Test Procedures
Start, determination of date after which changes are permitted
Flowchart 8: Determination of Date After Which Changes Are Permitted
Read check date of test procedure (that is, of corresponding subtype of the 0130 infotype)
yes
No date found? no Authorization check by personnel number still no response Determine period of responsibility according to structural authorization check authorized Determine periods of responsibility according to P_ORGIN, P_ORGXX, P_NNNNN (customer-specific authorization object) 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)
authorized
not authorized
not authorized
not authorized
yes
Is the end date not before the maximum? no
End, any change made as of 01.01.1800 (up to and including) is permitted
End, any change made after check date is permitted
50A
79
SAP Online Help
16.04.2002
Interaction of General and Structural Authorizations
If you use both structural and general authorizations, a users overall profile is determined from the intersection of his or her structural and general authorization profiles. The structural profile determines which object in the organizational structure the user has access to. The general profile determines which object data (infotype, subtype) and which access mode (Read, Write, ...) the user has for those objects.
Struktural Authorization Profiles
Authorization Profiles Using HR Authorization Objects
Example
An overall profile could be put together as follows:
Overall Profile
Struktural Profile
O1
Profile with P_ORGIN INFOTYP: SUBTY: AUTHC: PERSA: PERSG: PERSK: ... 0-7 * R,M * * *
Profil 1 with PLOG OTYPE: INFOTYP: ISTAT: PLVAR: PFCODE: SUBTYP: S 1000-1010 * 01 DISP *
S1 P1
SN
PN
Profile 2 with PLOG OTYPE: INFOTYP: ISTAT: PLVAR: PFCODE: SUBTYP: P * * 01 * *
The following authorizations or restrictions apply to a user who has the overall profile illustrated above:
50A
80
SAP Online Help
16.04.2002
The user has read authorization for positions S1 to SN in infotypes 1000 to 1010 (structural profile and 1/PLOG profile). The user is not authorized to access organizational units with this profile since the user has no corresponding PLOG authorization. The user has read authorization for persons P1 to PN in infotypes 0000 to 0007. (Structural Profile and Profile/P_ORGIN). The period of responsibility for persons is determined in accordance with the period of responsibility according to structural authorization. See Determining the Period of Responsibility According to Structural Authorization [page 62]. For the user to be able to access data on persons, you need to assign the user a corresponding PLOG authorization for persons. The infotype does not have to be specified. (Profile 2/PLOG)
Examples
These examples are intentionally simple. See the explanations of the individual authorization objects and authorization checks for details on why these examples work.
See also:
Example: Employee Self-Service [page 81] Example: Administrator Should Not Be Allowed to Edit Own Data [page 82] Example: Administrator Should Not Be Allowed to Enter Data Alone [page 82] Example: Decentralized Time Recording [page 83] Example: Telephone List [page 84] Example: Payroll [page 84] Example: Transaction-Dependent Authorizations [page 84] Example: Structural Authorization Profiles [page 85]
6.1 Example: Employee Self-Service

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

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

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

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

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

Requirement
You want to achieve the best possible performance of Payroll.
Realization
Assign the payroll administrator full authorization for the activated checks. In addition, assign the payroll administrator full authorization for the P_ABAP [page 30] 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:
50A
84
SAP Online Help
16.04.2002
6.8 Example: Structural Authorization Profiles

Example 1
Field
Plan Version
Values
01
Authorization:
Due to the users authorization profile, he or she is authorized to access plan version 01.
Example 2
Field
Plan Version Object Type
Values
01 O (Organizational Unit)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in plan version 01.
Example 3
Field
Plan Version Object type Object ID Evaluation Path
Values
01 O (Organizational Unit) Organizational Unit ID ORGEH (Organizational Structure)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in plan version 01 from a root object (entry in the Object ID field) along the Organizational Structure evaluation path.
Example 4
Field
Plan Version Object Type Object ID Evaluation Path Period
Values
01 O (Organizational Unit) Organizational Unit ID ORGEH (Organizational Structure) D (current day)
Authorization:
Due to the users authorization profile, he or she is authorized to access organizational units in the structure that is valid on the current day in plan version 01.
Example 5
Field
Plan Version
Values
01
50A
85
SAP Online Help Object Type Object ID Evaluation Path Function Module O (Organizational Unit) 0 = no restriction SBESX (Staffing Assignments Along Organizational Structure) RH_GET_MANAGER_ASSIGNM ENT
16.04.2002
Authorization:
Due to the users authorization profile, he or she is authorized to access objects along the Staffing Assignments Along Organizational Structure evaluation path from a root object in plan version 01. The root object is determined in this case using the function module, that is no entry should be made in the Object ID field. The user is then granted access authorization to the organizational unit he or she manages and to all lower-level objects along the SBESX evaluation path.
See also:
Definition of Structural Authorizations [page 12]
Customer Enhancements
This section presents the possible customer enhancements for authorization checks using Business Add-Ins in mySAP HR.
See also:
HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks) [page 86] HRBAS00_STRUAUTH (BAdI: Structural Authorization) [page 97]
7.1 HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks)

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

Definition
Business Add-In (BAdI) that you can use to implement a customer-specific test procedure for the structural authorization check.
50A
97
SAP Online Help
16.04.2002
Use
You can implement a customer-specific test procedure for general and structural authorization checks using a Business Add-In (BAdI). The BAdI for the structural authorization check is called HRBAS00_STRUAUTH.
Note
You can find the Business Add-In (BAdI) in the IMG for Personnel Management under Organizational Management Basic Settings Authorization Management Structural Authorization BAdI: Structural Authorization. You can find information on implementing a BAdI in the documentation of the corresponding IMG activity. For general information on Business Add-Ins and their implementation, see also Notes under BAdI: Customer-specific authorization checks [page 86]. You can implement the BAdI using the following methods, all of which must be implemented: CHECK_AUTHORITY_VIEW FILL_DATE_VIEW FILL_HYPER_VIEW CHECK_AUTH_PLAN1
Structure
The following describes the individual methods, which are coordinated using the IF_EX_AUTHORITY_BADI interface. The method interfaces are stored in the system as documentation of the corresponding methods. Review the method documentation of the corresponding method if you are implementing a new method or changing method. CHECK_AUTHORITY_VIEW (Check Structural Authorization of an Object) This method checks a users structural authorization for an object once the set of authorized objects for this user (VIEW) is determined. This implementation should reduce runtime problems if this user should be granted authorization for large structures. This enables the check to be performed by object type or by user. The authorization check can also be implemented independently of the VIEW. FILL_DATE_VIEW (Fill Table of Authorization Ranges for an Object) This method fills the interval tables for the intervals that a user has authorization to access an object. The authorization check can also be performed independently of the VIEW created. FILL_HYPER_VIEW (Fill Table of Authorization Relationships) This method fills the relationship tables (HYPER_VIEW) for relationships that a user has authorization for. The tables can be filled by object type or by user. CHECK_AUTH_PLAN1 (Check Personnel Authorization) This method checks the structural authorization from a personnel administration perspective (for example, write or read access) and fills the period tables for which a user has authorization accordingly.
Example
In the BAdI, you can display sample implementation code under Goto Display Sample Coding. You can also view this sample code in the Class Builder (SE24), by displaying the CL_EXM_IM_HRBAS00_STRUAUTH class and the corresponding methods.
50A
98
SAP Online Help
16.04.2002
8
Use
Troubleshooting Authorization Problems
The procedures described in this section are designed to help you analyze problems that arise in connection with authorizations.
Determining Minimum Authorization

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

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

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

It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the users authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients).
Analyzing an authorization problem that occurs for only one personnel number
Authorization problems that occur for a single personnel number are caused almost always by incorrect settings in the environment of the P_PERNR [page 34] authorization object. Authorization problems that are user-independent and occur for a single personnel number are caused almost always by a specialized organizational assignment (or even an incorrect organizational assignment). In this case, you should check the data of the Actions (0000) and Organizational Assignment (0001) infotypes and the relationships with the organizational structure (actively integrated systems) thoroughly.
50A
99
SAP Online Help
16.04.2002
Analyzing authorization problems in connection with locking and unlocking infotype records
Authorization problems that occur in connection with locking and unlocking infotype records are often caused by the CHECK_AUTH_SET_ENQ (SAPFP50M) form.
Localizing the cause of authorization problems after the import of HR Support Packages
The majority of code for the HR Master Data authorization check is localized in the CL_HRPAD00AUTH_CHECK_STD and CL_HRPAD00AUTH_CHECK_FAST classes, the SAPFP50P report, and the HRAC function group. You can also find smaller parts of code in the SAPDBPAP, SAPDBPNP, and SAPFP50M reports. If authorization problems are caused by HR Support Packages, a good place to start looking for changes to the code is in the above-mentioned classes and reports.
Useful questions for solving authorization problems

Over 90% of SAPs incoming messages about authorization problems are consulting problems. What is more, in many cases customers are convinced that an error is causing their problems when in fact the problem is due to a misunderstanding of the functions of the corresponding protection mechanism. When analyzing authorization problems, it is therefore important that you can answer the following questions: What data (which infotype/subtype) did the user access and how (using which transaction or which function of a transaction)? How did the system react (did it incorrectly allow or deny access)? How should the system have reacted (should it have allowed or denied the user access)? Which authorization main switches [page 43] are set up in the system? How are the authorizations for the activated authorization checks set up? Are the data records of the Organizational Assignment infotype (0001) as they should be for the personnel number in question?
Constraints
In this section you can find information about known problems with the authorization check for mySAP HR and solutions to help you overcome these problems.
See also:
Special Features of the Authorization Check in Dialog (Master Data) [page 100] Special Features of the Authorization Check in Reporting (Master Data) [page 101] Performance Aspects [page 102] 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
50A
100
SAP Online Help
16.04.2002
exists for the corresponding data record. The authorization level [page 46] is checked in the following order: 1. W (Write) = write access 2. S (Symmetric) = write access using the Symmetric Double Verification Principle 3. E (Enqueue) = write access using the Asymmetrical Double Verification Principle. E also enables you to create and change locked records 4. D (Dequeue) = write access using the Asymmetrical Double Verification Principle. D also enables you to change the lock indicator. 5. R (Read) = read access As soon as the authorization check has run successfully, the result is stored in the buffer and the check is ended. Consequently, all write authorizations in the dialog also work as read authorizations. However, since there are special modules that check for read access directly, this can lead to an inconsistent system response.
Solution I
Ensure that you always specify a read authorization together with the write authorization.
Problem Description II
The order in which the authorization level is checked can have the following additional effect: a user with authorization levels E and D for a data record, actually needs authorization level E to access the data record in question. Due to the business importance of authorizations, you would, however, expect this user to have the same authorizations as a user with authorization level W. This is also the case for users with the combinations E with S and in particular D with S.
Solution II
In future releases, it is planned to carry out this interpretation in a business-oriented sequence rather than the present technically oriented sequence. For this reason, you should not implement any authorization concepts that are based on the authorization level combination E, D or S for an infotype for a user.
Problem Description III

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

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

Problem Description
The creation of the set of objects for the structural authorization check can be very time-intensive at runtime if the evaluation paths are extensive and the organizational structures large. This is due to the fact that the set of objects must be newly created each time a user starts or changes transaction
50A
102
SAP Online Help
16.04.2002
so that the system can evaluate organizational changes as soon as possible. Performance problems often occur when structural authorizations are used.
Solution
Performance problems can be avoided for the most part by pre-generating profiles or by defining the structural authorization profiles more clearly: 1. You can use the RHBAUS00 [page 107] report to work with pre-generated profiles. 2. When you define structural authorization profiles, avoid above all the following fields, which are described in more detail together with solutions in: 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 Profile 1: Profile 2: Root Object
O1 O1
Evaluation Path
O-S-P (Staffing Assignment Along Organizational Structure) O_O_S_C (Position per Organizational Unit)
This type of profile (several evaluation paths) is often used to implement authorization requirements that cannot be met using a standard evaluation path. In the present example, the profile needs to contain authorization for organizational units, positions, jobs, and persons. This combination is not covered by any standard evaluation path, which is why the two evaluation paths mentioned above are used. However, the creation of the set of objects takes longer because specific objects (O, S) are read several times: Evaluation Path O-S-P: O O S O O S B002 B002 A008 B002 B003 A007 O S P O S C
Evaluation Path O_O_S_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 O B002 B003 O S
50A
103
SAP Online Help S S A008 A007 P C
16.04.2002
9.3.2
Evaluation Paths with Non-Specified Target Object Types
Problem Description
The use of evaluation paths with an unspecified target object type of a relationship is an additional cause of performance problems, even though the request on the authorization profile is limited to certain (target) object types, as the following example illustrates:
Example
Assume that the authorization profile should determine the permitted persons by organizational unit and position. You can use the SBESX evaluation path for this: Evaluation Path SBESX: O O S B002 B002 A008 O S *
If you use this evaluation path, the objects linked with positions are not determined by the definition of the evaluation path but according to the T77E table (Permitted Relationships). As a result, all other objects that could be linked to a position (object types BP and US) are also imported to the set of objects. This is NOT necessary for the current requirement.
Solution
To avoid this, an evaluation path with a specified target object type should be used: The Z_SBESP evaluation path could be used for this example: O O S B002 B002 A008 O S 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.
50A
104
SAP Online Help
16.04.2002
CEO Board CFO Finance Dir.Auto Automob. Head Sv Team lead Team2 Emp Emp Team lead Team3 Emp Emp Dir.Trucks Trucks Dir.HR Corp.HR Mgr Benefits BenefitsDept PC1 PC2 Mgr Payroll Payroll Dept Emp Emp
...
...
Team lead Team1 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
All employees in the managers team
Type of Authorization
Full read and write authorization for infotypes 0000 to 0007
Business overall profile of the role Payroll Manager:
Objects
Employees in the organizational structure
This cannot be illustrated using the existing HR authorization concept because there is no relationship of any kind between an individual structural profile and an individual basis authorization. This leads to overriding.
50A
105
SAP Online Help
16.04.2002
Structural Profile 1 (Role

Manager) O1
Profile 1 using P_ORGIN (Role

Manager)
S1 P1
SN PN
Overall Profile for Manager 1
INFOTYP: SUBTY: AUTHC: PERSA: PERSG: PERSK: ...
0-7 * W * * *
+
Structural Profile 2 (Role
Payroll Manager) O2
Profile 2 using P_ORGIN (Role

Payroll Manager)
Overriding!
S2 P2
SM PM
INFOTYP: SUBTY: AUTHC: PERSA: PERSG: PERSK: ...
8,15 * W * * *
You cannot create an assignment between a users specific structural profile (here, for example, structural profile 2) and a specific general profile (profile with P_ORGIN). What in fact happens is that the structural profiles (that is, the set of objects) and the general profiles are added (in this case, using P_ORGIN) to give the overall profile. Consequently, the following effect occurs in the above example: Manager 1 has complete read and write authorization for all objects in both structural profiles. When the authorization profiles are added together, the following overall profile is produced:
Objects
All employees in the managers team and 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
Employee of organizational structure
If Manager 1 wants to carry out his or her role as Payroll Manager for the organizational structure, he or she must log on to the system with the system user Payroll_Manager.
50A
106
SAP Online Help
16.04.2002
10 Additional Functions for Authorization Checks

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

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

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

Use
You can use this report to perform a comparison of the INDX (INDX System Tables ) and T77UU (Save User Data in SAP Memory) tables.
Features
The report generates a list of users who have data of the structural authorization in the SAP Memory but who are no longer entered in the T77UU table. The report also enables you to delete the entries of the users no longer in the T77UU table from the INDX table.
10.4 RHBAUS02 Report (Check and Compare T77UU (User Data in SAP Memory))
Use
You can use this report to enter users with authorization for a large number of objects in the T77UU table (User Data in SAP Memory). This improves performance because the system saves the objects of the structural authorization in SAP Memory for the users entered in this table, which makes the authorization check run quicker.
50A
108
SAP Online Help
16.04.2002
Note
It is only meaningful to enter users in this table who have authorization for a large number of objects.
Features
The existing report enters users in the T77UU table or deletes users from this table if they have too small a number of objects depending on a threshold value. You can define the threshold value for the report. The report can then automatically perform the Save User Data in SAP Memory Customizing activity.
Note
10.5 RPUACG00 Report (Code Generation: HR Infotype Authorization Check)

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

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

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

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

Authorizations in mySAP HR 46C PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authorizations in mySAP HR 46C PDF

Uploaded by

Copyright:

Available Formats

SAP Online Help

SAP Online Help

SAP Online Help

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

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

3.7.1 3.7.2 3.7.3 3.7.4

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

4.3.3.1.1 4.3.4 4.3.5 4.4 4.5

Process of Time Logic ............................................................................................... 70 Process of the Test Procedures ................................................................................ 74

SAP Online Help 4.5.1 4.6

Flowchart of the Test Procedures ...................................................................... 76

5 Interaction of General and Structural Authorizations...............80 6 Examples ...............................................................................81

7 Customer Enhancements .......................................................86

HRBAS00_STRUAUTH (BAdI: Structural Authorization).......................................... 97

8 Troubleshooting Authorization Problems ................................99 9 Constraints ...........................................................................100

9.3.1 9.3.2 9.4

Context Problems in HR Authorizations .................................................................. 104

10 Additional Functions for Authorization Checks ...................107

11 Glossary.............................................................................110 12 Index ..................................................................................113

SAP Online Help

General Authorization Check

SAP Online Help

1.1 Setting Up General Authorization Checks

SAP Online Help

SAP Online Help

Structural Authorization Check

SAP Online Help

2.1 Structural Profiles

SAP Online Help

Graphic 1: Diagram of an organizational structure using objects and relationships

SAP Online Help O1, O4, O5

Definition of Structural Authorizations

SAP Online Help There are

SAP Online Help

SAP Online Help

Graphic 3: How the Period Field Works in Structural Profiles

SAP Online Help

A012 = "is manager of"

SAP Online Help

Assignment of Structural Authorizations

You can use this function to assign structural profiles to users.

SAP Online Help

3.1 Authorization Objects

SAP Online Help

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

More Information About the Fields

P_DE_BW (HR-DE: Statements SAPScript)

SAP Online Help

More Information About the Fields

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

P_PYEVDOC (HR: Posting Document)

SAP Online Help

More Information About the Fields

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

More Information About the Fields

P_BEN (HR: Benefit Area)

More Information About the Fields

SAP Online Help 02: Change 03: Display

P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check)

More Information About the Fields

P_PE02 (HR: Authorization for Personnel Calculation Rule)

P_PE01 (HR: Authorization for Personnel Calculation Schemas)