Enhancing Change request Inbox with additional columns

Business Requirement

SAP Master Data Governance helps organizations govern master data from its creation in a business application,through  step by step enrichment by different roles in the organization, to its replication to target applications to ensure data quality and regulatory compliance across the enterprise. SAP master data governance can be used for multiple master data domains like customer, material, supplier, articles , finance etc. As you probably are already aware, SAP MDG  process are centered around the concept of Change Requests. Any request for creation or change of an object is handled via change request. The change request work items any user receives, as part of the governance process, are visible in his workflow inbox. In a typical business day, the user would log into his workflow inbox and start processing one work item after another. The workitem inbox in its standard  view shows only the field information from the change request header

In the retail industry we very often come across a requirement in article governance process , where the category manager or the purchasing manager likes to make a decision based on certain attributes on the article master data .  These could be for example, based on the Purchasing Group decide if he is the one to process or should this be picked up by another colleague in the team  or based on the price decide if he wants to include the article in his assortment therefore move the article to the next step for further enrichment  etc

Especially during the early steps in the governance process the category manager might not want to click on the change request item and go into the details, But rather might want to make the decision on how the workitem should be processed right from the inbox.

The category manager is looking for a view where he can look at some important fields on the article data  in a single glance and make decisions on multiple articles right from the inbox without going into the detailed view screen

Introduction

In this blog we will walk you through the steps required to enhance a standard MDG inbox to include additional fields.

Pre Requisites

We will enhance the inbox with the purchasing group field. The MDG for Article data model already has the field Purchasing group and hence we need not extend it. But if you want some other field as additional column in the MDG Inbox for any data model, then that respective field has  to be first extended in the Data Model

Class

• Create a class zcl_usmd_crequest_powl which is an inheritance from super class cl_usmd_crequest_powl.
• Copy the structure usmd_s_crequest_powl into your own Z structure. This is nothing but your inbox structure. Now add the additional field to this structure.
• Reimplement the method SET_MV_RESULTSTRUCTURE in your Z class and provide this structure name over there.

        Now you have your own structure which will be displayed in your inbox. In order to pass value to this field,

• Redefine the method  IF_POWL_FEEDER~GET_OBJECTS. Call the super method first and then have your part of coding:

data: : it_wi_crequest        type usmd_ts_wi_crequest,

        wa_wi_crequest        like line of it_wi_crequest,

        it_wi                 type usmd_ts_wi,

        wa_wi                 like line of it_wi,

        lo_usmd_crequest_api  type ref to if_usmd_crequest_api,

        it_entity             type usmd_t_crequest_entity,

        lr_data               type ref to data,

        it_field              type usmd_ts_field,

        wa_field              like line of it_field,

        lv_cond               type string value ‘wi_id = wa_wi_crequest-wi_id’,

        it_sel                type usmd_ts_sel,

        wa_sel                like line of it_sel,

        wa_entity             like line of it_entity.

field-symbols: <fs_results>      type any,

                 <fs_id>           type any,

                 <fs_data>         type any table,

                 <fs_wa>           type any,

                 <fs_wekgr>        type any,

                 <fs_wekgr1>       type any,

                 <fs_matnr>        type any.

                

super->if_powl_feeder~get_objects

    exporting

      i_username              = i_username

      i_applid                = i_applid

      i_type                  = i_type

      i_selcrit_values        = i_selcrit_values

*     I_LANGU                 = SY-LANGU

*     I_VISIBLE_FIELDS        =

    importing

      e_results               = e_results

      e_messages              = e_messages

      e_workflow_result_count = e_workflow_result_count.

e_results assigning <fs_results>.

    assign component ‘WI_ID’ of structure <fs_results> to <fs_id>.

    wa_wi = <fs_id>.

    append wa_wi to it_wi.

  endloop.

  it_wi_crequest = cl_usmd_wf_crequest_mapper=>get_crequest_by_wi( it_wi = it_wi ).

  loop at it_wi_crequest into wa_wi_crequest.

    call method cl_usmd_crequest_api=>get_instance(

      exporting

        iv_crequest          = wa_wi_crequest–usmd_crequest

        iv_model_name        = <model name>

      importing

        re_inst_crequest_api = lo_usmd_crequest_api ).

    call method lo_usmd_crequest_api->read_objectlist(

      exporting

        iv_entity_type = ‘MARA’

      importing

        et_entity      = it_entity ).

    read table it_entity into wa_entity index 1.

    if sy–subrc = 0.

      refresh it_field.

      wa_field–fieldname = ‘WEKGR’.

      insert wa_field into table it_field.

      call method lo_usmd_crequest_api->create_data_reference(

        exporting

          iv_entity    = ‘MAW1’

          i_struct     = ‘KATTR’

          it_attribute = it_field

        importing

          er_table     = lr_data ).

      assign lr_data->* to <fs_data>.

      wa_sel–fieldname = ‘MARA’.

      wa_sel–low       = wa_entity–usmd_value.

      wa_sel–option    = ‘EQ’.

      wa_sel–sign      = ‘I’.

      insert wa_sel into table it_sel.

      call method lo_usmd_crequest_api->read_value(

        exporting

          i_fieldname          = ‘MAW1’

          if_current_creq_only = ‘X’

          it_sel               = it_sel

        importing

          et_data              = <fs_data> ).

      refresh it_sel.

      if <fs_data> is assigned.

        loop at <fs_data> assigning <fs_wa>.

          assign component ‘WEKGR’ of structure <fs_wa> to <fs_wekgr>.

          if <fs_wekgr> is assigned.

            loop at e_results assigning <fs_results> where (lv_cond).

              assign component ‘WEKGR’ of structure <fs_results> to <fs_wekgr1>.

              assign component ‘ARTNR’ of structure <fs_results> to <fs_matnr>.

              move <fs_wekgr> to <fs_wekgr1>.

              move wa_entity–usmd_value to <fs_matnr>.

               modify e_results from <fs_results> index sy–tabix.

            endloop.

          endif.

        endloop.

      endif.

      refresh it_field.

this will give you the result including the Purchasing group. Now the inbox has to be changed based on this.

So, go to transaction code powl_type and change the entry usmd_changerequest_wi and change the class name

Now your inbox will be reflected with the new value.

Note: Since inbox is a common component where all workitems from all domains are received, this column will be visible also when you login to govern your vendor master data (for example). In order to avoid this, you have to create a separate role and have your own Powl Id in that which means it will be reflected only in your current Article Inbox.