SAP MDG: The Beginner Handbook

1. What is MDG?

Master data (customers, suppliers, materials, cost centers) is the data many processes share. If two people create the same customer twice, invoices and reports go wrong. SAP Master Data Governance (MDG) is a hub where master data is requested, checked, approved and only then released to the systems that use it.

The building blocks you will meet

Configuration lives in MDGIMG (switch to Classic Mode → Central Governance → General Settings). Users work in NWBC (NetWeaver Business Client) or Fiori.

Deep dive: what MDG can do and where it runs

Seeing the three deployments

Training systems are usually co-deployed, which is why you can check results directly in MARA or BUT000. In a hub you would check the hub's active data, then the target after replication.

2. Host file setup for NWBC

NWBC opens through a web address like https://mdghost.company.com:44300/nwbc. If your computer cannot translate that name into the server's IP address (no DNS entry), the page will not open. The hosts file is a local phone book that fixes this.

1. Get the server IP, fully qualified hostname and HTTPS port from your Basis team.
2. Open Notepad as administrator (the file is protected). Open C:\Windows\System32\drivers\etc\hosts.
3. Add one line at the bottom: 10.10.1.25 mdghost.company.com mdghost (IP, full name, short name). Save.
4. Browse to https://mdghost.company.com:44300/nwbc. Accept the certificate warning if your lab uses a self-signed certificate. Log in with client, user and password.
5. You should see roles such as Business Partner Governance or Material Governance. Empty? Your user lacks PFCG roles.

Deep dive: what happens when you open the NWBC URL

Hands-on: complete setup and test

1. Collect details from Basis: IP, FQDN, HTTPS port, client number, your user.
2. Edit hosts. Windows: C:\Windows\System32\drivers\etc\hosts. Mac/Linux: /etc/hosts (use sudo). One line per server, IP FQDN shortname. Do not add https:// or a port; the hosts file holds only names.
3. Flush the cache. Windows: ipconfig /flushdns in a command prompt.
4. Test the name. ping mdghost.company.com must show your IP. If the IP is different, another entry or DNS wins; remove the duplicate.
5. Test the port. Browse to https://mdghost.company.com:44300/sap/public/ping. A short "OK" style answer proves the server and port work before you blame NWBC.
6. Open NWBC (/nwbc), log in. Menu entries depend on your PFCG roles.

3. The three domains

A domain is a ready-made package for one kind of master data: a standard data model, change request types, UI and rules.

MDG-BP

Customers and suppliers are both Business Partners with roles. You create the partner once and add roles, so name and address are never duplicated. Use Business Partner Governance → Search Business Partner → New in NWBC.

MDG-FI

Governs finance objects: accounts, cost centers, profit centers, and their groups. Typical changes: a new cost center, or an account opened in another company code.

MDG-M

Governs material master. A material has a general part (basic data) and many dependent parts (plant, storage, sales). Section 4 uses this domain as the worked example.

Deep dive: MDG-BP, the Business Partner

SAP replaced separate customer and supplier masters with one object: the Business Partner. The partner holds identity once; roles say how it is used (customer, supplier, contact...). In S/4HANA, Customer-Vendor Integration (CVI) keeps the classic customer and supplier tables filled behind the scenes.

• Category: Person, Organization or Group. It decides which name fields appear.
• Grouping: controls the number range (internal or external numbering) and which roles are allowed.
• Core table: BUT000; addresses ADRC; banks BUT0BK; identification BUT0ID. Look at these in SE16N after activation.

Scenario: create a supplier with bank data

1. NWBC → Business Partner Governance → Search Business Partner → New → Organization → Create. The duplicate check (section 8) runs first.
2. Fill Name, Search term, Grouping, and the address (street, city, postal code, country, region, language). Bad addresses are the top cause of failed validations.
3. Add the Supplier role. Company code data appears: reconciliation account, payment terms, payment methods.
4. Open Bank Details → add a row: country, bank key (IFSC for India), account number, account holder, and a Bank Details ID to tell several accounts apart. Banks are checked against the bank master; an unknown bank key raises an error.
5. Check and fix messages (this is where your BRF+ derivation can fill the bank country).
6. Submit, approve as per workflow, then confirm in SE16N: BUT000 (partner), LFA1 (supplier view) and BUT0BK (bank).

