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: 

Borrowing Object Values

chris_hall2
Participant
0 Kudos

I'm sure this has been asked several times, yet I can't find anything using the search.

I have a scenerio where an employee has a purchase order release role as well as a requisition release role

PO Role

Transaction ME28

Release Grp MA, TL

Release Code 01

REQ Role

Transaction ME54

Release Grp *

Release Code 21

When the user goes into ME28 they are able to release purchase orders at any release level. I do realize that this is a design flaw in our Req role, but would like to understand the way this works. I know there are several instances where in one case you may want an object to be one value and another case a totally different value.

Edited by: Chris Hall on Oct 21, 2010 8:48 AM

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hello Chris,

Though there may be different instances where different values are required, the security concept in SAP is such that it groups the authorizations together at the end of the day (SU56 displays the user buffer for authorizations, but you may already know this). If two transactions are using the same auth object as in this scenario, and you have defined the values in both roles, SAP is going to pickup which ever authorization that satisfies the authority check condition.

In your scenario, it is imperative that the requisition role (ME54) be reined in, as from past experience with an automotive client i remember that the release strategy role (ME28) needs to be air tight as regards security.

Regards,

Prashant

3 REPLIES 3

Former Member
0 Kudos

Hello Chris,

Though there may be different instances where different values are required, the security concept in SAP is such that it groups the authorizations together at the end of the day (SU56 displays the user buffer for authorizations, but you may already know this). If two transactions are using the same auth object as in this scenario, and you have defined the values in both roles, SAP is going to pickup which ever authorization that satisfies the authority check condition.

In your scenario, it is imperative that the requisition role (ME54) be reined in, as from past experience with an automotive client i remember that the release strategy role (ME28) needs to be air tight as regards security.

Regards,

Prashant

0 Kudos

Hi Chris,

M_EINK_FRG is the object for the release code and the release group for both purchase orders and Purchase requsitions, so far so good - but my understanding says that this is NOT the only object that decides if you can release orders/requsitions on plants, purchasing organizations in which you are not supposed to.

you would have to check your entries for a host of other objects; M_BEST_BSA,M_BEST_EKG,M_BEST_EKO,M_BEST_WRK for PO's and M_BANF_BSA,M_BANF_EKG,M_BANF_EKO,M_BANF_FRG,M_BANF_WRK

Do give particular attention to M_BANF_FRG and M_BEST_WRK, M_BANF_WRK, since the WRK objects are the authorizations for the receiving plant

sdipanjan
Active Contributor
0 Kudos

Hi,

At the first glance I would think not to provide Rels Grp * in the 2nd case. Also look for the same authorization object which is under consideration for the checked authorization... if any 2nd instance is present through other role in the user context.

Regards,

Dipanjan