Organization level field value cannot be maintained in derived roles.

[Former Member]

Dear Experts,

I have a question.

We have derived roles in which some organization level fields cannot be maintained.

For instance as a deriving procedure:

1. Set * for the org level field BUKRS in a master role.

2. Derive child roles.

3. Set 1234 for the org level object BUKRS in the derived role (child role).

4. Generate the derived role.

The problem is:

In the derived role, we assume that the org field value 1234 should automatically be populated and set for all the relevant org fields, which in our case are BUKRSs. However, as we check the BUKRS object fields, some are set but some are not, left with the asterisk value of *. That means there is no company restriction, and financial documents can be posted for any companies.

Please give me some advice to resolve this issue.

Thanks,

HM

[mvoros]

Hi,

you can maintain individual values for organization level field. In this case the field won't pull pre-defined value. Is it possible that somebody modified those roles?

Cheers

[Former Member]

Yes, we know that we can maintain the field values in each child roles individuallyu2014however, the next time you change the master role (adding a tcode, or whatever), it will overwrite the maintained filed values in child roles.

If we do this, there is no point for us to use the deriving function.

I am taking over the role maintenance tasks, and I cannot tell if my predecessor modified these roles (for example, adding an extra org object manually).

I am still looking for what I can do to the issue.

HM

[mvoros]

Hi,

I did not propose to use this functionality. I just asked if there is a chance that somebody used this functionality before and hence you get that strange behavior.

If tat is your case and you want to find all these cases then you can try to search table AGR_1251 where FIELD is any org. level field and MODIFIED is equal to 'M'.

Cheers

[Former Member]

Dear,

"Set * for the org level field BUKRS in a master role."

You are maintaining the * value in the Master role. Maintaining * values in the master role is not correct. Because all the derived role will get the * values by default and you have restrict further in the derived role.

Another one is. in the Master role the BUKRS object are inserted and maintained manually in each object BUKRS filed?, then in the derived role you cannot control it throguh org level.

Regards,

Shrinivasan. KV

[Former Member]

Thank you both!

I think I am getting a conclusion.

If we find an org restriction necessary, we need to maintain those org fields/values individually in each derived role since the manually added org level fields are treated as normal authorization fields.

Of course, we need to delete the parent-child relationship to avoid the overwriting of the org values in child roles.

>Shrinivasan,

I have a specific question for you.

You pointed out that it is incorrect to set * in the org level fields of the master role. If that is true, are we simply leaving those fields blank in the master role? I thought setting * is a standard practice...

I would really appreciate your advice.

Thanks,

HM

[Former Member]

Hi

Just curious - do you know if the maintained org levels (at object showing in AGR_1251) were intentional or an error?

If intentional then break the link, if accidental then repair the org level to retain the derived link.

Regards

David

[Former Member]

>

> Of course, we need to delete the parent-child relationship to avoid the overwriting of the org values in child roles.
> 

If you do this you then lose the benefits of derived roles. I can't comment on the suitability of them for your solution however it would make sense to just delete the org levels from the parent role. It is not common that the * values are maintained in there. Leaving them out has a number of benefits, an obvious one being that you don't assign the master / parent to users.

[Former Member]

Alex,

Thank you for your comments.

First portion:

Yes, I have realized that, and I agree. However, since we already have master roles and child roles in the system, I just thought it may be a quicker solution to maintain those values individually and get rid of the inheritance.

Second portion:

Now I have two votes. Maybe I should rethink the current setting of * in the master role org fields.

You guys are so helpful. Thanks!

HM

[Bernhard_SAP]

Hello HM,

you can let the '*' as it is.

From the funcitonality it does not matter, if the field is filled in the master role or not. The only difference is at the first adaption of a new child/derived role. With the field empty, you'll get a red status in the chidl role -->forces to maintain the value, with filled

field (for instance with '*') the status is green in the child.

b.rgds, Bernhard

[Former Member]

Hi Bernhard

. The only difference is at the first adaption of a new child/derived role. With the field empty, you'll get a red status in the chidl role -->forces to maintain the value, with filled
field (for instance with '*') the status is green in the child.

Just had a look at this as I couldn't remember - creating a new derived from scratch using a parent with wildcards still brings up the org level box to complete rather than populating. Copying an existing derived retains the original org levels of the donor derived.

I don't like * values in parents for precisely the reason Alex stated - they get assigned before you know it unless you use a different prefix on the role and ensure the admin team are excluded from it.

Just my own personal preference.

Kind regards

David

[Former Member]

>

> Just my own personal preference.

Mine too. It's easy to get in a pickle when you have user admin's randomly assigning stuff that they have found in SUIM.

[arpan_paik]

Well,

Many things happened. The problem is with master role. The object you are facing the issue, see the company code field is dark blue. Besides that you have one delete button. Just click on that. This way th value to this field will be linked to organization level again. Then derive the master role and distribute it to child role. Now see the child role, it should be fixed.

Regards,

Arpan Paik

[Former Member]

Hi Arpan

In my previous reply I tried to hint:

If intentional then break the link, if accidental then repair the org level to retain the derived link.

AGR_RESET_ORG_LEVELS

Regards

David

[arpan_paik]

This message was moderated.

[arpan_paik]

AGR_RESET_ORG_LEVELS is new to me and thaks for the info...so far I knew the manual only inside role...yeah you were right and the problem is typical when some1 trying to give the authorization only no matter whatever dirty the way is...authorization given by any means problem solved..I am sure these can easily be avoided by other ways....may be system need few more role rather than a trouble for later people....

Regards,

Arpan Paik

[Former Member]

Hi Arpan

I only knew about this program because somebody I worked with was kind enough to share their knowledge and experience.

Manually maintaining org levels at object level even after seeing the big message about 'hey - what are you playing at?!!' does make you wonder about the reasoning behind the entry (if that has actually been confirmed in this thread?).

Cheers

David

[sdipanjan]

This message was moderated.

[Former Member]

Use '@buk@' for $bukrs and '@wrk@' for $werks etc.

This means the master is useless and the child is as well if not maintained, but more importantly you can easily search for them!

This is however only a small consolation to the pain of derived roles in general...

Cheers,

Julius

PS: I removed some "me too" answers and SMS-speak.

Edited by: Julius Bussche on Feb 12, 2011 7:50 PM