Deep dive: MDG-F, finance objects

Finance objects are time dependent: a cost center is valid from-to. MDG-F handles this with editions: a change request belongs to an edition with a validity date, which lets you plan next year's reorganisation without touching today's data.

Scenario: create a cost center

1. Gather: controlling area, cost center ID (for example YB1001), name, valid-from date, category, hierarchy node, company code, profit center, responsible person.
2. NWBC → Cost Center Governance (role names vary) → Create Cost Center.
3. Enter the data above. The hierarchy node places the cost center in the group structure; without it reports miss it.
4. Check, Submit and approve through the workflow.
5. Verify: KS03 displays the cost center; SE16N table CSKS shows the row.
6. Test negative cases: unknown profit center, past valid-from, missing hierarchy node. Each should return a message.

Deep dive: MDG-M, the material master

The material type (raw material, finished product, trading goods) decides which views exist. The industry sector sets screen defaults. Each organisational level (plant, storage location, sales org, valuation area) gets its own row, which is why one material can behave differently per plant.

Scenario: extend a material to a new plant

1. Pick an existing material (active, created earlier) and a plant that exists in the system.
2. NWBC → Material Governance → Search Material → open it → Change Material (starts a change CR).
3. Go to the Plant tab → add a row for the new plant. Maintain procurement type, MRP type, profit center, and any required storage location.
4. Add Valuation data if the plant has its own valuation area (price control and standard price).
5. Check, Submit, approve.
6. Verify: MM03 now lets you select the new plant; SE16N MARC has a new row with the material and plant; MBEW if valuation was added.

4. Data modelling and SMT mapping

A data model is the blueprint: which objects (entity types), which fields (attributes) and how they link (relationships). Path: MDGIMG → Central Governance → General Settings → Data Modeling → Edit Data Model.

Entity storage/use types

• Leading: parent key copied into the child key (Material → MARCBasic).
• Qualifying: the type 3 key joins the child key, so one material can have one row per plant.
• Referencing: optional link, stored as a normal field.

Walkthrough: inspect the standard MM model (display only)

1. MDGIMG → Data Modeling → clock icon on Edit Data Model. Switch to Display; choose MM. Why display: standard models must not be changed.
2. Entity Types → Position → search MARCBasic. Check its type (4).
3. Open Attributes. These fields come from table MARC. Verify in SE11: MARC has field FPRFM.
4. Relationships → Position → search Material (leading), WERKS (qualifying), PRCTR (referencing); find MARCBasic under To-Entity Type.
5. Visualize Data Model → Ctrl+F → MARCBasic to see the tree.

Walkthrough: build a custom data model

1. Edit Data Model → Inactive Data Models → New Entries: name YB (exactly 2 characters), description, active area MDG, prefix YBX (used to name generated objects). Save in a package.
2. Entity Types → New Entries → your entity, storage type 1.
3. Attributes → New Entries; reuse data elements from MARA so field definitions match standard SAP.
4. Activate. SAP generates staging tables and structures for each entity, named with your prefix.
5. Verify with SE38 program USMD_DATA_MODEL.

Structures and SMT mapping

Staging data is shaped differently from the real SAP tables. The Service Mapping Tool (SMT) holds the mapping rules that copy fields between them.

1. MDGIMG → Data Modeling → Generate Data Model-Specific Structures: select the model, view Structures (one per entity, prefixed) and Mapping (copy a name from the Staging → Active column).
2. Create and Edit Mappings → Open Mapping → paste the name → open MDG_BS_MAT_MARCBASIC → Details → Transformations → 0001 Field Mapping.
3. Select staging field MATERIAL on the right, MARC field MATNR on the left, click Map.

Standard mappings are locked; you can edit mappings only for custom data models.

Deep dive: what really happens to your data

Understanding the two storage areas explains almost every MDG behaviour.

