HR Security

SAP HR Organizational Management Tutorial Part 1 In this tutorial we will cover the key concepts in the OM module of SAP HR • • • •

Object Types Entities within OM are maintained as object types (e.g. Org Units, positions ,jobs) Relationships Links objects together (e.g. person to position, position to Org Unit) Validity Dates Validates life span of objects Info types Data input screens used to record relevant information

Object Types Each aspect of OM is recorded as an object type, a way of grouping similar data together. For example, organizational unit is an object type, position is another object type. Relationships There are many objects within OM, and the creation of relationships is the way that data is linked together. When you build the hierarchical organizational structure, you are creating a relationship between organizational unit objects. If you attach a position to an organizational unit, you are creating a relationship between the position object and the organizational unit object. Validity Dates Whenever you create an abject or a relationship between objects, you must enter start and end dates. These validity dates ensure that data entries can only be made within a specified lifespan. Info types These are the data input screens used to record the OM information. Some info types are automatically updated ‘behind the scenes’; other info types require you to manually input the information. Lets look into the different OBJECT TYPES in detail OM is based upon the use of Object Types and Relationships. Object Types group similar data together. Although an organizational plan can consist of many object types, the five basic building block object types and their ‘codes’ are as follows:

• •

•

The Personnel Administration (PA) module of the SAP HR system holds the person related data in info types in the master data file. The Organization Management (OM) module looks at the organization’s departmental structure and holds the data in object types. OM object types are a way of grouping similar data. The system assigns a code for each object type. These objects are created and maintained separately and are then linked together using relationships. Organizational unit

• • • • •

Object type O is used for Organizational Unit. Organizational units are units of your company that perform a function. These units can be departments, groups or project teams, for example. You create the organizational structure of your company by relating organizational units to one another. The organizational structure is the basis for the creation of an organizational plan.

Position

• • • •

Object type S is used for Position. Positions are used to distribute tasks to different positions and to depict the reporting structure in your organizational plan. Positions are concrete and are held by employees in a company. Positions are assigned to organizational units and can inherit characteristics from a job. Job

•

Object type C (classification) is used for Job.

•

• •

Positions are held by people in the company (e.g. secretary in the marketing department, HR manager). Jobs, in contrast, are classifications of functions in an enterprise (e.g. secretary, manager), which are defined by the assignment of tasks and characteristics. Jobs serve as job descriptions that apply to several positions with similar tasks or characteristics. When you create jobs, they are listed in a job catalog. When you create a new position (e.g. secretary in the marketing department), you can relate it to a job that already exists in the job index (e.g. secretary). The position then automatically inherits the tasks and characteristics of the job. This significantly reduces data entry time, as tasks and characteristics do not have to be assigned to each position separately, instead they are inherited via the descriptive job. Note however, that specific tasks and characteristics can also be assigned directly to positions.

Jobs are also important in the following components: • • •

Personnel Cost Planning Career and Succession Planning Compensation Management

When you create jobs, they are listed in a job catalog. A job catalog is a list of jobs maintained for an enterprise. Cost Center

• •

Object type K is used for Cost Center. Cost centers are a Controlling/Finance item that represents the origin of costs. Cost center are external from OM and will be created and maintained in the Controlling module. Cost centers can have relationships with either organizational units or positions.

•

Cost center assignments are inherited along the organizational structure.

Person • • •

Object type P is used for Employee. A person is generally an employee in the company who holds a position. Additional information for employees is maintained in PA (e.g. address, basic pay, etc.).IT0001 (Organizational Assignment) contains the position assignment, defining job, organizational unit, and cost center assignment.

Other noteworthy Object Type is TASKS • •

Object Type T is used for tasks Tasks are individual duties and responsibilities that must be undertaken by employees

Tasks can be clubbed under two headings • As part of workflow • As part of personnel management to describe jobs and positions SAP HR Organizational Management Tutorial Part 2 Relationships We need to look at two types of Relationships in SAP 1. Relationships with same Object Types 2. Relationships with different Object Types Let’s look into them in detail –

Relationships with Same Object Types

• •

• • •

Organizational units are related with each other to form a hierarchical structure. Each organizational unit is created as an individual object type. Using the example above, the organizational unit of “Region Office” is an object type, as are the organizational units of Finance & Accounting and Human Resources. To create the interrelated hierarchy, a relationship must exist between Regional Office and Finance & Accounting and between Regional Office and Human Resources. Relationships are formed in both directions, therefore Regional Office incorporates Finance & Accounting and Finance & Accounting belongs to the Regional Office. When you create a relationship between objects, SAP automatically creates the corresponding reverse relationship. Relationships with Different Object Types

• •

Any SAP organizational unit will have positions attached to it. The organizational units object would therefore be linked the position object types as a relationship. In the example detailed above, the organizational unit object of Human Resources has a relationship of ‘incorporates‘ with the position object of HR Manager, therefore the

position object of HR Manager has a relationship of ‘belongs to‘ with the organizational unit object of Human Resources. Common relationships

• •

Objects are linked though relationships. You create relationships between the individual elements in your organizational plan. Several linked objects can represent a structure. There are different types of relationships, as the type of connections between elements varies

SAP HR Organizational Management Tutorial Part 3

Once you have created different OM Objects , you will need to maintain Info types related to it. Let’s look into SAP-HR OM Info type Maintenance – There are two Methods to Maintain SAP – Organizational Management Info types 1. Using Organization and Staffing Transaction 2.Using the Expert Mode. In this tutorial we will look into the Expert Mode The Expert Mode is an interface that is ideal for maintaining details. Individual objects are selected using the Object Manager. Info types for that particular object can now be maintained. Transaction code PP01 can be used to maintain all object types. Due to authorization restrictions, you may not have access to PP01. Instead, you will have to use one of the following transactions, which restrict access to one particular object type: • • • •

PO10 Organizational Unit PO03 Job PO13 Position PO01 Work Center

