auomatic changes to child roles

[Former Member]

Hi

MY requirement is,I made some changes to set of parent roles which already having their corresponding derived roles,now the things is,i want to perform changes automatically to their derived roles instead of doing manually for each parent role.Can any one please help me to solve this issue.

Thanks in advance.

[Former Member]

well, eCATT (and i'm only saying this for Alex Ayers, otherwise i would never mention that darned tool) or LSMW are your friends here.

explore both of them. since you will use them also in the future, it might be worth investing the time to generate such a tool.

[Former Member]

>

> well, eCATT (and i'm only saying this for Alex Ayers, otherwise i would never mention that darned tool) or LSMW are your friends here.

[Former Member]

This message was moderated.

[Former Member]

Hi

Thanks for your suggestion.i will try this once and i let u know i have any issues.

Thanks

[Former Member]

Hi All

i do not understand the question and the answers???

One of the advantages or derived roles is that all changes to the parent role except org level changes can be distributed to the parent roles automatically!!!!

look in the menu in teh profiel generator (in the proifile view) for the menu distribute to derived roles and generate derived roles (have no system avialable here so can not login to give you the exact menu place and name).

so why should one use CATTS!!!

[Former Member]

Whenever you have master-derived role concept, always change all non organization fields in master role and distribute it to the child roles by "Generate derived roles" in authorization tab. changes will be distributed to all the derived roles automatically. For non org related field if you manually change in child roles that is very risky, because by any mistake somebody distributes the changes in master roles it will overwrite the manual changes in child role. So, it's better to change in master and distribute to child role.

[Former Member]

hi, i quite like your answer. but could u tell me how to manage differences @ the non-org values for each local company? In reality, there is always a need to maintain different values due to different requirements (say doc type, release code, auth group, cost centers).

So if we SHOULD NOT maintain the difference values at child roles, what is your opinion on the BEST method to cater for such requirements. Do share your experience. Thanks.

[Former Member]

Using report PFCG_ORGFIELD_CREATE you can change a non org field to org field. Let say if you have different doc type for different business unit, you can make the field BLART (doc type) as org field by using PFCG_ORGFIELD_CREATE. Then you can easily maintain diff doc type for diff business. Hope this is the strategy what you were looking for.

[Former Member]

Hi,

If you could read up this thread "Re: How to avoid create many roles", advice given is not to promote doc type to org field. In fact, to promote non-org field to an org field really requires a fair bit of analysis on the project as a whole. I wonder how are such situation (doc type, release code, etc) are really managed in real life. Anyone care to share your experience? Thanks.

[Former Member]

I read the forum mentioned by you. It's true that if you just change the doc type field to Org field but it will be difficult to maintain, because doc type is user for different purpose like financial doc, purchase doc etc. In that case you need to break up the roles in a way that you can avoid the situation. But, if you manually change non org field in derived role, there are huge risk. Any time it can be overwritten from master role. Another this is very interesting for me, why do you use different doc type for diff business unit. Let say purchase doc type NB should be used for same purpose regardless of business unit, diff business unit should be differentiated by purchase org or purchase grp not by doctype. If diff business unit use diff doc type for same purpose you should sit with the func consultants and explain them the scenario.