MDG Topic 2

5/19/2023
Master Data Governance

Generated on: 2023-05-19 14:33:21 GMT+0000
SAP S/4HANA | 2022 Latest
PUBLIC
Original content: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/6d52de87aa0d4fb6a90924720a5b0549?locale=en-US&state=PRODUCTION&version=2022.001
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation. The information included in custom
documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not
for productive use.
For more information, please visit the https://help.sap.com/docs/disclaimer.
This is custom documentation. For more information, please visit the SAP Help Portal 1
5/19/2023
Customer
Use
Master Data Governance for Customer enables you to monitor and control the creation, editing, and deletion of business partner master data.
A typical work ow starts with a user creating or changing data and submitting the change request. A master data expert then reviews the change request. In an additional step the
initial user may need to make changes, and nally the master data expert approves the change request. As a result the system updates or creates the appropriate business partner
master record.
Change Request Processing

The following documents about change request processing outline the functions and processes used for creating and processing change requests. During a typical work ow a user
might rst search for a customer, then generate a change request to create, change, or mark a customer for deletion, depending on his or her requirements. The user can also
change multiple customers at the same time using the Create Change Request and Mass Change services.
The user does not actually create, change, or mark customers for deletion; instead he or she creates change requests that are sent for approval by a Master Data Specialist. Once
this expert approves the change request, the new or updated customer data is written to the active area. During the change request process the new or changed master data is
stored in the master data governance staging area.
The change request worklist provides the user - either a normal user or a reviewer - with a list of work items to be considered. The user typically opens a work item in the Change
Requests screen from which he can activate the change request, reject the change request, validate the change request data, view the validation log, forward the change request, or
perform a variety of checks. The user can also access the BCV side panel to view additional information for the change request. For more information, see Con guring Business
Context Viewer for MDG Customer.
The steps in a typical work ow are outlined below:
1. The user creates a change request and the data in the change request is written to the staging area. The user may use the duplicate check to have the system scan for
duplicate data as well as additional checks to ensure the consistency of data.
2. The change request is sent to a Master Data Steward to review and approve.
3. The Master Data Steward reviews the change request and either approves it or rejects it.
If the Master Data Steward rejects the change request, it is sent back to the creator, who can either discard the change request or modify and resubmit it.
If the Master Data Steward approves the change request, the information in the change request is written to the active area and the process is complete.
 Note
Any work ow step offers the possibility to perform checks either by choosing a Check button, by choosing Next to continue or by choosing Enter. The extent of checks being
performed at each work ow step, for example duplicate check, validity check or required elds check are speci ed in the Customizing.
If a validity check or required elds check reports an error then the change request cannot be activated.
Search Customer
Use
The search customer service enables you to search for and display customers based on speci ed criteria. You can use a large range of attributes to search including names,
addresses, bank details and identi cation numbers. From the search results list you can choose to display, edit, replicate, create, or copy a customer.
Activities
The search offers the following possibilities:
Search Method
A variety of search methods offer sets of prede ned search criteria.
Additional Search Lines
You can extend or reduce the number of search criteria if required using the Insert New Line and Delete Row buttons.
Save and Load Searches
You can save a set of search parameters and load them for use at a later time.
Fuzzy Search
Depending on the Search Method chosen a Fuzzy Search check box is offered.
Maximum Number of Results
You can use the Maximum Number of Results eld to limit the number of results displayed.
Number of Search Result Records
5/19/2023
You can see the number of search result records, which includes blocked data related to customer.
 Note
The following points should be kept in mind when formatting your search:
If you search for two or more different attributes then the search lters its results based on an AND logic.
When searching a single attribute for more than one parameter the search lters its results based on an OR logic.
Creating a Customer
Prerequisites
You have maintained a change request type for customer creation and have set up your work ow for this change request type.
Context
You can use the Create Request service to create a change request for customer creation. This change request goes through the predetermined work ow process and when
complete results in the creation of a new customer in the active area.
Procedure
1. Selecting the change request type
In the Search Customer section, choose New and then select Organization or Person or Group.
2. Select a change request type in the Available Change Request Types dialog box.
3. Enter change request details
In the Change Request section, enter a description for your change request in the Description eld. You can enter details for your change request such as priority, due date,
and reason. You can also add comments and attach relevant les directly or by link.
4. Enter details for new customer
In the Customer Details section, enter the data for your customer. You can enter details for your change request such as general data, organizational data, address data and
communication data.
 Note
You can check your entries choosing theCheck button. Depending on the data entered an Address Validation dialog box asking for further input may be displayed. If similar
customer data already exists in the system a duplicate check dialog box will inform you about the potential duplicate. We recommend to start creating a customer with a
search.
5. Submit your change request
When you have entered your data choose the Submit button to trigger the work ow. As the rst step the checks as mentioned above will be performed.
 Note
To save the change request for use at a later time choose Save.
Results
The new change request for customer creation is created and sent for processing according to the rule-based work ow you have assigned to the create customer process. Usually,
this means that it passes to a Master Data Steward who reviews the changes. During this time the new customer is stored in the master data governance staging area and does not
appear in the active area. Once the Master Data Steward has approved the change request and technical validation has taken place, the new customer is written to the active area.
Enriching a Customer
 Restriction
As of Q1 of 2021, the SAP Data Enrichment service is not available for purchase. Existing customers can continue to use SAP Data Enrichment until the end of their license term.
Use
By integrating with SAP Cloud Platform Data Enrichment, you can enrich your existing customer with data from external data providers. This eliminates or reduces the costs and
efforts involved with manual data creation and maintenance. You can use these integration features with the Change Request app.
Prerequisites
You have con gured data enrichment integration as described in Data Enrichment Integration.
You have maintained a change request type for customer creation and change.
You have set up your work ow for this change request type.
5/19/2023
You have speci ed BP Enrichment as relevant in enhancement spots and checks using the Change Request step view. To do this, use the Customizing activity Master Data
Governance, Central Governance General Settings Process Modeling Change Requests Con gure Properties of Change Request Step .
You have activated the following event type linkages:
Object Type: BUS2250, Event: ACTIVATED , Receiver Type: ACTIVATED_DE
Object Type: BUS2250, Event: ROLLED_BACK , Receiver Type: ROLLED_BACK_DE
To do this, use the Customizing activity Master Data Governance, Central Governance General Settings Process Modeling Work ow Activate Event Type Linkage
You have added the Data Enrichment UIBB in the Change Request app by choosing Personalize Change Layout Add Data Enrichment .
Procedure
1. Select the customer category.
In the Search Customer section, choose New, and select Organization. Note that you can enrich data only for customer type Organization.
2. Choose Create Customer.
3. Enter details of the new customer.
In the Change Request section, enter a description for your change request in the Description eld.
In the Customer Details section, enter Name1, Country, and City. These are the mandatory elds for data enrichment.
4. Check your entries by choosing the Check button. Depending on the data entered, a dialog box is displayed with matched records from data enrichment.
5. Choose Continue to view details of the matched records. Another dialog box opens with the eld level data from data enrichment.
6. Select the data you want to import, and choose Enrich. The system navigates back to customer screen.
7. Make sure that the Address, Identi cation Numbers, and Data Enrichment blocks are lled correctly.
8. If required, enter additional data for the new customer.
9. Choose Submit to trigger the work ow.
Key Mapping
Key mapping is maintained between MDG and data enrichment systems for Business Partner ID and Data Enrichment ID. You can view the key mapping information in the Data
Enrichment UIBB.
Additional Information
For more information on SAP Cloud Platform Data Enrichment, see SAP Cloud Platform Data Enrichment.
Changing a Customer
Prerequisites
The customer to be changed exists in the active area and is not locked by another change request.
You have maintained a change request type for customer change and have set up your work ow for this change request type.
Context
You can use the Change Request service to create a change request for changing a single customer. This change request goes through the predetermined work ow process and when
complete results in the change of the selected customer in the active area. Creating the change request copies the customer to the staging area. A customer can only be assigned to
one active change request at a time, so no new change requests can be created for a customer that is already in the staging area.
 Caution
If you use the back-end system to make changes to a eld in the BP data model while the customer is undergoing the change request process, when the change request is
approved, all your changes will be overwritten and not just those elds affected by the change request.
You will however receive a warning during validation that this data has changed and you then have the option of viewing the changes made in the back-end system and
incorporating them into your change request. You can then submit the change request for validation again.
Procedure
1. Select a customer in the search result list
In the Search Customer service, select a customer in the result list.
2. Change to edit mode
To change the customer to edit mode, choose the Edit button.
3. Select a change request type
In the Available Change Request Types dialog box, select a change request type.
5/19/2023
In the Change Request section, enter a description for your change request in the Description eld. For further details see the corresponding section in Creating a Customer.
5. Enter changes and submit
Enter the changes you want to make to the customer and click the Submit button to submit your change request. For further details see the corresponding section in Creating
a Customer.
Results
Your new change request is created and sent for processing according to the rule-based work ow you have assigned to the change customer process. Normally this means that it
passes to a Master Data Steward who reviews the changes. Once the change request has been approved and technical validation has taken place, the changed customer data
replaces the existing data in the active area. The customer is no longer available in the staging area and can be included in new change requests.
Marking a Customer for Deletion
Prerequisites
The customer exists in the active area and is not part of an ongoing change request.
Context
You can use the Change Request service to create a change request that, once approved, will ag the customer for archiving in the next archiving run.
Procedure
1. Select a customer in the search result list.
In the Search Customer service, select a customer in the result list and choose Mark for Deletion.
2. Select a change request type.
In the Available Change Request Types dialog box, select an change request type.
3. Enter change request data.
4. Submit change request.
To trigger the deletion work ow, click the Submit button.
Results
The system creates a change request for deleting the chosen customer. The change request triggers the appropriate work ow and, once approved, results in the customer being
agged for archiving in the next archiving run.
Blocking/Unblocking a Customer
Prerequisites
The customer exists in the active area and is not part of an ongoing change request.
Context
You can use the Change Request service to create a change request that, once approved, will ag the customer as blocked or respectively unblock it.
Procedure
1. Select a customer in the search result list.
In the Search Customer service, select a customer in the result list and choose Block or Unblock.
2. Select a change request type
In the Available Change Request Types dialog box, select an change request type.
3. Enter change request data
4. Submit change request
To trigger the blocking or unblocking work ow, click the Submit button.
Results
The system creates a change request for blocking or unblocking the chosen customer. The change request triggers the appropriate work ow and, once approved, results in the
customer being blocked or respectively unblocked.
5/19/2023
Replicating a Customer
Prerequisites
The customer to be replicated exists in the active area and is not locked by another change request.
You have maintained a change request type for customer change and have set up your work ow for this change request type.
You have set up appropriate communication channels to your client systems using Services or IDocs.
Context
You can use the Replication by Object Selection service to replicate approved customers from the hub system to client systems.
Procedure
1. Select a customer in the search result list
In the Search Customer service, select a customer in the result list and choose Replicate.
2. Select target system
In the Replication by Object Selection service, select the target systems and choose Replicate.
 Note
Select the Test Run Only check box, if you only want a test being performed without your customer really being replicated.
Results
The customer data is replicated to the selected client systems.
 Note
Information about the replication status of customers are available using the Replication Status button. The Replication Status Information service includes information about the
status, the target systems and communication channels.
Creating a Mass Change Request
Context
The Create Mass Change Request service enables you to create change requests for the mass update of existing customers. Updating multiple customers is a two-step process; you
rst create a single change request for multiple customers using this service, then you use the Mass Change service to enter the details for the changes you want to make.
 Note
Although you can enter the IDs for the customers you want to change in this screen, SAP recommends to use the Mass Change service to add the customers instead.
Procedure
1. Open the change request service
Choose Processing of Multiple Customers and click the Create Mass Change Request link to open the Create Mass Change Request service.
2. Create Change Request
Select a draft of a change request or create a new change request by choosing the Continue button.
3. Enter general data
Enter a description, due date, priority, and reason for your new change request. Choose Next to continue.
4. Enter a reason for the change
In the Explanation text box enter a reason for this mass change request. This eld is mandatory. You can also upload attachments if required. Choose Next to continue.
5. Specify customers for the change request
To add customers to the change request, click the Specify Objects button. You can then use the input help in the elds of the Customer column to add customers to the
change request.
 Note
We recommend that you use the Mass Change service to add customers later rather than at this point.
Choose the Enter button followed by Next to continue.
6. Review
Check and review your new change request. Choose Submit to create your new change request.
Results
5/19/2023
A new change request has been created for the mass change of customers. Choose Close to return to the Customer Governance work center.
Mass Change
Prerequisites
You have created a mass change request using the Create Change Request service.
Context
You can use the Mass Change service to simultaneously change the attribute values for selected customers. You can change one or more attributes for the selected customers, but
each attribute must have the same new value.
Procedure
1. Open the Mass Change screen
Select the Mass Change link from the Customer Governance work center.
2. Select customers to include
Use the Selections list to choose the customers you want to include in your change request. Choose Next to continue.
 Note
While you can select customers in the Create Change Request service, SAP recommends that you use this screen instead.
3. Re ne your selection
Use the Scope of Selection table to review your chosen customers and remove any customers you do not want to include in your change request. Choose Next to continue.
 Note
If a customer you have selected already exists in the staging area, this change request overwrites it. A warning about this overwrite appears when you attempt to execute
the changes.
4. De ne values
Choose the attributes you want to change and the value you want to set them to. To do so, enter the new value in the Replace With column of the attribute you want to
change. This value is set for the attribute in each customer you selected. Choose Next to continue.
 Note
Only attributes available for mass change are visible on this screen.
5. Check and execute
Review your changes and choose Execute Changes to submit your change request.
Results
Once the change is submitted, the following results are possible:
If all customers are already contained in existing change requests where you are the owner, those change requests are modi ed and a warning message appears. If you are
not the owner, an error message appears.
If none of the customers to be changed are contained in change requests, the systems asks you for a mass change request where you are the processor. You can create a
mass change request with the Create Change Request service. The customers are added to the new mass change request.
If some customers appear in an existing change request and some do not, the system asks you for a mass change request. When you enter a mass change request, all
customers that were not in a change request are added to the mass change request and those that were part of an existing change request are modi ed using their own
change requests.
Once customers are assigned to a mass change request, the change request is usually sent to a Master Data Steward who reviews the changes. During this time the customers are
stored in the master data governance staging area. Once the Master Data Steward has approved the change request and technical validation has taken place the changed
customers are written to the active area.
Address Screening
Use
If your system is set up for address screening, you can use the optional feature address screening. It enables you to perform the screening of a person or organization by SAP
Business Integrity Screening within a speci ed change request step.
Prerequisites
You are authorized for the address screening.
The address screening is con gured according to the document Set up Address Screening.
5/19/2023
Features
One certain change request step is speci ed for the address screening. When a change request is approved, rejected, or checked within the speci ed change request step the
address screening starts automatically. If a potential hit exists, a dialog box shows you details comparing your current record with data of the hit. You now can decide whether to
con rm the hit or not.
In the case of a hit the standard system con guration allows the user to decide whether to continue the processing or not.
 Note
In the speci ed change request step, the Check button enables you to request the address screening manually at any time.
More Information
For more information on the address screening feature, see MDG, Business Partner: Address Screening
For more information on SAP Business Integrity Screening, see http://help.sap.com/bis .
Request Customer
Use
With this app you can request a new customer for an organization or person. This app is easily accessible for a general user with limited knowledge of master data governance.
Key Features
Lean requestor form for a user new to MDG
Separate forms to create a customer as an organization and a person
Automatically generated list of potential duplicates
You can customize the Duplicates button to display the + sign when a certain number of duplicates are found (for example, 20+).
Track My Requests UI to track the request status
Option to upload attachments containing request details
When you upload an attachment, the Reason for Request eld is automatically lled with the text Check attached documents.
Address format that automatically changes to EU or US when you enter the country or region
Supported Device Types

Desktop
Tablet
Smartphone
Relevant Business Catalog

SAP_MDG_BC_REQUESTOR_T
Decentralized Master Data Governance for Customer

Prerequisites
The client system is con gured as described in the document Con guring Master Data Governance for Customer on Client System.
Context
The decentralized Master Data Governance for Customer MDG-C enables you, while being logged on to the client system, to search and compare customer data on the hub system,
before creating or changing a customer on the client system. After the search you can copy the customer from the hub system to the client system. This data afterwards can be
edited in the client system. The data will then be replicated to the hub system using SOA services, where the business function Master Data Governance tor Customer offers
functions for data enrichment and data validation as well as data replication to all the other adapted client systems.
An extension of the existing search in transaction XD03 is offered, enabling you to search from the client system within the hub system. Therefore the Customers in MDG hub by
Address Attributes tab has been added to the Customer Display input help. The search on the hub system offers you a hit list sorted by similarity and indicating whether the data is
located on the hub system exclusively or on the client system as well.
Procedure
1. Search on the hub system
5/19/2023
Choose transaction XD03 in the client system. On the Customer Display: Initial Screen dialog box use the input help of the Customer eld. On the Customer Account Number
dialog box then select the Customers in MDG hub by Address Attributes tab.
Enter your search criteria and choose Start Search.
A hit list is displayed.
2. Copy to the client system
Search for customers on the hub system as described above. Mark a customer in the hit list and choose Copy Customer.
Results
If you have chosen Copy Customer the selected customer is copied from the hub system to the client system.
FI Contract Account
Master Data Governance for FI Contract Account enables you to monitor and control the creation and editing of contract account master data.
Change Request Processing

The following documents about change request processing outline the functions and processes used for creating and processing change requests. During a typical work ow, users
might rst search for an FI contract account, then generate a change request to create or change a contract account, depending on the requirements.
Users do not actually create, change, or mark contract accounts for deletion; instead, they create change requests that are sent for approval by a Master Data Specialist. Once this
expert approves the change request, the new or updated contract account data is written to the active area. During the change request process, the new or changed master data is
stored in the master data governance staging area. For more information, see the role description for Master Data Governance for FI Contract Account: Specialist under Roles for
SAP MDG, Central Governance in the Application Help for SAP Master Data Governance on https://help.sap.com/viewer/p/SAP_MASTER_DATA_GOVERNANCE.
The change request worklist provides users - either normal users or reviewers - with a list of work items to be considered. Users typically open a work item in the Change Requests
screen from which they can approve the change request, reject the change request, validate the change request data, view the validation log, forward the change request, or perform
a variety of checks.
The steps in a typical work ow are outlined below:
1. Users create a change request and the data in the change request is written to the staging area.
2. The change request is sent to a Master Data Specialist for review and approval.
3. The Master Data Specialist reviews the change request and either approves it or rejects it.
If the Master Data Steward rejects the change request, it is sent back to the requester, who can either discard the change request or modify and resubmit it.
If the Master Data Steward approves the change request, the information in the change request is written to the active area and the process is complete.
 Note
Any work ow step offers the possibility to perform checks either by choosing a Check button, by choosing Next to continue or by choosing Enter. The extent of checks being
performed at each work ow step, for example validity check or required elds check are speci ed in the Customizing.
If a validity check or required elds check reports an error, the change request cannot be activated.
Search FI Contract Account
Use
The Search Contract Account service enables you to search for and display contract accounts based on speci ed criteria. You can use a range of attributes to search including the
contract account name or category, and attributes of the business partners assigned to a contract account. From the search results list you can choose to display, edit, or create a
contract account.
Activities
The search offers the following possibilities:
Search Method
A variety of search methods offer sets of prede ned search criteria.
Additional Search Lines
You can extend or reduce the number of search criteria if required using the Insert New Row and Delete Row buttons.
Save and Load Searches
You can save a set of search parameters and load them for use at a later time.
Maximum Number of Results
You can use the Maximum Number of Results eld to limit the number of results displayed.
5/19/2023
 Note
The following points should be kept in mind when formatting your search:
If you search for two or more different attributes then the search lters its results based on an AND logic.
When searching a single attribute for more than one parameter the search lters its results based on an OR logic.
Creating an FI Contract Account

Prerequisites
You have maintained a change request type for contract account creation and have set up your work ow for this change request type.
Context
You can use the Create Request service to create a change request for contract account creation. This change request goes through the predetermined work ow process and when
complete results in the creation of a new contract account in the active area.
Procedure
1. Create change request for new contract account
In the Search Contract Account section, choose New .
In the Change Request section, enter a description for your change request in the Description eld. You can enter details for your change request such as priority, due date,
and reason. You can also add comments on the Notes tab and attach relevant les using the Attachments tab.
3. Enter details for new contract account
In the Contract Account - Account Header section, enter the header data for your contract account. You can enter details such as the name, and specify the contract account
number and category.
 Note
You can check your entries choosing the Check button.
4. Add business partner to contract account
In the Business Partners section, choose New. In the Business Partner ID eld, enter a business partner, choose Edit to make changes and enter new details if required, and
choose Done.
 Note
When there is more than one business partner, one of them must be selected as the Account Holder.
5. Enter Tax Exemption
If applicable, in the Tax Exemption section, choose New to enter one or more tax exemptions. Select a Tax Code, a Condition Type, and enter a Valid From date, and enter
more details in the remaining columns if required.
6. Submit your change request
When you have entered your data, choose the Submit button to trigger the work ow. The system performs a check before submitting the change request.
 Note
To save the change request for use at a later time, choose Save.
Results
The new change request for contract account creation is created and sent for processing according to the work ow you have assigned to the create contract account process.
Usually, this means that it is submitted to a master data specialist who reviews the changes. During this time, the new contract account is stored in the master data governance
staging area and does not appear in the active area. Once the master data steward has approved the change request and technical validation has taken place, the new contract
account is written to the active area.
Changing an FI Contract Account
Prerequisites
The contract account to be changed exists in the active area and is not locked by another change request.
You have maintained a change request type for contract account change and have set up your work ow for this change request type.
Context
5/19/2023
You can use the Change Request service to create a change request for changing a single contract account. This change request goes through the predetermined work ow process
and, when complete, results in the change of the contract account in the active area. Creating the change request copies the contract account to the staging area. A contract
account can only be assigned to one active change request at a time, so no new change requests can be created for a contract account that is already in the staging area.
 Caution