The PP01 screen is shown below. Screens for PO10,PO03,PO13 & PO01 are very similar

1. Plan Version: It is important to ensure that you are working in the correct plan version at all times (for this you can also default the plan version in the user parameter

2. Object Information: The object type, ID and abbreviation are displayed so the user can ensure that the right object is being edited. 3. Status: Select the status of the info type you want to maintain using the tab pages (select Active which has status = 1). 4. Info type: Select the info type you want to maintain. 5. Validity Period: Start and end dates specify the period during which the object exists in the plan version selected. Important OM Infotypes 1.IT0001 – Description: It gives an Object’s Abbreviation and Name

2.IT0002- Relationships:

• • • •

•

There are many different relationship types that you can create between object types Each individual relationship represents a subtype of the Relationships infotype (IT1001). Not all relationships apply to every object. Relationship records can manually be created using the Expert Mode interface, but they are also automatically created when using other interfaces (e.g. Organization and Staffing, Simple Maintenance). When creating a relationship, the inverse relationship is usually automatically created by the system.

HR Basics

SAP HR deals with private employee data much of which might be of sensitive nature. As a result the HR security is typically more stringent that security for the other SAP modules. In a lot of non HR applications, security is more geared towards prevention of wrongful entry of data into the system. However, in the case of HR, even the display of private data might lead to non compliance with prevailing laws and regulations. Other than the overtly sensitive nature of HR data, another reason of separating it out into its own category on this site is to emphasize two unique provisions in HR. •

•

Firstly, most of SAP security is based on positive authorization; i.e. presence of a particular authorization in the user buffer gives access to new functionality. HR is one area where negative authorization can also be used in addition to the existing positive authorizations. Negative authorization in this case prevents a user from accessing some application due to the presence of a certain authorization in his user buffer. Secondly, HR uses structural authorizations to restrict HR access to a certain hierarchy within an authorization independent to the general authorizations assigned through roles.

Info types Info types or Information Types always form an integral component of any discussion on SAP HCM. In general info types are structures to stores related HR data. For example, address of an employee is stored in a unique info type 0006. Similarly we have different info types storing personal data (0002), bank details (0009), basic salary (0008), etc. Some info types are further sub-divided into subtypes, an example being the address info type. An address entry can belong to the subtype permanent residence, temporary residence, emergency address, mailing address, etc. Info types are relevant from a security standpoint as SAP provides standard authorization objects which allow us to secure info type, subtype combinations for users. The first thing to note from the above examples is that all of them are attributes of a person. You store address of a person, salary of a person, bank details of a person. However, info types can just as well store attributes of HR objects like positions, jobs, tasks, etc. Depending on whether an info type stores attributes for a person or a HR object, we can divide them into info types required in Personnel Administration (PA) or Personnel Planning (PP) respectively. The PP info types are also referred to as info types for Organizational Management (OM) or Personnel Development (PD). The distinction between PA and PP info types is important for security as the two basic types of info types are secured by means of different authorization objects. Another point to note from the above examples is the fact that each info type is associated with a unique 4 digit number. This unique identifier might vary from 0000 to 9999 and is broken into sub-ranges depending on the type of the information stored as shown below •

0000 – 0999 – Personnel Administration (PA)

• • • •

1000 – 1999 – Personnel Planning (PP) 2000 – 2999 – Time Management (PA) 4000 – 4999 – Recruitment (PA) 9000 – 9999 – Customer Specific (Can store either PA or PP information depending on info type configuration

This preliminary introduction to info types would help us in our later discussions when we investigate ways to secure individual info types.

Types of HR Data A discussion of SAP security for a particular application area, like HR, FICO, SD, MM generally starts with an outline of the applications/transactions for the particular area and the authorization objects needed to secure them. This is fully justified as most of the time; security administrators are given a list of tcodes and asked to provide security for them. Starting from the t-code list we would normally look up the individual SU24 entries, look up the documentation for the linked authorization objects, determine if the default values of the linked authorization objects are enough to grant access, investigate whether the SU24 entries for the transaction should be changed and maintain appropriate values for the objects in the roles depending on requested access. In the present article, we will adopt a slightly different approach for HR. Instead of the transactions that we are trying to secure, let us instead start with a discussion of the data we are trying to secure. SAP application security is remarkably consistent while accessing the same data, even though data is accessed through different transactions. So once we get a hang of the authorization objects needed to secure a class of data, we can basically use the same objects to secure any transaction which use the same data. HR data, other than configuration data, are contained in three basic groups of tables. Personnel Administration (PA) data consists of attributes for people, whether employees or applicants and is stored in the PA info types. We have already come across PA data in our introductory article on Info types. Each info type in general is associated with a table in the Data Dictionary. Data for employees are stored in PA tables while data for applicants are stored in PB tables. For ex, employee addresses will be stored in PA0006 while applicant addresses is stored in PB0006. All PA and PB tables share a common authorization group PA. So unless we are prepared to modify the default authorization groups for each table, a person with access to PA authorization group through standard table maintenance transactions (like SE16, SM30, SM31), will have access to ALL the PA/PB tables. Due to the sensitive and private nature of PA data, this level of access is rarely given to any user in a production system. Instead access is given to individual info type, subtype combinations. The authorization objects to secure PA data for employees are P_ORGIN (CON), P_ORGXX (CON) and P_PERNR while P_APPL is used to secure PA data for applicants. Personnel Planning (PP) data store for “HR Objects”. These objects are identified by letter codes like Person (P), Position (P), Organization Unit (O), Job (C), Cost Center (K), Task (T), etc. These different HR objects are used for Personnel Planning, Personnel Development or

Organizational Management. PP data is also stored in info types but the underlying tables are of the form HRPXXXX where XXXX = unique info type id. (Ex Info type Object (1000) is stored in table HRP1000. Some PP info type like IT 1017 have both a corresponding HRP and HRT tables, HRP1017 and HRT1017. This is determined by the structure of the info types and doesn’t impact security). Security for PP info types is controlled by authorization Object PLOG. The final major types of HR data are contained in HR clusters. These are cluster tables PCL1, PCL2, PCL3, etc which store time evaluation results, payroll results, etc. Access to HR payroll clusters is controlled through the P_PCLX authorization object. Now let us leverage our knowledge of the different types of HR data and the corresponding authorization objects to provide security for one of the most common HR transactions, PA30 which allows the maintenance of HR Master Data. Specifically we use the transaction to maintain the address of a user. The first screen shows the initial PA30 screen when we have selected the user to modify.

PA30 - Initial Screen

Now we select the address info type and click the change button which leads us into the Address screen. We can update the address maintained for the employee. In addition PA30 allows us to save maintain text for an info type entry by using the menu path Edit->Maintain text. An info type with maintained text is indicated by the highlighted text icon in the info type header as shown below.

PA30 - Update Address In the sequence of actions above we update address (IT 0006) of an employee. Since address is an attribute of an employee we know that we are dealing with PA data. As a double confirmation, address data is stored in IT 0006 which falls in the range of PA info types (refer to the earlier post on info types for individual ranges). Hence we would need to provide update access (W = Write) to authorization objects P_ORGIN (CON), P_ORGXX (CON) and P_PERNR for info type 0006. Which of these objects are actually checked are determined by the values of the authorization switches which we have already encountered

in an earlier post? In addition to the actual address we also maintained some text for the info type entry. This text however is not stored in the info type table but in cluster tables. So an update access to P_PCLX is needed as well. The su24 entry for PA30 makes our job easy as it already provides the default cluster id which stores the text (clusters PC and TX). We are not updating attributes for any HR objects in the above sequence. So we do not need to be concerned with PLOG. However, there are other operations in PA30 which infact updates PD data. Hence, SU24 defaults for PA30, list PLOG as well. The above analysis becomes especially useful when trying to secure obscure t-codes without correct SU24 defaults maintained. Once we understand what kind of data the tcode is accessing, we can predict what all security is needed to execute it.

Authorization Switches In our article on SU24, we saw the feasibility of selectively switching off checks for certain authorization objects. However, HR objects (objects for authorization class HR) can not be marked as “Do not check”. However, there is another option for selectively switching off checks for HR objects. This is done be setting the values of authorization switches (through transaction OOAC) or directly modifying the HR config table (T77S0). The available authorization switches are shown below.

HR Authorization Switches You can look at the standard SAP documentation for the functionality of each of the switches but let me list a few of them •

• •

AUTSW – ORGIN – Switch on (1) or off (0) for authorization object P_ORGIN. This object is used to check for access to Personnel Administration (PA) master data through info types. AUTSW – PERNR – Switch on or off check for P_PERNR object for an employee’s own personnel number AUTSW – ORGPD – Switch off (0) or on (1,2,3,4) the structural authorization checks.

Securing PA Data We have already come across PA (Personnel Admin) master data in our initial discussion of different types of the HR data. Out of the box, SAP provides three main authorization objects for securing PA master data, P_ORGIN, P_ORGXX and P_PERNR. Let’s see how we can use each one of these in our security design landscape. PA master data stored in different info types is essentially the attributes for the employees of the organization. To store these attributes each employee is associated with a unique personnel number or PERNR. SAP HCM currently allows a person to have multiple pernrs as part of its extended configuration but that is beyond the scope of our discussion on basic HR security. The basic transaction for maintenance of PA master data is PA30. The first screenprint shows the initial screen of PA30 with the pernr and name of an employee.

PA30 - Initial screen In HR, the pernr similar in use to the system id used in the security system. In fact we use the info type 0105 (communication), subtype 0001 to store the SAP system id

corresponding to the pernr for a user. Later we will find that this link is mandatory for the use of the P_PERNR authorization object.

PA30 - Info type 0105 The first step in using any of the PA master data authorization objects is switching on the corresponding authorization switches for them in the transaction OOAC. For ex, to switch on security checks for P_ORGIN and P_PERNR we need to set the authorization switches AUTSW-ORGIN and AUTSW-PERNR values to 1 respectively. Once switched on, any access to PA master data will check the user master for these authorization objects. The most important info type with regard to any discussion on PA master data security is the Organization Assignment (0001) info type. The screen-print below shows the IT 0001 screen with the different data contained in it. This info type is important as the data fields of this info type are also part of the general authorization objects and are checked during data access. For ex, Personnel Area, EE group, EE subgroup, Cost Center, Payroll Area and the three Administrator fields are all used in the authorization objects.

PA30 - Info type 0001 The three common authorization objects with their authorization fields are given below P_ORGIN (HR: Master Data) Authorization Field

Long Text

INFTY

Info type

SUBTY

Subtype

AUTHC

Authorization Level

PERSA

Personnel Area

PERSG

Employee Group

PERSK

Employee Subgroup

VDSK1

Organizational Key

P_ORGXX (HR: Master Data – Extended Check) Authorization Field

Long Text

INFTY

Info type

SUBTY

Subtype

AUTHC

Authorization Level

SACHA

Payroll Administrator

SACHP

Master Data Administrator

SACHZ

Time Recording Administrator

SBMOD

Administrator Group

P_PERNR (HR: Master Data – Personnel Number Check) Authorization Field

Long Text

AUTHC

Authorization Level

PSIGN

Interpretation of Assigned Authorization

INFTY

Info type

SUBTY

Subtype

As you might have noticed, many of these fields were part of the org assignment info type. Thus if a security concept is built around personnel area, employee group, employee subgroup we can switch on the check for P_ORGIN and use the auth object in our roles or if the security concept is based around the time, master data and payroll administrators we can use the P_ORGXX authorization object. In some rare scenarios we might even want to use both the authorization objects in our roles. A case where both of them might be used is a scenario where we have different master data administrators for a single personnel area. Here instead of creating of roles with all the different combinations for P_ORGIN (Personnel Area)

and P_ORGXX (Administrators), we can reduce the number the of roles by separating out these two accesses into different roles. Finally a combination of the P_ORGIN and P_ORGXX roles will be assigned to a user to make up the total access of a HR rep. You would also notice that the standard authorization objects do not have any option to secure PA data at the level of the personnel sub area or cost center. A solution in such cases is provided by the Organization Key field. This is a 14 character field which can be configured to be derived from any of the IT 0001 fields or can be even manually entered by the administrator. The P_PERNR authorization object is a bit different in functionality from the other two objects. The P_PERNR object provides one of the very few examples of negative authorization concept in SAP. The object is used to provide different authorization to an administrator when accessing his own PERNR. The most common example is of a compensation analyst having access to update the basic pay info type. Though as part of his usual responsibility, how would be expected to maintain the basic pay of other employees, we would not want him to give himself a raise. It’s at this juncture that P_PERNR and its negative authorization comes to the rescue. The master data authorization of this person might typically be maintained as the following P_ORGIN INFTY 0008 PERSA * AUTHC W, R, M P_PERNR INFTY 0008 PSIGN E AUTHC W, D, S, E In the above case, the P_ORGIN authorization gives the comp analyst access to maintain (AUTHC – W – Write) the basic pay (IT 0008) for others but when accessing his own pernr, the value of P_ORGIN is over-ridden by the access in P_PERNR. The value of PSIGN as E (Exclusive) denotes that while accessing IT 0008 for his own pernr, his access will exclude the values maintained for AUTHC (W, D, S, E). The only possible values for AUTHC which excludes the 4 given values are R (Read) and M (match code) and as a result the administrator only has display access to his own pay data. It’s very important to remember a few points when trying to use P_PERNR. Firstly P_PERNR can only be used to provide access to a person’s own pernr or personnel record. A corollary of this, is the requirement that for P_PERNR to work a valid system id should be maintained for IT 0105, subtype 0001. This is necessary as the SAP system

needs to identify a personnel record with a user master record. Secondly, the only two possible values of the PSIGN field are E (Exclusive) and I (Inclusive). A value of * doesn’t make much in this case as by definition, a * value can be interpreted as either of the two possible values.

Securing PD Data Personnel Development (PD) Data is part of the Personnel Planning (PP) Data model used in SAP HCM. The PP Data model is made up distinct HR object types like positions (S), Persons (P), Jobs (C), Tasks (K), etc. The main use of this data is in Personnel Development (PD), Organizational Management (OM) and the Training and Event Management submodules of SAP HCM. In contrast to the PA master data which essentially store data for persons, PD data mainly store the attributes of the different PP object types. Also, the allowed PP info types depend on the object type and are controlled through configuration settings. PD data is especially relevant for security as it used to define the Organizational Structure of an enterprise and Organizational Structure in turn is used for the position based security assignment and structural authorizations. PD data is secured by the authorization object, PLOG (Personnel Planning). The fields of this object are given below. Authorization Field

Long Text

PLVAR

Plan Version

OTYPE

Object Type

INFOTYP

Info type

SUBTYP

Subtype

ISTAT

Planning Status

PPFCODE

Function Code

We can better appreciate the use of this object by looking at one of the basic transactions for maintenance of PD data – PP01.

PP01-Initial Screen In the initial screen of PP01, we can easily spot the fields for Plan Version, Object types, Info types and Planning Status (the tabs for Active, Planned, Submitted, Approved, Rejected). The buttons highlighted in the toolbar are for different activities on the info type selected. The permissible activities for the object and info type combination are contained in the PFCODE field of the authorization object. Among the huge multitude of possible values of PFCODE like INSE (create), disp (display), DEL (delete), CUTI (delimit), LISD (List Display), AEND (Change), LIST (List Display with Change), etc we discuss only the last two. In the first example we select info type Object (IT 1000) and click the change button. The info type change screen allows us to change the name and abbreviation of the object (AEND)

PP01- Change Object In the second example, we select Relationship (IT 1001) and click the second button from right to get into the Overview Screen which shows all the “relationships” created for the Object. The access being tested is LIST. Also note that accessing overview screen from a pure display transaction like PP01_disp would have checked for LISD (List display). IT 1001 is also one of the PD info types which can be secured at the subtype level. Each relationship record shown on the screen (like A002 – reports, B007 describes) is a separate subtype and is meant to link two different object types. The different relationships between these PP objects are actually used to build the entire Organizational Hierarchy of the enterprise.

PP01- List Display with Change In addition to the PLOG object, PP objects can be further secured through Structural Authorizations.

P_ABAP (HR Reporting) The authorization checks for PA master data (through P_ORGIN, P_ORGXX, P_PERNR, etc) while running HR reports are very involved and pose a significant performance penalty to the system. For each pernr selected in the report, the authorization system carries out a check for each of the info types being accessed. The P_ABAP (HR Reporting) is used in such cases to simplify the authorization check for PA master data when running HR Reports based on the logical databases SAPDBPNP or SAPDBPAP. The fields available in the object are given below Authorization Field

Long Text

COARS

Degree of Simplification of the Authorization Check

REPID

ABAP Report Name

The COARS field can have two values corresponding to two different degrees of simplification. • •

COARS = 1. The authorization checks for the info type/subtype combination and for organizational assignment are to be checked separately. COARS = 2. The report is run without any authorization checks for PA master data.

In practice, P_ABAP can be used in two main cases. A value of COARS = 1 can simplify the authorization checks significantly reducing the time needed to execute a report. This is the case for a number of reports in the pay-time component of HCM. For example, an export of PA master data during a typical payroll run would have to read a large number of PA info types for all the employees in the enterprise. Using P_ABAP in this case would ensure that the report completes in a reasonable amount of time. Also since these reports are generally run by payroll staff who already have access to almost all user data, a detailed authorization check for all users’ info types is often unnecessary. A second case for using P_ABAP appears when we want non HR users to be able to run some non sensitive reports on HR data without giving them direct access to P_ORGIN, P_ORGXX and similar objects. A value of COARS = 2 would enable these users to run the said report without any authorization check for PA master data. Its important to note that a P_ABAP authorization is always restricted to particular reports as a value of * or SAPDBPNP would allow any reports on master data to be run without checking proper authority checks.

Organizational Management This article about organizational management is meant to be a launch pad to our discussion on structural authorizations- an unique and indispensable part of HR security. We have already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Let’s take the discussion forward to the next level. OM deals with the representation of the personnel organizational structure within an enterprise within SAP HCM. OM uses the same data model as used by Personnel Planning. The data model uses object-oriented design and uses the concepts of • • •

Object Types Relationships Info types

The data model can be represented by the following graphic. Note that object types, Person and Cost Center are shown as orange boxes instead of blue ones. These are External Objects and not created in the OM component. However, they have relationships with normal OM objects.

OM Data Model A typical org structure when represented by the same data model might look something like the graphic (transaction PPOC) shown below

PPCO - Org structure showing positions and org units In OM, each element in an organization is represented by a distinct object with individual characteristics. Relationships are used to link one object to another. The objects and their relationships can be created and maintained through standard transactions (like PP01). The network created by objects and relationships are flexible enough to facilitate personnel planning, projections and evaluations of the org structure. Customizing is used to enhance the existing object types or create completely new ones. Customizing also allows the creation of new relationships and maintenance of those relationships for existing or new object types. Each standard object type is represented by a letter code (P = Person, O = Org Unit, S = Position, C = Job) while customized object types are represented by two letters like 9P. Relationships on the other hand are represented by a 3 digit code like 008 (belongs to), 012 (manages). Customer relationships are also 3 letters long but start with Z, like Z20. The unique object id for an object type is stored in IT 1000 (table HRP1000)

HRP1000 - Positions While the relationship between two objects is stored in the IT 1001 (table HRP1001).

HRP1001 - Relationships for a position Finally, the org structure composed through these two tables is displayed through the PPOSE transaction as shown below

PPOSE - Org Structure Display

Evaluation Paths An Evaluation Path is a chain of relationships between related OM objects in the Organizational Hierarchy. Different evaluation paths can be used to return different sets of OM objects even when all of the individual paths start from the same start object. As such, evaluation paths are used in a lot in OM reports and in structural authorizations. Evaluation Paths are created/maintained through the transaction OOAW shown below. The standard SAP system ships with a number of pre-defined evaluation paths. Since the standard evaluation paths can only use the standard relationships and objects defined in SAP, it stands to reason that we need to create new evaluation paths to use our own relationships/OM objects.

OOAW - View for Evaluation Paths As an example we select the evaluation path PERSON and see how it’s defined

OOAW - Define Evaluation Path

The PERSON evaluation path is meant to return the OM objects used in staffing along a standard organizational hierarchy. As such it can be used to evaluate the DR of a line supervisor and is used as such in the MANAGER structural profile. The definition of the evaluation path starts with an org unit. The path returns all positions (S) assigned to the start org unit (O) and the persons (P) linked to the said positions. Finally to build the entire org hierarchy the path continues to evaluate the sub-ordinate org units and positions (lines 30 and 40). Once defined, the evaluation path can be used to return a particular view of the org hierarchy through the PPST transaction.

PPST - Evaluation Options

The report output shows the evaluated objects.

PPST - Report Display In the next article, we explore the use of evaluation paths in defining structural authorizations or PD profiles

Structural Authorizations Structural Authorizations as the name suggests are used to restrict access to a certain organizational structure. As such they are only used while accessing HR data. In general, structural authorizations serve two purposes

• •

Restrict access to certain OM objects like Org Units, Jobs, Tasks, and Qualification Catalogs etc. In interaction with the access to authorization objects for PA master data, they can restrict access to certain set of persons in the enterprise.

While using structural authorizations, it’s important to note that •

•

•

A person’s total authorization is a result of the interaction between his general authorizations (through roles) and his structural authorizations (through PD profiles). Secondly, structural authorizations are always used to restrict access. You can never use structural authorizations to grant access. It can only be used to restrict access to a smaller set of objects or people than is already given though a general authorization. While using structural authorizations to restrict access, we need to ensure to add access to the corresponding objects is also added to the user’s roles through PLOG.

PD Profiles – Definition PD profiles are created through the OOSP transaction. SAP provides a few standard profiles but to a large extent, PD profiles are created by individual customer depending on their requirements.

OOSP - PD Profiles The definition of PD profiles is stored in the T77PR table. Let’s have a look at the definition of the standard PD profile for “MANAGER”

T77PR - PD Profile Definition Some features to note about the definition of the PD profile. • •

• • • •

Each record in the table is independent of the other records and gives access to a certain number of objects. Each record has values for PV (Plan Version), OT (Object Type ), Object ID, EvalPath (Evaluation Path), StatV (Status Vector), Depth, M (Maintenance Flag), Selection Period and Function Module. PV denotes the plan version for which the profile is valid. OT is the object type of the object id value. Object ID gives the start object when an evaluation path is used in the profile or an individual object. If evaluation path is maintained, the PD profile returns the object along the PD profile. Maintaining an evaluation path will only work if a start object value is maintained explicitly or dynamically through Function Modules.

•

•

• •

•

Status Vector is used to determine the status of the objects/relationships while creating the structure. A StatV of 12 for example will consider relationships of status Active (1) or Planned (2). Depth determines the level of the hierarchical structure till which the evaluation path is constructed. No maintained value indicates that the entire org structure returned by the evaluation path will be constructed. Maintenance (M) flag determines whether a person will be able to maintain the returned objects. Period determines the validity period of the objects/relationships while creating the structure. A value of D creates the structure which is valid on that day. A blank value indicates that the structure is not limited by the validity dates for the corresponding relationships. The function module field can be used to dynamically generate a start object. Efficient use of this option can greatly reduce the maintenance effort for PD profiles. Two standard function modules are supplied by SAP, RH_GET_MANAGER_ASSIGNMENT returns the org unit for which the user is a chief while RH_GET_ORG_ASSIGNMENT returns the org unit for a user. New function modules can be created by customers as per requirement.

PD Profiles – Assignment PD profiles can be assigned to users in two basic ways •

Transaction OOSB can be used to assign one or more PD profiles directly to users. Adding entries to the T77UA table through SM30/SM31 has the same effect.

OOSB - Assign PD Profiles

•

PD profiles can also be assigned to OM objects like positions through info type 1017 (through transactions like PP01/PP03).

PP01-Create PD Profile for Position Also note that a user without an entry in the T77UA table would by default have the PD profile access which is assigned to the SAP* user in the table. SAP provides a standard program RHPROFL0, to read the PD profile values from IT 1017 for a position and create an entry in the T77UA table for the user assigned to the position. For SAP installations using indirect assignment of profiles, this program is generally scheduled to run in batch every night. A screen with the various options available for this program is shown below.

RHPROFL0 - Transfer IT entries to T77UA Assigning the PD profiles to the position instead of direct assignment in the T77UA table can potentially save a lot of effort in manual maintenance of profile entries and is the recommended practice.

PD Profiles – Performance In a large organization using structural authorizations, the PD profiles assigned to a user might return thousands of distinct objects. Evaluating the entire PD profile at run time to generate the object list, for each access to HR data, can lead to a significant degradation in performance of HR transactions. Since the performance penalty is mostly due to the evaluation of the entire object list for a user during run time, the situation can be improved by storing the list of objects for a user. SAP provides a table T77UU to store an index of all objects returned by the PD profiles for each user. However, since this is a static list of the objects we have to periodically regenerate the index for all users who are maintained in this table. If a user is not entered in this table, his PD profiles are evaluated at runtime to generate the object list. This will consume more time but will not adversely impact performance if the number of objects for the user is below a certain critical threshold. The T77UU table is very rarely maintained manually. SAP provides two programs, RHBAUS02 – Check and compare T77UU (user data in SAP memory) and RHBAUS00 – Regeneration of INDX for Structural Authorization, to automate updating of the table and regeneration of the user indexes. The screen below shows, the selection criteria for the RHBAUS02 report. The report can be run for one or multiple users and for a certain threshold level of HR objects. The program evaluates the PD profiles for all the users entered in the selection screen and if the number of authorized objects returned is more than the threshold value updates the user in the T77UU table. Conversely if the number of objects for a user falls below the threshold, the user entry is removed from the T77UU table. Typically, a weekly batch run should be sufficient to take care of changing org structure and the profile assignment for users.

RHBAUS02 - Update user data in SAP memory The RHBAUS00 program is generally run after the last run for RHBAUS02 has completed and hence finished updating entries in T77UU. The RHBAUS00 program re-generates the indexes, and hence the objects authorized for a user, for all users entered in selection whose entries also exist in T77UU. In a practical scenario the OM structure of an enterprise keeps changing from day to day. Since, the index only stores the objects that were effective during the last time when it was re-generated, RHBAUS00 should be scheduled to be run periodically. A daily batch run for the program is mostly sufficient to take care of the changing org structure however even in such cases; indexes of individual users might need to be specifically regenerated through the program or its linked tcode, S_PH0_48000110.

RHBAUS00 - Regenerate user INDX

Context Solution In the modern enterprises, it’s very common that dual responsibilities are performed by the same individual. For example a Line Manager in the Training department of an Organization needs access to certain info types (like org assignment, personal data, education, etc) for all employees as part of the process structure. In addition to the above, by virtue of his position in the org hierarchy as a Line Manager, he would also need significantly more access (like basic pay for instance) to the employees who report up to him. This is problem of contextual security and is can not be handled properly through the structures that we have covered so far. Let us investigate further about the possible security solution in this case and try to understand why it might not meet the full requirements. We would need at least two roles for the training manager – on role with training info types and a second one with info types needed by the line manager. Further we also likely to have two PD profiles as well – on with access to all employees and the other with access to only the direct reports. When the 2 structural and general authorization profiles are assigned to the same person, like to the Training Manager in our discussion, we find that he has access to both sensitive and non sensitive info types for all employees. The sensitive access is not limited to only the direct reports as the security system has no way of understanding that access in the manager role needs to be restricted to only the direct reports (the people who are part of the manager PD profile). The context solution introduced as part of SAP R/3 4.7 seeks to address this very gap in HR security. The context solution introduces new authorization switches and the corresponding authorization objects. To switch on checks for any of the new objects, the

corresponding switches should be set to 1. It’s also customary to switch off checks (value 0) for the non context authorization objects. The relevant switches are given below • • •

AUTSW-INCON HR: Master Data (Context) for object P_ORGINCON AUTSW-XXCON HR: Master Data – Enhanced Check (Context) for object P_ORGXXCON AUTSW-NNCON HR: Customer-Specific Authorization Check (Context) for customer specific authorization object. The switch corresponds to AUTSW-NNNNN (HR: Customer-Specific Authorization Check) in the non context solution.

In addition to the three switches above there is a fourth switch used by the context solution. This last switch – AUTSW – DFCON – HR: Default Position (Context) – is analogous to ORGPD switch used in normal structural authorization as it controls access to non integrated personnel numbers (persons who are on a default position and as a result are not mapped to the organizational structure). The fields for the individual authorization objects P_ORGINCON and P_ORGXXCON are given below. P_ORGINCON Authorization Field INFTY SUBTY AUTHC PERSA PERSG PERSK VDSK 1 PROFL

Long Text Info type Subtype Authorization Level Personnel Area Employee Group Employee Subgroup Organizational Key Authorization Profile

P_ORGXXCON Authorization Field INFTY SUBTY AUTHC SACHA SACHP SACHZ SBMOD PROFL

Long Text Info type Subtype Authorization Level Payroll Administrator Master Data Administrator Time Recording Administrator Administrator Group Authorization Profile

You will notice that new authorization objects differ from the corresponding old objects in a single respect. Both of these have the new field PROFL (Authorization Profile). The PROFL field is meant to store the value of the PD profile for which each general authorization is valid. In other words, the PROFL field serves to link the general authorization with the corresponding structural authorization. Context problems, like the one we discussed about the Training manager, can now be easily solved by maintaining the correct PD profile on the role. The context solution is truly a welcome addition to the other security features of SAP HCM as it allows us to solve scenarios which couldn’t be solved with the means at our disposal till now. However it comes at the cost of increased maintenance effort as now in addition the PD profiles assigned to the user, we need to maintain the correct PD profiles for the role as well. Also, we should remember that the context solution only addresses the context problems for accessing people (PA master data). There is still no context solution for PD data secured through PLOG.

DFCON & ORGPD – Auth Switches My apologies if the title of the post makes no sense. Probably that’s because of the relatively niche nature of the topic. However, in the last few months, I have come across a few installations where people have run into issues due to security configuration around access to non integrated positions (the so called default position) and thought a new post might be in order. Both DFCON and ORGPD are authorization switches (refer to my post on Authorization Switches for some background) which control how your SAP security system handles access to employees with non integrated positions (these are the people who exist in the HR component but are not linked to any positions in the Org Mgmt Structure). Setting the proper values for these switches is a one time activity when configuring Structural Authorizations in your SAP system. Since structural authorizations use the OM structure to control access to employees, it’s a valid question “How do you want to control access to EEs/Pernrs which are not part of the OM structure?” These authorization switches help answer the question. The screen below shows a view from transaction OOAC using the switches.

OOAC – DFCON and ORGPD Switches Note that both these switches control access to non integrated persons but shouldn’t be used at the same time. Use ORGPD switch when using plain vanilla structural authorizations and DFCON when using the context solution. There is also a slight difference in the meaning of the different values possible. Access to these non integrated persons can be controlled by the value of the Org Unit stored in info type 0001 (org Assignment). However if there is no org unit also maintained in the info type, the system provides the option of giving/ denying access to all these persons. These two different cases are highlighted in the below screenshots from IT 0001.

Org Assignment – Default Position with no Org Unit

Org Assignment – Default Position with Org Unit Possible Values for ORGPD/ DFCON and their meaning 1 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. If no values are maintained in IT 0001, deny authorization to the person. 2 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Deny access to all these persons. 3 = Check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. If no values are maintained in IT 0001, give authorization to the person.

4 = Do not check access to Org Unit maintained in IT 0001 for persons not linked to the OM structure. Give access to all these persons. 0 (ORGPD) = Structural Authorizations are switched off. So the check for pernrs not present in OM doesn’t arise. 0(DFCON) = same behavior as maintaining 1 for DFCON with one important difference. Context solution is activated by switching on one or more of the INCON, XXCON, NNCON switches which in turn activates authority check for the P_ORGINCON, P_ORGXXCON or the custom Z object. I would explain with an example, For DFCON = 1, INCON = 1 you would need an authorization with P_ORGINCON with all values * (PROFL, PERSA, etc) to get access to pernrs with default position and no org unit maintained. For DFCON = 0, INCON = 1 you would need an authorization with P_ORGINCON with PROFL value * to get access to pernrs with default position and no org unit maintained. PERSA need not be *.

Indirect Role Assignment via OM We have come across the Organizational Management (OM) component while talking about SAP HCM. The OM component in SAP is used to map the Organizational Hierarchy of an enterprise by means of HR objects and Relationships between these objects. In this post we will discuss about the possibility of using OM to simplify some of the user-role assignments tasks that need to be handled by a security administrator. Let’s start with a sample org hierarchy created in PPOME transaction as shown below. We start with a root org unit ( HR obj O) “IDES Root” with “IDES India” and “IDES Bangalore” under it. ” IDES India” includes the position (HR obj S) of “Director – India” which is also set as the Line Manager for it. The position is filled by person (HR obj P) “Mister Director”. We make the basic assumption that the SAP access for a user corresponds to his position in the org structure of the enterprise.

PPOME - A Sample Org Hierarchy Consider the access for “Mister Director”. In the case of direct role assignment, any role would be assigned to the user id for “Mister Director” through SU01 or PFCG. Now let’s consider, that “Mister Director” gets promoted to be the CEO of “IDES Root” and a new person comes to take his place. However, since the roles for the India Director were directly assigned to his user id, he will continue to keep his old access even in his new position. Also the new person filling the position of “Director – India” will have to be manually assigned with enough access to enable him to do his job. This same situation will repeat for every transfer, promotion, demotion (and most other org changes in general) that takes place in an enterprise. For an enterprise with more than a few thousand employees, the effort involved in keeping user access in sync with the org hierarchy is substantial. In addition to the monetary cost of the effort, their is a time penalty as users would need to wait for the User Admin team to adjust their security before they can start using SAP. Indirect role assignment comes to the rescue in such situation and if configured correctly can reduce the routine maintenance effort appreciably. In indirect assignment, instead o directly assigning the roles to user id for “Mister Director” we assign the roles to the position “Director India” (The standard SAP configuration allows role assignments to the OM objects – Position, Org Unit, Work Center, Task and can be used depending on business cases) such that any user occupying the position would automatically get the access needed for “Director India”. There are four technical prerequisites for the use of indirect role assignment through Org Mgmt

• •

• •

An active planning version must be defined in the system. Roles/profiles are assigned to the OM objects defined in the active plan. The User and Personnel masters are linked via the IT 0105 (communication) subtype 0001 (system id). This translates to maintaining the SAP user id for a user in IT 0105, 0001 for the user’s personnel number with an active validity date. The HR_ORG_ACTIVE customizing switch is set to YES in the PRGN_CUST table either as the default value or as an entry in the table. The evaluation path US_ACTGR is defined and suitably adjusted in the system. The evaluation path is actually used by SAP to assign roles to the users during user comparison and is the last and the most vital cog in the wheel. The screen-shot below shows the default definition of the evaluation path in OOAW.

OOAW - Definition of US_ACTGR evaluation path Once the above prerequisites are met, we can just go ahead and create indirect role assignments between roles and HR objects. Indirect role assignment through PFCG can be accessed through the “Organization Management” button shown below. The blue lines correspond to indirect role assignments.

PFCG - Indirect Role Assignment through OM Clicking the Org Mgmt button opens the below screen where we can check the existing assignments for the role (both direct and indirect). New role assignments can e created using the highlighted button

PFCG - Indirect Role Assignment through OM 2 Roles can also be assigned through PP01. An indirect role assignment is a relationship between object type AG (Activity Group or Role) and HR objects like positions, org units, etc. Below screen shows a new assignment (relationship B007) between the users’ position and the role object (object type AG)

PP01 - Create B007 relation between S and AG The final step in the process of indirect role assignment is to copy the roles from the HR objects to the users. One of the most common ways to achieve this is to execute the PFUD transaction with the option for HR reconciliation checked. In productive systems, this program is normally scheduled to run everyday at midnight to sync user access with a changing org structure.

PFUD - User Master Reconciliation The critical success factor for indirect role assignment is to understand how correctly your org hierarchy mirrors the roles/ responsibilities of your users. Some of the questions that need to be discussed with your business owners, functional consultants and security team are •

What is the correlation between the roles/responsibilities users and their position in the org structure?

•

Who will be responsible for maintaining the org structure and how frequently?

•

Will users need their old access even if they move to a new position?

•

How will contractors be given access? Contractors are normally not part of the org structure and don’t occupy a position. So do you continue to directly assign roles to contractors or do you link them to the org structure in some way (for example through positions/jobs/tasks)?

•

Are you only concerned about a central ECC system or are there other systems in the landscape (BW, CRM, SRM, APO, etc)? Will the roles assigned in these other systems also be determined by the users’ positions in ECC?

Profile Assignment via OM In the last article we have already looked at the process of indirect role assignment through OM objects. SAP provides another option to achieve indirect assignment of security through the org structure of the enterprise. This method involves indirect assignment of authorization profiles. Though much less common now-a-days as most companies have moved to a system where access is based on roles instead of authorization profiles, there is really nothing preventing its use in even a role based system. The basic concept of indirect assignment remains the same. Instead of creating B007 relationships, between the user’s position and object type AG, we maintain info type 1016 for the position with the profile names. An example screen-shot is given below. Through configuration, it’s also possible to maintain IT 1016 for other org objects like jobs, org units, tasks, etc.

PP01 - Create IT 1016 (Standard Profiles)

To copy the profiles from HR objects to users, the report RHPROFL0 is used with the options shown below. This report can also be scheduled to run in the background everyday at midnight to sync up user access (both PD profiles and general authorization profiles) with a changing org structure.

RHPROFL0 - Copy IT 1016-1017 values to users

HR Processes and Forms A growing tendency of HR departments around the world has been to decentralize the maintenance of HR data. So instead of one major services department handling the data for the entire organization, we are moving towards a situation where each department has its own HR representative who owns the data for the department’s employees. Even for organizations using a shared services model for HR, the trend is to simplify data entry procedures so that even HR analysts with limited exposure to SAP transactions can get their jobs done efficiently. It was from this need to simplify the user interface for users that SAP came up with the concept of HR processes and forms. The technology is based on Adobe forms and more such more intuitive for a beginning user than SAP transaction. To a large extent, a process maps to a HR action like hire, transfer, retire. Each process in turn is tied to one or more forms which the HR administrator fills up with data. There is provision to do data validation during the submission of the forms to ensure that data entered make sense. Workflows can be configured so that on submission of the forms, the process is routed to one or more level of approvals before the action actually comes into effect. Most processes are exposed to end users through portal links. Before looking at the security aspects of a process, let’s first look at how a process would look like to a HR Administrator. Before an administrator can start a process, he first needs to choose a start object. The start object can be an employee (like in the example below) or an OM object (like a position or org unit).

Select an Employee for a Process After choosing the start object, the administrator would need to select the actual process for the start employee. On selection, an Adobe form opens up where data can be entered. The fields and validations in the form are part of the configuration done by HCM functional consultants.

Start process for an employee Security around HR forms and processes is highly customizable by config settings for each process. SAP has used a new authorization object P_ASRCONT (Authorization for Process Content) to restrict access to processes and forms. Further, configuration in SPRO allows us to use just this object, the standard HR objects for securing personnel data (P_ORGIN, P_ORGXX) or both for securing process contents. The details for this object are given below

Authorizations for processes 1 The activities field value allows HR administrators to read, process, approve or submit forms or processes. The authorization scope value of 1 or 2 allows them to access a process when only they are the target object or for all target objects except their own. This is important as

ideally we wouldn’t want an administrator to give themselves a raise. The Content Type field takes two values, P for Processes and F for Forms. Finally we also have the Content Group field which is similar in use to a table or program authorization group. This free form text field allows us to group access for similar processes/forms to a select group of users. This same text value needs to be maintained in the process groups for each form and process that we would like to secure. This portion of the work is performed by the functional consultant and out of scope of the job of the security administrator.

Specifying a process group for a process In the example given earlier and the one right below, we have used two authorizations. We have used the content group ZEMPLOYEE to group processes that an employee should be able to start for his own pernr and this is maintained as part of the Employee Self Service access. The HR Administrator access on the other hand (given below) allows them to start any HR processes. The HR administrator however are prevented from starting these processes for their own pernrs

Authorizations for processes 2