Skip to Content

A Different ‘Reject’ Behaviour in the Change Request Management Approval Procedure

So after some time at home (parental leave, etc.) today I want to share with you, how and where to change behaviour in the approval procedure easily if you are able to do coding (or in this special case insert the code).

I will not get into approval procedure detail, more information of the this can be found here f.e.:

Standard behaviour:
When using the approval procedure in Change Request Management with more than one approver, the Request for Change is only rejected after all approvers have voted, meaning executed their approval step.

Which means if you have a Request for Change with five approvers and the first one rejects the Request for Change, you have to wait until all approvers voted so the Request for Change is rejected. But it will be rejected as one reject is enough to completely reject the whole Request for Change.

This is the standard behaviour taken over from CRM standard.

Advantages and disadvantages:

The advantages are that all approvers know about the Request for Change and that it might be more convenient that if this has to be clarified with the rejecters, you know all of them in one step.

The disadvantage is that you have to wait until all approvers executed their decision until you get feedback because the Request for Change will nevertheless be rejected.

I was shortly contacted by a customer asking if this could be changed.

The customer wanted that the first reject leads to a general rejection of the Request for Change because it doesn’t make sense for him to wait until others rejected, too. I assume they have a process which allowed to go again into approval from ‘Rejected’ which might not be a ‘FINI’ status at all. But that’s a guess.

Here is now how the behaviour can be implemented:

  1. Copy a standard function module and change the code
  2. Register the new function odule instead of the old in the CRM event Framework

The standard behavior evaluating the approval steps and setting the approval procedure is implemented via the CRM Event Framework which can be reached via transaction ‘CRMV_EVENT‘.

event framework.jpg

There function modules are registered to be called by specified events, like save of the CRM document, etc.

Enter the function name ‘AIC_SRQM_RFC_APPROVAL_STAT_EC’ and press ‘Callback for Cat./Obj./Event’.

You will see that the function is registered to run on the event ‘AFTER_SAVE’ if for the object ‘APPROVAL’ the attribute ‘STEP’ has changed.

function regiesterd.jpg

This function  ‘AIC_SRQM_RFC_APPROVAL_STAT_EC’ has to be replaced by our own copied function ( f.e. ‘Z_SRQM_RFC_APPROVAL_STAT_EC’) with changed code.

To do so, call transaction ‘SE37’, copy the function to the name stated above to an existing function group of your choice and save everything in your transport. Be aware that the top-include of your function group needs the includes

INCLUDE crm_approval_con.

INCLUDE crm_object_kinds_con.

INCLUDE crm_object_names_con.

INCLUDE crm_events_con.

INCLUDE crm_mode_con.

INCLUDE crm_log_states_con.

INCLUDE crm_status_con.

so the copied function module is syntax free.

Then replace the code listed in the screenshot with the code further down and activate everything.


* Replacement code ****

  READ TABLE ls_approval_wrkapproval_steps_wrk WITH KEY approval_result = gc_statusrequest_for_change_rejected TRANSPORTING NO FIELDS.

  IF sysubrc NE 0.

* –4. whether all step are processed

    CHECK cl_crm_approval_utility=>all_steps_done(

          it_approval_s_wrk = ls_approval_wrkapproval_steps_wrk ) EQ true.

    lv_approved = true.

    LOOP AT ls_approval_wrkapproval_steps_wrk ASSIGNING <fs_approval_s_wrk>

            WHERE approval_result EQ gc_statusrequest_for_change_rejected.

      lv_approved = false.




    lv_approved = false.


Afterwards register this function in the CRM Event Framework by going into ‘Edit’ mode and entering the new function name.

replace 2.jpg

That’s all. Now the new function with the changed code is called and the Request for Change is set to ‘Rejected’ when the first approver rejects his approval step.

By the way,  if you are familiar with the Basis Enhancement Framework ,it is as well possible to replace the code directly in function ‘AIC_SRQM_RFC_APPROVAL_STAT_EC’, then you do not have to change the registration of the function in the CRM Event Framework.