If you use the back-end system to make changes to a eld in the BP data model while the contract account is undergoing the change request process, upon approval of the change
request, all your changes will be overwritten (and not just the elds affected by the change request).
The system will, however, issue a warning during validation that this data has changed, and you can then view the changes made in the back-end system and incorporate them in
your change request. You can then re-submit the change request for validation.
Procedure
1. Select a contract account in the Search FI Contract Account result list
In the Search Contract Account service, select and open a contract account from the result list.
2. Change relevant section to edit mode
To switch the section where you want to make changes to edit mode, choose the Edit button.
In the Change Request section, enter a description for your change request in the Description eld. For further details see the corresponding section in Creating an FI Contract
Account.
4. Enter changes
Enter the changes you want to make to the contract account. For further details see the corresponding section in Creating an FI Contract Account.
5. Submit changes
Click the Submit button to submit your change request.
Results
The new change request for changing the contract account is created and sent for processing according to the work ow you have assigned to the Change Contract Account process.
Usually, this means that it is submitted to a master data specialist who reviews the changes. During this time, the changed contract account is stored in the staging area and does
not appear in the active area. Once the change request has been approved and technical validation has taken place, the changed contract account data replaces the existing data in
the active area. The changed contract account is no longer available in the staging area and can be included in new change requests.
Process Analytics for MDG, Central Governance

MDG, Central Governance offer out-of-the-box process analytics applications to enable master data specialists to gain real-time insight into change request processes. Specialists
can also analyze the performance of completed processes for the purposes of continuous improvement. Process analytics provides a high-level overview as well as a detailed view
with information such as work items and individual change requests.
Master Data Process Overview for Business Partners
Use
The Master Data Process Overview for Business Partner app shows overview information on both completed and open tasks. You can use information from change request processes,
consolidation processes, and mass processes as trigger to work on tasks requiring your attention.
To use the lter bar options in order to restrict your results shown on the cards from this app, choose Adapt Filters.
The following lter bar options are valid for all cards from this app:
Created On:
You can lter for objects created during a speci c period of time.
Created By:
You can lter for objects created by selected users.
The following lter bar options are valid for change request-related cards from this app:
Change Request Type
You can lter for objects assigned to selected change request types.
Change Request Status
You can lter for objects assigned to selected change request statuses.
Business Object Type
You can lter for objects assigned to selected business object types.
The following lter bar options are valid for change process-related cards from this app:
5/19/2023
Process Goal
You can lter for objects assigned to selected process goals.
Process Template
You can lter for objects assigned to selected process templates.
Process Status
You can lter for objects assigned to selected process statuses.
 Note
You can create your own views of this app, save these views as tiles with indivual descriptions for your personal or for public use. You can also send these views as email to other
users.
For example, you can use the lter bar option Business Object Type, select Supplier or Customer to restrict your results and save this as a variant as your own view.
From every card of the Master Data Process Overview for Business Partner app, you can navigate to the Change Request Analysis for Business Partners app to display the
corresponding change requests or to the Change Process Analysis for Business Partners app to display the corresponding change processes.
Key Features
Total Change Requests
The information from this card can provide insights into the workload coming from change requests created and might allow you to predict future trends based on this set of
data.
Open Change Requests
This card displays the number of open change requests grouped by change request status or by change request type.
The information from this card can provide insights into the current workload and can help to optimize the processing time of open change requests.
Overdue Change Requests
This card displays the number of overdue change requests that exceed a de ned due date. The overdue change requests are sorted by days overdue.
The information from this card can provide insights into ways to reduce the number of delayed change requests and with this might allow you to accelerate the remaining
processing time.
Rejected Change Requests
This card displays the number of rejected change requests grouped by reasons for rejection.
The information from this card provides an overview of the volume of rejections, of the reasons for rejections, such as the most used reasons. The information from this card
can be used to analyze rejected change requests and to reduce the number of rejected change requests to improve the change request process.
Change Requests with My Participation
This card displays the number of change requests with your participation grouped by change requests created by you and change requests with your work ow involvement.
The information from this card provides an overview of those change requests where you are or where you have been involved in the change request processing to support the
analysis of all change requests with your involvement.
Longest Running Open Change Requests
This card displays the longest running open change requests sorted from the oldest change request to be displayed rst to the newest change request to be displayed last.
The information from this card can provide insights to analyze and nalize the processing of these change requests with the goal to improve the overall change request
processing and to reduce the number of long-running change requests.
Change Requests Older than 48 Hours
This card displays the number of open change requests older than 48 hours grouped by logical action.
The information from this card might allow you to trigger the processing of delayed change requests and to analyze the delay of the process.
Processing Duration of Finalized Change Requests
This card displays the number of days of the average processing duration of nalized change requests grouped by change request type and change request priority.
The information from this card can provide insights on how to optimize the average processing time comparing change requests of selected change request types or change
request priorities.
Open Consolidation and Mass Processes
This card displays the number of open change processes grouped by status.
The information from this card can provide insights into the current workload and can help to optimize the processing time of the open change processes.
Duration of Consolidation and Mass Processes
This card displays the number of days of the average processing duration of change processes sorted by process goals and grouped by open or nished change processes.
The information from this card can provide insights on how to optimize the average processing time comparing change processes of selected open change processes and
nished change processes.
Finished Consolidation and Mass Processes
5/19/2023
This card displays the number of nished change processes by date.
The information from this card can provide insights into the workload coming from change processes and might allow you to predict future trends based on this set of data.
Number of Processed Business Partners
This card displays the number of processed business partners grouped by process goal or by process template.
The information from this card can provide insights into the current workload and can help to optimize the processing time of open change processes.
Consolidation Validation Results
This card displays the number of validation errors by date.
You can navigate from this card to the Change Process Analysis for Business Partner app to drill down to a selected validation error for analysis.
Changed Business Partner Attributes
This card displays the number of business partner attributes that have been changed grouped by business partner table.
The information from this card can provide insights into the size and workload of nished change processes and can help to optimize the overall processing of change
processes.
Open Work Items by Responsibility and Status
This card displays the number of open work items for change requests grouped by responsibility or work item status. The information from this card provides insights into the
current workload and how many work items are being processed or still waiting in the queue.
Open Work Items by Change Request Type
This card displays the number of open work items for change requests grouped by change request type and steps. This card displays the number of open work items for change
requests grouped by change request type and processing hours. For more details of processing hours, refer to De ne Time Frames for Analytics Attributes.
Completed Work Items
This card displays the number of open work items for change requests grouped by change request action, by change request step, or by processing hours. The information
from this card provides insights on volume of rejections and how long ago the action took place, to decide if further analysis and improvement on change request processing is
needed.
Total Processing Days of Completed Work Items
This card displays the total processing days for change requests work items in the past months. The information from this card shows history workload trends for change
request processing, so can decide if more resources are needed for change request processing at certain times.
Average Processing Hours of Completed Work Items
This card displays the average processing hours of work items for change requests grouped by change request step, by month, or by year. The information from this card helps
you understand the processing efficiency on each change request step and trends of average processing times in previous months and years, so you can decide if you need
further analysis and improvement of your change request processing.
needed.

Desktop
Tablet
Relevant Business Catalogs

ERP Customer Governance (SAP_MDG_BC_ERPCUS_DATA)
ERP Vendor Governance (SAP_MDG_BC_ERPVEN_DATA)
5/19/2023
Supplier Governance (SAP_MDG_BC_SUPPLIER_DATA)
Business Partner Governance (SAP_MDG_BC_BUPA_DATA)
Customer Governance (SAP_MDG_BC_CUSTOMER_DATA)
CMD - Consolidation and Mass Processing for Business Partner Data (SAP_CMD_BC_BP_MONPROCS)
Change Request Analysis for Business Partners
Use
With this app you can carry out root cause analysis monitoring process quality issues related to change requests for business partners using various drill-down dimensions.
You can use the Compact Filter to restrict your change request results using the following options:
Created On:
Created By:
Priority
You can lter for objects assigned to selected change request priorities.
Status
Type
If you choose Adapt Filters, you can select additional lter values such as the Business Object Type.
 Note
You can create your own views of this app, save these views as tiles with indivual descriptions for your personal or for public use. You can also send these views as email to other
users.
For example, you can use the lter bar option Business Object Type, select Supplier or Customer to restrict your results and save this as a variant as your own view.
Key Features
This analytical list page provides the following features:
Analyze change request processes using different drill-downs on dimensions, such as, status, priority, and business object type.
Keep track of the average change request processing time.
Navigate to the selected change request.

Desktop
Tablet

ERP Customer Governance (SAP_MDG_BC_ERPCUS_DATA)
ERP Vendor Governance (SAP_MDG_BC_ERPVEN_DATA)
Supplier Governance (SAP_MDG_BC_SUPPLIER_DATA)
Business Partner Governance (SAP_MDG_BC_BUPA_DATA)
Customer Governance (SAP_MDG_BC_CUSTOMER_DATA)
Master Data Process Overview for Products
Use
The Master Data Process Overview for Product app shows overview information on both completed and open tasks. You can use information from change request processes,
consolidation processes, and mass processes as trigger to work on tasks requiring your attention.
5/19/2023
The following lter bar options are valid for all cards from this app:
Created On:
Created By:
The following lter bar options are valid for change request-related cards from this app:
Change Request Type
Change Request Status
The following lter bar options are valid for change process-related cards from this app:
Process Goal
You can lter for objects assigned to selected process goals.
Process Template
You can lter for objects assigned to selected process templates.
Process Status
You can lter for objects assigned to selected process statuses.
From every card of the Master Data Process Overview for Product app, you can navigate to the Change Request Analysis for Products app to display the corresponding change
requests or to the Change Request Analysis for Products app to display the corresponding change processes.
Key Features
This card displays the number of total change requests grouped by request date, change request status, and change request type.
The information from this card can provide insights into the workload coming from change requests created and might allow you to predict future trends based on this set of
data.
This card displays the number of open change requests grouped by change request status or by change request type.
The information from this card can provide insights into the current workload and can help to optimize the processing time of open change requests.
processing time.
5/19/2023
request priorities.
Open Consolidation and Mass Processes
This card displays the number of open change processes grouped by status.
The information from this card can provide insights into the current workload and can help to optimize the processing time of the open change processes.
Duration of Consolidation and Mass Processes
This card displays the number of days of the average processing duration of change processes sorted by process goals and grouped by open or nished change processes.
The information from this card can provide insights on how to optimize the average processing time comparing change processes of selected open change processes and
nished change processes.
Finished Consolidation and Mass Processes
This card displays the number of nished change processes by date.
The information from this card can provide insights into the workload coming from change processes and might allow you to predict future trends based on this set of data.
Number of Processed Products
This card displays the number of processed products grouped by process goal or by process template.
The information from this card can provide insights into the current workload and can help to optimize the processing time of open change processes.
Consolidation Validation Results
This card displays the number of validation errors by date.
You can navigate from this card to the Change Process Analysis for Products app to drill down to a selected validation error for analysis.
Changed Product Attributes
This card displays the number of product attributes that have been changed grouped by product table.
The information from this card can provide insights into the size and workload of nished change processes and can help to optimize the overall processing of change
processes.
needed.

Desktop
Tablet

Material Governance (SAP_MDG_BC_MATERIAL_DATA)
CMD - Consolidation and Mass Processing for Product Data (SAP_CMD_BC_PR_MONPROCS)
Change Request Analysis for Products
Use
With this app you can carry out root cause analysis monitoring process quality issues related to change requests for products using various drill-down dimensions.
5/19/2023
Created On:
Created By:
Priority
Status
Type
If you choose Adapt Filters, you can select additional lter values.
Key Features

Desktop
Tablet

Material Governance (SAP_MDG_BCG_MATERIAL_DATA)
Central Governance Process Overview for Financial Data
Use
The Central Governance Process Overview for Financial Data app shows overview information on both completed and open tasks. You can use information from change request
processes as trigger to work on tasks that require your attention.
 Note
If you want to use the precon gured application variants for Controlling and Accounting, you need to implement 2678488 .
The following lter bar options are available for this app:
Created On:
Created By:
Business Activity:
You can lter for objects assigned to selected business activities and business object types.
Edition
You can lter for objects assigned to selected editions and validity periods.
Status
Type
From every change request-related card of the Change Request Overview for Financial Data app, you can navigate to the Change Request Analysis for Financial Data app to display
the corresponding change requests and to drill down on a more detailed level.
5/19/2023
Key Features
This card displays the number of total change requests grouped by request date, change request status, and change request type.
The information from this card can provide insights into the workload of change requests created and might allow you to predict future trends based on this set of data.
This card displays the number of open change requests grouped by edition, change request status, and change request type.
The information from this card can provide insights into the current workload and can help to optimize the processing time of the open change requests.
processing time.
request priorities.
Status of Editions
This card displays the number of editions from the data model 0G grouped by edition status. From this card, you can navigate to the MDG: Editions application. The MDG:
Editions application shows all available editions.
needed.

Desktop
5/19/2023
Tablet

Fin Accounting Governance (SAP_MDG_BC_FINACC_DATA)
Fin Controlling Governance (SAP_MDG_BC_FINCTR_DATA)
Change Request Analysis for Financial Data
Use
With this app you can carry out root cause analysis monitoring process quality issues related to change requests for nancial data using various drill-down dimensions.
Created On:
Created By:
Edition
You can lter for objects assigned to selected editions and validity periods.
Status
Priority
Type
Business Activity:
You can lter for objects assigned to selected business activities and business object types.
If you choose Adapt Filters, you can select additional lter values.
Key Features

Desktop
Tablet

Fin Accounting Governance (SAP_MDG_BC_FINACC_DATA)
Fin Controlling Governance (SAP_MDG_BC_FINCTR_DATA)
App Extensibility: Process Analytics for MDG, Central Governance Apps
Use
You cannot extend Process Analytics for MDG, Central Governance apps.
More Information
For a general description of the extensibility options and procedures of SAP Fiori apps, see Extend SAP Fiori Apps.
Monitor Open Work Items from Change Requests for Business Partner
5/19/2023
With this app, you can gain real-time insights into your company’s change request processes. The app enables you to display reports showing the status of work items that are
currently in the change request process. You can lter information and drill down for further detail. You can also navigate directly to the change requests involved to identify and x
process gaps, bottlenecks, and errors. Key users can con gure report timeframes to your organizational requirements.
Key Features
You can use this app to:
Get an overview of the current situation and trend for your master data processes.
Analyze and compare process efficiency, both between organizational structures and against KPIs.
Increase workload transparency between organizational units.
In addition, the app supports the following technical features and options:
This app uses the C_MDGOVOPENWRKFLWBPQRY CDS view.

Desktop
Tablet
Smartphone
Monitor Open Work Items from Change Requests for Products

Key Features
This app uses the C_MDGOVOPENWRKFLWPRODQRY CDS view.

Desktop
Tablet
Smartphone
Monitor Open Work Items from Change Requests for Financial Master Data
Key Features
This app uses the C_MDGOVOPENWRKFLWFINQRY CDS view.

Desktop
5/19/2023
Tablet
Smartphone
Analyze Completed Work Items from Change Requests for Business Partner
With this app, you can gain real-time insights into your company’s change request processes. The app enables you to display reports showing the status of work items that have
completed the change request process. You can lter information and drill down for further detail. You can also navigate directly to the change requests involved to identify process
gaps, bottlenecks, and errors. Key users can con gure report timeframes to your organizational requirements.
Key Features
This app uses the C_MDGOVCLSDWRKFLWBPQRY CDS view.

Desktop
Tablet
Smartphone
Analyze Completed Work Items from Change Requests for Products

Key Features
This app uses the C_MDGOVCLSDWRKFLWPRODQRY CDS view.

Desktop
Tablet
Smartphone
Analyze Completed Work Items from Change Requests for Financial Master Data
Key Features
5/19/2023
This app uses the C_MDGOVCLSDWRKFLWFINQRY CDS view.

Desktop
Tablet
Smartphone
Working with MDG, Data Quality Management

The following documents provide information about the various apps that are available in SAP Master Data Governance to check and improve the quality of your master data.
Managing Data Quality
Use
With MDG, Data Quality Management, you can ensure the quality of your product and business partner master data. You can de ne derivation scenarios to deduce master data
based on derivation rules. You can de ne validation rules and data quality key performance indicators (KPIs). You can evaluate the quality of your master data according to these
rules and monitor the current state of the data quality as well as its trend.
By analyzing the evaluation results you can identify areas of data with errors, potential reasons for data with errors, and initiate the correction. You can also use machine learning to
mine your master data for new rule suggestions that you can assess and add to your validation rules.
Process
De ne Derivation Scenarios
Use the De ne Derivation Scenarios app to de ne derivation scenarios to deduce master data based on rules and a de ned scope to ensure data quality. A derivation scenario
consists of one or more derivation rules.
You can export and import derivation scenarios using the Export Derivation Scenarios and Import Derivation Scenarios apps.
De ne Validation Rules
Use the Validation Rules app to de ne validation rules and to implement these rules in BRFplus for evaluation by the system.
You can export and import validation rules using the Export Validation Rules and Import Validation Rules apps.
Perform Rule Mining
Use the Manage Rule Mining and Process Rules from Rule Mining apps to discover new validation rules based on your selected criteria. The process utilizes machine learning
to propose potential rules for data quality evaluation.
De ne Data Quality KPIs for Data Quality Scores
De ne data quality dimensions and dimension categories with assigned validation rules, and specify how scores are calculated to describe KPIs for data quality monitoring.
Evaluate Data Quality
Create and run an evaluation of your master data according to the validation rules with the Evaluate Data Quality apps. You can also schedule evaluations, for example in
weekly intervals.
Monitor Data Quality
Display up-to-date status information about current data quality and drill down into the details for further analysis with the Data Quality Evaluation Overview apps. If you have
con gured your own data quality dimensions and scores you can also display the current score, its trend, and the comparison to the de ned thresholds.
Analyze and Correct Data
Use the Evaluation Results apps to analyze data quality evaluation results for products and business partners with the goal to nd incorrect data, to investigate potential
reasons for incorrect data, and to start the correction.
Further Information
Managing Derivation Scenarios
Managing Validation Rules
Rule Mining Process Overview
Data Quality Evaluation Process Overview
Managing Derivation Scenarios
5/19/2023
You can use derivation scenarios to deduce master data based on rules and a de ned scope. Derivation scenarios are used during master data processes to ensure data quality, for
example in mass processing and consolidation as well as in change requests.
With the De ne Derivation Scenarios app, you can create and edit derivation scenarios. A derivation scenario consists of one or more derivation rules, which control how target
values are determined from source values. The process of de ning derivation scenarios and rules is shared collaboratively between different roles.
If you want to reuse your derivation scenarios in another system, you can use the Export Derivation Scenarios and Import Derivation Scenarios apps. The derivation scenarios and
rules are validated before you can carry out the export or import steps.
De ne Derivation Scenarios
App ID: F5522 (for products) and F5954 (for business partners)
With this app, you can create and edit derivation scenarios for your product and business partner data. You use derivation scenarios to deduce master data based on rules and a
de ned scope to ensure data quality. A derivation scenario consists of one or more derivation rules.
Key Features
You can use this app to do the following:
De ne and edit derivation scenarios, including their details
De ne and edit one or more derivation rules for each derivation scenario, including their details
Enable rules for execution in MDG processes (see Using Derivation Scenarios in MDG Processes)
Navigate to the BRFplus Workbench to de ne scope expressions and decision tables
The video below provides an overview of derivation scenarios and shows how you can use derivation rules as part of a business process.
Open this video in a new window

Desktop
Tablet
Smartphone
De ning a Derivation Scenario

This process describes how you de ne derivation scenarios to deduce master data based on rules and a de ned scope to ensure data quality.
Process
1. The scenario owner creates a new scenario and enters an ID and a name. In the General Information section, the scenario owner enters the base table as well as other
information as required.
2. The scenario owner creates one or several derivation rules and enters an ID and a name. For rules for elds, he or she selects a result table. For rules for tables, he or she
selects a rule base table and then a result table. The scenario owner adds condition elds and result elds and saves the rule by choosing Apply.
3. The scenario owner chooses Create to create the scenario.
4. The scenario owner sends the rule for implementation by setting the status To Be Implemented in display mode.
5. The scenario owner sends the scenario for implementation by choosing Send for Implementation in display mode.
6. The implementation expert prepares the scope expression for the scenario, implements the scope expression in BRFplus, and then sends the scenario for review by choosing
Send for Review in display mode.
5/19/2023
7. The implementation expert creates a scope expression and a decision table for each rule. If necessary, the implementation expert implements the scope expression in BRFplus
and adds additional conditions to the decision table. The implementation expert then sends the rule for review by selecting the status To Be Reviewed.
8. The scenario owner checks the decision table and sets the rule to status Ready for Input.
9. The data owner maintains the values in the decision table and sends the rule for approval by setting the status To Be Approved.
10. The rule owner navigates to and checks the decision table and approves the rule by setting the status Approved.
11. The scenario owner checks the sequence of the rules (if there are several) and adjusts it if necessary.
12. The scenario owner approves the scenario.
13. The rule owner can now activate the execution of the rule using the switch in the Execution column.
Result
In consolidation and mass processing, all active derivation scenarios (scenarios with statuses other than Disabled) containing rules that have execution status Enabled are executed
in all processes that have a Derivation step. For more information about the Derivation step, see Derivation for consolidation processes and Derivation for mass processes.
In change requests, all active derivation scenarios (scenarios with statuses other than Disabled) containing rules that have execution status Enabled are executed in the rule-based
work ow of change requests if the relevant setup has been done. For more information, see the following chapters:
De nition of Derivations Using Derivation Scenarios for products
De nition of Derivations Using Derivation Scenarios for business partners
De nition of Derivations Using Derivation Scenarios for suppliers
De nition of Derivations Using Derivation Scenarios for customers
Related Information
Derivation Scenario Statuses
Derivation Rule Statuses
Example: De ning a Derivation Scenario with Derivation Rules
Use Case: Derive Plant Attributes and Create Storage Locations

