Sap MDG-F

Customizing &
Application Guide
for SAP Master
Data Governance
Finance (MDG-F)
Business Partner -
Configuration
Dipl.-Wirtsch-Ing. Hans-G. Emrich

2020
SAP Master Data Governance Finance
Content
1 Summary ................................................................................................................... 8
2 Business Process Flows for G/L Account Administration ........................................ 11
2.1 Functionalities of MDG-F .............................................................................................................. 11
2.1.1 Copying of accounts .............................................................................................................. 12
2.1.2 Enhanced BCV content to display hierarchy changes .......................................................... 13
2.1.3 Importing Company Data ...................................................................................................... 13
2.1.4 Remote Where-Used List ...................................................................................................... 13
2.1.5 SOA Services for Consolidation Systems ............................................................................. 13
2.1.6 Enhancements for Data Model 0G ........................................................................................ 13
2.1.7 Group Accounts as Items ...................................................................................................... 13
2.1.8 Conclusion ............................................................................................................................. 14
2.2 High level Process Definitions ...................................................................................................... 17
2.2.1 Process flow - Single Creation of G/L Account and Cost Objects ........................................ 17
2.2.2 Process Flow Diagram .......................................................................................................... 21
2.2.3 Process flow – Single Blocking / Unblocking of G/L Account ............................................... 22
2.2.4 Process Flow Diagram .......................................................................................................... 23
2.2.5 Description of the MDG-F application process using an example ........................................ 24
3 Technical description and presentation of the settings of MDG-F ........................... 35
3.1 Data Model creation 0G ............................................................................................................... 35
3.2 SAP Best Practices Standard settings ......................................................................................... 35
3.3 Customizing setting ...................................................................................................................... 40
3.4 UI-Modelling .................................................................................................................................. 41
3.5 Search Application settings .......................................................................................................... 42
3.6 Duplicate Check settings .............................................................................................................. 42
3.7 Process modelling ........................................................................................................................ 43
3.8 Create Business Activity ............................................................................................................... 44
3.9 Replication model ......................................................................................................................... 46
3.9.1 Creation of Repication Models .............................................................................................. 46
3.10 Change requests ....................................................................................................................... 46
3.11 Type of change requests .......................................................................................................... 48
3.12 Configuring ALE for Master Data Governance for Financials ................................................... 50
3.12.1 Prerequisites .......................................................................................................................... 50
3.12.2 Define Global Business Areas ............................................................................................... 50
SAPCon Seite 2 von 214

3.12.3 Procedure .............................................................................................................................. 51

3.12.3.1 Create a Distribution Model ............................................................................................ 51
3.12.3.2 Create Replication Models ............................................................................................. 55
3.12.3.3 Activate Replication Models ........................................................................................... 57
3.13 Settings for Data Replication .................................................................................................... 58
3.13.1 Set Up Data Replication ........................................................................................................ 58
3.13.1.1 Set Up ALE Configurations ............................................................................................ 58
3.13.1.2 Define logical systems for all target systems in MDG hub. ............................................ 59
3.13.1.3 Create Global company code for ALE ........................................................................... 59
3.13.1.4 Create Distribution Model ............................................................................................... 59
3.13.1.5 Generate Partner Profile ................................................................................................ 60
3.13.1.6 Distribute the Model ....................................................................................................... 61
3.13.2 Set Up DRF Configurations ................................................................................................... 62
3.13.2.1 Define Business System ................................................................................................ 62
3.13.2.2 Define replication model ................................................................................................. 62
3.13.2.3 Enable monitoring of IDoc posting (ALE Audit) .............................................................. 63
3.13.2.4 Technical settings for Business Systems ....................................................................... 65
3.13.2.5 Landscape example ...................................................................................................... 65
3.13.3 Definition Business Systems, Bos ......................................................................................... 66
3.13.4 Define Replication Models ..................................................................................................... 67
3.13.5 Setting example for GL account master ................................................................................ 69
3.14 ALE / IDOC Settings ................................................................................................................. 70
3.14.1 Creation of Partner profiles ................................................................................................... 70
3.14.2 Outbound parameters in XCF ............................................................................................... 71
3.14.3 Inbound parameters in XCF .................................................................................................. 72
3.14.4 Partner Profiles in receiver system XR1CL010 ..................................................................... 72
3.14.5 Distribution Model creation of partner system ....................................................................... 74
3.14.6 Defining a Distribution Model ................................................................................................ 74
3.14.7 Example with System DCF & U0309 ..................................................................................... 76
3.14.8 Example with System DCFCLNT030 .................................................................................... 76
3.15 Creation of global company code ............................................................................................. 76
3.16 Workflow ................................................................................................................................... 79
3.16.1 Activities ................................................................................................................................ 79
3.16.2 Define Change Request Actions ........................................................................................... 79
3.16.3 Define Change Request Step Types and Assign Actions ..................................................... 81
3.16.4 Rule based-Workflow ............................................................................................................ 84
3.16.5 Define Change Request steps for Rule-Based Workflow ..................................................... 84
3.16.6 Configure Rule-Based Workflow ........................................................................................... 85
3.16.6.1 Decision Table................................................................................................................ 88

3.17 Workflow Description ................................................................................................................ 89

3.17.1 Business Process Overview .................................................................................................. 90
3.17.2 Process Overview Table for Sequential Approval ................................................................. 90
3.17.3 Process Steps ....................................................................................................................... 92
3.17.3.1 Approval Process ........................................................................................................... 92
3.17.4 Validate G/L Account Data .................................................................................................... 92
4 SAP MDG Finance Product Features an Best Practices and Future Roadmap ...... 94
4.1 Extensions and new features in MDG-F in Best Practices version .............................................. 94
1.1.1 Process Features .................................................................................................................. 94
1.1.2 Master Data and Hierarchy Assignment in the same Main Financial Objects UI ................. 95
1.1.3 Usability Features in Single-Object Maintenance UI ............................................................. 95
1.1.4 Usability Features in Hierarchy Processing .......................................................................... 96
1.1.5 Replications ........................................................................................................................... 97
1.2 Editions ......................................................................................................................................... 97
1.2.1 Workcenterper area: Accounting, Controlling, Consolidation ............................................... 98
1.2.2 How to enter master data changes ....................................................................................... 98
1.2.3 Change request ..................................................................................................................... 99
1.2.4 Central Governance for Financial Data ............................................................................... 105
1.2.5 MDG-f Supporting Central Finance (SAP S/4HANA Finance) ........................................... 106
5 A Configuring SAP for Inbound and Outbound Processing ................................... 107
5.1 Configuring SAP Inbound Processing .......................................................................................... 107
5.2 Configuring a Logical System ..................................................................................................... 107
5.2.1 Defining a Logical System ................................................................................................... 108
5.3 Configuring a Distribution Model ................................................................................................ 111
5.3.1 Defining a Distribution Model .............................................................................................. 111
5.3.2 Defining a Partner Profile .................................................................................................... 114
5.3.2.1 Defining a Partner Profile ............................................................................................. 114
6 Configuring SAP Outbound Processing................................................................. 119
6.1 Related Concepts and Terminology ........................................................................................... 119
6.2 Client and Server Programs ....................................................................................................... 119
6.3 Program IDs and Load Balancing ............................................................................................... 120
6.4 Connection Pooling..................................................................................................................... 120
6.5 Registering Your Program ID in SAPGUI ................................................................................... 121
6.6 Registering Your Program ID ..................................................................................................... 121
6.7 Testing the SAP Event Adapter .................................................................................................. 123
6.8 Testing the SAP Event Adapter by Sending an RFC or a BAPI Manually ................................. 123
6.9 Application Link Embedding Configuration for the Event Adapter ............................................. 125
6.10 Defining a Port ........................................................................................................................ 125
6.10.1 Steps of Defining a Port ...................................................................................................... 126

6.11 Creating a Logical System ...................................................................................................... 127

6.11.1 Creating a Logical System .................................................................................................. 127
6.12 Creating a Partner Profile ....................................................................................................... 129
6.12.1 Creating a Partner Profile .................................................................................................... 129
6.13 Collected IDocs ....................................................................................................................... 130
6.14 Creating a Distribution Model for the Partner and Message Type .......................................... 131
6.14.1 Creating a Distribution Model .............................................................................................. 131
6.15 Testing the SAP ALE Configuration ........................................................................................ 133
6.15.1 Testing the SAP ALE Configuration .................................................................................... 133
7 SAP TCodes for "Receiver Port " .......................................................................... 135
8 Master Data Management Generic Extractor (MDMGX) for Initial Load in
MDG-F ...................................................................................................................... 139
8.1 Transaction MDMGX – Main Menu ....................................................................................... 139
8.2 Define Object Types.................................................................................................................. 140
8.3 Define Repositories and FTP servers ................................................................................... 142
8.4 Maintain Ports and Check-Tables ......................................................................................... 144
8.5 Define Function Module Parameters for Exceptional Cases ............................................ 146
8.6 Start Extraction .......................................................................................................................... 147
8.7 Start Extraction .......................................................................................................................... 147
9 MDG Data Import Framework ........................................................................ 151
9.1 Technical Requirements ..................................................................................................... 151
9.2 System Setup ......................................................................................................................... 151
9.3 Examples: ................................................................................................................................. 151
10 Step-by-Step Example: MDMGX – MDG-F Extraction ............................... 153
10.1 Check Object Types in MDMGX ........................................................................................ 153
10.2 Define Repositories and FTP servers ......................................................................... 154
10.3 Maintain Ports and Check-Tables ................................................................................ 154
10.4 Account ................................................................................................................................... 155
10.5 Company ............................................................................................................................... 157
10.6 Cost Center ........................................................................................................................... 157
10.7 Cost Element ........................................................................................................................ 159
10.8 Group Account ....................................................................................................................... 159
10.9 Profit Center .......................................................................................................................... 160
10.10 4. Define Function Module Parameters for Exceptional Cases ............................... 162
10.11 Extract the Data ...................................................................................................................... 163
11 Step-by-Step Example: DIF- Import MDG-F Master Data.......................... 165
11.1 Upload extracted Files to the Application Server ........................................................ 165
11.2 Starting the Data Import Framework Application .................................................................... 165
11.3 Prepare the Import of Financial Master Data ............................................................... 166

11.4 Optional: Run a Simulation of the Import ...................................................................... 167

11.5 Run the Import ..................................................................................................................... 167
12 MDG extensions, improvements and business benefits ..................................... 169
12.1 Consolidation of master data .................................................................................................. 169
12.2 Mass processing of master data ............................................................................................. 170
12.3 Central governance of financial master data .......................................................................... 171
12.4 Central governance of financial master data .......................................................................... 172
12.5 Central governance of master data......................................................................................... 173
12.6 Central governance of business partner, customer, supplier master data ............................. 175
12.7 Process analytics for governing master data .......................................................................... 177
12.8 Master data quality management ............................................................................................ 178
12.9 Master data quality management ............................................................................................ 180
13 Useful Transactions in SAP Workflow ................................................................ 181
14 IDoc-Transaktionen ............................................................................................ 186
14.1 IDoc-Transaktionen – Anzeigen / Monitoring / Admin ................................................................. 186
14.2 IDoc-Transaktionen – Administration .......................................................................................... 186
14.3 IDoc-Transaktionen – Suche......................................................................................................... 186
14.4 IDoc-Transaktionen – Test ........................................................................................................... 186
14.5 IDoc-Transaktionen – Dokumentation ......................................................................................... 187
14.6 IDoc-Transaktionen – Entwicklung .............................................................................................. 187
14.7 IDoc-Transaktionen – Steuerung .................................................................................................. 187
14.8 IDoc-Transaktionen – Umsetzregeln ............................................................................................ 188
14.9 IDoc-Transaktionen – Umschlüsselung .................................................................................. 188
14.10 IDoc-Transaktionen – Sonstige ............................................................................................... 188
15 MDG Transactioncodes ...................................................................................... 189
16 Attachment ......................................................................................................... 190
16.1 Configuring Master Data Governance for Financials .............................................................. 190
16.2 Prerequisites ........................................................................................................................... 190
16.3 Data Model .............................................................................................................................. 190
16.4 Business Function ................................................................................................................... 191
16.5 SAP Business Workflow ......................................................................................................... 192
16.6 Web Dynpro Applications ........................................................................................................ 192
16.7 Process ................................................................................................................................... 192
16.8 Links ....................................................................................................................................... 193
16.9 How-to Guides ..................................................................................................................... 193
16.10 SAP Notes ........................................................................................................................... 194
16.11 Financial Data ......................................................................................................................... 194
17 BUSINESS SCENARIO Configuration Business Partner (BP) .......................... 197
17.1 SAP NOTES AND LINKS ....................................................................................................... 197

17.2 BACKGROUND INFORMATION ............................................................................................ 197

17.3 FUNCTIONAL RESTRICTIONS ............................................................................................. 198
17.4 STEP BY STEP EXPLANATION ............................................................................................ 198
17.4.1 Data Model .......................................................................................................................... 198
17.4.2 Multiple Assignments........................................................................................................... 199
17.4.3 Hierarchies .......................................................................................................................... 199
17.4.4 Customer / Vendor Integration (CVI) ................................................................................... 200
17.4.5 Access Classes ................................................................................................................... 203
17.4.6 Handler Classes .................................................................................................................. 204
17.4.7 Abstract Foundation Handler............................................................................................... 205
17.4.8 Abstract Application Handler ............................................................................................... 205
17.4.9 Business Partner Handler ................................................................................................... 205
17.4.10 Multiple Assignment Handler ........................................................................................... 206
17.4.11 Customer Handler ............................................................................................................ 206
17.4.12 Supplier Handler .............................................................................................................. 206
17.4.13 Data Derivation ................................................................................................................ 207
17.4.14 User Interfaces ................................................................................................................. 207
17.4.15 Generic Interaction Layer (genIL) .................................................................................... 207
17.4.16 Floorplan Manager ........................................................................................................... 209
17.4.17 Context Based Adaptations ............................................................................................. 210
17.4.18 UIBBs & OVPs ................................................................................................................. 211

1 Summary
This document is to describe how SAP MDG functionality is used for automating and
centralizing of business processes for finance.
Inconsistencies in financial master data arise from local, non-standardized

maintenance processes (e.g. different charts of accounts) with, in some cases, manual
workflow steps in a heterogeneous global system landscape. This not only affects the
operational efficiency, but also the input required for the respective financial
statements when preparing evaluations and the subsequent manual adjustments. In
addition to this, increasing complex regulations require organizations to have change
transparency and audit trails.
The introduction of MDG-F will primarily address the following weaknesses in the
administration of Master Data Governance Finance
Inconsistent Master Data across Enterprise

Manual Efforts to update and maintain master data in local systems
Risk of non-compliance to country specific standards
Lack of transparency about changes
High Master Data Maintenance costs
Multiple Domain specific master data systems
No clearly defined roles and responsibilities for creating and approving master
data
SAP MDG for Financials (MDG-F) offers central maintenance and governance solutions for a
wide range of financial master data. These include, for example, accounting objects such as
standard and group charts of accounts, general ledger accounts, companies and Controlling
objects such as profit centers, cost centers and their hierarchies. In addition, customer-
specific objects can also be implemented with SAP MDG for Financials (MDG-F).

Specifics of SAP MDG-F:
Consolidation of company financial data with the financial data of the

subsidiaries
Mapping between corporate and operative standard charts of accounts
Tracking of the change processes and process setup possible within the
scope of IFRS, Sarbanes-Oxley, GAAP, etc.
Time-based and period-based versioning: Transparency, traceability, edition

(summary of multiple work steps for the final release)
The centralized SAP MDG for Financials (MDG-F) system permits the user-friendly
management of your financial data and specific customizing options in order to comply with
legal requirements with the aid of holistic integration into your SAP ERP system. In particular,
SAP MDG-F is notable for allowing existing SAP ERP data structures and objects to be
reused, which in turn allows checks and validations to be used analogously. The user
interface is based on ABAP WebDynpro programming to respond flexibly to changes in
requirements.
Benefits of MDG-F:
Improving data quality
Stabilization and acceleration of business processes
Optimization of process efficiency
Risk mitigation through consistent data root
Flexible response to changes
Reuse of individual, existing SAP functionalities and data structures

Use of the standard SAP ERP checks
Extensibility and adaptation to customer-specific requirements
Surfaces are customizable, configurable and customizable using The
Floorplan Manager (ABAP Webdynpro based)

Rule-based workflow is integrated via BRFplus, can be adapted quickly

and individually and enables automated workflow control, e.g. with a
simple 4-eye principle
Central generation and maintenance of master data
Harmonisation and consolidation of data in heterogeneous system
landscapes
Compliance compliance
Transparency about the influence of master data on business
processes
Transparency on responsibilities in the area of master data maintenance
financial

2 Business Process Flows for G/L Account

Administration
2.1 Functionalities of MDG-F
The primary business capabilities of an Enterprise Data Governance solution via SAP MDG
are listed below:
Define the base Business Process Model (BPM) structure for all master objects in
scope till Level 3 Process
Each Level 3 Process defined will then have a master data governance process flow
definition in the Blue print document
Full Master Data Life Cycle Process definition for all 3 in scope masters will
governance framework which includes – Creation, Change / Extension, Block /
Unblock & Mark for delete with follow on processes
External Compliance Check Process integration with the Governance Process
Data Quality and Cleansing Processes
Operational & monitoring process definition for the end state MDM Organization setup
Change Management Process definition pertaining to the End State MDM
Organization setup
Define the Data Stewardship & Business SME Roles participating in the CRUD
process for each master data object – BP Finance, BP Finance and Material Master
Define a clear RACI matrix for all 3 objects in scope for the MDG Roles
Included in the RACI would be a SOD as per the S/4HANA MDG system standards
Identifying the stakeholders from within AC for mapping to MDG specific roles
Define the End State MDM Organization with TOM operational structure
Training on stewardship and the use of tools for MDM management and consumption
Define the Master Data Model as per SAP Standard & Industry specific requirements
and AC business needs
Define the automated governance workflow processes with business rules & validation
checks
Define the SAP MDG specific Role with relevant authorizations

Define the MDM Integration Landscape Architecture for seamless information flow
from all systems to SAP MDG and replication back to all Downstream systems
Reliability
Integration setup with a Hybrid Landscape of cloud & on premise applications
In today’s hybrid world of system landscapes and integrations, the setup of a master data
landscape with information flow architecture between SAP Cloud (ARIBA, C/4 HANA,
Success factors), On Premise (SAP S/4HANA 1809and the old SAP ECC systems) and Non-
SAP applications for end to end process lifecycle is the primary business need.
Our Enterprise governance solution with SAP MDG and use of SAP best practice standard
replications technologies like SAP ALE (Application Linking & Enabling) and IDOCS, MDG
Data Replication Framework, SAP Process Orchestration or SAP Cloud Platform Integration
enables us to achieve that business capability. A glimpse of that is shown below.
With MDG-F you will be able to:
Have consistent financial master data across the entire organization;

Trace ability of changes for compliance requirements;
Excellence in financial processes that is accurate reconciliation and timely group
closing;
High quality of master data and a single version of the truth;
Importing company data from remote systems, such as investment management
systems.
From version 9.2 of MDG-F, SAP extended or created some new functionalities for this
application. Those functionalities will be summarized and the most important ones will be
explained more in detail.
2.1.1 Copying of accounts
When creating a G/L account, you can now save time and effort by copying the Chart of
Accounts and Company Code Data (With Template) from an existing G/L account using the
new Copy function on the Search screen. Alternatively, you can copy just the Chart of
Accounts Data.

