Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 

A Central Finance implementation does require key mapping to be maintained in the system for Finance master to support transactional postings.

[ I intend not to discuss key mapping in details as we have lot of information shared by SAP community members which can be referred to ]

The focus of this blog is to consider the challenges faced during key mapping maintenance & replication from MDG to Central (S4 HANA) Finance system considering different timelines for implementing both these systems and steps to overcome the same.



  • The Central Finance system does support the key mapping maintenance for all finance objects.

  • But when MDG hub is also to be implemented along with it, business may expect that the mappings are governed in MDG (using customization as per business requirement as it is not standard  SAP functionality to govern key mappings) and also there replication to central finance (using Webservices, for details refer to url Key Mapping SOAP services )

  • MDG hub should stand single point of truth for key mapping of all such finance objects (e.g. GL, Cost center etc).

  • But there are challenges faced in the project if the central finance and MDG implementation timelines are different.

  • It is very critical to know these challenges and their impact on key mappings as it affects the financial postings in central finance system resulting into further Financial impact to the Client/Business

Before I discuss the challenges let me share few details on key mappings

  • All entries in the key mapping are assigned to a unique mapping group (a ID which identifies mappings) in each system (in this example it is MDG and Central Finance)

  • The mapping group may contain different (which may be incorrect) or duplicate mappings (e.g. same ECC/S4 GL value mapped with multiple Central Finance GL's) if they are maintained in central finance first irrespective of the implementation plan for MDG hub.

  • The mappings created are updated in database tables (few details below in this post)



Now let me explain you the different implementation scenarios and what challenges it may bring up :

1) MDG hub implementation planned before Central Finance Implementation:

  • The MDG system will have all key mappings created/maintained whenever central finance system implementation is kicked off.

  • The mapping group ID is unique in MDG and Central Finance, MDG being single source of truth having all correct entries

  • There are cases in which mappings are directly updated in central finance system (in pre go-live system) due to any reasons critical to business to support/test transactional data

  • Any such mapping updates done later in MDG will create duplicate entries in Central finance system as the database tables are already updated with same mappings but with different mapping group which is unique to central finance.

2) MDG hub implementation planned with Central Finance Implementation:

  • The MDG system will have all key mappings to be replicated to central finance and maintenance of the same is possible using single/mass processes.

  • But if in case any mappings are directly maintained in central finance will cause duplicate or incorrect entries. (due to different mapping groups in both systems which may contain different values)

  • As the mapping group from MDG and central finance will be different having different mappings also the database tables in central finance will not have similar values making it difficult for MDG to act as single source of truth.

3) MDG hub implementation planned after Central Finance Implementation:

  • The MDG system will have key mappings loaded from central finance system and the replication may cause incorrect/duplicate entries as the key mapping already exists in central finance and may have been modified. (This is also due to different mapping groups in both systems)

  • The incorrect or duplicate mappings may appear because of database tables updated with those mappings.

Example below are database tables for GL mappings.

{ Use the respective object text instead of "GLAM" in below table names for objects other than GL}

Table  Description
UKMDB_AGCGLAM0  UKM: Key Agency table
UKMDB_MDGGLAM0  UKM: Negative Mapping Groups table
UKMDB_MGPGLAM0  UKM: Positive Mapping Groups table
UKMDB_SCHGLAM0  UKM: Key Schema table
UKMDB_V78GLAM0  UKM: Value Table

Overcoming the Challenges:

To overcome the challenges of incorrect or duplicate mappings we need to be assured below steps are followed:

  • It is necessary that MDG acts as single point of truth for all key mappings to be created or updated

  • Get all the mappings replicated from MDG system only (no manual creation in Central Finance)

  • When MDG is planned to be implemented before or along with Central finance it is crucial that Central finance system gets all key mapping replicated from MDG only.

  • And when it is to be implemented after central finance all existing key mappings are to be removed and then replicated from MDG

  • If due to any reason the values are required to be maintained in central finance during any phase of the project it is important to refer to the database tables and remove the incorrect or duplicate entries from central finance system

  • Tcodes MDG_KM_MAINTAIN or FINS_CFIN_MAP_MANAGE can be used for deletion depending upon the entries



The takeaways from this post is the different timelines followed for MDG-F implementation with central finance system and challenges faced for the key mapping maintenance & replication using MDG as hub.
Also we come to know about the steps to be followed to overcome challenges which further helps avoid impact on financial postings and reduce errors in central finance system.

I hope this information useful to all readers. Request all readers to provide suggestions, feedback to improve my future posts
Labels in this area