02-15-2012 11:43 AM
Hello Gurus,
We have implemented Structural authorizations for only MSS users and we have switched off P_ORGIN and activated P_ORGINCON in all systems. We have added P_ORGINCON in all the roles.
Now, the problem is few ESS users are facing issues like users can't maintain info type 0008, 0014. But when checked the user has the required access. Trace showed lot of errors in P_ORGINCON but it checks for personal area as * rather than restricted areas as the users are performing steps based on their respective personal area only.
We are not able to find the exact error if it is related to security or HR team.
Please help me!
Regards,
Salman
02-15-2012 11:58 AM
Hello Salman,
Once you switched off P_ORGIN it will not be used anywhere in the system, so you have to replace it with P_ORGINCON in all roles.
Does your ESS users have access under P_ORGINCON for infotypes (which they are not able to change) with Structural Profile field in P_ORGINCON object maintained as * for ESS users
Regards,
Rakesh
02-15-2012 11:58 AM
Hello Salman,
Once you switched off P_ORGIN it will not be used anywhere in the system, so you have to replace it with P_ORGINCON in all roles.
Does your ESS users have access under P_ORGINCON for infotypes (which they are not able to change) with Structural Profile field in P_ORGINCON object maintained as * for ESS users
Regards,
Rakesh
02-15-2012 12:46 PM
Hi,
Sorry I didn't mentioned that.. Yes, We have inserted P_ORGINCON in all roles with * in profile field and rest copied from P_ORGIN.
Users complaining that they have lost access to maintain in IT0008 and IT0014. When we check in their roles this kind of access is available. So we traced and it produced lot of errors in P_ORGINCON but it is checking for personal area * instead of wild card we have used in the roles and users are doing the correct steps also.
We are not able to figure out why it is behaving like this, as it was not the case with P_ORGIN previously. Also, Structural authorization has been implemented only for MSS users and these users not MSS.
There is another scenario, yesterday one ESS user can't maintain IT0302 and today she can maintain IT0302. How it is possible as no security changes moved to production.
We are not sure, where we are missing now ??
Regards,
Salman
02-15-2012 5:10 PM
Hi Salman,
You are referring the users who are facing problems are ESS users which means that users are trying to update their own details.
The Infotypes which you are referring as problem are sensitive infotypes
IT0008 - Basic Pay
IT0014 - Recurring Payments or Deductions
Check if something was changed for P_PERNR, if there is exclusion for this objects.
If user has maintain access in P_ORGINCON for those infotypes and these are excluded from maintaining in P_PERNR then that tells us that users are not allowed to update their own data for these infotypes which would be normally done.
Regards,
Rakesh
02-15-2012 8:38 PM
Hi,
Firstly, it's not a good practice to design ESS through P_ORGINCON, please use P_PERNR for ESS role.
Secondly, only activating INCON in T77S0 or through OOAC is not enough...INCON is used for context solutioning, so you need to turn on DFCON ( choose value between 1 to 4 based on your requirements) along with INCON. or else need to turn on ORGPD.
However from my previous experiences in many implementations, I have an opinion of my own... You need to turn on ORGPD, INCON and DFCON all three to have Structural auth in place along with context solution.
You can go through the below link for details:
http://help.sap.com/saphelp_erp60_sp/helpdata/en/84/49ba3b3bf00152e10000000a114084/content.htm
http://help.sap.com/saphelp_470/helpdata/en/7f/1a7d3c8015d10ee10000000a11405a/content.htm
02-16-2012 7:28 AM
Thanks for the information!
Sorry for confusion, The users are GUI users like for example payroll provider. This user lost access to READ access to IT0008 and IT0007 but when checked in P_ORGINCON the user has the required access based on the personal area. Also the user is doing the correct steps.
So, I copied the production user to a test user in quality system and was able to successfully READ for IT0008 and IT0007. Checked all the roles are same as production, also the end date for these is valid.
If it is related to any switch then all the users should be impacted but it is not the case here. There are only Few users who has been affected.
Could it be that because of the Org unit being 00000000 ?
Regards,
Salman
02-16-2012 7:40 AM
Likely...please always ensure that Pernrs are assigned to active and valid Positions and Org Unit.
The switches that i was talking about actually deals with such cases where either Position or Org unit are not assigned for a Pernr.
02-22-2012 9:36 PM
It is still a mistry, It works perfectly fine in Q with a copy of production user.
Why the users are getting kicked off when they try to update details and get placed in Org unit 000000 ?