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: 

Reasons not to make Movement Type (BWART) into an ORG level.

Former Member
0 Kudos

I have just been told we have to lock down movement type from certain values. Movement type (BWART) is a field not an org level. It would be easier for us to lock it down if it were an org level instead of a field. That way we could manage it for the top level of the role, and then change it at the object level if needed.

The question is, is there any reason why we should not convert Movement Type (BWART) into an ORG level? Is there anything that can be harmful?

9 REPLIES 9

sreekanth_sunkara
Active Participant
0 Kudos

Hi,

Nothing Harmful you can make it as a Org value. we already did that in our company.

Thanks,

SS

Edited by: sun on Sep 21, 2010 9:14 PM

Former Member
0 Kudos

Your pre-decessor probably used a lot of derived roles and now you have a spagetti?

Promoting BWART to an org. level fits that solution nicely and will give you some relief for a while when you have less maintenance in more roles.

The main buggers to look out for are that org. levels are unique for all same fields of all objects per role ... so you might be tempted (or forced) into building even smaller task roles.

A natural progression is then to club these together into composite roles when user management becomes glazed over with a dull look on their faces because authorization management start creating "delta roles" to assign as singles to users.

Often, SUIM is usefull to look for the smallest role with the least number of other authorizations so that the other roles will work for the user.

Then some manager might ask whether it is possible to make a "shopping cart" available in your portal for requesting roles after the next release upgrade or you want to map all this task-based roles to cross-system Business roles in IDM.... at which ponit you might regret using org. levels to make 2 mouse-clicks easier for a solid role build.

Sorry for the rant, but I would always recommend avoiding derived roles and promoting org. levels. It has never failed me (except in moments of weakness which I always come to regret).

My 2 cents,

Julius

Former Member
0 Kudos

My view on promoting BWART as a Org level are in sync with Julius.

Derived roles or not, if you have a role with only MIGO transaction there are quite a few objects that get populated by default

and quite a few objects in it would need different values for the field BWART, i am sure you wouldnt want to give the same value for the movement types for the objects M_MSEG_BWF (Goods receipt for production orders) and M_MSEG_BWE (Goods receipt for Purchase orders)........in such situations you would be in a real difficulty if you have BWART as a Org Value

(Note to myself: I hope Mylene doesnt read this post and rip me on my MM skills )

0 Kudos

>

> (Note to myself: I hope Mylene doesnt read this post and rip me on my MM skills )

Shekar! Dammit! Am I so fearsome??

I do apologise! Seriously! I vow I will try to improve.

___________

As for the topic at hand: Shekar's totally correct - if you try to make a 'variable' element (variable data, movement data) like BWART (BWART = small bit in various processes, different for each process, changing during process ) into a static element you are praying for trouble. And you will get it. Lots. If you start organising your companie's roles by movement types, you have to be willing to combine said movement type with other organisational elements, say sales organisations, plants, etc ... the more production, warehousing, buying, selling and STO processes you have, the funnier your roles will look.

Pay close attention to Julius' very elaborate and sophisticated sarcasm - it'll help (especially the glazed-over part)! :-D.

0 Kudos

> Shekar's totally correct

This is very dangerous Shekar! I wouldn't move if I were you

0 Kudos

> Shekar! Dammit! Am I so fearsome??

> I do apologise! Seriously! I vow I will try to improve.

>

>

Hi Mylene,

You caught me .........since you have not been gracing the Security forum recently, didnt expect you to read it

> As for the topic at hand: Shekar's totally correct

I froze in my chair when i read this

on a more serious note, i think you are quite good with the functional flows and i was trying to sound comical and save my skin

0 Kudos

>

> Hi Mylene,

> You caught me .........since you have not been gracing the Security forum recently, didnt expect you to read it

You were betrayed! Someone e-mailed me your response!

>

> > As for the topic at hand: Shekar's totally correct

>

> I froze in my chair when i read this

> on a more serious note, i think you are quite good with the functional flows and i was trying to sound comical and save my skin

You are often correct. Not necessarily a need for me to agree with you - Security mostly isn't a matter of black or white - well, often not ... so there's more than one 'correct' way. But arguing with you is a pleasure - a fierce one!

But not for this topic. BWART as organisational level is downright wrong!!

Otherwise: I shall now retreat again to my annual SDN-months-long-avoidance-phase ...

0 Kudos

> You were betrayed! Someone e-mailed me your response!

I think i know who it could be

> You are often correct.

If i was not at office i probably would have been punch drunk by now

> Otherwise: I shall now retreat again to my annual SDN-months-long-avoidance-phase ...

I think this is not fair.......lets shoot someone if you prefer (Julius,maybe ). C'mon you are equally responsible to keep the charm of the forum going

Former Member
0 Kudos

I agree with BigJ, DrS & the one & only MD on this one. There are plenty of auth objects that have movement type and if it's a key restriction you could easily run into problems where you need different types for different objects in the same role. I would avoid promoting this to an org level based on the information we have available.