Authorizations in HR.pdf

8/20/2019 Authorizations in HR.pdf

1/114

SAP Online Help 16.04.2002

Authorizations in mySAP HR 50A 1

Authorizations in mySAP HR

Release 46C

H

E

L P

. H

R

A

U

T H


2/114



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 withoutthe 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 softwarecomponents of other software vendors.Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registeredtrademarks 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 WebConsortium, Massachusetts Institute of Technology.

JAVA®is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license fortechnology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAPEarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and other SAPproducts and services mentioned herein as well as their respective logos are trademarks orregistered 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.


3/114



Contents

Authorizations in mySAP HR .........................................................6

1 General Authorization Check....................................................6

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

2 Structural Authorization Check .................................................9 2.1 Structural Profiles ...................................................................................................... 10

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

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

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

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

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

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

3.1.3 P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company)......... 21 3.1.4 P_PYEVDOC (HR: Posting Document) ............................................................. 21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.19.1 Example of Period Determination Using P_ORGIN 33 3.1.20 P_PERNR (HR: Master Data – Personnel Number Check) .............................. 34

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

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

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

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

3.1.25 S_MWB_FCOD (BC-BMT-OM: Allowed Funct. Codes for Manager’s Desktop)40

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

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

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


4/114



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

3.1.28.2 S_TMS_ACT (TemSe: Actions on TemSe Objects) 42

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

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

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

3.2.3 AUTSW NNNNN (HR: Customer-Specific Authorization Check)....................... 44 3.2.4 AUTSW ADAYS (Tolerance Time for Authorization Check) ..............................44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2 Process of the Authorization Check by Personnel Number ......................................56 4.2.1 Flowchart of the Authorization Check by Personnel Number ............................ 58

4.3 Process of Determining the Periods of Responsibility ..............................................59

4.3.1 Process of Determining the Period of Responsibility According toOrganizational Structure.....................................................................................59

4.3.1.1 Flowchart of Determining the Period of Responsibility According toOrganizational Structure 61

4.3.2 Process of Determining the Period of Responsibility According to theStructural Authorization Check...........................................................................62

4.3.3 Process of Determining the Period of Responsibility According toOrganizational Assignment ................................................................................ 65

4.3.3.1.1 Flowchart of Determining the Period of Responsibility According toOrganizational Assignment 67

4.3.4 Process of the Authorization Check Using P_ORGIN, P_ORGXXand P_NNNNN................................................................................................... 68

4.3.5 Flowchart of the Authorization Check Using P_ORGIN, P_ORGXXand P_NNNNN................................................................................................... 70

4.4 Process of Time Logic...............................................................................................70

4.4.1 Flowchart of the Time Logic ............................................................................... 73

4.5 Process of the Test Procedures ................................................................................74


5/114



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

4.6 Process of Determining the Date After Which Changes Are Permitted forTest Procedures ........................................................................................................77

4.6.1 Flowchart of Determining the Date After Which Changes Are Permittedfor Test Procedures............................................................................................79

5 Interaction of General and Structural Authorizations...............80

6 Examples ...............................................................................81

6.1 Example: Employee Self-Service .............................................................................. 81

6.2 Example: Administrator Should Not Be Allowed to Edit Own Data........................... 82

6.3 Example: Administrator Should Not Be Allowed to Enter Data Alone.......................82

6.4 Example: Decentralized Time Recording.................................................................. 83

6.5 Example: Telephone List ........................................................................................... 84

6.6 Example: Payroll........................................................................................................84

6.7 Example: Transaction-Dependent Authorizations ..................................................... 84

6.8 Example: Structural Authorization Profiles................................................................ 85

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

7.1 HRPAD00AUTH_CHECK (BAdI: Customer-Specific Authorization Checks) ........... 86

7.1.1 Examples of the HRPAD00AUTH_CHECK BAdI ..............................................90

7.1.2 Example of the Implementation of HRPAD00AUTH_CHECK ...........................91

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

8 Troubleshooting Authorization Problems ................................99

9 Constraints ...........................................................................100

9.1 Specific Processing of the Authorization Check in Dialog (Master Data) ............... 100

9.2 Special Features of the Authorization Check in Reporting (Master Data) .............. 101

9.3 Performance Aspects .............................................................................................. 102

9.3.1 Redundant Read of Objects.............................................................................103

9.3.2 Evaluation Paths with Non-Specified Target Object Types .............................104

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

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

10.1 Report RHPROFL0..................................................................................................107

