SAP Community - SAP Master Data Governance

SAP Document AI in SAP MDG using Intelligent Scenario Lifecycle Management (ISLM)

2025-10-29T05:10:35.628000+01:00

Introduction

In this blog, let us understand how to leverage SAP Intelligent Scenario Lifecycle Management (ISLM) to manage Generative AI and AI business services in the SAP MDG. This blog mainly focuses on how to use one of the AI Business Services i.e. Document AI in MDG via ISLM. It is formerly known as Document Information Extraction (DIE).

MDG Scenario

The scenario is to derive the address details from vendor registration PDF document which will be uploaded in the MDG change request. SAP Document AI from BTP is used to read the details from a PDF document and derive the data into MDG change request.

Implementation

1. BTP

First of all, The BTP account is needed to create instance on the AI business service - SAP Document AI to read data from PDF. If you do not have a BTP account, please refer this link to create a BTP trial account Get an Account on SAP BTP Trial | SAP Tutorials.

You can find the SAP Document AI Trail (DIE) in the service marketplace to create an instance.

Please make sure instance as well as service key is created. The service key is used later in the ISLM connection mapping configuration.

Please subscribe to SAP Document AI UI application

Assign Role Collection to your user in Security.

To simplify all the above setup, you can use Booster as alternative to setup the SAP Document AI in BTP.

PDF Document

Please find sample PDF document which will be used as a document template to setup in the SAP Document AI.

Schema Configuration

Create a custom schema in SAP Document AI Application to extract fields from PDF document.

Add Header Fields

Add header fields in the custom schema to map with PDF document. All the fields such as FirstName, LastName, House No, Street, postal code etc. from PDF to map with business partner fields in MDG change request.

Activate the schema after all the fields are added.

Create Template

Template in SAP Business AI that uses schema and associated document. You could edit the extraction results of the associated documents to teach SAP Document AI where certain field values are located on the document to improve the accuracy of the extraction.

There is no associated document, so we need to add PDF document now in Documents.

Add Document

Add the PDF document in the Documents in SAP Document AI application and map the schema fields with PDF fields.

Add this document to template

Now, click on Add to Template Button to add this document to custom template created in one of the above steps.

Activate template

Access Template on the left navigation pane to activate it.

Now, all the setup related to SAP Document AI is completed.

2. Intelligent Scenario Lifecycle Management (ISLM) in MDG System

ISLM is part of the ABAP Platform offered as core functionality in ABAP stack.
ISLM Framework is developed in SAP BASIS Component from ABAP Platform 2020 delivery with SAP BASIS 755 / 7.8x onwards.
ISLM facilitates and helps to consume the Machine learning scenarios with an ABAP based Business Application seamlessly
ISLM helps to integrate AI and AI Business services into MDG system (S/4HANA).
ISLM offers an end-to-end framework to manage both pre-delivered and custom AI scenarios in SAP S/4HANA.

In this example, would like to walk through custom AI-DAR scenario through ISLM.

The below configuration is to be completed in MDG system to enable ISLM related applications.

Please make sure that role SAP_BR_ANALYTICS_SPECIALIST is assigned to the user which is required to access the below Intelligent Scenario Apps.

Click on Intelligent Scenarios App to create an intelligent scenario to consume AI business service SAP Document AI (DIE).

As you may aware, SAP ISLM provides two options as Embedded and Side-by-Side. In this example, would like to cover side-by-side scenario. So, click on create Button to initiate a side-by-side scenario creation.

Enter Scenario Name, Description and Type as Document Information Extraction.

It is recommended to use $TMP local package in ISLM until the Intelligent scenario is developed and tested thoroughly. After finalization, create the application package specific intelligent scenario. ISLM creates 'Intelligent Scenario' as an ABAP Object (Transportable / added to a TR based on catalog/package).

Create a prediction class with interface IF_ISLM_INTS_SBS_DOCX which will be assigned in the intelligent scenario.

The intelligent scenario could be published after all the above steps are done.

Maintain connection mapping between intelligent scenario and SAP Document AI (DIE) service (BTP) using service key and oAuth profile through the transaction ISLM_CONN_MAP.

In the Intelligent scenario management App, the deployment of intelligent scenario needs to be activated.

3. Master Data Governance (MDG)

In MDG, Cross entity derivation BADI could be used to call the Document AI via ISLM in MDG change request. In the BADI, it will read the name and address details using Document AI from PDF, which is attached in the MDG CR, and it will derive this information in the CR.

Execution

To execute this scenario, attach the PDF document in the MDG CR header and select BP grouping in the CR, it will trigger the BADI to derive the name and address details from PDF to MDG change request.

The file name and file title could be any and it is not fixed to any particular name.

Now, the name and address details are derived in the CR from PDF document.

Conclusion

In this blog post, we have learnt how to derive fields in the MDG change request from PDF document using SAP Document AI via ISLM.

SAP MDG: Locking Supplier General Data When Data Already exists

2025-10-29T15:36:02.091000+01:00

Hi SCN Folks,

Hope you guys are doing great 🙂

Note 01: This blog does not include execution screenshots.
Note 02: The entire code was developed and validated in the SANDBOX system, with results meeting expectations.
Note 03: There are several ways to implement; this blog is written about one of them.

Create one custom class & redefine the standard class (CL_MDG_BS_ECC_HANDLER)

Method Responsible: IF_MDG_BS_BP_ACCESS_HANDLER~GET_ENTITY_PROPERTIES.

DATA: lv_crequest_type TYPE usmd_crequest_type,
      lv_cr_number     TYPE usmd_crequest,
      lo_app_context   TYPE REF TO if_usmd_app_context.

DATA: lo_data      TYPE REF TO data,
      lt_data      TYPE usmd_ts_data_entity,
      lt_msg       TYPE usmd_t_message,
      ls_msg       TYPE usmd_s_message,
      lt_erp_v     TYPE REF TO data.

FIELD-SYMBOLS:
      <lt_erpv> TYPE SORTED TABLE,
      <ls_erpv> TYPE any,
      <lv_erpv> TYPE any.

CALL METHOD cl_usmd_app_context=>get_context
  RECEIVING
    eo_context = lo_app_context.

IF lo_app_context IS BOUND.

  CALL METHOD lo_app_context->get_attributes
    IMPORTING
      ev_crequest_id   = lv_cr_number
      ev_crequest_type = lv_crequest_type
      ev_process       = lv_process.

  lv_crequest_type = iv_crequest_type.

  CALL METHOD super->if_mdg_bs_bp_access_handler~get_entity_properties
    EXPORTING
      iv_entity         = iv_entity
      is_key            = is_key
      io_model          = io_model
      iv_crequest_type  = iv_crequest_type
      iv_crequest_step  = iv_crequest_step
      iv_crequest_index = iv_crequest_index
    CHANGING
      cf_read_only      = cf_read_only.

  IF iv_crequest_type EQ 'ZMDGS03'.
    io_model->read_entity_data_all(
      EXPORTING
        i_fieldname      = 'BP_HEADER'
        if_active        = abap_false
        i_crequest       = lv_cr_number
      IMPORTING
        et_message       = lt_msg
        et_data_entity   = lt_data
    ).

    lt_erp_v = VALUE #(
      lt_data[ usmd_entity      = 'BP_HEADER'
               usmd_entity_cont = 'BP_VENGEN'
               struct           = 'KATTR' ]-r_t_data OPTIONAL ).

    IF lt_erp_v IS NOT INITIAL.
      IF iv_entity EQ 'BP_VENGEN'.
        cf_read_only = 'X'.
      ENDIF.
    ENDIF.
  ENDIF.

ENDIF.

SAP S/4HANA SAP Master Data Governance ABAP Development

Thank You,
Sandeep Suggu.
SAP Community Profile | SAP Profile | LinkedIn

A clear guide to understanding how SAP MDG prioritizes UI layers—standard, CBA, customization, and e

2025-11-04T06:33:45.965000+01:00

When working with SAP Master Data Governance (MDG), it’s common to face situations where a field behaves differently than expected — maybe it’s hidden for one user role but visible for another, or a layout change doesn’t appear. These issues often come down to how different UI layers interact with each other.

To make sense of it, let’s walk through how SAP MDG decides which configuration takes effect when you use standard setup, CBA, customization, and enhancements.

Standard Configuration – The Starting Point

Every MDG screen begins with the standard SAP configuration. This includes the delivered Floorplan Manager (FPM) setup, feeder classes, and event logic. Think of this as the foundation. Everything else — from customizations to enhancements — builds on top of it.

Context-Based Adaptation (CBA)

CBA allows you to adapt the UI depending on the context — such as a business role, change request type, or entity type. If more than one CBA applies, the system picks the one with the highest priority (defined by the lowest numeric value in customizing). CBA runs before any runtime logic and overrides the standard configuration. It’s the best option when you want different screens or layouts for different user roles or processes.

UI Customization

Once the relevant configuration (standard or CBA) is loaded, the system applies any UI customizations you’ve made. These are the changes you do in the FPM configuration editor — for example, hiding a field, changing labels, or adjusting layout groups. If both a CBA and a customization touch the same field, the CBA takes priority because it decides which version of the configuration is active.

UI Enhancements

After all the configuration-based layers are applied, enhancements come into play. These are ABAP-based runtime changes done through custom logic or BadIs. Enhancements have the highest priority because they run at runtime and can override anything set in configuration or CBA. For example, even if a field is hidden in CBA, an enhancement can make it visible again based on business rules.

Summary of Priority

Priority| Layer| What It Does

(Lowest)| Standard Configuration: SAP-delivered default setup
CBA: Adjusts UI based on context (role, CR type, etc.)
UI Customization: Static FPM-level changes
(Highest)| UI Enhancements: Dynamic ABAP logic at runtime

Best Practice:

Use CBA for context-based variations (like role or process-specific screens).
Use UI Customization for layout or field visibility changes that stay constant.
Use Enhancements for dynamic, condition-based logic at runtime.

Understanding this order helps avoid conflicts between configurations and ensures your MDG UI behaves consistently. It also makes your design easier to maintain and extend as your governance processes evolve.

Why clean data is the foundation of enterprise success

2025-11-05T09:25:05.821000+01:00

Why clean data is the foundation of enterprise success

We’ve all been there: reports that don’t align, systems that refuse to speak the same language, and data that seems to have a mind of its own. It’s frustrating, time-consuming, and costly. Unclean data doesn’t just cause confusion - it multiplies complexity. It clogs business processes, drives up the number of upgrade cycles, and makes every transformation effort harder than it needs to be. And these aren’t just data quality issues - they’re symptoms of a fragmented data foundation that slows progress and limits innovation.

Now imagine a world where every decision is powered by data that just works: accurate, consistent, governed, and seamlessly connected across the enterprise. That’s what clean data makes possible. It’s the quiet engine behind transformation -the unseen force that fuels trust, agility, and innovation.

Clean data turns chaos into clarity. It enables governed, reusable data products built on shared semantics and harmonized master and reference data - so information flows freely across domains, analytics deliver truth instead of noise, and AI scales with confidence. Building on this foundation, the clean core approach takes the next step - transforming data clarity into business agility. It helps organizations unlock the full power of intelligent, connected operations by relying on harmonized, semantically linked data. When processes are standardized around proven best practices and strategic extensions are enabled for differentiation, businesses gain the agility to evolve without complexity.

With SAP Business Suite at the center, this approach keeps systems current, fuels continuous innovation, and paves the way for faster adoption of AI - turning trusted data into a true engine of transformation.

The business power of clean data

Clean data is more than a technical concern - it’s a true business enabler. By embedding clean data practices into the core of your enterprise, you can unlock:

Trustworthy decision-making – ensure leaders can rely on accurate, consistent information at every level of the business.
Regulatory confidence – meet compliance requirements seamlessly with transparent, auditable data.
AI and automation readiness – create the reliable foundation required to scale advanced analytics, automation, and intelligent technologies.
Operational excellence – reduce inefficiencies caused by data errors, rework, and duplication, freeing teams to focus on higher-value outcomes.

Clean core data whitepaper

That’s why I’m excited to introduce our new Clean core data whitepaper, designed for organizations moving from ERP to SAP S/4HANA Cloud Private Edition. This paper explores how to make this vision a reality. Inside, you’ll find practical guidance on implementing clean data practices, sustaining them at scale, and unlocking the full potential of your enterprise data.

A sneak preview of what’s inside

Here’s what you’ll find inside:

The five pillars of clean core data - explore the essential dimensions of clean data: strategy, governance, quality, volume efficiency, and protection - each designed to strengthen your enterprise data foundation.
A practical measurement framework - learn how to assess data maturity and governance using KPIs aligned with the RISE with SAP Methodology and dashboard.
Operationalizing the data product economy - discover how to leverage SAP Business Data Cloud and SAP Master Data Governance to deliver governed, reusable, and high-value data products.
Harmonizing SAP and non-SAP data - See how a unified semantic layer ensures interoperability and consistency, while keeping custom extensions decoupled on SAP BTP.
Driving seamless upgrades and intelligent insights - gain guidance on reducing infrastructure complexity, minimizing technical debt, and fueling trustworthy AI and analytics with a clean, future-ready data core.

Each chapter of the whitepaper takes you deeper into the journey:

Building a clean core: Overcoming data chaos for a modern, compliant enterprise
Chart the path to your clean data vision: Leverage clean core data to achieve business success
Data framework: Dive deep into the building blocks of clean core data
The cornerstones of a clean core data architecture

Driving data confidence with the RISE with SAP Methodology

Every successful digital transformation starts with one question: how do we turn data into continuous business value? Within the clean data framework, the answer begins with the RISE with SAP Methodology. It provides a clear roadmap, guiding organizations from identifying data challenges to building, monitoring, and scaling a sustainable clean data strategy. Through automated clean data KPIs, organizations can track the state of their data in real time - across both projects and day-to-day operations. All of this comes together in the RISE with SAP Methodology Dashboard, offering a unified view of data health, performance, and progress toward true data-driven agility.

Ready to take the first step?

Clean data is not a one-time project - it’s a journey and a discipline. The first step is to explore the Whitepaper on clean data and see how organizations can establish a foundation for smarter decisions, efficient operations, and long-term resilience.