Scenario: design a small custom model on paper first

Before touching SAP, write the design. Example: a training "product" master YB with plant-specific data.

Relationships: YPROD → YPRODPL leading; WERKS → YPRODPL qualifying; PRCTR → YPRODPL referencing. Rule of thumb: if the child key must be unique per something, that something is a type 3 qualifier.

Custom model: the execution checklist with checks

1. Create the model (Inactive Data Models → New Entries). Check: name is 2 characters, active area MDG, prefix chosen, saved in a transportable package (not $TMP if you will transport).
2. Create entity types. Check: each has a storage/use type; every entity (except 2 and 3 used only as keys) needs at least one key attribute.
3. Create attributes. Mark key attributes; set data element (reuse SAP elements such as MATKL so value helps and conversions come for free). Check: no attribute without a data element.
4. Create relationships exactly as in your table. Check: the To-Entity shows the child.
5. Activate. If it fails, read the log: typical causes are a missing key attribute, a relationship pointing to a missing entity, or a name clash.
6. Generate structures (Generate Data Model-Specific Structures) and look at the Structures and Mapping tabs. Check: one structure per entity with your prefix.
7. Verify with USMD_DATA_MODEL in SE38, which prints the model so you can compare with your design table.

Mapping in depth

A mapping is a list of "this source field goes to that target field" rules, grouped in transformations. A field mapping (like 0001) is the simplest: copy value X to Y. Reasons mappings exist: field names differ (MATERIAL vs MATNR), structures differ (one staging entity feeds several tables), or values must be converted. Edit them in the SMT editor (Create and Edit Mappings).

5. Process modelling

The process model decides how a change travels: which Change Request Type, which workflow steps, who approves. A CR type links a data model, a main entity and a workflow.

Static workflow CR, step by step

1. Create CR type (Process Modeling → Change Requests → Create Change Request Type): new Z entry, data model MM, description, Single Object, main entity Material. Why: this is the "ticket template".
2. Workflow: find a standard one at Workflows → Other MDG Workflows → Define Change Request Step Numbers, copy its name, paste it into the CR type. Why: reusing a standard workflow avoids building one.
3. Entity Types sub-node: add Material. Tells the CR which objects it may touch.
4. Business Activities: add e.g. MAT01 (create material). Save in a package; verify using Position search.
5. Assign processors: Assign Processor to Change Request Step Number (Simple Workflow). For your CR type and each step (0 to 5): agent type User, agent your user ID. Why: without an agent nobody receives the work item.
6. Test in NWBC → Material Governance → Search Material (HANA Search) → New → pick your CR type → fill unit, material type, sector, description → Save → Check → Submit → Send for Revision (with comment) → Finalize Processing → Approve. Open Workflow Log → Background Steps to see activation.
7. Verify in SE11 table MARA by searching the description.

Rule-based workflow (BRF+)

Static workflows send everything to the same people. A rule-based workflow decides at runtime, e.g. materials of one type go to Manager A, high value to Finance. You assign a rule-based workflow to the CR type, then build BRF+ decision tables that return the approver per step (initial, manager, business, final).

Deep dive: anatomy of a change request

Think of a CR as a courier envelope: the CR type is the envelope kind, the business activity says what is inside (create, change, mark for deletion), the entity types list which objects may be inside, and the workflow is the route.

Step numbers: what they mean

A standard workflow is a list of numbered steps such as draft, revision, approval and activation. The processor table asks "who gets step N?". Open Define Change Request Step Numbers for your chosen workflow to read what each number means before assigning agents; do not guess. Assign every step that creates a work item, otherwise the CR stops silently.

Scenario: two-level approval, tested end to end

1. Create CR type ZMAT01 (MM, Single Object, main entity Material) as in the steps above.
2. Assign processors: requester step = your user; approval step = a second test user (create ZAPPR1 in SU01 with the MDG material roles). Why two users: you see the work item land in a different inbox.
3. Log in as requester: create a material CR, Check (fix messages), Submit.
4. Log in as ZAPPR1: open the work item from SAP Business Workplace (SBWP) or the NWBC inbox, open the CR, Send for Revision with a comment.
5. Requester sees the comment, edits, submits again; approver Approves.
6. Check the CR status shows activated; open Workflow Log; confirm the row in MARA.