10.2 RHBAUS00 Report (Regeneration INDX for Structural Authorization) ...................107

10.3 RHBAUS01 Report (Output of Views on Objects in the Structural Authorization) .. 108

10.4 RHBAUS02 Report (Check and Compare T77UU (User Data in SAP Memory))... 108

10.5 RPUACG00 Report (Code Generation: HR Infotype Authorization Check)............ 109

11 Glossary.............................................................................110

12 Index ..................................................................................113


6/114



Authorizations in mySAP HR

Purpose

Authorizations control system users’ access to system data and are therefore a fundamentalprerequisite 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 youcan set up HR-specific structural authorizations that check by organizational assignment if a user isauthorized 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] forall relevant technical information about both authorization types.

Integration

You can set up both authorization types (general access authorizations and structuralauthorizations) simultaneously. This can lead to a complex interaction of authorizations. For moreinformation, see Interaction of General and Structural Authorizations [page 80].

Features

This documentation explains for each authorization type the characteristics you should single outand how you can use them to set up authorizations. For more information about the authorizationtypes, 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 forauthorizations, 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 authorizationrequirements.

1 General Authorization Check

Use

The general authorization check for mySAP HR controls access to Human Resources infotypes.

Integration

This authorization type applies to the general SAP authorization check, which is set up using thetransaction PFCG. The authorization objects that are used only in mySAP HR are HR-specificauthorization objects.


7/114



Features

Authorizations are defined by authorization objects. An authorization object specifies the fields thatoccur in an authorization. The system checks if a user has the corresponding authorization forcertain field specifications in the user master record.

Authorizations are grouped together in authorization profiles.

A user’s 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 SAPsystem. For more information, see Authorization Objects [page 18].

The authorization main switch controls the use of authorization objects. For more information aboutthe authorization main switches, see HR: Authorization Main Switches [page 43].

In addition to the authorization objects and the main authorization switches, the following technicalaspects 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 authorizationobject.

• 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 byorganizational 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 relevantsubsteps 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 upGeneral Authorization Checks [page 7].

Example

The following examples demonstrate how you can accommodate simple authorization requirementsfor 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


8/114



perform in the system. Authorizations are parts of roles and are stored as an authorization profilefor 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 tomanually. 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 theroles. A user menu should therefore contain only the functions that are required by a specific userwith 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 deliveredby SAP have the prefix SAP_).

2. In the Menu tab page, assign transactions, reports, and/or web addresses to the role. By doingthis, you set the user menu that is automatically called up when the user assigned to this rolelogs on to the SAP system. When you assign transactions and so on, the user’s role or taskprofile is defined. The transactions defined in Menu tab page are then used by the system tocreate authorizations automatically.

3. You can change the authorizations that were automatically created by the system if you need toby setting the menu in the Authorizations tab page. To do so, choose the Expert Mode optionunder Maintain Authorization Data and Generate Profile in this tab page.

You can create additional authorizations when you change the authorizations that you havealready 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) inOrganizational Management . You cannot use the profile generator for this type ofassignment; you must use transaction SU10 (User Maintenance: Mass Changes) inOrganizational Management .

Caution

The generated profile is only entered in the user master record once a user comparisonhas taken place. A comparison is also required if changes are made to the usersassigned 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).


9/114



2 Structural Authorization Check

Use

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

Integration

You can integrate the structural authorization check with the general authorization check. Note thatif you do so, the authorizations entered for each authorization type may influence one another. Formore 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 HumanResources components (Organizational Management, Personnel Development, Training and EventManagement, etc.)

Features

You can grant authorizations for objects that are stored in a hierarchical structure using thestructural authorization check. If you specify a root object, you can determine that all objects in thehierarchy 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 accessto objects that they are responsible for.

This flexibility is achieved in two steps. First by using the (initial) structure built in OrganizationalManagement to define the authorization profiles. And second by using a concept to storeauthorization profiles that reacts automatically/dynamically to changes in the organizationalstructure, 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 intime-dependent structures:


10/114



O1

O2 O3 O4

O5 O6 O7 O8 O9

O11 O12

O10

An organizational structure divides into three subtrees (organizational units O2, O3, and O4) on thesecond 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 thisorganizational structure that allow him or her to read/change data in O1, O2 or O3 AND in all lowerlevel organizational units.

If you were to use the general authorization concept (values in fields) here, you would have to enterall 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 followingobjects 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 involveconsiderable maintenance work to the initial profile and to the organizational structure if changeswere made to it.

