Role generation

[Former Member]

Hi experts,

We are doing global SAP rollout. I have some requirement to create Roles for all regional users.Kindly help me on it.

Is't advicable to create 1 Composite Role & assign all Single Roles or is't always better to create 1 Single Role & assign all necessary T-codes to it?

I can give you one example. I need to create a Planner Roles, these Planners can be 1 in Korea, one in Japan & 1 in China.

They have their own Company code, Plant specific data.

Composite profile: MPS-Planner

Single profiles (allocated to MPS-Planner):

- process planning (=create and maintain projects)

- process MRP

- check and release MRP-results

- process MRP-master data

Transaction codes (allocated to Process Planning);

CJ20N u2013 Create Projects

CN33 u2013 Bill of Material Transfer

u2026u2026 - Maintain Projects

MD04 u2013 Stck Requirements List

Etc.

Transaction codes (allocated Process MRP);

MD01 u2013 Create MRP

MD02 u2013 Create MRP (in batch)

MD04 u2013 Stck Requirements List

Etc

Please advice the easy way to maintain authorization to all regional users.

Thanks,

Pri

[Former Member]

answered

[Former Member]

HI Pri,

Well, there can be another way to accomplish the same, which is a bit convnient and scalable to a particular country too. This can be accomplished by using two roles for each task, such as planner. These two roles would be:

1. Transaction Role (T Role): having transactions only. this would be common to all locations.

2. Org Role : Having only org level objects. This would be separate for each location based on the org level value.

Thus you can have a composite for each location, having two of the obove roles each. An edge of this method over the Derived is that if in future you come accross any object that is relevant to any particular location and other locations not wanting the same , you can easily give it to that particular location in the org role and carry on.

This is particularly because going futher in the support mode you generally have issues between locations, each of which may not reccommend a certain object to be added in the role. So mplementing this way makes it more scalable and easy to maintain. Otherwise for every such request which is not approved by one of the locations you end up creating new roles for each location.

NOTE: I would suggest to use the derived option only in case where you are 100% sure that the same changes in the role would be required for all the locations everytime. Oterwisw it becomes a real pain to handle.

Regards,

Hersh.

[Former Member]

Hi Hersh,

I think it is fair to warn Pri of the drawbacks of using that particular approach too....from my experience of auditing this method in the past, it usually results in a mess unless very carefully controlled.

There is discussion on the topic here:

[sreekanth_sunkara]

Hi,

1. first create roles with some names and add the transactions and fix all the open autorizations.

2. then create child roles (derive from parent role) and maintain the Organizational Values according to Organization. in that way all can get the same access, but limited to their organization

thanks,

Sree

[diwheeler]

Hiya Pri,

this is something that might be referred to in your security design document. If you have nothing in there, then you have options - and it all really depends on how separate each access will be.

If you use composite roles to manage your single roles, your benefit is that you have an easier time of assigning access and managing the provisioning process. You also can define what your menus etc will look like for your users.

To create the composite roles, you will still need to create single roles to go into it, and I guess this is probably where your question is more relevant. Well, as with most things in SAP, there are options.

1 - create individual single roles for each country that are copies of each other. The most basic method, but lots of work, and if you do copies of each role, you can get them out of sync.

2 - create template roles and use them to create derived roles. Transaction maintenance is made in the template, and the derived roles references the template. This means each access is the same across areas, but you populate the authorisations & org values with regional specific information. Less work on this option.

3 - You can create roles that get sneakier - so single roles that have menus only, and then individual roles with no menu and multiple manually entered profiles for each area, so all users of a process would receive the menu role, and their appropriate manually entered profile. You should avoid this if you're not sure of what you're doing, and personally I think this can be sloppy later on as it's harder to see what auths are requried for which transaction, and therefore manage conflict.

I've done something similar to what you've described and have used option two quite successfully. The next step is for me to use composite roles to group access according to job requirements.

Good luck,

regards,

Dianne

[Former Member]

Hi Dianne,

Thanks for your reply !

I do not have idea on the Option 2 that you have mentioned below. Neither used them also.

Can you advise for my example, how to create derived roles?

You mean template role is something like a single role with all T-codes added?

I don't have clear idea on how to start with. Appreciate if you can elaborate. Should I need to have individual composite roles for each Planner in each country? And create specific Single roles for them...

Becos when i create single roles & insert all t-codes by default it will assign the authorization obejcts where at that place I have key in the particular company code, plant, movement type, stor.loc etc ...if this composite role/single role is going to be used by 1 specific country planner...

Pls help me !

Thanks,

Pri

[Former Member]

Hi Dianne,

Please suggest how to proceed with option 2,

2 - create template roles and use them to create derived roles. Transaction maintenance is made in the template, and the derived roles references the template. This means each access is the same across areas, but you populate the authorisations & org values with regional specific information. Less work on this option.

Thanks,

Pri

[Former Member]

Pri

May I suggest that if you type SAP Derived Roles into google, you will get a large number of results telling you exactly how to create a derived role