2.1.2 Enhanced BCV content to display hierarchy changes
A new display option was added to the Query Views. In addition to displaying changes per
change request, you can now also display only hierarchy-specific changes for a change
request for a detailed overview.
2.1.3 Importing Company Data
You can use enterprise services to import the entity type Company from remote systems
(such as investment management systems) into SAP Master Data Governance for Financials.
You can use BAdIs for data importing to do this.
2.1.4 Remote Where-Used List
You can search for entity types in your attached remote system, using either the screen on
the UI, or using a Business Add-In, available in the Customizing structure.
2.1.5 SOA Services for Consolidation Systems
You can use an outbound service to replicate financial master data to consolidation systems
such as SAP BusinessObjects Financial Consolidation, SAP BusinessObjects Planning and
Consolidation, and SAP SEM: BCS or NON-SAP-Systems.
2.1.6 Enhancements for Data Model 0G
The entity types for Account, Account in Company Code, Cost Center, Cost Element and
Profit Center have each been enhanced with a new entity type with storage and use type 4
for storing SAP ERP audit information. This allows the Created by and Created on
information to be transferred from SAP ERP systems into the central MDG system during an
initial load of master data.
2.1.7 Group Accounts as Items
• With MDG 9.2 it is possible to upload group accounts from SAP ERP (stored in table
SKA1) to MDG-F as items (entity type FSI). The replication of items to SAP ERP as
group accounts is also supported;
• The functionality includes:
o Enhanced extraction criteria for MDMGX (Master Data Management Generic
Extractor) in SAP ERP;
o Enhanced initial load functionality in MDG DIF (Data Import Framework);
o Enhanced data replication for items.
Next to this you also have the possibility to:
• Enablement of Mobile Access through Fiori Apps for Approval of G/L Accounts in Fiori;
• Integration with SAP Shared Service Center;

• Enhanced Edition Management;

• Changeable IDs for MDG-F entity types;
• Multi-copying for accounts in company code;
• One-step creation of accounts and their related primary cost elements;
• Enhanced search capabilities with an out-of-the-box integration of SAP HANA Search;
• Enhanced and Simplified Hierarchy Management;
• Data transfer & replication.
2.1.8 Conclusion
To finalize this blog a little summary of key-points why to implement MDG(-F) in your SAP
landscape:
• The centralized MDG-F system permits the user-friendly management of your financial
data and specific customizing options in order to comply with legal requirements;
• No duplicated data in your SAP system;
• Tracking of the change processes and process setup;
• Time-based and period-based versioning: Transparency, traceability, edition ;
• Importing, transferring and replication of data.
This part now describes the creation, modification, change and blocking of a G / L account.
SAP Master Data Governance provides a central place to maintain master data used in
finance processes and provides consistent data throughout the enterprise.
o Reduce maintenance efforts with high Data quality
o Delivers Consistent Definition, Authorizations and replication of key master data

entities for SAP
o Re use of SAP Data Model, UI and Existing business logic and configuration for
creation and validation of
o Master Data
o Eliminates error prone manual maintenance across multiple systems
o Enables governance, compliance and transparency through integrated staging,

approval and central audit trail.
o Trusted Data Quality Information

o One source of truth
o Flexible and unified view of all information
o Data flow transparency

Standard process flow for creating and administering a G / L account
Derived from this, the business flow results in the MDG-F Best Practices concept
The standard process flow in MDG-F consists of three core activities:
1. Business Activities
Create G/L Account

Process G/L Account
Display G/L Account
2. Change Request Types
Create Contract Account

Change Contract Account
3. Standard Workflow
Two-step workflow for four-eyes-principle

Implemented via Rules-based Workflow
Simplified, this business process is as follows:

Based on this process, the mapping takes place in the workflow.
2.2 High level Process Definitions
2.2.1 Process flow - Single Creation of G/L Account and Cost Objects
If the G/L Account is Profit & Loss Account, then a corresponding Primary Cost Element
would be automatically created in the CO module with mirror/same information from the G/L
along with some additional information.
Hence once the “Account Type” Attribute / field in the CoA related data section is selected as
– “Primary Costs or Revenue” from the drop down of values, then some additional
information like Controlling Area, Cost Element category needs to be filled in the same MDG
CR in a separate UIBB (UI Section of the MDG G/L creation form) which is related to the
Primary Cost Element and the corresponding Primary Cost Element will be created once this
MDG request is activated.

The Secondary Cost Element creation with S/4HANA Simple Finance & SAP MDG is
simplified and integrated with creation of the G/L account just like the Primary Cost Element.
Hence Secondary Cost Objects will also be created in the same G/L account creation
process as described above and the Account Type field value in the Chart of Account related
data section is selected as – “Secondary Costs” from the drop down.
Once this above value is selected, the exact same Workflow process for G/L account creation
will be developed & once the MDG CR is activated & MDG workflow process is completed the
Corresponding Secondary Cost Element will also be created in the S/4HANA Core System
available for business transactions.
The requester role of “MDG_GL_Corporate Accounting” will belong to the Local Accounting
departments and the primary Responsibilities and Segregation of duties are given below:
• Initiating / triggering the SAP MDG “Change Request (CR)” for Creation of G/L
Account and Cost element (as required)
• Attaching the relevant business justification document for this G/L creation with the
MDG CR explaining the reason & background of this request
• Filling in all the relevant information related to Chart of Accounts & Company Code
Once the “Account Type” Attribute / field in the CoA related data section is selected as
– “Primary Costs or Revenue” from the drop down of values, then some additional
information like Controlling Area, Cost Element category (below is the screenshot of
the same) needs to be filled in the same MDG CR in a separate UIBB (UI Section of
the MDG G/L creation form) which is related to the Primary Cost Element and the
corresponding Primary Cost Element will be created once this MDG request is
activated.
• Then the MDG CR is submitted for the next step of the governance workflow process
The next role in the G/L account governance process is the “MDG_GL_Data Steward” and
the primary Responsibilities and Segregation of duties are given below:
• Validating the information in the MDG CR for new creation of G/L account & cost
element
• Either Approve the MDG CR & send the workflow to the next step of the governance
workflow process or reject the MDG CR & send it back to the Requester for revision &
resubmission. This can be done using proper “Notes” functionality of MDG CR.
The next & final role in the G/L account governance process is the “MDG_GL_Account Gate
Keeper” and the primary Responsibilities and Segregation of duties are given below:
• Validating the overall complete information provided in the MDG CR for the new G/L
creation
• Applying the 4 Eye MDM principle, this role would only have “Read / View”
authorization of all the information in the MDG Cr and would not be able to “Edit” any
information

• Either Approve – “Activate” the MDG CR & & thus completing the Governance process
in MDG & creating the G/L Account Master Data Record in Corporate S/4HANA
System or reject the MDG CR & send it back to the for revision & resubmission. This
can be done using proper “Notes” functionality of MDG CR.
Once the MDG CR is activated, the G/L account master data is created in the S/4HANA
Corporate system and is available for all business transactions & reporting’s.
With the activation of the MDG CR, if the G/L account is a P&L account then, the
corresponding Primary Cost Element Master Data Record will also be created in the CO
module of the S/4HANA System.
In all cases of the MDG Governance workflow process, automated email notifications with
direct link to the MDG CR is triggered to all the Approvers in the forward flow and to the
requester roles in case of the rejections / sent for Revision scenarios.
When new Financial Master Data has been added, or changes made, the activation date for
the changes needs to take account of the reporting periods within Finance (to ensure
financial comparisons are meaningful and to comply with legislation where necessary).
It is recommended, as a general business rule, that changes (approvals) to financial master

data should not take place after the cut-off date in the month, to ensure all follow-on
processes have good enough time to be processed.

2.2.2 Process Flow Diagram
The process flow diagram is given below:

2.2.3 Process flow – Single Blocking / Unblocking of G/L Account
As per SAP Standard, G/L Accounts can be blocked in 2 different ways and SAP MDG with
S/4HANA follows the exact same process. G/L Accounts master record can be blocked at 2
levels and they are:
• At the Chart of Accounts Level, if a G/L account is blocked at CoA level, then the block
will be applicable for all Company Codes present in that CoA. This blocking will block
the G/L for both “Postings” and “Account Planning”
• At the Individual Company Code Level, G/L Account Master data records can be
blocked at individual Company Code Level which is applicable for specific Company
Codes. This blocks the G/L account only from a “Postings” perspective
The Unblocking of G/L accounts are also done exactly in the same scenarios described
above in the blocking.

The SAP MDG based Governance Process for blocking / unblocking of G/L Accounts will be
a 2 Step Business process flow as described below:
• The role of “MDG_GL_Corporate & Local Accounting” would take the business
decision to block / unblock a GL account and would trigger a MDG CR for the same
by “ticking the Checkbox for Blocking / removing the tick in checkbox for Unblocking”
for the G/L account as per the 2 different processes of blocking described above
• The next & final role in the Governance process is the team with the Business role of
“MDG_GL_Data Steward” who would finally validate the request and once this role
activates this Blocking / Unblocking MDG CR, the G/L Account will be blocked /
Unblocked in the Corporate S/4HANA system
Once this above described process is completed, the G/L account master data record will be
blocked in the CoA level or Company Code level for Postings & Account Planning as per the
block performed.
2.2.4 Process Flow Diagram
The Process flow diagram for this process is given below:

2.2.5 Description of the MDG-F application process using an example
In the following example we have the following functions
Requestor or business user

MD Steward
Approver or Global MD council











3 Technical description and presentation of the settings

of MDG-F
3.1 Data Model creation 0G
In this Customizing activity, you define and activate a data model to map master data in the
system, along with its properties and relationships. The system uses this data model to
generate database tables in which the master data can be stored.
You can assign a reuse active area to a data model or to individual entity types of a data
model. The inactive part of the master data is stored in the generated tables, and the active
part is stored in the database tables.
By default, the system displays all data models that are available for processing. For each
data model you can see whether an active version of the data model exists and whether that
version differs from the version of the data model that is displayed in the processing view.
3.2 SAP Best Practices Standard settings

The following data models are available:
• 0G for FINANCE
You can use the delivered data model itself or use it as a copy template for your own data
model.
The following standard SAP model is used in the standard implementation

• MM for Material
You can use the delivered data model. SAP does not recommend to use it as a copy
template for your own data model as the copied model requires extensive rework before
activation.
• BP for Business Partner
You can use the delivered data model itself or use it as a copy template for your own data
model.

SAP MDG for Finance provides central maintenance and governance for the following
financial master data
Table Name Description

Chart of Account (CoA) SKA1 , SKAT CoA
G/L account SKB1 G/L account
Company T880 Company
Company T011 Financial Reporting
Structure(Root + Hierarchy)
Profitcenter CSKS + CSKT CostCenter + Texts
CSKA + CSKB CostElements
CC & PC ; Assignments to CEPC + CEPCT +CEPC_BUKRS Profit Center + Texts +
Company Codes Assignments to Company
Codes
Internal Order AUFK+ JEST InternalOrder
Accounting
Entity types of the accounting area relate to Description

common SAP ECC objects:
MDG Entity Type
Chart of Accounts (ACCOUNT) Reflects the so called “A-Segment” of the

SAP ECC Account (tables SKA1 and SKAT).
It is the chart of accounts dependent data of
an account.
G/L Account in Company Code Reflects the so called B-Segment of the SAP
(ACCCCDET) ECC Account (table SKB1). It is the company
code dependent data of an account.
Entity types ACCOUNT and ACCCCDET are usually combined within MDG-F to the term G/L
Account.
Company (COMPANY) Reflects the SAP ECC Company customizing
(table T880).
Financial Reporting Structure Reflects the SAP ECC Financial Statement
(FRS) Version / Financial Reporting Structure
(table T011).
FRS Item Reflects the SAP ECC Financial Statement
(FRSI) Version / Financial Reporting Structure
Items (tables FAGL_011*).
Entity types FRS and FRSI are usually combined within MDG-F to the term Financial Reporting
Structure. The financial reporting structure supports the creation of a hierarchy, too. You can
assign accounts to this hierarchy.


Entity types FRS and FRSI are usually combined within MDG-F to the term Financial Reporting
Structure. The financial reporting structure supports the creation of a hierarchy, too. You can
assign accounts to this hierarchy.
Controlling
Entity types of the controlling area

relate to common SAP S/4HANA
objects:
MDG Entity Type Description
Cost Center (CCTR) Reflects the SAP ECC Cost Center (tables CSKS
and CSKT).
Cost Center Group (CCTRG) Reflect the SAP ECC Cost Center Group
Cost Center Group Hierarchy (CCTRH) Hierarchy. In MDG-F the entity Cost Center
Group Hierarchy defines the root node of the
hierarchy. Both entities are required to build the full
hierarchy. Cost Centers are added as leafs.
Cost Element (CELEM) Reflects the SAP ECC Cost Element (tables
CSKA, CSKB, and CSKU). In MDG-F a Cost
Element does not differentiate between common
and controlling area dependent data as done in
SAP ECC.
Cost Element Group (CELEMG) Reflect the Cost Element Group Hierarchy. In
Cost Element Group Hierarchy (CELEMH) MDG-F the entity Cost Element Group Hierarchy
defines the root node of the hierarchy. Both entities
are required to build the full hierarchy. Cost
Elements are added as leafs.
Profit Center (PCTR) Reflects the SAP ECC Profit Center (tables CEPC,
CEPC_BUKRS and CEPCT).
Profit Center Group (PCTRG) Reflect the Profit Center Group Hierarchy. In
Profit Center Group Hierarchy (PCTRH) MDG-F the entity Profit Center Group Hierarchy
defines the root node of the hierarchy. Both entities
are required to build the full hierarchy. Profit
Centers are added as leafs.
Internal Order (IORDER) Reflects the SAP ECC Internal Order (tables
AUFK).
Here we worked with the SAP standard.

3.3 Customizing setting

3.4 UI-Modelling
In this Customizing activity, we can specify whether the system hides the entity types for a
selected data model
Here we worked with the SAP standard.

3.5 Search Application settings

In this Customizing activity, you define the search providers available for the different types of
search used in Master Data Governance (MDG). The available search applications are:
• Address Search (BAS)
• Database Search
• Enterprise Search
• Remote Key Search
• SAP HANA Search
The following settings were made here
3.6 Duplicate Check settings
In this Customizing activity, you configure the duplicate check for an entity type. Based on the
data model (here 0G), you define which search mode the system should use and which
thresholds (percentages) to apply.
When selecting the percentages for the low threshold and high threshold, note the following:
• Records that have a matching score lower than the low threshold are not considered
duplicates
• Records that have a matching score greater than the low threshold are considered
potential duplicates

• Records that have a matching score greater than or equal to the high threshold are
considered to be identical. These records can still be created, but the user will receive
an additional warning message that they are creating a potential duplicate.
3.7 Process modelling
In this Customizing activity, you define the following properties, which are valid for all editions
with the same type:
• You define the data model for which the edition type is valid. You can only assign an
entity type to one edition type.
• You define whether an edition is valid for one or more periods or for a date-specific
time period.
• You specify which entity types can be edited within the editions of the new edition
type.

3.8 Create Business Activity
In this Customizing activity, you can create your own business activity and assign it to a
data model for cases in which you want to process your own entity type or entity types for
which no business activity is delivered by SAP Standard Best Practices.
If you use the data model BP, the business activities are already defined and assigned to the
data model. When processing the entity types that exist in this data model, we strongly
recommend using only the activities delivered by SAP Standard Best Practices If you use the
data model MM, the business activities are already defined and assigned to the data model.
When processing the entity types that exist in this data model, we strongly recommend using
only the activities delivered by SAP Standard Best Practices You can assign business
activities to a change request type using the client-dependent Customizing activity Create
Change Request Type.
In the case here we have used SAP Standard Best Practices


3.9 Replication model
3.9.1 Creation of Repication Models
In the present case, the following DATA REPLICATION MODELS was created, for FINANCE >> MDG-F with
the Data Model 0G
3.10 Change requests
In this activity, you define which statuses the change requests can have and which
processing options are enabled for each of those statuses.
Standard settings
The standard delivery contains the following statuses:
00 To Be Evaluated
01 To Be Considered and Approved
02 Changes to Be Executed

03 To Be Revised
04 Final Check to Be Performed
05 Final Check Approved
06 Final Check Rejected
07 Activation Failed
08 Approved, to Be Replicated
09 Dependent Data to Be Processed/Approved
10 To Revise: Perform Changes
11 Process Errors After Activation
12 Approved, Contact Person to Be Processed
99 No Status Set
The statuses Final Check Approved and Final Check Rejected have the meaning that a
change request is finalized and cannot be changed any more.
Any other status has the meaning that a change request is still open for processing. This
applies also to all statuses you add additionally.

3.11 Type of change requests

In this Customizing activity, you create one or more types of change requests and assign
entity types to them. You can define the following properties for a particular change request
type
For standard changes, you use a change request type in which the object list is defined prior
to processing. You create a change request type, set the Objects Required indicator, and
assign all entity types to the change request type.
For mass changes, you use a different type of change request in which the object list is not
required. You create another change request type, do not set the Objects Required indicator,
and assign all entity types to that change request type.
Within the framework of the project the following CR types will be applied
ACC1P1 0G_ALL Create Account
ACC1P2 0G_ALL Create Account with Hry. Assignments
ACC2P1 0G_ALL Process Account
ACC2P2 0G_ALL Process Account with Hry. Assignments
ACC5P1 0G_ALL Block/Unblock Account
ACC6P1 0G_ALL Mark Account for Deletion
ACCAP1 0G_ALL Mass Change Account
ACCLP1 0G_ALL Account Initial Load
ACCXP1 0G_ALL Delete Account
CCC1P1 0G_ALL Create Consolidation Characteristics
CCC2P1 0G_ALL Process Consolidation Characteristics
CCCAP1 0G_ALL Mass Change Consolidation Characteristic
CCCXP1 0G_ALL Delete Consolidation Characteristics

CCG1P1 0G_ALL Create Cost Center Group

CCG1P2 0G_ALL Create CCTR Group with Hry. Assignments
CCG2P1 0G_ALL Process Cost Center Group
CCG2P2 0G_ALL Process CCTR Group w. Hry. Assignments
CCGAP1 0G_ALL Mass Change Cost Center Group
CCGHP1 0G_ALL Process Cost Center Group Hierarchies
CCGXP1 0G_ALL Delete Cost Center Group
CCH1P1 0G_ALL Create Cost Center Group Hierarchy
CCH2P1 0G_ALL Process Cost Center Group Hierarchy
CCHAP1 0G_ALL Mass Change Cost Center Group Hierarchy
CCHXP1 0G_ALL Delete Cost Center Group Hierarchy
CCT1P1 0G_ALL Create Cost Center
CCTAP1 0G_ALL Mass Change Cost Center
CCTFP1 0G_ALL Create Cost Center (SAP Fiori)
CCTLP1 0G_ALL Cost Center Initial Load
CCTXP1 0G_ALL Delete Cost Center
CEG1P1 0G_ALL Create Cost Element Group
CEG1P2 0G_ALL Create CELEM Group w. Hry. Assignments
CEG2P1 0G_ALL Process Cost Element Group
CEG2P2 0G_ALL Process CELEM Group w. Hry. Assignments
CEGAP1 0G_ALL Mass Change Cost Element Group
CEGHP1 0G_ALL Process Cost Element Group Hierarchies
CEGXP1 0G_ALL Delete Cost Element Group
CEH1P1 0G_ALL Create Cost Element Group Hierarchy
CEH2P1 0G_ALL Process Cost Element Group Hierarchy
CEHAP1 0G_ALL Mass Change Cost Element Group Hierarchy
CEHXP1 0G_ALL Delete Cost Element Group Hierarchy
CEL1P1 0G_ALL Create Cost Element
CEL1P2 0G_ALL Create Cost Element w. Hry. Assignments
CEL2P1 0G_ALL Process Cost Element

3.12 Configuring ALE for Master Data Governance for Financials
This part describes the configuration steps that are required to enable the exchange of financial data using
Application Link Enabling (ALE) for MDG-F.
3.12.1 Prerequisites
Set Up RFC Connections
Set up RFC connections in the MDG hub and MDG target systems:
Run transaction SM59 (configuration of RFC connections), and provide the required RFC
destination details.
1. Define the logical systems in Customizing for SAP NetWeaver. Run transaction SALE,
and choose Basic Settings Logical Systems Define Logical System . Enter all
target systems as logical systems.
2. Run transaction SALE, and assign the logical system to a client under Basic
Settings Logical Systems Assign Logical System to Client .
3. Define Global Company Codes
If the company code is required for your data, you must define the global organizational units
for company code. Run this activity in Customizing for SAP NetWeaver under Application
Server IDoc Interface/Application Link Enabling (ALE) Modelling and Implementing
Business Processes Global Organizational Units Cross-System Company Codes . Create
cross-system company codes and map all company codes in use to the defined global
company codes.
3.12.2 Define Global Business Areas
If the business area is required for your data, you must define the global organizational units
for business areas. Run this activity in Customizing for SAP NetWeaver under Application
Server IDoc Interface/Application Link Enabling (ALE) Modelling and Implementing
Business Processes Global Organizational Units Cross-System Business Areas . Create

