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 organisation, 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 organisations 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 as 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, lets first look at how a process would look like to a HR Administrator. Continue reading “HR Processes and Forms”
My apologies if the title of the post make 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 an one time activity when configuring Structural Authorizations in your SAP system. Since structural authorizations use the OM structure to control access to employees, its 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.
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 infotype 0001 (org Assignment). However if there is no org unit also maintained in the infotype, 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.
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 *.
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 infotype 1016 for the position with the profile names. An example screen-shot is given below. Through configuration, its also possible to maintain IT 1016 for other org objects like jobs, org units, tasks, etc.
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.
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.
Lets start with an 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.
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 lets consider, that “Mister Director” get 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.
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.
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
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)
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 way 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.
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?
In the modern enterprises, its 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 infotypes (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 infotypes and a second one with infotypes 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 infotypes 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. Its 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.
|Authorization Field||Long Text|
|VDSK 1||Organizational Key|
|Authorization Field||Long Text|
|SACHP||Master Data Administrator|
|SACHZ||Time Recording Administrator|
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 increaded 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.
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 evluation of the entire object list for an 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 a 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 user 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 updation 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.
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.
- PD profiles can also be assigned to OM objects like positions through infotype 1017 (through transactions like PP01/PP03).
Also note that an 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.
- 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 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.
The definition of PD profiles is stored in the T77PR table. Lets have a look at the definition of the standard PD profile for “MANAGER”
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 hierarchial 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.
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, 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, its 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 authorizations.
- While using structural authorizations to restrict access, we need to ensure to add access to the corresponding objects are also added to the user’s roles through PLOG.
Since we have already extensively discussed, security roles and their assignment we will use the next few articles to describe PD profiles and their assignment.
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.
As an example we select the evaluation path PERSON and see how its defined
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 reportees 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.
The report output shows the evaluated objects.
In the next article, we explore the use of evaluation paths in defining structural authorizations or PD profiles