👉 Download the Clean core data whitepaper

Extending Standard SAP MDG Data Model (MM) with Custom Fields

2025-11-10T09:32:27.425000+01:00

This blog is based on our practical experience and learnings from a recent SAP Master Data Governance (MDG) project. We had a requirement to extend the standard SAP MDG Data Model (MM) with custom fields at both Plant and Sales levels.

To achieve this, there are two main approaches available:

Traditional Approach
In-App Extensibility

1. Traditional Approach : Using the traditional approach, adding a custom field requires multiple manual extensions across different layers of the SAP system — including:

Database tables (e.g., MARC, MVKE)
CDS views
SOA services
OData APIs

During our implementation, while extending the MARC table with a custom field, we encountered the following error:

DBSQL_REDIRECT_INCONSISTENCY – A table could not be redirected

SAP has already addressed this issue in SAP Note 2242679 – Redirect inconsistency – Proxy Substitution, which suggests executing the report NSDM_PROXY_SUBSTITUTION for the MARC table to adjust the related CDS view and resolve the inconsistency.

Although this resolves the immediate technical issue, the traditional approach still requires repetitive manual work — extending the field individually at every layer (database, CDS, SOAP, and OData). This process is not only time-consuming but also prone to inconsistencies.

2. In-App Extensibility (Custom Fields and Logic)

To overcome these challenges, we adopted the In-App Extensibility approach using the Fiori app — Custom Fields and Logic.

This approach allows you to add and manage custom fields in a single step. When a field is created via this app, it can automatically extend the following components (depending on your configuration and enablement):

Underlying database tables
Relevant CDS views
SOAP services
OData APIs

This provides a one-stop solution for extending standard SAP objects — significantly simplifying the process and reducing development effort.

Extensibility Steps (Using In-App Extensibility)

Follow the steps below to create and enable a custom field using the Fiori App – Custom Fields and Logic.

Open the Custom Fields and Logic app.

Click on the “+ (Create)” button to add a new custom field.

Enter all the necessary information such as:

Business Context
Label
Data Type
Length

Select the services across different tabs where you want to make this custom field available (e.g., Database Table, SOAP Service, OData API, etc.).

Click Save to save your configuration.

Click on Publish to enable the custom field.

The publishing process may take a few minutes. Once completed, the field’s status will change to “Published.”

After publishing:

Check the database table (e.g., MARC or MVKE) to ensure the new field is added.

Verify that the field is available in the corresponding SOAP service.

Verify that the field is available in the corresponding MDC Model.

Note: The Data Model Extension process in MDG remains unchanged. You must still follow the standard MDG extension procedure as detailed in the official SAP document:https://www.sap.com/documents/2015/07/76525357-5b7c-0010-82c7-eda71af511fa.html

Key Takeaways

Traditional Approach: Requires manual extensions at multiple layers; higher maintenance effort.
In-App Extensibility: Provides a one-stop, upgrade-safe solution for extending database tables, CDS views, and APIs in a consistent manner.

Acknowledgment

Special thanks to Suresh, Soumya and Aswin for their valuable technical insights and contributions throughout the implementation.

SAP Ariba SLP - MDG attachment Integration - Making the Impossible Possible

2025-11-19T17:37:23.442000+01:00

The integration between SAP Ariba Supplier Lifecycle and Performance (SLP) and SAP Master Data Governance for Suppliers (MDG-S) enables extensive synchronization of supplier master data across both systems through choreographed business scenarios. The SLP-MDG integration supports bidirectional data exchange between SAP Ariba SLP and MDG-S, ensuring consistent supplier master data across both applications. If you would like to know the supported scenarios within this integration, refer to the standard documentation here

In this section, we will cover the details of integrating attachments from Ariba SLP into SAP MDG or SAP ERP systems. Let's first discuss the potential documents a supplier will upload to Ariba SLP when they register or update their existing registration.

Quality and other Certificates
Tax and Financial Documents
Supporting Documents that the buyer wants the supplier to upload
Contractual or Risk documents