If the organizational structure was expanded to include the organizational units O11 and O12, forexample, you would have to add the O2 and lower level objects profile to include 011 and 012manually.

Structural profiles, on the other hand, allow you to copy profiles, such as the O2 and lower levelobjects profile, by entering a start object (in this case, O1) and an evaluation path. This requiresminimal 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 OrganizationalManagement, Personnel Development and Training and Event Management to build hierarchiesusing objects and relationships. Different types of objects (Object Types) and different types ofrelationships are used in this process. The organizational structure of a company is illustrated in thefollowing way:


11/114



S1

P1

O6

S4

O1 O2

O0

B008:

Holder

A002: reports to

O3

S5

P5

O4

S2

O5

S3

P4

A003:

belongs to

A003: belongs

to

B008:

Holder

Graphic 1: Diagram of an

organizational structure usingobjects and relationships

P2 P3

B008:

Holder

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

•

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 theirdefinition: The definition of an evaluation path determines the start object and which object typesusing which relationships are selected.

Example

The evaluation path O-S-P (Staffing Assignments along Organizational Structure) is anexample of an evaluation path (and also a standard evaluation path that plays a centralrole in Authorizations) that is defined as follows:

ObjectType

Relationship Relationship Name Related ObjectType

O B002 is line supervisor of O

O B003 incorporates S

S A008 holder P

This evaluation path starts selection from an organizational unit (O) that is used as thestart 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 (OB002 O).

The following organizational units are selected for the structure in the above example:


12/114



O1, O4, O5

Second, the evaluation paths starts selection from the selected organizational unitsaccording to row 2 of the definition (O B003 S) and selects the followingpositions:

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 startobject 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 anexisting structure. This exact combination or the objects returned by this combination, represents auser’s structural profile. Note that neither the number of objects nor the specific objects that arereturned by a structural profile are constant, nor is this desirable. The concrete objects that arereturned 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 beused to define structural profiles. These fields simply allow you to add more detail about frequentlyoccurring standard cases, but use the basic principle of “start object plus evaluation path”. SeeDefinition of Structural Authorizations [page 12] for more information on these fields and how tocreate 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 authorizationobject for the structural authorization check

• AUTSW ORGPD (HR: Structural Authorization Check) [page 45]: Importance of theORGPD 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 Definition of Structural Authorizations

Use

You can use this function to define structural authorizations. You can define structuralauthorizations using the T77PR table (Definition of Authorization Profiles).


13/114



There are

• Structural authorizations for the Organizational Management, Personnel Development, and Training and Event Management components – described in this section.

• Structural authorizations that should be used for more specific authorization checks (onaccount of the organizational structure) during the processing of HR master data. SeeInteraction of General and Structural Authorizations [page 80] for detailed information.

IntegrationTo assign profiles, use the T77UA table (User Authorizations = Assignment of Profile to Users). Formore information, see Assignment of Structural Authorizations [page 17].

Prerequisites

To be able to understand and set up structural authorizations, you must have knowledge of thePersonnel Development data models (Organizational Management , Personnel Development ,Training and Event Management , and so on). For more information, see Structural Profiles [page10].

Features

