Skip to Content

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 😉

To report this post you need to login first.

4 Comments

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

  1. 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!!!!

    (2) 
    1. 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 !

       

      (0) 
        1. 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! 🙂

           

          (1) 

Leave a Reply