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
In this blog we will walk you through the steps required to enhance a standard MDG inbox to include additional fields.
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
- 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.
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 =
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.
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(
iv_crequest = wa_wi_crequest–usmd_crequest
iv_model_name = <model name>
re_inst_crequest_api = lo_usmd_crequest_api ).
call method lo_usmd_crequest_api->read_objectlist(
iv_entity_type = ‘MARA’
et_entity = it_entity ).
read table it_entity into wa_entity index 1.
if sy–subrc = 0.
wa_field–fieldname = ‘WEKGR’.
insert wa_field into table it_field.
call method lo_usmd_crequest_api->create_data_reference(
iv_entity = ‘MAW1’
i_struct = ‘KATTR’
it_attribute = it_field
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(
i_fieldname = ‘MAW1’
if_current_creq_only = ‘X’
it_sel = it_sel
et_data = <fs_data> ).
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.
this will give you the result including the Purchasing group. Now the inbox has to be changed based on this.
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.