cross-system business areas and map all business areas in use to the defined global
business areas.
3.12.3 Procedure
The following steps are required to configure ALE for MDG-F (transaction SALE) in the MDG
hub and MDG target system.
3.12.3.1 Create a Distribution Model
To create a new distribution model in the MDG hub, carry out the following steps in both
systems:
1. Run transaction SALE (Display ALE Customizing), and choose Modelling and
Implementing Business Processes Maintain Distribution Model and Distribute
Views . Alternatively, run transaction BD64 (Display Distribution Model).
2. In editing mode, create a new model. Choose Create Model View. Enter a short text
and a technical name.
3. Choose Add Message Type for the newly created model. Enter the logical sender
system and receiver system, and add a message type from the following table. Repeat
this step for all required IDoc message types.
IDoc Message Type Description
GLMAST Master data G/L accounts (Master IDoc)
COSMAS Master cost center
COGRP1 Cost center groups

COELEM Cost element master data
COGRP2 Cost element groups
PRCMAS Profit center master record
COGRP6 Profit center groups
For Internal Order, choose Add BAPI, and make the following entries:
1. Obj. name/interface: InternalOrder

2. Method: SaveReplica.
3. Save your entries.
4. After you have saved your settings, you need to generate a partner profile.
Choose Environment Generate Partner Profiles . Select the model view you just have
saved and enter the target system. Select immediate processing for the output mode and
inbound parameter. Choose the Execute button.
1. After you have generated the necessary partner profile, choose Edit Model
view Distribute to distribute this model view to your target system.
2. Enter the target system, and repeat step 4 to generate partner profiles on the MDG
client.

Enhance Distribution Model for Confirmation Message
The configured distribution model needs to be enhanced to send a confirmation message

back from the target client to the client of the MDG hub:
Enter the client of the MDG hub and call transaction SALE.
Goto Modelling and Implementing Business Processes Maintain Distribution Model and
Distribute Views . Select the distribution model you have generated previously.
1. Select Environment: Change Partner Profile from the dropdown list.

2. Open Partner Type LS, and select the profile of the target system.
3. Choose the Create inbound parameter button.
4. Chose the message type ALEAUD and enter the process code AUD2. Save your
entries.
In the client of the target system, the distribution model also needs to be enhanced:
1. Enter the client of the target system and call transaction SALE.
2. Goto Communication Maintain Distribution Model and Distribute Views . Select the
distribution model you have generated previously.
4. Open Partner Type LS and select the profile of the source system.
5. Choose the Create outbound parameter button.
6. Chose the message type ALEAUD, select the receiver port from the selection list, and
enter the value ALEAUD01 as the basic type.
7. Select Transfer Idoc Immed. as the output mode and save your entries.
8. Define Business Systems
In the client of the MDG hub, a business system for the target client needs to be created as
follows:
1. Call transaction MDGIMG.

2. Goto General Settings Data Replication Define Custom Settings for Data
Replication Define Technical Settings Define Technical Settings for Business
Systems .

3. Choose the New Entries button.

4. Enter the business system, logical system, and RFC destination for the target client.
5. Select the line of the newly defined business system and select the folder Define Bus.
Systems, Bos. Enter all desired business object types:
Business Object Type Description
158 Cost Center
229 Profit Center
892 General Ledger Account Master
983 Cost Element
984 Cost Element Group
895 Cost Center Group
896 Profit Center Group

DRF_0019 Internal Order
6 Select each business object type, and choose the folder Define Bus. Systems,
BOs, Communication Channel. Choose the New Entries button, and select the
communication channel 2 Replication via IDoc. Repeat this for all defined
business object types.
7 Save your entries.
3.12.3.2 Create Replication Models
Once the distribution model and the business system are defined in the client of the MDG
hub, it is possible to create a replication model for each IDoc type:
1 Call transaction MDGIMG.

2 Goto General Settings Data Replication Define Custom Settings for Data
Replication Define Replication Models .
3 Choose the New Entries button, and define a replication model with name, description,
and data model 0G for each IDoc type listed.
For each defined replication model, select the line of the replication model, and select the
folder Assign Outbound Implementation. Choose the pushbutton New Entries. Assign the
corresponding outbound implementation to each replication model you have defined:

Outbound Implementation Description
1012 General Ledger Account Master IDoc
1102 Cost Centre IDoc
1112 Cost Centre Group Hierarchy IDoc
1182 Cost Element IDoc
1192 Cost Element Group Hierarchy IDoc
1122 Profit Centre IDoc
1132 Profit Centre Group Hierarchy IDoc
1200 MDG-F Internal Order IDoc

of the implementation, and select the folder Assign Target Systems for Repl. Model
/Outb.Impl. Choose the New Entries button. Assign the business system with the ERP client
of the target system.
4 Save your entries
3.12.3.3 Activate Replication Models
Activate the previously defined replication models as follows:
1 Call transaction MDGIMG.

2 Goto General Settings Data Replication Define Custom Settings for Data
Replication Define Replication Models .
3 In the table of replication models, select all replication models you have previously
defined.
4 Choose the Activate button, and check the log for error messages. Successful
activation is indicated with a checkmark in the Active column.
5 Check the log and make sure that all selected replication models have been activated
successfully.

3.13 Settings for Data Replication
The purpose of this part is to describe the configuration steps required to manually set up
Master Data Governance for Financial Master Data Management . The scope of this
document is limited to setting up the Data Replication Framework for MDG Financials-GL
Account.
1. MDGIMG Configuration Process

2. Set Up Data Replication to a ABAP System
3.13.1 Set Up Data Replication
3.13.1.1 Set Up ALE Configurations
Create RFC connection in MDG hub (hub to client) and in client systems (client to hub)
1. Access the transaction using the following transaction code:
Transaction Code SM59
2. Choose ABAP connections and choose Create Icon to create a new RFC connection
3. Enter the RFC Destination Name.
4. Choose Technical Settings Tab and enter Target Host, System Number, and Host Name
or IP Address
5. Choose Logon and Security tab and enter Client, User Name, and password

3.13.1.2 Define logical systems for all target systems in MDG hub.
Transaction Code SALE
2. Execute the activity under Basic Settings → Logical Systems → Define Logical System
3. Check or create a new entry for the logical system
4. Execute the activity under Basic Settings → Logical Systems → Assign Logical
System to Client.
5. Check or create a new entry for the logical system client
3.13.1.3 Create Global company code for ALE

Transaction Code SALE
2. Execute the activity under Modeling and Implementing Business Processes → Global
Organization Units → Cross-System Company Codes
3. Double-click Cross-System Company Codes

4. Check or create a new entry for the Global Company Code
5. After creating Global Company codes, double-click Assign Company Code to Cross-
System Company Codes.
6. Check or assign the global company code to the Company Code
3.13.1.4 Create Distribution Model

Transaction Code BD64
2. Choose Create Model View and enter Short text and Technical Name of the Model
view
3. Choose the newly created Model View and choose Add Message Type
4. Select the Model View, Logical Source system as Sender, Logical Target system as
Receiver and choose required Message Type. Repeat this step for all required IDoc
message types
GLMAST Master data G/L accounts (Master IDoc)
3.13.1.5 Generate Partner Profile
2. Select the Model View created in the previous step and Target system as the Partner
System and click execute.
3. Enter the ALE-User and the following values in the corresponding fields, and execute.
Field Value
Version 3
Pack Size 100
Output Mode Transfer IDoc immediately
Inb. Parameters: Processing Trigger immediately
4. To verify your settings, run transaction WE20 and from the Partner Profiles menu,
choose Partner type LS. Verify that Partner type LS is the logical destination system.
5. In the detail screen, the chosen message types GLMAST must appear as outbound
parameters.

3.13.1.6 Distribute the Model
2. In the Menu, Choose Edit → Model View → Distribute.
3. Select the Model View created in the previous steps and choose Ok
4. Verify within the receiving system that the model view was created.
5. In the remote system, run transaction SALE and choose “Modeling and Implementing
Business Processes → Partner Profiles → Generate Partner Profiles”. Alternatively,
run transaction BD82.
6. Select the distributed model and the partner system.
7. Enter the ALE-User and the following values in the corresponding fields, and execute.
Field Value
Version 3
Pack Size 100
Output Mode Transfer IDoc immediately
Inb. Parameters: Processing Trigger immediately
8. To verify your settings, run transaction WE20 and from the partner profiles menu,
choose partner type LS. Verify that partner type LS is the logical destination system.
9. In the detail screen, the chosen message types GLMAST must appear as inbound
parameters.
The Data Replication set up for MDG-F is completed .

3.13.2 Set Up DRF Configurations
3.13.2.1 Define Business System
Transaction Code MDGIMG
2. Run the Customizing activity in the Customizing for Master Data Governance under
“General Settings → Data Replication → Define Custom Settings for Data Replication
→ Define Technical Settings → Define Technical Settings for Business Systems”
3. Choose New Entries to create a new Business System. Enter Business System Name
select the Logical system and RFC destinations for the target system.
4. Mark the Business System and choose Define Bus. Systems, BOs
5. Enter the respective BO Types (Financials) as in the below table
892 General Ledger Account Master
6. Mark each business object type and choose the folder Define Bus. Systems, BOs,
Communication Channel. Choose the pushbutton New Entries and select the
communication channel 2 Replication via IDoc. Repeat this for all defined business
object types.
7. Save your entries.
3.13.2.2 Define replication model
1. Run the Customizing activity in the Customizing for Master Data Governance under
“General Settings → Data Replication → Define Custom Settings for Data Replication
→ Define Replication Models”

2. Choose New Entries and enter the Name of the Replication Model, Description, and
0G as Data Model
3. Mark the line and choose Assign Outbound Implementation. Create a new entry and
enter the following values using the input help:
o Outbound Implementation: 1012 General Ledger Account Master IDoc
o Communication Channel: Replication via IDoc
o Filter time: Filter After Change Analysis
4. Mark the line and choose Assign Target Systems for Repl. Model/Outb.Impl. Create a
new entry and enter the business system name for the receiving system created in the
step before.
5. Choose Save to save your entries.
6. Mark the newly created replication model, and choose Activate.
3.13.2.3 Enable monitoring of IDoc posting (ALE Audit)
The configured distribution model needs to be enhanced to send a confirmation message

back from the target client to the client of the MDG hub, as follows:
1. Enter the client of the MDG hub and call transaction SALE.
2. Go to “Modelling and Implementing Business Processes → Maintain Distribution Model
and Distribute Views”. Mark the distribution model you have generated previously.
4. Open Partner Type LS and select the profile of the target system.
5. Choose the pushbutton Create inbound parameter.
6. Choose the message type ALEAUD and enter the process code AUD2.Save your
entries.
In the client of the target system, the distribution model also needs to be enhanced, as
follows:

1. Enter the client of the target system and call transaction SALE.
2. Go to “Modelling and Implementing Business Processes → Maintain Distribution Model
and Distribute Views”. Mark the distribution model you have generated previously.
4. Open Partner Type LS and select the profile of the source system.
5. Choose the pushbutton Create outbound parameter.
6. Choose the message type ALEAUD, select the receiver port from the selection list,
and enter the value ALEAUD01 as the basic type.
7. Select Transfer IDoc Immed. as the output mode and save your entries.
8. To configure the replication of audit documents open transaction SALE and choose
“System Monitoring → IDoc Confirmation in Receiving System (ALE Audit) →
Confirmation of Audit Data → Define Variant“.
9. You can schedule the report RBDSTATE as a background job to run on a regular
base. Use transaction SM36.

3.13.2.4 Technical settings for Business Systems
In this part is created the connecting BUSINESS SYSTEM .
3.13.2.5 Landscape example
In the case we are working with

XCF (Sender System)
with following receiver SYSTEM:
• DCFCLNT030
• U03090
• XR1CL010
• X0RCLNT010

3.13.3 Definition Business Systems, Bos
Doubleclick on

3.13.4 Define Replication Models
Doubleclick on
Doubleclick on

Here is the next step fort he creation oft he Business System
Doubleclick on ASSIGN Outbound Parameter
For all the business system we have the same parameter >> SEND_DELTA_INFO

3.13.5 Setting example for GL account master

3.14 ALE / IDOC Settings
3.14.1 Creation of Partner profiles
Outbound parameter in XCF
• COSMAS > Master cost center

• COELEM > Cost element master data
• COGRP1 > Cost center groups
• COGRP2 > Cost element groups
• COGRP2 > Cost element groups
• COGRP6 > Profit center groups
Settings sender system profiles message type „GLMAST“

3.14.2 Outbound parameters in XCF

3.14.3 Inbound parameters in XCF
3.14.4 Partner Profiles in receiver system XR1CL010


3.14.5 Distribution Model creation of partner system
In the distribution model you have to define a message flow for the message type ALEAUD.
As the filter object value specify the message type for which the audit confirmation is to be
created.
If you do not specify a filter object value, all the IDocs are confirmed with the receiver
ALEAUD.
A distribution model is used to describe the ALE message flow between logical systems.
Business objects are distributed to connected recipients according to a unique distribution
model that can contain rules of varying complexity depending on the type of business objects
involved.
3.14.6 Defining a Distribution Model
To define a distribution model:

1. Run the bd64 transaction.

3.14.7 Example with System DCF & U0309
3.14.8 Example with System DCFCLNT030
3.15 Creation of global company code
Here are two steps necessary
1. Settings with OB72


2. Settings with OBB5
Here, company code is assigned to global company code

3.16 Workflow
SAP MDG core features:
SAP Master Data Governance comes with standard workflow scenarios to cover typical client
processes and organizational requirements. More complex process configurations can be
developed within the SAP standard workflow development framework.
In this Customizing activity you activate the Event Type Linkage for the Events of the Object
Type BUS2250 (MDG Change Request).
3.16.1 Activities
1. Add an entry for the Object Type BUS2250 and the Event CREATED. Leave the field
Receiver Type empty. The system determines the receiver type at runtime using a
function module. Therefore, enter the following parameters in the Linkage Setting group
frame:
3.16.2 Define Change Request Actions
In this Customizing activity, you define new actions for change requests. You can use this
screen to enter the action ID and action description. You can also enter the label and tooltip
for the pushbutton associated with the action if you use them in dialog processing. Actions
define the possible results of a change request step from a user decision in a dialog task or
from a workflow task background. For custom actions, you can determine if a check without

errors is required, if a note must be entered, and if a reason for rejection must be given to
proceed. You make this setting by selecting or deselecting the relevant checkbox (Check,
Note and Reason).
We deliver the following standard actions:
Action Description
1 Agree
2 Disagree
3 Approve
4 Reject
5 Finalize Processing
6 Send for Revision
7 Resubmit
8 Withdraw
9 Activate
10 Send for Revision
21 Successfully Executed
Successfully Executed with
22
Warning
23 Failed
31 Activation Successfull
32 Activation Failed
Activation Failed for
33
Snapshot
You assign the actions to change request step types that are then used to control the visibility
of pushbuttons on the UIs displayed during the workflow process for dialog tasks. You can
use the Customizing activity Define Change Request Step Types and Assign Actions
under Master Data Governance -> General Settings -> Process Modeling -> Workflow.to
assign actions to step types.
Once you have defined the new action and assigned it to a change request step type, you
have to define how the system will process the action. If you use rule-based workflow
templates, implement the BAdI definition USMD_SSW_SYSTEM_METHOD_CALLER or
launch a sub workflow. If you use a non-rule-based workflow template, use the workflow
builder (transaction SWDD) to copy and adapt the template.
When you select one of the actions during the processing of a change request in a dialog
task, the system will perform all the checks that are configured for the current change request
step. All checks need to be executed without errors before the current workflow work item is
completed.

SAP delivers the following actions for which the checks are not executed and therefore the
work item can be completed even if it contains data with errrors:
Action Description
02 Disagree
04 Reject
06 Send for Revision
08 Withdraw
3.16.3 Define Change Request Step Types and Assign Actions

In this Customizing activity, you define change request step types and assign actions to
them. You assign the change request step types to non-background workflow tasks where
the step types determine the visibility of buttons and the associated actions on the UI. You
can use the workflow builder to make these assignments for a non-rule-based workflow. You
can use BRFplus to make the assignments for a rule-based workflow.
In all change request step types the following special actions are always implicitly available:
• Save
The system executes all configured checks for the current change request step. The data
is saved independently of the result of these checks, even if errors occur.
• Check
The system executes all configured checks for the current change request step and
displays the messages of these checks.
Note: The actions Save and Check do not complete the current workflow work item.
We deliver the following standard change request step types:
Change Request Step Type Change Request Action

1 Check Change Request 01 Agree; 02 Disagree
2 Approve Change Request 03 Approve; 04 Reject
05 Finalize Processing; 06 Send for
3 Process Change Request
Revision
4 Revise Change Request 07 Resubmit; 08 Withdraw
5 Activate Change Request 09 Activate; 10 Send for Revision
6 Approve Change Request (Without
03 Approve; 06 Send for Revision
Rejection)
7 Revise Change Request (Without
05 Finalize Processing
Rejection)
8 Activate Change Request 04 Reject; 09 Activate
9 Enrich Change Request 05 Finalize Processing; 08 Withdraw
The change request action defines whether checks need to be executed without error before
the action can be performed. For more information, see the documentation of the
Customizing activity Define Change Request Actions under Master Data Governance ->
General Settings -> Process Modeling -> Workflow.

Example step 1

3.16.4 Rule based-Workflow
Three steps
3.16.5 Define Change Request steps for Rule-Based Workflow
In this Customizing activity, you define the change request steps to be executed in a rule-
based workflow for a particular change request type.
The steps you define are used in the Business Rule Framework plus (BRF+) tables when you
are setting up the workflow rules in the Configure Rule-Based Workflow Customizing
activity.
You have customized the change request and linked it to the rule-based workflow template
WS60800086 using the Create Change Request Type Customizing activity.

3.16.6 Configure Rule-Based Workflow
In this Customizing activity, you define the rules for the rule-based workflow. For each
change request type you can provide separate settings.
We have created the change request types for which you want to specify rules.
We have linked the change request type to the rule-based workflow template WS60800086
using the Create Change Request Type Customizing activity.
We have defined the change request steps used for this change request type workflow using
the Define Change Request Steps for Rule-Based Workflow Customizing activity.
In the case of a complex workflow scenario, for example, if there are special functions
required in the workflow, you must also have defined the service names for the BAdI
implementations that are to be used for this change request type workflow.
SAP Best Practices delivers Business Rule Framework plus (BRFplus) decision tables as
example content for each change request type.
Start screen in


3.16.6.1 Decision Table
Steps Status
Change of Object
0 Processing 00 To Be Evaluated List
Change of Object
90 Revision by MD specialist 01 To Be Considered and Approved List
Withdraw request and complete Execution of
92 workflow 02 Changes to Be Executed Changes
Change of Object
93 Revision by Approver 03 To Be Revised List
94 Activation 04 Final Check to Be Performed No Processing
95 Revision Processing by Requestor 05 Final Check Approved No Processing
96 Processing After Activation Error 06 Final Check Rejected No Processing
07 Activation Failed No Processing
08 Approved, to Be Replicated No Processing
Dependent Data to Be Execution of
09 Processed/Approved Changes
Execution of
10 To Revise: Perform Changes Changes
Execution of
11 Process Errors After Activation Changes
Approved, Contact Person to Be
12 Processed No Processing
13 In Business Partner Screening No Processing
99 No Status Set No Processing
DT_NON USER
Condition Alias Agent Group Process Pattern Service Name
=4 1 05
=6 1 99
=8 1 99
=10 1 08
=11 1 05
DT_USER
Condition Alias User Agt Grp No. Step Type User Agent Type User Agent Value
=1 1 2 SU INIT
=2 1 2 SU INIT
=3 1 4 SU INIT
=5 1 4 SU INIT
=7 1 5 SU INIT
=9 1 2 SU INIT
=12 1 4 SU INIT

