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 consisitent 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 infotypes. We have already come across PA data in our introductory article on Infotypes. Each infotype 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 infotype, 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 infotypes but the underlying tables are of the form HRPXXXX where XXXX = unique infotype id. (Ex Infotype Object (1000) is stored in table HRP1000. Some PP infotype like IT 1017 have both a corresponding HRP and HRT tables, HRP1017 and HRT1017. This is determined by the structure of the infotypes and deson’t impact security). Security for PP infotypes is controlled by authorization Object PLOG.
The final major type 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.
Now we select the address infotype 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 infotype entry by using the menu path Edit->Maintain text. An infotype with maintained text is indicated by the higlighted text icon in the infotype header as shown below.
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 infotypes (refer to the earlier post on infotypes 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 infotype 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 infotype entry. This text however is not stored in the infotype 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 specially useful when trying to secure obscure t-codes without correct SU24 defaults maintained. Once we understand what kind of data the t-code is accessing, we can predict what all security is needed to execute it.
Hello Aninda
I am a little confused about the difference between P_ORGIN object and P_PERNR. Could be please explain what the difference is? I did understand that P_PERNR is for an employees own data and we can tweak it to not let them change some of their own data but say for example I want to find out which users have access to a particular infotype then do I run the query in the system for P_ORGIN or P_PERNR or both? Thanks in advance
I think you have mentioned the difference between the two yourself. P_ORGIN or P_ORGXX are for general access to HR data. When you report on users having access to HR data, these are the objects that should be investigated. You might want to report separately on P_PERNR to check which infotypes users might(I)/or might not (E) update for their own personnel records.
Hi
I am new to HCM security.I have just started learning from here.Good site for SAP security.I appropriate your efforts.
Just wanted to know Whats the difference between employee and applicant in HR.
Personnel Administration (PA) data consists of attributes for people, whether employees or applicants and is stored in the PA infotypes
From a functional HCM level there might be a lot of difference and I wouldn’t claim to know all of them. In brief, an applicant is basically someone who is looking for employment in your company. Once he is hired he becomes an employee.
The tables storing applicant data are of the form PBXXXX instead of PAXXXX which store employee data. The transactions and authorization objects to restrict applicant data are also different. For ex, to maintain applicant data you would use tcode PB30 and secure it via P_APPL object. Typically security requirements around applicant data is less stringent than for employees.
Dear Aninda,
Actually i have to provide table level security only for all those hr tables which have restricted data and should only be view by responsible persons wihich hve reqiuerd authorization.
So As per till now if i restricted all tables started with PA*,PB*,HRP*, HRP*,PCLn will this cover my requirement?
Reagrds,
Anuj jain
Hi Anuj,
I think you are good with identifying the tables. We do have a few other tables which store HR configuration data but I don’t believe these will need to be separately secured because these are not storing employee data. The key point to rememeber about privacy is to securre access to PII (personally identifiable information).
Regards,
Aninda
Hi
when we add pa30/40 to a role p_pclx is auto populated with pc. Tx values. Can you pls let me know at what point will they be checked
i tried to trace by updating IT 0001 data but pclx was not checked
It will be great if you can give me few infotypes for which it is checked
To start with, i must say, it’s an awesome website put up by you.
Now the questions –
1. Difference between P_ORGIN and P_ORGXX, why and how P_ORGXX used to restrict access?
I have read the basic difference between the objects, the fields are different, but what I do not understand is the application of this object? The fields related to various administrators, what do they signify? DO we fill Pernr/User ID of admin. there?
**A user has authorization for data for only those time intervals when user is assigned to P_ORGXX and/or P_APPL objects.
Is it the same validity range which we enter while assigning a profile/role?
2. ** In document HR940 it was mentioned that P_ORGXX and P_APPL has time dependent specifications.
What does Specifications mean here, is it the fields of the HR auth. objects?
i’m bit curious about role of Security Admin. wrt Time Logic!
3. Relation of default position (99999..) with field ORGPD or DFCON?
The fields available in P_ORGXX are different from those available in P_ORGIN. So basically its comes down to which one of these two helps you to map your client requirements.
For time logic and period of responsiblity, I will refer you to SAP documentation. I can not better explain the various cases than what the documentation already says.
There is another post on this blog which talks at length on ORGPD and DFCON
Hi Aninda, I’m very pleased to read the content of this website. Wasn’t aware of the existence of this site until it came up in one of my searches. Very insightful information. I have a question and ‘m looking for some help/inputs. Do you happen to know what HR table contains Time & Expense data. Is it available in HR Cluster Tables (PCL1 & PCL2 – Relation ID: TE / TS)? If yes, how do you access data from these HR Cluster Tables. Regards, Janantik.
Hi Janantik,
The HR Clusters store payroll and time evaluation results amonng other things. I am not sure about the expenses data. SAP provides standard reports to read data from the clusters depending on which of the clusters are being read. Directly reading the cluster tables would not help too much.
Thanks,
Aninda
+1 🙂
Thanks for the lengthy comments Madam Subbulakshmi!
Subbulakshmi is funny :)!
What is the full meaning of hr triggers in simply method?
This is a topic within GRC – HR triggers allows us to take specific actions within GRC based on HR actions.