Full questions with full answers — no sign-in required.
mediumBusiness Partner, Material and Finance Governance
1. A retail company wants to enforce that customer records cannot be saved without a valid VAT registration number format per country. How would you implement this using MDG data quality rules?
Implement a validation rule in BRFplus scoped to the customer entity, using a decision table or rule that checks the country key and applies a regex/format pattern for the VAT field. The rule is attached to the relevant process step (e.g., before activation) and raises an error message if the format doesn't match. Country-specific patterns should be maintained in a BRFplus decision table for easy extension without code changes, and the rule should be tested against edge cases like blank VAT for countries where it's optional.
mediumBusiness Partner, Material and Finance Governance
2. During hypercare, how would you configure key mapping in DRF to handle a target CPI-connected system that uses different key structures for business partners than the MDG hub?
Configure a key mapping outbound implementation in DRF (or use the Key Mapping app/SOA-based key mapping service) linking the MDG internal ID to the receiving system's local key. The mapping table stores object type, source system, target system, and both key values. For CPI-integrated targets, the mapping is often populated via a confirmation message-back from the receiver after successful load, ensuring keys stay synchronized during hypercare when reprocessing failed messages.
hardBusiness Partner, Material and Finance Governance
3. You are architecting the workflow for MDG Financial Objects governance (e.g., GL account or cost center master data) where certain financial object attributes feed SD pricing conditions and customer credit management setups. How would you design the workflow to ensure financial approvals complete before SD-relevant data becomes consumable, while avoiding unnecessary bottlenecks for non-SD-relevant financial object changes?
Design conditional workflow branching based on whether the financial object change impacts SD-relevant attributes (e.g., account assignment used in pricing procedures or credit control area linkage); route only SD-impacting changes through an additional approval step involving SD/credit stakeholders, while standard financial object changes follow a lighter approval path. Use BRFplus or rule-based agent determination to dynamically evaluate impact and route accordingly, and gate activation so downstream replication only occurs after all required approvals close.
easyBusiness Partner, Material and Finance Governance
4. What is the MDG data model layered structure, and how do data model components relate to each other conceptually?
The MDG data model consists of entity types (root and dependent), attributes, relationships between entity types, and mapping to underlying persistence tables (active area and staging area). Root entity types represent the governed object (e.g., Business Partner, Material); dependent entity types capture sub-structures like addresses or roles. Relationships define hierarchy and cardinality. This structure is defined in transaction USMD_MODEL and drives generated UI, workflow, and BRFplus context availability.
easyBusiness Partner, Material and Finance Governance
5. In SAP MDG, what is the purpose of the duplicate check service and how does it typically leverage HANA capabilities?
The duplicate check service compares new or changed master data (e.g., business partner, customer) against existing records using fuzzy search and similarity scoring to flag potential duplicates before they are created. In HANA-based systems, it uses HANA search or fuzzy search functions and search models built on database views for fast, scalable matching across large data volumes, improving performance versus classic ABAP-based search helps.
hardBusiness Partner, Material and Finance Governance
6. Explain the role of IDocs in a DRF replication scenario feeding master data into an Ariba integration landscape, and where IDoc status monitoring fits into support processes.
In many DRF-to-Ariba landscapes, master data is replicated via IDoc-based outbound implementations (or through middleware that converts IDocs to Ariba-consumable formats). DRF triggers the IDoc generation for the assigned business object and port; the receiving side (often via PI/PO or CPI) transforms and forwards to Ariba's cloud integration gateway. Support teams monitor IDoc status in WE02/WE05 and BD87 to identify failed segments, reprocess errors, and reconcile with Ariba's own integration logs.
