Part 4 - SAP MDG – A Stepping Stone for SAP S/4HANA Journey

[Antony_Prasanna]

Introduction

Clients across the globe are getting into the Transformation journey started with SAP S/4HANA.

In this blog, we will take one of the use cases to discuss how the master data (MDG)  journey will be the stepping stone for SAP S/4HANA Transformation and the needed steps to achieve it.

This is the 4th blog in this series. Please go through Part 1,2 & 3 in the given below link

https://blogs.sap.com/2023/01/27/sap-mdg-a-stepping-stone-for-sap-s-4hana-journey-part-i/

https://community.sap.com/t5/technology-blogs-by-members/sap-mdg-a-stepping-stone-for-sap-s-4hana-jo...

https://community.sap.com/t5/technology-blogs-by-members/sap-mdg-a-stepping-stone-for-sap-s-4hana-jo...

Key Aspects for MDG : Deep Dive

B. MDG Specific

B.2 User Interface

For any product/solution to be successful, it needs to have a good user experience. The first impression for the users comes from the user interface

SAP MDG offers Netweaver Business Client (NWBC) and SAP Fiori as the UI.

For this use case, NWBC is considered as it is tightly integrated with MDG data model which means the out of Box data model is already available in NWBC by standard

In this section, we will discuss the approach for UI flexibility for user experience and solution approach for field status for specific system

Approach for UI ( Global Form vs Specifics )

As MDG going to the central master data systems catering for 3 ECC systems & future S/4 system, it is important to finalize the strategy for UI as we are considering having all finalized fields ( Global + Local) be governed in MDG

There are 2 options which can be catered to this

• Global Form – All finalized fields will be shown to all users irrespective of the ERP system ( Region) to which user belongs to
• Regional specific Form – All global fields + that specific region fields are only shown.

It needs discussion with various stakeholders in terms of business value realization, use cases and vision before finalising the UI for MDG.

UI enhancement can be done either by configuration / developments.

 Solution Approach for Field Status Requirements

In the previous blog on data model section, there was a topic on field status when there are differences between ECC systems.

• Field status matches across all systems – Same will be configured at back end ( Account Group level)
• Field status having differences across systems - One of the suggestions is to keep Optional at the back-end configuration

This will help to overcome the forced need of data enrichment at local systems for data migration into MDG & also for the CRUD process.

If that’s the case, then comes the below question

How do we handle the need for field status for specific ECC systems?

The need for a specific ECC system field status ( Ex: Field 2 for ECC – Americas ; Field 3 for ECC – Asia to be mandatory for Acc grp 1) to be catered.

There are multiple solution approaches for this. Considering the complexity, there needs a framework solution which needs to give flexibility  and reusable

UI Framework

The high-level solution is to have a framework to manage the exceptions as below

 

1. Acc grp Configuration Backend – By SAP standard, the field status are setup at MDG UI
2. The framework solution gets MDG to read a UI control table and set the field status accordingly ( Exceptional)
3. If there are no entries in control table , the field property will behave as per the status set at the account group configuration at the backend

The solution is to use the Field Properties BADI to read the control table to set the field properties.

Below are the example control table entries for the requirements listed above

If a field is at the organizational level, then the field status behaves once the company codes have been added.

What if , there are exceptions at general data ?

As the framework have company code as one of the dimensions ( input), in the form, that field will show as Optional at first. However, once the company code is added, the framework will trigger the exceptions status to show in the form.

It could be a training topic for the users ( They might wonder about the status change in the form during the process !)

Please be noted that for Block, Mark for Delete CR’s , by SAP standard all fields will be read-only except the actual block/mark for delete specific fields. So the framework solution will not be applicable for those 2 CR types.

Even though the solution offers flexibility , there are some limitations , disadvantages which it brings such as field status validations to be build, data load etc which will be discussed in the subsequent sections

In the next blog, I will cover other topics in detail.

About the Author,

Antony Prasanna has been working in SAP master data space since 2006. Have experience working across multiple large transformation programs on SAP S/4HANA including SAP MDM, MDG and Data Migration tools.