Purchase Requisition release strategy Security issue

[rammohan_shenoy]

Experts, We are facing an issue with respect to security for Release strategy. Our PR release strategy has about 26 Release codes. The requirement is that  1. PR release be restricted by plant 2. PR create / change required for multiple plants Example : A user may have Release code ZA (for $5000 limit) assigned for Plant XYZ0 in security profile. So he can approve upto $5000 for XYZ0 in Tcode: ME54N. However he also has PR create and change security access for multiple plants (ABC0, XYZ0) under Tcode: ME51N/ME52N. However ME54N restriction by plant (XYZ0) is being overridden by ME52N Plant setting of * or (ABC0, XYZ0) Result is that Tcode ME55 or ME54N gives him access to approve Release code ZA not only for XYZ0 but also for other plants(ABC0). PS: Our release strategy configuration does not have plant as characteristic. Otherwise Release codes would multiply by26. That will be in excess of 300 Release codes. We do not want this as data maintenance becomes too much. Not feasible option Any thoughts from experts what may be wrong from Security standpoint or otherwise would be appreciated. Regards,

[jagdeepsingh83 · Accepted solution]

I think you need to have BADI ME_REQ_PROCESS_CUST to call your custom authority check for ME54N..

[rammohan_shenoy · Accepted solution]

This community expert experience all put together might be 1000 of years. I am sure many experts have faced this issue and resolved in some way. I did not receive anybody else thoughts. Regards,

[JL23 · Accepted solution]

Usually people who are nominated as approver are intelligent enough to select and release only requisitions in their responsibility. It is even possible to enter the plant in the selection screen of ME55 to get only the PR for which he is responsible, minimal education could help too.

People who have authority to work in different plants have to be careful anyway to not mix the plants when they enter requisitions or anything else.

It is a long known fact that authorizations accumulate per object. Talk to your security team for details.  Such facts have to be considered when you setup release strategies, even it leads to the effect that you  you have to setup 300 release codes.

And if you don't want to do that then you have to go the ABAP way to program own checks.

[rammohan_shenoy · Accepted solution]

Thanks to all that replied. Jurgen - I agree that Approvers are people with responsibility. But errors can be done by anyone. Your answer does make sense. This was the analysis of my MM & Security team as well. Regards,

[BijayKumarBarik]

Hi,

Our release strategy configuration does not have plant as characteristic.

As plant is not  release characteristic , then data maintenance is the other option in case of more number of plants in your business.

Otherwise Release codes would multiply by26. That will be in excess of 300 Release codes.

I would prefer-  you can go for 5 or 6 release codes and go for data maintenance by having releasers with release codes with a custom tablle

1st screen, Enter Plant code

2nd screen,

Keep following

Release code-----------------R1----------------R2--------------R3----------------R4------------R5-----------R6

Releasers-------------------User:1-------------User:2--------User:3-----------User:4------User:5-----User:6

Releasers-------------------User:7-------------User:8-------User:9--------User:10-----User:11-----User:12

Releasers-------------------User:13---------User:14------User:15--------User:16-----User:17-----User:18

____

---------

Etc...

For each plant you can keep releasers with release codes.

With above option you can manage Security standpoint with only 6 release codes but data maintenance is unavoidable.

Regards,

Biju K