You can use the following fields in the T77PR table (Definition of Authorization Profiles) to defineauthorizations for HR objects (the fields are described according to their sequence in themaintenance 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. Ifyou use a system that integrates the Personnel Administration (PA-PA) and OrganizationalStructure (PA-OS) components, note that plan version 01 is generally the integrated planversion.

• 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 adifferent key (for example, cost centers). Technically speaking, this includes allauthorization objects that are entered in the T77EO table (External Object Types) but that

do not have an inverse relationship (INREL = ). You can use the general

authorization check of the relevant application for external objects without an inverserelationship.

• 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 toa 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 onlyauthorized to access objects along this evaluation path.

You must also assign a root object for the structure when you use an evaluation path. Thisroot object can either be entered directly in the corresponding field of the T77PR table(Definition of Authorization Profiles), or determined dynamically using a suitable functionmodule.


14/114



The choice of evaluation path has a decisive influence on the overall performance of thesystem. 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 canfind 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 isauthorized 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.

O3 S4O2

S2 S3S1

Level 1

Level 2

Level 3

O1

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 profilesshould be created which process the structure “bottom up”.

If you make no entry in this field (default value ) or enter a + sign, the structure is

processed in the normal “top down” manner.

• Period

In this field, you can define the profile according to the validity period of the structure. Youcan enter the following options: Key date, all, and different periods such as current year,current month and so on.

If you select the entry D (current day), the structural authorization is limited to the structures

valid on the current day.

If you define a structural authorization for a manager using period D, the manager is

authorized to access data on all persons who are currently in the manager’s group.

If you do not make an entry (default value ), the structure is not limited by validity

period. If you define the profile using the period, the manager is authorized to

access data on former or future employees in addition to the authorization in the above

example.


15/114



The Period field has, therefore, no influence on the period for which a user is authorized toaccess a specific object. In other words, the structural authorization check, unlike thegeneral authorization check, does not return periods of responsibility. Instead, the systemoutputs 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 authorizationcheck for further processing. See Flowchart of Determining the Period of Responsibility

According to Structural Authorization Check [page 62] for a description of how theperiod of responsibility is determined for the general authorization check.

S1

P1

O1

P2

S2

01.01.1999 - 31.12.9999

Graphic 3: How the Period Field Worksin Structural Profiles

01.01.1999 - 31.12.2000 01.01.1999 - 31.12.9999

Due to different values in the Period field, the user is authorized to access different sets ofobjects for the data in the above diagram.

Example

For the following two examples, which refer to graphic 3, the system date is set toFebruary 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 andthe relationship between S1 and P1 ends before February 6, 2001.

Example 2:

Period: (= all)

If you enter (= All), the user is granted access to P1 and P2.

• Function Module

You can use this field to specify a function module that determines the root objectdynamically at runtime. Do not make an entry in the Object ID field. However, you mustspecify the Plan Version and Object Type fields.


16/114



The advantage of using function modules is that each time you define an authorizationprofile, 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 T77PRtable (Definition of Authorization Profiles) does not need to be changed. What is more, thenumber of entries in the T77PR table can be reduced significantly by setting up functionmodules.

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 useras manager by position and by relationship A012 (is manager of ) is determined as theroot object.

This function module is key date-related, that is only the organizational units that areassigned to the user as manager on the current system date are determined as rootobjects for that user.

S1

P1US1 A268 S2

P2US2 A268

O1 O2

O0

B008

B008

A003

A012 = "is

manager of"

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.

User 2 (US2) has no root object (with the

same profile) and therefore has no structural

authorization.

− RH_GET_ORG_ASSIGNMENT (Organizational Assignment )

When you use this function module, the organizational unit that is organizationallyassigned to the user is determined as the root object.


17/114



Graphic 5: How theRH_GET_ORG_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 usesthis 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.

S1

P1US1 A268 S2

P2US2 A268

O1 O2

O0

B008

B008

A003

2.1.2 Assignment of Structural Authorizations

Use

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

Integration

Structural profiles are not assigned in the same way as general authorization profiles. Whereasgeneral authorization profiles are assigned using the Profile Generator (PFCG transaction), youassign 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). Ifone or more entries exist, the set of objects is mapped according to the profile definition. The set ofobjects 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 processingindicator 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 entryexists, 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.


18/114



3 Technical AspectsThe following paragraphs explain how you set up general and structural authorizations and provideyou with an outline of the technical aspects of authorizations, in other words, of all the technicalobjects, checks, and additional setting options that play a part in setting up these authorizationtypes.

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 ObjectsIn certain contexts, you may need several authorizations to perform an operation in the SAPsystem. The resulting contexts can be very complex. The SAP authorization concept has beenrealized on the basis of authorization objects to provide an understandable and easy-to-followprocedure. 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 anaction. An authorization object groups up to ten authorization fields that are checked in an ANDrelationship.

For an authorization check to be successful, all field values of the authorization object must bemaintained in the user master data.

Authorization objects are assigned to object classes for purposes of clarity. The authorizationobjects 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 canalso 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 thestandard system, consists of the following fields:

Authorization Field Long TextINFTY Infotype

SUBTY Subtype

AUTHC Authorization Level

PERSA Personnel Area

PERSG Employee Group

PERSK Employee Subgroup

VDSK1 Organizational Key


19/114



You can therefore assign authorizations for personnel data in Human Resources atinfotype/subtype level according to the employee’s personnel area, employee group,employee subgroup, and organizational key .

The following sections describe the authorization objects for the HR (Human Resources) objectclass and selected authorization objects from the BC_A (Basis - Administration) object class thatalso play an important part in mySAP HR .

NoteIn most cases, the individual fields of the authorization objects are described by meansof 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 eachauthorization object.

Authorization objects for the HR object class:

• P_CH_PK (HR-CH: Pension Fund: Account Access) [page 20]

