Non-org fields in derived child roles: Any work-arounds not to adjust them?

[Former Member]

Dear gurus,

In a moment of weakness, I decided to build 80 derived roles for VA01 and VF01 where the only difference between them is to be the Sales Organization. It was even possible to push all other org.fields from the parent role and the users access the role via webservice calls in a portal so the front end will always be the same for all of them, so... I took the bait...

For a brief moment the roles were truely beatiful with all standard authorizations only.

The problem is however that I overlooked a little devil in the detail: The functional folks have created Sales Document Types (V_VBAK_AAT) and Billing Document Types (V_VBRK_FKA) for each sales organization, and these fields are not Org.Levels and they have now given me the list of values they want in the child roles.. :-((((

Other Sales and Billing document types are "normal" ones and used independently of the sales organization and liberally so, i.e. promoting it to an Org.Level is not an option. There are almost 1000 of them and no usable naming convention to range with.

I fear that the only option is to dump the derivation of the roles and start over from a template role to copy from, but thought there might be some trick which I am not aware of.

Anyone been confronted by this and found a way around it?

Cheers,

Julius

[jurjen_heeck]

Seeing that this is in creation and SD is there a chance the funcies can 'steer' which sales document types may be created for each sales org so you won't need to authorize on this?

Just my 2ct

Jurjen

[Former Member]

That was what the first attempt was by adjusting a * for them from the parent role and letting the front-end take care of the "steering", but some users have SAPGui access to VA01 & Co. as well, so the requirement was to restrict it via the document types and not rely on the S_SERVICE's being the only entry point.

Some users have Webgui transactions as well, and the ok-code cannot be hidden reliably.

Unfortunately this requirement became known to me after I had built the roles.. :-((

Cheers,

Julius

[jurjen_heeck]

> Unfortunately this requirement became known to me after I had built the roles.. :-((

Which makes the fact that new requirements may cause a redisign an extra sad one. Been there, done that. As far as steering is concerned I was thinking in the line of user exits in the abap behind said transactions, not at front-end level. Security should work irrespective of the kind of user interface people use.

[Former Member]

> Which makes the fact that new requirements may cause a redisign an extra sad one.

Yep, this is an omnipresent risk with derived roles and I warned them, but only mildly as I thought it would work. I was hoping to at least get out of the building before the lights started to dimm...

Another option was to have "little" value roles for the two objects and derive an inactive authorization from the parent and "wrap" the two into a composite. But that makes 240 roles to maintain.

Creating 80 new single roles from a template and starting over seems to be the best option to me, unless Chuck Norris or McGuyver show up here in the next few minutes.

Thanks for your help and suggestions!

Julius

[Former Member]

Julius,

Document types on sales orders is only one aspect you ended up with, if you had master and derived roles for everything possible and if there are different document types to be used for different countries / contexts - you would go nuts with it.

Imagine you have master/derived roles for customer master maintenance (or) for account postings, users would need authorizations only for their customer authorization groups and in this case a * in the master/derive d role wouldnt work

I had this concept of having a Dummy value in the master role and then derive the roles, so that all roles are consistent. you can then create different roles with only the necessarry object value and assign them in pairs - keeping track initially can be difficult, but with practice it can be done quite efficiently.

but, i remember being ripped on the forum for this approach.

The plan i have works for me and because the transactions and object combinatios dont change, i dont have un-necessary reporting on SOD issues from the auditors. I sold the idea to them and it is well received and working fine

[Former Member]

Julius,

don't let yourself be talked into something fancy (sorry Shekar, I love your posts - despite the fact that I mostly disagree with you ).

80 single roles it is: every single one with it's own set of activities, organisational levels, billing and sales document types. Think a bit more into the futuer - they might come up with trying payment cards - but (as a pilot) in one sales organisation only ... that's where the derived roles concept would go bust anyway.

Derived roles in SD usually make no sense, when your funkies are talking about different sales organisations - they only would chose that organisational level for their processes, if they wanted major differences between those processes be separated on a high level. If these sales organisations represent several countries: you can bet that process can never be the same (legal requirements/country versions with their on J1* t-codes) etc. So, if the funkies talk sales organisations - most likely you talk single roles (composite at the most). sadly enough, SD knows only that one org-level (in MM you have at least the purchasing group).

[Former Member]

> Julius,
> 
> don't let yourself be talked into something fancy (sorry Shekar, I love your posts - despite the fact that I mostly disagree with you ).

Well, i never expected someone would agree

> Derived roles in SD usually make no sense, when your funkies are talking about different sales organisations - they only would chose that organisational level for their processes, if they wanted major differences between those processes be separated on a high level. If these sales organisations represent several countries: you can bet that process can never be the same (legal requirements/country versions with their on J1* t-codes) etc. So, if the funkies talk sales organisations - most likely you talk single roles (composite at the most). sadly enough, SD knows only that one org-level (in MM you have at least the purchasing group).

It is not about SD or MM or FICO......the derived roles concept would inevitably end up in this state when you have different values to be maintained for Non-Organizational fields. So there is a default 'chink in the armour" and i got trapped by that and am living with it

• For a matter of fact, Purchasing group in MM is small fry, it does pop in the PFCG entries of organization values but i dont think it has any legal authenticity like a sales organization or a purchasing organization - what a user can/cannot procure can be discussed and users can be added to purchasing groups without major hassles - the "real organization values would be the company code, purchasing organization, sales organization..........." - correct me if i am wrong (i know you will ) Purchasing groups are not organizationally dependent

[Former Member]

>

> 
> *** For a matter of fact, Purchasing group in MM is small fry, it does pop in the PFCG entries of organization values but i dont think it has any legal authenticity like a sales organization or a purchasing organization - what a user can/cannot procure can be discussed and users can be added to purchasing groups without major hassles - the "real organization values would be the company code, purchasing organization, sales organization..........." - correct me if i am wrong (i know you will ) Purchasing groups are not organizationally dependent

They are not hierachically dependent, I give you that - and that is exactly the reason why you can so wonderfully combine them with purchasing organisation, company code - only all fullfilled will grant you access ...

beat that in SD

[Former Member]

> 80 single roles it is: every single one with it's own set of activities, organisational levels, billing and sales document types.

I did also consider the options described by Shekar but when the number of roles "took off" I backed off. Having 80 is bad enough.

If it were that the sales org and the document type were the only fields and each used only in one object, then I might (in defense of Shekar) have considered building just one single functional role for the tool assigned to everyone and then 80 little "value roles" with just the 2 objects in it manually, but then I read:

> Think a bit more into the futuer - they might come up with trying payment cards - but (as a pilot) in one sales organisation only ... that's where the derived roles concept would go bust anyway.

Sold to the lady with the infra-red binoculars...

Cheers,

Julius

ps: I will close the thread when the forum software is behaving normally again.

[Former Member]

>

> Creating 80 new single roles from a template and starting over seems to be the best option to me, unless Chuck Norris or McGuyver show up here in the next few minutes. 
> 
> Thanks for your help and suggestions!
> 
> Julius

Not much to add but a bit more support for that conclusion. I wonder if this is a real consensus or an IPCC definition of consensus. hmm.

[Former Member]

Thanks Alex,

I reserved some time to build them again and some "disc-space" to remember for next time why I had to.

IPCC

IPCC Intergovernmental Panel on Climate Change (WMO) 
IPCC Independent Police Complaints Commission (UK) 
IPCC Integrated Pollution Prevention and Control 
IPCC Infinity Property and Casualty Corporation (Birmingham, AL) 
IPCC Irish Peatland Conservation Council 
IPCC International Professional Communication Conference (IEEE) 
IPCC International Packet Communications Consortium 
IPCC Internet Protocol Contact Center 
IPCC Iraqi Property Claims Commission (Iraq) 
IPCC International Pigment Cell Conference 
IPCC International Publishers Copyright Council 
IPCC Investment Planning Counsel of Canada 
IPCC International Pentecostal Church of Christ 
IPCC ionic polymer conductor composites 
IPCC Instituo Português de Cartografia e Cadastro (Portugal) 
IPCC Information Processing Center - Columbus 
IPCC Information Processing Command and Control 
IPCC Incorrect Product Code Codeword 
IPCC Interprocess Communication and Control

I hope for my sake that there is one which google doesn't know about yet..

Any clues?

Cheers,

Julius

[Former Member]

Lol, the first record was the one I was referring to

[Former Member]

Hi Julius,

Maybe I'm missing something in this thread, but what about coming back to letting the functional folks take care of that? I'm a bit surprised that this is supposed to be controlled via authorizations, what about the standard customizing, i.e. IMG and then path (taken from ECC 6.0):

Sales and Distribution u2192 Sales u2192 Sales Documents u2192 Sales Document Header u2192 Assign Sales Area to Sales Document Types

Per customizing help:

In this menu option, you allocate the allowed order types to each sales area group. You do not need to make any entries at all if all the sales order types are allowed for each of your sales areas.

I.e. no entries mean that all document types are allowed for all sales areas, but as soon as you start entering them, they are restricted to the listed sales areas. I'd kind of expect that this should already be in place if they defined sales area specific sales order types.

Now I'm not sure about billing (and too lazy at the moment to check), but even if a similar control doesn't exist, it might work if your billing documents are usually created with reference. Then copy control should take care of ensuring that only the right document types can be picked. However, your SD consultants should be able to give you the details...

Cheers, harald

[Former Member]

Thanks for the idea Harald.

We had already pushed a * for the sales document type in the first build (what else to derive?) and it worked for VA01, but the webservices were the reason why they set up the document types in the first place. Also we have not thoroughly tested the same for any reporting consequences. Sales orgs are 1:1 with company codes, and BUKRS is generally not enough to restrict on in CO-PA reporting.

I could not find anything comparable for Billing, but will check this with the funkies next week as well.

Even so, I don't think the derived roles design is worth saving.

1) We have to build 80 roles anyway.

2) All authorizations are "standard" in the role (except for the 2 doc. types) so changes can still be done centrally via SU24 where we maintain exact proposals against the webservices. Maintenance effort is already minimized this way as we can use SUPC easily (= 4 mouse-clicks per role to merge a change).

3) It is expandable to the same group of users (this is almost a certainty as it is called from the portal and they are all talking about webservices here...) via the same role. See Mylene's comment about rollouts and flexibility and the number of local fields to maintain which might not be org.levels.

4) The key-user from the business is on our case already about these doc. types because the auditors pick at anything with a * in it and want him explain the reason to them...

I will get back to you on the Billing document type assignment to Sales Org. if I find something.

Cheers,

Julius

[Former Member]

I still find my solution worthwhile (atleast it works me)

[Former Member]

> (atleast it works (for) me)

That is important, but some consideration should also be given for those who follow you and have to maintain the concept after you have moved on. It should work for them as well.

If one of them doesn't read your documentation (or this thread) and expects standard behaviour when adjusting the child roles from the parent, then your concept is easily toasted. That is always a risk.

Still thank you for your interesting and alternate insights into the problem. It makes for a good discussion.

Cheers,

Julius

[Former Member]

> Julius Bussche wrote:

>

> 2) All authorizations are "standard" in the role (except for the 2 doc. types) so changes can still be done centrally via SU24 where we maintain exact proposals against the webservices. Maintenance effort is already minimized this way as we can use SUPC easily (= 4 mouse-clicks per role to merge a change).

With my technical limitation, I think i am not understanding the concept right. If you make changes in SU24 for doument types and default a value for it, doesnt this effect all roles that have the transaction in it? how do you manage that this gets applicable only to users who are defined for web services?

> 3) It is expandable to the same group of users (this is almost a certainty as it is called from the portal and they are all talking about webservices here...) via the same role. See Mylene's comment about rollouts and flexibility and the number of local fields to maintain which might not be org.levels.

If we have 10 transactions in a role and derive it to say 20 entities, and there are differences in the values maintained for non-org values, how do we manage that?

> 4) The key-user from the business is on our case already about these doc. types because the auditors pick at anything with a * in it and want him explain the reason to them...

I have no problems with the auditors with my concept, i havent done anything different to what they expeceted, all users who are order takes have the same derivced role with respect to the transactional content and the org values are different. and for the non-org values they get a 'freebie" which makes no impact on the audit check

> I will get back to you on the Billing document type assignment to Sales Org. if I find something.

> Cheers,

> Julius

I will be keen to hear about it, if you would remember to update it

Edited by: Julius Bussche on Mar 24, 2010 7:07 PM

Formatting of quote tags fixed for you.

[Former Member]

Hi Shekar,

I can maintain everything in SU24 against the webservices used, except the Sales Org. field and the 2 document types I need. If another check value, or object, or even a transaction code might join, I can maintain this against the webservice as well - centrally for all the roles.

The SPRO assignment seems a bit dodgey to me as I discovered 115 transactions in the system for which the SU24 check indicator is set to "No Check" on V_VBAK_VKO, and 37 against V_KONH_VKO. These include some VA* transactions even...

The checks on the billing type are in include LV60AA08. It checks both the sales org and the billing type. The value always came through in the checks from the BAPIs used in the various webservices. I could not find an option to assign billing types to anything orgnaizational ($VKORG).

But anyway, all of this is immaterial because today already 10 of the 80 sales orgs asked about using request and a more limited release authorization for their sales orders...

It's over Shekar. It's all over...

Cheers,

Julius

PS: It took 2 of us about 2 hours to build them from start to finish from a template, and then mass generate the profiles. I added a link to this thread in the longtext description of the roles. Thank you very much for the interesting discussion as always (I read all your posts in detail) although in this case it did not fall in your favour

Edited by: Julius Bussche on Mar 24, 2010 10:12 PM