Skip to Content
author's profile photo Former Member
Former Member

HR Structural Authorizations

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?

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

5 Answers

  • Posted on Nov 19, 2007 at 10:36 AM

    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:

    http://help.sap.com/saphelp_47x200/helpdata/en/7f/1a7d3c8015d10ee10000000a11405a/frameset.htm

    Message was edited by:

    Dimitri

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 19, 2007 at 04:10 PM

    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.

    Thanks!

    Add a comment
    10|10000 characters needed characters exceeded

    • 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!

  • author's profile photo Former Member
    Former Member
    Posted on Nov 20, 2007 at 04:33 PM

    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?

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 20, 2007 at 05:29 PM

    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?

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Nov 20, 2007 at 08:02 PM

    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!

    Add a comment
    10|10000 characters needed characters exceeded

    • 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.

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.