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 infotypes 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 two values corresponding to two different degrees of simplification.
- COARS = 1. The authorization checks for the infotype/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 infotypes 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’ infotypes is often unneccessary.
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.
Are there any disadvantages of using COARS=2 in roles? Are there roles where we should always use value 1 vs using value 2?
Ideally you shouldn’t be using P_ABAP in too many roles at all. And whenever you use P_ABAP in roles, it should be restricted to the particular report name which should be run with simplified security checks. Also both the possible values have their uses but in different situations. I am giving 2 common examples
1 is used for HR administrators who already have access to sensitive HR data. When a person with this level of security accesses the HR data of a large number of users (like for a mass data export for a country during payroll), a P_ABAP value with 1 can shorten the execution times.
2 is used to give non HR users (like helpdesk staff) access to non sensitive HR reports. Since a value of 2 will make the report run without any HR security checks, if you to ensure that the report doesn’t display sensitive data. We use P_ABAP in such cases as otherwise we would have needed to maintain P_ORGIN (ORGXX) authorizations for these users and which would in fact allow them greater access to HR.
The Privacy Officer or Chief Information Officer can help you in the determination of sensitivity of different data and the people who might access them. For any questions on access to HR data, these people should always be consulted as violations might be against corporate policies or prevalent laws.
Thanks for the great SAP posts here. I have a question or two about context authorization. My client already has SAP HR implemented with much needed clean up as no best practices were adopted.
Currently their context authorization is not set up but they have set up lots of existing structural profiles without any documentation to guide me. My questions are:
1. How do I sort out which structural profiles to use?
How do I assign say a Time Admin in a specific PERSA to the correct profile. I mean how do I decide which of the matched profiles to use and how do I test. They have given me no data and no documentation.
2.If they have assigned several objects manually in the role, how do I decide which t-codes to assign to p_orgincon in SU24?
3. I assign the user to the structure in OOSB and also add the same profile in p_orgincon.
please help me to be able to determine the correct steps to get this to work.
Atta
Hi Atta,
Are your clients using structural security at all? If not you can just ignore the existing profiles and start building profiles from scratch. If you build from scratch you will probably have to do more work up front but will have a cleaner design. Whatever the case, I would suggest that keep the number of PD profiles to the minimum. Use PD profiles for security only when general security can not meet the requirements.
If your client already uses structural security but now are moving to context solution, you can get an idea about the functionality of the PD profiles from looking at OOSB and checking the roles assigned to users who are also restricted by PD profiles.
Another way to find the objects returned by a PD profile is to check the PD profile definition in OOSP and click the I (information) button adjacent to each profile entry.
Once you have the PD profiles that are applicable for each HR role, you would need to add these profile values to P_ORGINCON (or P_ORGXXCON) in the PROFL field. The other field values for these objects would be the same as the corresponding P_ORGIN (or P_ORGXX) values.
Hope this helps you in getting closer to the answer 🙂
Regards,
Aninda
Hi Aninda,
Thanks for your excellent work. I have managed to sort out a few issues with my current client. I have implemented CONTEXT for HR. I have a few requests from my client and I can’t seem to find a solution although from a CONTEXT point of view my role design should have worked to restrict access to IT0008 such that HR employees should be able to see their own IT008 records. 2. They should be able to R/W/E IT0008 for all non HR associates. 3) HR should be able to R/W/E.. data for all associates in the organization including HR (that is all infotypes excerpt IT008 for HR associates.)
My client doesnt want to create a PERSA for HR nor designate ORG KEY to HR. They do not want to assign two user ID(S) to HR associates.
My solution:
1)Create a PD profile with the HR org unit as the start object.
2)Assign both ALL and the new HR PD profile to HR associates with the exclusion button checked for the HR PD profile in OOSB (T77UA)
3)Assign the ORGANIZATION PD profile in the role that allows the user to access his/her IT0008 records but excludes IT0008 as a value in AUTHC (0000-0007, 0009-09999)
4) The role that gets the ALL PD profile also gets IT0008 as a feild value. P_PERNR= R,IT0008, I, *.
PA, EG, ESG ORG KEY same for both roles
RESULTS:
1. User can access his/her IT0008 records
2. User can access all records of all associates outside of the HR department
3. USER CANNOT ACCESS ANY RECORDS OF OTHER HR ASSOCIATES
How do I solve this? will an in-house FUNCTION MODULE work to exclude the HR during runtime for IT008..Please help.
Thank you
Atta
Hi Atta,
I will take a shot at this but can not guarantee if the solution will work. For simplicity’s sake I will assume that you are currently using P_ORGINCON and P_PERNR for securing PA data.
Create a copy of the ORGANIZATION PD profile say XXX and also assign this to the HR folks in T77UA. In the role giving PA access following authorizations will be needed.
P_ORGINCON
INFTY 0000 – 0999
AUTHC R, W, E
PROFL ALL, ORGANIZATION
P_ORGINCON
INFTY 0000-0007, 0009-0999
AUTHC R, W, E
PROFL XXX
P_PERNR
INFTY 0008
AUTHC R
SIGN I
Other than this have you given thought to the fact that who actually updates IT 0008 for the HR Team? Your requirement can also probably be met by using P_ORGXXCON by using separate HR Administrator groups for the HR folks and the rest of the employees. Let me know how it goes. Thanks for the question. First time I have come across this requirement but does sound like something that a lot of clients can ask for.
Regards,
Aninda
P/S The ORGANIZATION PD profile is a function module RH_GET_ORG ASSIGNMENT
Hi Aninda,
I have requested the ABAPERS to build an in-house FM that skips the HR org unit. I will see how a combination of this FM allow restriction for IT0008 to HR associates while granting access to all other records for other associates including HR. I will post my findings once I succeed.
2. Today, a defect was raised while accessing retiree records with CONTEXTUAL authorization.. As I understand it, all feild values will have to pass authorization checks in order to grant access. If the PERNR (RETIREE’S) is accessed, how will P_ORGINCON get arround it if PROFL check does not find the “PERSON”(PERNR)in the ORG structure? Retirees no more have any position assignments in the ORG structure.
3.Recently, I requested that the DEV client be copied so that I can implement the CONTEXT solution. When a user executes SA38 and runs a report for a PERNR, it seems to work but the system directs it’s output to a printer. Once print preview is pushed, it starts generating the report but it terminates halfway through the report without generating an error message at the the status line.
When I excute SU53, the authorization check is asking for P_ORGIN?? STRANGE!! OOAC switches are set as ff: ADAYS=15, DFCON=2, INCON=1, ORGDP=1, PERNR=1. ORGIN=0 and eveything else is set at “0”. Do you think the printer settings could be the culprit? I have already asked BASIS to reset but the error still prevails. Please help.
Thank you.
Hi Atta,
Good luck with your function module though I am a bit skeptical about the robustness of the solution going into the future. Org units change in the course of time and a FM hard-coded to skip a particular org might create more difficulties in the future. But as long as the business owners are onboard, you shouldn’t have to worry.
After retiring, the erstwhile employees will be part of on the so called default position (9999……). The SAP systems access to these is controlled to the different values of the DFCON switch. Check which one works for you. There is a post in this blog which specifically talks about the DFCON switch.
Finally, the last error has anything to do with authorization. There is a user parameter (SAU) for writing to spool which might be at fault here.
Best of luck!
Aninda
Hi ANINDA,
Thanks for your great help. After changing DFCON=2 to DFCON=4, the user was able to update retiree health plans IT0167. The client had requeted a DENY BY DEFAULT ACCESS to default 99999999 positions.
I have found out that the errreport runs okay when running SA38 FLEX-ENROLL for new hires but when “ANNUAL” is selected the print preview terminates without any error message.
Thanks.
Hello Aninda,
To increase the performance of Payroll run of large enterprise, we included P_ABAP object in the role with COARS:1 and REPID:HINCALC0. Due to audit compliance, we are not allowed to use COARS: 2.
While running the trace, P_ABAP hasn’t been checked( We don’t see the object in trace report) and the performance hasn’t been improved a lot.
Payroll admin has too many roles and in the concept we have 300 Personnel areas.
Any suggestion to increase the performance?
Thanks