Rule-based workflow in depth

Typical real requirement: "Raw materials go to Purchasing; finished goods to Sales; value above 100,000 also needs Finance." Build a BRF+ decision table whose columns are the inputs (material type, plant, value) and whose result column is the agent or step. Activate the table and function, then reference it from the workflow configuration. Always test with one case per row.

6. UI modelling

MDG screens are built with Floorplan Manager (FPM) on Web Dynpro ABAP, so they are configured, not coded. A floorplan is the page layout; UIBBs (UI building blocks: forms, lists, trees) fill it; a feeder class supplies the data from the data model.

• Why UI modelling matters: you decide which fields users see, which are mandatory or hidden, and which roles get which screen.
• Standard screens exist for BP, FI and MM; copy them and adjust rather than starting empty.
• Open the UI in NWBC, use Adapt / Personalize to enter configuration mode, then change field properties in the Floorplan Manager configuration editor. Always keep changes in a transport.

Deep dive: how an MDG screen is assembled

MDG supplies feeder classes that read the data model, so a form UIBB can show an entity's attributes without ABAP. This is why adding a field to the data model makes it available to the screen.

Hands-on: show and enforce a field on the Material screen

1. Open the Material screen in NWBC. Use the personalize/configure option (often Ctrl+Shift+right-click → Settings → Adapt, or open the configuration in FPM_WB/SE80 if you know its name).
2. Select the Form UIBB that holds the field group. Choose Configure so the configuration editor opens.
3. In the editor, Add field from the list of available feeder fields (all attributes of that entity).
4. Set label, visibility, read-only and mandatory. Place it on the right row and column.
5. Save in a package and transport request. Never save to $TMP if the change must go to Quality.
6. Reload the app, open a CR and confirm the field is shown. Leave it empty and press Check to prove the mandatory flag works.

7. Business rules: validations and derivations

A validation checks data and raises a message (e.g. error if first and last name are empty). A derivation fills a field for the user (e.g. bank country = IN when blank). In MDG they run when you click Check or Submit. Two tools: BRF+ (no code) and BAdI (ABAP).

Custom validation (BRF+)

1. MDGIMG → Data Quality and Search → Validations and Enrichments → Define Validation and Derivation Rules, data model BP. Open the trigger function (the hook MDG calls).
2. Right-click → Create Object Node → Function, e.g. check_functionone.
3. Add Existing Data Object: pick an entity such as AD_NAME_P. Why: the rule can only see fields in its context.
4. Create a ruleset, insert a rule.
5. IF: first name is initial AND last name is initial. (AND is added with Add condition.)
6. Action: Log Message, type Error, with your text. Activate message, ruleset, function in that order (inner to outer).
7. Simulation: leave names blank → Execute and Display Processing Steps → see MSG_NAME.
8. Afterwards Disable Rule in Assigned Ruleset so test rules do not block real users.

Custom derivation (BRF+)

Same path, but right-click Derivation. Data object BP_BKDTL. IF bank country/region is initial → action Assign Value to Context: bank ctry/reg = IN. Activate, simulate (value changes to IN), then disable.

BAdI approach

For logic BRF+ cannot express: Validations and Enrichments → Business Add-ins. BAdI Define Validations/Derivations: open an implementation → Filter Values shows its data model → Implementing Class holds the standard method code (read it to learn). BAdI Derivation Across Entity Types derives a value in one entity from another.

Deep dive: BRF+ vocabulary

Which tool for which job?

Worked scenarios (use the same steps as above)

1. Postal code check. Data object: address entity (e.g. AD_ADDR). IF country = IN AND postal code length is not 6 THEN Log Message (Error) "Indian PIN code must have 6 digits". Why: wrong PIN codes break delivery and tax reports.

2. Search term derivation. IF search term is initial THEN assign it from the first 20 characters of the organization name (upper case). Why: users skip the field, and search later becomes unreliable.

