Skip to Content
avatar image
Former Member

How to avoid multiple roles for release PO in SAP ECC ?

Hello Team,

Our company has multiple release code and release group.

For each release code and group combination we have a single role.

The number of roles are increasing with the creation of new release codes/release groups.

Is there a way or different strategy this is being handles in other organizations?

Can we create a custom table to add users with new release code/group to avoid multiple role craetion. What are the risks associated with this?

Add comment
10|10000 characters needed characters exceeded

  • Former Member


    Please suggest if your organization/client has implemented something different for release Purchase Order security.

    1. Is it the only best way to manage- By creating single role for each release code and release group combination?

    I am interested to understand how it is being handled in other organizations.How many roles you have in your system for the same.

    Authorization Object M_EINK_FRG

    Release Code

    Release group

  • Get RSS Feed

3 Answers

  • Sep 07, 2017 at 04:45 AM

    The first thing that you have to understand is what a release code actually is. It is basically a key to unlock a door.

    Imagine now an apartment building, each apartment has usually its own individual key, the release code.

    The caretaker service has a general key, one key to open any door.

    The question is now, which kind of key do you want to give to your tenants?

    If each tenant should have its own individual key - then this means for each release code 1 role

    If all tenants would be okay that each of them has the general key - then you can create just 1 role and add all release codes to this role.

    The tenants would actually not even realize this if nobody tells them. The release code is a mandatory field in the release transaction and not searchable. So the approver knows basically the code which was told to him. Even better if all was supported with approval workflows and the approvers would not need to go to the normal transactions.

    Actually, the team who is building the roles is not really in the lead in this activity which is purely based on the setup of the purchasing release strategy. If "general key for all" would be wanted then the whole release strategy setup could be done differently. Of course it would be best if MM consultants had some knowledge on role creation and their company specific concepts but also the authorization team could consult with the MM guys if they understood how a release strategy works. Unfortunately purchasing release strategy is the supreme discipline of MM consultants, and because of that even more difficult to understand from non-MM-consultant, but maybe it can help you to read my blog to get a step into this.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member
      • Thank Jurgen for sharing the link of your blog.

      It is a big and very detailed blog.I had to read it more than once so I can understand how it works behind the scene.

      I have some understanding now and have set up a meeting with our Production Support team handling the release strategy.I will try to understand the current strategy being followed in our organization and if they want to change/ optimize it .

      With the current little understanding I had it seems they do not want to touch it /change it :-)

  • Sep 06, 2017 at 02:54 PM

    can't we go with Master and Derived Role concept or may be restrict the user base on Authorization Group concept, just wonder?

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hello Rizwan,

      Release code and group are not an organization field . We can change them into org field but it will not bring the role count down.

      We will still have to create a new role for new combination of release code and release group.

      Can you please explain how we can utilize the authorization group concept in this scenario?

  • Sep 07, 2017 at 01:49 AM

    Authorization Group concept, just wonder? I mean restrict the tables on Authorization groups level through criticial Authorization Objects S_TABU_DIS & S_TABU_NAM.

    Add comment
    10|10000 characters needed characters exceeded