Restricting movements on a Transaction

[Former Member]

Hello All

I am from a retail background and this question is aiming at my users in the warehouse. We have warehouse where i'd like to restrict certain movements with regards to certain transactions.

E.G.

I would like UserA to have Transaction code (MB51 - Article Movements by Article) that i know how to do.

BUT i would only like UserA to do goods movements 901 and 902

and

UserB also to have (MB51 - Article Movements by Article) and to do a good movement of 161 and 162

I appreciate any response on a directional note.

Rgds...Bhavesh Katechia

[Former Member]

Hi Bhavesh,

Restricting the transaction code MB51 based on movement type can be achieved by upgrading the authorization field to org value but this will effect entire system and this is usually set during the system set up.

In your case the authorization field BWART need to be converted to org level this can be achived by report PFCG_ORGFIELD_CREATE (tcode se38 to run).

[link|http://www.sapsecurityonline.com/sap_security_interview_questions/sap_security_interview_questions_2.htm]

Further it depends on your requirement, if there are few users then you can create different single roles and assign to them(which i dont recommend)

Rakesh

[Former Member]

Hey,

In this case , you would have just need seperate roles for user A and user B , with transaction MB51 and for Auth. Object M_MSEG_LGO have different combinations of Movement Type (BWART) .

Assign diffrent set of values in each role , based on users needs.

Cheers

Puneet.

[Former Member]

All

You've both been extremly helpful, currently I have auths based on Activity Groups and users, How does an Object fit into this place and what are the added benefits.

thanks...BK

[Former Member]

Hi Bhavesh,

As said earlier if you have few users who needs different movement types then go head and create different roles and assign them to the users.

If the requirement is in bulk then promote the authorization field to organizational field.

Rakesh

[diwheeler]

Hi Bhavesh,

so, just repeating what the others have said but probably with lots more words. I guess you're wanting to produce a segregation of duties between the users. You would have a separate role for user A, that lets user A do their thing, and another role for user B that lets B do their thing.

So..

User A

assigned role Z_USERA_Role

containing:

Tcode: MB51

auth object: M_MSEG_LGO: BWART = 901, 902

User B

assigned role Z_USERB_ROLE

containing:

Tcode: MB51

auth object: M_MSEG_LGO: BWART = 161, 162

If the roles are fundamentally identical barring the underlying authorisations, you have a few options.

You can create separate roles for each user that have each to be maintained individually. Obviously this has a higher maintenance overhead if you plan on keeping them the same.

You can create a template role, then create derived 'children' roles that are driven off from the template role with different auth values. Menu changes get made to the template role and the derived 'children' roles get updated with appropriate auth values suitable to each area. This assumes there is the same business process across all areas, but that there are different realms of responsibilities (e.g. might be company code/movement type etc).

You can create a single role providing transaction access that everyone gets and a separate role containing profile values only (the recommendation is usually only do this if you know what you're doing)

Of course, these people might already have their own roles which you can introduce this functionality into if your role design is more job based than process based.

One other thing which I'm sure youre aware of is to be careful of the SOD requirements or role conflict requirements you might have if you assign two of the same roles together. Your business process owners could help you with this if you don't know quite where the lines should be drawn.

Cheers,

Di

[Former Member]

thank you all very much...thanks for the detailed explanation Di....

cheers ...BK