You want to create a derivation scenario for semi nished products.
You want the derivation scenario to deduce further plant attributes, for example, the MRP type, based on the material group and the laboratory/design office. For this purpose, you
create a rule for elds.
You also want to derive storage locations for the assigned plants. For this purpose, you create a rule for tables.
Process
1. You create a derivation scenario.
a. You create a new scenario and enter the scenario ID (for example, DERIVE_PLANT_ATTR) and a scenario name (for example, Derive Plant Attributes).
b. You enter the Basic Data (MARA) table as the scenario base table.
c. You enter a scope description, for example Semifinished products.
d. You choose Create to create the scenario.
e. You choose Send for Implementation.
f. You choose Prepare Scope Expression and con rm the popup window that appears.
g. The scenario status changes to Generation Running.
h. You choose Refresh. When the status has changed to To Be Implemented, you continue with the following steps.
i. You choose the link below Scope Expression to implement the scope expression in BRFplus.
j. In the BRFplus Workbench, you choose Edit Edit Operand Use Direct Value Range From Select Context Parameter .
k. In the Context Query popup under Search Criteria, you leave the rst row (Data Object Type is equal to Any) as it is. In the second row, you search for the name (Name
is equal to) MTART and select Material Type in the result list.
l. On the BRFplus Workbench screen in the Detail section, you enter HALB in the eld next to If MARA Key...-Material Type is equal to.
m. You choose Save and navigate back to the De ne Derivation Scenarios app.
n. You choose Send for Review.
o. You choose Approve. The scope status changes to Active and the derivation scenario status to Approved.
2. You create a rule for elds to derive plant attributes.
a. You enter a rule ID (for example, MAINT_PLANT_ATTR) and a rule name (for example, Maintain Plant Attributes).
b. You enter Plant Data (MARC) as the result table.
c. You add the following condition elds:
Plant (MARC-WERKS)
Material Group (MARA-MATKL)
5/19/2023
Laboratory/design office (MARA-LABOR)
d. You add the following result elds:
MRP Type (MARC-DISMM)
MRP Controller (MARC-DISPO)
Lot Sizing Procedure within Materials Planning (MARC-DISLS)
Material: MRP pro le (MARC-DISPR)
3. You create a rule for tables to create storage locations.
a. You enter a rule ID (for example, CREATE_STOR_LOC) and a rule name (for example, Create Storage Location).
b. You enter Storage Location (MARD) as the result table and Plant Data (MARC) as the rule base table.
c. You add the following condition eld: Plant (MARC-WERKS)
d. In the Result Fields table, the mandatory key elds Storage Location (LGORT) and Plant (WERKS) are provided automatically.
e. You add the following result eld: Picking area for lean WM (MARD-LWMKB)
4. In display mode, you change the rules' status to To Be Implemented.
5. You maintain the values in the rules' decision table. This is described in the following example for the rule for tables that was created in step 3.
a. You select the rule for tables, which has the status To Be Implemented. In the Implementation section, you choose Create Decision Table.
b. You choose Refresh. When the rule status has changed to To Be Implemented, you can see the decision table links for the condition and the result in the
Implementation section.
c. You choose the link for the condition decision table, which navigates you to the Decision Table screen in the BRFplus Workbench.
d. You choose Edit and then the plus sign (+, Insert New Row) below Table Contents to insert a new row.
e. In the dropdown list in the Plant column, you select Direct Value Input.
f. In the dropdown list below Plant, you select is between, enter 1 and 1000 in the elds that appear, and choose OK.
g. In the dropdown list in the Condition Group column, you select Direct Value Input and enter a name of your choice for the condition group, for example Plant Group.
This condition group will be used as a condition in the result decision table (step m). You choose OK.
h. You can add more rows to the decision table, if required.
i. You choose Save and navigate back to the De ne Derivation Scenarios app.
j. You choose the link for the result decision table, which navigates you to the Decision Table screen in the BRFplus Workbench.
k. You choose Edit and then the plus sign (+, Insert New Row) below Table Contents to insert a new row.
l. In the dropdown list in the Condition Decision Table column, you select Direct Value Input.
m. You enter the name of the condition group entered in step g (Plant Group) in the eld next to Condition Decision Table … is equal to and choose OK.
n. In the dropdown list in the Picking area column, you select Direct Value Input, you select a picking area from the value help, and choose OK.
o. In the dropdown list in the Location column, you select Direct Value Input, you select a storage location from the value help, and choose OK.
p. In the dropdown list in the Plant column, you select Select Context Parameter.
q. In the Context Query popup under Search Criteria, you leave the rst row (Element Type is equal to Text) and the second row (Name is equal to *) as they are. In the
third row, you search for the Text (Text is equal to) Plant and select the Plant entry below MARC Key and Attribute Structure in the result list.
This means that you use the value of the corresponding plant in the Plant Data (MARC) table.
r. You can add more rows to the decision table, if required.
s. You choose Save and navigate back to the De ne Derivation Scenarios app.
t. You continue with the status changes as described in De ning a Derivation Scenario (as of step 7, as applicable).
Result
The derivation is executed during master data processes in MDG. The derived plant attribute and storage location values are written to the result tables.
For more information, see Using Derivation Scenarios in MDG Processes.
Related Information
Using Derivation Scenarios in MDG Processes
Use
You want to use your derivation scenarios in change requests, in mass processing, and consolidation.
Prerequisites
You have set up at least one derivation scenario that has been approved once.
You have set up at least one derivation rule that has the execution status Enabled.
For consolidation and mass processes, you are using a process step template that contains the derivation step.
5/19/2023
For more information, see Import Prede ned Process Templates for Business Partner and Import Prede ned Process Templates for Product.
For more information about the Derivation step, see Derivation for consolidation processes and Derivation for mass processes.
For change requests, you have done the necessary setup as described in the following chapters:
De nition of Derivations Using Derivation Scenarios for products
De nition of Derivations Using Derivation Scenarios for business partners
De nition of Derivations Using Derivation Scenarios for suppliers
De nition of Derivations Using Derivation Scenarios for customers
Process
You use the mass processing and consolidation apps as described in Working with MDG, Consolidation and Mass Processing. Alternatively, you use change requests in central
governance as described in Working with MDG, Central Governance.
Result
In consolidation and mass processing, all active derivation scenarios (scenarios with statuses other than Disabled) containing rules that have execution status Enabled are executed
in all processes that have a Derivation step.
In change requests, all active derivation scenarios (scenarios with statuses other than Disabled) containing rules that have execution status Enabled are executed in the rule-based
work ow of change requests.
Related Information
How-To Set Up Central Governance to Use Data Quality Management Derivation Scenarios

The lifecycle of a derivation scenario is determined by various statuses, which can be set by different roles, as shown in the following graphic. The status transitions can be restricted
by authorizations.
 Note
Changing the status is only possible when the scenario is in display mode.
You can set the status Disabled from any status, and you can move the scenario from status Disabled to any other status except New.
You can delete a scenario if it has status New or Disabled.
 Note
When you select Prepare Scope Expression or Create Decision Table, the BRFplus artifacts are generated in the background. While the generation is ongoing, the scenario or rule
has the status Generation Running, and you cannot change the scenario and the rule. When the generation is complete, the status changes back to To Be Implemented.
The following table provides more information about the individual statuses in the typical process:
Status Description Rule Execution
5/19/2023
Status Description Rule Execution
New The scenario has been created recently. Rules might have been No
de ned, but are not ready for execution yet.
To Be Implemented The implementation expert needs to implement the scope Dependent on the rule's execution status
expressions. Please note, however, that the scope expressions
aren’t activated yet.
To Be Reviewed The scenario owner needs to check if the scenario ful lls its
purpose.
Approved The scenario has been veri ed with regard to business and
implementation aspects. The scope expressions are activated.
Disabled The rules are not executed. No

The lifecycle of a derivation rule is determined by various statuses, as shown in the following graphic. The de nitions of the individual roles determine who is responsible for setting
which status.
 Note
Changing the status is only possible when the scenario is in display mode.
You can set the status Disabled from any status, and you can move the rule from status Disabled to any other status except New.
You can delete a rule if it has status New or Disabled.
 Note
When you select Prepare Scope Expression or Create Decision Table, the BRFplus artifacts are generated in the background. While the generation is ongoing, the scenario or rule
has the status Generation Running, and you cannot change the scenario and the rule. When the generation is complete, the status changes back to To Be Implemented.
The following table provides more information about the individual statuses in the typical process:
Status Description
New The rule has been created recently.
To Be Implemented The implementation expert needs to prepare and implement the BRFplus artifacts.
To Be Reviewed The scenario owner needs to check if the rule ful lls its purpose.
Ready for Input The data owner maintains values in the decision table.
To Be Approved The rule owner needs to verify the rule with regard to business and implementation aspects.
5/19/2023
Status Description
Approved The rule has been veri ed with regard to business and implementation aspects. The scope
expression and the decision table are activated. You can switch on the execution.
Disabled The rule is not executed.
Derivation Scenario Roles

The following roles are involved in the lifecycle of a derivation scenario. You can adjust the responsibilities of the roles by changing the respective authorizations.
Role Tasks
Scenario owner Creates and changes the scenario and its status
Describes the scope of the scenario as required by the relevant business process
Creates derivation rules, in particular their set of condition elds and result elds, their
scope and the base table
Assigns the implementation expert, the rule owner, and the data owner
Implementation expert Prepares the implementation of the whole scenario by technically generating the BRFplus
artifacts
Implements the scope expressions and, if necessary, formulas and expressions to be

used in the decision table
Rule owner Approves the changes done by the data owner. As a consequence, the changes become
effective and the decision tables are activated.
Sets the rule's execution status
Can change the condition elds and result elds
Data owner Maintains the values in the decision tables
 Note
Only those users are displayed in the value help for the respective roles that have the appropriate authorization to ful ll the relevant tasks. For more information, see
Authorization Objects Used for Managing Data Quality.
Related Information
Roles for Business Partners
Roles for Products
Export Derivation Scenarios

App ID: F6405
With this app, you can download derivation scenarios and their rules, which you previously created in the De ne Derivation Scenarios app. This is useful if you want to reuse derivation
scenarios in another system. You start the export process in the De ne Derivation Scenarios app. The selected derivation scenarios and their rules are validated before you can start
the export and download the le. You can then use the Import Derivation Scenarios app to upload derivation scenarios to another system. You can use this app to export derivation
scenarios both for business partners and for products.
Key Features
Start the export process
Trigger the validation process for selected exports
Display the logs to check and correct any issues found during validation
Check the export status of each derivation scenario after the export is completed
Download the le with the derivation scenarios and derivations rules, which can then be imported using the Import Derivation Scenarios app
Search for and delete existing exports

Desktop
Tablet
Smartphone
5/19/2023
Import Derivation Scenarios

App ID: F6410
With this app, you can upload and import derivation scenarios and their rules, which you have previously downloaded using the Export Derivation Scenarios app. The uploaded
derivation scenarios and their rules are validated before you can start the import. You can use this app to import derivation scenarios both for business partners and for products.
Key Features
Upload the le with the derivation scenarios and derivations rules, which have previously been exported using the Export Derivation Scenarios app
Display the logs to check and correct any issues found during validation
Start the import process
 Note
If you want to update a derivation scenario that already exists in the target system, the derivation scenario in the target system needs to be disabled. You can then import
the new version of the derivation scenario. The existing derivation scenario will be overwritten.
Check the import status of each derivation scenario after the import is completed
 Note
The imported derivation scenarios are disabled until you manually enable them by approving them.
Search for and delete existing imports

Desktop
Tablet
Smartphone
Managing Validation Rules

Overview
With the rule management process of MDG, you can collaboratively de ne and catalog validation rules in a repository. The rules can be implemented with BRFplus to be used for data
quality evaluations and for checking data in consolidation and in mass processing. You can also use them for checking data in change requests in MDG, central governance. In addition,
you can group and import and export rules from one system to another, for example from a test to a production system.
The apps relating to rule management are as follows:
Validation Rules
With this app you can collaboratively describe, catalog, and implement rules for data quality using a central rule repository. These validation rules can be used for data quality
evaluations and for checking data in change requests, in consolidation and in mass processing for products and business partners.
Export Validation Rules
With this app you can export validation rules and the corresponding BRFplus data from one system (for example, a test system), in order to later import them into another
system (for example, a production system). The exported rules are pre-validated and you can view a detailed log per export and per validation rule. You start the export
process in the Validation Rules app by selecting the validation rules for the export and triggering the export process.
Import Validation Rules
With this app you can create and work with imports. These imports are uploaded les containing validation rules, the corresponding BRFplus data and administrative data,
such as the source system. You can trigger the validation process for selected rules in an import. The imported rules can then be enabled for usage in your master data
processes.
Validation Rules
With this app, you can collaboratively describe, catalog, and implement rules for data quality using a central rule repository. These validation rules can be used for data quality
evaluations and for checking data in change requests, in consolidation and in mass processing for products and business partners.
As a Master Data Steward, you can use this app to get a structured and comprehensive access to rules as well as to link rules from the rule mining process to validation rules in the
central rule repository. You can also trigger the rule export process from this app.
Key Features
De ne rules including business aspects, responsibilities, and usages
5/19/2023
De ne status handling and lifecycle of rules
De ne the technical implementation and execution of rules with BRFplus
Assign one or several rule usages to be able to proceed with the rule implementation
Con gure a message that will appear in the master data processes where the rule is applied
Link rules from the rule mining process to validation rules in the central rule repository. If automatic implementation is supported, the BRFplus implementation is automatically
added.
Start the export of rules
Enable or disable the usage for each master data process
Simulate rules to check if they work as intended
Display the history of a validation rule by selecting Show Audit Trail in the Administrative Data section

Desktop
Tablet
Smartphone
Simulation
You can use the Simulation function to judge the effect of validation rules. Simulations can be used to verify your implementation to ensure its correctness. Simulations can also give
you a preview of the rule results so you can see the potential impact on your data quality.
The Simulation function can be accessed through the Simulations tab in the Validation Rules apps.
How to Simulate Validation Rules

Use the following procedure to simulate your validation rules.
Context
Use the following procedure to simulate your validation rules.
Prerequistes
Create a validation rule as outlined in Example: Creating a Validation Rule for Products.
Implement a scope expression and condition expression for your rule in the BRFplus.
The rule must not be disabled.
You must have the correct authorizations.
Procedure
1. In the Validation Rules app for your chosen domain, choose a rule and in the Simulations section, choose Create.
2. Enter a description for your simulation and choose Save.
3. Select the data that you want to apply the rule to.
4. Optionally, navigate to the Simulate Active Version and Simulate Inactive Version tabs to change the package size and set checkpoints before starting the simulation. The
default package size is 500, this is used for processing. Reduce the package size if you are dealing with complex records to avoid timeout issues.
5. Choose Start. You simulate based on the active and inactive version of the rule implementation. If a rule does not have an active version or an inactive version that step is
skipped.
Active and Inactive Versions of a Rule
An active version of a rule has its BRFPlus implementation saved and activated. An Inactive version of a rule has changes in the BRFPlus that have been saved but not yet
activated. There can only be one active and one inactive version of a rule at any one time.
6. Review the results shown for the rule simulation.
7. Navigate back to the Simulations tab in the validation rule to get an overview of the simulation results for the active and inactive versions of that rule. Decide if you want to
rework the rule implementation or send it for approval. Note that when you approve a validation rule, the simulations for that rule are automatically deleted.
Export Validation Rules

With this app, you can export validation rules from one system to another, for example from a test to a production system. The BRFplus implementation of the rules is also included in
the export. The exported validation rules are pre-validated, and you can view a detailed log per export and per validation rule. You start the export process in the Validation Rules app
by selecting the validation rules for export and triggering the export process. You can then use the Import Validation Rules app to import the les provided by the export.
This is helpful if you as a Master Data Steward need to set up another system quickly, such as a test system or a system used in a different region.
5/19/2023
 Note
The following BRFplus expression types can be exported:
Boolean
Case
Constant
Database Lookup
Decision Table
Formula
Function Call
Procedure Call
Key Features
Start the export process
Search for and delete existing export processes
Trigger the validation process for selected exports
Check the export status of each rule after the export is completed
Download the export les containing the rule data
 Note
The download contains two les: one .xlsx le containing the rule data and one .zip le containing the BRFplus implementation data

Desktop
Tablet
Smartphone
Import Validation Rules

With this app, you can create and work with imports. These imports are les that were previously created using the Export Validation Rules app. They contain validation rules, their
business details and their BRFplus implementation. You can trigger a validation process for the rules contained in an import. The imported rules can then be enabled for usage in your
master data processes.
This is helpful if you as a master data steward need to set up another system quickly, such as a test system or a system used in a different region.
 Note
The following BRFplus expression types can be imported:
Boolean
Case
Constant
Database Lookup
Decision Table
Formula
Function Call
Procedure Call
 Note
If you use reference objects (for example, ABAP classes or artifacts from other BRFplus applications than ZMDQ_194 and ZMDQ_147), these objects must exist in the target
system before you start the import.
Key Features
5/19/2023
Search for and view a list of imports
Create and delete imports for validation rules
Upload the previously downloaded export les containing the rule data (one .xlsx le and one .zip le, see Export Validation Rules)
Trigger a validation process for the rules to be imported
If the rule owner or implementation expert does not exist in the destination system, the person responsible for the import is automatically assigned as the rule owner.
The validation of the BRFplus implementation might lead to issues that need to be addressed.
If you solve some of the issues shown in the log after the initial validation, you can trigger another validation to get updated results and then trigger the import.
Start the import process. Imported rules are imported with rule status New, and all usages are disabled.
Check the status of imported rules

Desktop
Tablet
Smartphone
Example: Creating a Validation Rule for Products

This business example describes how to create a validation rule to check if a division is provided for nished goods. Rule: For all products of type Finished Product (MARA-MTART =
FERT), the eld Division (MARA-SPART) must be lled.
The rst part of the rule, For all products of type Finished Product (MARA-MTART = FERT), is called the rule scope. The scope de nes which product master data the rule
shall be applied to. For all product data in the scope of the rule, the condition is evaluated. This produces the outcome of either OK or Not OK. For all product data that is not in
the scope of the rule, the outcome is unde ned.
The second part of the rule, the eld Division (MARA-SPART) must be lled, is called the rule condition. This is the check of the rule and the system shall provide the
information if products comply with this rule or violate this rule. When the rule is evaluated, the rule condition determines the outcome of either OK or Not OK.
1. Launch the Validation Rules for Products app.
2. Create a validation rule, enter a Rule ID and a Rule Name, then save the rule. For example:
Rule ID: MARA_SPART_REQ
Rule Name: Division
3. Choose Basic Data (MARA) as the Base Table; choose MARA-SPART as the Checked Field.
The base table is the basis of the rule. Rules are evaluated by the system for each row of the base table. The checked eld is the subject of the rule.
 Note
You have to make an entry in the Base Table eld, while entering a Checked Field is optional.
4. In the General Information section, enter the business details and the contact information. Save the rule.
5. In the Usage section, select Add to add a usage. Select Data Quality Evaluation.
6. In the Usage Action column, select Prepare. If this is the rst usage that you add, check the base table and select Prepare Usage.
7. In the Implementation section, select the link for the scope expression. If you have used MARA_SPART_REQ as the rule ID, the name of the scope expression is
MARA_SPART_REQ_SCP.
The BRFplus Workbench is launched and an initial expression is displayed that needs to be adapted to the desired scope of the rule.
8. Choose Edit Edit Operand Use Direct Value Range From... Context More... , search for the text Material Type and select the entry. Use the value help of the right-
hand side operand and choose FERT for Finished Product.
9. Check if the expression reads: If Material Type is equal to FERT Then Boolean is true, else it is false. This means that this condition is ful lled, if the product is in the scope of
the rule, otherwise it is not in the scope.
10. Save and activate the BRFplus expression, then navigate back to display the validation rule.
11. In the Implementation section, select the link for the condition expression. If you have used MARA_SPART_REQ as the rule ID, the name of the condition expression is
MARA_SPART_REQ_CON.
The BRFplus Workbench is launched, and an initial expression is displayed that needs to be adapted to the desired condition of the rule.
12. Choose Edit Edit Operand Use Direct Value Range From... Context More... , search for the text Division and select the entry. Change the operator in the expression
to is not initial.
13. Check if the expression reads: If Division is not initial Then Boolean is true, else it is false. This means that the outcome of the rule is OK if Division is lled and Not OK if
Division is not lled.
15. Check if the status of both the scope expression and the condition expression is Active.
16. Select Approve to switch the status of the rule to Approved.
17. In the Usage section, select Enable to enable the usage. From now on, the rule is executed in data quality evaluations.
5/19/2023
Example: Implementing Rules with Extra Data Provisioning (Products)
Use
When the system calls the implementation of a validation rule, the data of the base table, the parent table of the base table and the root table Basic Data (MARA) is automatically
supplied. For example, if the base table is Storage Location (MARD), the data from the Plant Data (MARC) and the Basic Data (MARA) tables is automatically supplied. For more
information, see Product Data Model.
In order to check the context objects that are available for your scope or condition expression, navigate to the BRFplus Workbench by selecting one of the links in the Implementation
section and select Context Overview. If you want to access data that resides in a different table of the data model, you can use one of the predelivered procedure calls in BRF+ in the
application ZMDQ_194.
 Note
