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.:

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2013/10/31/new-charm-feature-with-sp-10-enhanced-approval-procedure-functions

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‘.

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.

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_wrk–approval_steps_wrk WITH KEY approval_result = gc_status–request_for_change_rejected TRANSPORTING NO FIELDS.

  IF sy–subrc NE 0.

* –4. whether all step are processed

    CHECK cl_crm_approval_utility=>all_steps_done(

          it_approval_s_wrk = ls_approval_wrk–approval_steps_wrk ) EQ true.

    lv_approved = true.

    LOOP AT ls_approval_wrk–approval_steps_wrk ASSIGNING <fs_approval_s_wrk>

            WHERE approval_result EQ gc_status–request_for_change_rejected.

      lv_approved = false.

      EXIT.

    ENDLOOP.

  ELSE.

    lv_approved = false.

  ENDIF.

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

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,

Michael