DT_SINGLE
CR Previous Previous Parallel Agt Grp Condition New Chng. Req. New CR
Step Action No. Alias Step Status
=00 1 90 02
=90 =03 2 93 09
=90 =04 3 95 10
=93 =03 4 94 08
=93 =04 5 95 10
=94 =31 6 99 05
=94 <>31 7 96 11
=92 8 99 06
=95 =07 9 90 02
=95 =08 10 92 06
=96 =09 11 94 08
=96 =10 12 95 10
3.17 Workflow Description

This document provides a detailed procedure for testing the scope item. Each process step,
report, or item is covered in its own section, providing the system interactions (test steps) in a
table view. This document describes the activities / steps involved to execute and test the
following scenarios,
• Change request for GL Account (Chart of Account) with 2 Level and 3 Level Sequential
Approval process

3.17.1 Business Process Overview

The figure below provides an overview of the business process relating to workflow based on
Chart of Account with two or three sequential approvers.
3.17.2 Process Overview Table for Sequential Approval

The table below provides an overview of the process for sequential approval to Change
request to create or change a G/L Account (Chart of Account).
Test Instruction Busin Trans Expected Result

Step ess action
# Role Code
1. Log on to S/4HANA using User Name Requ SAP Easy Access screen is
and Password ester displayed
2. Launch NetWeaver
Call transaction NWBC (NetWeaver NWB Business Client screen
Business Client) C opens in a separate
window
3. Choose SAP Business Client for

SAP_MDGF_ACC_MENU_04 Accounting Governance

Test Instruction Busin Trans Expected Result

Step ess action
# Role Code
opens
4. A dialog box Opens to

Choose Create G/L Account Centrally choose Change Request
type and Edition Type
5. For change request for creating a new

G/L Account, enter the following:
Change Request Type: XXXX
Edition: Select a Valid Edition
Choose Ok
A screen for entering data

For change request for changing a appears
G/L Account, enter the following:
Change Request Type: XXXX
Edition: Select a Valid Edition
Choose Ok
6. Enter all the required and mandatory Change request is

data and choose Submit successfully submitted
7. Choose Change Requests in the side

A navigation menu opens
panel
8. Select My Change Request Under

My Change Requests is
Tree “Change Requests and
displayed in the main panel
Documents”
9. Select Created by Me from the Newly submitted change

dropdown list and click Go request is displayed
10. Screen displays the first

Select the respective change request
level approver of the work
and choose Workflow Log
item

3.17.3 Process Steps

3.17.3.1 Approval Process
If the Chart of Account is BKMG, two levels of approval are required. All approvers are
required to follow the below process sequentially:
Test Instruction Business Transac Expected Result

Step # Role tion
Code
11. Log on to ECC using User SAP Easy Access screen is

Approver
Name and Password displayed
12. Launch NetWeaver

Call transaction NWBC Business Client screen
NWBC
(NetWeaver Business Client) opens in a separate
window
13. SAP Business Client for

Select
Accounting Governance
SAP_MDGF_ACC_MENU_04
opens
14. Select My Change Request

Under tree Change Requests ->
Change Requests and POWL is displayed
Documents
15. Select To Be Processed By Me

New Change request is
From the dropdown and click
displayed in POWL table.
Go
16. Change request document

Double-click the change
is opened with Approve and
request
Reject buttons.
17. Choose Approve Approved successfully.
3.17.4 Validate G/L Account Data
Test Step # Instruction Business Transaction Code Expected Result

Role
18. Log on to ECC

using User
Name and
Password
Requester FSP0 FSP0 screen is displayed
Call transaction
Display G/L
Account Chart of
Account data

Test Step # Instruction Business Transaction Code Expected Result

Role
19. Enter G/L

Account and
Chart of G/L Account Chart of
Account then Account data is displayed
press Enter
Select all views
20. Review and

validate the Validation successful
material data

4 SAP MDG Finance Product Features an Best

Practices and Future Roadmap
4.1 Extensions and new features in MDG-F in Best Practices version
When requesting a new financial master data item, often the requesting user does not yet
know the number to be used in Business Suite Applications. To provide flexibility to the
requestor whilst adhering to corporate numbering standards, the single-object maintenance in
SAP MDG-F offers the feature to use a generated key first, and changing it to the desired
final number in a later step of the creation process.
1.1.1 Process Features
•Copy multiple company codes: create multiple company code-specific G/L accounts by
simple copying
•One-step creation of primary cost element: automatically create the primary cost element
connected to a new account in the same maintenance step

1.1.2 Master Data and Hierarchy Assignment in the same Main Financial
Objects UI
1.1.3 Usability Features in Single-Object Maintenance UI

1.1.4 Usability Features in Hierarchy Processing

1.1.5 Replications
MDG-F replicates the data according to the needs of the connected business systems. This
is independent of the deployment option, if MDG is used on top of one of the operational ERP
or S/4 systems, or as a standalone MDG data hub.
1.2 Editions

1.2.1 Workcenterper area: Accounting, Controlling, Consolidation
1.2.2 How to enter master data changes

1.2.3 Change request






1.2.4 Central Governance for Financial Data
Enhanced Hierarchy Processing

1.2.5 MDG-f Supporting Central Finance (SAP S/4HANA Finance)

5 A Configuring SAP for Inbound and Outbound

Processing
During inbound (client) processing, IDocs are transferred to the interface and stored in
the R/3 System. The document data is generated in a second step, also in the course of a
workflow. Outbound processing in SAP involves event handling. An event in SAP is
defined as an occurrence of a status change in an object. Events are created when the
relevant status change occurs. The following topics describe how to enable inbound and
outbound SAP processing.
• Configuring SAP Inbound Processing

• Configuring SAP Outbound Processing
5.1 Configuring SAP Inbound Processing
SAP inbound processing requires the upstream system to transfer an IDoc to the IDoc
interface through the R/3 System port. For this reason, you do not have to specify a port in
the inbound partner profiles; the IDoc interface only must recognize the upstream system as
a port. A port definition, which provides a unique ID for the upstream system, must be
available for the port. The technical parameters of this port definition can (and usually are)
overwritten by the upstream system.
If the upstream system is recognized, then the IDoc is saved in the database. If a partner is
defined with the corresponding message in partner profiles, the IDoc is then processed
further. This is done independently in the second step. This ensures that the external system
can receive the data quickly and reliably (automatically).
You must perform the following steps to configure SAP for inbound IDoc processing:
1. Configure a logical system.

2. Configure a distribution model.
3. Define an inbound partner profile.
5.2 Configuring a Logical System
In any distributed environment, each participating system must have a unique ID to avoid
confusion. In SAP, the name of the logical system is used as the unique ID. This name is
assigned explicitly to one client in an SAP system.

5.2.1 Defining a Logical System
To define a logical system:
1. Run the sale transaction.
Description of the illustration ale_saletransaction.gif
The Display IMG window is displayed.
Description of the illustration ale_inbound1.gif
Perform the following steps:
a. Expand Sending and Receiving Systems.

b. Expand Logical Systems.
c. Select Define Logical System.
2. Click the IMG - Activity icon.
A message window is displayed. It indicates that the table is cross-client.

Description of the illustration ale_imgmessage.gif
3. Click the check mark icon to continue.
The Change View "Logical Systems": Overview window is displayed.
Description of the illustration ale_inbound2a.gif
4. Click New Entries.
The New Entries: Overview of Added Entries window is displayed.

Description of the illustration ale_inbound4a.gif
5. Enter the Logical System, for example, ORACLETDS, in the Log.System column and
provide a description in the Name column.
6. Click Save.
The Prompt for Workbench request dialog box is displayed.
7. Click the Create Request icon.
The Create Request dialog box is displayed.

8. Enter a name and description for your request and click Save.
The logical system you configured, for example, ORACLETDS, is now added to the list.
Description of the illustration ale_logicalsysdisplay.gif
5.3 Configuring a Distribution Model
A distribution model is used to describe the ALE message flow between logical systems.
Business objects are distributed to connected recipients according to a unique distribution
model that can contain rules of varying complexity depending on the type of business objects
involved.
5.3.1 Defining a Distribution Model
To define a distribution model:
2. Run the bd64 transaction.
Description of the illustration ale_nbd64.gif

The Display Distribution Model window is displayed.
Description of the illustration ale_distmodel1.gif
3. Click Distribution Model from the menu bar.
4. Select Switch processing mode.
The Display Distribution Model window is switched to Change Distribution Model.

5. Click Create model view.
The Create Model View dialog box is displayed.
6. Enter a model view name in the Short text field and a name in the Technical name
field, which also serves as a description.
7. Click the check mark icon to enter the information.
You are returned to the main Change Distribution Model window. The distribution
model you configured is now added to the list.
8. Click Add message type.
The Add Message Type dialog box is displayed.

a. In the Sender and Receiver fields, enter the logical system you configured,
for example, ORACLETDS.
You can click the icon to the right of each field to browse from a list of logical
systems.
b. In the Message type field, enter the message type you want to use, for
example, MATMAS.
You can click the icon to the right of each field to browse from a list of available
message types.
9. Click the check mark icon to enter the information.
You are returned to the main Change Distribution Model window.
10. Click Save.
5.3.2 Defining a Partner Profile
Partner profiles are a prerequisite for data exchange. This involves defining who can
exchange messages with the SAP system and using which port.
5.3.2.1 Defining a Partner Profile
To define a partner profile:
1. Run the we20 transaction.
Description of the illustration ale_we20.gif
The Partner profiles window is displayed.

Description of the illustration ale_pprofile1.gif
2. In the left pane, expand Partner type LS and select the logical system you configured
from the list, for example, ORACLETDS.
In the right pane, the Partn.number field refers to the name of the logical system.

Description of the illustration ale_pprofile2.gif
3. Click Save.
4. From the Inbound parameters table, click the Create inbound parameter icon.
The Partner profiles: Inbound parameters window is displayed.

5. In the Message type field, enter the message type you want to use, for example,
MATMAS.
message types.
The Inbound options tab is selected by default.
6. In the Process code field, enter the process code you want to use, for example,
MATM.
process codes.
7. In the Processing by function module area, select one of the following options:
• Trigger by background program.
In this case the adapter writes IDocs to the SAP database, which is processed
immediately.

• Trigger immediately.
In this case, the adapter waits for the SAP system to process IDocs. This can
take anywhere from 1 to 15 minutes.
8. Click Save.

6 Configuring SAP Outbound Processing

Event creation must be implemented by you or by SAP. An event is created from specific
application programs (the event creator) and then published systemwide. Any number of
receivers can respond to the event with their own response mechanisms. An event is usually
defined as a component of an object type.
SAP pseudo events are not processed by the SAP Event manager, but are called from an
ABAP program or Remote Function Call (using the Destination parameter).
6.1 Related Concepts and Terminology
The following topic lists and defines specific terminology related to SAP and SAP event
handling.
6.2 Client and Server Programs
RFC programs for non-SAP systems can function as either the caller or the called program in
an RFC communication. There are two types of RFC programs:
• RFC Client
• RFC Server
The RFC client is the instance that calls the RFC to run the function that is provided by an
RFC server. The functions that can be called remotely are called RFC functions, and the
functions provided by the RFC API are called RFC calls.
SAP Gateway
The SAP Gateway is a secure application server. No connections are accepted unless they
have been preregistered previously from the SAP presentation Client. A server connection
presents itself to the Gateway and exposes a Program Identifier. If the Program Identifier is
found in the list of registered Program IDs, the Gateway server then offers a connection to
the server, which "Accepts" a connection. This ProgramID is then linked with an RFC
Destination within SAP, which enables SAP Function Modules and ALE documents (IDocs or
BAPI IDocs) to be routed to the destination. The RFC Destination functions as a tag to mask
the Program ID to SAP users.
An RFC server program can be registered with the SAP gateway and wait for incoming RFC
call requests. An RFC server program registers itself under a Program ID at an SAP gateway
and not for a specific SAP system.

In SAPGUI, the destination must be defined with transaction SM59, using connection type T
and Register Mode. Moreover, this entry must contain information on the SAP gateway at
which the RFC server program is registered.
6.3 Program IDs and Load Balancing
If the Gateway Server has a connection to a particular server instance and another server
instance presents itself to the gateway, then the gateway offers the connection and then
begins functioning in Load Balancing mode. Using a proprietary algorithm, the Gateway
sends different messages to each server depending on demand and total processing time.
This may cause unpredictable results when messages are validated by schema and
application.
When configuring multiple events in the Oracle Application Server using a single SAP
program ID, SAP load balances the event data. For example, if multiple remote function calls
or BAPIs use the same program ID (for example, ORACLETDS) and multiple SAP listeners are
configured with this progamID, then SAP sends one request to one listener and the next to
another listener, and so on.
There is a load-balancing algorithm present in the SAP Gateway Server. This mechanism is
proprietary to SAP application development and might work by comparing total throughput of
the connection, the number of times in wait state, and so on. This means one connection
might receive nine messages and a second connection might receive one message. If five of
the nine messages are rejected for schema validation and the one message on the other
connection is rejected for schema validation, you might suspect that you are missing SAP
event handling messages.
Load balancing in server (inbound to adapter from SAP) situations is handled by connecting
multiple instances of the adapter to the SAP system. The SAP system will then load balance
the connections. You cannot tune this performance.
Load balancing in client (outbound from adapter to SAP) situations is handled only by the
SAP application design. If your system supports a Message Server, then you can load balance
in client situations. If you have only one application server, you cannot load balance except
by application server tuning, such as maximum number of connections permitted or time of
day limits on connections.
The SAP system default limit is 100 RFC (communication) or adapter users. Each user takes
up more than 2 MB of memory on the application server of the SAP system, and more or less
on the adapter depending on the workload.
6.4 Connection Pooling
A connection pool is a set of client connections to a specific destination. The pool may
automatically create new connections to the specified remote system or return an already
existing connection. It also provides methods to return a connection back to the pool when it
is no longer needed.

A connection pool can check which connections are no longer in use and can be closed to
save system resources. The time period after which the pool checks the connections as well
as the time after which a connection will time out can be configured by the calling
application.
A pool is always bound to one user ID and password, meaning that all connections taken
from this pool will also use these credentials. An SAP connection is always bound to an SAP
user ID and an SAP Client number.
If you log on with a pool size that is set to 1, no connection pool is created (1 userid – 1
process thread). If you log on with a pool size that is greater than 1, a pool is created with a
size of n, which is the number you specified.
For more information about connection pooling, see the SAP JCO API documentation.
6.5 Registering Your Program ID in SAPGUI
To enable your SAP system to issue the following calls or interfaces to the SAP event
adapter, you must register your program ID under an RFC destination.
• Remote Function Calls (RFC)

• Business Application Programming Interfaces (BAPI)
• Intermediate Documents (IDoc)
The RFC destination is a symbolic name (for example, ORACLETDS) that is used to direct
events to a target system, masking the program ID. The Program ID is configured in both
SAPGUI and the event adapter.
6.6 Registering Your Program ID
To register your program ID:
1. Launch the SAP GUI and log in to the SAP system.

2. Select Tools, Administration, Network, and then RFC destination.
3. Run the SM59 transaction.
The Display and maintain RFC destinations window is displayed.

Description of the illustration iway_sapu_tcpipconnect.gif
4. Select TCP/IP connections and click Create.
The RFC Destination window is displayed.
Description of the illustration iway_sapu_rfcddestination.gif
Provide the following information:

a. In the RFC destination field, enter a name, for example, ORACLETDS.
The value you enter in this field is case sensitive.
b. In the Connection type field, enter T for destination type TCP/IP.

c. In the Description field, enter a brief description.
5. Click Save from the tool bar or select Save from the Destination menu.
The RFC Destination ORACLETDS window is displayed.
Description of the illustration iway_sapu_iwaydest.gif
a. For the Activation Type, click Registration.

b. In the Program field, enter ORACLETDS.
6. Click Save from the tool bar or select Save from the Destination menu.
7. Ensure your event adapter is running.
8. Verify that the SAP system and OracleAS Adapter for SAP are communicating.
9. Click TestConnection.
6.7 Testing the SAP Event Adapter
In the SAP Server, the SE37 transaction enables you to send an RFC (Remote Function Call)
or a BAPI (Business Application Programming Interface) to any RFC destination. For more
information on RFC destination, see Registering Your Program ID in SAPGUI.
6.8 Testing the SAP Event Adapter by Sending an RFC or a BAPI

Manually
To test the SAP event adapter:
1. In the Function Builder, select a function module, for example,

RFC_CUSTOMER_GET.
Description of the illustration iway_sapu_functionbuilder.gif
2. To choose single test, press F8 and click the Single Test icon or choose Function
module, select Test and then Single Test.
3. Enter an RFC target system, for example, ORACLETDS.
4. Enter input data for the particular RFC modules, for example, AB*.
5. To execute, press F8.
The Test Function Module: Initial Screen window is displayed.

Description of the illustration iway_sapu_testfunctionmod.gif
6. Enter data into the SAP GUI and click Execute.
The function name and input data are transferred through RFC to create an XML
document on the Oracle Application Server with the parameters input in SAPGUI.
6.9 Application Link Embedding Configuration for the Event Adapter
The SAP event adapter receives IDocs (Intermediate Documents) from SAP. To configure an
SAP system to send IDocs to the SAP event adapter, use the ALE (Application Link
Embedding) configuration to:
1. Register your program ID in SAPGUI.

2. Define a port.
3. Create a logical system.
4. Create a partner profile.
5. Create a distribution model for the partner and message type.
6. Test the SAP event adapter.
6.10 Defining a Port
A port identifies where to send messages. This port can be used only if an RFC destination
was created previously.
To establish an RFC connection in the IDoc adapter, proceed as follows:
1. 1. Choose Port Maintenance in the IDoc Adapter (Transaction IDX1).

On the left-hand side the system displays a list of ports that are already defined, for example
SAPABC_123, and a description.
2. 2. To create a port (an RFC connection) to the required system, choose Create ( ).
The system converts the display area on the right-hand side of the screen into an input area where you
can enter the specifications for the new port.
• ○ Enter the name of the port under Port.
For SAP systems this comprises the type and ID of the connected system, for example, SAPABC.
• ○ Enter the three-digit number of the client under Client.

• ○ Enter a brief description for the port under Description.
• ○ Under RFC Destination, enter the RFC destination of the connected system.
This comprises, for example, the system ID and the client, for example, ABC_123.
• ○ Enter the partner number and partner type of the receiver under Receiver of Status Messages.
The specifications for Port and Client correspond to the sender port and the client in the IDoc control
record.
The system places the entry alphabetically in the list of defined ports.
6.10.1 Steps of Defining a Port
To define a port:
1. In the ALE configuration, choose Tools, Business Communications, IDocs Basis,

IDoc, and then Port Definition.
You can also run the WE21 transaction.
The Creating a tRFC port window is displayed.

Description of the illustration iway_sapu_defineport.gif
2. In the left pane under Ports, select Transactional RFC and click Create.
3. Select Generate port name.
The system generates the port name.
4. Enter the IDoc version you want to send through this port.
5. Click the destination you created, for example, ORACLETDS.
6. Save the session, making note of the system-generated RFC port.
6.11 Creating a Logical System
One type of partner is a logical system. A logical system manages one or more RFC
destinations.
6.11.1 Creating a Logical System
To create a logical system called ORACLETDS:
1. In the ALE configuration, enter the area menu selection SALE transaction.
2. Select SAP Reference IMG.
3. Expand the following nodes: Basis Components, Application Link Enabling
(ALE), Sending and Receiving Systems, Logical Systems, and Define Logical
System.
4. Click the check mark beside Define Logical System.
The Change View "Logical Systems": Overview window displays a list of logical
systems and their names.

Description of the illustration iway_sapu_iwaylog.gif
5. Click New entries.
The New Entries: Overview of Added Entries window is displayed with Log.System and
Name columns for new log system.
Description of the illustration iway_sapu_newentries.gif
6. Type an entry for Log System, for example, ORACLETDS.

7. In the Name column, enter a name (description) for the partner profile.
8. Click Save to save the session.

