[Fiori] Leave Request Approval Steps with Custom Workflow

If you want to copy the standard workflow of the leave request approval process (WS12300111) and are adding antoher approval step (or you just want to add an esacalation where you set the approve workitem to obsolete and create a new approval step for the next approver) you have to implement the following BAdI. In detail you only have to add the new step ID in the filter, else the approver will not see any approval or reject buttons in his inbox. See details here.

BAdI: /IWWRK/BADI_WF_BEFORE_UPD_IB

Defaul implementation: HCMFAB_LEAVE_APPROVAL_INBOX
Default Workflows and Step ID’s
Add your custom workflow and the custom approval step id in your own BAdI implementation

As second step you have to add the Worklow in the customizing. You’ll find further information here.

SM30 View /IWWRK/V_WFSTEP.
Add the Workflow with Approval StepId
Add the Approve and Reject Buttons

[ABAP] Find employee subtitutes

cl_swl_substitution=>get_pers_substitutes( EXPORTING  i_substituted_person     = ls_substituted_person
                                                      i_start_date             = sy-datum
                                                      i_end_date               = sy-datum
                                           IMPORTING  et_substitutes           = DATA(lt_substitutes)
                                           EXCEPTIONS user_not_found           = 1 " Benutzer existiert nicht
                                                      plan_variant_not_found   = 2 " Planvariante ist nicht gepflegt
                                                      time_period_not_valid    = 3 " Zeitraum ungültig
                                                      no_personal_substitution = 4 " Es handelt sich um keine persönliche Vertretung
                                                      OTHERS                   = 5 ).

[ABAP] Leave Request Approval Workflow with Escalation

During the leave request approval process the standard workflow WS12300111 does not include any deadlines. To archieve this you can simply copy the workflow and add a deadline at the approval task (Step 38). There are two possible ways to forward the approval step to the next processor:
1. Forward your current workitem to the next approver.
2. Set current workitem to obsolete and create a new workitem and assign it to the next approver. Then you also have to add the new step ID to this BAdI Filter.
I took the first option. In my demo the escalation is triggered after just three minutes.

The deadline generates a new exit on the approval step.

In this new exit you able to call your own logic on finding the new approver, forward the workitem and inform him via mail if necessary.

To forward the request to next the approver, you have to forward the workitem and also set this new approver as next processor in the current leave request.
So first identify the next approver. I used RH_GET_LEADER for this.

*--------------------------------------------------*
* Get next approver
*--------------------------------------------------*
    CALL FUNCTION 'RH_GET_LEADER'
      EXPORTING
        plvar                     = '01'
        keydate                   = sy-datum
        otype                     = is_approver-otype
        objid                     = CONV realo( is_approver-objid )
      IMPORTING
        leader_type               = lv_leader_type
        leader_id                 = lv_leader_id
      EXCEPTIONS
        no_leader_found           = 1
        no_leading_position_found = 2
        OTHERS                    = 3.

    CHECK lv_leader_type EQ 'P' AND lv_leader_id IS NOT INITIAL.

    CALL FUNCTION 'HR_GET_USER_FROM_EMPLOYEE'
      EXPORTING
        pernr             = CONV pernr_d( lv_leader_id )
        iv_with_authority = abap_false
      IMPORTING
        user              = lv_userid_approver.

    ev_approver-otype = |US|.
    ev_approver-objid = lv_userid_approver.


Then set this new approver as next processor in your request. While doing this, it’s recommended to enqueue and dequeue the request. To get the current request object use class cl_pt_req_badi.

*--------------------------------------------------*
* Set new approver in request
*--------------------------------------------------*
    " Enqueue the request
    CALL FUNCTION 'ENQUEUE_EPTREQ'
      EXPORTING
        mode_ptreq_header = 'S'
        mandt             = sy-mandt
        request_id        = io_req->req_id
      EXCEPTIONS
        foreign_lock      = 1
        system_failure    = 2
        OTHERS            = 3.

    " Get the request object instance
    CALL METHOD cl_pt_req_badi=>get_request
      EXPORTING
        im_req_id  = io_req->req_id
      IMPORTING
        ex_request = DATA(lcl_request).
    CALL METHOD lcl_request->set_next_processor
      EXPORTING
        im_actor_type = 'P'
        im_plvar      = '01'
        im_otype      = 'P'
        im_objid      = CONV #( lv_leader_id ). " PERNR of Next Approver
    IF sy-subrc = 0.
      COMMIT WORK AND WAIT.
    ENDIF.

    " Dequeue the request
    CALL FUNCTION 'DEQUEUE_EPTREQ'
      EXPORTING
        mode_ptreq_header = 'S'
        request_id        = io_req->req_id.

Finally forward the workitem to the new approver. There of course you need the right workitem ID of the approving step.

*--------------------------------------------------*
* Forward workitem to next approver
*--------------------------------------------------*
    CALL FUNCTION 'SAP_WAPI_FORWARD_WORKITEM'
      EXPORTING
        workitem_id  = iv_wi_id                "woritem id of approving step
        user_id      = lv_userid_approver
        language     = sy-langu
        do_commit    = 'X'
      IMPORTING
        return_code  = lv_subrc.
    IF lv_subrc <> 0.
    ENDIF.