Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

HR issues after Structural authorization implementation

former_member275658
Contributor
0 Kudos

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

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

7 REPLIES 7

Former Member
0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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

0 Kudos

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.

0 Kudos

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 ?