Skip to Content
Author's profile photo Sascha Wächter

Processes & Forms: Set latest approver instead of WF-Batch as last modifier in infotype

We took our first steps with processes & forms and liked it. Then someone noticed that the user WF-BATCH is always displayed as the last modifier of the infotype if a process has been approved. This is a bit ugly because you can not see who is responsible for the change within the infotype.

In our case it’s about a double approval where the clerk is the last approver. So I decided to implement a soulution for this, so that the latest approver is set as latest modifier instead of WF-BATCH.

In my workflow I added the field approver to the container where i hold the actual last approver. In my last approval step before I save the workflow data I add the approver of the task to the container.

Dataflow looks like this:

So after that i have to import the latest approver from the container in my task where the data is saved to infotype.

No you can copy standard class CL_HRASR00_WF_COMPONENTS -> E.g. ZCL_HRASR00_WF_COMPONENTS

Change method save_form_data_to_db_wd:

**********************************************************************
* Note 1422496: Enable the debugging for background task.            *
*               To activate debugging execute FM:                    *
*               K_PLAN_WAIT_FOR_DEBUGGING_CTRL with the following    *
*               parameters.                                          *
*               ID_DEBUG_ID     = 'HRASR'                            *
*               ID_DEBUG_LEVEL  = 'SAVE_FORM_DATA_TO_DB'             *
*               ID_USERNAME     = <User_Name>                        *
**********************************************************************
  CALL FUNCTION c_debug_fm "K_PLAN_WAIT_FOR_DEBUGGING
    EXPORTING
      id_debug_id    = c_debug_id
      id_debug_level = c_save_form_data_to_db_wd.
**********************************************************************
* End Note 1422496                                                   *
**********************************************************************

* Call maintain_form_data with activated save to backend (check_only = '')

  sy-uname = conv #( approver_in+2 ).

  CALL METHOD cl_hrasr00_wf_components=>maintain_form_data_wd
    EXPORTING
      check_only                     = ''
      workitem_id                    = workitem_id
      form                           = form
      activity                       = activity
    IMPORTING
      procstate                      = procstate
      error_category                 = error_category
      error_messages                 = error_messages
      expert_withdraw_button_visible = expert_withdraw_button_visible.

Here the special move is to add approver to sy-uname.

You have to add the approver as parameter to the method before.

 

After that you have to change the basic info of your save task and ad your custom class:

Finally you modify the data flow for the object method and add the approver:

 

Don’t forget to add the approver to your task container:

 

After all is done, your latest approver is automatically the latest modifier of the infotyp after approval 🙂

 

 

I think it is one out of many ways but it works 😉

Assigned tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Christopher Solomon
      Christopher Solomon

      Nice blog and write up! .....and yes, there are a few ways to do this.

      This topic comes up in EVERY HCM P&F project I have done. There are always discussions about whether or not having WF-BATCH show as the user who changed data is a good or bad thing.

      I won't rehash what you did/said here....because, some clients absolutely insist a "real person" show as the person who "touched" the record. However, here is the argument for NOT doing it that way and using/accepting WF-BATCH (standard behavior).

      1. Looking at  the record, you have NO idea that it was actually part of a process....ie. MANY people involved and made the decision for the update.
      2. Given #1, not clear path to "audit" the update.
      3. Given #1 and 2, if you make it part of the training/habit of the users that if they see "WF-BATCH" then they know that it was done as part of a process....and then can take that information to go look at EVERYONE involved (for example, use Process Search to locate the actual process that updated the record).

      I think this gives the end user a MUCH more clear picture of "why" the update was done more than just "who" did it.

      .....and in the end, I follow which ever path the client decides.....but it is nice to know they have the options!

      Thanks again and keep blogging!!!!

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Not just HCM. There was a question posted just recently how to do similar thing for PO approval. When PO is approved by email, apparently some companies want to see the real user name, not a generic WF/batch user.

      Thanks for sharing, Sascha Wächter !

       

      Author's profile photo Christopher Solomon
      Christopher Solomon

      Jelena....I clicked "like" on your post...in fact, I clicked it about 10 times and it never updated.....ugggg.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      It happens to me every other day. You have to refresh the page, then it works. One of the SCN "features", I guess. One really needs to be determined to "like" a comment! 🙂