3. Warning versus error. Use Error to stop submission and Warning when the user may continue (e.g. "Region not maintained"). Choosing wrongly either blocks good data or lets bad data through.

Order of execution and good habits

• Validations and derivations run when you click Check or Submit, not while typing.
• Activate from inside out: message → rule/ruleset → function. An inactive inner object makes the outer activation fail or silently use an old version.
• A disabled or inactive rule does nothing, which is the most common reason for "my rule is not firing". Also check the rule sits on the right entity (data model + entity must match).
• Keep one rule per business statement and name it so a colleague understands it in a year.
• Move to Quality or Production by transport; test rules by simulation with positive and negative cases.

8. Data quality: search and duplicates

Before creating a partner, MDG searches for an existing similar one. The search runs on SAP HANA using fuzzy matching: "Chenai Traders" can match "Chennai Traders" with a similarity score.

1. Create Search View (Data Quality and Search → Search and Duplicate Check): New → name, description, business object BP, HANA package name → Next → tick fields (BP Header, Address, Name1, Names of Organizations) → Save with transport → Generate. Why: it tells HANA which fields to index.
2. Define Search Application: choose HANA Search (HA); under Allocation of Search Help, confirm your view appears for the BP model.
3. Match Profile: new, data model BP, entity BP_HEADER → Relevant Fields → add each field (e.g. AD_NAME_O / Name1), sequence starting at 1, fuzziness such as 0.70. Higher = stricter (fewer false matches); lower = looser.
4. Configure Duplicate Check for Entity Types: pick BP, add your match profile and search help, Save.
5. Test: NWBC → Business Partner Governance → Search → New → Organization → Create, entering values that already exist. A duplicate message appears; continue anyway or hand over to duplicate handling.

Deep dive: how matching works

Two different features share the HANA index. Search finds records the user is looking for. Duplicate check compares the new record against all existing ones using the match profile.

For each relevant field the engine computes a similarity from 0 to 1 and combines them. Fuzziness is your tolerance: at 1.0 only exact text matches; at 0.70 small typos, missing letters and reordered words still match; very low values flood users with false hits.

Scores are illustrative to show the logic; real values depend on the engine.

Choosing fields and settings like a consultant

• Name fields: fuzzy (0.7 to 0.85). People mistype names most.
• Identifying numbers (tax ID, bank account): exact or very high (0.95+). If these match, it is almost always the same party.
• City, postal code: support fields; do not rely on them alone.
• Start loose in the test system, review hits with business users, then tighten.

Scenario: prove the check works

1. Create BP "Acme Traders Pvt Ltd" in Chennai through a normal CR and activate it.
2. Wait for the search index to refresh (ask Basis if it is not real-time).
3. Create a second BP with the same name. Expect the duplicate message listing the first BP.
4. Create a third with a typo. Expect a match shown with a lower score.
5. Create a fourth with a different name. Expect no message.
6. If step 3 does not match, lower fuzziness a little or check that the field is in both the search view and the match profile.

9. Data Replication Framework (DRF)

Approved data is only useful once target systems get it. DRF is the "delivery service": it picks changed objects and sends them to business systems through ALE/IDoc or SOA web services.

1. Technical settings (DRFIMG): define business systems and the connection (ALE logical systems in BD64/WE20/WE21, or SOA in SOAMANAGER).
2. Define custom settings: create a replication model with the data model, target business system and an outbound implementation (e.g. BP via ALE, Material via MATMAS).
3. Filters (optional): send only certain company codes or material types.
4. Run: automatically after CR activation, or manually with DRFOUT (select model → Start Replication).
5. Monitor: DRFLOG, plus WE02 for IDocs. Fix errors and re-run.

Key mapping matters when the target system uses a different ID than the hub; DRF stores both so later changes find the right record.

Deep dive: DRF vocabulary

Hands-on: replicate a material to another client (ALE)

A. Prepare the connection (once per target)

