How to restict movement type specific to plant

[Former Member]

We have 3 plants, Say A, B , C ; and one user X , Y and Z ;

X belongs to A

Y belongs to B

Z belongs to C

We need to restrict the moovement type 641 specific to plant

A B C

X no yes yes

Y yes no yes

Z yes yes no

Remaning movement type access for his own plant.( ie x will have access for the remaining movement types in plant A ,

similarly all other users)

How to configure this through authorization?

Kindly Help.

[JPReyes]

Moved to Security forum

[Former Member]

I guess you can achieve this by creating few extra derrived roles and specify the restriction.

Regards

Rakesh

[Former Member]

X has role with access to all plant (A,B and C) and all mov type except 641

X has role with access to plant B and C and all mov type

similarly for Y and Z.

[Former Member]

>We need to restrict the moovement type 641 specific to plant

>

>A B C

>X no yes yes

>Y yes no yes

>Z yes yes no

This can be done with 3 roles.

> X has role with access to all plant (A,B and C) and all mov type except 641

> X has role with access to plant B and C and all mov type

>

> similarly for Y and Z.

This is different.

If the movement type (BWART) and the plant (WERKS) are not fields of the same object, then you will need to look for another field which is uniquely assigned to a plant and can be re-used.

In some cases, the system will perform more complex checks than just one object, but that depends on which transaction you want this restriction for and whether your users can be restricted to that group of transactions.

If you provide more details, then perhaps there is a way.

Otherwise, less elegant solutions such as creating 2 ID's for each person so that the roles don't "mix", or activating an exit / enhancement to deny permission based on the user having passed an authority-check.... are theoretically possible as well. But ugly

Cheers,

Julius

[Former Member]

> If the movement type (BWART) and the plant (WERKS) are not fields of the same object, then you will need to look for another field which is uniquely assigned to a plant and can be re-used.

>

To continue discussion :-

I agree with Julius that we will need a little more information to see if we can get this done by using three roles. Probably a list of transactions would be a little more helpful...but in all probablity except auth object M_MSEG_LGO ..am not aware of any standard auth object containing Plant and Movement type and even in this object there is field for storage location. If the t-code that is being used is not associated with this object ...then this object becomes redundant.

> In some cases, the system will perform more complex checks than just one object, but that depends on which transaction you want this restriction for and whether your users can be restricted to that group of transactions.

>

Most of the transaction related to movement type and plant will be associated with more that just 1 one auth object and that makes its restriction all more difficult.

Unless we have a Auth object with Plant and movement type as two fields, I do not see this being done by using just 3 roles.

If we have a custom object with just these two fields then I can understand

giving X a single role with two authrizations of this custom object

One containing all 3 plants and movement type except the one that is not needed

Second authorization containg plant B and C with all movement types.

[Former Member]

> > In some cases, the system will perform more complex checks than just one object, but that depends on which transaction you want this restriction for and whether your users can be restricted to that group of transactions.

> >

>

> Most of the transaction related to movement type and plant will be associated with more that just 1 one auth object and that makes its restriction all more difficult.

>

> Unless we have a Auth object with Plant and movement type as two fields, I do not see this being done by using just 3 roles.

But it can be done and some objects work in this way.

An example is S_TABU_LIN (if activated in SPRO) which will further restrict S_TABU_DIS (if correctly set in SE54) which itself is restricted by S_TABU_CLI (depending on the Data Dictionary).

Lets wait a while to see whether any gurus know an elegant way to do this for the movement type, and if not then I will move the thread to the ERP MM forum.

Cheers,

Julius

[Former Member]

Hi Rony,

Maintain Authobj for MvtTyp

Movement types are mostly used in below auth object:

Goods Movements: M_MSEG_BWA

Goods Receipt for Purchase Order: M_MSEG_BWE

Goods Receipt for Production Order: M_MSEG_BWF

These are paired with a corresponding auth object for plant access:

Goods Movements: M_MSEG_WWA

Goods Receipt for Purchase Order: M_MSEG_WWE

Goods Receipt for Production Order: M_MSEG_WWF

don't restrict movement type globally.

to get more dependency on mv typ visit link:[mvt|http://bbs.vsharing.com/Article.aspx?aid=641314]

regards,

[Former Member]

Hello Rony,

Restricting the same object for different movement type access for different plants cannot be done for the same role as the objects are interlinked. You have an object with mvt type and Actvt and another with actvt and plant. So, it will not be possible to restrict the role at this level. It would have been possible if we had one single object with Mvt type, Plant and Actvt. We could have maintained different instances of the object and thereby imposed the restriction.

As Julius suggested you may have to adopt the dirty way of having two user ids if it is absolutely essential.

But, 641 TF to stck in trans. as far as i know does not require authorization for the receiving plant. The movement has been designed specifically considering that the user should have authorization for the issuing plant only although the stock in transit would reflect under the stock for the receiving plant. correct me if I am wrong...

Regards,

Subbu