Updated on 31.01.2014 to include information from SolMan 7.1 SP05 onwards.

People working with SAP Solution Manager Implementation Projects and Change Request Management (ChaRM) are probably used to set up authorization object S_PROJ_GEN to control authorizations in project functions such as lock blueprint, assign logical components to the project landscape, create and assign task list to a project. These functions are currently well documented rather in SAP Notes, SAP Solution Manager Security Guide or here in SCN. Authorization object S_PROJ_GEN has the following fields:

  • PROJECT_ID      Name of the project

  • PROJ_FUNC      Project administration functions

Those users working with Quality Gate Management, specialy in SolMan 7.0, can face some difficulties to understand how to set up this authorization object since there is no documentation explaning the meaning of the new PROJ_FUNC codes related to QGM. QGM functions such as Create Change, Create Transport Order, Release Transport Order, Reassign Transport Order and so on have a corresponding PROJ_FUNC field to allow the user to define who can do each task in the QGM webdynpro.

SAP Solution Manager Security Guides for 7.0 and 7.1 mention the standard roles relevant for QGM. There are four standard single authorization roles in SolMan 7.0:

  • SAP_SM_QGM_ALL: For all authorizations in QGM

  • SAP_SM_QGM_TRANSPORT: Authorization for Transport Delivery

  • SAP_SM_QGM_STATUS_QM: Set Quality Gate status as Quality Manager

  • SAP_SM_QGM_STATUS_QAB: Set Quality Gate status as Quality Advisory Board

SolMan 7.1 has the above single roles and some more.

From SP01:

  • SAP_SM_QGM_CHANGE: Quality Gate: Change Manager Role

From SP05 on:

  • SAP_QGM_MANAGED_CHANGEMAN: QG Management on managed systems (Change Manager)

From SP08 on:

  • SAP_SM_QGM_CM_ALL: Change Management for QGM (Administrator)

  • SAP_SM_QGM_CM_CHANGE: Change Management for QGM (Change Manager)

  • SAP_SM_QGM_CM_QAB: Change Management for QGM (QAB)

  • SAP_SM_QGM_CM_QM: Change Management for QGM (Quality Manager)

  • SAP_SM_QGM_CM_TRANSPORT: Change Management for QGM (Transport)

There are composite roles in 7.1 for QGM:






These roles in SolMan 7.1 have many authorization objects not used by QGM before because release 7.1 included new functionalities such as a new CRM transaction type called SMQC (QGM: Change) and SMQU (QGM: Urgent Change). They use authorization object S_PROJ_GEN with default values for project function field PROJ_FUNC. If you need to create your own role to distribute the different activities to different people or group of people, instead of using only the standard roles, you will need to understand the meaning of each PROJ_FUNC field. You will find listed in the SAP Security Guide for 7.1 some of the new fields (not all) created for QGM, but will not have any explanation of what they mean. In the SAP Security Guide for Solution Manger 7.0 SP23 these new fields are not mentioned.


Below I show three figures that are screenshots from transaction PFCG, one with a list of the PROJ_FUNC field values in SolMan 7.0 and another 2 lists with the PROJ_FUNC field values existing in SolMan 7.1. Most of them are related to QGM. People using SolMan 7.1 has a little bit more information about the QGM values if comparing to SolMan 7.0 users – more field values with description- but there are still some values with no description:

Figure 1 – PROJ_FUNC fields in SolMan 7.0 SP23:

Proj_Func values in SolMan 7.0

Figure 2 – PROJ_FUNC fields in SolMan 7.1 SP3:

Proj_Func values in SolMan 7.1

Figure 3 – PROJ_FUNC fields in SolMan 7.1 SP10:


Table below shows the description of each field value related to QGM and whether they are related to SolMan 7.1, including new fields already considered in the QGM authorization routines in SolMan 7.1, but not yet included in the list of existing entries for authorization object S_PROJ_GEN, at least not in SolMan versions that I checked. If someone using a different SolMan Support Package finds these missing field values, please leave a comment.

