MM / P2Parchitect

MM Supplier and Business Partner Part 4: Architecting the BP Model Across ECC, S/4HANA and Cloud Landscapes

Key takeaway

Architect supplier master data across landscapes: conversion vs new implementation implications, central governance with MDG, distribution to connected systems (Ariba, other ERPs), supplier lifecycle (onboarding, qualification, blocking), duplicates and harmonization, and data privacy.

Explanation

📌 KEY POINTS
✅ Decide the leading system for supplier data (e.g. MDG or S/4HANA) and distribute from there.
✅ Supplier lifecycle: onboarding (often Ariba/SLP), qualification, activation, blocking, archiving.
✅ Harmonize duplicates and groupings across legacy systems before or during migration.
✅ Integration with Ariba and other systems needs clear ownership of fields and IDs.
⚠️ Multiple systems creating suppliers independently guarantees duplicates and sync errors.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–3 covered the model and configuration. Now the architecture.

━━━━━━━━━━━━━━━━━━━━
▶ 1. LEADING SYSTEM

MDG hub or S/4HANA as system of record; others consume.

━━━━━━━━━━━━━━━━━━━━
▶ 2. LIFECYCLE

Request, validation (tax, bank, sanctions), approval, activation.
Blocking and archiving of inactive suppliers.

━━━━━━━━━━━━━━━━━━━━
▶ 3. INTEGRATION

Ariba (supplier onboarding, sourcing), other ERPs, payment systems.
Key mapping and field ownership.

━━━━━━━━━━━━━━━━━━━━
▶ 4. MIGRATION

Conversion: CVI; new implementation: cleanse and load BPs.
Harmonization rules and golden records.

━━━━━━━━━━━━━━━━━━━━
▶ 5. GOVERNANCE AND PRIVACY

Owners, approvals, dual control for bank changes, data privacy rules for person BPs.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Define the system of record and data flows.
Design the supplier lifecycle and approvals.
Plan harmonization and migration.
Define integration ownership and monitoring.

✅ CHECKPOINT: each supplier field has one owning system and process.

Code example

ABAP Code

===== STEP 1: landscape =====Ariba SLP (onboarding) → MDG (governance, validation, approval) → S/4HANA (BP) → other ERPs/payment systems ===== STEP 2: controls =====Duplicate check (tax/bank/name) | bank change dual control | sanctions screening | blocking inactive suppliers ===== STEP 3: migration =====Legacy vendors → harmonization → golden records → CVI conversion or BP load → key mapping for integrations

Real project scenario

A global template integrating S/4HANA with Ariba had suppliers created both in Ariba and locally in S/4HANA, producing duplicates and failed replications. Making MDG the system of record, with Ariba onboarding feeding MDG requests, eliminated local creation and stabilized integration.

Common mistakes

Several creating systems.
No bank change controls.
Migrating without harmonization.
Unclear field ownership in integrations.
No blocking/archiving policy.

Best practices

Define one system of record.
Govern the lifecycle with approvals.
Harmonize before migration.
Map keys and ownership.
Monitor integration errors.

Interview angle

Questions: "How would you design supplier master governance?", "How does Ariba integrate?", "How do you handle duplicates across systems?"
Strong answer: system of record, lifecycle and controls, integration with ownership and key mapping, harmonization and migration, governance and privacy.

Practice this lesson

Quick check

1. Why harmonize suppliers before migrating from several legacy systems?

2. Which control reduces fraud risk in supplier master data?

3. Suppliers are created both in Ariba and locally in S/4HANA, producing duplicates. What architecture decision fixes this?

Interview questions

1. During a Fit-to-Standard workshop for a P2P migration to S/4HANA with Ariba integration, the client insists on retaining separate vendor master records per company code rather than adopting the Business Partner/CVI model with centralized synchronization. What is the correct governance guidance, and what is the risk of ignoring it?

Answer it in your own words first, then compare.

2. A client migrating to S/4HANA Public Cloud has thousands of ECC vendor masters with duplicate tax IDs and inconsistent bank data. How would you approach the Business Partner supplier conversion in this constrained, standard-config environment?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.