1. BD54: define logical systems, one for hub and one for target, e.g. MDGCLNT100 and ERPCLNT200. SCC4 assigns the logical system to the client.
2. SM59: RFC destination (type 3) named like the target logical system, test the connection.
3. WE21: a tRFC port using that destination.
4. BD64: distribution model: add model view, add message type (MATMAS for material; customer/supplier use DEBMAS/CREMAS), sender = hub, receiver = target. Generate partner profiles (WE20 shows them).

B. Configure DRF (DRFIMG, Define Custom Settings for Data Replication)

1. Define Technical Settings: create the business system and link its logical system; put it in a business system group.
2. Define Replication Models: name, data model MM, add outbound implementation for the material, assign the target business system. Standard implementations are delivered; select them rather than writing new ones.
3. Optional filters: for instance only material type FERT.
4. Decide the trigger: replication can run automatically after activation (how this is switched on depends on your release and CR type/workflow setup; confirm with your lead) or be started manually. Begin manual.

C. Replicate and prove it

1. Activate a material through a CR (section 5).
2. DRFOUT: choose the replication model, select the object (or all changed), start replication.
3. DRFLOG: status per object (success, error, waiting). Open an error to read the message.
4. WE02 (hub): the outbound IDoc status 03 means sent. In the target client WE02 shows inbound status 53 = posted.
5. Target client MM03: the material exists with the same data.

10. Roles and authorizations

Most "it does not work" tickets in MDG are really missing access. Plan access around four kinds of people.

• SAP delivers role templates per domain. Copy them to Z roles in PFCG, never edit the originals.
• Access is checked per CR type and per workflow step through MDG authorization objects (for example USMD_CREQ), so a user can create a material CR but not approve it. Confirm object names in SU21.
• Direct maintenance (MM01, XK01) should be locked for normal users, otherwise people bypass governance.
• Debug a refusal: user repeats the action, then runs SU53 to see the failed check.

11. Loading data and changing it in bulk

Projects rarely start empty. Three tools cover the common cases.

Typical initial-load sequence: extract from legacy; cleanse (remove obvious duplicates, fix addresses, standardise names); load a pilot of about 100 records into the test system; read every error; fix the data or the rules; load the rest; reconcile counts (SE16N row counts and spot checks) before sign-off. Fixing a validation is cheaper than fixing 10,000 records.

12. How an MDG project and daily support work

1. Requirements: which objects, which fields, who creates, who approves, which systems receive.
2. Design: data model sketch (as in section 4), CR types and approval matrix, UI field list, rule list, replication map.
3. Build in development: in this order, because each depends on the previous: data model, structures and mapping, CR types and workflow, UI, rules, duplicate settings, DRF.
4. Unit test every scenario with the positive and negative cases written in your design.
5. Transport Dev to Quality to Production with one transport per layer so a failure is easy to isolate. After importing a data model, check that generated structures exist in the target.
6. User acceptance test with real business users, then cut over and run the initial load.
7. Support: table below.

13. Quick revision

• MDG = request → check → approve → activate → replicate.
• Edit Data Model: types 1 root, 2 reference, 3 qualifier, 4 dependent; relationships leading, qualifying, referencing.
• Standard models are read-only; custom model names are exactly 2 characters.
• SMT: _2PP staging → active; _2STA active → staging.
• CR type needs: data model, main entity, workflow, entity types, business activity, processors.
• BRF+ order: function → data object → ruleset → rule → action → activate inside-out → simulate → disable.
• Duplicate check: search view → HA application → match profile → assign to entity → test.
• DRF: business systems → replication model → outbound implementation → DRFOUT → DRFLOG.

Menu paths and names can vary slightly by release; confirm against your own system.

14. Glossary

15. Viva and interview questions

Try to answer before opening each one. Answer pattern that interviewers like: definition in one line, why it exists, a small example, and one thing that can go wrong. Amber text below each answer is an example you can reuse.

A. Core quick-fire

B. Fundamentals, with examples

C. Data model and mapping

D. Process modelling and workflow

E. UI and rules

F. Data quality and replication

G. Scenario and troubleshooting questions

H. Describe your project (template)

I. Rapid-fire one-liners