Using the provided procedure calls impacts the performance. Only use them if you need to access sibling tables of the base table or to check if data exists in subordinate tables, as
shown in this example.
In this example, you want to de ne a validation rule that checks if the delivering plant of a sales area (MVKE-DWERK) has a valid MRP procedure (MRP Type does not equal No
planning/ND). You have entered the base table Sales Data (MVKE) for the rule. Only the data from the Sales Data (MVKE) and Basic Data (MARA) tables and from the evaluation
context can be used directly in the rule implementation. Other data – in our example: plant data, that are stored in the Plant Data (MARC) table – have to be retrieved by using one of
the predelivered procedure calls.
Prerequisites
You have created a validation rule with base table Sales Data (MVKE), and you have added at least one usage.
The rule is in status To Be Implemented.
You have already implemented a scope expression.
Procedure
1. Navigate to the BRFplus Workbench by selecting the relevant link for the condition expression in the Implementation section of the validation rule and select Edit.
2. Select Edit Operand Create Expression .
3. Under General data in the Type dropdown list, select Table Operation.
4. Enter a name, for example Check_MRP_Controller, and a short text. Select Create And Navigate To Object.
 Note
If a popup window appears that informs you that the name already exists, select No and adjust the name.
5. In the popup window that informs you that changes will be lost, select Yes to save your changes.
6. On the Table Operation screen in the Operation dropdown list, select Has exactly and con rm the popup window that appears.
7. In the <Not assigned> dropdown list, choose Select Expression.
8. In the Object Query popup under Search Criteria, leave the rst row (Application Name is equal to ZMDQ_194) as it is. In the second row, select the expression type Procedure
Call, so that the row reads Expression Type is equal to Procedure Call and select Search.
9. In the result list, nd and select MARC lookup ALL and select Ok.
 Note
The result list contains <table name> lookup ALL procedure calls for all tables of the data model that read all data of the respective table.
10. In the description in the Detail section, change the entry 0 for the number of rows to 1.
11. Next to With selection conditions, select Add Condition Insert Include Condition With Plant .
12. In the same row, select Change Context More .
13. In the Context Query popup under Search Criteria, leave the rst row (Element Type is equal to Text) as it is. In the second row, search for the name (Name is equal to) DWERK
and select Deliver.Plant in the result list.
14. In the With selection conditions row, select Change Insert Include Condition With More elds .
15. In the Choose Column popup, search for and select DISMM (MRP Type), and choose OK.
16. Choose the dropdown list next to MRP Type and select is not equal to and enter ND (No planning) in the eld next to it.
17. Save and activate the table operation and choose Display to unlock it.
18. Select the Back button below Table Operation, save and activate the condition expression and choose Display to unlock it.
19. The condition expression can now be used in the validation rule.
Example: Creating a Validation Rule for Business Partners

This business example describes how to create a validation rule to check if a goods-receipt-based invoice veri cation is provided for purchasing group 001. Rule: For all suppliers of
purchasing group 001 (LFM1-EKGRP = 001), the eld GR-Based IV (LFM1-WEBRE) must be checked/must not be initial.
The rst part of the rule, For all suppliers with purchasing group 001 (LFM1-EKGRP = 001), is called the rule scope. The scope de nes which supplier master data the rule
shall be applied to. For all suppliers in the scope of the rule, the condition is evaluated. This produces the outcome of either OK or Not OK. For all business partner/supplier
data that is not in the scope of the rule, the outcome is unde ned.
5/19/2023
The second part of the rule, The eld GR-Based IV (Goods-receipt-based invoice veri cation, LFM1-WEBRE) must be lled, is called the rule condition. This is the check of the
rule and the system shall provide the information if business partners/suppliers comply with this rule or violate this rule. When the rule is evaluated, the rule condition
determines the outcome of either OK or Not OK.
1. Launch the Validation Rules for Business Partners app.
2. Create a validation rule, enter a Rule ID and a Rule Name, then save the rule. For example:
Rule ID: LFM1_WEBRE_REQ
Rule Name: GR-Based Invoice Veri cation
3. Choose Purchasing Org Data (LFM1) as the base table; choose LFM1-EKGRP as the Checked Field.
The base table is the basis of the rule. Rules are evaluated by the system for each row of the base table. The checked eld is the subject of the rule.
 Note
You have to make an entry in the Base Table eld, while entering a Checked Field is optional.
4. In the General Information section, enter the business details and the contact information. Save the rule.
5. In the Usage section, select Add to add a usage. Select Data Quality Evaluation.
6. In the Usage Action column, select Prepare. If this is the rst usage that you add, check the base table and select Prepare Usage.
7. In the Implementation section, select the link for the scope expression. If you have used LFM1-WEBRE_REQ as the rule ID, the name of the scope expression is LFM1-
WEBRE_REQ_SCP. The BRFplus Workbench is launched and an initial expression is displayed that needs to be adapted to the desired scope of the rule.
8. Choose Edit Edit Operand Use Direct Value Range From... Context More... , search for the text Purchasing Group and select the entry. Use the value help of the
right-hand side operand and choose 001 for MDG Purch. Group 1.
9. Check if the expression reads: If Purch. Group is equal to 0001 Then Boolean is true, else it is false. This means that this condition is ful lled, if the business partner is in the
scope of the rule, otherwise it is not in the scope.
11. In the section Implementation, select the link for the condition expression. If you have used LFM1-WEBRE_REQ as the rule ID, the name of the condition expression is LFM1-
WEBRE_REQ_CON.
The BRFplus Workbench is launched, and an initial expression is displayed that needs to be adapted to the desired condition of the rule.
12. Choose Edit Edit Operand Use Direct Value Range From... Context More... , search for the text GR-Based IV (GR-Based Invoice Veri cation) and select the entry.
Change the operator in the expression to is not initial.
13. Check if the expression reads: If GR-Based IV is not initial Then Boolean is true, else it is false. This means that the outcome of the rule is OK if GR-Based IV is lled and Not OK
if GR-Based IV is not lled.
15. Check if the status of both the scope expression and the condition expression is Active.
16. Select Approve to switch the status of the rule to Approved.
17. In the Usage section, select Enable to enable the usage. From now on, the rule is executed in data quality evaluations.
Example: Implementing Rules with Extra Data Provisioning (Business Partners)
Use
When the system calls the implementation of a validation rule, the data of the base table, the parent table of the base table and the root table General Data (BUT000) is
automatically supplied. For example, if the base table is Phone (ADR2), the data from the Address (ADRC) table and the General Data (BUT000) tables is automatically supplied. For
more information, see Business Partner Data Model.
In order to check the context objects that are available for your scope or condition expression, navigate to the BRFplus Workbench by selecting one of the links in the Implementation
section and select Context Overview. If you want to access data that resides in a different table of the data model, you can use one of the predelivered procedure calls in BRF+ in the
application ZMDQ_147.
 Note
Using the provided procedure calls impacts the performance. Only use them if you need to access sibling tables of the base table or to check if data exists in subordinate tables, as
shown in this example.
In this example, you want to de ne a validation rule that checks if a business partner has at least one identi cation number. You have entered the base table General Data (BUT000)
for the rule. Only the data from table General Data (BUT000) and from the evaluation context can be used directly in the rule implementation. Other data – in our example:
identi cation numbers, that are stored in table BUT0ID – have to be retrieved by using one of the predelivered procedure calls.
Prerequisites
You have created a validation rule with base table General Data (BUT000), and you have added at least one usage.
The rule is in status To Be Implemented.
You have already implemented a scope expression.
Procedure
1. Navigate to the BRFplus Workbench by selecting the relevant link for the condition expression in the Implementation section of the validation rule and select Edit.
2. Select Edit Operand Create Expression .
3. Under General data in the Type dropdown list, select Table Operation.
5/19/2023
4. Enter a name, for example Check_ID, and a short text. Select Create And Navigate To Object.
 Note
If a popup window appears that informs you that the name already exists, select No and adjust the name.
5. In the popup window that informs you that changes will be lost, select Yes to save your changes.
6. On the Table Operation screen in the Operation dropdown list, select Has at least and con rm the popup window that appears.
7. In the <Not assigned> dropdown list, choose Select Expression.
8. In the Object Query popup under Search Criteria, leave the rst row (Application Name is equal to ZMDQ_147) as it is. In the second row, select the expression type Procedure
Call, so that the row reads Expression Type is equal to Procedure Call and select Search.
9. In the result list, nd and select BUT0ID lookup ALL and select Ok.
 Note
The result list contains <table name> lookup ALL procedure calls for all tables of the data model that read all data of the respective table.
10. Optionally, you can add further conditions using the Add Condition dropdown list next to With selection conditions.
11. Save and activate the table operation and choose Display to unlock it.
12. Select the Back button below Table Operation, save and activate the condition expression and choose Display to unlock it.
13. The condition expression can now be used in the validation rule.
Implementing Validation Rules with Extra Data Provisioning

When the system calls the implementation of a validation rule, the data of the base table and of the root table (for example, MARA or BUT000) is automatically supplied. If the root
table is not the parent table of the base table, the data of the parent table of the base table is also automatically supplied.
 Note
For more information about the table relationships in the product and business partner data models, see Data Models.
If other data is required, you need to set up extra data provisioning. To access data that resides in a table of the data model, you can use one of the predelivered procedure calls in
BRFplus in the application ZMDQ_194 for products and ZMDQ_147 for business partners. Additionally, you can do this by using for example BRFplus Database Lookup expressions,
BRFplus Procedure Call expressions (to call custom ABAP code), or model extensions as well as by creating custom views.
 Note
Please consider the performance impact when using extra data provisioning.
Extra data provisioning is for example required in the following cases:
When data is not automatically supplied at runtime, for example, if you want to compare a eld of sales data (from MVKE) with a eld of a particular plant (from MARC), or if
you want to consider transactional data.
When advanced data lookups are required that go beyond simple JOIN conditions.
 Example
For a detailed description about implementing rules with extra data provisioning using the predelivered procedure calls, please refer to Example: Implementing Rules with Extra
Data Provisioning (Products) and Example: Implementing Rules with Extra Data Provisioning (Business Partners).
Important Information
The system uses a process from consolidation and mass processing (CMP) to perform a data quality evaluation. This means that the system copies the relevant data from the tables
storing active data (for example, MARA, MARC, BUT000, KNA1) to the process tables of the CMP framework. The system considers a table relevant for copying, if there is at least
one validation rule with this table as the base table.
For extra data provisioning, you should read data from the process tables, using the Process ID, Step Number and Source ID as parameters. The values for these parameters are
supplied at runtime to the implementation of the rule.
If you need to access data from tables that are not automatically copied, because there is no validation rule with this table as the base table, you need to access the tables with active
data. Alternatively, you can also create a dummy validation rule with this table as the base table, so that the system considers the table as relevant. To avoid that this dummy rule
produces undesired evaluation results, you can use a scope expression that always returns false.
Using a dummy rule implies that all data of the base table is copied, regardless of whether all the data is needed by the implementation. However, the advantage is that the resulting
implementation will also work if the rule is used in consolidation and mass processing.
For more information, see SAP Note 3027162 .
Consolidation and Mass Processing