• P_DE_BW (HR-DE: Statements SAPScript) [page 20]

• P_DK_PBS (HR-DK: Authorization Check for Access to PBS Company) [page 21]

•

P_PYEVDOC (HR: Posting Document) [page 21]

• P_OCWBENCH (HR: Activities in the Off-Cycle Workbench) [page 22]

• P_BEN (HR: Benefit Area) [page 22]

• P_CATSXT (HR: Time Sheet for Service Providers Type/Level Check) [page 23]

• P_PE02 (HR: Authorization for Personnel Calculation Rule) [page 24]

•

P_PE01 (HR: Authorization for Personnel Calculation Schemas) [page 24]

• P_HRF_INFO (HR: Authorization Check InfoData Maintenance HR Forms) [page 24]

• P_HRF_META (HR: Authorization Check Master Data Maintenance for HR Forms) [page 25]

•

P_CERTIF (HR: Statements) [page 25]

• P_APPL (HR: Applicants) [page 26]

• P_PYEVRUN (HR: Posting Run) [page 27]

• P_PCLX (HR: Clusters) [page 28]

• P_DBAU_SKV (HR: DBAU: Construction Pay Germany – Social Fund Procedure) [page 28]

• P_PCR (HR: Payroll Control Record) [page 29]

• P_ABAP (HR: Reporting) [page 30]

• P_ORGIN (HR: Master Data) [page 32]

•

P_PERNR (HR: Master Data – Personnel Number Check) [page 34]

• P_ORGXX (HR: Master Data – Extended Check) [page 37]

• P_TCODE (HR: Transaction Code) [page 37]

• P_USTR (HR: US Tax Reporter) [page 38]

• PLOG (Personnel Planning) [page 39]

• S_MWB_FCOD (BC-BMT-OM: Allowed Function Codes for Manager‘s Desktop) [page 40]

• P_NNNNN (Customer-Specific Authorization Object) [page 40]

The following authorization objects are also important for mySAP HR :

•

S_TABU_DIS (Table Maintenance (Using Standard Tools such as SM30)) [page 42]


20/114



•

S_TMS_ACT (TemSe: Actions on TemSe Objects) [page 42]

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

Definition

Authorization object that is used during the authorization check for access to pension fund accounts(PF Accounts). This check takes place in transactions or reports that process account data.

Structure

The P_CH_PK authorization object contains the following fields which, are tested during anauthorization check:

Authorization Field Long Text

KONNR Number of Individual PF Account

AUTGR HR-CH: Authorization for PF Accounts

PKKLV HR-CH: Pension Fund: Authorization Level for Account Access

More Information About the Fields

• The KONNR field specifies which pension fund accounts an administrator is authorized to

access.

• The AUTGR field specifies the permissible authorization groups for the authorization check.

•

The PKKLV field specifies which operations (authorization level) the user is authorized to

perform in pension fund accounts. The following values are possible:

-: No Access

R: Read authorization

W : Write authorization

X: Extended authorization (for example, offsetting entries for postings or changing the lockdate)

3.1.2 P_DE_BW (HR-DE: Statements SAPScript)

Definition

Authorization object that enables you to determine the authorization check within statements (withSAPScript) for Payroll Germany.

Use

Only edit this authorization object if you have first set up statements with SAPScript. You can dothis 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 anauthorization check:


BEWID Statement Identifier

BSUBJ InfoSet Identification for Statements

BACT Activities for Statements in Authorization Check


21/114




• 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 istherefore only authorized to navigate within these two functional areas.

If an administrator has authorization for all functional areas, the user parameters can onlybe used to simplify coordination since the initial access branches directly to this functionalarea.

You can configure up to 30 functional areas.

•

The BACT field contains the activities for statements that are valid as part of the authorizationcheck. 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 toPBS 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 anauthorization check:


PBSFIRMA HR_DK: Company Used for PBS

3.1.4 P_PYEVDOC (HR: Posting Document)Definition

Authorization object that is used to protect actions on posting documents.

Structure

The P_PYEVDOC authorization object contains the following fields, which are tested during anauthorization check:


BUKRS Company Code

ACTVT Activity


22/114




The ACTVT field contains the activities for posting documents that are possible as part of theauthorization 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-CycleWorkbench)

Definition

Authorization object that is used during the authorization check for the off-cycle workbench. TheP_OCWBENCH authorization object ensures that each administrator sees only the off-cycleactivities that he or she is authorized to perform.

Structure