6.12 Creating a Partner Profile
A partner profile is a definition of parameters for the electronic interchange of data with a
trading partner using the IDoc interface.To communicate with a partner using the IDoc
interface, you must create a partner profile.
6.12.1 Creating a Partner Profile
To create a partner profile:
1. In SAP GUI, choose Tools, Business Communication, IDoc Basis, and Partner
profile.
You can also run the WE21 transaction.
The Partner profiles: Outbound parameters window is displayed and shows fields for
specifying details for the partner profile.
Description of the illustration iway_sapu_partnerprofile.gif
a. Select Partner type LS (Logical system).

b. Press F5 (Create).
2. For Type, enter USER.
3. For Agent, enter the current user ID, or you may select another agent type.
4. Under the outbound parameter table control, select Create outbound parameter.

Partner type is LS, and the Message type is DEBMAS, which is the IDoc document
type.
5. Leave Partn.funct blank.

6. Click the Outbound options tab.
a. Depending on your performance requirements, click Transfer IDoc Immed or

Collect IDocs.
b. For the IDoc, enter a message type, for example, DEBMAS.
c. Enter a receiver port, for example, A000000036.
7. Click Save to save the session.
The Partner profiles summary window is displayed. It contains information for the
logical system that you created.
Description of the illustration iway_sapu_savedsession1.gif
6.13 Collected IDocs
When using collected IDocs on any platform during inbound processing (service mode), if the
DOCNUM field does not have a unique document number for each IDoc, the system creates
an IDoc for each header record in the collected IDoc file and duplicates the data for each
IDoc.
Make sure the DOCNUM field is included in the EDI_DC40 structure and that each IDoc has a
unique sequence number within the collected IDoc file.

6.14 Creating a Distribution Model for the Partner and Message Type
You must create a distribution model for the partner and message type you designated.
6.14.1 Creating a Distribution Model
To create a distribution model called ORAMOD:
1. In SAP GUI, choose Tools, AcceleratedSAP, Customizing, and then Project

Management.
You can also run the BD64 transaction.
The Display Distribution Model window is displayed.
2. Select Create model view.
If required, switch the processing mode to edit within Distribution Model/Switch

Processing Mode.
3. Enter a short text string and a technical name for your new model view.
4. Click Save.
The Distribution Model Changed window is displayed, showing a tree structure of the
distribution model.
Description of the illustration iway_sapu_distributemodel.gif

a. In the Distribution Model tree, select a new model view.

b. On the right, select Add message type.
The Add Message Type box is displayed. It contains fields for specifying the sender
and receiver of the message, as well as the message type.
Description of the illustration iway_sapu_addmessagetype.gif
c. In the Sender field, provide the sender that points to the SAP system, which
sends the IDoc, for example, I46_CLI800.
In this case, the sender is an SAP 4.6B system.
d. In the Receiver field, provide the logical system, for example, ORACLETDS.
e. In the Message type field, provide the type of IDoc, for example, DEBMAS.
5. Click the check mark icon.
6. Click Save.
The Change Distribution Model window displays the new model view to use to send
message type, DEBMAS, from the I46_CLI800 SAP system to the ORACLETDS logical
system.

Description of the illustration iway_sapu_changedistmodel.gif
You are now ready to test the connection to the logical system.
6.15 Testing the SAP ALE Configuration
In the SAP Server, the BD12 transaction enables you to send IDocs to any logical system, for
example, to an event adapter.
6.15.1 Testing the SAP ALE Configuration
To test the SAP Application Link Embedding (ALE) configuration:
1. In the Send Customers window, enter the IDoc message type, for example, DEBMAS
in the Output type field.

Description of the illustration iway_sapu_sendcustomers.gif
2. In the Logical system field, enter the logical system, for example, ORACLETDS.
3. Click Run.
The SAP event adapter receives the IDoc in XML format. No response is expected from
the event adapter.
A confirmation window is displayed.

Description of the illustration iway_sapu_testcomplete.gif
7 SAP TCodes for "Receiver Port "
TCODE Description Functional Area *

RFC Destinations
SM59 BC - RFC +
(Display/Maintain)
WE20 Partner Profiles BC - ALE Integration Technology +
SMICM ICM Monitor BC - Internet Communication Manager +
SM58 Asynchronous RFC Error Log BC - RFC +
WE19 Test tool BC - ALE Integration Technology +
WE05 IDoc Lists BC - ALE Integration Technology +
IDX1 port Maintenance in IDoc Adapter BC - ALE Integration Technology +
WE21 port definition BC - ALE Integration Technology +
WE02 Display IDoc BC - ALE Integration Technology +
Meta Data Overview in IDoc
IDX2 BC - ALE Integration Technology +
Adapter
XSLT XSLT tester BC - ABAP XML Processing +
SXMB_MONI Integration Engine - Monitoring BC - Integration Engine +
AL11 Display SAP Directories BC - Operating System Monitors +
BD64 Maintenance of Distribution Model BC - ALE Integration Technology +

TCODE Description Functional Area *

SMQ2 qRFC Monitor (Inbound Queue) BC - RFC +
SXI_CACHE Integration Directory Cache BC - Integration Builder - Configuration +
SXMB_ADM Integration Engine - Administration BC - Integration Engine +
SXI_MONITOR XI: Message Monitoring BC - Runtime Workbench/Monitoring +
LPCONFIG Maintain Logical ports BC - WebServices ABAP Configuration +
SE11 ABAP Dictionary Maintenance BC - Dictionary Maintenance +
SE38 ABAP Editor BC - ABAP Editor +
SM30 Call View Maintenance BC - Table Maintenance Tool +
BC - User and Authorization
SU01 User Maintenance +
Management
SE80 Object Navigator BC - Repository Browser +
SE37 ABAP Function Modules BC - Function Builder +
ST22 ABAP Dump Analysis BC - Syntax, Compiler, Runtime +
TABLE Description Functional Area *
MONI Monitor table MONI Basis - Performance Monitors (TCC) +

CDATA Change Data Logistics - Vendor Master +
SXMSPLSRV XMS: Pipeline Service Specification Basis - Integration Engine +
IDXNOALE Do not request IDoc Adapter exception list Basis - Integration Server +
acknowledgement
MATERIALID Material Identification Cross Application - Cross-Application +
Components
UST04 User masters Basis - User and Authorization +
Management
HTTPURLLOC HTTP URL Location Exception Table Basis - Client/Server Technology +
EDIPORT Summary Table for all port Types for IDoc Processing Basis - ALE Integration Technology +
ADAA SAP DB: Directory of Valid DBA Actions Basis - MaxDB +
FILETEXT File Name Description Basis - Platform-Independent File Names +
A386 Sales Org./Dist.Chl./Division/Sold-To Pty IS - SAP Media +
SALRT Alert: Instance Table Basis - Alert Framework +
SXMSPIPE XML Message Server: Pipeline Definition Basis - Integration Engine +
EDEXTASKIDOC IDocs for Data Exchange Task IS - Energy Data Management +



8 Master Data Management Generic Extractor

(MDMGX) for Initial Load in MDG-F
SAP Master Data Governance provides out-of-the box solutions for the central management
of master data objects. Domain-specific solutions include business partner (MDG-BP),
customer (MDG-C), supplier (MDG-S) governance, material governance (MDG-M), and
financials governance (MDG-F). This guide provides you with the foundation knowledge
you need to perform an initial load of master data into the financial governance (MDG-F)
data model.
SAP Master Data Governance (MDG) is used for embedded Master Data Management (MDM), that
is, centralized, out-of-the-box, domain-specific creation, modification, and distribution of master data
with a focus on SAP Business Suite.
Domain-specific content (data models, user interfaces, workflows) is provided as part of the standard
for several application areas. It is a common requirement from customers to adapt the MDG data
models to their specific needs.
This document explains how-to perform an initial load of master data from SAP ECC systems into the
MDG hub. It covers the setup and execution of the extraction of master and/or customizing data in
from SAP ECC client systems as well as the import of the extracted data into the MDG hub. It
explains the key concepts and implementation details in general and includes some real-life examples
of the MDG-F data model .
8.1 Transaction MDMGX – Main Menu
Start the transaction MDMGX. The figure below shows the MDMGX main menu.

consists of several actions that are required to configure the required

customizing for the generic data extraction.
is used for data extraction. In MDG, only
is relevant. is not required.
8.2 Define Object Types
In MDMGX, you can group several tables for a single object type. This is comparable with the
MDG data model which consists of several entity types. The general recommendation is the
creation of a single object type for each MDG data model. The object type consists of a technical

name and a description.

8.3 Define Repositories and FTP servers
The repository is the receiver of the MDMGX output. In NW MDM, several repositories can receive
the same data. In MDG, the MDMGX output is represented using an entity type with SU Type 1 for
a single data model. The general recommendation is the creation of a single repository for each
entity type with SU Type 1 of the target MDG data model.
An FTP server configuration is only needed when the MDMGX output is transferred directly to the
MDG Hub via FTP. A local download is supported, too.
The figure below shows the required information for the definition of repositories and FTP
servers using a template entry.
Fields that are not mentioned below are not relevant for MDG.
The logical repository name is the repository key used within MDMGX. We recommend that you
replace the with the name of the target entity type with SU Type 1. It is mandatory to
use the MDG_
prefix in the name. Reuse the same value for field too.

The object type links the repository with its object. Select one of the defined object types from the F4
help.
Maintain the same value as in
Maintain the URL of the FTP server if the MDMGX output is transferred to the MDG hub via FTP.

Maintain the logical name of the system used for data extraction. We recommend the following
naming convention:
Maintain the type of the system used for data
extraction. Upload Ports and Check-Tables
You use upload ports and check-tables to upload MDMGX configuration from a text file. This applies
for SAP MDG-F objects. It provides a pre-defined configuration file usable for the common SAP entity
types (refer to the MDG-F step-by-step example for details).
8.4 Maintain Ports and Check-Tables
This item is used to define the actual data extraction. ginates from SAP NW MDM. It
describes how the extracted data is imported into MDM. This feature is used by MDG in a similar way.
In MDG the port creates the link between the MDG entity type with SU Type 1 and its related
database table in the SAP system.
Maintenance is done in the SAP data browser. It is possible to define a pre-selection. For
example, you can define that specific record is used as a template for new records. If no template
is used, new records are created from the list. Choose the Create button to define a new one.
The following fields are mandatory for MDG scenarios.
The system type defines to which SAP system the current definition belongs.
The object type defines to which object the current definition belongs. Examples for MDG-F object
types are “ Account ” or “ Cost El ement ” .

In MDG scenarios, the MDM port code always refers to the name of the MDG entity type with SU Type
1 linked to the SAP database table of the current definition. The port code is reflected in the
extracted data. The port code is the re-occurring XML node that encapsulates a single record.
Examples of MDG-F port names are for the A segment of an account or
for the texts of cost elements.
The table name is the database table to be used for data extraction.

Non-language fields define the single fields that are extracted. Maintenance of multiple fields is
possible by entering a comma separated list. The input is used to create a dynamic SQL
statement for data extraction. Additionally, the input defines the name of the XML element in the
output of the extraction. We recommend using the related attribute name in the MDG data model.
Therefore, the required syntax is
Refer to the step-by-step examples
for details.
The where-clause defines the condition for the data selection. It has to be written in the correct SQL
syntax, otherwise the extraction might fail. The general syntax is
‘ <Fi el dVal ue>’ . A combination of several selection criteria using the SQL or operators
is supported, too.
The following example shows a selection of cost centers of the controlling area 0001:
. Further examples are available in the step-by-step examples.
The link info defines a joined selection for the maintained database table. The information is
mapped to an SQL INNER JOIN. This feature allows the selection of master data from different
tables for a single port. The required syntax is:
.
Refer
to the step-by-step examples for details.
Function modules for XML allow the creation of custom extraction logic. You can use function
modules if a complex selection is required that cannot be configured using the feature.
Function module- based extraction is used by the MDG-F object Cost Element (refer to the step-
by-step example for more details).
8.5 Define Function Module Parameters for Exceptional Cases

This customizing allows defining input parameters for function module-based extraction. This
feature is used by the MDG-F object Cost Element. The screenshot below shows the input screen.
The object type defines to which object the current definition belongs. Examples for MDG-F object
types are
Account or Cost Element.
The function module defines the name of the function module that is used by the object for data
extraction. An example of an MDG-F function module is MDM_ERP_CELEM_EXTR.
The input parameter defines a string that is given to the function module as input parameter. The
content of the string must be handled by the function module. Refer to the related chapter for the
cost element function modules as example.
8.6 Start Extraction
8.7 Start Extraction

Start extraction triggers the actual data extraction from the current MDG client system into an XML file.
The screenshot below shows the selection screen.
This required field defines the data to be extracted. Select a repository from the F4 help.
If the data to be extracted consist of several tables, the port name allows the selection of a specific
table. Usually, the field can be left blank to indicate an extraction of all ports that are defined for the
current repository.
MDMGX supports various options for transferring the data.
Local Download stores the resulting XML directly on the PC of the current user. The file
directory must be defined.

Download to Appl. Server stores the resulting XML directly on the file system of the current
application server. The file directory must be defined.
Upload via FTP transfers the file via FTP to the destination that is defined for the
repository. If the FTP is not anonymous, user and password are required.
Start extraction triggers the actual data extraction from the current MDG client system into an XML file.
The screenshot below shows the selection screen.
This required field defines the data to be extracted. Select a repository from the F4 help.
If the data to be extracted consist of several tables, the port name allows the selection of a specific
table. Usually, the field can be left blank to indicate an extraction of all ports that are defined for the
current repository.

MDMGX supports various options for transferring the data.
Local Download stores the resulting XML directly on the PC of the current user. The file
directory must be defined.
Download to Appl. Server stores the resulting XML directly on the file system of the current
application server. The file directory must be defined.
Upload via FTP transfers the file via FTP to the destination that is defined for the
repository. If the FTP is not anonymous, user and password are required.

9 MDG Data Import Framework
9.1 Technical Requirements
The data import framework (DIF) is delivered as part of the MDG solution. Some components are
available within the common software layer SAP_BS_FND. The development of the new MDG
content required some enhancements in the common layer, too. Ensure that the MDG system is at
least on the release level of SAP_BS_FND 7.31 SP07 or newer.
9.2 System Setup
DIF requires at least two types of file directories on the application server:
One directory for each object type to store the files to be imported
One directory for all object types to store the archived files that have been imported
SAP recommends the creation of application specific file directories. Those shall be bound to
unique folders of the application server.
9.3 Examples:
MDGF_TRANSFER_ACCOUNT with folder /usr/sap/Q7B/SYS/MDG/financial/account/
o This folder is used by all MDMGX XML files related to the account, its texts and the account
in company code.
MDGF_TRANSFER_CCTR with folder /usr/sap/Q7B/SYS/MDG/financial/cctr/
o This folder is used by all MDMGX XML files related to the cost center and its texts.
MDGBP_TRANSFER_IN01 with folder /usr/sap/Q7B/SYS/MDG/bp/in01/
o This folder is used for the MDG Business Partner / Customer / Supplier application.
MDG_ARCHIVE with folder /usr/sap/Q7B/SYS/MDG/archive/
o This folder is used as archive folder for all kinds of processed files.
Create the physical directories on the application server and map them to logical
directories using transaction .

Configure the directories in Customizing for Master Data Governance (transaction ) under
General Settings Data Transfer Define File
Source and Archive Directories for Data Transfer.
The Data Transfer Directories are used for the source files to be imported. The directories
are not object specific.
The Archive Path for Object Types must be maintained for each object that shall be imported.
The step-by-step examples provide further information how DIF is used for MDG-F.

10 Step-by-Step Example: MDMGX – MDG-F

Extraction
This example describes the extraction of all entity types for the MDG-F data model. This data can
be imported into the SAP MDG data model . The import into MDG always requires a change
request. An import of active data is not supported. This fact is especially reflected by the selection
criteria for ports and check tables.
Accounts consist of two entity types in MDG-

refers to the chart of
account dependent data stored in database table .
Related texts are stored in database table refers to the company code
dependent data stored in database table .
Companies reflect the MDG-F entity type . Relevant data is stored in database table .
Cost Centers reflect the MDG-F entity type . Relevant data is stored in database table .
Related texts are stored in database table .
Cost elements combine the ERP client data in a single MDG-F entity type . Relevant data is stored
in database tables and . Related texts are stored in database table .
Group Accounts reflect the special handling of Group Accounts in MDG-F. Instead of storing Group
Accounts in entity type Account ( ), MDG-F stores this information
in entity type Item ( ). MDMGX based extraction supports transferring SAP ERP Group
Accounts (tables and ) to MDG-F Items. The
functionality is introduced in SAP MDG-F 7.0 with SAP Note 2082479.
Profit Centers reflect the MDG-F entity type including its entity type with SU Type 4 that
is the assignment of a profit center to the company codes of its controlling area. The profit center
database table is ; assignments are stored in ; and
relevant texts are stored in .
The following steps require that transaction MDMGX is running in the MDG client system that shall
be used for data extraction.
10.1 Check Object Types in MDMGX

MDG-F object types are pre-defined by SAP. Check that the following object types exist:
and .
10.2 Define Repositories and FTP servers
The screenshot below shows all repositories that must be defined for the extraction of all MDG -F
objects. It is strictly recommended to create them accordingly using the same names.
10.3 Maintain Ports and Check-Tables
MDG-F provides a pre-configuration of ports and check tables. The configuration depends on the
current MDG release. Related text files are attached to the following SAP Notes:
MDG-F 7.0: 1882127
MDG-F 8.0: 2134044
This text file can be uploaded into MDMGX.
1. Go to the SAP note and download the attached text file.

2. In transaction MDMGX ensure that none of the MDG-F related entity types is maintained yet in
“ Mai nt ai n Por t s and Check Tabl es” . Otherwise the upload will not work.
3. Start “ Upl oad Por t s and Chec k Tabl es” .
4. Enter Object Type “ Ac c ount ” and select the locally stored text file. Ensure that checkbox
is set.
5. Execute the upload. It should result in a success message.

6. Go back to the main menu.
7. Start “ Mai nt ai n Por t s and Check Tabl es” to check the ports. Choose system type R3 and
display the records. The system displays the list as shown in the screenshot.
The pre-defined ports and check tables are not yet usable for an immediate extraction. The
Customizing contains only the extraction settings for the tables and fields. The actual selection
criteria must be defined according to the existing data as described in the following chapters.
10.4 Account
Account data is not time dependent. The key for an account consists of three parts: the general
A-Segment (entity type stored in table ), the text (stored in table ), and the
company code specific B-Segment (entity type stored in table ). The extraction consists of
three ports to separate the master data extraction from its assignments to the company codes
and the text extraction:

Port extracts only the master data for the A-

Segment. Port extracts the texts.
Port extracts the B-Segment including its company code specific data.
The text extraction is a join: the selection itself is made on the account (A-Segment) master data
table but the data in the resulting XML is extracted from the text table.
The B-Segment extraction is a join: the selection itself is made on the account in the master data
table for the company code (B-Segment). The data in the resulting XML is enriched with the
related chart of accounts, as defined in table . This enriched data is required for the later
import into the MDG-F data model.
The general recommendation is to limit the extraction in the following ways:
1. Use the chart of accounts ( ) for the extraction of A-Segments and relevant texts. This limits
the number of objects to be extracted and thus ensures that the change request used for the import
in the MDG hub does not get too big.
2. Use the company code ( ) for the extraction of B-Segments. This limits the number of objects
that to be extracted and thus ensures that the change request used for the import in the MDG hub
does not get too big. Additionally, it is easier to select valid B-Segments according to the extracted A-
Segments:

a. The chart of accounts of the A-Segment defines the valid company codes.
b. The A-Segment must exist in MDG before B-Segments can be imported.
The general delivered by SAP for ports respectively

is SKA1~KTOPL = ‘INT’ respectively SKAT~KTOPL = ‘INT’. Adding further criteria
for field limits the selection for specific accounts.
The general delivered by SAP for port SKB1~BUKRS = ‘0001’.