When the system uses a validation rule as part of a consolidation or mass process, there is technically no relevant difference from the data quality evaluation case described above.
However, you need to consider that the data to be validated might come from an active record or from a source record that is to be loaded. As a general recommendation, read the
extra data from the process tables.
5/19/2023
Check in Change Requests
When the data to be validated is part of a change request, it must be read using one of the APIs for reading data from change requests so that all use cases are covered.
Procedure
The system supplies the required information with the BRFplus structure data object Evaluation Context (EVAL_CONTEXT_DQ_STR).
When implementing the scope and condition expressions with BRFplus, use a CASE expression that uses the component Rule Stage (RULE_STAGE) of the Evaluation Context to
branch into different expressions for data provisioning.
Use the components Process ID (PROCESS_ID) and Step Number (PROCESS_STEP_NO) together with Source ID (SOURCE_ID) of the supplied data to read from process tables of
the CMP framework. You can also use the API cl_mdc_process_access to get further information.
Use the component Change Request (CHANGEREQUEST_ID) to read the data of a change request.
General Advice
Consider the performance.
Carefully examine each option depending on the use case.
Separate the business logic from data provisioning.
Example: Determine valid combinations of values in one expression, and use another expression for data provisioning.
Re-use common parts in multiple validation rules.
If business requirements change, typically only a change of the logic in the expression is needed, and no change in data provisioning is required.
Further Information
For more information, see the documentation on the SAP Community (https://community.sap.com/topics/master-data-governance/how-to ).
Implementing Rules from Rule Mining
Use
You can include rules that were generated during rule mining in your rule repository and use them to check the quality of your master data. The advantage of using rules from rule
mining is that a rule from rule mining can be automatically implemented, if all involved elds, for example Checked Field, Technical Description and Technical Focus Area, belong to
the generated set of elds.
Prerequisites
You have executed a rule mining run in the Manage Rule Mining app.
Automatic implementation is supported if all involved elds of a rule from rule mining belong to the base table of the validation rule, its parent table or root table (see Data
Models).
 Example
If the elds used in the rule from rule mining belong to tables MARC and MVKE, automatic implementation is not possible, because these are sibling tables.
In the Process Rules from Rule Mining app, you have linked the desired rule to a new or existing rule (see Reviewing Mined Rules in Rule Mining Process Overview).
Procedure
If you have linked the rule to a new rule, proceed as follows:
1. In the Validation Rules app, call up the linked rule using the search in the header area. Alternatively, in the Process Rules from Rule Mining app, you can select the link in the
Linked Validation Rule column and then the Validation Rules link.
 Note
The sections Rule Mining Implementation and Rules from Rule Mining are displayed in the rule. In the Rules from Rule Mining section, you can see that the rule has not been
implemented, and if automatic implementation is supported.
2. In the Usage section, click Add to select a usage.
3. In the Usage Action column, select Prepare and then Prepare Usage. The BRFplus expressions are created and activated in the background. In the Rules from Rule Mining
section, you can see that the Status has changed to Implemented.
4. Select Approve to activate the rule.
If you have linked the rule to an existing rule, proceed as follows:
1. In the Validation Rules app, call up the linked rule using the search in the header area. Alternatively, in the Process Rules from Rule Mining app, you can select the link in the
Linked Validation Rule column and then the Validation Rules link.
 Note
5/19/2023
The sections Rule Mining Implementation and Rules from Rule Mining are displayed in the rule. In the Rules from Rule Mining section, you can see that the rule has been
added and that it has not been implemented, and if automatic implementation is supported.
2. In the Rule Mining Implementation section, select Update Decision Tables.
The rule implementation is updated. If you select the links in the Implementation section and navigate to the decision table in BRFplus, you can see that the elds have been
added to the table.
3. In the Rules from Rule Mining section, you can see that the new rule now also has the status Implemented.
4. Select Approve to activate the rule.
Reusing BRFplus Artifacts

The BRFplus artifacts that you use in the scope or condition of your rules can be reused by other rules. Therefore, please consider the following:
If you activate or change a BRFplus artifact, this also affects other rules that use the same artifact.
If you import rules with reused BRFplus artifacts using the Import Validation Rules app, these objects must exist in the target system before you start the import.
Using Validation Rules

You can use validation rules for different master data processes, which you can de ne in the Validation Rules app in the Usage section of a rule as follows.
Prerequisites
If you want to use validation rules in change requests, in consolidation and in mass processing, you have to make the corresponding Customizing settings in MDG, central governance
(for change requests) or in consolidation and mass processing.
For consolidation and mass processing, please refer to the following sections:
Con gure Validation
Con gure Activation for Business Partner
Con gure Activation for Material
For change requests, please refer to the following sections:
De nition of Validations Using Validation Rules for products
De nition of Validations Using Validation Rules for business partners
De nition of Validations Using Validation Rules for suppliers
De nition of Validations Using Validation Rules for customers
De nition of Validations Using Validation Rules for custom objects
Procedure
5/19/2023
1. Select Add to add a usage.
2. Choose one of the following processes:
Data Quality Evaluation (to be scheduled in the Evaluate Data Quality app)
Check in Change Requests
Check in Consolidation
Check in Mass Processing
 Note
You can select one or several of these processes for each rule.
3. Select Prepare to prepare the usage of the validation rule in the relevant process.
4. If it’s the rst time that you add a usage, you have to implement and activate the rule in BRFplus and then approve the rule.
5. Select Enable to be able to use the rule in the various processes.
 Note
You can only enable the usage, if the rule is in status Approved.
When you have added a usage for Check in Change Requests, Check in Consolidation or Check in Mass Processing, the Message section appears on the UI, where you can choose to
use the Default Text or a Prede ned Text. After the validation step in change requests, in consolidation or mass processing, the selected message is displayed per enabled rule.
If you select Prede ned Text, you can de ne your own message. In this case, you de ne the Message Severity, enter the Message Class and Message Number and enter values for
the message variables. You can use values belonging to the rule (for example, Rule Owner) and values belonging to the master data (for example, Material Type).
Role Setup for Validation Rule Management

You have different options to set up the responsibilities for managing validation rules. Please nd below two example processes. In the rst one, the tasks are split up between two
roles. In the second one, one role is authorized for all tasks.
Shared Reponsibilities
In the following graphic, two roles are involved in the rule management process: the rule owner (SAP_CMD_QLTY_<BP/PR>_RULE_MNG – Manage Rule) and the implementation
expert (SAP_CMD_QLTY_<BP/PR>_RULE_IMP – Implement Rule). They are set up in such a way that you have a separation of duties.
Fast Track
In the following graphic, the whole process is driven by the role SAP_CMD_QLTY_<BP/PR>_RULE_FAST (Manage Rule Fast Track). Assign this role to users who should be authorized
for every step of the process. However, since for this role not all rule statuses are required, it is recommended not to combine this role with other roles in the process.
5/19/2023
Related Information
Master Data Quality: Validation Rule (MDQRM_RULE)
Rule Mining Process Overview
Overview
The purpose of the rule-mining process is to discover new validation rules based on your selected criteria. The process utilises machine learning to choose potential rules for your
evaluation.
The complete process involves creating a mining run, executing that run, evaluating the mined rules created by the run, and then linking the mined rules you want to keep with
validation rules in the rule repository either by linking to existing validation rules or creating new ones.
You can break the rule mining process down into two main steps: creating a rule mining run and reviewing the rules mined from the run.
Creating a Rule Mining Run

1. Open the Manage Rule Mining app and choose + to create a mining run.
2. Give your new mining run a description and add a reason for the run. You can also choose how many rules you want the engine to suggest.
3. Choose the database tables that you want to search for rules.
4. From the database tables choose the elds you want to include.
5. Choose if you want elds to be the condition of the rule, the subject of the rule (checked by the rule), or both. If a eld is a condition of a rule it is used in the "if" part of the rule,
if it is checked by the rule then it is part of the “then” part of the rule.
 Example
Consider this rule: If Base Unit of Measure = EA, then Valuation Unit of Measure = EA. In this case the Base Unit of Measure is the condition and the Valuation Unit of
Measure is checked.
6. If you wish you may enter a lter or focus area to narrow the scope of your selection. For example, you may decide that your older records contain too many mistakes and
restrict the rule mining to the more recent material numbers.
7. Once you have entered all required information and saved the run you can start the run. This will start the run and you can review the status in the main screen. Any time
before the run has completed running you can stop the run. You can also delete the run and remove any associated mined rules (except for those rules already approved).
8. Once a run has completed you can review and check the suggested rules using the Process Rules from Rule Mining app. You can navigate directly to this app from the
completed mining run.
Reviewing and Using Mined Rules

1. Open the Process Rules from Rule Mining app to review the rules generated by your mining run.
2. You can either accept or reject a mined rule. You can use the data on the screen to make your decision. If you accept a mined rule the next stage is to link this mined rule to a
validation rule in the rule repository. Other options offered by this UI include deleting the rule or changing the rule status.
Interpreting Your Rule Mining Results
The system provides you with an evaluation for each rule of the data records considered by that rule. The data records can either be judged as not relevant for the rule,
violating the rule, or complying with the rule. The most interesting rules are usually those with high percentages in complying with the rule or low percentages in violating the
rule, which display clear trends in data entry. It is suggested to use the lters to screen your data for rules with these trends.
3. Select a rule with the status Accepted and choose the Link to Validation Rule dropdown button to link the mined rule to either an existing validation rule or a new validation
rule. When linking to an existing validation rule, the system offers you rules with the same checked eld and table as the mined rule. The linked rule is shown in the Linked
Validation Rule column.
5/19/2023
4. You have now created or updated a validation rule. Your next step is to open the Validation Rules app, either from the launchpad or directly by selecting the link in the Linked
Validation Rule column and then the Validation Rules link. For information on implementing rules, see Implementing Rules from Rule Mining
Manage Rule Mining

With this app you can create and start a rule mining run to discover business rules for your master data records. In a mining run, you can de ne the focus for a mining run and specify
the elds that could be potential condition elds and checked elds for your new rules. When you start the mining run, the system uses a machine learning algorithm to propose a list
of potential rules based on your input. This app assists the master data steward in uncovering potential rules for their master data and so shortens the preparation time of rule
de nition.
Key Features
Create and start mining runs with following capabilities:
Describe the mining purpose or the expected rules generated from this mining run
By drilling down to each selected table, you can de ne a mining data scope by using lters in the focus areas, and selecting elds which could be conditions or checked
by the rules.
De ne maximum number of rules which you want to work with after this mining run nished.
View all previous mining runs, monitoring the run status and mining log.
Delete stopped mining runs or stop executing mining runs
Navigate to a mined rule list from a completed mining run.

Desktop
Tablet
Smartphone
Process Rules from Rule Mining

With this app you can review and manage rules generated from rule-mining runs. You can decide to accept the rules or set them for review by others from this app. You can either
create a new validation rule directly from the accepted mined rules, or link the mined rules to existing validation rules. This app offers many lters and ways of sorting and grouping
the rules to help you to nd and compare interesting rules. For each rule, the app shows you the number of records complying or violating the rule to help you to make decisions.
Key Features
Review and manage rules from rule-mining runs.
Adjust the status of mined rules: accept, reject, set to review, set to initial.
Link mined rules to validation rules: link to new rule, link to existing rule, or remove a link.
View the number of records that violate or comply with the rule.
View the checked eld - this is a eld that has been identi ed as the subject of a rule. All rules with the same checked eld can be linked to a single validation rule.

Desktop
Tablet
Smartphone
Data Quality Evaluation Process Overview
Overview
The data quality evaluation apps collectively enable you to con gure how you want your data quality scores to be calculated; create, monitor, and manage Data Quality Evaluation
runs; show the quality scores for your data; and analyze, drilldown, and correct errors in your data based on evaluation results.
The apps can be grouped as follows:
Con gure Data Quality scores apps
5/19/2023
These apps enable you to determine how the system calculates the data quality scores for your data to be used in Data Quality Evaluation runs. You can choose thresholds for
your validation rules to apply, and the weighted impact of these validation rules.
This app enables you to create, schedule, and execute data quality evaluation runs. You can also delete results while keeping that data for score calculation.
Data Quality Evaluation Overview apps
These apps provide dashboards showing a high-level overview of your data quality and data quality trends across an entire business object. This data is always based on the
default Global category.
Evaluation Results apps
These apps enable you to analyze data from your evaluation runs and navigate to correct errors.
Data Quality Score apps
These apps show the data quality scores for your objects across all categories and dimensions, you can drill down to examine the scores based on the tables, rules, dimensions,
or categories.
Prerequisites
To use data quality evaluation apps, you should have created and approved validation rules in your system. You can create these rules manually or use the Rule Mining apps to assist
you in the process.
Process Overview
The process for data evaluation involves multiple apps with some optional steps. You need to create and execute data quality evaluation runs to check your data quality based on your
prede ned validation rules, and then you use the evaluation apps to display data quality evaluation results and navigate to additional apps to resolve data quality issues.
The Data Quality Score and Data Quality Evaluation Overview apps enable you to monitor your data quality with meaningful KPIs. Optionally, you can also con gure your data quality
score display to better monitor your data quality.
Creating and Executing Data Quality Evaluation Runs

1. Launch the Evaluate Data Quality app for your chosen domain (Product or Business Partner).
2. Choose Create Process.
3. Enter a description for your evaluation run and choose a process template for the run. In most cases there should only be one process template. Choose Save.
4. Use the toggles to determine if you want to provide scores for dimensions, to delete previous evaluation results, or to delete old data quality scores. You can enter a Package
Size for parallel execution. If you are encountering timeout issues for your evaluation runs, you can use this setting to reduce the volume of objects to avoid these issues. If you
don’t enter a number here, the system uses 500 as the default size.
5. To execute your data quality run, choose Start. The run automatically processes your data using all active validation rules in your rule repository.
6. You can stay on the page while the run executes, optionally choosing Abort, to cancel the run. You can see the run progress in the status bar.
7. The system displays the preliminary results for the run. Choose Analyze Results to navigate directly to the Evaluation Results app or choose Back to return to the main
Evaluate Data Quality UI.
Evaluating and Correcting Data Quality Run Results

1. To view the results of your evaluation run, launch the Evaluation Results app for your domain (Product or Business Partner) or navigate directly from an evaluation run by
choosing Analyze Results.
2. The Evaluation Results apps consist of a header bar with a graphical representation of the results and a detailed Evaluation Items section below with a breakdown that
changes based on the graphics you select above. Select the Not OK element to display the records that violate your validation rule.
3. Choose the links in the Evaluation Items table to discover more data about the records and the rules. Choosing the Rule ID link enables you to see the BRFplus expression for
the rule and to navigate directly to the BRFplus.
4. If you wish, you can start a mass change using the Process Business Partners or Process Products buttons. This is useful for cases where you have multiple similar rule
violations.
5. If you wish, you can export the business partner or product data to a le using the Export Business Partners or Export Products buttons. This is useful in cases where you need
to check with experts or want to keep an offline copy of your work.
6. When you have clari ed all data errors you can use the Evaluate Data Quality app to create a new data quality evaluation run to con rm your results.
For further information on interpreting the data quality results see the following document: Interpreting Data Quality Evaluation Results
Con guring Data Quality Scores (Optional)

You can use the Con gure Data Quality Scores apps to de ne new dimension categories and dimensions for your data. You do this by adding dimension categories, assigning
dimensions, and adding rules to the dimensions. Once you save your new content, the system automatically adds it to the Data Quality Score apps (for all categories) and the Data
Quality Evaluation Overview app (if you have modi ed the Global category). To create a new category, follow the process below.
1. Launch the Con gure Data Quality Scores app for your domain (Product or Business Partner).
2. To add a new dimension category, choose +. Alternatively, you can edit an existing dimension.
5/19/2023
3. In the Category eld, enter a meaningful name.
4. In the Target, Warning, and Critical elds enter the threshold levels in percent where you want to trigger visual warnings on the UI for these levels. For example, you may
choose 95 as the target level, 80 as the level to highlight as a warning, and 65 as a critical level.
5. To add a new dimension to your dimension category choose Add Dimension.
6. In the Dimension section give your dimension a name and enter distinct threshold levels for the dimension if you wish. Choose Save.
7. To add validation rules to your dimension, choose Edit.
8. In the Dimensions section choose > in the Dimension table next to your new dimension.
9. To add a new rule to your dimension choose +.
10. Use the search box to nd rules and then select one or more rules to add to your dimension and Choose OK.
11. Choose an impact level from the Impact drop down menu.
12. Choose Apply.
13. To save your assigned rules, dimension, and dimension category, choose Save.
14. You have created a new dimension category that will appear in the related Data Quality Score app.
Con gure Master Data Quality Scores

With this app you can con gure how a data quality score is calculated, based on the evaluation of master data in combination with data quality rules. You can create data quality
dimensions, categories of data quality dimensions, and assign rules to these data quality dimensions. This results in a hierarchy with data quality categories at the top, data quality
dimensions at the next level, and assigned rules at the lower level. The system calculates scores for dimensions and categories based on this information. Note that if you rename or
delete the Global dimension category the following cards in the Data Quality Evaluation Overview app will be blank: Latest Data Quality Score and Data Quality Trend.
Key Features
Compare the progress of data quality related efforts in your organization over time and data quality dimensions.
De ne quality categories, including a category score as a key performance indicator (KPI) of data quality.
De ne thresholds for the category score
De ne quality dimensions, including a dimension score as a KPI of data quality
De ne thresholds for the dimension score
Assign data quality rules to dimensions as the basis for data quality score calculation
De ne the impact of a rule on the assigned dimension

Desktop
Tablet

With this app you can create, execute, and schedule data quality evaluations runs. You can also delete entire existing runs or choose to delete the results of evaluations and keep
their aggregated data to use in score calculation.
Key Features
Create and execute a data quality evaluation
Schedule a data quality evaluation, for example, at weekly intervals
Delete a data quality evaluation including its data
Delete the results of data quality evaluations and keep their aggregated data to use in score calculation

Desktop
Tablet
Interpreting Data Quality Evaluation Results

5/19/2023
Data quality evaluation run results can be more complex than they rst appear. The system evaluates each rule and returns the result OK or Not OK for each rule and dataset
combination. This simple result has more complex interpretations and this document will explain how to read the results to get the best understanding of your data.
Impact of Rule Structure on Product Results

Each rule has a Base Table; this is the database table that the evaluation is based upon. If the base table is MARA (Basic Data) the system evaluates the rule only once for each
product. If the base table is MARC (Plant Data) the system evaluates the rule based on the number of plants for which it was created; this could be once, multiple times, or not at all.
The validation rule scope narrows the master data the rule applies to. A typical scope expression may look something like this: If Material Type = FERT, then apply rule. The rule is only
applied to records that area in scope, those that are not in scope are unde ned. You can see how many database table rows were checked in the evaluation results.
Impact of Rule Structure on Business Partner Results

Each rule has a Base Table; this is the database table that the evaluation is based upon. If the base table is BUT000 (General Data) the system evaluates the rule only once for each
business partner. If the base table is KNVV (Sales Data) the system evaluates the rule based on the number of sales organizations for which the Business Partner was created; this
could be once, multiple times, or not at all.
The validation rule scope narrows the master data the rule applies to. A typical scope expression may look something like this: If Purchasing Group = 001, then apply rule. The rule is
only applied to records in scope, those that are not in scope are unde ned. You can see how many database table rows were checked in the evaluation results.
No Evaluation Results for a Validation Rule

If you don’t get any evaluation results for a rule this may be because of the following:
The rule is not active, and/or it is not yet considered in any evaluation.
The rule was evaluated, but according to the rule’s scope, there was no data that produced an outcome.
The rule was evaluated, and evaluation results were available, but these results were deleted.
No Evaluation Results for an Entire Evaluation Run

As with a single rule you can have an entire evaluation run with no results. This may be because:
The results were deleted using the Delete Results action
The system automatically deleted the results due to the housekeeping settings of a subsequent evaluation
There are no active rules, or no data selected based on the rule scope
Deeper Analysis of Evaluation Results

You can use the Evaluation Results apps to analyze the evaluation results. There can be multiple rows in the Evaluation Items table in these apps for a single product. There will be an
evaluation item for each combination of product and outcome at least. If elds such as Plant and Storage Location are considered, then there will be rows for each
eld/product/outcome combination. If elds such as Sales Organization and Distribution Channel are considered, there will also be rows for each eld/customer/outcome
combination.
Understanding Rule Impact and Weighting

Rule Impact is a value you manually assign to a rule that in uences the weighting of a rule used when calculating a data quality dimension score.
The weightings displayed on the Data Quality Dimension UI represent the weighting of the rule and change dynamically based on new rules or changes to existing impact values. If
you add another rule to a data quality dimension (with an impact other than None) the impacts of the assigned rules stay the same, but the weightings change.
Each Data Quality Category has a score based on its constituent Data Quality Dimensions. The scores for each dimension are added together and averaged (with no weighting) to
get the nal data quality category score.
Impact and Weighting

The impact effects the weighting of a rule as follows:
Rules with Low impact are the lowest weighting that in uence a rule and have a numeric value of 1.
Rules with Medium impact have twice the weighting of a low impact rule, or a numeric value of 2.
Rules with High impact have three times the weighting of a low impact rule, or a numeric value of 3.
Rules with an impact of None do not in uence the dimension score and so have a numeric value of 0.
Example
You have two rules for a Data Quality Dimension: Rule A with a data quality score of 40, and Rule B with a data quality score of 80. Rule A has an impact of High (3), Rule B as an
impact of Low (1). Rule A has three times the weighting of Rule B. So, the weighting for Rule A is .75 and the weighting for Rule B is .25.
When calculating the data quality dimension score the formula would be (40 X .75) + (80 X .25) for a total data quality score of 50.
If I add a new rule, Rule C with an impact of Low (1) and a data quality score of 50 the weighting for all three rules changes as follows:
5/19/2023
Rule Score Impact Old Weighting New Weighting
Rule A 40 High (3) .75 .60
Rule B 80 Low (1) .25 .20
Rule C 50 Low (1) None .20
The data quality dimension score calculation would be (40 X .60) + (80 X .20) + (50 X .20) for a nal score of 50 for the data quality dimension.
Product Evaluation Results
Evaluation Results for Plant Data of Products

With this app you can analyze the data quality evaluation results. You can display the evaluation outcome for rules and products on plant-level. You can analyze which products have
errors and which do not to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Analyze data with errors using lters, diagrams, and sorting based on product attributes.
Start the correction of data with errors
Create pre- ltered lists of data to be corrected, for example to collaborate with data owners
This app uses the C_MDQltyProductPlantResult CDS view.

Desktop
Tablet
Evaluation Results for Products

With this app you can analyze the data quality evaluation results. The app displays the evaluation outcome for all rules and products. You can analyze which products have errors and
which do not to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from this app.
Key Features
Create pre- ltered lists of data to be corrected, for example to collaborate with data owners
This app uses the C_MDQltyProductGeneralResult CDS view.

Desktop
Tablet
Evaluation Results for Sales Data of Products

With this app you can analyze the data quality evaluation results. You can display the evaluation outcome for rules and products on sales data-level . You can analyze which products
have errors and which do not to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Create pre- ltered lists of data to be corrected, for example to use when collaborating with data owners
This app uses the C_MDQltyProductSalesResult CDS view.
5/19/2023
Desktop
Tablet
Data Quality Evaluation Overview for Products

With this app you can display up-to-date status information about the current data quality and drill down into the details for further analysis.
Key Features
This app provides the following key features:
A card showing the data quality score by dimensions of the category global
A card showing the trend of the data quality score of the category global
A card showing latest data evaluation processes
A card showing incorrect product data based on the latest evaluation
A card showing incorrect plant data for products based on the latest evaluation
A card showing incorrect sales data for products based on the latest evaluation
This app uses the C_MDQltyProductGeneralResult CDS view.

Desktop
Tablet
Data Quality Score for Products

With this app you can display up-to-date data quality score information for all dimension categories of products. You can drill down into the details for further analysis.
Key Features
View the data quality score by category
View the data quality score by dimension
View the data quality score by base table
View the data quality score by rule

Desktop
Tablet
Smartphone
Business Partner Evaluation Results
Evaluation Results for Business Partners

With this app you can analyze your data quality evaluation results. The app displays the evaluation outcome for validation rules applied to your business partner records. You can
determine which business partners have errors and which do not, to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from this app.
Key Features
Analyze data with errors using lters, diagrams, and sorting, based on business partner attributes
Create pre- ltered lists of data with issues, which you can use, for example, to collaborate with data owners
This app uses the C_MDQltyBPGeneralResult CDS view.
5/19/2023
Desktop
Tablet
Evaluation Results for Sales Data of Customers

With this app you can analyze the data quality evaluation results. You can display the evaluation outcomes for rules applied to the sales data of customers. You can determine which
customer entries have errors and which do not, to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Analyze data with errors using lters, diagrams, and sorting based on business partner and customer attributes.
This app uses the C_MDQltyBPCustSalesAreaResult CDS view.

Desktop
Tablet
Evaluation Results for Purchasing Data of Suppliers

With this app you can analyze the data quality evaluation results. You can display the evaluation outcomes for rules applied to supplier purchasing data. You can determine which
suppliers have errors and which do not, to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Analyze data with errors using lters, diagrams, and sorting based on business partner and supplier attributes
This app uses the C_MDQltyBPSuplrPurgOrgResult CDS view.

Desktop
Tablet
Evaluation Results for Company Code Data of Suppliers

With this app you can analyze the data quality evaluation results. You can display the evaluation outcomes for rules applied to the supplier company code data. You can determine
which supplier company code entries have errors and which do not, to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Analyze data with errors using lters, diagrams, and sorting based on business partner and supplier attributes.
Create pre- ltered lists of data with issues, which you can use, for example, to collaborate with data owners.

Desktop
Tablet
Evaluation Results for Company Code Data of Customers

5/19/2023
With this app you can analyze the data quality evaluation results. You can display the evaluation outcomes for rules applied to the customer company code data. You can determine
which customer company code entries have errors and which do not, to nd areas of bad data or reasons for incorrect data. You can also start the correction of data from here.
Key Features
Analyze data with errors using lters, diagrams, and sorting based on business partner and customer attributes.
Create pre- ltered lists of data with issues, which you can use, for example, to collaborate with data owners.

Desktop
Tablet
Data Quality Evaluation Overview for Business Partners

With this app you can display up-to-date data quality score information for business partners. You can drill down into the details for further analysis.
Key Features
This app provides the following key features:
A card showing the data quality score by dimensions of the category global
A card showing the trend of the data quality score of the category global
A card showing latest data evaluation processes
A card showing incorrect business partner data based on the latest evaluation
A card showing incorrect sales data of customer based on the latest evaluation
A card showing incorrect purchasing data of supplier based on the latest evaluation
A card showing incorrect supplier company code data
A card showing incorrect customer company code data
This app uses the C_MDQltyDimnCatRuleScore CDS view.

Desktop
Tablet
Smartphone
Data Quality Score for Business Partners

With this app you can display up-to-date data quality score information for all business partner dimension categories. You can drill down into the details for further analysis.
Key Features
View the data quality score by category
View the data quality score by dimension
View the data quality score by base table
View the data quality score by rule

Desktop
Tablet
Smartphone
Master Data Quality Worklist

5/19/2023
 Note
As of SAP S/4HANA 1909, we recommend to use the apps for Managing Data Quality instead of the Master Data Quality Worklist apps.
The Master Data Quality Worklist enables you to display rules data and product master data as well as to import les of master data objects with errors that come from an external
data quality validation tool. With this you can start the correction process to remediate product master data objects with errors to improve the data quality in your company.
Master Data Quality Worklist for Product
Use
This app provides information about product master data objects with errors.
With this app you can see rules data and product master data. With this app you can also start the correction process to remediate product master data objects with errors.
For more information on the process steps, see Using the Worklist for Product App.
Key Features
List all master data quality issues for products
Filter object attributes, rule sets, and IDs
Get a detailed rule description for every rule violation
Navigate to the object data
Navigate to the object maintenance applications
Share the master data quality issues to discuss them with your colleagues using SAP Jam functions
This app uses the C_MDQualityProductsWithErrors CDS view.

Desktop
Tablet
Phone

Master Data Quality - Product (SAP_CMD_BC_QLTY_PRODUCT)
Using the Worklist for Product App
Use
With this app you can monitor product master data quality issues as a prerequisite to get these issues solved and to ensure that business processes run correct.
Process
1. The evaluation run provides a worklist with master data object attributes and with speci c rule violations.
2. You can specify a lter for the list view to get only those master data objects with errors that are relevant for you.
3. You can see the rule description to get a detailed information about the violated rule.
4. You can get details of the master data object to understand the root cause of the error.
5. You can select the master data object you want to work on.
6. You can trigger a single object change.
7. The system navigates to the application where you can change the object.
8. After having corrected the error, you can change the status of the object to Finalized to have an overview of the objects that are processed already.
9. You can adjust the violated rule to avoid these kind of errors in the future.
10. You can enter the note Rule Adjustment.
11. You can lter all items for which the rule needs to be adjusted to discuss this adjustment with your colleagues.
Manage Imports for Master Data Quality
5/19/2023
Use
With this app you can import les of master data objects with errors that come from an external data quality validation tool to start the remediation process. For more information on
the process steps, see Using Manage Imports for Master Data Quality.
Key Features
Upload data from external sources for data quality evaluations
Monitor import processes
Use application log information for import processes
In the Manage Import app, you can use an application log to analyze imports. If the import process does not nish successfully, you can delete the import.
The list of imports provides the following details:
Rule Repository
EvaluationSetting
Import Start Date
Created By
Import Status
 Note
The system provides status information also for those imports that have been deleted.
The system provides application log messages including information on the import status and the start date as well as the start time of the import.
You can display the application log details for one import on a seperate object page.
Delete imports and evaluation runs
To delete one import, you select <Delete> in the list of imports.
You can delete all imports of objects with errors except for those with status Deleted. If you have done so, the system marks the corresponding evaluation run as deleted.
You can delete imports that are assigned to rule repositories with status Created and In process. Imports that are assigned to rule repositories with other statuses
cannot be deleted.
The status Deleted of an import ensures that the administrative information related to that import remains available in the system.
We recommend to not delete imported rule data.
Display rule repository
You can display rule data of a rule repository to check the details of the rules that you need to upload.
When you select the rule repository name in the list of imports, the system displays the rule repository data with the following details:
Rule Version
Version Validity
Created On
Created By
You can lter for Version Validity, Created On, and Created by.
In addition, this app supports the navigation to the master data quality worklist. You can navigate to the import details for one import of objects with errors on a seperate object page
and then choose <Open in Worklist>.
This app uses the C_MDQualityDataImport view.

Desktop
Tablet
Phone

Master Data Quality - Con guration (SAP_CMD_BC_QLTY_CONFIG)
Using the Manage Imports App
Use
5/19/2023
You can use this app to import les of an evaluation run of an external data quality validation tool to display objects with errors in the master data quality worklist. After you have also
imported the rule data that are related to your objects with errors, you can start the remediation process.
Process
1. You can open the application for data import for master data quality.
2. The system presents all existing data import processes.
3. You can create a new data import process for objects with errors or rule data.
4. The system offers the possibility to select an evaluation setting or a rule repository.
5. You can choose an evaluation setting or a rule repository to start the required data import.
6. The system displays detailed data of the evaluation setting or the rule repository.
7. System provides a possibility to upload the le to be imported.
8. You can select a le.
9. If you have selected a le containing objects with errors, the system provides the possibility to enter evaluation run data manually.
Start Remediation Process
Use
With this app, you can start the process for the data quality remediation to validate and correct the products you have selected.
For more information on the process steps, see Using the Start Remediation Process App.
Key Features
Select products to be validated
Validate products
Display validated products
Display number of objects with errors
Transfer objects with errors to the Master Data Remediation Worklist app

Desktop
Tablet

Business Role Template: SAP_BR_PRODMASTER_STEWARD
Master Data Remediation - Product: SAP_CMD_BC_QLTY_PRODUCT_PC
Using the Start Remediation Process App
Process
With the Start Remediation Process app, you can start the process to rst validate and then correct product master data objects with errors.
The result of the validation is transferred to the Master Data Remediation Worklist app. In the Master Data Remediation Worklist, you can monitor product master data objects with
errors and navigate to single processing or mass processing applications to correct the errors.
1. You can enter a description for the remediation process and select the corresponding process template Data Quality Remediation for Products and save the process.
2. You can select the master data objects to be validated.
Manage Remediation Process
Use
With this app, you can manage the process for the data quality remediation to validate and correct the products you have selected.
Key Features
5/19/2023
Finalize remediation process
Delete remediation process
Display audit trail for selected validation process
Navigate to the Start Remediation Process app

Desktop
Tablet

Business Role Template: SAP_BR_PRODMASTER_STEWARD
Master Data Remediation - Product: SAP_CMD_BC_QLTY_PRODUCT_PC
Master Data Remediation Overview
Use
With this app you can get an overview of master data quality issues for products of the last evaluation run. You can drill down to selected products with errors to analyze them and to
remediate them.
The Master Data Remediation Overview app shows aggregated information about master data quality issues for products. It acts as a central navigation point for the access to the
Master Data Remediation Worklist app as well as to analytical drill downs for data analysis. You can navigate to the target application for the remediation process and apply context-
based lters using preselected values from the Master Data Remediation Overview app according to a speci c evaluation setting. The evaluation setting is a mandatory lter
ensuring that only the data of a speci c evaluation setting is displayed. This enables the comparability of the displayed results in the context of the selected setting.
The information is displayed on a set of actionable cards. The Master Data Remediation Overview app displays the aggregated product information about the last evaluation run on
these cards. The Master Data Remediation Overview app offers precon gured content that aggregates the data according to Master Data Remediation speci c attributes, such as
rule violations and remediation status, or object speci c attributes, such as product type and product group. Starting from the Master Data Remediation Overview app, you can use
speci c actions on the cards to drill down to selected products with errors to analyze them according to Master Data Remediation speci c attributes or product related attributes or
a combination of both.
Key Features
Errors Sorted By Remediation Status
This card displays the number of errors in the current evaluation run grouped by the remediation status.
See how many master data quality issues for products are in which remediation status.
Display the corresponding master data quality issues for products in the Master Data Remediation Worklist app.
Errors in the Latest Evaluation Runs
This card displays a trend of the amount of issues in the latest 4 evaluation runs. In addition, this card displays the total number of errors of the current evaluation run as a KPI.
See how many errors there are for every single evaluation run of the latest 4 evaluation runs.
Display the corresponding master data quality issues for products in the Master Data Remediation Worklist app.
Products with Errors: Top 3
This card displays 3 products that have assigned the highest number of errors of all products with errors in the current evaluation run. In addition, this card displays the total
number of products with errors.
See how many errors are assigned to the top 3 products with errors.
Display the corresponding products with errors in the Master Data Remediation Worklist app.
Drill down to a selected product with errors to analyze it according to product related attributes.
Rule Violations: Top 3
This card displays 3 rules that have been violated most often in the current evaluation run. In addition, this card displays the total number of violated rules.
See how many times the most often violated rules have not been taken into account correctly.
Display the corresponding rules in the Master Data Remediation Worklist app.
Drill down to a selected violated rule to analyze it according to Master Data Remediation speci c attributes.
Errors Sorted by Product Attributes: Top 4
This card displays the number of errors grouped by product attribute Division, Product Type or Product Group according to your setting.
See how many errors occured in the current evaluation run grouped by product attribute Division, Product Type or Product Group.
Drill down to a selected error according to your product attribute setting to analyze it.
5/19/2023
Desktop
Tablet
App Extensibility: Master Data Quality Worklist Apps
Use
You cannot extend Master Data Quality Worklist apps.
More Information
For a general description of the extensibility options and procedures of SAP Fiori apps, see Extend SAP Fiori Apps.
Delete Evaluation Data and Import Data
Use
With the report MDQ_DELETE_EVALUATION_DATA, you can delete evaluation run data for the evaluation setting you have entered, using the following options:
Key Features
Delete Selected Evaluation Run
Delete All Evaluation Runs
Delete Evaluation Setting and All Evaluation Runs
Delete Rule Repository and Subordinate Objects
For more information, see the report documentation of MDQ_DELETE_EVALUATION_DATA.
Use
With the report MDQ_DELETE_IMPORT_DATA, you can delete import data using the following options::
Key Features
Delete data for the available GUID
Delete data for imports of the available user who created the import.
For more information, see the report documentation of MDQ_DELETE_IMPORT_DATA.
Data Quality Remediation Process
Use
MDG ensures that standards are observed when master data are created and changed. If master data do not comply with these changing standards, then these objects with errors
can be identi ed with data quality services. With a data quality tool or your own implementation these problems can be solved.
The data quality remediation (DQR) provides the process integration of identifying master data objects with errors in a data quality tool as the SAP Information Steward, for
example, and their correction in Master Data Governance (MDG). In order to use this process, you additionally need to implement a tool that is not part of the delivery of Master
Data Governance.
Process
1. A data quality tool analyzes master data according to a set of validation rules to detect objects with errors. This can be done in a periodical batch run, based on master data
that was previously loaded from MDG systems and other systems.
2. Typically the master data specialist wants to identify the objects with errors with the highest priority or with similar quality issues. In order to support this, a data quality tool
might offer the ltering of the objects with errors according to a rule (or a set of rules). MDG allows the master data specialist to select the criteria for the ltering that is
done by the data quality tool. Alternatively, MDG can integrate a data quality tool speci c UI that allows to select criteria for ltering. The MDG DQR retrieves the objects with
errors and displays them for investigation by the master data specialist.
3. The master data specialist selects an object with errors and creates a change request for data quality remediation. With the data quality remediation process is also possible
to create multiple change requests at once, one for each of the selected objects. Additionally, one change request can be used for multiple objects.
5/19/2023
Integration Topics
This section provides information about integration options of MDG with other solutions.
Integration of MDG-S with SAP Ariba Supplier Lifecycle and Performance

When using SAP Ariba Supplier Lifecycle and Performance and Master Data Governance for Supplier (MDG-S), supplier master data needs to be exchanged between both solutions.
In this documentation, best-practice integration scenarios are described ensuring that supplier master data is synchronized between SAP Ariba Supplier Lifecycle and Performance
and MDG-S.
For a description of different integration scenarios, see Integration Scenarios .
For the con guration steps required for this integration, see Integrating SAP MDG-S with SAP Ariba Supplier Lifecycle and Performance.
Integration Scenarios
The documents below provide examples of how to use SAP Master Data Governance for Supplier (MDG-S) and SAP Ariba Supplier Lifecycle and Performance (SLP) in different
integration scenarios.
There are two variants each for the rst three scenarios. These are based on whether the replication of a potential supplier is done a) during the request of a new supplier, or b) upon
registration/quali cation of a new supplier. If you prefer potential suppliers that are created in SLP to be part of your master data management, you can select option a) replication
during supplier request. If you chose option b), potential suppliers are replicated to SAP MDG only after the potential supplier is registered and/or quali ed in SAP Ariba SLP.
 Note
