Recently, my customer department asked me to turn a text field in Material master (MARA-BEGRU) into a checked input field with a value help, plus text (plant name) from foreign table. The requirement specification based the approval workflow on said field contents, so there was really no way I could talk the customer straight out of this nonsense idea.
The outlook was bleak, our options were dire: Start a requirement discussion with the user department late in the project? Rush in a modification? Postpone GoLive? Surrender? - Never!
tl&dr;
Turn this ... |
... into this. |
Implementing these requirements is surprisingly easy with SAP Master Data Governance, as it uses Floorplan Manager for Web Dynpro ABAP for UI and provides a ton of extensibility options:
- FPM allows you to specify and override field properties in the GET_DATA call, e.g. to add a DDIC search help to a field that has none.
- Adding UI-only fields can be achieved via FPM feeder class extension.
- Checking against the foreign key table via the MDG check extensions, e.g. BRFplus
Implementation
In ERP, such a requirement requires a modification (which is often described on the net), but we do not want to do this, especially since MDG considers the check table setting of the fields domain, and the domain of this field is used in several master data objects. Luckily in MDG-M, we can use extension mechanisms of MDG-M itself and Floorplan Manager to achieve the same result w/o modification.
Note: MDG-M uses the Service Provider (SPI) Framework internally, so not everything of this implementation can be 1:1 applied to other MDG applications, yet the approach will still be the same.
Provide your own feeder class
Use one of the FPM provided extension methods to add your own UI logic into the SAP delivered MDG-M application. This allows you to extend / alter parts of the SAP delivery modification-free, w/o being cut-off from future SAP developments or bug fixes. The MDG-M User Interface Enhancement Guide has a very comprehensive step-by-step description of the process. I prefer to use FPM enhancements for changes that effect all screens / change requests, and CBA if the change is only applicable in certain situations (e.g. certain Material type).
Adding text fields
Redefine the FPM SPI feeder method /PLMU/IF_FRW_G_FIELD_DEF~CHANGE_FIELD_DEFINITION to add additional fields to the both the field catalog (CO_CATALOGUE) as well as the field description (CT_DEFINITION). For text fields, it is important to:
- name the field in the following pattern: <main_field>__TXT<optional_id>
So if your field is named YY_DSRESP, then you should call your text field(s) for that field YY_DSRESP__TXT and YY_DSRESP__TXT2. - Do your changes to before calling the super-> method. This way MDG works some magic to hide the text fields when the main field is hidden, highlights changes, etc.
The following sample code does the trick:
METHOD /plmu/if_frw_g_field_def~change_field_definition.
"Get the current UI structure's field list
DATA(lt_components) = co_catalogue->get_components( ).
"---------- Add custom (UI-only) fields
"Text field for 'Authorization group', where we have plant numbers
y0mm_mat_ui_assist=>add_custom_ui_field(
EXPORTING
iv_name = cs_field-begru-txt
iv_type = VALUE t001w-name1( )
CHANGING
ct_components = lt_components
ct_spi_field_descr = ct_definition
).
"---------- Modify field list / Call SAP Standard
"Create new structure description with added components
co_catalogue = cl_abap_structdescr=>create(
p_components = lt_components
).
"MDG standard does all the magic (highlighting, hiding field if key is hidden, ...)
CALL METHOD super->/plmu/if_frw_g_field_def~change_field_definition
IMPORTING
et_special_groups = et_special_groups
CHANGING
co_catalogue = co_catalogue
ct_definition = ct_definition.
ENDMETHOD.
The helper method for consistently changing the structure and description list looks like this:
METHOD ADD_CUSTOM_UI_FIELD.
"Get data type of new field
DATA: lo_field_description TYPE REF TO cl_abap_datadescr.
lo_field_description ?= cl_abap_datadescr=>describe_by_data(
p_data = iv_type
).
"Add field to UI data structure
INSERT
VALUE #(
name = iv_name
type = lo_field_description
)
INTO TABLE ct_components.
"Add UI field to description
INSERT
VALUE /plmu/s_frw_g_field_descr_appl(
name = iv_name
technical_field = abap_false
)
INTO TABLE ct_spi_field_descr.
ENDMETHOD.Adding Search Help
This is also very easy, since you can provide the name of a DDIC search help in the field description list. So in the above method, just change the field description after you have called the super-> method. In the below code, the MDG delivered search help for plants (T001W) is assigned to the field Authorization group (BEGRU), which normally is a text field:
"---------- Change behaviour of existing fields
"Search help for BEGRU
READ TABLE ct_definition
WITH TABLE KEY name = cs_field-begru-name
ASSIGNING FIELD-SYMBOL(<field_definition>).
IF IS ASSIGNED.
"Use same search help that MDG uses for plant number search
<field_definition> -ddic_shlp_name = 'MDG_BS_MAT_WERKS_ELEM'.
ENDIF.Foreign key check
The changes so far affect only the UI, i.e. MDG-M itself does not know about the foreign key relation between the field Authorization Group (MARA-BEGRU) and the plant table (T001W), but you can implement this yourself, e.g. using a BRF+ rule to do the check and issue an appropriate error message if the entered key is not in the table.
Conclusion
I've been working with MDG for several years now, from early CoInnovation over several Ramp-ups all the way to the recent v7.0, yet still I am sometimes surprised on how easy it is to implement customer requirements, while at the same time staying fully within the boundaries of supported enhancements of the SAP standard. Working with the v7.0 release has been a real joyful experience so far, enabling us to implement some rather obscure requirements in my current project.
Many thanks to adrian.branka2 for providing the idea for this solution. His consulting skills have kept our project from derailing several times already.
- SAP Managed Tags:
2 Comments