Adding further criteria for field limits the selection for specific accounts.
The following examples show possible adjustments.
1. SKA1~KTOPL = ‘INT’ AND SKA1~SAKNR > ‘0000120000’ limits the selection to all accounts with
the ID greater than 120000 for chart of accounts INT.
2. SKB1~BUKRS = ‘0001’ AND SKA1~SAKNR = ‘0000120000’ limits the selection to the single
account 120000 in company code 0001.
You must adjust the selection criteria for all ports of the account. The selection criteria must always
be synchronized.
10.5 Company
Company data is not time dependent. Its key consists only of one component. The general
recommendation is that an extraction of all companies in one run is possible. If a selection of a
specific company is required an example for the T880~RCOMP = ‘COMPID’. This clause extracts
the company with the ID .
10.6 Cost Center
Cost Center data is time dependent. Its key consists of multiple components. The extraction co nsists
of two ports to separate the master data extraction from the text extraction:
Port extracts only the master

data. Port extracts the
texts.
The text extraction is a join: the selection itself is made on the cost center master data table but
the data in the resulting XML is extracted from the text table.

1. Use a time slice consisting of the valid from ( ) and valid to ( ) dates as selection criteria.
In MDG the entity is stored within an edition having a time slice (valid from date and infinite valid to
date), too. It is not possible to import multiple time slices at once in MDG. At least the valid from
date extracted from the client system should match the one of the target edition in the MDG hub.

2. Use the controlling area ( ) as selection criteria. This limits the number of objects to be
extracted and thus ensures that the change request used for the import in the MDG hub does not
get too big.
The general delivered by SAP for both ports is CSKS~KOKRS = ‘0001’

AND CSKS~DATAB = ‘YYYYMMDD’ AND CSKS~DATBI = ‘YYYYMMDD’.
The following examples show possible adjustments.
1. CSKS~KOKRS = ‘0001’ AND CSKS~DATAB = ‘20130101’ AND CSKS~DATBI = ‘20131231’

limits the selection to all cost centers of controlling area 0001 that are valid from the 1st of
January to the 31st of December 2013.
2. CSKS~KOKRS = ‘0001’ AND CSKS~DATAB >= ‘20130101’ AND CSKS~DATAB <= ‘20130201’
limits the selection to all cost centers of controlling area 0001 that are valid starting from
the range 1st until 31st of January.
The adjustment of the selection criteria must be done for both ports of the cost center. The selection
criteria must always be synchronized.
10.7 Cost Element
Cost Elements use function modules for data extraction. Specific settings for the ports and check
tables are not required. Refer to the next chapter for details about the selection.
10.8 Group Account
Group Accounts are a special version of common accounts. In the SAP ERP customizing for Chart
of Accounts, it is possible to define a
transactions.
Group Account data is not time dependent. It does not include company code specific B-
Segments. The key for a group account consists of two: the general A-Segment (entity type
stored in table ), and its text (stored in

table ). The extraction consists of two ports to separate the master data
extraction from its text extraction:
Port extracts only the master data for the A-

Segment. Port extracts the texts.
The text extraction is a join: the selection itself is made on the account (A-Segment) master data
table but the data in the resulting XML is extracted from the text table.
The general recommendation is to limit the extraction by using the chart of accounts ( ) for
the extraction of A-Segments and relevant texts. This limits the number of objects to be
extracted and thus ensures that the change request used for the import in the MDG hub
does not get too big.
The general delivered by SAP for ports

respectively is SKA1~KTOPL = ‘ I NT’ respectively SKAT~KTOPL = ‘ I NT’ .
You can add further criteria for the field to limit the selection for specific accounts.
The following example shows possible adjustments.
SKA1~KTOPL = ‘ I NT’ AND SKA1~SAKNR > ‘ 0000120000’ limits the selection to all accounts
with the ID greater than for chart of accounts .
You must adjust the selection criteria for all ports of the account. The selection criteria must always
be synchronized.
10.9 Profit Center
Profit Center data is time dependent. Its key consists of multiple components. Additionally, it
has a single entity type with SU Type 4 . The extraction consists of three ports to separate
the extraction of master data, of assignments to company codes, and of text. The ports are as
follows:
Port extracts only the master data.
Port extracts the assignments to company

codes. Port extracts the texts.

Both the extraction of assignments to company codes and the extraction of text are achieved
using a join. The selection itself is made on the master data table for the profit center. However,
the data in the resulting XML is extracted from the assignments to company codes table and the
text table.
We recommend that you limit the extraction in the following ways:
1. Use a time slice consisting of the valid from ( ) and valid to ( ) dates as selection criteria.
In MDG, the entity type is within an edition that also has its own time slice (valid from date and
infinite valid to date). It is not possible to import multiple time slices at once in MDG. At least the
valid from date extracted from the client system should match the one of the target edition in the
MDG hub.
2. It is recommended to use the controlling area ( ) as selection criteria. This limits the number of
objects that will be extracted and thus ensures that the change request used for the import in the
The general delivered by SAP for ports is and

PROFIT_CENTERS_DESCR is CEPC~KOKRS = ‘0001’ AND CEPC~DATAB = ‘YYYYMMDD’
AND CEPC~DATBI = ‘YYYYMMDD’.
The following example shows a possible adjustment.

CEPC~KOKRS = ‘0001’ AND CEPC~DATAB = ‘20130101’ AND CECP~DATBI = ‘20131231’ AND
CEPC~PRCTR = ‘0020014360’ limits the selection to the profit center 20014360 of controlling area
0001 that is valid from the 1 st of January to the 31st of December 2013.
The adjustment of the selection criteria must be done for all ports of the profit center. The
selection criteria should always be synchronized.
10.104. Define Function Module Parameters for Exceptional

Cases
Cost Elements require function modules for the master data extraction. This is needed to overcome
the different data models of MDG-F compared to the SAP ERP backend. In the ERP backend its
data is separated in three different tables: storing the chart of account dependent data;
storing the time and controlling area dependent data; and storing the
texts. The MDG-F data model uses only one entity type that groups
the data together. Its data is time dependent. Its key consists of multiple comp onents. The extraction
has to select the data from the different table in the correct way. Unfortunately the generic
functionality of MDMGX using INNER JOINS is not sufficient for this.
The extraction consists of two ports to separate the master data extraction from the text extraction:
Port extracts only the master data from tables and . It is linked to
the function module .
Port extracts the texts from tables and . It is linked to

the function module .
There is no general configuration defined for input parameters by SAP. It is mandatory to adjust
the parameter according to the desired extraction. The parameter must be use the common
format of an SQL Where clause.
1. It is recommended to use a time slice consisting of the valid from ( ) and valid to ( ) dates
as selection criteria. In MDG the entity type will be stored within an edition having a time slice (valid
from date and infinite valid to date), too. At least the valid from date extracted from the client system
should fit to the one of the target edition in the MDG hub.
2. It is recommended to use the controlling area ( ) as selection criteria. This limits the number of
objects that will be extracted and thus ensures that the change request used for the import in the
MDG hub does not get too big.
The following example shows a possible adjustment. You do not have to mention the table name.
KOKRS = ‘0001’ AND DATAB = ‘20130101’ AND KSTAR = ‘0000400000’ limits the selection to the cost
element 400000 of controlling area 0001 that is valid from the 1 st of January 2013.
The adjustment of the selection criteria must be done for all ports of the cost element. The
selection criteria must always be synchronized.
10.11Extract the Data
Having checked and maintained the ports and check tables the actual data extraction can be
started. The process describes how-to download the files to a local PC.
1. In the MDMGX main menu, click item . This loads the input screen of the data
extraction.
2. Select a repository (e.g. ) using the F4 help on field
.
3. The input fields of can be blank. In that case the system tries to extract data
for all ports being maintained. Maintaining a port will only extract its specific data (e.g.
extracts only the texts).
4. Select the checkbox and use the F4 help on field to specify

the destination folder for the extracted files.
5. The screenshot shows a possible result. button to trigger the

extraction.
6. MDMGX display a result for the last extraction run.

11 Step-by-Step Example: DIF- Import MDG-F

Master Data
The example describes the required steps to import profit center master data. The requirement is
that some XML files are already available on the application server in one of its folders used for
financial master data upload.
11.1 Upload extracted Files to the Application Server
There are various ways of uploading files to the application server. It is required that the files extracted
with MDMGX are stored within one of the source file directories for DIF.
1. Enter MDG Hub with SAP GUI and call transaction .

2. Search for the source files stored locally.
3. Enter a path on the application server as storage location in field
. Including the filename, too (for example,
/usr/sap/Q7B/SYS/MDG/financial/in01/upload.xml)
4. Click the button to start the upload.
11.2 Starting the Data Import Framework Application
There are various ways to start DIF. The recommendation is using the link within the MDG-F work center.
1. Logon to the MDG Hub.

2. Run transaction .
3. Select the appropriate role to navigate to your work center. The example uses role
(the financial controlling work center) since profit center data shall be
imported.
4. In the tree menu on the left hand side select

.
In the main screen the DIF application is now running.

11.3 Prepare the Import of Financial Master Data
DIF itself is a cross entity type application. It supports importing various entity types for various data
models. Entity types are reflected in DIF . The MDG-F specific ones are:
– : related to the entity type
– : related to the entity types and

The following steps are required to prepare the upload of profit centers.
1. Select – .
2. Maintain a meaningful for the import of master data.
3. On the list for click the button.
4. Select the in the pop-up and confirm with .
5. Use the F4 help for to select the one that contains the data to be imported.
6. It is possible to optionally check the content of the directory by clicking on
.
7. Define a and an for the import.
11.4 Optional: Run a Simulation of the Import
DIF offers the possibility to simulate the master data import. This is supported by MDG-F. The
simulation processes the files and maps them into the target format but does not create a
change request. The simulation is triggered with button . Once the simulation has
been started button
can be used to navigate into the log of the simulation run.
11.5 Run the Import
The import of MDG-F master data always creates a change request. A direct import of the data
into the active are is currently not supported.
1. Use button to trigger the master data import. The import runs asynchronously. The UI only
displays the related import run number. It is not updated with any status information.
2. Choose the button to navigate to the import log. The
displays the status of the import run.
3. Click the linked ID in column to navigate to its details.
4. Expand the . Scrolling down to its end, the message “ Change r equest
<I D> has been cr eat ed” displays if the import run has been successful. If the import
fails, you must import the complete file(s) again.
Seite 167 von 214

The master data is now part of the change request. Checks have not yet been performed. The
change request might contain inconsistent data. It must be processed according to its workflow
definition to ensure the creation of the master data in the active area.
Seite 168 von 214

12 MDG extensions, improvements and business

benefits
12.1 Consolidation of master data

Support for multiple vendor and customer assignments and process enhancements*
Innovations Business value

Support of multiple assignments for Enhanced consolidation of business
vendors and customers* partner data by integration of multiple
vendor and customer assignments in the
Deletion capability in best record identification of duplicates and calculation of
calculation best records
Re-validation of data after manual More process flexibility by applying
changes manual data changes
Search and display changes of active
records
Seite 169 von 214

12.2 Mass processing of master data

Support for multiple vendor and customer assignments, classification and process
enhancements

Support of multiple assignments for Enhanced mass processing with extended
vendors and customers* scope for business partner data
Change classification data in mass Flexibility to change classification data
processes using a mass process
Export of master data into spreadsheet
format for offline changes and upload into a
mass process
Re-validation of data after manual
changes
Search and display changes of active
records
Seite 170 von 214

12.3 Central governance of financial master data

Central governance for internal order master data

With release 19xx, SAP MDG on SAP
S/4HANA covers:
Centralized governance, compliance and
Central maintenance and governance of
transparency of master data during creation
internal order master data
and change through integrated staging,
Replicating internal orders via IDOC or approval and central audit trail
SOA* from MDG system
Consistent definition, authorization and
Receiving internal orders via IDOC or replication of internal order master data,
SOA into SAP S/4HANA,via IDOC into SAP keeps data consistent cross systems
ERP
Elimination of error-prone manual
Initial load of internal orders into MDG maintenance processes for internal order
(e.g. from SAP ERP or SAP S/4HANA) master data in multiple systems
Seite 171 von 214

12.4 Central governance of financial master data

Merge cost element into G/L account*

Central maintenance of controlling data (cost element) Simplified maintenance of
integrated into the G/L Account user interface financial master data
Replication of cost element data to S/4HANA can be Harmonized behavior as in
done via the G/L Account IDOC and SOA service SAP S/4HANA
Simplified replication channel
Seite 172 von 214

to lower TCO
12.5 Central governance of master data

Scope enhancements and simplifications for business partner and material domains
Innovations
With release 1809 and 19xx adjustments, SAP S/4HANA has increaseddata coverage in
central governancefor…
…business partner:
Use of newly added customers and vendors for a business partner as references for
Seite 173 von 214
partner functions within the same change request*

Load and replication of contract accounts (FI-CA) via service-oriented architecture (SOA)
service
…and material domains:

Adoption of enhancements and simplifications of SAP S/4HANA for the MDG for
materialapplication*
Defaulting of search engine SAP HANA-based search for MDG for material*
Seite 174 von 214

12.6 Central governance of business partner, customer, supplier master

data
Enrichment via SAP S/4HANA Cloud for data enrichment

Though integration with SAP S/4HANA
Cloud for data enrichment you can enrich
Leverage value added insights via
master data with name, address and
business partner information provided by
identification information from external data
external data providers, like Dun &
providers, when…
Bradstreet
…creating a new business partner,
customer or supplier master data record
Considerably reduce the risk of errors in
manual data creation
…changing an existing business partner,
customer or supplier master data record
Seite 175 von 214

Seite 176 von 214

12.7 Process analytics for governing master data

Enhanced SAP Fiori user experience in process analytics

With release 1809, SAP S/4HANA has
increasedSAP FIORI-based process
One-stop information on prevailing
analytics for governing master data,
process quality in central governance,
including:
consolidation, and mass processing
Summary dashboard and analytical list
pages displaying relevant process Intuitive navigation and drill down for
information at a glance detailed analysis of process-quality issues
Seite 177 von 214

12.8 Master data quality management

Managing data quality rules

With release 1809, SAP S/4HANA provides
data quality management for product
Central place for data-quality rules for
master data, including:
product master data
Repository to catalog and define data-
quality rules Transparency on business aspects,
Comprehensive description of rules, usages and technical implementations of
including business aspects, ownership, and rules
rule implementations
Collaboration and status handling during
the lifecycle of rules, from creation to sunset
Seite 178 von 214

Seite 179 von 214

12.9 Master data quality management

Measuring and analyzing data quality

With release 1809, SAP S/4HANA provides
data quality management for product
Consistent quality definition for product
master data, including:
master data
Evaluation of master data using data-
quality rules Continuous data-quality evaluation and
Analysis of incorrect data and correction monitoring
of identified issues
Definition of data-quality scores as KPIs
for master data management
Reporting and analysis of scores
Seite 180 von 214

13 Useful Transactions in SAP Workflow
OOAW Evaluation paths
PFAC Create and maintain Rules
PFOM Maintain assignment to SAP organizational objects
PFOS Display assignment to SAP organizational objects
PFSO Organizational environment of a user
PFTC Create and maintain tasks
PPOCW Create organizational plan
PPOMW Maintain organizational plan
PPOSW Display organizational plan
SWDA Workflow Builder (Calls the Workflow Builder in alphanumeric mode)
SWDD Workflow Builder
SWDS Workflow Builder (Selection)
SWDD_CONFIG Workflow configuration
SBWP The Business Workplace
SWDC_DEFINITION Workflow Builder administration data
Seite 181 von 214

SWDC_RUNTIME Workflow runtime administration data
SWNCONFIG Extended notifications for business workflow
SWDM Business Workflow Explorer
SWEINST Evaluation and maintenance of instance linkages
SWEINSTVC Evaluation and maintenance of instance linkages
SWE2 Evaluation and maintenance of type linkages
SWE3 Evaluation and maintenance of instance linkages
SWE4 Switch event trace on/off
SWEL Display event trace
RSWELOGD Delete event trace
SWEC Link change documents to events
SWED Assign change document objects to object types
SWEQADM_1 Event queue administration
SWEQBROWSER Administration of event queue browser
SWETYPV Evaluation and maintenance of type linkages
SWI1 Selection report for work items
Seite 182 von 214

SWI2_FREQ Work items per task
SWI2_DEAD Work items with monitored deadlines
SWI2_DURA Work items by processing duration
SWI11 Tasks in workflows
SWI13 Task profile
SWI5 Workload analysis
SWL1 Settings for dynamic columns
SWLV Maintain work item views
SWFVISU Parameters for Work Item Visualization in the UWL
SWO1 Business Object Builder
SWO6 Customizing object types
SWR_WEBSERVER Customizing Web server
SWU_CONT_PERSISTENCE Administration of container persistence
SWU_EWCD Wizard for event creation using change documents
SWU_EWLIS Wizard for event creation using the Logistics Information System
SWU_BTE Wizard for event creation using Business Transaction Events
SWU0 Event simulation
SWU2 RFC monitor
Seite 183 von 214

SWU3 Automatic Workflow Customizing
SWU4 Consistency check for standard tasks
SWU5 Consistency check for customer tasks
SWU6 Consistency check for workflow tasks
SWU7 Consistency check for workflow templates
SWU8 Switch workflow trace on/off
SWU9 Display workflow trace
SWU10 Delete workflow trace
Transaction Code Description
SWUD Diagnostic tools
SWUE Trigger event
SWUI Start workflows/tasks
SWUS Testing workflows/tasks
SWXML Display XML documents
SWUY Wizard for linking messages to workflows
SWWCOND_INSERT Schedule background job for work item deadline monitoring
SWWCLEAR_INSERT Schedule background job for clearing tasks
RSWWCOND Execute single background job for work item deadline monitoring
Seite 184 von 214

RSWWCLEAR Execute work item clearing work once
WF_HANDCUST WebFlow service handler maintenance
WF_EXTSRV Maintain Web Service Repository
WFWS Import WSDL files
SWIA WI Administration Report
Seite 185 von 214

14 IDoc-Transaktionen
14.1 IDoc-Transaktionen – Anzeigen / Monitoring / Admin

# WLF_IDOC – IDoc Verarbeitung –
# WE02 – Anzeigen IDoc
# WE05 – IDoc Listen
# BD87 – Statusmonitor für ALE Nachrichten
14.2 IDoc-Transaktionen – Administration

# WE20 – Partnervereinbarungen
# WE21 – Portbeschreibung
# SM59 – RFC Destinations (Anzeige u. Pflege)
# SM58 – Fehlerprotokoll Asynchr. RFC
14.3 IDoc-Transaktionen – Suche

# WE06 – Aktive IDoc Überwachung (Monitoring)
# WE07 – IDoc Statistik
# WE09 – IDocs suchen über Inhalt
# WE10 – IDocs suchen über Inhalt
# WE11 – Löschen von IDocs
14.4 IDoc-Transaktionen – Test

# WE19 – Testwerkzeug
# WE15 – Test Ausgangsverarbeitung ab NAST
# WE14 – Test Ausgangsverarbeitung
Seite 186 von 214

# WE18 – Statusdatei erzeugen
# WE17 – Test Statusdatei
# WE12 – Test modifizierte Eingangsdatei
# WE16 – Test Eingangsdatei
14.5 IDoc-Transaktionen – Dokumentation

# WE60 – Dokumentation für IDoc Typen
# WE64 – Dokumentation Nachrichtentypen
14.6 IDoc-Transaktionen – Entwicklung

# WE31 – Entwicklung IDoc Segment
# WE30 – Entwicklung IDoc Typ
# WE81 – Logische Nachrichtentypen
# WE82 – Zuordnung Nachrichten zu IDoc Typ
# WE41 – Vorgangscodes Ausgang
# BD51 – Eingangsfunktionsbausteine pflegen
# WE57 – Zuordnung Nachrichten zu Anw. Objekt
# WE42 – Vorgangscodes Eingang
14.7 IDoc-Transaktionen – Steuerung

# WE47 – Statuspflege
# WELI – Statusgruppen pflegen
# WE43 – Funktionsbaustein Statussatz Anzeige
# WE24 – Vorschlagswerte Ausgangsparameter
# WE27 – Vorschlagswerte Eingangsparameter

Seite 187 von 214
# WE44 – Partnerarten und Prüfungen
# WE45 – Weiterleiten Eingang (V3, EDILOGADR)
# WE55 – Funktionsbaustein für Pfadnamen
# WE34 – Objekte zur Anzeige von XML IDocs
# WE32 – Entwicklung IDoc Sicht
14.8 IDoc-Transaktionen – Umsetzregeln