For scenarios 1-3, MDG, consolidation is used for new business partners that arrive from SLP. Only with consolidation, detected duplicates can be properly handled on MDG side,
and the result can be synchronized with SLP. This includes not only the detection of duplicates in MDG, but also
merging the duplicate with the best record including the merger of attributes, and
replicating the result to SLP including key mapping.
If you don’t use MDG, consolidation but only MDG, central governance, you can only use the duplicate check to detect a duplicate. Then, however, merging both business partners
and replicating the merged result back to SLP is not possible. An incoming business partner, although it might be a duplicate, then has to continue to exist in both MDG and SLP.
For this reason, we strongly recommend you use MDG, consolidation for new business partners arriving from SLP from the beginning.
The following scenarios are described:
Scenario 1a: New supplier in SLP, no duplicate in MDG - replication during request
Scenario 2a: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication during request
Scenario 3a: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication during request
A step-by-step description of these scenarios can be found here:
Scenarios 1a, 2a, 3a: Step-by-step description
Scenario 1b: New supplier in SLP, no duplicate found in MDG - replication upon registration / quali cation
Scenario 2b: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication upon registration / quali cation
Scenario 3b: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication upon registration / quali cation
Scenarios 1b, 2b, 3b: Step-by-step description
Scenario 4: Change supplier in MDG
Scenario 5: Change supplier in SLP
Scenario 6: Create supplier in MDG
Scenarios 4, 5, 6: Step-by-step description
Scenario 7: Merge two active suppliers in MDG
A step-by-step description of this scenario can be found here:
Scenario 7: Step-by-step description
Overview: Scenarios 1a-7

The documents below provide an overview of the following integration scenarios:
5/19/2023
Scenario 2a: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication during request
Scenario 3a: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication during request
Scenario 1b: New supplier in SLP, no duplicate found in MDG - replication upon registration / quali cation
Scenario 2b: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication upon registration / quali cation
Scenario 3b: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication upon registration / quali cation
This scenario shows what happens when a new supplier is requested in SLP, and no duplicate for the supplier is found in MDG.
5/19/2023
1. A new supplier is requested in SLP, and the supplier request is approved
2. The supplier request work ow transfers the data to MDG for validation as part of the MDGS validation step.
3. In MDG, a consolidation process is automatically created and started. No duplicates are found,...
4. ...and the supplier is created in MDG. The key mapping between the supplier ID in SLP and the Business Partner ID in MDG is created.
5. The supplier is replicated from the MDG hub to SLP and to the operational ERP, and - based on the con rmation - key mapping between the business partner ID in MDG and
the operational ERP is created in MDG.
6. In SLP, the creation of the supplier is completed upon replication from MDG. Depending on the SLP con guration, the supplier can be used further to manage the supplier
lifecycle, and for transactional purposes depending on the customer’s buying policy.
Scenario 2a: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication
during request
This scenario shows what happens when a new supplier is requested in SLP, a duplicate for the supplier is found in MDG, and the business partner does not yet exist in SLP.
5/19/2023
1. A new supplier is requested in SLP. The supplier request is approved, and...
2. ...the supplier request work ow transfers the data to MDG for validation as part of the MDGS validation step.
3. In MDG, a consolidation process is automatically created and started. In the matching step, the supplier replicated from SLP is recognized as a duplicate of a business partner
that already exists in MDG. For example, this can be a customer that is not known in SLP. MDG creates a best record by merging the data of both business partners,...
4. ...and the existing business partner is updated. The key mapping of the existing business partner in MDG is enhanced by the SLP supplier ID.
5. The supplier is then replicated from the MDG hub to all connected client systems including SLP.
6. In SLP, the creation of the supplier is completed upon replication from MDG.
Scenario 3a: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication
during request
This scenario shows what happens when a new supplier is requested in SLP that already exists in SLP, and MDG recognizes the supplier as a duplicate of a business partner in MDG.
5/19/2023
1. A new supplier is requested in SLP as a duplicate of an already existing SLP supplier, for example because the user did not search for it or did not nd the existing supplier
when searching, or because the user ignored the duplicate warning message when creating the supplier request in SLP.
2. In SLP, the supplier request is approved, and the supplier request work ow transfers the data to MDG for validation as part of the MDGS validation step.
that already exists in MDG. MDG creates a best record by merging the data of both business partners,...
4. ...and the existing business partner is updated. The key mapping of the existing business partner in MDG is enhanced resulting in two mappings towards SLP suppliers, which
means both SLP suppliers will be updated based on the MDG business partner.
5. The supplier data is replicated to all connected client systems including SLP.
6. In SLP, the work ow ends when the replication from MDG is received, and the requestor is asked to use the already existing supplier. The newly created duplicate supplier is
updated and deactivated, and the already existing supplier is updated with the best record data from the MDG hub.
Scenario 1b: New supplier in SLP, no duplicate found in MDG - replication upon registration /
quali cation
This scenario shows what happens when a new supplier is requested in SLP, and no duplicate for the supplier record is found in MDG. Unlike scenario 1a, the supplier record is
replicated to MDG upon registration or quali cation of the supplier.
5/19/2023
1. A new supplier registers in the Ariba Network and responds to the buyer-speci c registration questionnaire. The buyer then approves the supplier registration information in
SLP and proceeds with the supplier quali cation process as needed. Based on the con guration de ned by the buyer of how to replicate the supplier, which is either upon
registration or upon quali cation,...
2. ...the new supplier is replicated from SLP to MDG.
3. In MDG, a consolidation process is automatically created and started. No duplicates are found,...
4. ...and the supplier is created in MDG. The key mapping between the supplier ID in SLP and the business partner ID in MDG is created.
5. The supplier is replicated from the MDG hub to all connected client systems including SLP, and - based on the con rmation - key mapping between the business partner ID in
MDG and the operational ERP is created in MDG.
6. In SLP, the supplier data and the MDG ID are stored.
Scenario 2b: New supplier in SLP, duplicate found in MDG, BP not yet in SLP - replication
upon registration / quali cation
This scenario shows what happens when a new supplier is requested in SLP, a duplicate for the supplier is found in MDG, and the business partner does not yet exist in SLP. Unlike
scenario 2a, the supplier record is replicated to MDG upon registration or quali cation of the supplier.
5/19/2023
1. A new supplier registers in the Ariba Network and responds to the buyer-speci c registration questionnaire. The buyer then approves the supplier registration information in
2. ...the new supplier is replicated from SLP to MDG.
3. In MDG, a consolidation process is automatically created and started. In the matching step, the supplier replicated from SLP is recognized as a duplicate of a Business Partner
that already exists in MDG. For example, this can be a customer that is not known in SLP. MDG creates a best record by merging the data of both business partners,...
4. ...and the existing business partner is updated. The key mapping of the existing business partner in MDG is enhanced by the SLP supplier ID.
5. The supplier is then replicated from the MDG hub to all connected client systems including SLP.
6. In SLP, the creation of the supplier is completed upon replication from MDG.
Scenario 3b: New supplier in SLP, duplicate found in MDG, BP already in SLP - replication
upon registration / quali cation
This scenario shows what happens when a new supplier is requested in SLP that already exists in SLP, and MDG recognizes the supplier as a duplicate of a business partner in MDG.
Unlike scenario 3a, the supplier record is replicated to MDG upon registration or quali cation of the supplier.
5/19/2023
1. A new supplier registers in the Ariba Network, and responds to the buyer-speci c registration questionnaire. The buyer then approves the supplier registration information in
2. ...the new supplier is replicated from SLP to MDG. In this case, the new supplier record is a duplicate of an already existing SLP supplier.
that already exists in MDG.
4. MDG creates a best record by merging the data of both business partners,...
5. ...and the existing business partner is updated. The key mapping of the existing business partner in MDG is enhanced resulting in two mappings towards SLP suppliers, which
means both SLP suppliers will be updated based on the MDG business partner.
6. The supplier data is replicated to all connected client systems including SLP.
7. In SLP, the requestor is asked to use the already existing supplier. The newly created duplicate supplier is updated and deactivated, and the already existing supplier is updated
with the best record data from the MDG hub.
5/19/2023
This scenario shows what happens when a supplier is changed in MDG.
1. An existing business partner with supplier role is changed and activated in the MDG hub using a change request.
2. The changed business partner is then automatically replicated from MDG to all connected client systems including SLP.
5/19/2023
This scenario shows what happens when a supplier is changed in SLP.
1. A supplier updates their existing supplier record in the Ariba Network, and the change is approved in SLP.
2. The changed record is sent to MDG.
3. In MDG, the change request process is triggered, and a master data specialist veri es and approves the record.
4. Once the record is activated in MDG, it is replicated to all connected client systems including SLP.
5/19/2023
This scenario shows what happens when a supplier is created in MDG.
1. The creation of a new supplier is requested in MDG. The central governance work ow is triggered, the request is processed, and the new supplier record is activated.
2. MDG then replicates the data to all client systems including SLP.
5/19/2023
This scenario shows what happens when two active suppliers are merged in MDG.
1. A user scans all business partners in MDG for duplicates using the Remove Duplicates consolidation strategy. Two business partners are recognized as duplicates, so MDG
merges the data of both business partners and combines the key mapping information to create a best record. This means from now on the mapped records in SLP and ERP -
two on SLP side, and two on ERP side - will be updated based on the best record.
2. MDG then replicates the data to all client systems including ERP and SLP. In ERP, both existing suppliers are kept because transactional data might exist. One of the suppliers
can be archived at a later point. In SLP, both suppliers are kept, and both refer to the same business partner in MDG. The duplicate supplier is deactivated in SLP.
Step-by-Step Descriptions: Scenarios 1a-7

The documents below provide a detailed description of the integration scenarios.
Scenarios 1a, 2a, 3a: Step-by-step description

5/19/2023
This document provides a step-by-step description of three of the scenarios of the integration of SAP Master Data Governance for Supplier (MDG-S, hereinafter referred to as MDG)
and SAP Ariba Supplier Lifecycle and Performance (hereinafter referred to as SAP Ariba):
 Note
There are two points at which the new supplier can be replicated to MDG: during the request, and after the registration / quali cation in SAP Ariba. This document describes the
scenarios when the replication is carried out during the request. For a description of the replication after the registration / quali cation, see Scenarios 1b, 2b, 3b: Step-by-step
description.
Scenario 1a: New supplier created in SAP Ariba – no duplicate found in MDG
Scenario 2a: New supplier created in SAP Ariba – duplicate found in MDG, BP does not yet exist in SAP Ariba
Scenario 3a: New supplier created in SAP Ariba – duplicate found in MDG, BP already exists in SAP Ariba
Scenario 1a: New Supplier Created in SAP Ariba - No Duplicate Found in MDG
1. Create new Supplier Request in SAP Ariba
a. Create Supplier Request in SAP Ariba
Log on to SAP Ariba. Select the Supplier Management tab to open the Supplier Management work center. Choose Create, and choose Supplier Request.
b. Fill in the Supplier Request form, for example, enter the supplier name, address, and primary contact details including an e-mail address. An invitation e-mail will be
sent to this e-mail address once the supplier has been created.
Choose Submit, then choose Close.
The supplier request submission is now in progress. Once it is complete, you can view the submitted request.
c. In the supplier list, choose View for the supplier you requested. In the approval form, select Approve, optionally enter a reason for approval, and select Con rm
approval. The current work ow step in SAP Ariba is MDGS Validation.
2. Supplier Replication (MDG-S Validation)
Upon approval of the supplier in SAP Ariba, the replication to MDG is triggered automatically with an outbound SOA message, and a consolidation process for the new supplier
is created in MDG. Once the consolidation is complete, MDG sends an inbound SOA message to SAP Ariba to activate the supplier in SAP Ariba
a. To check the status of your SAP Ariba work ow, in the Supplier Management work center, choose View for your supplier request.
b. To check the progress of the replication, in the Supplier Management work center in SAP Ariba, select Manage SM Administration . Select ERP Integration Status,
and check the outbound messages. The outbound message of type Request_In is displayed in the list. The status is Completed. The new supplier ID is displayed in the
SM Vendor ID column.
Note down the supplier ID for future reference.
c. To display the details for the supplier, select the SM Vendor ID. The summary screen shows the registration status as Pending External Approval, the quali cation status
as Not Quali ed, and the ERP integration status as In Progress.
d. You can also check the replication progress in MDG. To do so, run transaction srt_moni in the MDG system.
3. Consolidation in MDG
 Note
You can con gure the consolidation process to determine whether it runs automatically and under which conditions a manual review is required.
 Note
The behavior of MDG depends on the con guration of the consolidation process. Depending on the con guration, the number of steps varies, and affects whether the
system stops between steps. In the examples below, the process foresees which steps are carried out, and includes a stop between each step.
 Note
The central governance tiles mentioned below are only integrated into the Fiori Launchpad in MDG on S/4HANA. If you are using MDG 9.2 on ECC, to access the central
governance apps, run transaction NWBC and use the corresponding workcenter in the NetWeaver Business Client.
a. In MDG, open the Fiori Launchpad. Under Consolidation for Business Partner Data, select the Manage Consolidation Processes - Business Partners tile. In the
processes list, the consolidation process for your supplier request is displayed with the SAP Ariba business system ID as data source. The process status is Stopped for
Review (Initial Check).
b. Select the process to open the process details. You can display and edit the details of the record by selecting Show Result. Carry out all the consolidation process steps
until the consolidation is completed. Since there are no duplicates, no match groups are created. A change request for the business partner is created in MDG.
 Note
The system settings for the Activation step were adjusted to determine that a change request is created after the consolidation. This was done so subsequent processors
have the option of adding purchasing and nancial data to the supplier record.
4. Approve Change Request in MDG
a. To open the change request, launch the Change Request Inbox app from the Fiori launchpad or, for S/4HANA release 1909 and higher, click on the KPI chart in the
activation step, choose Show Details, select the change request link, and open the change request. Check the data, which contains the details that were entered in SAP
Ariba. You can edit the data, for example, you can add a company code and purchasing organization details. To approve the change request once you're done, choose
Done, and choose Approve. The business partner is created in MDG and the supplier is automatically replicated to SAP Ariba.
5/19/2023
The change request status is Final Check Approved, and the Business Partner ID created in MDG is displayed under Business Partner Details General Data . Note
down this ID for future reference.
b. To review the supplier data and check the replication status in MDG, launch the Manage Supplier Governance app from the Fiori Launchpad, and search for the
Business Partner ID you noted down earlier. To display the business partner details, select the business partner in the search result list. To display the replication status,
select the business partner in the search result list, and choose Replication Status.
5. Supplier Registration
 Note
