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”
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
This article about organizational management is meant to be a launchpad to our discussion on structural authorizations– an unique and indispensable part of HR security. We ave already have had a brief idea on Org Mgmt or OM when talking about the PLOG authorization object. Lets 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
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.
A typical org structure when represented by the same data model might look something like the graphic (transaction PPOC) shown below
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)
while the relationship between two objects is stored in the IT 1001 (table HRP1001).
Finally, the org structure composed through these two tables is displayed through the PPOSE transaction as shown below