# BD62 – Segment Umsetzungsregel definieren
# BD79 – Pflege IDoc Umsetzungsregeln
# BD55 – Zwischenbeleg Umsetzung pflegen
14.9 IDoc-Transaktionen – Umschlüsselung

# WE70 – Umschlüsselung: Basistypen
# WE71 – Umschlüsselung: Erweiterungen
# WE72 – Umschlüsselung: IDoc Typen
# WE73 – Umschlüsselung: log. Nachrichten
14.10 IDoc-Transaktionen – Sonstige

# BDM2 – Monitoring: IDOCs beim Empfänger
# BDM7 – ALE Audit: Statistische Auswertungen
# SARA – Archivadministration
# IDOC – IDoc: Reparatur und Prüfprogramme
Seite 188 von 214

15 MDG Transactioncodes
Description Functional Area *
CODE
MDGIMG Master Data Governance CA - Master Data Governance +
Customizing
MDG_KM_MAINTAIN Maintain Key Mapping -- CA - Key Mapping +
MDGDT Configuration Workbench CA - Design Time +
MDG_BS_SUPPL_HARM mdgS: CVI Settings -- CA - MDG Supplier (Central Parts) +
MDG_HDB_GEN_UI HANA View Generator CA - Data Quality +
MDG_DATA_MODEL mdg Data Model: Generated Tables CA - Application Framework +
MDG_TR_DEST Destination for Transport Methods CA - Application Framework +
MDG_TABLE_ADJUST Change settings of generated tables -- CA - Application +
Framework
MDG_TR_WZ RFC Connection Wizard CA - Application Framework +
MDG_DELETE_CREQUEST Delete Change Requests -- CA - Application Framework +
MDG_DL_OBJ Define Object Types for Data Load CA - Mass Load +
MDGM_MODEL_DETAILS Data Model Mapping -- CA - MDG Material +
MDG_DELETE_MODEL Delete Active Version of a Model -- CA - Application +
Framework
SMT Customizing Transformation CA - Service Mapping Tool +
Workbench
MM01 Create Material & LO - Material Master +
PFCG Role Maintenance BC - ABAP Authorization and Role Management
Seite 189 von 214

16 Attachment
16.1 Configuring Master Data Governance for Financials
SAP Master Data Governance for Financials enables you to govern financial master data on
a hub system and to replicate the data to a number of client systems. The system centralizes
and manages the master data by an approval process. You can use this guide to help you to
configure Master Data Governance for Financials (MDG-F) 9.2.
Note
MDG-specific Customizing is located under SAP Customizing Implementation
Guide Cross-Application Components Processes and Tools for Enterprise
Applications Master Data Governance, Central Governance.
You can also directly access all MDG-specific Customizing using transaction MDGIMG.
The Customizing settings are located under Master Data Governance, Central
Governance Master Data Governance for Financials as well as Master Data
Governance, Central Governance General Settings. For more information, see General
Settings for Financials.
16.2 Prerequisites
After installing MDG-F, run the report RGZZGLUX before opening the UIs delivered with
MDG-F. The report performs several checks regarding the general ledger configuration of
your MDG system.
16.3 Data Model
If data model 0F is available in your system and you want to activate the new data model 0G,
delete data model 0F. Data model 0F is the predecessor of 0G and must not be used. To
delete data model 0F, follow the steps described in Deleting Data Model 0F.
Seite 190 von 214

16.4 Business Function
Before you activate the business functions, ensure that you have the administration
authorization for MDG. The required authorization objects are delivered with the authorization
role SAP_MDG_ADMIN. In transaction PFCG, we recommend creating a copy of this role
and assigning the relevant authorization values. For the authorization object USMD_DM, you
need to assign the values for the authorization field USMD_MODEL (for example MM, BP, or
0G) and the values for the authorization activity ACTVT (for example, 01: Create or generate
or 02: Change).
You have activated the following business functions in transaction SFW5:
• Master Data Governance, Generic Functions (MDG_FOUNDATION)
• Master Data Governance, Generic Functions 2 (MDG_FOUNDATION_2)
• Master Data Governance, Generic Functions 3 (MDG_FOUNDATION_3)
• Master Data Governance, Generic Functions 7.0 (MDG_FOUNDATION_4)
• Master Data Governance, Generic Functions 7.0 Feature Pack

(MDG_FOUNDATION_5)
• Master Data Governance for Financials, Organizational Units (FIN_MDM_ORG)
• Master Data Governance for Financials 3 (MDG_FINANCIALS_3)
• Master Data Governance for Financials 7.0 (MDG_FINANCIALS_4)
• Master Data Governance for Financials 7.0 Feature Pack (MDG_FINANCIALS_5)

Seite 191 von 214
16.5 SAP Business Workflow
You have made your general settings for SAP Business Workflow in Customizing for SAP
NetWeaver under Application Server Business Management SAP Business Workflow.
For more information, see SAP Business Workflow.
16.6 Web Dynpro Applications
You have activated the services for Web Dynpro Applications. For a detailed list of the
relevant services, see Services to be Activated for Web Dynpro Applications.
16.7 Process
1. Activate Data Model 0G
2. Activate the Business Configuration Set
3. Check or Create an Edition Type
4. Check Business Activities
5. Check or Define a Change Request Type
6. Assign and Personalize the Role
7. Define the Validation Rules and Derivation Rules
8. Configure the Financials Workflow
9. Define Scope for Changes
10. Create Hierarchy Versions
11. Configure the Data Replication
12. Define Value Mapping

Seite 192 von 214
13. Define Key Mapping
14. Define a UI Environment for Running SAP MDG
15. Setting Up Initial Load
16. Display Remote Where-Used List
17. Change Message Types for Validation
18. Enable Detailed Analysis of Change Requests
The following configuration settings can be made for optional features:
• Configure Changeable IDs
• Set Up HANA Search
• Configure Business Context Viewer for MDG Financials
16.8 Links
• MDG 7.0 Guides on Service Market Place
• Extensibility Options for SAP Master

Data Governance Financial Data A zip file with Data
Model Metadata (Financials)
• SAP MDG Documentation for DIF on Service Market Place
16.9 How-to Guides
Extensibility Options for SAP Master Data Governance Financial Data
Seite 193 von 214

16.10SAP Notes
MDMGX Setup in SAP ERP Client Systems
o MDG-F 7.0: 1882127
o MDG-F 8.0: 2134044
MDMGX Corrections in SAP ERP Client Systems
o 1783851
o 1880169
o 2134044
SAP ERP Audit Information for MDG 7.0
o 2134044
o 2140352
SAP ERP Group Accounts for MDG 7.0
o 2082479
16.11 Financial Data
Title Description and Documents

SAP Note 2021246 contains spreadsheets for the
Data Model Metadata
Financials data model 0G.
SAP Note 2337685 contains a spreadsheet with an
Standard Validations overview of SAP pre-defined validations that are
executed by the system when validating data.
Overview of MDG-F This guide provides you with foundation knowledge
about financial data and its related governance solution
financial governance (MDG-F).
This guide provides you with expert knowledge for
ALE Replication using the Same setting up an ALE scenario for the replication of MDG-F
Client in MDG-F entities into the same physical client system. MDG hub
and ERP system share the same client.
Cross-Entity Derivation in MDG-F This guide provides you with expert knowledge
for implementing a custom cross-entity derivation for
MDG-F entity types. It covers the key concepts and
implementation details in general and includes a real-life
example of the MDG-F data model 0G.
Seite 194 von 214

Enable Changeable IDs in MDG-F This guide provides you with expert knowledge
for enabling the changeable ID functionality for MDG-F
entities. It describes the key concepts and
implementation details as well as possible enhancement
options.
Enable Dynamic Parallel Approval for This guide provides you with expert knowledge
for creating parallel approval workflow steps using a
Company Code Data in Rule-based
rule-based workflow when the parallel number is
Workflow
determined dynamically.
Enable HANA Search in MDG-F This guide provides you with expert knowledge
for enabling the HANA search for MDG-F. It describes
the key concepts and implementation details as well as
possible enhancement options.
Enable multi-copy of Accounts in This guide provides you with expert knowledge
Company Code in MDG-F for enabling the copy functionality for a single Account in
Company Code to multiple target Accounts in Company
Code. It describes the key concepts and implementation
details as well as possible enhancement options.
Enable Primary Cost Elements for This guide provides you with expert knowledge
Accounts in MDG-F for enabling the one-step creation of Primary Cost
Elements for Accounts. It describes the key concepts
and implementation details as well as possible
enhancement options.
This guide provides you with expert knowledge
Extend Data Model 0G by New Fields for extending the MDG-F data model 0G by new fields. It
in MDG-F describes the key concepts and implementation details
as well as possible enhancement options.
Read Approval Information via MDG This guide provides you with expert knowledge
APIs in MDG-F for reading approval information for MDG-F entities
using the MDG APIs. It describes the key concepts and
implementation details as well as possible enhancement
options.
Use the Master Data Management This guide provides you with foundation knowledge for
Generic Extractor for Initial Load in performing an initial load of master data into the financial
MDG-F governance (MDG-F) data model.
Remote Where-Used List: Example This guide demonstrates how to use the remote where-
Implementation used-list in MDG. The standard delivery includes a
generic user interface and an example Business Add-In
(BAdI) implementation for the ACCOUNT entity type of
the 0G data model. In this document, we use the default
implementation as an example of all implementations.
In this article we look at two different approaches for
extending the 0G data model of MDG-F. In the first
MDG-F Extensibility: Ways of section, we extend the 0G model directly. In the second
Extending the 0G Data Model section, we extend a copy of 0G. Finally, we compare
the advantages and disadvantages of the two
approaches.
How to Extend New Attributes for Description how to extend new attributes for entity type
Certain Entity Type
Seite 195 von 214

Seite 196 von 214

17 BUSINESS SCENARIO Configuration Business Partner

(BP)
SAP Master Data Governance for Business Partners, Customers or Suppliers (MDG-BP/C/S) provides
business processes to find, and maintain business partner, customer or supplier master data. It supports data
governance in a central hub and the distribution to connected operational and business intelligence systems.
The processes are workflow-driven and can include several approval and revision phases, and the
collaboration of all users participating in the master data maintenance.
This how to guide provides you with the foundation knowledge you need to know about business partner,
customer and supplier data and their related governance solutions.
17.1 SAP NOTES AND LINKS
In addition to the detailed explanations written in this document, please see the following SAP Notes and links
for further important information:
1637249 MDG: Information for efficient message processing
2105467 MDG Performance
2221398 MDG-BP/C/S/CA: (Un-)Supported Fields in Data Model BP
2561461 Scope of support for SAP Master Data Governance (MDG)
2847807 MDG-BP/C/S/CA: Usage of MDG Tools and Processes
Configuration and Enhancement of SAP Master Data Governance
Web Dynpro & Floorplan Manager
17.2 BACKGROUND INFORMATION
MDG offers different solutions in the business partner area:
• MDG-BP for Business Partners

• MDG-C for Customers
Seite 197 von 214
• MDG-S for Suppliers
MDG-BP is the foundation for MDG-C and MDG-S. Each customer and supplier are always based upon a
business partner. You cannot create a customer or supplier without a corresponding business partner. MDG
re-uses the common SAP Business Partner as available in each SAP system via transaction BP.
MDG-C is an extension of MDG-BP governance. It adds the specific tables of customer master data as
available in each SAP S/4 HANA system in transaction BP using a customer role (or in old SAP ERP
systems via transactions XD0*).
MDG-S is an extension of MDG-BP governance. It adds the specific tables of supplier master data as available
in each
SAP S/4 HANA system in transaction BP using a supplier (vendor) role (or in old SAP ERP systems via
transactions
XK0*).
From a technical perspective, the MDG solutions are implemented in two different software layers. The
general business partner components are built in the MDG foundation (MDG_FND) layer whereas the
customer and supplier components belong to the MDG application (MDG_APPL) layer. This is important to
remember if you plan enhancements of your solutions.
17.3 FUNCTIONAL RESTRICTIONS
The following restrictions apply:
• All information published in the how to guide correspond to the current release of SAP MDG,
Central Governance being available for public use.
• If your system is an older version of SAP MDG, Central Governance some functionality mentioned in this
how to guide might not exist.
17.4 STEP BY STEP EXPLANATION
17.4.1 Data Model
The MDG data model for business partners, customers and suppliers is model BP. A detailed list of all fields
being supported by the data model is provided by SAP note 2221398 MDG-BP/C/S/CA: (Un-)Supported Fields
in Data Model BP.
Seite 198 von 214

Use report USMD_DISPLAY_DATA_MODEL with data model BP to display its current state in your local
system.
The entity types of the model are mainly reuse entity types. The active data of the model is stored in existing
database tables of the SAP system (for example the business partner is stored in table BUT000, the customer
is stored in table KNA1, the vendor is stored in LFA1, and so on). The MDG staging tables are used for the
inactive version of the data that is currently processed within a governance process.
17.4.2 Multiple Assignments
Multiple Assignments allow you to link one or more customers / suppliers to a single business partner. Within
SAP MDG, the functionality exists since MDG 6.0. MDG client systems having the release version S/4 HANA
1809 or newer support the functionality, too.
17.4.3 Hierarchies
MDG-BP, MDG-C and MDG-S support the creation and maintenance of analytical hierarchies. The hierarchies
are built using the business partner. MDG specific flexible entity types are used for modelling the hierarchies.
These do not relate to any re-usable SAP Business Partner, Customer or Supplier hierarchy.
The data is solely stored in the generated MDG tables. Data replication is not available.
Data maintenance is supported either by the generic MDG user interfaces for collective and hierarchy
processing, or via the enhancements of the single object maintenance user interfaces as introduced by MDG
9.0.
Seite 199 von 214

17.4.4 Customer / Vendor Integration (CVI)

Customer and supplier governance are both based on business partner governance. In MDG the business
partner is the leading object. Using MDG, a business partner is always created.
MDG reuses the existing principles of the Customer / Vendor Integration (CVI). Depending on the CVI
configuration and the entered data, a customer and/or supplier record is created in addition to the business
partner. Taking a detailed look at the related database tables it is obvious, that some fields are identical in
the different entity types. CVI is a generic tool that can synchronize parts of the business partner master data
with the related ERP customer and supplier master data and vice versa.
MDG
UI: Maintain Name 1
Activate
Change Request
SRM
SOA
BUT000 BUT000
CVI Synchronization
R/3 4.6C
ALE
LFA1 & KNA1 LFA1 & KNA1
The figure shows the flow of the field Name 1 as example. The data is maintained in the business partner part
of the user interface for either customer or supplier governance. As soon as the related change request is
approved, data activation stores the field in the business partner table BUT000. This triggers CVI, which
creates an additional entry in the related tables for customer master data (table KNA1) and vendor master data
(table LFA1).
One benefit of this behavior is the simplified data replication. If the newly created MDG records are sent to an
SRM system, the system uses the business partner data. SRM neither knows the customer nor the vendor
since this is ERP specific data. If an (older) ERP system is the target receiver, it is possible to replicate either
the customer data, or the vendor data, or a combination of both, in a direct way (for example, using the common
DEBMAS or CREMAS IDocs). All records in all systems have the same value for Name 1.
Seite 200 von 214

CVI synchronizes the following segments and fields:
• General Data
o Names
o Search Terms
o Trading Partner
o Business Partner Category
▪ ERP customer and supplier do not differentiate between organizations, persons and
groups. Therefore, all business partners are treated as organizations.
• Address Data
o The business partner can handle multiple addresses. This feature is not available for ERP’s
customer and supplier. Therefore, only the standard address is synchronized.
• Communication Data
o Only address dependent communication data is synchronized.
• Bank Accounts
• Industry Sectors
o The business partner can handle multiple industry systems and sectors. This feature is not
available for ERP’s customer and supplier. Therefore, only the standard industry sector of the
standard industry system is synchronized.
• Tax Numbers
o The business partner stores tax numbers in a table format. ERP customer and supplier use
simple fields combined with a table for European VAT Numbers. CVI takes care of the correct
synchronization of the business partner table with the fields and tables for customer or supplier.
When you consider an extension of MDG, you can choose from several options to add tables and fields. Your
choice strongly depends upon the following question: Which entity receives the additional information?
The following scenarios are possible:
• The new field or table is available only in the business partner.

• The new field or table is available only in the customer or only in the supplier.
• The new field or table is available in both the business partner and in either the customer or in the
supplier.
Each extension requires a specific sequence of steps that must be implemented correctly. Detailed how-to
guides explain each extension option.
CVI is used by MDG. It is neither developed nor maintained by MDG. The synchronization happens during
the activation of master data, and always in the following direction: from the business partner to the
Seite 201 von 214

customer or the supplier. During the setup phase of MDG-C and/or MDG-S it is possible to use the CVI
Synchronization Cockpit to create business partners from existing customers or vendors.
All MDG-C or MDG-S related use cases require a valid configuration of the CVI customizing. You can apply
→ →
settings in Customizing via Cross-Application Components Master Data Synchronization Customer
Vendor Integration.
MDG’s core scenario of central master data governance requires that you set up Customizing to
enable the synchronization direction BP to Customer / Supplier. This involves the following tasks:
• Defining at least one business partner role that triggers the creation of a customer / supplier.
o It is possible to define multiple roles. If you do this, you must assign the correct role when
maintaining the user interface. If you define only one role, the system uses the role
automatically when it stores the business partner in the active area.
o If you use either the Customer Like UI or the Vendor Like UI, you must define a unique role in
customizing. If you add multiple roles, you need to either derive the default role to be used, or
to add the list for business partner role maintenance in the UI’s customizing.
• Defining a mapping of the business partner grouping to its related customer / supplier account group.
o The MDG UIs do not enforce the maintenance of the BP grouping. If a user does not select
any BP grouping, the system chooses a default grouping based on the business partner ID in
use. If a business partner ID is maintained, the default grouping for external numbering is
used. If no business partner ID is maintained, the default grouping for internal numbering is
used. You must correctly
configure the related BP groupings when applying customizing settings for CVI.
o The group mapping defines the key mapping implicitly since each Business Partner / Customer /
Supplier (account) group is assigned to a specific number range. Ensure that the respective
number ranges match, especially if you use the same numbers for the BP and for the customer /
supplier.
o The first customer / supplier that is added to a BP is the “standard assignment”. This
assignment
derives its account group according to configuration specified in customizing settings for CVI.
The account group can only be changed manually in the MDG UIs if you have enabled the
flexible grouping functionality. Additional assignments require the manual selection of the
account group.
o If you use either the Customer Like UI or the Vendor Like UI, only the following
numbering combinations for BPs to customers / suppliers are allowed:
▪
BP internal and C/S internal (results in different IDs)
▪ BP internal and C/S external with same number (results in identical IDs)
▪ BP external and C/S external with same number (results in identical IDs)
▪ Other combinations would cause a deadlock in the UI.
• Making sure to check if further settings / mappings on segment level (e.g. industry sectors) are required.
Seite 202 von 214

MDG processes do not require that you set up the synchronization direction Customer / Supplier to BP. This
direction is only useful if you want to transfer existing customers or suppliers to BPs. Techniques for doing this
include using the MDS Load Cockpit functionality of CVI.
A detailed description of the CVI is available in the SAP Application Help.
17.4.5 Access Classes
Data model BP being a reuse area model requires the implementation of an access classes that is
responsible for all actions related to the reuse area: read and store the data from and in the reuse area
database tables, derivations, validations, etc.
MDG uses a single access class that distributes all calls to different, object-specific handler classes. This
allows an extension of the access class simply by creating and registering a custom handler class. The access
class is only responsible for controlling the calls. The actual execution of the calls, which involves, for example
reading data or saving data, is implemented within the handler classes. Following the segregation of duty
principle there is a handler for each object (in other words one for business partner, one for multiple
assignment, one for customer, and one for supplier). This handler alone is fully responsible for the related
object (in other words, the supplier handler must never change the customer object).
Access classes are required to route the calls by the MDG framework to the specific handler implementations.
Since MDG-BP, MDG-C and MDG-S consist of multiple software layers, a single access class would not be
enough for this need. Therefore, the implementation consists of three classes in a hierarchy with inheritance:
• CL_MDG_BS_BP_ACCESS_MASTER
o The master class is the one being called by the MDG framework. Its object instance depends
on the current software layer it is running in. In the MDG foundation layer, it is a reference of
class CL_MDG_BS_FND_ACCESS whereas in the MDG application layer it is a reference of
class CL_MDG_ECC_ACCESS. The class implements the MDG framework's access interface
and provides some generic functionality.
• CL_MDG_BS_FND_ACCESS
o This class is the MDG foundation layer implementation.
o It inherits from class CL_MDG_BS_BP_ACCESS_MASTER .
o It contains both generic implementations usable for all entity types of MDG-BP Customer
Governance (MDG-C) and Supplier Governance (MDG-S) as well specific coding for all entity types
of MDG-BP.
• CL_MDG_BS_ECC_ACCESS
o This class is the MDG application layer implementation.
o It inherits from class CL_MDG_BS_FND_ACCESS.
o It contains only coding for all entity types of Customer Governance (MDG-C) and Supplier
Governance (MDG-S).
Seite 203 von 214