This step is provided as an additional step as part of this detailed description. It is not part of the shorter scenario overview (diagram and video).
a. In SAP Ariba, select the Supplier Management tab to open the Supplier Management work center.
To check the supplier data, select View for your supplier. Select the SAP Ariba work ow, and choose View Supplier Pro le. Select ERP data. Under General, you can, for
example, expand the Vendor Information node, and select Integration Status and ERP Vendor ID to verify the data.
b. To send an invitation to the supplier, select Registration, and select Invite. On the Invite to register screen, the supplier registration questionnaire is automatically
pre lled. To send an invitation to the e-mail address you entered when requesting the supplier, select Send. The registration status is now Invited.
Once the supplier receives the invitation with a registration link, they can register on the Ariba Network. The pro le information in the questionnaire is pre lled based
on the already existing data. The supplier can complete the form with additional data, and select Create account and continue to continue with the registration. The
supplier then receives a registration con rmation by e-mail containing their ID and username. Alternatively, the supplier can use their existing Ariba Network account to
log in.
Once the supplier registration questionnaire is approved in SAP Ariba, the system triggers a replication to MDG. The replication to MDG is triggered because the
supplier data was changed due to the registration of the supplier.
In MDG, a change request is created because the system settings determine that a change request is created if the data of an existing supplier in MDG changes.
c. To check the supplier status, in the supplier pro le, choose Summary. You can see the registration status, the quali cation status, and the ERP integration status. After
approval of the supplier registration, the outbound message is automatically triggered and the integration status will change from Integrated to In Process based on
the con guration in SAP Ariba under Manage SM Administration ERP integration status Initial supplier synchronization .
d. To check the ERP integration message status, choose Manage SM Administration , select ERP Integration Status, and check the outbound messages. Once the
replication has been triggered, the outbound message of type Request_In with the status Completed is displayed, and the supplier ID is listed in the SM Vendor ID
column.
e. To approve the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad, and open the change request. Choose Approve. The business
partner is automatically replicated to SAP Ariba.
f. To check the supplier data in SAP Ariba, open the Supplier Management work center, and choose View for your supplier. Choose ERP data, and open the General tab.
Expand the relevant nodes to verify the data.
Scenario 2a: New Supplier Created in SAP Ariba - Duplicate Found in MDG, Business Partner does not yet exist in SAP Ariba
0. Preparation: Create Business Partner with Customer Role in MDG
 Note
This is a preparatory step for the data in MDG. It is not part of the actual integration scenario.
a. To create a new customer in MDG, launch the Manage Customer Governance app from the Fiori launchpad. If required, select a change request type. Enter a change request
description, and enter data for the new customer. To submit the change request, choose Submit. Approve the change request. Choose Refresh, and note down the Business Partner
ID that was created for the new customer.
b. To check the replication status in MDG, search for the Business Partner ID you noted down in the previous step, select the business partner in the search result list, and choose
Replication Status. The status is green, and the Object ID of the business partner and the ERP customer created in the Operational ERP client system are shown. In this case, the
business partner was not replicated to SAP Ariba because based on the lter settings, only business partners with vendor role and a supplier data segment are replicated to SAP
Ariba.
1. Create New Supplier Request in SAP Ariba
a. To create a new supplier request in SAP Ariba, carry out the steps described under Scenario 1, section 1a - 1c considering the following: In the supplier request form,
enter the same name and address you entered for the customer created in MDG in the preparation step above. This will later lead to a match with an existing business
partner in the consolidation process in MDG
2. Supplier Replication
a. To check the ERP integration message status, choose Manage SM Administration , select ERP Integration Status, and check the outbound messages. Once the
column. Note down the supplier ID.
b. To check the supplier status, in the supplier pro le, choose Summary. The registration status is Pending External Approval, the quali cation status is Not Quali ed, and
the ERP integration status is In Progress.
a. In MDG, open the Fiori Launchpad. Under Consolidation for Business Partner Data, launch the Manage Consolidation Processes - Business Partners app. In the
processes list, the consolidation process for your supplier request with the SAP Ariba business system ID as data source is displayed. The process status is Stopped for
b. Select the process to open the process details. You can display and edit the details of the record by selecting Show Result. Carry out the consolidation process steps up
to the Matching step.
5/19/2023
c. Choose Match Review, and select the match group. Choose Back to navigate to the process overview. The process status is Stopped for Review (Matching).
The KPI chart shows that an approved match group consisting of two records was created. MDG recognized the supplier created in SAP Ariba as a potential duplicate of
an active business partner record in the MDG hub.
d. To carry out the Best Record Calculation, choose Continue. The process status is Stopped for Review (Best Record Calculation). The KPI chart shows an updated
record.
e. You can display or change the Best Record. To do so, choose Show Result. In the Overview table, select the Best Record, and choose Review. You can make changes to
the Best Record by choosing Edit. To con rm and activate the data, choose Save. To navigate back to the process overview, choose Back.
The active business partner record in MDG is updated with the data of the supplier created in SAP Ariba.
f. To nalize the consolidation process, carry out the remaining process steps. If you are working with S/4HANA release 1909 or higher, click on the KPI chart in the
activation step, and choose Show Details. The process is now completed, and the KPI chart shows an updated record with the activation target Change Request. The
Business Partner ID you noted down earlier is displayed in the columns Source ID and Business Partner.
 Note
The system settings for the Activation step were adjusted to determine that a change request is created after the consolidation. This was done so subsequent
processors have the option of adding purchasing and nancial data to the supplier record.
g. To approve the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad or, for newer releases, select the change request link, and open
the change request. The data you entered in the supplier request in SAP Ariba is part of the data in this change request. You can make changes or add data. To do so,
choose Edit, and add details, e.g. the company code and the purchasing organization. One you’re done, choose Done, and choose Approve. The business partner is
automatically replicated to SAP Ariba. Choose Refresh. The change request is displayed as Final Check Approved. Note down the Business Partner ID.
h. To check the supplier data in MDG, launch the Manage Supplier Governance app from the Fiori launchpad. Search for the Business Partner ID you noted down in
preparation step 0a of scenario 2, and open the business partner details. The data corresponds to the best record you reviewed earlier. The changes you made during
the consolidation and change request process are re ected.
a. To check the replication status, in the Fiori Launchpad that is connected to the MDG Hub system, under Supplier Governance, launch the Manage Supplier Governance
app. Search for the Business Partner ID you noted down in preparation step 0a of scenario 2, select the business partner in the search result list, and select Replication
Status. The replication status is displayed, as well as the Object IDs of the business partner and the ERP Vendor that were updated in the Operational ERP client.
a. To check the supplier data in SAP Ariba, select the Supplier Management tab to open the Supplier Management work center. Choose View Supplier Pro le for your
supplier. Select ERP data. Under General and Company Code you can, for example, expand the relevant nodes and verify the data. The supplier you created earlier in
this scenario has been overwritten with the data from the best record created in MDG.
b. To register the supplier, carry out the steps described in steps 5a - c (Supplier Registration) of scenario 1.
Scenario 3a: New Supplier Created in SAP Ariba - Duplicate Found in MDG, BP already exists in SAP Ariba
a. To create a new supplier request in SAP Ariba, carry out the steps described in section 1 of scenario 1 considering the following: In the supplier request form, enter the
same name and address as you entered for the supplier in the preparation step 1 of scenario 2. This will lead to a match with the existing business partner in the
consolidation process in MDG.
a. To check the ERP integration message status in SAP Ariba, choose Manage SM Administration , select ERP Integration Status, and check the outbound messages.
Once the replication has been triggered, the outbound message of type Request_In with the status Completed is displayed, and the supplier ID is listed in the SM
Vendor ID column. Note down the supplier ID.
b. To check the supplier status, select the supplier ID link. In the summary screen, the registration status is Pending External Approval, the quali cation status is Not
Quali ed, and the ERP integration status is In Progress.
b. To carry out the matching and the match review, select the process to open the process details. Carry out the consolidation process steps up to the Matching step.
Choose Match Review, and review the match group. The match group contains two records, as MDG has recognized the supplier from SAP Ariba as a potential
duplicate of an active business partner with customer role in MDG. Choose Back to navigate to the process overview.
c. To carry out the Best Record Calculation, choose Continue. The process status is Stopped for Review (Best Record Calculation). The KPI chart shows an updated
record.
d. You can display or change the Best Record. To do so, choose Show Result. In the Overview table, select the Best Record, and choose Review. You can make changes to
the Best Record by choosing Edit. To con rm and activate the data, choose Save. To navigate back to the process overview, choose Back. The active business partner
record in MDG is updated with the data of the supplier created in SAP Ariba.
e. To nalize the consolidation process, carry out the remaining process steps. If you are working with S/4HANA release 1909 or higher, click on the KPI chart in the
activation step, and choose Show Details. The process is now completed, and the KPI chart shows an updated record wiith the activation target Change Request.
 Note
f. To process the change request, open the change request. To do so, launch the Change Request Inbox app from the Fiori launchpad or, for newer releases, select the
change request link, select the Business Partner ID entry in the Objects table, and select Single Processing. You can make changes to the data. To approve the change
request, choose Approve. Choose Refresh, and note down the Business Partner ID. The business partner replication to SAP Ariba is triggered automatically.
5/19/2023
g. To check the supplier data in MDG, launch the Manage Supplier Governance app from the Fiori launchpad, and search for the Business Partner ID you noted down in in
the preparation step 0 of scenario 2. Select the business partner description link. The business partner details are displayed. The data corresponds to the best record
data you reviewed and edited in step 3d of this scenario. The changes you made in the consolidation process and in the change request are re ected.
a. To check the replication status, in the Fiori launchpad, under Supplier Governance, launch the Manage Supplier Governance app. Search for Business Partner ID you
noted down in the preparation step 0 of scenario 2. Select the business partner in the search result list, and select Replication Status. The replication status is green.
The business partner in MDG points to two suppliers in SAP Ariba. The Object IDs of two suppliers in SAP Ariba are displayed. The Object IDs of the business partner
and the ERP Vendor that were updated in the Operational ERP client are displayed.
5. Supplier Deactivation in SAP Ariba
After the replication from MDG, the supplier request work ow in SAP Ariba is stopped at the MDG-S validation step and the system displays a message asking you to use the
existing supplier. The requester is also noti ed about the duplicate record by email.
a. In SAP Ariba, select the Supplier Management tab to open the Supplier Management work center. Choose Manage SM Administration , and click on Inactive
Suppliers in the menu on the left. Search for the supplier ID you noted down in section 2a of scenario 3. The system shows the supplier in the list of inactive suppliers,
because another supplier refers to the same MDG ID, and SAP Ariba deactivated the new supplier.
b. To check the data of the original supplier in SAP Ariba, in the Supplier Management, search for the supplier ID you noted down in section 3a of scenario 2. In the supplier
pro le, choose ERP data. Expand the relevant nodes under General. The supplier data was overwritten with the best record data from the MDG hub. The data of the
original and duplicate suppliers in SAP Ariba corresponds to the best record supplier data in MDG.
Scenarios 1b, 2b, 3b: Step-by-step description

This document provides a step-by-step description of three of the scenarios of the integration of SAP Master Data Governance for Supplier (MDG-S, hereinafter referred to as MDG)
and SAP Ariba Supplier Lifecycle and Performance (hereinafter referred to as SAP Ariba):
 Note
There are two points at which the new supplier can be replicated to MDG: during the request, and after the registration / quali cation in SAP Ariba. This document describes the
scenarios when the replication is carried out after the registration / quali cation. For a description of the replication during request, see Scenarios 1a, 2a, 3a: Step-by-step
description.
Scenario 1b: New supplier created in SAP Ariba, no duplicate found in MDG
Scenario 2b: New supplier created in SAP Ariba – duplicate found in MDG, BP does not yet exist in SAP Ariba
Scenario 3b: New supplier created in SAP Ariba – duplicate found in MDG, BP already exists in SAP Ariba
Scenario 1b: New Supplier Created in SAP Ariba - No Duplicate Found in MDG
1. Create new Supplier Request in SAP Ariba
a. Create Supplier Request in SAP Ariba
Log on to SAP Ariba. Select the Supplier Management tab to open the Supplier Management work center. Choose Create, and choose Supplier Request.
b. Fill in the Supplier Request form, for example, enter the supplier name, address, and primary contact details including an e-mail address. An invitation e-mail will be
sent to this e-mail address once the supplier has been created.
Choose Submit, then choose Close.
The supplier request submission is now in progress. Once it is complete, you can view the submitted request.
c. In the supplier list, choose View for the supplier you requested. In the approval form, select Approve, optionally enter a reason for approval, and select Con rm
approval. Choose Done.
b. To open the supplier pro le, select View for your supplier. Select the SAP Ariba work ow, and choose View Supplier Pro le. Select ERP Data. Check the data and note
down the SM Vendor ID.
c. Choose Registration, and choose Invite. On the Invite to register screen, the supplier registration questionnaire is automatically pre lled. To send an invitation to the e-
mail address you entered when requesting the supplier, select Send.
d. Once the supplier receives the invitation with a registration link, they can register on the Ariba Network. The pro le information in the questionnaire is pre lled based
on the already existing data. The supplier can complete the form with additional data. To send an invitation to the supplier, select Create account and continue to
continue with the registration. The supplier then receives a registration con rmation by e-mail containing their ID and username. Alternatively, the supplier can use
their existing Ariba Network account to log in.
e. Once the supplier registration questionnaire is approved in SAP Ariba, the system triggers a replication to MDG.
f. To check the supplier status, in the supplier pro le, choose Summary.
a. To check the ERP integration message status, choose Manage SM Administration . Select ERP Integration Status, and check the outbound messages. Once the
column.
4. Consolidation and Change Request Processing in MDG
5/19/2023
 Note
You can con gure the consolidation process to determine whether it runs automatically and under which conditions a manual review is required.
 Note
The behavior of MDG depends on the con guration of the consolidation process. Depending on the con guration, the number of steps varies, and affects whether the
system stops between steps. In the examples below, the process foresees which steps are carried out, and includes a stop between each step.
 Note
b. Select the process to open the process details. You can display and edit the details of the record by selecting Show Result. You can add new values or change existing
ones. To nalize the consolidation process, carry out all the consolidation process steps until the consolidation is completed. Since there are no duplicates, no match
groups are created. A change request for the business partner is created in MDG.
 Note
c. To open the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad or, for S/4HANA release 1909 and higher, click on the KPI chart in
the activation step, choose Show Details, select the change request link, and open the change request. In collective processing, under Objects, select the Business
Partner ID entry. Choose Single Processing.
d. Check the data in the change request. The data that was entered in the supplier request and registration questionnaire in SAP Ariba is displayed. To navigate do ERP
Vendor speci c data, in the ERP Vendors table, choose Edit. You can edit the data, for example, you can add a company code and purchasing organization details. When
you're nished, choose Done.
e. To approve the change request, choose Approve. The business partner is created in MDG and the supplier is automatically replicated to SAP Ariba.
The change request status is Final Check Approved, and the Business Partner ID created in MDG is displayed under Business Partner Details General Data . Note
down this ID for future reference.
f. To check the supplier data in MDG, launch the Manage Supplier Governance app from the Fiori launchpad. Enter the Business Partner ID you noted down in the
previous step, and choose Search. To open the supplier details, select the business partner description link. The business partner data corresponds to the supplier data
that was entered in SAP Ariba. The changes made in the MDG consolidation process and change request are re ected.
a. To check the replication status in MDG, launch the Manage Supplier Governance app. Search for the Business Partner ID you noted down in step 4e. Select the
business partner in the search result list, and choose Replication Status. Note down the ERP Vendor ID that was created in the ERP operational client. The replication
status is green, the Object ID of the supplier that was updated in SAP Ariba is displayed. The Object IDs of the business partner and the ERP Vendor that were created
in the Operational ERP client are displayed.
b. To check the supplier data in SAP Ariba, in the Supplier Management work center, search for the supplier ID you noted down in step 2b. Select ERP data. Under General,
you can, for example, expand the Company code node, and verify the data. The changes you made in the consolidation process and in the change request in MDG were
replicated and are re ected.
Scenario 2b: New Supplier Created in SAP Ariba - Duplicate Found in MDG, BP does not yet exist in SAP Ariba
0. Preparation: Create Business Partner with Customer Role in MDG
 Note
a. To create a new customer in MDG, launch the Manage Customer Governance app from the Fiori launchpad. If required, select a change request type. Enter a change request
description, and enter data for the new customer. To submit the change request, choose Submit. Approve the change request. The data is automatically replicated to SAP Ariba.
Choose Refresh, and note down the Business Partner ID that was created for the new customer.
b. To check the replication status in MDG, search for the Business Partner ID you noted down in the previous step, select the business partner in the search result list, and choose
Replication Status. The status is green, and the Object ID of the business partner and the ERP customer created in the Operational ERP client system are shown. In this case, the
business partner was not replicated to SAP Ariba because based on the lter settings, only business partners with vendor role and a supplier data segment are replicated to SAP
Ariba.
a. To create a new supplier request in SAP Ariba, carry out the steps described under Scenario 1, section 1a - 1c considering the following: In the supplier request form,
enter the same name and address you entered for the customer created in MDG in the preparation step above. This will later lead to a match with an existing business
partner in the consolidation process in MDG
a. Carry out the steps described in sections 2a - 2g of scenario 1.
5/19/2023
4. Consolidation and Change Request Processing in MDG
b. Select the process to open the process details. Carry out all the consolidation process steps up to the matching step.
c. Choose Match ReviewBack to navigate to the process overview. The process status is Stopped for Review (Matching). The KPI chart shows that an approved match
group consisting of two records was created. MDG recognized the supplier created in SAP Ariba as a potential duplicate of an active business partner record in the
MDG hub.
record.
e. You can display or change the Best Record. To do so, choose Show Result. In the Overview table, select the Best Record, and choose Review. You can make changes to
the Best Record by choosing Edit. To con rm and activate the data, choose Save. To navigate back to the process overview, choose Back.The active business partner
f. To nalize the consolidation process, carry out the remaining process steps. If you are working with S/4HANA release 1909 or higher, click on the KPI chart in the
activation step, and choose Show Details. The process is now completed, and the KPI chart shows an updated record with the activation target Change Request. The
Business Partner ID you noted down earlier is displayed in the columns Source ID and Business Partner.
 Note
g. To open the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad or, for newer releases, select the change request link. The data you
entered in the supplier request and the registration questionnaire in SAP Ariba is part of the data in this change request. You can make changes or add data. To do so,
choose Edit, and add details, e.g. the company code and the purchasing organization. One you’re done, choose Done, and, to approve the change request, choose
Approve. The business partner is automatically replicated to SAP Ariba. Choose Refresh. The change request is displayed as Final Check Approved, and select the
match. Note down the Business Partner ID.
h. To check the supplier data in MDG, launch the Manage Supplier Governance app from the Fiori launchpad. Search for the Business Partner ID you noted down in
preparation step 0a of scenario 2, and open the business partner details. The data corresponds to the best record you reviewed earlier. The changes you made during
the consolidation process and in the change request are re ected.
a. To check the replication status, in the Fiori Launchpad that is connected to the MDG Hub system, under Supplier Governance, launch the Manage Supplier Governance
app. Search for the Business Partner ID you noted down in preparation step 0a of scenario 2, select the business partner in the search result list, and select Replication
Status.
b. To check the supplier data in SAP Ariba, select the Supplier Management tab to open the Supplier Management work center. Choose View for your supplier, and choose
View Supplier Pro le. Select ERP data. Under General and Company Code you can, for example, expand the relevant nodes and verify the data. The supplier you
created earlier in this scenario has been overwritten with the data from the best record created in MDG.
Scenario 3b: New Supplier Created in SAP Ariba - Duplicate Found in MDG, BP already exists in SAP Ariba
a. To create a new supplier request in SAP Ariba, carry out the steps described in section 1 of scenario 1 considering the following: In the supplier request form, enter the
same name and address as you entered for the supplier in the preparation step 0 of scenario 2. This will lead to a match with the existing business partner in the
consolidation process in MDG.
a. To register the supplier, carry out the steps described in steps 2a - g (Supplier Registration) of scenario 1.
b. Select the process to open the process details. Carry out the consolidation process steps up to the Matching step.
c. Choose Match Review, and select the match group. Choose Back to navigate to the process overview. The process status is Stopped for Review (Matching).
The KPI chart shows that an approved match group consisting of two records was created. MDG recognized the supplier created in SAP Ariba as a potential duplicate of
an active business partner record in the MDG hub.
record.
You can display or change the Best Record. To do so, choose Show Result. In the Overview table, select the Best Record, and choose Review. You can make changes to
the Best Record by choosing Edit. To con rm and activate the data, choose Save. To navigate back to the process overview, choose Back. The active business partner
5/19/2023
e. To nalize the consolidation process, carry out the remaining process steps. Click on the KPI chart in the activation step, and choose Show Details. The process is now
completed, and the KPI chart shows an updated record with the activation target Change Request. The Business Partner ID you noted down earlier is displayed in the
columns Source ID and Business Partner.
 Note
f. To process the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad or, for newer releases, select the change request link, and open
the change request. You can make changes or add data. One you’re done, choose Done, and, to approve the change request, choose Approve. The business partner is
automatically replicated to SAP Ariba. Choose Refresh. The change request is displayed as Final Check Approved. Note down the Business Partner ID.
g. To check the supplier data in MDG, launch the Manage Supplier Governance app from the Fiori launchpad. Search for the Business Partner ID you noted down in step 1a
of scenario 2, and open the business partner details. The data corresponds to the best record you reviewed earlier. The changes you made during the consolidation and
change request process are re ected.
a. To check the replication status, in the Fiori launchpad, under Supplier Governance, launch the Manage Supplier Governance app. Search for Business Partner ID you
noted down in the preparation step 1 of scenario 2. Select the business partner in the search result list, and select Replication Status. The replication status is green.
The business partner in MDG points to two suppliers in SAP Ariba. The Object IDs of two suppliers that were updated in SAP Ariba are displayed. The Object IDs of the
business partner and the ERP Vendor that were updated in the Operational ERP client are displayed.
a. In SAP Ariba, select the Supplier Management tab to open the Supplier Management work center. Choose Manage SM Administration , and click on Inactive
Suppliers in the menu on the left. Search for the supplier ID you noted down in section 5a of scenario 3. The system shows the supplier in the list of inactive suppliers,
because another supplier refers to the same MDG ID, and SAP Ariba deactivated the new supplier.
b. To check the data of the original supplier in SAP Ariba, in the Supplier Management, search for the supplier ID you noted in section 3 (Supplier Registration) of scenario
2. In the supplier pro le, choose ERP data. Expand the relevant nodes under General. The supplier data was overwritten with the best record data from the MDG hub.
The data of the original and duplicate suppliers in SAP Ariba corresponds to the best record supplier data in MDG.
Scenarios 4, 5, 6: Step-by-step description