So, hope that helped a bit if you find errors, get in contact with me,


You must be Logged on to comment or reply to a post.
  • Welcome Back Michael, we have been missing your blogs for quite some time now 🙂

    This is really useful tip you have shared and I will try to implement this using whatever the little ABAP knowledge I have.



    • Hi Vivik, thanks for the flowers :-). I would like to post more but we are all busy here with 7.20 Solman release. That is as well, why I am keeping a low profile here 🙂

  • Hi Michael,

    this is good, if this is the preferable procedure and also most of the customers need, can we achieve this by delivered SAP NOTES corrections

    because as Vivek mentioned we have very limited ABAP knowledge, if this suggestion released as notes then easy to follow.



    • Hi Jansi, a good idea. I have forwarded this to my product owner, so he can check this.

      I will update you if the decision is done,

      best regards,


  • HI Michael, just found this now, glad you posted our idea about this type of rejection, we have been using it and it works great.

    Thanks again, keep up the great work



  • Hi Michael, thank you for this post. I have implemented all settings and code you’ve posted.

    But I’ve faced with error in my system. In case of scope extending and already created change document(s) in processed RfC when I try to reject approval my RfC goes to Approved status instead of status according to rejected one. It seems like system ignores FOLL_REJ settings


    • Hi Dimitry, please open up a customer message as no analysis can be done without system access. SAP support will analyze this issue,

      best regards,


      • Hi Michael, I’m afraid that they will refuse my request as I’ve changed it according this post and now it is Z-functionality


        • Hi Dimitry,

          please try it, it might go in the consulting direction but no try no gain ;-).

          I am sure you understand that an analysis is not possible from here.

          best regards,


          • Hi Michael,

            unfortunately AGS can not resolve this issue. If you have access to SAP AGS system you can look at 417155 / 2015 Message. I think – it is the error in SAP SM that doesn’t resolved now!


          • Hi Dimitry, I checked the message, this is a bug and has to be fixed. Can you open up the message again, so I can take over or send it to the relevant colleague?



          • Hi Dimitry, as there has started a discussion internally, I have to be more specific with my communication to you. The only bug I see is this one:

            if the scope is extended and all the change documents already created are in status ‘Withdrawn’ and then the RfC scope is ‘Rejected’, the RfC should go to ‘Rejected’ in  standard, meaning choosing the ‘FOLL_REJ’ way. But we will continue this discussion in the message now as this is not the correct place to do it 😉

  • Hello Michael,

    Thank you for the great post. I have a similar requirement and I believe I can use your post to get it sorted.

    However, I have something more to this requirement. I want to make the ‘Comments’ field mandatory whenever a user ‘Reject’ the RfC / Change Doc.
    I am an ABAP Consultant but pretty new to CRM. I would appreciate if you could give some pointers in order to make the ‘Comments’ field mandatory in case of a Rejection.

    Thank you.



      Hi Sudarshan,
      one way would be to implement a ChaRM check that is assigned to the status in which the rejects leaves. In the Standard Transaction type this would be ‘In validation’. The check should check if the approval procedure is closed and if yes, check if the rejected steps have a comment left. This would be quite generic.
      Another way would be to do an Extension in the CRM approval procedure assignment block field ‘Comment’ itself. You could Change the Attribute dynamically to ‘mandatory’ for the field in case the value is rejected in the CRM UI buffer. This has to be done via tx BSP_WD_CMPWB, for UI component ‘BT_APPROVAL’ but you should maybe check the transaction type first because this component is as well used for other Transaction types like the SMIR (IT Requirement).
      Check out the context of BTAPPROVALSTEPS Base Entity BTApprvalStep. For the Attribute STRUCT.PROCESSED_BY you Need a getter method. You can create this by right-clicking on the Attribute. I am not sure but I think the method is GET_P_PROCESSED_BY where you have to do it.
      Do your logic and then decide…

            IF lv_mandatory EQ abap_true.
              rv_value = ‘TRUE’.                                  “#EC NOTEXT
             rv_value = ‘FALSE’.                                 “#EC NOTEXT