PROJ_FUNC   value


SolMan 7.1

Not in list


Create   Change Document


Modify   Change Document


Delete   Change Document


Decouple a transport request from a  Change



Reassign Change Document


Release Change Document


Change Document



Withdraw Change Document



Create a maintenance cycle for QGM



Approve   Q Gates as Quality Advisory Board


Approve   Q Gates as Quality Manager


Create   Task

TRAPApprove/revoke Critical ObjectX


Assign Transport Request




Modify Transport Request


Create Transport Request


Decouple  Transport Request




Delete  Transport Request

TRIMImport LockX



Reassign   Transport Request


Release   Transport Request


Create   Transport of Copies for Production system




Create   Transport of Copies

UCCAApprove Urgent Change as Quality Advisory BoardX
UCMAApprove Urgent Change as Quality ManagerX

If you check Figure 2 you will note that 3 values listed in the table above are missing in the list of entries: TRAS, TRDC and TRTP. But they are included in standard role SAP_SM_QGM_TRANSPORT for SolMan 7.0 SP23 and SolMan 7.1 SP03. TRAS (Assign Transport Request) and TRDC (Decouple Transport Request) are not available functions in SolMan 7.0 QGM and the source codes for authorization checks do not consider them, so they are not relevant in this SolMan release. In SolMan 7.1 they are all being checked.

In SolMan 7.1 SP05 two new functionalities were added to QGM: Approve/Revoke Critical Objects and Set/Unset Import Lock. The corresponding value for Import Lock (TRIM) is not in the PFCG list either, even in SP10, but it was included in the standard QGM roles.

Figure 4 shows authorization object S_PROJ_GEN in standard role SAP_SM_QGM_TRANSPORT of SolMan 7.0:


If you want to check the source code of authorization routines, go to transaction SE24 and check class CL_TD_AUTHORIZATION.

The list of existing project functions are stored in table SPR_ADM, and the descriptions in different languages are stored in SPR_ADMT. If you want to see all the descriptions in the authorization object S_PROJ_GEN values list while creating your roles in PFCG, update table SPR_ADMT and include the missing texts in the relevant languages.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Tom Cenens

    Hello Raquel

    It’s great to see you are blogging on SCN 😎 .

    Getting the authorizations right is important and often a challenge within a project.This will certainly help out numerous consultants. SAP could definitely brush up certain guides / help pages to give a clear view on what is what and how to use it and so on. Glad you did!

    Kind regards


    1. Raquel Pereira da Cunha Post author

      Hi Tom,

      I faced some issues when trying to find out what each of the new function codes means when setting up roles for QGM and decided to share my conclusions in SCN. I hope I can help other people. I just went live with QGM in a customer with all the authorizations correctly set up and that was definitely an important point for the success of this project. Authorizations are often not very well treated during projects and support, and the correct set up makes all the difference.

      Thank you very much for your comment.

      Best regards,


      1. Tom Cenens

        Hello Raquel

        I’m sure this blog post will prove useful to community members. I have seen discussion threads that are related to what your blog post explains so hopefully they find your blog post 🙂 and use it well

        I agree with you, authorizations are a pain point really in such implementations. Sometimes due to the fact that SAP doesn’t put sufficient information out there so I’m glad fellow community members are helping out to get more information out there.

        Best regards


  2. Esteban Hartzstein

    Hello Raquel,

    I am facing the question from a customer regarding how to restrict the changes you are working in.  I imagine dozens of changes in a project and you want to restrict that people work only in their own changes, to avoid mistakes (releasing transport that belongs to someone’s else transport).

    I was digging into the objects and run ST01 to check the trace but I could not find anyway to restrict in which changes work each person.  As long as they are working in the same project, everybody that can modify a change can do it for any.  Do you have any alternative? Is there any badi that can help in working with that request?

    Many thanks



Leave a Reply