The P_OCWBENCH authorization object contains the following field which is tested during anauthorization check:


P_OCTYP Type of Off-Cycle Activity


The P_OCTYP field contains the activities for the off-cycle workbench that are possible as part of the

authorization check. The field can have the following values:

OC: Run Off-Cycle Payroll

HI: Display History

PR: Replace Payment

AC: Assign Check Number

PV: Reverse Payment

3.1.6 P_BEN (HR: Benefit Area)

Definition

Authorization object that is used during the authorization check for benefits. This check takes placewhen benefit tables are edited or read.

Structure

The P_BEN authorization object contains the following fields, which are tested during anauthorization check:


PBEN_AREA Benefit Area

ACTVT Activity


The ACTVT field contains the activities for benefits that are possible as part of the authorization

check. The field can have the following values:


23/114



02: Change

03: Display

3.1.7 P_CATSXT (HR: Time Sheet for Service ProvidersType/Level Check)

Definition

Authorization object that is used during the authorization check for task type and task level in theTime Sheet for Service Providers.

Use

The P_CATSXT authorization object is used for the following checks in the CATSXT andCATSXT_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 timerecording according to different organizational perspectives.

Structure

The P_CATSXT authorization object contains the following fields, which are tested during anauthorization check:


CATS_AUTHP Personnel Number Check

TASKLEVEL Task Level

TASKTYPE Task Type

BUKRS Company Code


KOSTL Cost Center



ORGEH Organizational Unit

ACTVT Activity


• The CATS_AUTHP field contains the processing mode that is permitted for the authorization

check. The following values are possible:

E: Processing your own personnel ID

O: Processing a different personnel ID

Note

To determine your own personnel ID, infotype 105 must be defined in the system.

•

The ACTVT field contains the permitted activities. The following values are possible:

01: Add (currently not used)


24/114



02: Change (edit or copy data from the history)

03: Display (currently not used)

06: Delete (delete data from history)

71: Evaluate (currently not used)

3.1.8 P_PE02 (HR: Authorization for Personnel Calculation Rule)Definition

Authorization object that is used during the authorization check for personnel calculation rules.

Structure

The P_PE02 authorization object contains the following field, which is tested during anauthorization check:


P_AUTHPE02 Personnel Calculation Rule: Authorization

3.1.9 P_PE01 (HR: Authorization for Personnel CalculationSchemas)

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 anauthorization check:


P_AUTHPE01 HR Schema: Authorization

3.1.10 P_HRF_INFO (HR: Authorization Check InfoDataMaintenance for HR Forms)

Definition

Authorization object that is used during the authorization check for the processing of infotypes forHR Forms.

Structure

The P_HRF_INFO authorization object contains the following fields, which are tested during an

authorization check:


MOLGA Country Grouping

P_HRF_INET HR Forms: InfoNet

ACTVT Activity


The ACTVT field contains the activities for the InfoData maintenance of HR Forms that are possible

as part of the authorization check. This field can have the following values:

02: Change


25/114



03: Display

