05-07-2009 2:59 PM
Hello,
When trying out PFCG_ORGFIELD_CREATE I ran into a problem:
I want to have an organisational level field for BEGRU in C_STUE_BER (Auth.grp in BOM-header);
there are other auth.objects that also have a field called BEGRU (eg M_MATE_MAR, M_MATE_MAT, F_BKKA_BPG);
we have roles that have several of these objects.
Running PFCG_ORGFIELD_CREATE leads to problems in those roles that have several of the objects with a field BEGRU. In general the values to be assigned to BEGRU in different objects is not the same.
The only solution i can think of is to have per role only one object with field BEGRU.
This would mean a serious redesign of our roles :-(.
Is there another option?
Thanks for your contributions.
John Hermans
05-07-2009 3:08 PM
> The only solution i can think of is to have per role only one object with field BEGRU.
> This would mean a serious redesign of our roles :-(.
>
> Is there another option?
I'm afraid not. That is the biggest issue with org.fields. The value is reflected into each object in the role. So if you have three values for BEGRU in one role and you want to keep them separate, with their own activities, you'll have to split that role into three roles.
05-07-2009 3:08 PM
> The only solution i can think of is to have per role only one object with field BEGRU.
> This would mean a serious redesign of our roles :-(.
>
> Is there another option?
I'm afraid not. That is the biggest issue with org.fields. The value is reflected into each object in the role. So if you have three values for BEGRU in one role and you want to keep them separate, with their own activities, you'll have to split that role into three roles.
05-07-2009 10:13 PM
Another option is to create transactions for the BEGRU and maintain SU24 for them.
But that is not scalable for large BEGRU values and has an implication for menus and number of transactions, in addition to the number of roles...
But BEGRU fields should be used with caution, as the objects which use them are mostly not intended to be scalable (like P_PERNR is scalable....) so Su24 or well documentented "Maintained" authorizations might be an option to switch to.
Cheers,
Julius