ECC Authorisations

[Former Member]

I am currently working on a rebuild of existing roles in ECC. Our current landscape has one controlling area but 10 entities for which users need varying access i.e. some need access to one or two entities, some need access to all. I'd like to to build generic roles and create area-control or entity based roles to assign in conjunction with the generic role so that the user can only access Company codes, Sales Orgs etc as per the Org Level authorisations within the 'area-control' role assigned to their profile. What's the best way to achieve this?

I'd be very grateful for any help!

Jane

[Former Member]

Hi Jane,

I am not sure if i am getting your question right but i think you can either use "derived roles" or "enabler roles" method. Both have their own advantages and dis advantages. You can choose between them depending on which ever feels fit for your requirement.

[Former Member]

What's the best way to achieve this?

Your approach in itself is known as "value roles" or "enabler roles" and cannot be associated in any way with the word "best".

It is the worst approach possible, although at first it seems tempting and PowerPoint programmers can even give you the impression that it works.

Rather avoid it, build a proper role for each entity without any dependencies and activate menu redundancy compression to show it only once to the user when they log on. If you can logigically group the entities and there is no reason to create individual roles for them, then do that to further reduce the number of roles.

There are also several other threads here discussing the merits of such approaches. They are not favourable either...

Cheers,

Julius

[Former Member]

Hi,

I strongly agree with what Julius said. The concept of Enabler role ( the one you are getting into at the end of the day) is a very poor idea of design and have lots of demerits.

You can feel the pain of an enabler role concept long after it has been implemented and specially when you are upgrading a system having such design. Ask someone who has upgraded such system and definitely that person couldn't have slept for nights.

I believe SAP is not stupid and we should use what the software has provided us. The concept of derived roles will be much more efficient and will make an effective design for future.

I have said this before in various threads...just to reiterate..."In the dictionary of SAP, there is nothing called Enabler Roles". Roles are only of two categories...Single and Composite and within Single Role, it's subdivided into two types..Master and Derived....THAT'S IT!!!

Thanks,

Deb

[Former Member]

I believe SAP is not stupid and we should use what the software has provided us. 

Those are real strong views and words. Dont you have any custom built transactions or programs?

> I have said this before in various threads...just to reiterate..."In the dictionary of SAP, there is nothing called Enabler Roles". Roles are only of two categories...Single and Composite and within Single Role, it's subdivided into two types..Master and Derived....THAT'S IT!!!
Thanks,
Deb

When a project is planned it needs more thought than a rudimentary discussion on 'should it be an enabler concept, or should it be master/derived or composites'.

what you mention on the effort during Upgrades or in understanding the origianl design is quite true. If we stick to the idea of having ONLY Master & Derived roles, i would like to know your view on how to implement restrictions on Customer Authorization groups , Vendor Authorization groups, Cost Centre restrictions.......?