Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

In BW 3.5 - Making an Customer Auth Obj and Organizational Item

Former Member
0 Kudos

Hello,

We are running a very old BW 3.5 system.  We have need to take a Customer Created Authorization Object and raise it to an Organizational Level so it can be used in roles that follow a Template-Derived role pattern.  I know how this is done on the ECC side, but I am having issues replicating the process on the BW side.

Does someone have experience with this?  If so, can you tell me the difference between ECC and BW?  I am sure I am missing something on the BW side.

Thank you.

Rich

1 ACCEPTED SOLUTION

Former Member
0 Kudos

You cannot promote Auth Objects to org. levels. You can only promote fields. That then applies to all objects which use the field.

If you also have a custom field and the org.field create program is not available to adjust SU24 and roles, then you can maintain the USORG table with the field as it does not affect anything (except perhaps test roles).

But using derived roles has more disadvantages than just this. I have always regretted it when I became tempted to use them.

Perhaps you can explain where you are using your custom object and what it is controlling access to which does not have a standard object for it and "old concept" reporting field for?

Also: is a release upgrade planned? With the new BW reporting concept you have much more flexibility.

Cheers,

Julius

3 REPLIES 3

Former Member
0 Kudos

You cannot promote Auth Objects to org. levels. You can only promote fields. That then applies to all objects which use the field.

If you also have a custom field and the org.field create program is not available to adjust SU24 and roles, then you can maintain the USORG table with the field as it does not affect anything (except perhaps test roles).

But using derived roles has more disadvantages than just this. I have always regretted it when I became tempted to use them.

Perhaps you can explain where you are using your custom object and what it is controlling access to which does not have a standard object for it and "old concept" reporting field for?

Also: is a release upgrade planned? With the new BW reporting concept you have much more flexibility.

Cheers,

Julius

0 Kudos

Hello Julius,

First, thank you for your reply.  I have returned from Holiday.

In reply to your last question, there is no upgrade planned.  The current plan is to stay with BW 3.5 until a Global Warehouse strategy is adopted.  At that point the data will be migrated and the system will be shutdown. 

The situation is the following:

  • The developer has produced a report that is generic in scope; meaning it pulls data from all sales organizations.
  • The desire is to have users groups by sales organization so the data they have returned is for their sales organization only.  Basically, I see my data and you see your data, but we cannot see the data of the other.
  • What the developer has done is create a new Authorization object: YZZV_SO.  The field for this object is SALESORG.  The desire is to have this field become an Organizational Level so that each group of users can have their sales organization coded in a derived role.  All of the other Authorization Objects are the same across all Sales Organization Groups.  So, the Template/Derived role concept is appropriate. 

I need to research if this field is used elsewhere in other roles.  Any assistance in how to accomplish this would be appreciated.

Happy New Year!

Rich

0 Kudos

Hi Rich,

Based on your latest reply, Please try to create a new customized authorization object by using t code RSSM instead of using SU21.

Here Salesorg field is by default Organizational field.

Steps to create BW Auth objects.

1. Please make sure characteristic value (0salesorg) is authorization relevant or if not make that one as "Authorization Relevant" under Business Explorer tab of RSD1 t code.

Note: if you are using customized sales org by copying standard characteristic value of Salesorg then make sure to maintain that value as Auth Relevant.

2. Go to RSSM and Specify the name of Customized auth object and click on create.

3. Select the sales org char value from right hand side pane and  move it to left hand side.then save the Object.

4. Add the newly created auth object in to required roles then Sales org field by default will be appeared as organizational field from there you can derive the as per your requirement.

I hope this will helps to your requirement.

Thanks,

Siva