Attachments in Ariba SLP are not restricted to the above documents it could be any Ariba acceptable format that pass the inbuilt Virus test while uploading on the SAP Business Network for Suppliers (which is the UI for the Supplier when trying to register to a Buyer's SLP)

Secondly, attachment-related inputs can be collected in the Registration, Modular, and Qualification Questionnaire. The SAP Ariba SLP product team recommends receiving certifications with Validity dates through Modular questionnaires only.

Lastly, Questionnaire respondents can add attachments to a supplier management questionnaire as a response to any of the following questions:

Answer type of Attachment.
Answer type of Certificate, where one of the certificate detail fields is an attachment field.
Any other answer type, with Participant can add additional comments and attachments set to Yes

In the first two cases, the attachment is a direct answer to the question. In the third case, the attachment is an optional addition to the response and can be added with or without a comment. For more details about the attachment sizes supported refer to the help documentation here.

Our Solution: A Dedicated Integration Package for Attachments

Given the context above, customers seeking attachment integration typically fall into two categories:

Existing Users: Customers already live with the standard SAP Ariba SLP integration (via SAP Integration Suite, Managed Gateway for Spend and Business Network/CIG).
New Implementations: Customers planning or currently implementing the standard SAP SLP-MDG/ERP integration through CIG.

Why This Package is Essential

Our integration package is designed to work for both customer groups because it does not disrupt the standard SAP Ariba CIG integration for Supplier Data Integration.

Instead, we leverage SAP Ariba's open APIs and standard SAP MDG APIs, making the package highly consumable, robust, and extensible for future scenarios. We strongly recommend that customers first implement the standard CIG-based integration for core vendor master data integration and then utilize this package to seamlessly supplement it with attachment integration.

Let's now take a look at the architecture at a high level to see how to achieve this.

High-Level Architecture

The integration package, which we have developed and deployed for customers, operates on a continuous polling mechanism:

It checks SAP Ariba SLP at regular intervals for the latest created and changed suppliers.
It identifies suppliers that are Approved and have a Registered status.
Using SAP Ariba Open APIs, it securely transfers the attachments from the questionnaires to the target system (SAP MDG or SAP ERP), which is configurable based on customer requirements.
The package includes the necessary ABAP code to accurately add the attachment to the SAP MDG Change Request or the SAP ERP Business Partner record.

Benefits of deploying this integration package for the Ariba SLP → SAP MDG / SAP ERP BP Attachment Integration would be,

Fully automated attachment flow, zero manual intervention
Reduced onboarding cycle time, Accelerates Supplier Onboarding
Lower administrative overhead for Supplier Management teams in Customers
More consistent and complete supplier records, strengthening compliance and Auditability
Enhances Data Quality and Governance
Supports Multiple Integration Scenarios (Both SAP MDG and SAP ERP systems)

Customers have reported a 40-60% reduction in manual effort during supplier onboarding, based on the volume of attachments they handle.

If you have any further questions, please leave a comment below or send your inquiries to the email CoE_AI_PlanningSpendExec@global.corp.sap. We will be happy to get back to you.

SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook (Part 3)

2025-11-26T08:21:24.234000+01:00

Integrating SAP EHS Public Cloud: Extending Your Existing Landscape Side-by-Side - Guidebook

Part 3: Integration of Business Partner & Material from SAP Master Data Governance (MDG)

Table of Contents:

1. Why is this Integration required?

Integrating Business Partner and Material master data from SAP Master Data Governance (MDG) into SAP EHS Public Cloud is a foundational step for enabling core EHS processes, particularly in Emissions Management. Instead of maintaining these master data objects locally within SAP EHS Public Cloud, the system relies on harmonized and validated Business Partner and Material data coming from the corporate master data governance layer. This ensures that supplier information, responsible persons, material properties, and classification attributes remain consistent across the enterprise.

Accurate and up-to-date Business Partner and Material data is essential in Environment, Health & Safety (EHS), as many analytical and reporting steps in Emissions Management depend on correctly maintained master data. Examples include assigning responsible Environmental Managers, linking sampling activities to suppliers or contractors, and using material-specific characteristics (e.g., heating values, emission factors, composition) as inputs for emission calculations.

In other words: Without integrated Business Partner and Material data, SAP EHS Public Cloud cannot reliably calculate emissions, assign responsibilities, or produce compliant environmental reports.

Architectural Approach - Scope

The highlighted section of the architectural diagram illustrates the scope relevant to this blog post - focusing on the integration of Business Partner and Material from SAP Master Data Governance (MDG) into SAP S/4HANA Public Cloud.

Reference to User Scenario (C) – Emissions Management

In part 1 “Introduction & Overview”, the User Scenario (C) – Emissions Management at Mike Machineries clearly illustrated why this integration is required:

Scenario Step	Why Business Partner & Material Integration Matters
The Environmental Manager prepares the annual emissions monitoring plan	The Environmental Manager must exist as Business Partner with up-to-date organizational data to be assigned as the responsible person for monitoring and reporting activities.
An Environmental Technician collects samples and records operational data	The technician must be identifiable as a Business Partner to ensure accountability, traceability, and proper assignment of sampling tasks.
Supplier-provided material data is used to support emission factor calculations	Material master data – such as composition, heating values, or supplier relationships – must be accurate and synchronized from MDG to ensure correct calculation of emission factors.
SAP EHS aggregates emission data and calculates quarterly NOx emissions	Material attributes and Business Partner assignments form essential input for compliant and reproducible emission calculations.
A deviation is detected, triggering an investigation	The system must determine responsible persons (Business Partner) to initiate corrective actions and assign follow-up tasks.
A Corrective Action Plan is defined and assigned	Task assignments require valid Business Partner information to ensure that responsible roles receive, process, and complete corrective actions.
Findings are shared with Sustainability and Operations teams	Consistent organizational Business Partner data ensures that notifications and reporting reach the correct stakeholder groups across sites.

Without integrated Business Partner and Material data, the system would not be able to:

Identify responsible persons (Environmental Manager, Technician, etc.)
Use complete and reliable material attributes in emission calculations
Track corrective actions or investigation responsibilities
Produce compliant and auditable emissions reports

Note: Although employees such as the Environmental Manager or the Environmental Technician could technically be replicated from SAP SuccessFactors, this alone is not sufficient for Emissions Management. The SAP SuccessFactors integration delivers Workforce Persons, which are used for people-related EHS processes (e.g., workflows, incident reporting, assignments). Emissions Management, however, requires full Business Partner master data – including organizational roles, supplier relationships, and external parties – that SAP SuccessFactors does not provide. These Business Partners are essential for material classification, supplier-dependent emission factors, regulatory reporting, and responsibilities that are not limited to internal employees.

This makes the integration of Business Partner and Material master from SAP MDG into SAP EHS Public Cloud a mandatory prerequisite for configuring Emissions Management.

Note: When implementing Emissions Management as shown in the User Scenario, ensure that the relevant scope item – 4XD – Emissions Management – is activated in SAP S/4HANA Public Cloud via Central Business Configuration (CBC). This activation enables the Emissions Management processes and configuration in SAP EHS Public Cloud so that the replicated Business Partner and Material master data can be used for monitoring, calculating, and reporting emissions.

While this integration is mandatory for Emissions Management, it is equally relevant for other EHS use cases such as Risk Management or Incident Management. In these scenarios, consistent master data ensures reliable assignment of responsibilities, correct categorization of materials, and accurate process execution. Across the organization.

Therefore, in the following section, we will take a closer look at the general setup of the Business Partner and Material data integration between SAP MDG and SAP EHS Public Cloud.

2. Prerequisites

To successfully integrate Business Partner and Material Master data from SAP Master Data Governance (MDG) into SAP S/4HANA Public Cloud, the following prerequisites must be fulfilled. These ensure that master data replication works seamlessly and support EHS processes such as Emission Management.

To successfully set up this integration scenario, the following prerequisites must be in place:

Tenant Provisioning:

SAP S/4HANA Public Cloud tenant
SAP MDG system should be available as the source system.

Administrator Access: Ensure administrator users exist in both systems:

SAP S/4HANA Public Cloud: The administrator should have the template role of SAP_BR_ADMINISTRATOR assigned to allow creation of communication users, systems, and arrangements.
SAP MDG for replication framework setup.

Scope Item Activation:

While this section focuses on the setup required for Emission Management, the same integration scenario also enables other EHS functionalities like Incident Management and Risk Management. For these processes, the corresponding scope items described in part 1 must be activated:

3FP – Incident Management
54A – Risk Management

In our scenario for Emission Management following scope items were activated:

1RO – Master Data Integration
- Purpose: Provides the technical foundation for master data replication, including communication scenarios for Business Partner (SAP_COM_0008) and Material Master (SAP_COM_0009).
- Why: Without 1RO, the integration cannot be configured because the required APIs and replication models are not available.
4XD – Emissions Management (only if Emission Management is in scope)
- Purpose: Enables emission-related processes in SAP S/4HANA Public Cloud.
- Why: Business Partner and Material Master data serve as the backbone for emission sources and organizational assignments.

Data Requirements:

Legal entities in SAP Material Master Governance (MDG) must match the Company Codes in SAP S/4HANA Public Cloud (Mismatches will lead to replication failures).

Cloud Connector Setup:

To establish secure and reliable communication between SAP S/4HANA Public Cloud and the On-Premise SAP MDG system, the SAP Cloud Connector must be properly configured for this integration scenario.

Register the SAP MDG system in the Cloud Connector UI and ensure that the connection is active and reachable.
Define a virtual host and port in the Cloud Connector. This virtual host will later be referenced when creating the Communication System in SAP S/4HANA Public Cloud.
Ensure that the SCC Location ID is maintained to link the correct connector instance.

3. Technical Integration

This section describes the practical implementation of the master data integration based on the predefined 1RO – Master Data Integration scope item. It outlines how Business Partner and Material Master data are replicated from SAP Master Data Governance (MDG) to SAP S/4HANA Public Cloud and highlights the key configuration areas involved in the process.

The 1RO scope item provides the standard integration scenario for master data replication and supports related data flows that are essential for EHS processes such as Incident Management, Risk Management, and Emission Management. Accurate and consistent master data is crucial for these use cases, as organizational structures, business partners, and material information form the foundation for compliance and operational processes.

Therefore, this section focuses on the Business Partner and Material Master integration processes, which serve as the backbone for all subsequent EHS configurations.

Key 1RO Configuration Areas:

Communication User and Communication System setup for SAP S/4HANA Public Cloud Configuration
Business Partner Integration (SAP_COM_0008)
Product Integration (SAP_COM_0009)
Configure Message Monitoring SAP S/4HANA Public Cloud

For detailed documentation, please refer to the official 1RO content in the SAP Process Navigator.

1RO Setup Instructions as PDF

3.1 Communication User & Communication System Setup for SAP S/4HANA Public Cloud Configuration

The integration scenario in this chapter enables the replication of Business Partner and Material Master data from SAP Master Data Governance (MDG) to SAP S/4HANA Public Cloud.

This is achieved by using the predefined communication scenarios delivered by SAP S/4HANA Public Cloud:

SAP_COM_0008 – Business Partner Integration
SAP_COM_0009 – Product Integration

Both scenarios form part of the activated scope item 1RO – Master Data Integration, which provides the APIs and replication models required for master data exchange between SAP MDG and SAP S/4HANA Public Cloud.

In our setup, SAP_COM_0008 and SAP_COM_0009 were both assigned to one shared Inbound Communication User and one shared Communication System. The differentiation between scenarios is handled within the Communication Arrangement, where scenario-specific service endpoints and authentication settings are maintained.

3.1.1 Create Inbound Communication User

The Inbound Communication User is required for authenticating inbound calls from SAP MDG to SAP S/4HANA Public Cloud. We created a dedicated user (e.g. MDG_IN) using the “Maintain Communication Users” app in the SAP Fiori Launchpad.

Select Maintain Communication User

If no suitable user exists, a new one must be created by choosing “New”.

Select New Communication User

The username and password for Basic Authentication can be defined freely.

Illustration of our Communication User - Overview

Once created, the system automatically structures the user view, showing assignments to Communication Systems and Arrangements (added in later steps).

Illustration of our Communication User - Assigned Communication System & Arrangements

3.1.2 Create Communication System

The Communication System represents the technical connection between SAP S/4HANA Public Cloud and the external SAP MDG system. It includes critical configuration information such as: Hostname, authentication method, inbound/outbound communication users, technical identifiers used for secure system-to-system communication.

Note: Unlike the JB1 employee replication in part 2 (chapter 3.2), which connected SAP S/4HANA Public Cloud to SAP Integration Suite, the 1RO master data scenario connects SAP S/4HANA Public Cloud directly to the SAP MDG On-Premise system. This scenario is SOAP-based and does not involve middleware. Therefore, SAP MDG ats as the external Business System in the Communication System setup.

If no applicable Communication System exists, a new one must be created via the “Communication Systems” app.

Select Communication SystemsSelect New Communication System

Enter a System ID and System Name referring to the SAP Master Data Governance (MDG) tenant and proceed with the set up.

After creating the new Communication System entry, additional configuration details must be maintained – including Technical Data, User for Inbound Communication and User for Outbound Communication. These parameters define how SAP S/4HANA Public Cloud connects with the external SAP MDG tenant. For comprehensive configuration guidance, refer to the 1RO setup instructions.

Communication System Setup - Technical Data 1

Note: As we are connecting a cloud system to an on-premise system, the SAP Cloud Connector needs to be added to the Communication System. If your on-premise system is currently not linked via any Cloud Connector, please refer to your SAP BASIS admin. Once the SAP MDG On-Premise system is added as mentioned before, the Cloud Connector then provides a secure tunnel and enables the use of virtual host names and its corresponding virtual port, which can be viewed in the SAP BTP Cockpit via Connectivity > Cloud Connectors. These values must be maintained as Host Name and Port in the SAP S/4HANA Public Cloud Communication System.

Additionally, the SCC Location ID must be maintained in the Communication System to ensure the correct connector instance is used. As the SCC Location ID is only visible in the UI of the Cloud Connector, please refer to your BASIS admin to get the SCC Location ID. For further information you can have a look in the SAP Help Portal.

For the Business System, we added our SAP MDG tenant and configured the Logical System using the SAP MDG system‘s runtime URL. It is important to enter the runtime URL without the „HTTPS:/“ prefix as the protocol is handled separately during the communication setup.

Because we are using Basic Authentication, all other advanced communication settings – including RFC Settings, OAuth 2.0 Settings, Event Exchange Infrastructure, Remote SQL Access, and Identify Provider configurations – were intentionally left empty or set to offline, as they are not required for our case.

Communication System Setup - Technical Data 2

Communication System Setup - Identify Provider

For the Inbound Communication User, we selected the one created in the previous step.

The Outbound Communication User does not necessarily come from the “Maintain Communication Users” app. It can be any technical user in the SAP S/4HANA Public Cloud system with the required authorizations for outbound communication. In productive scenarios, it is recommended to use a dedicated technical user for this purpose.

Communication System Setup - Users for Inbound & Outbound Communication

If any Communication Arrangements are assigned (will be explained in later sections), they will be visible within this Communication System.

Communication System Setup - Overview of assigned Communication Arrangements

3.2 Business Partner Integration

3.2.1 Communication Arrangement for Integration Scenario SAP_COM_0008

In the Communication Arrangement, the previously created components (Communication User and Communication System), have been linked within the integration scenario SAP_COM_0008. This arrangement consolidated the technical connection and authentication setup by combining the Communication System (representing the external MDG system) with the appropriate Inbound and Outbound Communication Users. Once configured, SAP S/4HANA Public Cloud is prepared to receive replicated Business Partner master data from SAP Master Data Governance (MDG).

The Communication Arrangement also provided the inbound service URL required for the MDG replication and enables secure, consistent data exchange as part of the 1RO scope item.

To create the arrangement, log in to the SAP S/4HANA Public Cloud Fiori Launchpad as an administrator and open the “Communication Arrangements” app.

Select Communication Arrangements

Then click on “New” to create a new Communication Arrangement.

Create New Communication Arrangement

Choose SAP_COM_0008 as the Communication Scenario.

Assign Communication ScenarioSelect Communication Scenario SAP_COM_0008

After that, further setting configurations needs to be done. Therefore, the before created Communication System will be attached.

Add Communication System to Communication Arrangement

Take note of the value maintained in the field “Own SAP Cloud System” (see screenshot below). This value is required when configuring the external MDG system, where it must be entered in fields such as System Instance ID, Business System ID, or IDoc Logical System ID during the setup of the corresponding integration settings.

In our case, the fields under “Additional Properties” remained empty.

Own SAP Cloud System in Communication Arrangement

Based on the selected Inbound Communication User, the system automatically derives the user for this Communication Arrangement. The Inbound Services listed in this section can remain unchanged. Their respective Service URLs are generated automatically from the API base URL ad the service-specific path.

Communication Arrangement Setup - Inbound Communication User

For Outbound Communication, the system automatically derives the User Name from the assigned Communication System.

By default, all Outbound Services are set to “Active”. The predefined Service URL and Basic Type can remain unchanged, as these values are generated automatically.

Since our integration scenario replicates Business Partner data from the on-premise SAP MDG system to SAP S/4HANA Public Cloud, we follow the guidelines described in chapter 3.1.5 of the scope item in the 1RO setup instructions, page 16. According to these guidelines, all Outbound Services must be set to “Inactive”, except for:

Business Partner – Send Confirmation from SAP S/4HANA Cloud Public Edition to Client
BP Relationship – Send Confirmation from SAP S/4HANA Cloud Public Edition to Client

These two services must remain active so that SAP S/4HANA Public Cloud can send confirmation messages back to the source system (SAP MDG) after successful processing. This ensures proper synchronization attempts within the Data Replication Framework.

Communication Arrangement Setup - Required Outbound Services

3.2.2 Integrate Business Partner Data from SAP Master Data Governance (MDG) to SAP S/4HANA Public Cloud

This section focuses on the Business Partner replication setup based on the recommendations of chapter 3.1.5 of the 1RO setup instructions, beginning at page 16. Since the required Outbound Services and Service URLs were already outlined in chapter 3.2.1, we continue here with the configuration of the Inbound Services within Communication Arrangement SAP_COM_0008.

To begin the integration setup, the WSDL/Service Metadata for the following Inbound Services from the SAP S/4HANA Public Cloud system:

Business Partner – Replicate from Client to SAP S/4HANA Cloud
Business Partner Relationship – Replicate from Client to SAPS/4HANA Cloud

Download WSDL Service Metadata from the Communication Arrangement SAP_COM_0008

Upload WSDL in SAP MDG - SOAMANAGER

In the on-premise SAP MDG system, navigate to SOAMANAGER. According to the 1RO setup instructions, chapter 3.1.5 – Procedure – sub chapter 4 - page 18, you must choose between a central or decentral configuration approach. In our scenario, we used the decentral configuration.

Navigate to SOAMANAGER in SAP MDG On-Premise System

Note: To enable dynamic receiver determination, the Business Partner web service uses service groups in SOAMANAGER. Consequently, logical ports for the service consumer must not be created manually; instead, they must be generated automatically based on the integration scenario. This requires a WSDL-based configuration.

De-Central Configuration Approach:

We selected the decentralized configuration approach because it provides the flexibility required for our system landscape. While SAP MDG remains the primary source for master data, SAP S/4HANA Public Cloud may also perform validations or localized adjustments. A decentralized setup is typically preferred when multiple systems need to manage master data independently, ensuring agility and avoiding reliance on a single central system.

Ensure that the Central Configuration switch is set off for this setup. You can verify this under: Technical Administration > SAP Client Settings > Central Configuration.

De-Central Configuration Approach

After that, we need to upload the before downloaded WSDL/Service Metadata to the on-premise SAP MDG system. Therefore, navigate to Tools > WSDL Upload

Uploading WSDL Service Metadata in MDG On-Premise System via SOAMANAGER - Overview

Create a new entry with the appropriate Name, Description, and WSDL Base with the selected radio button “Via File”, and upload the first WSDL file. Repeat this step for the second WSDL file as well.

Uploading WSDL Service Metadata in MDG On-Premise System via SOAMANAGER

Note: The WSDL typically contains several protocol and authentication alternatives. By default, WS-RM and HTTPBasic are selected. If another option is preferred (e.g., SAP-RM), the WSDL must be adjusted prior to upload by removing unneeded alternatives.

Create Entries in Service Registry:

Navigate to Service Registry > Publication of External WSDL.

Publish Uploaded WSDL Service Metadata in MDG On-Premise System via SOAMANAGER - 1

Choose the uploaded WSDL file and follow the instructions of the 1RO setup instructions. The steps you can find in chapter 3.1.5 De-Central Configuration Approach – Create Entries in a Service Registry, page 21.

Publish Uploaded WSDL Service Metadata in MDG On-Premise System via SOAMANAGER - 2

Chapter 3.1.5 - Create Entries in a Service Registry - Page 21

Ensure that in step 7 of the above shown steps, the Own SAP Cloud System is entered in the System Name field, and the corresponding API-URL (as Host Name) is taken from the communication arrangement SAP_COM_0008, as described in chapter 3.2.1.

Publish Uploaded WSDL Service Metadata in MDG On-Premise System via SOAMANAGER - 3

Own SAP Cloud System in Communication Arrangement

When repeating the WSDL publication step for the BusinessPartnerRelationship WSDL, select the existing Physical System that was created in the previous step.

Publish Uploaded WSDL Service Metadata in MDG On-Premise System via SOAMANAGER - 4

Create Profile:

When integrating via SOAP services, the WSDL only defines the interface. The security profile ensures secure communication by specifying:

Authentication (User ID/Password)
Transport Security (secured communication)
No IBC determination for simplified setup

This profile is referenced by provider systems to enforce consistent security settings for all service calls. Navigate to Technical Administration > Profiles

Create Profile in SOAMANAGER - 1

Create the new user as specified above. We created a DEFAULT_PROFILE in our scenario.

Create Profile in SOAMANAGER - 2

Create a Provider System:

The provider system links SAP MDG to SAP S/4HANA Public Cloud for SOAP-based integration. Navigate to Technical Administration > Provider Systems

Create Provider System in SOAMANAGER - 1

Create the Provider System as mentioned in the 1RO setup instructions. The steps you can find in chapter 3.1.5 De-Central Configuration Approach – Create a Provider System, page 21-22.

Chapter 3.1.5 - Create a Provider System - Page 21-22

Use the same Name as maintained in the Own SAP Cloud System of the SAP_COM_0008 Communication Arrangement, and assign the profile created in the previous step.

Create Provider System in SOAMANAGER - 2

For WSDL Access, if no system appears in the value help, select the service registry SR_LOCAL and remove this system from the value help. Ensure that the WSIL Service is deactivated.

Create Provider System in SOAMANAGER - 3

According to WSDL Documents select Basic Authentication and enter the user credentials of your MDG user. Ensure that the Tolerant Search option is enabled under Search Granularity.

Create a Provider System in SOAMANAGER - 4

In the creation step, select Retrieve Business Applications. The system will automatically generate an entry for the business application. Complete the changes afterwards.

Create Provider System in SOAMANAGER - 5

Create logon data:

Creating logon data ensures secure authentication for SOAP communication between SAP MDG and SAP S/4HANA Public Cloud. It centralizes credential storage and links them to service definitions to support reliable and secure data replication. To configure this, navigate to: Service Administration > Logon Data Management

Create Logon Data in SOAMANAGER - 1

In the Maintenance tab, create a new user if none exists and select User/Password or X.509 as the authentication method. Enter the user of the SAP S/4HANA Public Cloud system that was created as the Inbound Communication User and maintain the corresponding password.

Create Logon Data in SOAMANAGER - 2

In the Assignment tab, proceed the remaining steps described in the . The steps you can find in chapter 3.1.5 De-Central Configuration Approach – Create Logon Data, page 22.

Chapter 3.1.5 - Create Logon Data - Page 22

Create Integration Scenario Configuration:

This step consolidates all previously configured settings into an executable integration scenario and generates the logical ports required for SOAP-based replication. For that, navigate to Service Administration > Local Integration Scenario Configuration.

Create Integration Scenario in SOAMANAGER

As all required settings required for this step are mentioned in the previous steps, you can follow the remaining steps of . You can find them in chapter 3.1.5 De-Central Configuration Approach – Create Integration Scenario Configuration, page 22.

Chapter 3.1.5 - Create Integration Scenario Configuration - Page 22

Configuration in Data Replication Framework:

Since the SAP MDG system is operated as an on-premise system in our scenario, the configuration within the Data Replication Framework (DRF) is carried out using the DRFIMG transaction. As a result, two configuration steps are required.

Configuration of Communication (Target) System:

Navigate to Define Custom Settings for Data Replication > Define Technical Settings > Define Technical Settings for Business Systems.

Define Technical Settings for Business System

On the first level, the Business System and Logical System must be maintained. These entries must match the corresponding settings in SOAMANAGER. Optionally, an RFC Destination can be specified (e.g., <Business System>_IDOC) if IDoc-based communication is intended.

On the second level, the relevant Business Objects are selected. For this scenario, the following objects have been configured: 147 – Business Partner, 986 – Business Partner including Relationships, 194 – Product (used for product integration). The output mode has been set to D – Direct Output. Note: Business Object 194 is not part of the Business Partner but is used exclusively for product integration.

Configuration of Communication (Target) System - 2

On the next level, the corresponding communication channels for replication via Services were assigned to Business Objects 147 and 986, as illustrated below.

Configuration of Communication (Target) System - 3

Configuration of Replication Model: After defining the technical settings for the target system in DRF (Business System, Logical System, and communication channels), the next step is to create and configure the replication model.

Navigate to Define Custom Settings for Data Replication > Define Replication Models.

Define Replication Models

Create a new replication Model. Therefore, select New Entries on the first level and provide a name and description for the model. This model determines which business objects will be replicated to the target system.

Define Replication Model - 1

Select the new entry and navigate to Assign Outbound Implementation on the second level. For the Business Partner replication, use Outbound Implementation 986_3 (Business Partner including Relationships), give a description and choose Communication Channel Replication via Services.

Define Replication Model - 2

After this step, select the new Outbound Implementation 986_3 and navigate to Assign Target Systems for Replication Model/Outb. Impl. on the third level. Enter the previously configured target system.

Define Replication Model - 3

At Assign Outbound Parameter we can define, how many records will be collected into a bulk message. Therefore, you can use the outbound parameter PACK_SIZE_BULK. A recommended value for this parameter is 100.

Define Replication Model - 4

After the replication model is defined, save your changes, select the replication model and choose Activate. Note that this step is required, as replication can only be executed after successful activation.

Configuration of Value Mapping

During Business Partner integration, certain code lists differ between SAP MDG and SAP S/4Public Cloud. To ensure seamless replication, these values must be mapped so that the target system correctly interprets the data sent from the source system.

Examples where value mapping is required for code lists:

BP groupings (DTEL MDG_FND_NR_INTERVAL_BP_GRP_COD)
Account groups (TABL MDG_FND_BP_MAINT_PRF_CODE)
Region codes (TABL MDG_FND_REGION_CODE)
Pricing procedure (DTEL KALKS)

Note: Although value mapping is primarily maintained in the on-premise system, certain entries may still need to be created in SAP S/4HANA Public Cloud using the “No Mapping” indicator to avoid unnecessary mapping attempts during inbound processing.

In our scenario, we also executed the value mappings described above. The example below illustrates how Account Group value mappings are maintained in the code lists. You must decide in which system (SAP S/4HANA Public Cloud or SAP MDG) the mapping should be maintained. In our case, the mapping was performed in SAP S/4HANA Public Cloud.

Before maintaining value mappings, the relevant code lists must be assigned to the respective business systems and elements. This ensures that the replication framework knows which code list is applicable. To perform this activity, open the SAP Fiori Launchpad as Business Expert and navigate to Assign Code Lists to Elements and Systems.

Assign Code Lists to Elements & Systems

In our scenario, we assigned several code lists (such as Tax Types, Account Groups, and BP Groupings) to our MDG business system. After assignment, we defined value mappings to harmonize internal and external codes – for example, mapping the internal tax type to external code MWST. Next, navigate to the “Maintain Value Mapping” app and select Position.

Select Position in Maintain Value Mapping

Enter the Object Type and Global Data Type that were assigned as code lists to the corresponding elements and system.

Enter parameter selection

Select the relevant Value Mapping Field.

Select Value Mapping FieldAssigned Code Lists

Select the assigned code list and navigate to Define Value Mapping. Here, specify how the source system codes (SAP MDG) corresponds to the target system codes (SAP S/4HANA Public Cloud). For example, the external tax type “MWST” from MDG is mapped to the internal code 01 in the cloud system. This ensures consistent interpretation of data during replication.

Define Value Mapping

This example is provided for reference only to demonstrate how value mappings can be created in SAP S/4HANA Public Cloud. Depending on your project requirements, you may need to maintain additional mappings accordingly.

3.3 Product Integration

3.3.1 Communication Arrangement for Integration Scenario SAP_COM_0009

To extend the integration beyond Business Partner data and establish the product integration between SAP S/4HANA Public Cloud and the SAP MDG system, we created an additional Communication Arrangement using scenario SAP_COM_0009, which provides the required communication services for product replication.

Therefore, as before, choose “New” in the “Communication Arrangements” app and select the communication scenario SAP_COM_0009.

Select Communication Scenario SAP_COM_0009

As described in chapter 3.2.1, take note of the value maintained in “Own SAP Cloud System”, as it is required for configuring the external MDG system. This value will be used in the target integration systems for parameters such as System Instance ID, Business System ID, and IDoc Logical System ID.

Next, select the Communication System previously created for this scenario (“MDG”).

After selecting the Communication System, all related information, such as the Inbound Communication User, and the Service URLs of the outbound services – will be automatically populated.

Assign Communication System & Own SAP Cloud System

For the additional properties, we selected Product Number Harmonization = 1 to ensure that product numbers from SAP MDG remain consistent in the SAP S/4HANA Public Cloud system. By selecting setting, products are replicated with the same number as in the SAP MDG system. If the product number already exists in SAP S/4HANA Cloud, the system updates the existing product rather than creating a duplicate. If the number is already used for a different product, the replication fails. In our scenario, no mapping was required because MDG was used as the leading system.

Select Value for Product Number Harmonization

In our scenario, inbound services were the most relevant because they enabled the replication of product data from SAP MDG to SAP S/4HANA Public Cloud. Outbound services, in contrast, were not required for the main data flow.

The only outbound service we kept active was “Product Master – From S/4HANA Cloud to Client”, which is necessary to send a confirmation back to the source system (SAP MDG) after successful processing. All other outbound services can be set to “inactive” to avoid unnecessary communication and reduce complexity.

Required Outbound Services

3.3.2 Integrate Products from SAP Master Data Governance (MDG) to SAP S/4HANA Public Cloud

The transfer of Product Master data from the on-premise SAP MDG system to SAP S/4HANA Public Cloud follows a similar process to the steps described in chapter 3.2.2, with only minor adjustments specific to the product integration.

Since the product master data replication is handled via the Communication Arrangement SAP_COM_0009, a different inbound service is used for this scenario.

The inbound service used for this scenario is: ProductMDMBulkReplicateRequest_In

This service also includes the service group MDM_PRD_REPLICATE_REQ, which will be required later during the configuration steps in SOAMANAGER within the on-premise SAP MDG system.

Download WSDL Service Metadata for Product Integration

Configuration in Data Replication Framework:

Configuration of Communication (target) System:

Due to the DRF customizing in the SAP MDG transaction DRFIMG, the same target system is referenced, using Business Object 194 (Product) together with the Key Mapping as part of Key Harmonization. To configure this, navigate to: Custom Settings for Data Replication > Define Technical Settings > Define Technical Settings for Business Systems

On the first level, select the Business System and navigate to the communication channel configuration for Business Object 194 (Product). Because Key Mapping is also used for the Communication Arrangement SAP_COM_0009, it must additionally be configured here in the target system communication settings, as shown below.

Configuration of Communication (Target) System for Product Integration

Configuration of Relocation Model:

This follows the same logic described in chapter 3.2.2. For product replication, the outbound implementation 194_3 (Product Master Data) is used.

In our scenario we used for the assigning of the outbound implementation the same replication model as for the Business Partner. Assign the same Target System as for the Business Partner. Optionally you can assign the outbound parameter PACK_SIZE_BULK which will define how many records will be collected into a bulk message.

Configuration of Replication Model for Product Integration

Value Mapping for Products:

Value mapping for product-related data follows the same principle as the Business Partner. Below is an example of value mappings already maintained in the on-premise SAP MDG system for Mechanical Engineering.

Value Mapping for Products in SAP MDG On-Premise System3.4 Configure Message Monitoring SAP S/4HANA Public Cloud

Accurate and timely replication of Business Partner and Product Master Data from SAP MDG on-premise to SAP S/4HANA Public Cloud is essential for Emission Management processes. Any replication failure can lead to incorrect assignments of emission sources, roles, or responsibilities, which may impact compliance with environmental regulations and operational safety. SAP S/4HANA Public Cloud provides the “Message Dashboard“ app to monitor replication scenarios. Before using it for the 1RO integration scenario, recipients must be assigned in the “Assign Recipients to Users“ app.

Configuration Steps:

1. Open the “Assign Recipients to Users“ app in the SAP Public Cloud Fiori Launchpad.

Select Assign Recipients to Users2. Verify that your user is assigned with the following details:

Namespace	Recipient Name	Message Type	Overview	Technical User
/CMDBP	CMD_BP	Application Error or Technical Error	Select the checkbox.	Select the checkbox
/CMDPR	CMD_PRODUCT	Application Error or Technical Error	Select the checkbox.	Select the checkbox.
/MDMKM	MDM_KEY_MAPP ING	Application Error or Technical Error	Select the checkbox.	Select the checkbox.

Required Recipient User Subscriptions for Monitoring - 1

If your user is not listed, add a new entry using your User ID and then assign the details of the table shown above.

Once recipients are assigned, the Message Dashboard displays all relevant replication messages – including errors, warnings, and successfully processed records – allowing early detection and resolution of integration issues.

Note: To reprocess messages directly from the Message Board, the user must have the SAP_BR_ADMINISTRATOR business role assigned. Without this role, reprocessing is not authorized.

Message Dashboard Overview:

Select Message Dashboard

The Message Dashboard provides after this setup a consolidated view of all replication messages for the 1RO scenario:

The calendar view indicates daily status (green = no errors, red = errors occurred).
Messages can be filtered by date range for detailed analysis.
The result list summarizes processed messages per interface (e.g. /CMDBP), including counts of warnings, technical errors, and successful replications.

This monitoring ensures transparency and operational reliability by allowing administrators to quickly identify and resolve replication issues before they impact.

Message Dashboard Overview

4. Lessons Learned

Implementing 1RO for Business Partner and Product integration – from the SAP MDG On-Premise system to SAP S/4HANA Public Cloud – provided several valuable insights that are highly relevant for similar integration projects.

1. Separate Replication Models Are Mandatory in DRF: Even though Business Partner and Product replication steps look similar, each requires its own replication model in DRFIMG because outbound implementations (986_3 vs 194_3) are object specific. Trying to reuse the same model can cause conflicts.

2. Service Groups Are Crucial for Dynamic Routing: The concept of service groups in SOAMANAGER is essential for Business Partner and Product replication. They enable dynamic receiver determination and simplify configuration. Ensure WSDL-based configuration is used to generate logical ports automatically.

3. Value Mapping Is Often Overlooked: Differences in code lists (e.g., BP groupings, account groups, material types) between MDG and S/4HANA Public Cloud can cause replication failures. Plan value mapping early and verify mappings in both systems.

4. Cloud Connector Setup is required for integrations from an On-Premise System into Cloud: Incorrect virtual host or missing SCC Location ID in the Communication System often leads to connectivity issues. Validate these settings before proceeding with SOAMANAGER configuration.

5. Monitoring Setup Is Critical for Operational Reliability: Assign recipients in the “Assign Recipients to Users” app before using the Message Dashboard. Without this, replication errors will not be visible to the right users, delaying troubleshooting.

6. Consistency in Product Number Harmonization: For Product replication, enabling “Product Number Harmonization” in the Communication Arrangement SAP_COM_0009 prevents duplicate products and ensures updates instead of new creations. This setting is often missed.

7. Test with Small PACK_SIZE_BULK First in the DRF configuration: Start with a smaller bulk size (e.g., 10) during initial testing to simplify error analysis. Increase to the recommended 100 only after successful initial runs.

8. Documentation Alignment with 1RO: Always cross-check with SAP’s official 1RO documentation. Minor deviations (e.g., service names, WSDL variants) can lead to integration failures.

5. Engage with Us

To follow the series, make sure to subscribe to the SAP EHS Public Cloud blog tag.

We welcome your thoughts and feedback in the comments!

Acknowledgements

This blog post series is the result of close collaboration within our EHS implementation team. I would like to express my sincere appreciation to my colleagues, whose expertise, insights, and project experience significantly contributed to the depth and quality of this guide.

A special thank you goes to:

Their contributions were instrumental in shaping the content of this blog post. I am truly grateful for their collaborations and support.

🚀 Launch Alert! Become a Data Architecture Powerhouse: Your Foundational Learning Journey

2025-12-02T06:14:39.976000+01:00

To equip data professionals with the skills to bridge technical expertise and strategic business impact, SAP Data Architecture experts and the SIX learning team are thrilled to announce the launch of the Data Architect Learning Journey (Foundational). This essential first stage of the Becoming a Data Architect curriculum is designed to empower aspiring architects, data professionals, and solution experts to master the core principles, modern paradigms, and critical frameworks that define successful enterprise data architecture.

🏗️ Structure: Building Expertise from the Ground Up

This learning journey is structured methodically, ensuring you build expertise layer by layer, from foundational theory to strategic impact.

The journey begins with Unit 1: Foundational Concepts, where you will anchor your understanding in the essential principles of modeling, metadata management, and architectural alignment. You will master basic terminologies and fundamentals, including Conceptual, Logical, and Physical data models, and understand how data architecture integrates with enterprise frameworks like Zachman and TOGAF.

Next, Unit 2: Modern Paradigms & Integration takes you into the contemporary world of data patterns. You'll explore and compare models like Data Mesh, Data Fabric, Data Lake, and Data Lakehouse, learning how to select the right approach for any scenario. This unit also delves into integration essentials, comparing and contrasting approaches such as ETL and ELT.

Unit 3 focuses on the critical need for Governance, Security & Strategic Impact. As data ecosystems expand, governance becomes the bedrock of trust. You will learn to establish comprehensive data governance frameworks (including stewardship and data lineage) and integrate crucial security and privacy controls to ensure compliance and secure modern use cases like AI/ML.

The journey culminates in Unit 4: Communicating Data Value. A great architect is also a great leader. This final unit strengthens the communication and leadership skills needed to influence change, teaching you how to articulate the limitations of the current ("as-is") data landscape and present a compelling, business-focused narrative for the future ("to-be") architecture, focusing on quality, cost, and scale.

🎯Who Should Enroll? Shift from Technical Expert to Strategic Leader

This curriculum is ideal for data professionals at every stage ready to evolve from technical implementers into strategic architectural leaders. This includes Data Engineers and Modelers seeking advancement, Solution and Enterprise Architects aiming to solidify their data design expertise, BI and Analytics Professionals who need architectural context, and IT and Transformation Leaders focused on aligning data systems with business outcomes.

✅Why Start This Journey Now?

Modern organizations demand architects who master both technology and business value. By mastering these principles, you will gain skills that directly translate into competitive advantages: you'll improve data quality and governance, learn how to connect data architecture directly to enterprise goals, and gain the credibility needed to influence strategic decisions. Crucially, this course sets the definitive foundation for the planned SAP Certified Data Architect specialization* launching in 2026!

Visit SAP Learning and enroll in the Becoming an SAP Data Architect – Foundational Learning Journey Today! Becoming an SAP Data Architect (Foundational)

Meet Joule: Your AI Copilot for SAP Master Data Governance

2025-12-02T09:42:44.286000+01:00

If there’s one thing we all want more of in our workday, it’s time. What if you could skip the clicks, stop hunting through endless menus, and just ask for the data or task you need right when you need it? That’s exactly what Joule, SAP’s powerful generative AI assistant, brings to the table. Today, we’ll explore Joule’s capabilities, then zoom in on how it takes SAP Master Data Governance (MDG) to a brand-new level of usability and efficiency.

What is Joule?

Joule is SAP’s generative AI assistant, designed to help you interact with your SAP systems in the simplest way: conversation. Whether you need business information, want to complete a task, or are searching for a specific insight, just ask Joule in plain language. Joule can retrieve information, complete routine tasks, guide you to the right application, or even explore your business data with you, all within the familiar SAP ecosystem.

You can work with Joule in multiple conversation threads, review or delete expired conversations, and move seamlessly between ongoing dialogues. Its capabilities are broad, spanning transactional, navigational, informational, and analytical scenarios.

Why Joule?

Joule is not just about simplifying tasks; it is about connecting everyone in your company, especially business users, with professional Master Data Governance (MDG) capabilities. This means that even users without extensive knowledge of MDG applications can accelerate business processes with ease. By removing the need to build custom user interfaces, Joule lowers total cost of ownership, reduces the resources needed to manage MDG, and streamlines communication by automating routine governance tasks. Here are some of the key business benefits Joule brings to your organization:

Enhanced Accessibility and Ease of Use
With Joule, access to core MDG features is democratized. Employees from any department can seamlessly engage in data governance tasks no matter where they are, eliminating the heavy reliance on specialized MDG experts. This opens up data quality and integrity efforts to a broader team and fosters a more inclusive data culture.

Efficiency in Business Processes
Joule automates routine tasks and provides intuitive conversational interfaces for complex operations. As a result, business processes move faster, and everyone spends less time managing data, leading to a significant boost in productivity.

Cost Reduction and TCO Savings
Because Joule delivers built-in, user-friendly interfaces out of the box, there is no need to invest in developing or supporting custom UIs. This helps companies save on development costs and ongoing maintenance, making the solution more cost-effective.

Improved Data Quality
By leveraging large language models to identify and correct errors, Joule helps catch anomalies and typos at the point of entry. This results in better, more consistent data from the start, supporting confident decision-making throughout the business.

Enhanced User Experience
The conversational, intuitive design of Joule makes working with complex data simpler and more enjoyable. Employees can interact with the system naturally, leading to higher satisfaction, stronger engagement, and increased productivity across the company.

Implementing Joule in your MDG landscape brings tangible business value by improving accessibility, accelerating processes, cutting costs, enhancing data quality, and ensuring scalable data management as your organization grows.

Joule for Master Data Governance: A New Era of Productivity

To help you understand what does this base MDG Joule AI Feature in SAP Business AI Catalog offers, let’s dive into what makes Joule a game-changer for Master Data Governance.

With SAP Master Data Governance on S/4HANA 2023 FSP0 Private Cloud, customers can use following Joule capabilities to enable their business users:

Effortlessly Search and Display Business Partners

Searching for Business Partners is smarter now. You can search by almost any attribute, such as name, address, bank details, tax ID, or even birthdate:

“Find all Business Partners in Munich.”
“Search BPs with IBAN 789789.”

Joule provides results instantly and can guide you to detailed views or relevant applications for further action.

Display Business Partners

Need to look up a specific Business Partner’s information? Just type:

“Show me the bank details for BP 1234567.”
“Display details for Business Partner 345678.”

Joule can retrieve overviews, basic details, bank accounts, identification numbers, address usages, payment cards, roles, contact relationships, and more. You don’t need to know in advance where in the system this data resides, Joule brings it to you. Once you have the information that you need, you can open the Business Partner record from the Joule chat window or continue working on the record through Joule.

Create Business Partners (cloud-ready mode)

Creating or updating Business Partners has never been easier. Instead of navigating multiple screens, you can tell Joule what you need in natural language:

“Create a new organization named ABC Corp with address in Berlin.”
“Create a new person.” (and let Joule walk you through the steps)

Joule guides you through supplying only the necessary details, checks for duplicates, and creates the governance process. Of course, you can always choose to submit, retype, or decline the process—all within your conversational flow.

Edit Business Partners (cloud-ready mode) - On the Fly

Need to update a detail? No need to open multiple transactions:

“Change the organization name for BP 1234567.”
“Change the email to example@example.com for partner 4711.”

Joule manages the governance workflow for these changes, letting you save drafts, submit them for approval or even cancel as needed.

Query MDG Process (cloud-ready mode)

Joule isn’t stopping there. With S/4HANA 2025 Private Cloud, managing your governance processes just became much more intuitive:

Now, you can search not just for Business Partners, but for the governance processes themselves - across Central Governance, Consolidation, and Data Quality areas. Need to find a process by the process ID, who created it, its status, or when it was created? Just ask:

“Show my last process.”
“Find high priority processes from last week.”
“Display all processes created by John.”

Once you find a process, Joule brings you the essential details: process ID, status, priority, and more. Need to understand what’s going on with a particular record? Request:

“Show me the details of process 1234.”

And from there, you can jump straight to related Business Partner data or the relevant management app.

Bringing It Together

Joule is redefining how we interact with Master Data Governance in SAP. With intuitive conversational access, you can create, search, display, and edit Business Partners or even manage governance processes - without losing your flow or context. No more clicking through menus or remembering transaction codes. You get instant, accurate responses, all backed by the power and security of SAP.

Ready to work smarter? Meet Joule, and experience next-level productivity in Master Data Governance. Take a moment to also check our video on the newest Joule capabilities in MDG with demos and examples.

Interested in learning more about Joule’s capabilities or how to enable it for your team? Reach out to your SAP contact or check out the SAP Help Portal for the latest documentation and setup guides.

Hidden Crisis: Ageing Infrastructure, Reactive O&M, and the Data Problem No One Is Solving

2025-12-02T14:58:59.622000+01:00

Why ageing infrastructure and reactive maintenance are accelerating into a classic hockey-stick cost curve for oil and gas industry, and how trusted master data is the only realistic path to predictive excellence.

Dr. Imad Syed, CEO, PiLog Group

The oil and gas (O&G) industry remains one of the world’s most critical sources of primary energy, shaping global economic stability and long-term development. Yet behind this strategic importance lies an accelerating challenge: an ageing infrastructure that is pushing operations and maintenance (O&M) into a reactive, high-cost spiral.

Many upstream and midstream assets – platforms, pipelines, processing units and refineries – are now 20-30 years old. Science journal, Nature, found that many of the world’s 12,000 offshore platforms are nearing their end-of-life. More than 3,000 installations in the North Sea and Gulf of Mexico have already exceeded 25-30 years of operation.

Ageing assets drive a predictable but costly pattern: the “hockey-stick” curve of O&M costs. As corrosion, fouling, fatigue, and obsolete parts accumulate, operators are forced into more inspections, more emergency work, more reverse-engineering, and ultimately more unplanned shutdowns. Downtime alone can exceed $1 million per day per asset. Global outages contribute to more than 10 million barrels per day of lost production – representing nearly $200 billion in annual revenue foregone.

Our analysis of 18 global publicly listed O&G companies reveals that O&M already represents 18% of their total operating costs, rising to as high as 35% for some players. This cost pressure is magnified whenever price cycles trigger deferred maintenance, compounding future reliability risk.

Why Digital Investments Alone Don’t Solve the Problem

The industry has responded with aggressive investments in digital technologies. Global O&G digital transformation spend reached an estimated $77-90 billion in 2024 and is projected to rise to $90-124 billion in 2025: approximately 10-15% of upstream/downstream CAPEX.

Some leaders, including ExxonMobil, Chevron, and Saudi Aramco report strong returns through reduced downtime and optimized assets. However, scaling remains the industry’s biggest weakness: only 13-36% of firms have taken successful pilots into full-scale operations. Nearly 60-70% remain stuck in pilot mode.

The root cause is clear:

Digital tools generate data, but most O&G operators lack the foundational master data integrity required to turn that data into reliable decisions.

Sensors proliferate, but only 13% of companies use this data strategically. Legacy systems Maximo, ERP, SCADA, CMMS, engineering repositories, procurement databases hold conflicting records of the same assets, parts, BOMs, locations, and vendors. Without a ‘single version of the truth’, predictive models cannot be trusted, digital twins cannot remain accurate, and planners spend more time reconciling than optimizing.

The result: fragmented data, stalled initiatives, and a widening gap between digital ambition and operational reality.

Master Data Management (MDM): The Missing Foundation for O&M Transformation

Master Data Management is not a “data-cleaning exercise”, it is a structural capability that enables oil & gas operators to control the lifecycle, quality, and reliability of asset, equipment, material, and vendor data across all systems. When done properly, it directly addresses both the ageing infrastructure challenge and the industry’s deeply reactive maintenance culture.

MDM gives operators:

A single asset golden record (industry-specific) that integrates engineering, EAM, CMMS, inspection, procurement, and sensor data
Clean, enriched, audit-ready records of equipment, parts, hierarchies, and BOMs
Governance workflows that ensure every change is approved, traceable, and compliant
The ability to feed digital twins and AI engines with trusted, high-quality data
The foundation required to shift from reactive to predictive maintenance

Strengthening Asset Integrity for Ageing Infrastructure

Integrity management depends on reliable equipment history, correct system hierarchies, validated inspection data, and traceable change records. Ageing assets amplify the consequences of poor data – small inaccuracies can lead to missed integrity threats and unplanned shutdowns.

MDM provides:

A unified asset master data record (tag, serial, function, location, BOM, history, specs, certificates, maint. plan, etc)
Cleansing and enrichment with OEM data, calibration records, and criticality ratings
Governance that ensures every change, a modification, retrofit, or decommissioning is documented and approved

The result is an asset register that becomes the single, authoritative source for risk-based integrity planning and regulatory compliance.

Moving Beyond Reactive Maintenance to Predictive Excellence

Predictive maintenance cannot succeed without clean, consistent, and connected master data. AI/ML models rely on correct sensor-to-asset mapping, harmonized failure codes, and trustworthy historical labels.

MDM enables:

Accurate “sensor → asset → system” mapping
High-quality historical maintenance data aligned to standard failure modes
Enriched material masters with lead times, alternate parts, and criticality
Validated data flows into PdM engines, digital twins, and planning systems

Industry estimates indicate that predictive-maintenance excellence made possible by reliable master data can reduce unplanned downtime by 20-30% and cut maintenance costs by 5-15%, rising to 20-30% with advanced AI-based scheduling and spares optimization.

Reducing Costs Through Better Materials, Spares, and Inventory Data

Good master data creates quantifiable value:

Lower inventory and working-capital costs
Fewer emergency purchases
Higher first-time fix rates
Better compliance and reporting
Faster work-order planning and execution

O&G companies frequently carry 10-25% duplicate materials, which directly inflate procurement and storage costs. Clean, standardized material masters eliminate duplication, enforce catalogue discipline, and drive more strategic sourcing.

Case 1: The Real Cost of Bad Master Data in Oil & Gas / Petrochemicals

Symptom	Typical Annual Cost (per site)	Source
Duplicate / obsolete spares	$5–25 M	Solomon, Accenture, McKinsey
Excess inventory carrying cost (25–35 %)	$3–12 M	Deloitte 2024
Emergency purchases & expediting fees	$2–8 M	ARC Advisory
Unplanned downtime from “wrong part”	0.5–3 % of revenue (~$10–60 M for large refinery/upstream asset)	Solomon RAM Studies
Contractor inefficiency (re-work, waiting, repeated mobilizations)	15–40 % premium	EY, Bain

Total hidden cost: easily $20–80 M per year for a large refinery or offshore platform.

Case 2: Three Areas Where Clean Master Data Delivers Immediate ROI

Increasing Maintenance Budget (without asking for more money)

Clean equipment hierarchies + accurate BOMs → 20–40 % reduction in emergency work orders
Accurate failure codes and catalog profiles → better MTBF data → defensible reliability projects
Result: You re-allocate 10–25 % of existing maintenance spend from reactive to preventive/predictive → effectively “creates” new budget

Optimizing Spares Inventory (freeing up cash or hording cost)

De-duplication projects typically remove 12–15 % of Spares
Accurate min-max driven by real consumption (not guesswork) → 20–30 % inventory reduction in 12–18 months
Standardized material descriptions → vendor consolidation → source of supply mapping → 8–15 % purchase price reduction
Real case: Middle East refinery freed $38 M working capital in 14 months after master data cleanse

Optimizing Inbound Services & Contractor Spend

Clean functional locations + Clean equipment classification + standardized task lists → standardized BOMs → work packs issued with 95 %+ material availability
Accurate service master and vendor master (service provider) → automated 3-way match → 98 % touchless invoicing
Result: 25–40 % reduction in contractor waiting time and repeated mobilizations
Example: North Sea operator cut turnaround contractor cost by 18 % in 2024 just by fixing material master and BOMs

How PiLog’s DQG Suite Delivers These Outcomes

Together with SAP, PiLog has embarked on a partnership journey to address these industry challenges. Complementing and enriching SAP Intelligent Asset Management, PiLog’s Data Quality and Governance (DQG) Suite is built to deliver the exact MDM capabilities required for aging infrastructures, predictive maintenance, and integrated O&M operations. The solution is Endorsed and Premium Certified with over 200+ real-time integrations ready to deploy on-premise, private cloud & SaaS public cloud for SAP Cloud ERP Private & Public editions.

The suite provides:

End-to-end data migration, standardization, cleansing, enrichment, and governance
AI-enabled classification based on ISO 81346 and ISO 14224
Harmonized assets, equipment, and material records for SAP EAM, APM, and S/4HANA
Seamless integration with SAP APM, FSM, IBP (MRO), BNAC & Ariba
A foundation for digital twins, predictive maintenance, and data-driven operational excellence

Common Pain Points Identified Across PiLog’s O&G Customers

Duplicate or inconsistent material masters
Unstructured PR/PO creation and poor service masters
Missing or incomplete asset and equipment masters
Multi-entity inconsistencies across business groups

Quantifiable Improvements Delivered

Up to 25% duplicate detection and elimination
Up to 15% reduction in inventory hoarding
12% YoY reduction in O&M costs
22%+ reduction in sourcing and procurement cost

These results demonstrate that master data is not an IT function, it is an operational performance driver.

Aging Assets Are Inevitable – Reactive O&M Is Not

The industry cannot stop infrastructure from ageing. But it can change how it responds.

Digital investments alone will not close the reliability gap. A foundational shift to high-quality master data, governed, enriched, standardized, and connected across all systems – is what allows O&G companies to control the cost curve, extend asset life, and move decisively toward predictive maintenance excellence.

With the right master data foundations, operators can break the cycle of reactive firefighting and build a more reliable, safer, and economically resilient O&M model.

* References can be provided upon request

🚀 Ignite Your Data Architecture Journey: Empower Enterprise and Data Architects Today!

2025-12-03T05:18:15.798000+01:00

In the era of digital transformation, data is the heartbeat of innovation, strategy, and impactful decision-making. Strong Data Architecture is the foundation that powers every thriving enterprise. To bridge technical expertise with strategic business outcomes, the SAP Data Architecture experts alongside the SIX learning team proudly unveil the Data Architect Learning Journey (Foundational).

This inaugural phase of the Becoming a Data Architect program is crafted to equip aspiring architects, data professionals, and solution experts with essential frameworks, modern methodologies, and core principles that shape successful enterprise data architectures.

🏗️ Layered Learning: From Fundamentals to Enterprise Impact

This journey guides you through a carefully designed progression to build your expertise methodically:

Unit 1: Foundational Concepts anchors you in the fundamentals—mastering modeling techniques, metadata management, and the integration of data architectures with enterprise frameworks such as Zachman and TOGAF. Grasp the essentials of Conceptual, Logical, and Physical models that form the backbone of data design.
Unit 2: Modern Paradigms & Integration immerses you in today’s evolving landscape, exploring advanced patterns like Data Mesh, Data Fabric, Data Lake, and Data Lakehouse. Understand when and how to apply each, plus gain insights into key integration frameworks, including the nuances between ETL and ELT strategies.
Unit 3: Governance, Security & Strategic Value addresses the growing need to establish trust and compliance within expansive data ecosystems. Delve into comprehensive data governance frameworks—data stewardship, lineage, and privacy safeguards that secure modern architectures and enable AI/ML innovations.
Unit 4: Communicating Data Value sharpens your leadership voice, guiding you to communicate complex architectural changes clearly and compellingly. Learn to narrate the journey from the current state to future architecture, emphasizing quality, cost-efficiency, and scalability to align with business priorities.

🎯Who Should Embark?

Designed for data professionals ready to evolve beyond technical roles into influential architectural strategists, this foundation suits:

Data Engineers and Modelers aspiring to architect-level roles
Solution and Enterprise Architects deepening their data design acumen
BI and Analytics experts seeking architectural context
IT and Transformation leaders aligning data strategies with business goals

✅Why Now? Gain a Strategic Edge

Today’s enterprises demand architects who not only understand technology but who can also drive meaningful business outcomes. This journey empowers you to enhance data quality, governance, and alignment with enterprise strategies—skills that translate directly into leadership credibility and competitive advantage. Plus, it sets the stage for the upcoming SAP Certified Data Architect specialization, launching in 2026.

🛣️ Begin Your Path to Architecting Tomorrow

Ready to elevate your data architectural mindset and lead transformative initiatives? No prerequisites required—start your journey today!

Enroll now at SAP Learning: Becoming an SAP Data Architect – Foundational Learning Journey!

Recommendation/Best Practice for SAP Master Data Governance Extensibility in Classic Mode

2025-12-05T06:53:35.987000+01:00

Introduction to Clean Core in S/4HANA

With the introduction of MDG Cloud Ready Mode in SAP S/4HANA 2023, SAP has significantly intensified its emphasis on maintaining a clean core. SAP’s objective is clear: Organizations must transition toward a clean core, a system landscape where customizations are isolated from the core application, ensuring long-term stability, predictable upgrades, and seamless adoption of innovations delivered by SAP.

Customers opting for Cloud Ready Mode encounter stricter guardrails around extensibility. Traditional enhancement patterns—such as modifications, implicit enhancements, or pervasive use of custom code within standard classes—are heavily restricted. Only those extension approaches that guarantee lifecycle stability and upgrade resilience are supported.

Implications for MDG Customers in Classic Mode

For organizations currently using MDG in Classic Mode, but intending to maintain system stability and ensure smooth, low-effort upgrades, it becomes essential to adopt an extension strategy that aligns closely with clean-core guidelines. The extension approach must strike a balance between functional requirements and long-term maintainability, particularly in upgrade-intensive environments.

Organizations in Classic Mode face pressing questions:

How do we continue enhancing MDG without jeopardizing upgrade stability?
Which extensibility options remain viable, and which should be avoided?
How can we design custom logic that aligns with SAP’s forward-looking roadmap?
What development patterns minimize rework in future upgrades?

Recommended Extensibility Approach

Following SAP’s clean-core philosophy, the recommended extensibility hierarchy is as follows:

1. Key User In-App Extensibility

Preferred for UI and lightweight business logic enhancements, designed to be upgrade-safe and lifecycle-stable

2. Side-by-Side Extensibility

Ideal for more complex or custom business processes using SAP BTP, providing isolation from the S/4HANA digital core while ensuring deep integration through released APIs and events

3. Classic Extensibility

Classic extensions remain available in MDG Classic Mode, but they should be used sparingly and only when clean-core options cannot fulfil the requirement.

Classic extensibility includes:

BADIs specific to MDG
Enhancement points
Derivation and validation exits
Custom code within allowed enhancement frameworks

Considerations for MDG Extension Design

There have been attempts in Classic Mode to build wrapper classes around SAP standard MDG classes with the intention of stabilizing custom logic across upgrades. However, given the expanding set of released APIs and whitelisted objects, attempting to wrap all MDG-specific classes is time-consuming.

A more sustainable approach is to rely on:

Released MDG APIs, frameworks, and BAdIs
Workflow and rule-based configurability
Event-driven extension patterns via SAP BTP
Governance processes aligned with clean-core principles

Below table will outline the recommended and prioritized extension options for MDG in Classic Mode, offering guidance for customers seeking to preserve upgrade stability while aligning with SAP’s recommended enhancement strategy.

We will continue to revise and update the above list, as and when new scenarios and capabilities are identified.

Do you know how to Build essential skills to manage and improve master data quality with SAP?

2025-12-16T11:18:17.334000+01:00

I recommend to access our Exploring SAP Master Data Governance learning journey.

Learning outcome
After completing this learning journey, you will be able to:

• Explain the purpose and value of Master Data Governance in an enterprise setting
• Describe SAP’s Master Data Governance capabilities and deployment options
• Identify key governance processes, roles, and responsibilities
• Outline how controlled data creation, maintenance, and distribution improve data quality

Goals

Get started with SAP: Building the basics
Develop your expertise: Skill deepening learning
Excel in your expertise: Advanced specialization learning

Please post you question related to the digital learning Journey in the Q&A area.

Our SAP Learning Experts will get back to you as soon as possible!
We are here to support you.

I appreciate your feedback and we will make sure to continue sharing interesting topics.

Kind regards, Lian

4 Important enhancements related to Object type in SAP PM

2025-12-17T03:15:41.671000+01:00

Here are the top four important enhancements related to object type in SAP PM:

Default value of authorization group: The object type can be proposed for motors, pumps, compressors, electrical distribution lines, transmission lines, assembly lines, etc. Now for each of the object types there can be a default value of authorization group. We can maintain those values in a Z table. If any new object type is introduced, a default value can be added. The user can add the respective value of the authorization group later on.
Default value of Planner group: Planner groups generally work for a specific department or specific type of machine. In such a situation we can determine a specific planner group based on object type. This can be done by enhancing and maintaining the planner group and object type in the Z table.
Determine the catalog profile based on the type of object type: The catalog profile is very important for adding technical findings in the form of codes in a notification. The catalog profile should be specific to the technical object or technical object type. So, you can maintain a catalog profile and object type in a Z table and determine the catalog profile automatically at the time of creating a technical object. At the time of creating a notification, the catalog profile is determined automatically as a part of the standard SAP feature.
Determine the class and assign it to the equipment: You can determine the class automatically with respect to object type. For example, for object type "electrical pole," you can do an enhancement to determine its respective class automatically. You need to maintain the class and object type in a z table. It helps to assign the correct class to the technical object.

You can use user exit IEQM0003 for the check at the time of saving the equipment.

You can use the BAPI => BAPI_OBJCL_CHANGE to assign the class as per the object type in a equipment.

Regards,

Vaibhav Mishra

Rule Mining in a Nutshell, Manage your rules with Master Data Quality Rule Mining

2025-12-23T06:33:42.164000+01:00

Introduction

Rule mining, a fundamental element of master data quality management, enables more consistent and systematic data control. It also helps us define new rules, which in turn make data control easier and more organized. As a result, organizations strengthen data integrity, ensure consistency and build a more solid foundation for their business strategy.

Figure 1: MDQ Rule Mining entry point in Fiori

Why Rule Mining Matters

Rule Mining uncovers relationships in your data and makes rule management easier:

Discover new rules: As you can see in the screenshot below, new rules are presented, offering us many options to gain more control over our data.

Figure 2: Recommended Process Rules - System-generated rules based on existing data patterns.

Increase efficiency: With the new rules, you can improve data consistency more easily and quickly.

Figure 3: Validation Rules for Rule Mining

Enhance consistency: By performing evaluations and comparisons, you can manage your data more quickly and easily.

Figure 4: Evaluate Data Quality

Simplify maintenance: You can update BRF+ tables directly via Fiori without manually entering BRF+ information.

Figure 5: Simplified BRF+ Workbench

Business Benefits

Rule Mining is not just a technical feature—it directly adds value to business processes:

Better data quality: Rules enforce completeness and accuracy.

Operational speed: Clean data accelerates processes such as onboarding, procurement, and reporting.

Strategic advantage: Reliable data supports stronger decision-making.

Time savings: You can save time by managing rules more quickly.

Conclusion

MDQ Rule Mining allows you to discover and apply rules directly from your data, achieving efficiency and consistency. Using this method, we both improved data quality and discovered the ability to easily update BRF+ tables from Fiori, leading to faster rule management solutions than ever before. You too can improve data quality and save time by discovering new rules faster.

Thank you for reading,

Best regards.

Ahmet

Replicating DMS Documents via Web Services in MDG Scenarios

2026-01-13T12:47:42.354000+01:00

Content

1. Introduction

In SAP MDG scenarios, master data is governed centrally and replicated to connected systems using web services via the Data Replication Framework (DRF). For Business Partner data, this covers core attributes such as general data, roles, addresses, and bank details.

In many implementations, suppliers and customers have documents attached using SAP Document Management System (DMS). These documents are stored as Document Info Records (DIR) and linked to business objects via table DRAD. During Business Partner replication, document references are transferred as part of the message structure.

However, the content of the original files is not transferred. When source and target systems use different content servers, this results in document links in the target system that point to files users cannot access. Standard options such as DOCMAS IDocs are not web service–based and are not integrated with DRF, and SAP does not provide a standard solution for transferring file content in such scenarios.

This blog presents a custom approach that uses standard OData APIs to download document content from the source system and recreate Document Info Records with attachments in the target system, integrated into the MDG outbound replication process.

Note: This solution targets on-premise SAP environments. SAP S/4HANA Cloud offers its own DMS capabilities, which are outside the scope of this blog.

2. Scenario and Feasible Option

In our scenario, DMS documents are linked to ERP vendors in the MDG hub system. When vendors are replicated to target systems via web service, the document links are transferred but the actual files are not. Since the systems do not share a common DMS server, users in the target system receive document references that point to files they cannot access.

Two fundamental gaps prevent standard functionality from addressing this requirement: no web service-oriented document replication method exists, and file content cannot be transferred between separate content servers. A custom solution is required. The proposed approach consists of three steps:

Read document links from the source system: Query the DRAD table to identify all DMS documents linked to the vendor being replicated.
Download files from the source system: Use API_CV_ATTACHMENT_SRV to retrieve the actual file content for each linked document.
Create documents in the target system: Use API_DMS_PROCESS_SRV to create the Document Info Record and API_CV_ATTACHMENT_SRV to upload the file content. Then establish the object link to the replicated vendor.

This approach runs within the MDG outbound processing framework, ensuring that document replication is triggered automatically whenever a vendor is replicated via web services.

3. Technical Implementation

3.a Architecture Overview

Figure 1: DMS Document replication architecture overview

3.b Service Activation and Connection Setup

Before implementing the replication logic, the required OData services must be activated and the HTTP connections must be configured.

Service Activation

OData services must be activated in both systems via t-code /IWFND/MAINT_SERVICE:

API_CV_ATTACHMENT_SRV – API for Attachment Service
API_DMS_PROCESS_SRV – API for DMS

SM59 HTTP Destinations

In the source system, two HTTP destinations must be created in transaction SM59 to connect to the target system. Both destinations use connection type H (HTTP Connection to ABAP System).

Z_MER_DMS – Points to the API_DMS_PROCESS_SRV service. This destination is used for creating Document Info Records and establishing object links to the supplier.
Z_MER_DOCUMENT – Points to the API_CV_ATTACHMENT_SRV service. This destination is used for uploading file content to the DIR in the target system.

Figure 2: Configuration for Z_MER_DMS destination

Figure 3: Configuration for Z_MER_DOCUMENT

Both destinations should be configured with appropriate authentication credentials for the target system.

3.c Class Structure

The replication logic is encapsulated in a custom class. This class is initialized with a configuration structure and provides a single public method EXECUTE to trigger the replication process. Internally, the class handles reading document links, downloading files, and creating documents in the target system through private methods.

Figure 4: Replication class methods

The constructor accepts a configuration structure that controls the replication behavior:

TYPES: 
  BEGIN OF ty_config,
    source_supplier   TYPE lifnr, "Supplier number in source system
    target_supplier   TYPE lifnr, "Supplier number in target system
    target_doc_type   TYPE dokar, "Document type to be used in target system
    storage_category  TYPE string, "Content server storage category
    cv_destination    TYPE c LENGTH 20, "Destination name for attachment API
    dms_destination   TYPE c LENGTH 20, "Destination name for DMS API
  END OF ty_config.

3.d Read Document Links

The first step identifies all DMS documents linked to the supplier being replicated. This information is stored in the DRAD table, which maintains object links between DIR and business objects.

SELECT DISTINCT dokar, doknr, dokvr, doktl
  FROM drad
  INTO CORRESPONDING FIELDS OF TABLE _document_keys
  WHERE objky = _supplier AND dokob = 'LFA1'.

3.e Download Files via OData

Once the document links are identified, the actual files are downloaded from the source system using API_CV_ATTACHMENT_SRV. This process involves two calls: first to retrieve attachment metadata, then to download the binary content.

CSRF Token Handling

Before making any OData calls, a CSRF token must be fetched:

lv_url = gc_cv_service_path && '/$metadata'.

cl_http_utility=>set_request_uri( request = lo_http_client->request  uri = lv_url ).

lo_http_client->request->set_header_field( name = 'x-csrf-token' value = 'Fetch' ).
lo_http_client->request->set_method( 'GET' ).

lo_http_client->send( ).
lo_http_client->receive( ).

lv_csrf_token = lo_http_client->response->get_header_field( 'x-csrf-token' ).

Retrieving Attachment Metadata

For each DIR key, the attachment metadata is retrieved through the navigation property:

lv_url = gc_cv_service_path &&
         |/A_DocumentInfoRecordAttch(| &&
         |DocumentInfoRecordDocType='{ ls_dir_key-dokar }',| &&
         |DocumentInfoRecordDocNumber='{ ls_dir_key-doknr }',| &&
         |DocumentInfoRecordDocVersion='{ ls_dir_key-dokvr }',| &&
         |DocumentInfoRecordDocPart='{ ls_dir_key-doktl }')
         /DocumentInfoRecordToAttachmentNavigation|.

This returns metadata including LogicalDocument, ArchiveDocID, Filename, and MimeType.

Downloading Binary Content

The actual file content is downloaded using the $value endpoint:

lv_url = gc_cv_service_path &&
         |/AttachmentContentSet(| &&
         |DocumentInfoRecordDocType='{ is_nav-documentinforecorddoctype }',| &&
         |DocumentInfoRecordDocNumber='{ is_nav-documentinforecorddocnumber }',| &&
         |LogicalDocument='{ is_nav-logicaldocument }',| &&
         |ArchiveDocumentID='{ is_nav-archivedocumentid }',| &&
         |...)/$value|.

lo_http_client->send( ).
lo_http_client->receive( ).

rs_file-content = lo_http_client->response->get_data( ).  " Returns xstring

The get_data( ) method returns the binary content as xstring.

3.f Create Document in Target System

Creating a document in the target system involves three sub-steps: creating the Document Info Record, establishing the object link to the supplier, and uploading the file content.

DIR Creation

First, a new Document Info Record is created via API_DMS_PROCESS_SRV:

lv_url = '/A_DocumentInfoRecord'.
lv_json = |\{| &&  |"DocumentInfoRecordDocType":"{ ms_config-target_doc_type }",| &&
          |"DocumentInfoRecordDocVersion":"00",| &&
          |"DocumentInfoRecordDocPart":"000"| &&  |\}|.

io_dms_client->request->set_method( 'POST' ).
io_dms_client->request->set_header_field( name = 'x-csrf-token' value = iv_csrf_token ).
io_dms_client->request->set_header_field( name = 'Content-Type' value = 'application/json' ).
io_dms_client->request->set_cdata( lv_json ).

Object Link Creation

After the DIR is created, the link to the supplier is established via the to_ProductObj navigation property:

lv_url = |/A_DocumentInfoRecord(| &&
         |DocumentInfoRecordDocType='{ is_dir_key-dokar }',| &&
         |DocumentInfoRecordDocNumber='{ is_dir_key-doknr }',| &&
         |DocumentInfoRecordDocVersion='{ is_dir_key-dokvr }',| &&
         |DocumentInfoRecordDocPart='{ is_dir_key-doktl }'/to_ProductObj|.

lv_json = |\{| && |"LinkedSAPObject":"LFA1",| &&
          |"LinkedSAPObjectKey":"{ lv_supplier }"| &&  |\}|.

File Upload

Finally, the file content is uploaded via API_CV_ATTACHMENT_SRV. The filename is passed in the header and the binary content is sent in the request body:

lv_url = |/A_DocumentInfoRecordAttch(| &&
         |DocumentInfoRecordDocType='{ is_dir_key-dokar }',| &&
         |DocumentInfoRecordDocNumber='{ is_dir_key-doknr }',| &&
         |DocumentInfoRecordDocVersion='{ is_dir_key-dokvr }',| &&
         |DocumentInfoRecordDocPart='{ is_dir_key-doktl }')
         /DocumentInfoRecordToAttachmentNavigation|.

io_cv_client->request->set_method( 'POST' ).
io_cv_client->request->set_header_field( name = 'x-csrf-token' value = iv_csrf_token ).
io_cv_client->request->set_header_field( name = 'Content-Type' 
                                  value = 'application/octet-stream' ).
io_cv_client->request->set_header_field( name = 'Slug' value = is_file-filename ).
io_cv_client->request->set_header_field( name = 'StorageCategory' 
                                         value = ms_config-storage_category ).
io_cv_client->request->set_data( is_file-content ).

3.g Hook into MDG Outbound Processing

To trigger document replication automatically during Business Partner replication, we implement the IF_MDG_SE_BP_BULK_REPLRQ_OUT interface.

METHOD if_mdg_se_bp_bulk_replrq_out~outbound_processing.

  DATA(lv_bp_number) = in-partner-header-object_instance-bpartner.
  
  IF lv_bp_number IS INITIAL.  
   RETURN.  
  ENDIF.

  DATA(lo_replicator) = NEW zcl_dms_doc_replication(
    is_config = VALUE #(
      source_supplier  = lv_bp_number
      target_supplier  = lv_bp_number  "Generally same with source supplier number
      cv_destination   = 'Z_MER_DOCUMENT'
      dms_destination  = 'Z_MER_DMS'
      target_doc_type  = 'KPR'
      storage_category = 'DMS_C1_ST' ) ).

  TRY.
      DATA(ls_result) = lo_replicator->execute( ).
    CATCH cx_static_check INTO DATA(lx_error).
      " Handle error
  ENDTRY.

ENDMETHOD.

This ensures that whenever a supplier is replicated through the standard MDG replication process, the associated DMS documents are replicated automatically.

4. Conclusion

In web service-based SAP MDG scenarios, replicating Business Partner master data without its associated DMS documents leads to incomplete and confusing results for end users. This blog demonstrated a practical and reusable approach to closing this gap by leveraging standard OData APIs and integrating the logic directly into the MDG outbound processing framework. By this logic, DMS documents can be replicated automatically whenever a supplier is replicated.

The same concept can be extended to other business objects, such as customers or materials, that use DMS attachments. Until SAP delivers a web service–based document replication solution integrated with DRF, this approach provides a robust alternative for MDG implementations that require consistent document availability across systems.

Thank you for reading.
Best regards,

Merve

Switch to the new mass apps for business partner master data on SAP S/4HANA Cloud Public Edition!

2026-01-23T18:26:09.892000+01:00

Do you still use the deprecated apps for mass load and mass maintenance for business partners on SAP S/4HANA Cloud Public Edition? It is now to benefit from the successor apps and prepare your environment before the old apps will be removed. This post provides you with more information and details on how to make the switch.

⚠️Important This activity must be completed before the deprecated apps are no longer available! This is planned for release 2608.

Why should I switch?

The new apps are enhanced in several dimensions:

Useability is enhanced with a new dialog to start a mass change process that allows you to more flexibly define the selection criteria. Selection criteria can now be reviewed and refined from the top of the page. It is no longer required to specify a scope of the change. Overall, this makes working with the app more intuitive.
Using data from a file for a mass change or mass load is now directly possible from the aforementioned dialog.
These 2 changes make the Manage Mass Maintenance app the central point to start mass processes. No need for the separate Tile Start Mass Processing.
The new version of the app provides additional process attributes, such as due date.
Customers with the additional license for SAP Master Data Governance can now display each business partner in the app Manage Business Partner – Central Governance, providing a single view on the complete business partner (see Additional Scope Items below).
Finally, the new version offers the most recent user experience and generic features of SAP Fiori, for example to collaborate with other users

What must I do?

There are 3 basic steps for making the switch happen:

First, you should finalize all ongoing mass maintenance processes or delete the process if it is no longer relevant. This is recommended as processes created with the deprecated version of the Manage Mass Maintenance app are no longer visible in the new version of the app.
Activate the feature Successor MDG apps for business partners (MDC_BP_CLOUD_READY).
Remove the deprecated Business Catalogs Mass Load - Business Partner Master (Deprecated) (SAP_CMD_BC_BP_MASSLOAD_PC) and Mass Maintenance - Business Partner Master (Deprecated) (SAP_CMD_BC_BP_MASSMAINT_PC). Assign the successor Business Catalog Master Data Governance - Mass Maintenance for Business Partners (SAP_CMD_BC_BPCS_MAINT_PC). This will adjust your role to the updated business role template Master Data Specialist - Business Partner Data (SAP_BR_BUPA_MASTER_SPECIALIST).
Finalize the procedure by starting the app Export Master Data - Business Partners (Fiori ID F6551A) and export any selection of business partners (at least one).
Important: This is a mandatory step that completes technical setting to enable all new apps!

In case you need more detailed instructions, here they are:

More Detailed Instructions

How to activate the feature?

Follow the documentation Activate Features to find the correct configuration environment according to your system landscape. Eventually, you will find the item Basic Settings and launch this item.

This leads you to the activity Activate Features. Search for the feature Successor MDG apps for business partners (MDC_BP_CLOUD_READY) and activate it. Note: The feature is not reversible, so please test your processes before activating in your production tenant!

How to change the business role for my users?

Examine the business role that you use for your master data specialists using the app Maintain Business Roles. On tab Business Catalogs you will find the two catalogs Mass Load - Business Partner Master (Deprecated) (SAP_CMD_BC_BP_MASSLOAD_PC) and Mass Maintenance - Business Partner Master (Deprecated) (SAP_CMD_BC_BP_MASSMAINT_PC). Note that both of them are marked as deprecated.

Remove these catalogs form the business role. Instead, add the catalog Master Data Governance - Mass Maintenance for Business Partners (SAP_CMD_BC_BPCS_MAINT_PC).

You can also use the function Manage Changes After Upgrade that becomes visible once you switch the business role to edit mode.

If your business role is based on the business role template Master Data Specialist - Business Partner Data (SAP_BR_BUPA_MASTER_SPECIALIST), you can also use the app Business Role Templates to compare and adjust the role.

How to finalize with the export?

It is important to finalize the switch procedure by performing an arbitrary selection of business partners, at least one. Launch the app Export Master Data - Business Partners (Fiori ID F6551A). For example, in the section Define Scope enter BUT000 in the field Select Tables, then enter a business partner number that will select at least one business partner. Also make sure that not too many are selected to avoid spending too much time. After that press Export and if you are satisfied with selected number of business partners, once more Export. There is no need to download the file. It is only important that the export completes.

Done!

You should now be able to use the new app Manage Mass Maintenance – BP (Fiori ID F7974) and all the other new apps included in the new business catalog.

Additional Scope Items

Customers with the additional license for SAP Master Data Governance can active scope item Central Governance for Business Partner (1N7) for additional capabilities.

Business Partner Master Data in SAP Cloud ERP 2602

2026-02-12T13:12:31.201000+01:00

In today's fast-paced digital economy, the integrity, security, and accessibility of master data are paramount to operational excellence. High-quality Business Partner data forms the foundation of countless critical processes, from procurement and sales to finance and compliance. I am pleased to share some of the latest innovations within SAP S/4HANA Cloud that are designed to elevate your business partner master data management strategy.

SAP Cloud ERP is part of SAP Business Suite that brings AI, data, and applications together into a fully integrated system. This community is open for anyone in the cloud ERP ecosystem–customers, partners, and SAP experts.

To strengthen security and data integrity, we implement header-level authorization checks and proactive duplicate detection to prevent unauthorized access and ensure high-quality, reliable data from the outset. At the same time, onward replication across multisystem landscapes and conversational AI through Joule enable seamless synchronization and intuitive access to information, driving efficiency, transparency, and faster decision-making across the enterprise.

This post will provide an overview of four significant new features:
1. Enhanced security through header-level authorization checks.
2. Proactive data quality management with an API-based duplicate check.
3. Streamlined data synchronization via onward replication in multisystem landscapes.
4. Efficient data access using our conversational AI, Joule.

1. Enable Business Partner Header-Level Authorization Checks Based on Data Controller and Purpose

Data privacy and compliance are non-negotiable. To provide more granular control over sensitive information, we have introduced the ability to enable authorization checks at the business partner header level based on the combination of a Data Controller and a Purpose.

Feature Scope:
This feature allows for the assignment of specific data controller and purpose combinations directly to a business partner record. Subsequently, the system can enforce authorization checks based on these assignments.

Key Benefits:
The primary advantage is a significant enhancement in access control. With this feature activated, a user must be explicitly authorized for the specific data controller and purpose assigned to a business partner to gain access to that record. This ensures that only relevant personnel can view or process sensitive data, strengthening your data governance and compliance posture in line with regulations like GDPR.

Business partner: assignment of purposes along with data controllers

2. Business Partner A2X OData API Operation for Duplicate Check

Maintaining a clean and duplicate-free master data repository is a constant challenge, especially in integrated environments. To address this proactively, we have extended the capabilities of our core Business Partner OData service.

Feature Scope:
A new operation for performing a duplicate check has been added to the `API_BUSINESS_PARTNER` A2X OData service. This operation can be invoked for Business Partners, Customers, and Suppliers.

Key Benefits:
This new functionality empowers external applications to identify potential duplicates before a new master data record is created via the API. By embedding this check into the creation process, organizations can prevent the introduction of redundant data at the source. This is a crucial step toward retaining high master data quality, reducing downstream cleanup efforts, and ensuring process consistency across the enterprise.

Please refer to following Blogs:

Duplicate Check in Business Partner A2X

3. Business Partner Integration: Onward Replication in a Multisystem Landscape

For organizations managing complex system landscapes, ensuring data consistency across all systems is a major undertaking. Our new onward replication capability simplifies this process significantly.

Feature Scope:
This feature allows you to trigger the onward replication of incoming business partner data from your SAP S/4HANA Cloud ERP system to all other connected systems in your landscape. Activation is managed through a simple self-service configuration user interface (SSCUI).

Key Benefits:
This innovation enables your SAP S/4HANA Cloud system to function as a true master data hub. When a business partner is created or changed, the system automatically distributes these updates to all subscribed downstream systems. This automated synchronization ensures data consistency across the entire landscape, reduces manual integration efforts, and minimizes the risk of data-related process failures.

Onward Replication of Business Partner Master Data in SAP S/4HANA Cloud ERP

Community Blog: Onward Replication of Business Partner master data in SAP S/4HANA Cloud Public Edition

4. Joule as Efficient Access to Business Partner, Customer, and Supplier Master Data

In our pursuit of a more intelligent and user-friendly ERP experience, we have integrated our conversational AI, Joule, with master data management.

Feature Scope:
Joule now allows users to efficiently access attributes of Business Partner, Customer, and Supplier master data objects using natural language queries.

Key Benefits:
This feature fundamentally streamlines the process of data retrieval for business users. Instead of navigating through multiple Fiori apps and screens, a user can simply ask Joule a question, such as "Show me the addresses for Business Partner 100345" or "What are the dunning data details for Customer XYZ?". The key benefits include:

- Enhanced Productivity: Immediate access to necessary data saves time and effort, allowing analysts to focus on decision-making rather than data retrieval.
- Reduced UI Clicks: Joule provides extremely quick information about attributes without requiring users to open dedicated applications.
- Intuitive Interaction: Natural language input makes data access more accessible to a wider range of users.
BP, Customer, Supplier Master Data in SAP Joule

Joule can provide details ranging from a business partner overview, roles, and relationships to specific customer sales area data and supplier purchasing organization details.

Community Blog; Exploring Business Partner Master Data with SAP Joule, the AI Co-pilot

These four features represent a significant step forward in making master data management more secure, intelligent, and efficient within SAP S/4HANA Cloud. By enhancing security, improving data quality at the point of entry, simplifying landscape-wide synchronization, and accelerating user access, we are empowering our customers to build a more robust and reliable data foundation for their enterprise.

📽️ Watch the replays of our SAP Cloud ERP 2602 Early Release Series!

From January 12-16, we hosted a series of 22 expert-led live sessions to highlight the exciting innovations shipped with the SAP Cloud ERP 2602 release. Missed the live sessions? We've got you covered! Take advantage of the entire series or pick and choose the sessions most relevant to you. You will find the recording and presentation for LoB/Industry/Topic as well as 21 other topics of interest. Don't miss this chance and watch them on demand–anywhere, anytime.

🔎 Find all our assets

We at Cloud ERP and SCM Product Success offer a service as versatile as our product itself. Check out the numerous offerings our team has created for you below:

SAP Master Data Governance, cloud edition – Maintenance Windows and Major Upgrade Windows in 2026

2026-02-12T18:25:20.539000+01:00

Major Upgrade Windows

As in 2025, the SAP Master Data Governance, cloud edition has 4 Major Upgrade Windows in 2026. These 24 hours of potential system unavailability are used to upgrade the systems to the next major version.

May 16th – 17th (Release 2605)
August 15th – 16th (Release 2608)
November 14th – 15th (Release 2611)

Depending on the data center region, the 24 hours downtime will start/end at:

Europe: SAT 4 am – SUN 4 am UTC
Americas: SAT 10 am – SUN 10 am UTC

Weekly Maintenance Windows

Potentially every weekend, the SAP Master Data Governance, cloud edition could use a downtime of 4 hours, to apply database updates, Hotfix Collections and other changes.

Depending on the data center region, the 4 hours downtime may start at:

Europe: SAT 9 pm UTC
Americas: SUN 5 am UTC

The following events for the release 2602 are planned as Weekly Maintenance Windows in 2026:

Hotfix Collection ... for Release 2602 | ... (information will be updated accordingly)

Cloud System Notification Subscriptions (CSNS)

Please register to Cloud System Notification Subscriptions (CSNS) in SAP for Me to get important information about planned and unplanned downtimes:

Please register to Cloud System Notification Subscriptions (CSNS) in SAP for Me to get important information about planned and unplanned downtimes:
- Access to Cloud System Notification Subscriptions (CSNS): https://me.sap.com/systemsprovisioning/getNotified
- Find more information about Cloud System Notification Subscriptions (CSNS) in this documentation
- To find SAP Master Data Governance, cloud edition entry select:
  - Subscription Type: Cloud Service
  - Solution Area: SAP Master Data Governance, cloud edition

References

SAP Data Reconciliation: Moving from Matching Maze to The Autonomous Future

2026-02-20T16:17:57.003000+01:00

BACKGROUND

There are two types of SAP reconciliation meetings during cutover.

Meeting Type 1 (What we planned):

“Let’s quickly confirm data moved correctly.”

Meeting Type 2 (What actually happens):

Finance says revenue looks off.
Procurement says suppliers are complaining.
Supply chain says inventory is inflated.
IT says record counts match.
Everyone stares at IT.

Welcome to the beautiful chaos of SAP data reconciliation.

Whether you’re:

Splitting a company
Running S/4 alongside ECC
Sharing data with subsidiaries
Migrating to a new instance
Or integrating systems after M&A

Data matching in SAP is not just technical data reconciliation. It’s business continuity surgery.

Why SAP Reconciliation Feels So Painful Today with current ETL tools?

Let’s be honest about the current state.

We Reconcile Tables, Not Decisions

We check:

Counts
Totals
Field matches

But business runs on:

Commitments
Revenue recognition
Inventory valuation
Working capital

Matching tables ≠ preserving business intent.

SAP Processes Are Chains, Not Records

Every transaction is part of a flow:

Forecast → Production → Inventory → Sale → Revenue
Contract → Order → Delivery → Billing → Cash
Budget → Commitment → Accrual → Payment

Break one link, and financial truth bends quietly.

Reconciliation today doesn’t understand chains. It understands spreadsheets.

Customization Is Everywhere

Every SAP system has:

Custom fields
Custom pricing logic
Custom movement types
Custom account determination
Custom approval flows

Generic reconciliation tools look at this and say: “Good luck.”

Real Business Reconciliation KPIs (Not Row Counts)

Let’s talk about reconciliation the way your CFO thinks about it.

Procure-to-Pay (P2P): The “Where Did My Money Go?” Flow

Business Flow:

PO Amount → GR Amount → Invoice Amount → Payment Amount

Real Business KPIs:

PO to GR Consumption Ratio

What % of PO value has been physically received?

Detects over-delivery or under-delivery
Identifies ghost POs
Highlights operational leakage

If PO is $1M and GR is $1.4M, someone is shopping.

GR to Invoice Variance %

Are vendors invoicing more than what was received?

Detects pricing issues
Catches duplicate invoicing
Flags freight/tax mismatches

This is not technical reconciliation. This is margin protection.

Order-to-Cash (O2C): The “Where Did My Revenue Go?” Flow

Business Flow:

Sales Order → Delivery → Billing → AR → Cash

Real Business KPIs:

Order Fulfillment Integrity

% of orders fully delivered as priced.

Detects partial deliveries not billed
Finds pricing condition errors
Highlights logistics-billing gaps

Delivery-to-Billing Variance

Does billing reflect delivered quantity and agreed price? This catches:

Wrong pricing conditions
Missed surcharges
Freight miscalculation

Revenue leakage hides here.

Manufacturing: The “Why Is My Warehouse Lying?” Flow

Business Flow:

Material → Production → Inventory → Valuation → COGS

Real Business KPIs:

Inventory Valuation Consistency

Does total inventory value match between systems by:

Plant
Material group
Valuation class

Mismatch here = financial statement distortion.

BOM Integrity Impact

% of production orders where:

Component consumption matches BOM
Standard cost matches actual cost

Incorrect BOM migration? It is cost explosion.

The Real Question for the Future

When we reshare data between SAP systems in the future, we should not ask:

“Did the data copy and tables and fields match?”

We should ask:

“Did the business outcome stay intact?”

That is a completely different problem. And it requires a completely different capability set.

The Future: Business-First, Agentic SAP Reconciliation

Let’s imagine what reconciliation should look like 5 years from now.

Not reactive. Not 400 dashboards..

But autonomous, business-aware, and proactive.

Flow-Centric Reconciliation

Instead of reconciling:

Material master
Vendor master
GL master

We reconcile:

Revenue lifecycle integrity
Working capital stability
Margin preservation
Inventory flow accuracy
Commitment-to-cash cycles

Example:

Instead of: “Material record count and fields matches.” The system says:

“Inventory valuation variance of 1.8% driven by missing moving average price adjustments in 3 plants. Financial impact: $2.1M.”

That’s business reconciliation.

Agentic Automation Capabilities of Future Data Reconciliation Tool

Here’s what real agentic SAP reconciliation must be capable of:

1. Business Context Modeling

The system must understand:

How revenue is recognized
How inventory is valued
How pricing conditions affect margin
How tax determination impacts compliance
How cost flows through production

Not just tables — but intent.

2. Cross-Process Correlation

If:

Billing increases
But cash conversion drops
And AR aging shifts

The system correlates these across modules. SD + FI + CO + Treasury. Today, that takes 3 teams and 2 weeks.

Future system: “Cash conversion delay traced to payment term misalignment for customers migrated from legacy region.”

3. KPI Stability Monitoring

When data is migration between SAP systems, the system should monitor:

Revenue per customer
Margin per product
Inventory turns
Working capital ratio
DSO / DPO shifts
Production yield

If KPIs deviate outside normal behavior bands. Alert triggered. Because business drift matters more than table drift.

4. Intelligent Variance Classification

Not every difference is a problem. Agentic reconciliation should classify:

Configuration difference
Timing difference
Master data gap
Transaction sequencing issue
True financial error

And suggest action.

Not just: “Mismatch found.”

But: “Difference due to delayed goods issue posting in target system. Expected to auto-correct in next batch.”

That reduces panic and so many meetings.

Executive-Ready Narrative

Future reconciliation shouldn’t produce:

47 dashboards
16 pivot graphs
A nervous data analyst

It should produce:

“Post SAP data migration, revenue and margin remain stable within historical variance bands. Minor inventory timing differences detected in 2 plants with no financial impact. No systemic control breaks identified.”

That’s board ready confidence.

The Big Shift: From Data Movement to Business Assurance

Old model:

Move data. Validate data. Sign off.

Future model:

Simulate business impact. Continuously assure process integrity. Autonomously detect drift. Explain root cause.

Reconciliation becomes less about matching numbers…and more about protecting enterprise behavior.

What Organizations Expect in Future SAP Reconciliations?

In the future, companies won’t ask: “How many records mismatched?” They’ll ask:

Are warehouse movements as expected?
Did margin integrity hold?
Did working capital spike?
Did revenue timing shift?
Did operational velocity slow down?
Did risk exposure increase?
Does financial demand and supply are working as expected?

That’s reconciliation redefined in the era of agentic automation!!

Part 1: Introduction & Overview	Link
Part 2: Integration of Employees from SAP SuccessFactors	Link
Part 3: Integration of Business Partners & Material from SAP Master Data Governance (MDG)	Link
Part 4: Integration of Functional Locations & Equipment from SAP S/4HANA On-Premise System	Link
Part 5: Extensibility Scenarios & Further Implementation	Link
Part 6: Summary & Outlook	Link