If you want to create an extension of MDG, it is strictly not recommended to enhance existing access
classes respectively to create an access class of your own. We recommend that you implement a
specific handler class instead.
All calls from the access to the handler classes are triggered by the access class. Therefore, the access class
collects a list of registered handlers consisting of both predefined SAP handlers as well as custom handlers
first. Then the access class calls each handler within a loop. SAP owned handled classes are usually called
before custom handler classes.
17.4.6 Handler Classes
The link between an access class and a handler class is the handler interface
IF_MDG_BS_BP_ACCESS_HANDLER. A handler class must implement this interface. Since major parts of the
application logic needed for MDG-BP, MDG-C, and MDG-S is the same for each object, two abstract classes provide
this common implementation. In addition, object specific handler classes provide dedicated functionality only for the
object the class is responsible for. all classes are implemented in a hierarchy with inheritance to support the needs of
the different software layers:
• CL_MDG_BS_FND_HANDLER
o CL_MDG_BS_BP_HAN
DLER o
CL_MDG_BS_ECC_HANDL
ER
▪
CL_MDG_BS_MLT_ASSGNMNT_HANDLER
▪ CL_MDG_BS_CUST_HANDLER
▪ CL_MDG_BS_SUPPL_HANDLER
All classes strictly follow the segregation of duty principle. A single handler is responsible for a single object
only.
If you want to extend MDG by creating your own handler classes, there are several possibilities. A general
recommendation for the creation of a custom handler class is that your new class inherits from either the
abstract foundation handler or from the application handler. Deciding which parent to choose from the
available SAP handlers depends on the actual use case of the extension. In some cases, it might even make
sense to choose one of the SAP predefined object handlers as a parent.
Seite 204 von 214

17.4.7 Abstract Foundation Handler
Class CL_MDG_BS_FND_HANDLER is the abstract foundation handler in the MDG_FND software layer.
It contains generic and reusable coding for all entity types of MDG-BP, MDG-C and MDG-S. It introduces several
static attributes and constants that are reusable by all other classes inheriting from the abstract handler. Some
examples are:
• The MDG-BP specific derivation buffer GS_BP_EXTERN_DERIVED_DATA
• The MDG-BP specific active data buffer GT_BP_DATA_DB
17.4.8 Abstract Application Handler
Class CL_MDG_BS_ECC_HANDLER is the abstract application handler in the MDG_APPL software layer.
It contains only reusable coding for multiple assignments, MDG-C and MDG-S. It introduces several static
attributes and constants that are reusable by all other classes inheriting from the abstract handler. Some
examples are:
• The derivation buffer GS_MLT_AS_DERIVED_DATA

• The derivation task buffers BP_ROOT_TASK or GT_MLTAS_TASK
• The active data buffer GT_ECC_EXTERN_DB
17.4.9 Business Partner Handler
The MDG-BP specific handler class is CL_MDG_BS_BP_HANDLER.
It inherits from class CL_MDG_BS_FND_HANDLER. It provides the business partner-specific

implementation of the handler interface.
This class is a valid parent for a custom handler class if the use case is a modification or enhancement of the
existing application logic of the business partner.
If you have enhanced the data model with a custom entity type next to or directly below the business
partner entity type, it’s recommended to create a custom handler class inheriting from the abstract
foundation handler.
Seite 205 von 214

17.4.10 Multiple Assignment Handler
The multiple assignment specific handler class is CL_MDG_BS_MLT_ASSGNMNT_HANDLER.
It inherits from class CL_MDG_BS_ECC_HANDLER. It provides the multiple assignment-specific

This class is valid parent for a custom handler class if the use case is a modification or enhancement of the
existing application logic of the multiple assignments.
If you have enhanced the data model with a custom entity type next to or directly below the multiple
assignment entity type, it’s recommended to create a custom handler class inheriting from the abstract
application handler.
17.4.11 Customer Handler
The MDG-C specific handler class is CL_MDG_BS_CUST_HANDLER.
It inherits from class CL_MDG_BS_ECC_HANDLER. It provides the customer specific implementation of the
handler interface.
existing application logic of the customer.
If you have enhanced the data model with a custom entity type next to or directly below the customer entity
type, it’s recommended to create a custom handler class inheriting from the abstract application handler.
17.4.12 Supplier Handler
The MDGS specific handler class is CL_MDG_BS_SUPPL_HANDLER.
It inherits from class CL_MDG_BS_ECC_HANDLER. It provides the supplier (vendor) specific

existing application logic of the supplier (vendor).
If you have enhanced the data model with a custom entity type next to or directly below the supplier entity
type, it’s recommended to create a custom handler class inheriting from the abstract application handler.
Seite 206 von 214

17.4.13 Data Derivation
The data derivation is part of the SAP handler classes. You can use data derivation to create, change, or
delete data based upon either user actions in the UI or data inbound or both. An example is the automated
creation of default partner functions as soon as a sales area is created in the customer UI. From the UI
perspective, a derivation is triggered during the start of the UI application as well as during each UI round-trip
triggered by the user. During data inbound derivations are executed, too.
The SAP handlers implement the derivation in two phases.
• The handlers analyze the current changes applied in the User Interface or in inbound processing. The
application of these changes comes via the framework to the handler class. The data is buffered within
the handlers. If any actions are required due to the new data, related tasks are being buffered, too.
Related coding is available in the method BUFFER_DERIVED_DATA of the handler classes.
• The handlers perform the derivation according to the given tasks and buffered data. Related coding is
available in the method DERIVE_DATA of the handler classes.
There is another special derivation option that is triggered by a change of the business partner key. In that
case the MDG framework calls the handler method DERIVE_DATA_ON_KEY_CHANGE.
17.4.14 User Interfaces
The user interfaces (UI) for single object maintenance in MDG-BP, MDG-C and MDG-S are built using
Floorplan Manager (FPM) and its Business Object Layer (BOL) / Generic Integration Layer (genIL)
integration.
17.4.15 Generic Interaction Layer (genIL)
The genIL layer consists of a genIL model and one or more genIL implementation classes for the specific model.
genIL models are defined and maintained in the SAP backend with transaction
GENIL_MODEL_BROWSER. genIL implementation classes are built within the common transactions SE24
or SE80.
The genIL model of MDG-BP, MDG-C and MDG-S reflects the introduced separation of objects due to
multiple software layers, too. The basis is the business partner genIL model component BUPA which is
extended by customer and supplier nodes in the genIL model enhancement BUPA_CUSP.
A genIL model basically consists of objects and relations.
Seite 207 von 214

• Objects consist of attributes. Each attribute reflects a usable field for the user interface.
• Relations connect one object to another. They define the cardinality of objects in a relation, too. Relations
are reflected in the user interface by the wires (connections) from one UIBB to another. It is mandatory
that the UIBB hierarchy in the overview page is consistent to the genIL object hierarchy as defined by the
relations.
The genIL component BUPA is modelled. It is not generic. Any enhancement must be added manually. If you
compare the genIL model BUPA (or BUPA_CUSP) with the MDG data model BP, you will notice that the
hierarchical structuring is identical. It is important to add your enhancements at the same place. You will also
notice that names differ. A mapping can be viewed for SAP defined entity type in view cluster
VC_MDG_BS_GENIL respectively maintained for custom entity types in view cluster VC_MDG_BS_GENIL_C.
The important parts of an object are the key structure and the attribute structure. Both must be existing ABAP
DDIC structures. The key structure is used internally by genIL. The sub-object’s key structure must always
contain the key fields of its parent. The attribute structure is used by FPM during the UI creation. It defines the
field catalogue that is available for creating a list or form UIBB. If a key field shall be visible respectively
maintainable in the UI, it must be part of the attribute structure, too.
Each genIL model component respectively enhancement requires exactly one implementation class. With regards
to the complexity of the MDG-BP, MDG-C and MDG-S solution this might be considered as a limitation since the
MDG solutions would need implementation classes for each specific object. To solve this challenge the MDG-BP,
MDG-C and MDG-S genIL implementation consists of a strict class hierarchy where each class inherits from its
parent class:
1. CL_MDG_BS_GENIL: the generic genIL implementation for all MDG solutions
2. CL_BS_GENIL_BUPA: the genIL implementation for MDG-BP
3. CL_BS_GENIL_MLT_ASSIGNMENTS: the genIL implementation for multiple assignments
4. CL_BS_GENIL_SUPPLIER: the genIL implementation for MDG-S
5. CL_BS_GENIL_CUSTOMER: the genIL implementation for all MDG-C
Class CL_BS_GENIL_CUSTOMER is defined in the genIL model enhancement BUPA_CUSP. The class
hierarchy
ensures that always all classes are executed during design and runtime of the UI. It is strictly mandatory that
each
custom enhancement of the genIL model which needs to use an own implementation class inherits from
CL_BS_GENIL_CUSTOMER. Otherwise it might come to unforeseen errors during design and runtime of the
UI.
Seite 208 von 214

The generic implementation in class CL_MDG_BS_GENIL contains a type-based mapping from the UI data
structures into the MDG entity data structures and vice versa. This mapping works fine if the used data type of
the source and target field is identical. If this is not the case, or if multiple fields are using the same data type,
the generic mapping fails
which might lead to disappearing values in the UI. To resolve this issue, it is possible to re-define one of the
following methods:
• IF_BS_TYPECASTED_MAP_ASSISTANT~TARGET_FIELD_NAME
o The method allows defining a strict field mapping based upon the source structure and field
name to the target structure and field name.
• IF_BS_TYPECASTED_MAP_ASSISTANT~TYPE_ALTERNATIVE
o The method allows defining an alternative data type for the generic type-based mapping
based upon the source structure and field type to the target structure and field type.
• “Example” implementations are pre-defined by SAP in the above-mentioned object-specific classes.
The business partner hierarchy of data model BP uses a dedicated genIL component called MDGBPH. The
model is dynamically generated according to the MDG data model BP. Its implementation class is
CL_MDGBP_GENIL_ADAPTER_HRY.
17.4.16 Floorplan Manager
The user interfaces (UI) for single object maintenance in MDG-BP, MDG-C and MDG-S are built using
Floorplan Manager (FPM) and its Business Object Layer (BOL) / Generic Integration Layer (genIL)
integration.
Some advantages by using FPM mentioned are:
• Loose coupling of the UIs to the MDG specific processes
• High flexibility for the creation of the UIs. The huge number of fields to be displayed is split into small UI
Building Blocks (UIBBs). UIBBs support lists, forms and special kinds like pop-ups, search input and
search results.
• Possibility to create object specific UIs to create a common look and feel and/or a similarity of the
MDG UI compared to the SAPGUI maintenance transactions
• Reuse of existing tables, structures and fields (including naming) during the UI creation
Seite 209 von 214

17.4.17 Context Based Adaptations

A context-based adaptation (CBA) is an FPM concept that allows changing the UI in a flexible way based upon
given values (e.g. application parameters, user input, and others). A CBA consists of an Adaptation Schema
that consists of one or more Adaptation Dimensions. Using both it is possible to create various adaptations of
the UI (e.g. a different layout of an overview page (OVP), or additional/removed row actions within a list UIBB,
and so on). It is possible to combine several dimensions to create a very specific adaptation.
The CBA concept is based on the common FPM event handling. It is possible to trigger one or more CBA
events that are handled by FPM's event loop processing.
Refer to chapter Context Based Adaptations (CBA) in the FPM Cookbook on SDN for more details.
The layout of an OVP can only be changed with a CBA during the startup of the application. It is not possible to
change the OVP (e.g. the sequence of UIBBs) using a CBA during UI roundtrips. CBAs can only change the
layout of single UIBBs for each round-trip.
FPM's event handling concept allows triggering multiple CBA events during one UI round-trip. But FPM
does not cumulate the dimension information given within each event. Consider a scenario with the
following sequence of events:
• A first event triggers a CBA for dimension ACTION (for example by defining the value DELETE to
trigger the Mark for Deletion UI),
• A second CBA event contains only some information for a different dimension without the dimension
ACTION.
In this scenario, the CBA for the ACTION will not be NOT processed since its value is reset to initial
Still, there is a possibility to trigger complex CBAs described in the related use case Trigger my own CBA Event.
The SAP delivered UIs support and use CBAs. There is a predefined schema BP_ADAPTS having several
dimensions that are actively used within the UIs. The actual UI that is being displayed to a user in the web
browser is determined from various components of the UI configuration:
• Personalization
• Enhancements
• Context Based Adaptations
• Base Configuration
The general rule is that the personalization is the strongest component. This is best explained with an example.
Seite 210 von 214

The base configuration defines the overview page as a list of UIBBs. Since a user does not want to scroll, he or
she creates a personalization of the page introducing a stacking of the UIBBs in tab-strips. A UI designer
decides to create a context-based adaptation that sets a single UIBB to “hidden and excluded from event loop”.
All users not having a personalization will not see this UIBB anymore. The user with the personalization set is
unaffected by this change. This is because the UIBBs that are hidden and excluded from event loop still belong
to the OVP. They can be added to the OVP using personalization. Since the user has created a personalization
that shows the UIBB (the personalization was created before the CBA), the UIBB is still visible. To exclude the
UIBB you must either reset personalization or delete the UIBB in the CBA.
17.4.18 UIBBs & OVPs
UIBBs define the actual form or list usable for data maintenance. UIBBs are grouped into Overview Pages
(OVPs) to finally build the UIs for end users.
UIBBs can be reused multiple times in different OVPs. This is done by the different MDG solutions to ensure a
stable look and feel of the UIs. For example, the UIBB for maintaining the standard address is the same
technical UIBB being used by nearly all the following OVP configurations.
MDG-BP provides the OVP BS_OVP_BP as main UI for business partner governance. You can find all
UIBBs and configurations in package MDG_BS_BP_BOLUI.
MDG-C provides several independent UI applications for maintaining customer master data. All applications
re-use common look and feel of the business partner UI and either change or extend it specifically for the
customer:
• BS_OVP_CU
o Main UI for customer governance.
o Reuses the overview page for the business partner UI.
o Extends this page with the customer multiple assignments list. This list is the starting point for
the
maintenance of ERP customer master data.
o The UI consists of several edit pages with forms and list User Interface Building Blocks (UIBB).
• BS_OVP_CU_VL
o Referred to as the ERP Customer Like user interface.
o Does not use multiple assignments.
o Layout is synchronized, as far as possible, with the old SAP ERP GUI transactions used to
maintain customers (XD0*).
• BS_OVP_CU_LCC
o Lean Requestor user interface for customer master data. The configuration consists only of
a very limited sub-set of attributes.
• BS_OVP_CU_ORG
Seite 211 von 214
o Lean Organizational user interface for customer master data. The configuration is usable only
for data maintenance or approval steps. It consists of object specific sub-sets like only
company codes or only sales areas. The intended usage is a scenario using the sub-workflow
that assigns work items for company codes or sales areas to specific user groups only.
All objects are available in package MDG_BS_ECC_CUSTOMER_BOLUI.
MDG-S provides several independent UI applications for maintaining supplier master data. All applications
re-use common look and feel of the business partner UI and either change or extend it specifically for the
supplier:
• BS_OVP_SP
o Main UI for supplier governance.
o Reuses the overview page for the business partner UI.
o Extends this page with the vendor multiple assignments list. This list is the starting point
for the maintenance of ERP vendor master data.
o The UI consists of several edit pages with forms and list User Interface Building Blocks (UIBB).
• BS_OVP_SP_VL
o Referred to as the ERP Vendor Like user interface.
o Does not use multiple assignments.
o Layout is synchronized, as far as possible, with the old SAP ERP GUI transactions used to
maintain vendors (XK0*).
• BS_OVP_SP_LVC
o Lean Requestor user interface for supplier master data. The configuration consists only of
a very limited sub-set of attributes.
• BS_OVP_SP_ORG
o Lean Organizational user interface for supplier master data. The configuration is usable only for
data maintenance or approval steps. It consists of object specific sub-sets like only company
codes or only purchasing organizations. The intended usage is a scenario using the sub-
workflow that assigns work items for company codes or purchasing organizations to specific
user groups only.
All objects are available in package MDG_BS_ECC_SUPPLIER_BOLUI.
The multiple assignment UI consists of re-usable components only. There is no specific OVP. There are several lists
and forms available for the different assignment categories of business partner, customer and supplier. This simplifies
the creation of object specific OVPs. All objects are available in package MDG_BS_ECC_BP_MLT_ASSGMNT.
If you use both MDG-C and MDG-S, OVP BS_OVP_BP_ALL combines both the customer and supplier related
UIBBs into one, singe OVP.
Seite 212 von 214

Seite 213 von 214

Seite 214 von 214

Sap MDG-F

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sap MDG-F

Uploaded by

Copyright:

Available Formats

Customizing &

Dipl.-Wirtsch-Ing. Hans-G. Emrich

SAPCon Seite 2 von 214

3.12.3 Procedure .............................................................................................................................. 51

SAPCon Seite 3 von 214

3.17 Workflow Description ................................................................................................................ 89

SAPCon Seite 4 von 214

6.11 Creating a Logical System ...................................................................................................... 127

SAPCon Seite 5 von 214

11.4 Optional: Run a Simulation of the Import ...................................................................... 167

SAPCon Seite 6 von 214

17.2 BACKGROUND INFORMATION ............................................................................................ 197

SAPCon Seite 7 von 214

Inconsistencies in financial master data arise from local, non-standardized

Inconsistent Master Data across Enterprise

SAPCon Seite 8 von 214

Specifics of SAP MDG-F:

Consolidation of company financial data with the financial data of the

Mapping between corporate and operative standard charts of accounts

Time-based and period-based versioning: Transparency, traceability, edition

Improving data quality

Stabilization and acceleration of business processes

Optimization of process efficiency

Risk mitigation through consistent data root

Flexible response to changes

Reuse of individual, existing SAP functionalities and data structures

SAPCon Seite 9 von 214

Rule-based workflow is integrated via BRFplus, can be adapted quickly

SAPCon Seite 10 von 214

2 Business Process Flows for G/L Account

2.1 Functionalities of MDG-F

SAPCon Seite 11 von 214

With MDG-F you will be able to:

Have consistent financial master data across the entire organization;

2.1.1 Copying of accounts

SAPCon Seite 12 von 214

2.1.2 Enhanced BCV content to display hierarchy changes

2.1.3 Importing Company Data

2.1.4 Remote Where-Used List

2.1.5 SOA Services for Consolidation Systems

2.1.6 Enhancements for Data Model 0G

2.1.7 Group Accounts as Items

Next to this you also have the possibility to:

SAPCon Seite 13 von 214

• Enhanced Edition Management;

o Reduce maintenance efforts with high Data quality

o Delivers Consistent Definition, Authorizations and replication of key master data

o Eliminates error prone manual maintenance across multiple systems

o Enables governance, compliance and transparency through integrated staging,

o Trusted Data Quality Information

SAPCon Seite 14 von 214

o One source of truth

o Flexible and unified view of all information

o Data flow transparency

SAPCon Seite 15 von 214

Standard process flow for creating and administering a G / L account

The standard process flow in MDG-F consists of three core activities:

Create G/L Account

2. Change Request Types

Create Contract Account

Two-step workflow for four-eyes-principle

Simplified, this business process is as follows:

SAPCon Seite 16 von 214