3.1.11 P_HRF_META (HR: Authorization Check Master DataMaintenance 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 authorizationobject to restrict the actions a user can carry out.

Structure

The P_HRF_META authorization object contains the following fields, which are tested during anauthorization check:


P_HRF_TYP HR Forms: Object Type


P_HRF_MOBJ HR Forms: MetaData Object

ACTVT Activity


The ACTVT field contains the activities for the MetaData maintenance of HR Forms that are

possible as part of the authorization check. This field can have the following values:

02: Change

03: Display

3.1.12 P_CERTIF (HR: Statements)

Definition

Authorization object that is used in Statements to check which tasks an administrator is authorizedto perform.

Use

This object is used only in Statements. Only edit this authorization object if you have first set upstatements 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 certaintask.

In report creation, this object determines whether an administrator is authorized to make changeswhen displaying statements that have already been created (this corresponds to individualcreation).

Structure

The P_CERTIF authorization object contains the following fields, which are tested during anauthorization check:



BESNR Statement Number



26/114




• 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 administratorby user assignment:

Authorization Country Grouping Statement Number Authorization Level

P_CRF_ALD 01 * ES

P_CRF_TENLD 01 01-10 L

P_CRF_DRUA 03 * AD

3.1.13 P_APPL (HR: Applicants)

Definition

Authorization object that is used during the authorization check of Recruitment infotypes. Thechecks take place when applicant infotypes are edited or read.

Structure

The P_APPL authorization object contains the following fields, which are tested during anauthorization check:


INFTY Infotype

SUBTY Subtype



APGRP Applicant Group

APTYP Applicant Range



27/114



RESRF Responsible Personnel Officer


• 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, anauthorization may only exist for certain time intervals depending on the user’s authorization. Auser’s period of responsibility is represented by all the time intervals for which he or she has

P_APPL authorizations (see also example of the period of responsibility using P_ORGIN [page

33]).

Note

Unlike the P_ORGIN and P_ORGXX authorization objects, the check on thisauthorization object cannot, in principle, be deactivated (that is, there is nocorresponding 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 anauthorization check:


P_EVTYP Run Type

P_EVSIMU Posting Run: Simulation Indicator

ACTVT Activity


• The P_EVTYP field contains the run type that is to be tested during the authorization check. The

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


28/114



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 anauthorization check:


RELID Area Identifier for Clusters in Tables



• 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 ofClusters 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 SocialFund Procedure.

Use

This authorization object determines which reports with which parameters or which processingsteps 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 anauthorization check:


REPID ABAP Report Name

ZVKAS Social Fund

RZNUM Data Processing Center Number for Constr.Ind.SI Fund


29/114



ACTVT Activity


•

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


01: Add or Create

03: Display

06: Delete

Example

An administrator should have the following authorizations regarding the evaluation report for thesocial 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 administratorby user assignment:

Authorization Report Name Social Fund Data Center Activity

P_DBAU_SKV_A RPCBLFD0 * * 03

P_DBAU_SKV_E RPCBLFD0 02 * 01

P_DBAU_SKV_L RPCBLFD0 02 12345678 06

3.1.17 P_PCR (HR: Payroll Control Record)

Definition

Authorization object that is used during the authorization check for payroll control record.

Use

This check takes place when the control record is displayed using transaction PA03, or when thecontrol record is maintained. The check also takes place during maintenance using the payrollmenu.

Structure

The P_PCR authorization object contains the following fields, which are tested during anauthorization check:


ABRKS Payroll Area

ACTVT Activity


30/114




The AUTHC field contains the activity for the authorization (for example, Display). The following


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 anauthorization check:


COARS Degree of Simplification of the Authorization Check

REPID ABAP Report Name


Using P_ABAP in HR Reporting:

You can use the relevant authorizations for this object to control how the objects P_ORGIN,P_ORGXX, and the customer-specific authorization object P_NNNNN are used in the specifiedreports to check the authorization of HR infotypes. You can also use reports to control the infotypeauthorization check. This can be useful for functional reasons or to improve performance at runtimeof the corresponding reports.

For this object, enter the report name(s) in the REPID field and the degree of simplification to be

used for the authorization check in the COARS field.

The following degrees of simplification are possible:

• Authorization using COARS = or no authorization. The authorization checks are to

be processed as in

• Authorization using COARS = 1.The authorization checks for theinfotype/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 theprogram and that the user has a read authorization for the organizational assignment of thepersonnel number.

•

Authorization using COARS = 2. The authorization check is inactive.


31/114



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) cannotperform any more authorization checks. In general, you will only want to deactivate theauthorization checks for a very small number of Reports. In case of doubt, do notassign 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 authorizationchecks. In HR reports, these checks are carried out in addition to the HR infotypeauthorization check. HR Reporting, however, overrides the HR infotype authorizationcheck for selected reports, with the result that the authorization checks are weakenedor completely switched off.

Examples

• In your company, the authorization for infotypes is set up independently of the authorizationfor specific organizational units. For example, an administrator is authorized to accessaddress, personal, and education data and is responsible only for personnel area 0101.

This does mean that the administrator would be authorized to access addresses inpersonnel 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 theauthorization 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 protectionis 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 startthe report (S_PROGRAM ( ABAP: Program Run Checks) authorization object), but performno 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 doesnot 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 theauthorization check, but does affect the runtime required to produce the result is authorizedto. 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 cannotsee or can see only partially, the system must read the Basic Pay (0008) infotype, amongstothers, during time evaluation. To be able to carry out time evaluation, the timeadministrator must have a display authorization for the Basic Pay (0008) infotype. On theother hand, the user should not have general display authorization for the Basic Pay (0008)infotype. To restrict the read authorization for the Basic Pay (0008) infotype for employees

with the 0001TIMEXXX organizational key in the RPTIME00 report, use the following

authorizations:

• P_ORGIN (HR: Master Data) – two authorizations:

INFTY = 0008

SUBTY = *

AUTHC = R

VDSK1 =

...

INFTY =

SUBTY =


32/114



AUTHC =

VDSK1 = 0001TIMEXXX

...

• Object P_ABAP (HR: Reporting ):

REPID = RPTIME00

COARS = 1

A simple check is carried out for the infotype authorization check in conjunction with theRPTIME00 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 – TimeEvaluation), all fields of the object P_ORGIN (HR: Master Data) are checked together. Thischeck 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. Theperson who starts this kind of evaluation normally has extensive infotype authorizations. In thiscase, 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 inAccounting:

The payment medium programs in Accounting specifically process extremely sensitive personaldata. As an additional security measure, the system checks whether the user has a correspondingauthorization 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 – ReportNames) 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 takesplace when HR infotypes are edited or read.

Structure

P_ORGIN contains the following fields, which are tested during an authorization check:


INFTY Infotype

SUBTY Subtype







33/114




• 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 authorizationlevels 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 mayonly exist for certain time intervals depending on the user’s authorization.

Note

The time dependency of infotypes is stored in table T582A (Infotypes – Customer-

Specific Settings) in the VALDT field.

A user’s period of responsibility is represented by all the time intervals for which he or shehas P_ORGIN authorizations.

See also:

Example of Period Determination Using P_ORGIN [page 33]

3.1.19.1 Example of Period Determination Using P_ORGIN

Authorization check using P_ORGIN for:

INFTY = 0014

SUBTY = M120

AUTHC = R

The data available in the Organizational Data infotype (0001):

01.01.2000 – 31.12.2000: 01.01.2001 – 31.12.2001: 01.01.2002 – 31.12.9999:

PERSA = DE01 PERSA = US01 PERSA = DE01 PERSG = 1 PERSG = 1 PERSG = 1

PERSK = DA PERSK = DA PERSK = DB

VDSK1 = 42 VDSK1 = 42 VDSK1 = 42

The user’s authorizations available in the user master record:

INFTY = 0014

SUBTY = M120

AUTHC = R

PERSA = DE01

PERSG = 1

PERSK = *

VDSK1 = *

as well as

INFTY = 0015

SUBTY = *

AUTHC = *

PERSA = *

PERSG = *


34/114



PERSK = *

VDSK1 = *

The following authorization checks are performed by the system:

For the period January 1, 2000 – December 31, 2000:

INFTY = 0014

SUBTY = M120

AUTHC = R

PERSA = DE01

PERSG = 1

PERSK = DA

VDSK1 = 42

Due to the first authorization in the user master record, the authorization check is successful. Theperiod belongs to the period of responsibility.


INFTY = 0014SUBTY = M120

AUTHC = R

PERSA = US01

PERSG = 1

PERSK = DA

VDSK1 = 42

The first authorization in the user master record denies access to PERSA = US01, the second

denies access to INFTY = 0014. The authorization check is unsuccessful and the period does not

belong to the period of responsibility.


INFTY = 0014

SUBTY = M120

AUTHC = R

PERSA = DE01

PERSG = 1

PERSK = DB

VDSK1 = 42

Due to the first authorization in the user master record, the authorization check is successful. Theperiod belongs to the period of responsibility.

Result

In this example, the period of responsibility consists of the periods January 1, 2000 – December31, 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


35/114



this check is active and the user has been assigned a personnel number in the system, it candirectly override all other checks with the exception of the test procedures. This check does nottake place if the user has not been assigned a personnel number, or if the user accesses apersonnel 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 anauthorization check:



PSIGN Interpretation of Assigned Authorization

INFTY Infotype

SUBTY Subtype


The PSIGN field (Interpretation of Assigned Authorization) can have the following values:

I: include (for additional authorizations)

E: exclude (for authorizations that are to be removed)

Example

The authorization checks for P_ORGIN and P_PERNR are activated in the system. In addition,there are user assignments for some personnel numbers.

The user in our example is assigned a personnel number and is administrator responsible for theBasic 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 notchange his or her basic pay, irrespective of the personnel area for which the employee isresponsible. The corresponding authorizations for the P_PERNR authorization object must be setup 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 underthe employee’s personnel number. The second authorization denies write authorization for all datarecords of the Basic Pay infotype (0008) stored under the employee’s personnel number.

The authorization checks for all other personnel numbers and for write authorizations for allinfotypes (except Basic Pay (0008)) run according to P_ORGIN.


36/114



Caution

As the following example

Authorizations in HR.pdf

Documents

Transcript of Authorizations in HR.pdf