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.
Showing results for 
Search instead for 
Did you mean: 

HR Structural Authorizations

Former Member
0 Kudos

We are planning to use structural authorizations and restrict users to their Organization Units. Here is my question and I'm not sure if this can be done.

1. The client wants to be able to restrict organizations to maintain data (PPOME) by ORG UNITS. (I know how to do this.)

2. The client also wants to be able to display all organizations (PPOSE). (I don't know how to do this because of #1 above.) If you are restricting them to maintain by their ORG UNIT, how can they review all organizations in display mode (PPOSE).

3. Our test showed that you could see display data for Master data (PA) but not for OM data or Organizational data.

I know you could do this by removing their PD profiles (Structural Authorizations) but this not wanted.

Anyone know how to do this?


0 Kudos

hi doug,

by the information provided by you, I would advise getting into contextual authorizations.

through this concept you can quite easily authorize people to display organizational data (for a larger population) through one structural profile and give the same people maintain authorization for the organizational units they are allowed to maintain through another, more restricted structural profile.

please check out this sap-help link to get you started:

Message was edited by:


Former Member
0 Kudos

The client wants HR personnel to be able to only maintain their organization data (PPOME) but be able to display all organizations data (PPOSE).

If you're using Context authorizations checks, can you share what your settings are in ooac, and where is your authorization for display all? Does the display all authorization go into your role (p_origincon) or table oosb? I am just starting to work on Structural Authorizations and the issue I have is:

In order to do this and what I have read I think you need to use context authorization checks with structural authorizations checks.

I have read the material you attached but still need a little help with the setup.

I am confused on where the profile for display all is set up p_orgincon or oosb.


0 Kudos

hi again doug,

the context solution is by principle the integration of structural into 'normal' authorizations.

in order to get your issue working you will basically need two P_ORGINCON objects where the main difference will be the specification of the authorized organizational structure.

this is done through the PROFL field where you specify the structural profile. this structural profile does nothing more than tell us for which part of the org. structure the user is authorized. what the user can do within this org. structure is in turn specified in the P_ORGINCON object itself (ACTVT and INFTY/SUBTY for example)

the structural profile itself is created with OOSP and can only be added into P_ORGINCON once you've actually created it...

please take notice of the fact that persons not assigned to any structural profile are handled as a structural SAP_ALL, meaning that they are by default allowed to see the entire structure. maybe restricted by the values in P_ORGINCON (PERSA etc.)

in your case you should specify for which organizational units an employee is authorized (structural profile) to maintain and combine the structural profile with the P_ORGINCON object.

for the display all you don't have to create a structural profile as you can simply use a * in the PROFL field (meaning no restrictions on org structure).

in OOAC, the main thing is to not leave the ORGIN switch on (1) together with the INCON switch.

in the sap help link above a BAdI is mentioned (HRBAS00_GET_PROFL) for your questions regarding OOSB. when implementing this BAdI, you will not have to maintain this table manually, which can indeed be tiresome when alot of users are involved.

if you have any other concerns, don't hesitate to ask!

Former Member
0 Kudos

I assume I will need two roles with the P_ORGINCON objects, is this right?

Also do I need to implement the BAdl (HRBAS))_GET_PROFL)? What does this do?

0 Kudos

there's no requirement to put the 2 P_ORGINCON objects in different roles. you can put them together in one, it's really up to you.

the BAdI reads the value from the PROFL field in P_ORGINCON and enters it in the T77UA table (OOSB) automatically.

Former Member
0 Kudos

I just ran a test on this and the testor can only see one organization even though I have an asterick * under the second P_ORGINCON object PROFL. I notice these p_orgincon objects seem to pertain only to master data. How can we allow view of other organization data?

Under PPOSE we still only see one organization.

p_orgincon - organization ZOSP20000101 Transportation - this one works, this one is in table t77ua (oosb)

p_orgincon - * read access - this one doesn't work - this is not in table t77ua (oosb)

Any ideas?

Former Member
0 Kudos

I have another question, we have 700 org units, how do we get around creating 700 derived roles. Guess I can't see the big picture here!

0 Kudos

you can also try to create a structural profile allowing to see the entire structure instead of assigning * to the PROFL field. make sure the starting object O is the root node of your structure and I assume you will be able to use the standard evaluation path O-O-S-P. assign this profile to the second P_ORGINCON object.

you can use the derivation principle when you use a function module within your structural profile. in your case the RH_GET_ORG_ASSIGNMENT function will probably do, assuming the user is actually assigned to a position in the org unit he is authorized to maintain.

if the 'normal' authorization is the same for all users in the 700 org units, you can simply create one masterrole and create 700 childroles.