This document provides a step-by-step description three of the scenarios of the integration of SAP Master Data Governance for Supplier (MDG-S, hereinafter referred to as MDG)
and SAP Ariba Supplier Lifecycle and Performance (hereinafter referred to as SAP Ariba).
The following scenarios are described in reverse order:
Summary:
A supplier is created in SAP MDG (MDG), replicated to SAP Ariba Supplier Lifecycle and Performance (SAP Ariba), changed again in SAP Ariba, and changed yet again in MDG. A
business partner with supplier role is created in MDG and replicated to SAP Ariba. The supplier then updates their information in the buyer-speci c registration questionnaire in the
Ariba Network, and the change is approved in SAP Ariba. The changed record is sent to MDG. In MDG, the change request process is triggered, and a master data specialist veri es
and approves the record. Once the record is activated in MDG, it is replicated to all client systems including SAP Ariba. The buyer-speci c registration questionnaire in the Ariba
Network is also updated. The existing business partner with supplier role is then changed and activated in the MDG hub using a change request. The changed business partner is
automatically replicated from MDG to all connected client systems including SAP Ariba.
 Note
1. Create and Approve Supplier in MDG
Create a new supplier in MDG using the Manage Supplier Governance app. Approve the change request for the new supplier. The data replication to SAP Ariba is triggered
automatically. The new supplier is now displayed in the Manage Supplier Governance app, including the Business Partner ID. You can note down the ID for future reference.
You can check the replication status of the new supplier in MDG. To do so, search for the Business Partner ID you noted down earlier, and choose Replication Status. Note down
the Supplier ID created in SAP Ariba for future reference.
3. Check Supplier in SAP Ariba
The data you added in the MDG hub is now available in SAP Ariba. To check the data, select the Supplier Management tab to open the Supplier Management work center.
Search for the supplier name or for the Supplier ID you noted down earlier. Open the supplier pro le, and select ERP Data on the left. Expand the relevant nodes to verify the
data.
5/19/2023
1. Change Supplier in SAP Ariba and replicate changes to MDG
Search for the supplier name or for the Supplier ID you noted down earlier.
b. To invite the supplier, open the supplier pro le and select Registration on the left. Choose Invite, and choose the plus sign on the Invite to Register screen. If required,
enter a name and an e-mail address, choose Save, and choose Send.
c. The supplier contact receives an e-main with an invitation to register. They create an account in the Ariba Network, and see the supplier registration questionnaire that
is pre lled with data that was entered for the supplier in MDG. The supplier contact adds additional details and creates an account. The contact then receives a
con rmation e-mail that contains the organization account ID and the supplier username. Alternatively, the supplier can use their existing Ariba Network account to log
in.
d. The supplier contact reopens the supplier registration questionnaire and makes changes to their data, e.g. the contact details or tax number, and submits the
questionnaire. The supplier registration update is approved in SAP Ariba and the replication to MDG is triggered automatically based on the con guration under
Manage SM Administration ERP integration status Initial supplier synchronization .
e. In SAP Ariba, the supplier registration questionnaire is approved. The registration is complete. The supplier status is Registered, the quali cation status is Not
Quali ed, and the ERP integration status is Integrated.
f. To check the ERP integration message status, choose Manage SM Administration , select ERP Integration Status, and check the outbound messages. Once the
column.
g. To process the change request in MDG, launch the Change Request Inbox app from the Fiori launchpad. Select the relevant change request and review the data. The
changes made in SAP Ariba are displayed and highlighted.
Choose Approve to activate the data. To check the status, choose Refresh. The business partner replication to SAP Ariba is triggered automatically.
h. To review the supplier data in MDG, launch the Manage Supplier Governance app, and search for your supplier to review it. The changes made in SAP Ariba as well as
the changes made in the change request in MDG are re ected.
To check the replication status in MDG, search for your business partner in the Manage Supplier Governance app. Select the business partner in the search result list,
and choose Replication Status.
To check the supplier data in SAP Ariba, open the Supplier Management work center, and choose View for your supplier. Choose View Supplier Pro le, and choose ERP
Data. On the General tab, expand the relevant nodes to verify the data. The changes made in the change request in MDG were replicated and are re ected.
Senario 4: Change Supplier in MDG
1. Change Supplier in MDG
a. To create a new change request for the supplier you created earlier, launch the Manage Supplier Governance app from the Fiori launchpad in MDG. Search for the
Business Partner ID you noted down earlier.
b. Select the business partner description link, and choose Edit. Select a change request type (for example, Process Supplier), and choose OK.
c. Enter a change request description, and make changes to some of the data. To submit the change request, choose Submit. Approve the change request. The change
request status is now Final Check Approved, and the data replication to SAP Ariba is triggered automatically.
d. To check the supplier data in MDG, in the Manage Supplier Governance app, search for your supplier, and select the business partner description link. The changes you
made are now re ected.
To check the replication status in MDG, search for the Business Partner ID you noted down earlier, select the business partner in the search result list, and choose Replication
Status. The status is green and Posted Successfully in Target System. The object IDs of the supplier updated in SAP Ariba and the operational ERP are shown.
3. Review Supplier in SAP Ariba
To check the supplier in SAP Ariba, open the Supplier workcenter in the Supplier Management. Search for the supplier name or for the supplier ID you noted down earlier.
Navigate to the supplier details, choose ERP Data on the left, and expand the relevant nodes to verify the data. The changes you made in MDG were replicated to SAP Ariba
and are re ected. The changes are also re ected in the registration questionnaire for the supplier.
Scenario 7: Step-by-step description

This document provides a step-by-step description of one of the scenarios of the integration of SAP Master Data Governance for Supplier (MDG-S, hereinafter referred to as MDG)
and SAP Ariba Supplier Lifecycle and Performance (hereinafter referred to as SAP Ariba). The following scenario is described:
It is one of SAP MDG’s goals to avoid duplicates. However, in rare cases it can happen that duplicates come up, e.g. because during load, a duplicate check was not part of the load
process. In this integration scenario, all business partners in MDG are scanned for duplicates using the consolidation strategy Remove duplicates. Two business partners are
recognized as duplicates. MDG merges the data of both business partners and creates a best record. This means the mapped records in SAP Ariba Supplier Lifecycle and
Performance (hereinafter referred to as SAP Ariba) and ERP - two on SAP Ariba side, two on ERP side - will from now on be updated based on the MDG best record. Optionally, the
other business partners in MDG can be archived or deleted later on.
MDG then replicates the data to all client systems including ERP and SAP Ariba. In ERP and SAP Ariba, both existing suppliers are kept, because transactional data might exist. One of
the suppliers can be archived at a later point. In SAP Ariba, both suppliers refer to the MDG best record.
 Note
5/19/2023
0. Creation of active suppliers in MDG
 Note
a. Create two or more active suppliers in MDG using the Manage Supplier Master Data app. The replication to SAP Ariba is triggered automatically.
You can check the replication status in MDG. To do so, launch the Manage Supplier - Governance app from the Fiori launchpad. Search for the relevant business partner IDs, and
choose Replication Status, which is green for the new suppliers once the replication is carried out. You can also see the Supplier IDs that were created in SAP Ariba. Note them down
for future reference.
You can check the new suppliers in SAP Ariba. To do so, log on to SAP Ariba, select the Supplier Management tab to open the Supplier Management work center, and search for the
Supplier IDs you noted down earlier. The suppliers that were created in MDG and replicated to SAP Ariba are displayed.
1. Consolidation of active records
 Note
As a prerequisite for this scenario, please create a process template for the consolidation of active records with the Remove Duplicates stategy.
a. To create a consolidation process, in MDG, launch the Manage Consolidation Processes Business Partners app from the Fiori launchpad. Choose Create Process, enter
a description, select the process goal Consolidation of Active Records, and select the process template you created as a preparation for this scenario (Remove
Duplicates strategy). Choose Save.
b. To start the consolidation process, enter the selection criteria for your new business partners, and choose Start. The process stops at the Matching step, and one
approved match group is created.
c. Choose Match Review. For one of the business partners in the potential duplicates, the system determines that it is the Best Record. You can select another business
partner as the best record using Set As Target. Note down the ID of the business partner you select as the best record for future reference.
d. Carry out the best record calculation. Choose Review to see that the best record was created according to the rules set for the best record calculation process.
e. Finalize the consolidation process to activate the record. Once the process is completed, the business partner replication is triggered automatically.
f. If you are working with S/4HANA release 1909 or higher, to check the data, click on the KPI chart, and choose Show Details. Click on the business partner description link
to navigate to the Business Partner app.
g. You can check the data of the two other duplicate business partners. To do so, launch the Manage Supplier Master Data app. The data remains unchanged, and the
duplicate business partners have the status Flagged for Archiving. In the connected Operational ERP client, all three business partners are updated with the data of the
best record.
2. Supplier replication
a. You can check the replication status. To do so, launch the Supplier Governance app, and search for the business partner you selected as the best record during
consolidation. Select the business partner in the search result list, and choose Replication Status.
a. SAP Ariba detects that other suppliers refer to same MDG ID and deactivates the duplicate suppliers. New sourcing events or purchase transactions cannot be created
for these suppliers anymore.
b. You can check the data of the inactive and active suppliers in SAP Ariba. To do so, select the Supplier Management tab to open the Supplier Management work center.
In the search eld, enter the supplier ID you noted down earlier to display the supplier that corresponds to the business partner you selected as the best record in the
consolidation process. Select Manage SM Administration , and choose Inactive Suppliers from the menu on the left. Search for the duplicate supplier IDs you
noted down earlier. The suppliers are displayed in the list of inactive suppliers.
Navigate back to the supplier pro le, and expand the relevant nodes under General. The supplier data was overwritten with the best record data from the MDG hub.
The data of the original supplier in SAP Ariba is now in sync with the best record supplier data in MDG.
4. Supplier Registration - Change of Supplier in SAP Ariba and Replication to MDG
a. Log on to SAP Ariba. Select the Supplier Management tab to open the Supplier Management work center.
b. In the search elds, enter either the supplier names or the supplier ID you noted down earlier, and start the search.
c. To invite the supplier, open the supplier pro le, and click on the Registration link on the left. Choose Invite. On the Invite to register screen, click on the plus sign in the
Choose recipient table, and enter the name and e-mail address of the supplier if required. Select Send. The registration status is now Invited. A registration e-mail is
sent to the supplier with an invitation to register. The supplier can now review pre lled data and add additional details. Once the supplier has created an account and is
registered, they will receive a con rmation by email containing the account ID and the supplier username.
d. If supplier data is changed in the questionnaire and the registration process is completed, the changed data is automatically replicated to MDG.
e. You can check the ERP integration status in SAP Ariba. To do so, choose Manage SM Administration , and choose ERP Integration Status to check the outbound
messages. Once the replication is completed, the outbound message type Request_In is displayed, and the status is Completed.
f. If changes were made during the registration, process the change request in MDG. Open the Friori launchpad and launch the Change Requests Inbox app. Open the
relevant change request and review the data. The change request for the business partner that was selected as a best record in step 1c is created, and changes made
in SAP Ariba are displayed and highlighted. You can make changes to the data choosing Edit. Choose Approve to approve the change request. The business partner
replication to SAP Ariba is automatically triggered.
You can check the activated supplier in MDG. To do so, launch the Manage Supplier Master Data app.
5/19/2023
You can check the replication status in MDG. To do so, launch the Manage Supplier Governance app from the Fiori launchpad and search for the best record business
partner ID you noted down earlier. Select the business partner in the search result list and choose Replication Status.
Integration of MDG-C with SAP Cloud for Customer (C4C)

SAP Master Data Governance for Customer (MDG-C) integration with SAP Cloud for Customer (C4C) enables the bi-directional replication of new or changed business partner
records.
The integration enables bi-directional data replication between the C4C system and the MDG system via a Process Integration (PI) or Cloud Platform Integration (CPI) system. It
ensures the availability of the latest version of data records in both systems at an optimal data quality. Changed or newly created records and the corresponding key mapping are
synchronized without the risk of data loss, and master data information is made available so that transactional business can ow between C4C and the connected client systems.
MDG ensures that all connected client systems including ERP are provided with the latest versions of data records. Consolidation processes are automatically triggered in MDG to
identify duplicates, de ne best records, and disregard or replace redundant records.
 Note
For the integration scenarios 1, 2, 3, and 7 (see link below), MDG, consolidation is used for new business partners that arrive from C4C. Only with consolidation, detected duplicates
can be properly handled on MDG side, and the result can be synchronized with C4C. This includes not only the detection of duplicates in MDG, but also
merging the duplicate with the best record including the merger of attributes, and
replicating the result to C4C including key mapping.
If you don’t use MDG, consolidation but only MDG, central governance, you can only use the duplicate check to detect a duplicate. Then, however, merging both business partners
and replicating the merged result back to C4C is not possible. An incoming business partner, although it might be a duplicate, then has to continue to exist in both MDG and C4C.
For this reason, we strongly recommend you use MDG, consolidation for new business partners arriving from C4C from the beginning.
For a description of recommended integration scenarios, see Integration Scenarios for MDG-C/C4C.
For con guration instructions of your MDG system for this integration, see Set Up Integration of MDG-C with SAP Cloud for Customer (C4C).
For the technical setup in SAP Cloud for Customer, see https://help.sap.com/viewer/d16cafef8d2447cda9db3d55214e0515/1902/en-US/0438d5f7ab9844ae8e239adfaa460fa6.html.
The gure below shows the communication between the systems involved.
Overview of MDG/C4C System Communication
Integration Scenarios for MDG-C/C4C

This document provides an overview of the recommended best-practice scenarios for the integration of MDG, C4C, and connected client systems. The scenarios below describe the
respective system behavior and replication activity.
1. Scenario 1: New Customer Record from C4C, No Duplicate Found in MDG
5/19/2023
Example: As a sales representative, you create a new potential customer in the C4C system. If there already is a rst Sales Order by this customer, you can also already enter
the order in the C4C system to start business with this customer immediately. As soon as the customer becomes relevant for business, it is replicated to MDG-C to ensure
optimal data quality, enrich data for follow-up processes, and make the customer available in all relevant follow-up systems, for example, for the processing of Sales Orders. If
you created a Sales Order when creating the customer record in C4C, the Sales Order can be replicated to ERP for further processing.
a. A new customer record is created in C4C.
b. The customer record is then automatically sent to the MDG Hub using SOA.
c. This automatically triggers a consolidation process in the MDG Hub, where no duplicates are found.
d. The record is activated in the MDG Hub.
e. The activated record with new key mapping is then automatically replicated to all connected client systems. After successful replication, the client systems send a
con rmation message with the local number to the MDG Hub, and MDG writes the key mapping for the new customer.
f. The key mapping is then replicated from MDG to all client systems.
g. The ERP number of the customer is stored in C4C to make sure transactional data, for example Sales Orders, can be properly replicated.
2. Scenario 2: New Customer Record from C4C, Duplicate Found in MDG: Business Partner Record Does Not Exist in C4C
a. A new customer record is created in the C4C system.
c. This automatically triggers a consolidation process in the MDG Hub, where a duplicate is found. The data of the duplicate records is merged.
d. The consolidated record is then activated in the MDG system, and the key mapping of the existing record is enhanced.
e. The activated record with new key mapping is then automatically replicated to all connected client systems. After successful replication, the client systems send a
con rmation message with the local number to the MDG Hub, and MDG writes the key mapping for the new customer.
g. The ERP number of the customer is stored in C4C to make sure transactional data, for example Sales Orders, can be properly replicated.
3. Scenario 3: New Customer Record from C4C, Duplicate Found in MDG: Business Partner Record Already Exists in C4C
a. A new customer record is created in the C4C system.
5/19/2023
c. This automatically triggers a consolidation process in the MDG Hub, where a duplicate is found. The data of the duplicate records is merged.
d. The consolidated record is then activated in the MDG system, and the key mapping of the existing customer record is enhanced. This results in two key mappings that
will be sent to C4C.
e. The activated record with the enhanced key mapping is automatically replicated from the MDG Hub to all connected client systems. After successful replication, the
client systems send a con rmation message with the local number to the MDG Hub, and MDG writes the key mapping for the new customer.
g. Based on the incoming key mapping, C4C detects duplicates for this record in the C4C system. C4C then merges the duplicates locally and marks the redundant
customer record as inactive.
4. Scenario 4: Change Business Partner Record in MDG
Example: As a master data specialist, you change the data of an existing customer record based on new information, and you want to make this new data available to sales
representatives using the C4C system, as well as in ERP, for example, for the processing of Sales Orders.
a. A business partner record is changed in the MDG Hub with a change request in a central governance process.
b. Once the change request is approved and the changed record is activated, MDG replicates the changed record to all connected client systems.
5. Scenario 5: Change Customer Record in C4C
Example: As a sales representative, you change customer data based on new information, and want to share this new data with the MDG system as well as with ERP, for
example, for the processing of Sales Orders.
a. A customer record is changed in the C4C system.
b. The changed record is sent to MDG using SOA.
c. In the MDG system, a central governance change request process is automatically triggered. A master data specialist veri es the data and approves the request.
d. Once the record is activated, MDG replicates it to all client systems.
5/19/2023
6. Scenario 6: Create Customer Record in MDG
Example: As a master data specialist, you create a new customer record and want to make this new data available to sales representatives using the C4C system, as well as in
ERP, for example, for the processing of Sales Orders.
a. A new customer record is created in the MDG Hub using a change request in Central Governance.
b. After successful completion of the change request process, MDG replicates the approved record to all client systems.
c. The client systems then send a con rmation message with the local number to the MDG system. MDG writes the key mapping for the new record.
d. The MDG system replicates the key mapping to all client systems.
e. The ERP number of the record is stored in the C4C system to make sure transactional data, for example Sales Orders, can be properly replicated.
7. Scenario 7: Merge Two Active Customer Records in MDG
Example: As a master data specialist, you carry out a consolidation of active records in MDG-C. The consolidation identi es one of the customer records as a duplicate. A best
record is de ned and activated in MDG, and the information is shared with C4C. The corresponding records can then also be locally merged in C4C to re ect the new data.
a. In the MDG Hub, a consolidation of active records is carried out with the remove duplicates strategy.
b. A duplicate record is found. The redundant business partner record is marked as being replaced by the remaining business partner. The key mapping is adjusted.
c. After the activation of the records, MDG replicates the customer data and the key mapping to all client systems. In the C4C system, the customer record already exists.
A local merge case is created in C4C. C4C merges the duplicates locally and marks the redundant customer record as inactive. In ERP, there may be transactional data,
for example Sales Orders, and both customers remain.
5/19/2023
How to Get Master Data Governance Running

MDG Topic 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MDG Topic 2

Uploaded by

Copyright:

Available Formats

5/19/2023

Master Data Governance

SAP S/4HANA | 2022 Latest

Original content: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/6d52de87aa0d4fb6a90924720a5b0549?locale=en-US&state=PRODUCTION&version=2022.001

For more information, please visit the https://help.sap.com/docs/disclaimer.

Change Request Processing

The steps in a typical work ow are outlined below:

A variety of search methods oﬀer sets of prede ned search criteria.

Additional Search Lines

Save and Load Searches

Maximum Number of Results

Number of Search Result Records

3. Enter change request details

4. Enter details for new customer

5. Submit your change request

You have activated the following event type linkages:

Object Type: BUS2250, Event: ACTIVATED , Receiver Type: ACTIVATED_DE

Object Type: BUS2250, Event: ROLLED_BACK , Receiver Type: ROLLED_BACK_DE

2. Choose Create Customer.

3. Enter details of the new customer.

8. If required, enter additional data for the new customer.

9. Choose Submit to trigger the work ow.

In the Search Customer service, select a customer in the result list.

2. Change to edit mode

To change the customer to edit mode, choose the Edit button.

3. Select a change request type

4. Enter change request details

5. Enter changes and submit

Marking a Customer for Deletion

2. Select a change request type.

3. Enter change request data.

4. Submit change request.

To trigger the deletion work ow, click the Submit button.

2. Select a change request type

3. Enter change request data

4. Submit change request

2. Select target system

Creating a Mass Change Request

2. Create Change Request

3. Enter general data

4. Enter a reason for the change

5. Specify customers for the change request

Choose the Enter button followed by Next to continue.

2. Select customers to include

5. Check and execute

For more information on SAP Business Integrity Screening, see http://help.sap.com/bis .

Separate forms to create a customer as an organization and a person

Automatically generated list of potential duplicates

Track My Requests UI to track the request status

Option to upload attachments containing request details

Supported Device Types

Relevant Business Catalog

Decentralized Master Data Governance for Customer

Enter your search criteria and choose Start Search.

A hit list is displayed.

2. Copy to the client system

Change Request Processing

The steps in a typical work ow are outlined below:

Search FI Contract Account

A variety of search methods oﬀer sets of prede ned search criteria.

Additional Search Lines

Save and Load Searches