PUBLIC

How-To Set Up Central Governance to Use Data

Quality Management Derivation Scenarios

Applicable Releases:
MDG on S/4HANA 2022 and higher

Version 1.2
March 2024

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.
Document History

Document Version Description

1.0 First version (November 2022)

1.1 Add chapter on debugging the derivation for a change request (January
2023)
1.2 Add details on restriction of logical actions, add SAP note (March 2024)
1. BUSINESS SCENARIO ........................................................................................................................................................... 4
2. EXAMPLE PROCESS ............................................................................................................................................................. 4
3. RESTRICTIONS ..................................................................................................................................................................... 5
3.1. SUPPORTED LOGICAL ACTIONS, SINGLE OBJECT MAINTENANCE ..........................................................................................................5
3.2. BUSINESS PARTNER, CUSTOMER, SUPPLIER .....................................................................................................................................5
4. STEP BY STEP EXPLANATION ............................................................................................................................................... 7
4.1. NEW ACTIONS AND STEP TYPE......................................................................................................................................................7
4.2. CONFIGURATION OF A NEW CHANGE REQUEST TYPE INCL. RULE BASED WORKFLOW.............................................................................10
4.2.1. Create a Service Name in IMG.....................................................................................................................................10
4.2.2. Create a New CR Type and Configure CR Steps ...........................................................................................................12
4.2.3. BAdI Implementation for BAdI USMD_SSW_SYSTEM_METHOD_CALLER ...................................................................15
4.2.4. Configure Rule-Based Workflow for New CR-Type ......................................................................................................24
4.3. EXAMPLE DERIVATION SCENARIOS...............................................................................................................................................35
4.3.1. Example Derivation Scenario for Products (Materials) ...............................................................................................35
4.3.2. Example Derivation Scenario for Business Partners ....................................................................................................47
5. TIPS AND TRICKS FOR IMPLEMENTING DERIVATION SCENARIOS ....................................................................................... 60
5.1. DERIVATION FOR BUSINESS PARTNER (CUSTOMER/ SUPPLIER) AND LANGUAGE FOR ADDRESS ................................................................60
5.2. EXISTING DERIVATION FOR BUSINESS PARTNER (CUSTOMER/ SUPPLIER) .............................................................................................60
5.3. TYPE-4 ENTITIES MUST HAVE AT LEAST ONE ATTRIBUTE ....................................................................................................................61
5.4. PROVIDE DATA VIA EXTRA DATA PROVISIONING – DB LOOKUP .........................................................................................................62
5.5. ACCESS CHANGE REQUEST DATA ................................................................................................................................................63
5.6. DEBUGGING THE DERIVATION FOR A CHANGE REQUEST ...................................................................................................................66
6. ADDITIONAL INFORMATION ............................................................................................................................................. 67
6.1. FURTHER READING ...................................................................................................................................................................67
6.2. SAP NOTES ............................................................................................................................................................................68

3
1. BUSINESS SCENARIO
SAP Master Data Governance provides business processes to find, create, change, and mark master data for deletion.
It supports the governance of master data in a central hub and the distribution to connected operational and business
intelligence systems.

The processes are workflow-driven and can include several approval and revision phases, and the collaboration of all
users participating in the master data maintenance.

Derivation scenarios are used to deduce master data in MDG, central governance as well as consolidation and mass
processing. This document guides through setting up central governance to use DQM derivation scenarios. In addition,
it contains tips and tricks for implementing more complex derivation scenarios.
For more information about defining derivation scenarios, see https://help.sap.com/docs/SAP_S4HANA_ON-
PREMISE/6d52de87aa0d4fb6a90924720a5b0549/7b586ec9ab7f4d9ba5c240ddac4f3a92.html?q=Derivation%20Scen
ario&locale=en-US

2. EXAMPLE PROCESS
The following example process will be set up in this guide using a rule-based workflow.

In change request step 00 the requestor creates a new supplier and submits the change request (CR). Hence, the
process gets to CR step 30 (DQ Derivation). This is a background step. Via process pattern 02 (Synchronous System
Method) a BAdI is called which uses API CL_MDG_MDQ_RBWF_DERIVE to trigger the DQ derivation 1. 0F

This API has three potential results: Derivation successful, derivation successful but with messages and derivation
failed. For a successful derivation the process goes to CR step 40 where a master data specialist can finalize the
processing or send the CR for revision. When finalizing processing the process reaches CR step 90. The approver can
either activate the CR and send it to the previous CR step for revision. This is the golden path. The alternative paths
are as follows:

• Derivation failed, derive again

In CR step 30 API CL_MDG_MDQ_RBWF_DERIVE indicates the derivation failed. In this case the process goes to CR
step 85 (Fix or Continue), where a master data steward can review the CR as well as any issues logged in the

1
See MDG Data Quality Management Derivation Scenarios

4
 backend. The steward might even find that some derivation scenario might need to be adjusted or corrected. In
this case the steward can resubmit to go to CR step 30 again and get the DQ derivation triggered again for this
CR.

• Derivation failed, continue

As an alternative for a failed derivation, the master data steward could just continue without having the DQ
derivations triggered again. The process goes to CR step 40 in this case.

• Derivation successful but with messages

The example process is set up to not distinguish between a failed derivation and a successful one but where
messages occur. Both go to CR step 85. However, since different actions (D2 for a failed derivation, D5 for a
successful derivation but with messages) are used, there is the possibility to
o go to different CR steps for a failed derivation and a successful derivation where messages occur (e.g.
a CR step 86) or
o handle a successful derivation where messages occur the same way like a successful derivation
(without messages) and hence go to CR step 40.

Later in the process there are (the already known) alternative paths for revision. From CR step 40 to process goes to
CR step 95 (Revise) in case the master data specialist chooses to send the CR for revision. The requestor needs to
change and resubmit the CR or can withdraw it. A similar revision-loop is there for CR steps 40 and 90.

Note: SAP recommends to have a dialog step after the background step in which the derivation takes place. For the
example scenario above this means that configuring a transition from CR step 30 directly to 99 is not recommended.

3. RESTRICTIONS

3.1. Supported Logical Actions, Single Object Maintenance

A change request type is assigned to a business activity. The business activity is a combination of a data model, an
object type code and a logical action. The functionality only supports the logical actions BLOCK (un-block an object),
CREATE, CHANGE, and DELETE (un-mark an object for deletion). Other logical actions are not supported. This
restricts the functionality to the single object maintenance related change request types.

Details on unsupported logical actions:

- MASS (Pass Processing), LOAD (Data Exchange): Both logical actions typically are related to a process (à CR
type) where huge numbers of master data objects are processed. Using DQM derivation scenarios in such
processes in MDG Central Governance will result in performance issues and potentially timeouts. If you would
like to process many master data objects and apply DQM derivation scenarios you should use MDG
Consolidation and/or MDG Mass Processing.
- Processes in Central Governance which relate to logical action MASS typically only change entity types of
storage and usage type 1. This conflicts the scope of DQM derivation scenarios where entity types of other
storage and usage types can be changed too.
- In MDG Central Governance there is no status which indicates result of the DQM derivations per master data
object. The derivation status is only available per change request and in the BAdI implementation of the
background step. For a change request with a huge number of master data objects (à common for change
request types that relate to logical action MASS) the behavior for the DQM derivations would be as follows: In
case there is a single error no derived values must be stored for any master data object (à reproducibility).
Hence, the more master data objects are contained in a change request the more likely is a failure during
derivation and hence that no values are derived at all.

3.2. Business Partner, Customer, Supplier

The functionality supports only main entity type BP_HEADER and its dependent entity types.

It is impossible to create new addresses and/or business partner relationships since entity type ADDRNO and
BP_REL/TD_BPREL are not supported. Existing relationships cannot be changed (a change of existing address data is
possible).

All entity types related to texts (e.g., sales area texts, supplier general data texts) are not supported.

5
Documents and document links are not supported.

Regarding multiple assignments, it is only possible to use the standard assignments for customers and/or suppliers.
Additional, non-standard assignments as well as custom assignments are not supported.

6
4. STEP BY STEP EXPLANATION

4.1. New Actions and Step Type

This chapter describes the creation of new actions and a new step type. The actions are used to control the rule-based
workflow. API method DERIVE of API CL_MDG_MDQ_RBWF_DERIVE indicates a derivations result.

<<interface>>
IF_MDG_MDQ_RBWF_DERIVE
DERIVE( CHANGE_REQUEST ): DERIVATION_RESULT

DERIVATION_FAILURE: CHAR1 ( 'F') Possible values of

DERIVATION_SUCCESS: CHAR1 ( 'S') DERIVATION_RESULT
DERIVATION_SUCCESS_W_MESSAGES: CHAR1 ( 'M') (constants)

<<class>>
CL_MDG_MDQ_RBWF_DERIVE

There are the following possibilities:

• Failed Derivation ('F')

• Successful Derivation ('S')
• Successful Derivation, but with Messages ('M')

It is up to the customer to decide how to integrate derivation scenarios into the rule-based workflow for a certain
change request type. A maximal configuration for these results requires three actions (one for each derivation result)
plus actions for the UI (here Continue and Resubmit in case the derivation was not successful or messages occurred).

In this guide the following actions are used:

• D1 (Derivation successful) for Successful Derivation ('S')

• D2 (Derivation failed) for Failed Derivation ('F')
• D3 (Continue) to continue to change request step 40
• D4 (Resubmit with DQ Derivation) to go again to change request step 30 (and again execute derivations)
• D5 (Success with Messages) for Successful Derivation, but with Messages ('M')

The actions D1, D2, D5 are used for change request step 30 (background step) and in the BAdI implementation.
Actions D3 and D4 are used in the MDG UI for the change request step 85. The process will reach step 85 in case of a
failed derivation or in case of a successful derivation but with messages. In this step the user will see two buttons
(Continue, Resubmit).

7
Besides these actions a new step type 'H' (Fix or Skip DQ Derviation) is created, which has the actions D3 and D4
assigned to it. Step type 'H' is used in user agent decision table (DT_USER_AGT_GRP_...) for the condition aliases
DQM and DQF, which are used for the transitions from change request step 30 (DQ Derivation) to 85 (Fix or Continue).

Step Explanation Screenshot

1 Start transaction MDGIMG.

Navigate to General Settings
> Process Modeling >
Workflow > Define Change
Request Actions

2 Press New Entries.

3 Create the actions as Action Description Pushbutton Text Quick Info Text Check Note Reason
described on the right side: D1 DQ Derivation N/A N/A - - -
successful
D2 DQ Derivation N/A N/A - - -
failed
D3 Continue Continue Continue Yes - -
D4 Resubmit with Resubmit with Resubmit with DQ Yes - -
DQ Derivation DQ Derivation Derivation Rules
D5 DQ Derivation DQ Derivation DQ Derivation Yes - -
successful with successful with successful with
Messages Messages Messages

4 The new actions should look

like this:

Press Save and exit the

customizing.

8
Step Explanation Screenshot
5 Navigate to General Settings
> Process Modeling >
Workflow > Define Change
Request Step Types and
Assign Actions.

6 Press New Entries.

7 Enter Step Type 'H' and

Description as well as
Window Title 'Fix or
Continue (DQ Derivation)'.
Press Save.

8 Navigate to Assign Actions.

9 Press New Entries.

9
 Step Explanation Screenshot
10 Assign the actions as Action Description Sequence
described in the table on the D3 Continue 1
D4 Resubmit with DQ Derivation 2
right. Press Save.

4.2. Configuration of a new Change Request Type incl. Rule Based Workflow
In this chapter a new CR type is configured. A rule-based workflow is used to integrate DQ derivations in a background
step and handle the derivation result (derivation failed, derivation successful with/without messages). The latter is
achieved by having a dedicated CR step (85) in the workflow. The following tasks are performed in this chapter:

• Define a service name in Customizing under Master Data Governance, Central Governance > General Settings
Process Modelling > Workflow > Define Service Names for Rule-Based Workflow. (chapter 4.2.1)

• Create a new CR type and configure its steps (chapter 4.2.2).

• Create a BAdI implementation for BAdI Rule-Based Workflow - Call System Method
(USMD_SSW_SYSTEM_METHOD_CALLER). The BAdI implementation uses the defined service name as a filter value.
The implementation uses the API CL_MDG_MDQ_RBWF_DERIVE. Depending on the derivation result, an
appropriate action is determined to control the rule-based workflow. (chapter 4.2.3)

• Configure the decision tables for the rule-based workflow for the new CR type in Customizing under Master Data
Governance, Central Governance > General Settings > Process Modelling Workflow > Configuration Rule-
Based Workflow. Here, a condition alias needs to be defined using process pattern 02 (Synchronous System
Method) and the service name (previous step) in the non-user agent decision table. In the single value decision
table this condition alias must be assigned. (chapter 4.2.4)

4.2.1. Create a Service Name in IMG

This chapter describes the definition of a service name for the rule-based workflow. It serves as a Business Add-In
(BAdI) filter value (see next chapter) and is at the same time available for definitions in the rule-based workflow (BRF+)
for process pattern Synchronous System Method (02).

10
 Usage of the service name as BAdI filter: Usage of the service name in a rule-based workflow:

In the following steps, generic names and descriptions are used in the screenshots. For this guide you need to
replace them as follows:

Object Name / Description To be replaced by:

Service Name ZMY_SERVICE_NAME ZMDQ_DERIVATION

Service Description Some description providing a hint as to System Method Call for MDQ Derivation
what this service does

Step Explanation Screenshot

1 Start transaction MDGIMG.

Navigate to General Settings
> Process Modeling >
Workflow > Rule-Based
Workflow > Configure Rule-
Based Workflow > Define
Service Names for Rule-
Based Workflow.

11
 Step Explanation Screenshot
2 Choose New Entries.

3 Create a new entry with the

following data:
• A meaningful name
for Service Name,
here:
ZMDQ_DERIVATION
• A Description
providing a hint as to
what this service
does: System
Method Call for
MDQ Derivation

Choose Save.

Note: You might need to

choose a transport request
to record you changes.

4.2.2. Create a New CR Type and Configure CR Steps

In this chapter a new change request type is created and configured. To omit starting from scratch, the SAP-delivered
change request type SUPPL1P1 (Create Supplier) is copied to ZSUP1MDQ (Create Supplier w/ MDQ Derivation) and
adjusted.

Step Explanation Screenshot

1 Start transaction MDGIMG.

Navigate to General Settings
> Process Modeling >
Change Requests > Create
Change Request Type.

12
Step Explanation Screenshot
2 Select change request type
SUPPL1P1 and choose Copy
As.

3 Enter the following values:

• Type of Change
Request:
ZSUP1MDQ
• Description: Create
Supplier w/ MDQ
Derivation
• Workflow:
WS60800086

(Note that the used workflow

needs to be changed.)

4 Choose Copy.

5 In pop-up Specify object to

be copied choose copy all.

6 Acknowledge the information

on Number of dependent
entries copied by choosing
Continue.

13
Step Explanation Screenshot
7 Navigate to Type of Change
Request.

8 Choose Save.

9 Go back to MDGIMG. Navigate

to General Settings >
Process Modeling >
Workflow > Rule-Based
Workflow > Define Change
Request Steps for Rule-
Based Workflow.

10 Press New Entries.

14
 Step Explanation Screenshot
11 Enter ten entries with the
name of the change request
type to ZSUP1MDQ:
• CR Step: 0
Dscr: Processing
Next Step: 30
• CR Step: 30
Dscr: DQ Derivation
(Backgr.)
Next Step: 40
• CR Step: 40
Dscr: Processing
Next Step: 90
• CR Step: 85
Dscr: Fix or Skip
Next Step: 30
• CR Step: 90
Dscr: Final Check
Validation: yes
Next Step: -
• CR Step: 91
Dscr: Activation
Next Step: -
• CR Step: 92
Dscr: Revision
Next Step: -
• CR Step: 93
Dscr: Validation
Next Step: -
• CR Step: 95
Dscr: Revision
Processing
Next Step: 40
• CR Step: 99
Dscr: Complete
Next Step: -

Choose Save.

4.2.3. BAdI Implementation for BAdI USMD_SSW_SYSTEM_METHOD_CALLER

In this chapter a Business Add-In (BAdI) implementation for BAdI USMD_SSW_SYSTEM_METHOD_CALLER (Rule-Based
Workflow - Call System Method) is created. It enables calling a system method in a rule-based workflow in SAP Master
Data Governance. For more information, see the BAdI documentation. The service name is defined in the previous
chapter (4.2.1 serves as BAdI filter). The actual implementation of the BAdI method depends on the use case.

In the following steps, generic names and descriptions are used. For this guide you need to replace them as
follows:

Object Name / Description To be replaced by:

Enhancement ZMY_SERVICE_CALL_SYSTEM_METH ZBDI_MDQ_DERIVATION

Implementation OD
Enhancement Some description providing a hint as to System Method Call for MDQ Derivation
Implementation Short Text what this enhancement is about

15
Object Name / Description To be replaced by:
BAdI Implementation ZMY_SERVICE_CALL_SYSTEM_METH ZBDI_MDQ_DERIVATION
OD
BAdI Implementation Some description providing a hint as to System Method Call for MDQ Derivation
Description what this BAdI implementation is about.
BAdI Implementing Class ZCL_MY_SERVICE_CALL_SYS_METHO ZCL_BDI_MDQ_DERIVATION
D
BAdI Filter Value ZMY_SERVICE_NAME ZMDQ_DERIVATION

Step Explanation Screenshot

1 Start transaction SE18.

Select option BAdI name
and enter
USMD_SSW_SYSTEM_METHOD_
CALLER. Choose Display.

2 Open the context menu on

the Implementations for BAdI
USMD_SSW_SYSTEM_METHOD_
CALLER and choose Create
BAdI Implementation.

3 In the pop-up Select or

Create Enhancement
Implementation, choose
Create Enhancement
Implementation.

16
Step Explanation Screenshot
4 In the pop-up Create
Enhancement
Implementation enter the
following data:
• A meaningful name
for the Enhancement
Implementation,
here:
ZMY_SERVICE_CALL
_SYSTEM_METHOD
• Some Short Text
providing a hint as to
what this
enhancement is
about
Choose Creation of
Enhancement.

5 Choose a suitable
development package or
store the enhacement
implemantation as a local
object depending on your
needs.

6 In the
pop-up Select or Create
Enhancement
Implementation amongst
others, the new
enhancement
implementation is listed.
Select it and choose Select
Specified Enhancement
Implementation.

17
Step Explanation Screenshot
7 In the pop-up Create BAdI
Implementation enter the
following data:
• A meaningful name
for the BAdI
Implementation,
here:
ZMY_SERVICE_CALL
_SYSTEM_METHOD
• Some Description
providing a hint as to
what this BAdI
implementation is
about
• The name of the
Implementing Class
which implemented
the BAdI interface,
here:
ZCL_MY_SERVICE_C
ALL_SYS_METHOD
Choose continue.

8 In the next pop-up choose

Enhancement
Implementation
MDG_BS_MAT_CREATE_SUCCE
SSOR_CR and choose Copy
Sample Class.

9 Choose a suitable
development package or
store the implementation
class as a local object
depending on your needs.

18
Step Explanation Screenshot
10 Navigate to the Filter Values
for the BAdI implementation.

11 Go to edit mode.

12 A filter shall be created for

filter SERVICE_NAME to be
ZMY_SERVICE_NAME,
matching the service defined
in the Customizing Define
Service Names for Rule-
Based Workflow (see 4.2.1).
Press Combination.

13 Double-click the combination

or choose Value.

19
Step Explanation Screenshot
14 In the pop-up Change Filter
Value enter or choose the
following data:
• Value 1: The service
name defined in
Customizing Define
Service Names for
Rule-Based
Workflow (see
4.2.1), here:
ZMY_SERVICE_NAME
You can use the value help
to choose the service name.
• Comparator 1: =
Choose Continue.

Note: One BAdI

implementation can handle
calls for more than one
service name. Use the
service name distinguish
between use cases.

15 As result the filter is

adjusted.

16 Navigate to Implementing
Class.

20
Step Explanation Screenshot
17 Double-click BAdI method
IF_USMD_SSW_SYST_ME
THOD_CALLER~CALL_SYS
TEM_METHOD.

18 Go to edit mode.

19 Change the example

implementation according to
your needs.
At least change the CASE-
WHEN statement to match the
service name defined in the
Customizing Define Service
Names for Rule-Based
Workflow (see 4.2.1), here:
ZMY_SERVICE_NAME.

21
Example code:
METHOD if_usmd_ssw_syst_method_caller~call_system_method.

DATA(cr_number) = iv_cr_number.

CASE iv_service_name.
WHEN 'ZMDQ_DERIVATION'.

"Get an instance of the MDQ derivation controller

DATA(derivation_controller) = cl_mdg_mdq_rbwf_derive=>get_instance( ).

"Execute the derivation and evaluate the result

DATA(result) = derivation_controller->if_mdg_mdq_rbwf_derive~derive( change_request = cr_number ).

IF result EQ derivation_controller->if_mdg_mdq_rbwf_derive~derivation_failure.
"Indicate that the derivation failed
ev_action = 'D2'.
"INFO: access to messages via derivation_controller->messages
ELSEIF result EQ derivation_controller->if_mdg_mdq_rbwf_derive~derivation_success_w_messages.
"Indicate that the derivation was successful but with messages
ev_action = 'D5'.
"INFO: access to messages via derivation_controller->messages
ELSE.
"Indicate that the derivation was successful
ev_action = 'D1'.
ENDIF.

WHEN OTHERS.

ENDCASE.
ENDMETHOD.

Step Explanation Screenshot

20 Activate the method. In case
other objects are still to be
adjusted, select them for
activation as well.

21 The enhancement, the BAdI

implementation as well as
the BAdI class have not
been activated so far. In the
pop-up Inactive Objects for
... select these.

22
Step Explanation Screenshot
22 To activate the selected
object choose continue.

23 Navigate back to the

enhancement
implementation.

24 Navigate back to
enhancement spot
USMD_SSW_SERVICE_PROCES
SOR.

23
 Step Explanation Screenshot
25 Check the activation status
(column Active) for your
enhancement
implementation. It must be
Active or Implementation is
called.

26 You may need choose

Refresh to get the current
status.

27 After refreshing the status

must be Active or rather
Implementation is called.

4.2.4. Configure Rule-Based Workflow for New CR-Type

This chapter describes the configuration of a rule-based workflow for the new change request type ZSUP1MDQ (Create
Supplier w/ MDQ Derivation). To omit starting from scratch the BRF+ decision tables of the SAP-delivered change
request type MAT01 (Create Material) are copied for ZSUP1MDQ and adjusted.

24
Step Explanation Screenshot

1 Start transaction MDGIMG.

Navigate to General Settings
> Process Modeling >
Workflow > Rule-Based
Workflow > Configure Rule-
Based Workflow.

2 Enter the change request

type MAT01 and choose
Continue.

3 Navigate to the single value

decision table
(DT_SINGLE_VAL_MAT01).

25
Step Explanation Screenshot
4 Choose Export To Excel.

5 Navigate to the user agent

decision table
(DT_USER_AGT_GRP_MAT01)
and choose Export To Excel.

6 Navigate to the non-user

agent decision table
(DT_NON_USER_AGT_GRP_MA
T01) and choose Export To
Excel.

26
Step Explanation Screenshot
7 There should be three MS
Excel files downloaded.

8 Open MS Excel document

DT_SINGLE_VAL_MAT01.xls
x and change the content of
the first worksheet
accordingly (see right side).

(Content as Text:)
CR Previous Previous Condition New Chng. New
Step Action Alias Req. Step CR Status
=00 SUB 30 02
=30 =D1 DQS 40 02
=30 =D5 DQM 85 Z5
=30 =D2 DQF 85 Z1
=40 =05 FIN 90 02
=40 =06 REV 95 02
=85 =D3 DQC 40 02
=85 =D4 DQR 30 02
=90 =09 2 91 02
=90 =10 3 95 10
=91 =31 4 99 05
=91 <>31 5 90 11
=92 6 99 06
=95 =07 7 40 02
=95 =08 8 92 02
9 Save the MS Excel file.

27
Step Explanation Screenshot
10 Open MS Excel document
DT_NON_USER_AGT_GRP_MAT
01.xlsx and change the
content of the first worksheet
accordingly (see right side).

(Content as Text:)
Condition Alias Agent Group Process Pattern Service Name
=2 1 06
=SUB 1 02 ZMDQ_DERIVATION
=DQR 1 02 ZMDQ_DERIVATION
=4 ; =6 1 99
=8 1 08

11 Save the MS Excel file.

12 Open MS Excel document

DT_USER_AGT_GRP_MAT01.x
lsx and change the content
of the first worksheet
accordingly (see right side).

(Content as Text:)
User Agt Step User Agent
Condition Alias Grp No. Type Type User Agent Value
=FIN 1 5 AG SAP_MDGS_MENU_03
=REV 1 4 AG SAP_MDGS_MENU_03
=DQS ; =7 ; =3 ; =DQC 1 3 AG SAP_MDGS_MENU_03
=DQF ; =DQM 1 H AG SAP_MDGS_MENU_03

13 Save the MS Excel file.

14 In the MDGIMG navigate to

General Settings > Process
Modeling > Workflow > Rule-
Based Workflow > Configure
Rule-Based Workflow.

28
Step Explanation Screenshot
15 Enter the newly created
change request type
ZSUP1MDQ and choose
Continue.

16 Navigate to the single value

decision table
(DT_SINGLE_VAL_ZSUP1MDQ)
.

17 Choose Edit to switch to edit

mode.

18 Adjust the Table Settings to

hide non-relevant columns.
In any case make sure that
the columns match the
columns in the MS Excel file.

29
Step Explanation Screenshot
19 Non-relevant columns in this
case are the condition
columns CR_PRIORITY and
the following ones.

20 Choose Additional Actions >

Import From Excel to import
the corresponding MS Excel
file and apply its content as
settings since the actual
settings of the single value
decision table are empty.

21 Choose MS Excel file

DT_SINGLE_VAL_MAT01.xls
x and then OK. Having
"..._MAT01..." instead of
"..._ZSUP1MDQ..." in the
file name will not be any
issue.

30
Step Explanation Screenshot
22 The decision table should
contain the adjusted values
from the MS Excel file.

23 Save the decision table.

24 Activate the decision table.

25 In case a confirmation for the

activation is required choose
Yes.

26 Navigate to the user agent

decision table
(DT_USER_AGT_GRP_ZSUP1M
DQ).

31
Step Explanation Screenshot
27 Choose Edit to switch to edit
mode.

28 Choose Additional Actions >

Import From Excel to import
the corresponding MS Excel
file and apply its content as
settings since the actual
settings of the single value
decision table are empty.

29 Select MS Excel file

DT_USER_AGT_GRP_MAT01.x
lsx and choose OK.

30 The decision table should

contain the values from the
MS Excel file.

32
Step Explanation Screenshot
31 Save the decision table.

32 Activate the decision table.

33 Navigate to the user agent

decision table
(DT_NON_USER_AGT_GRP_ZS
UP1MDQ).

34 Choose Edit to switch to edit

mode.

35 Choose Additional Actions >

Import From Excel to import
the corresponding MS Excel
file and apply its content as
settings since the actual
settings of the single value
decision table are empty.

33
Step Explanation Screenshot
36 Select MS Excel file
DT_NON_USER_AGT_GRP_MAT
01.xlsx and then OK.

37 The decision table should

contain the adjusted values
from the MS Excel file.

38 Save the decision table.

39 Activate the decision table.

34
4.3. Example Derivation Scenarios
The following step by step explanations assume that you are able to access the apps Define Derivation Scenarios for
Products/Business Partners from the SAP FIORI Launchpad.
If this setup is missing, follow these instructions in the ‘Configuration of MDG, Data Quality Management’
documentation.

We recommend to use the online help provided by SAP Companion, i.e. clicking on the ‘?’ provides context related
support.

Note: A typical derivation scenario modelling workflow involves various people with roles like Scenario Owner,
Implementation Expert, Rule Owner and Data Owner. The following examples do not consider this derivation scenario
modelling workflow.

4.3.1. Example Derivation Scenario for Products (Materials)

In this chapter, a sample derivation scenario for products (materials) is created. The use case is to derive plant
attributes from material basic data. For an existing material, the user maintains the fields Material Group and
Laboratory and assigns plants. The derivation scenario derives values for plant attributes, which depend on these
fields.
Note: The intention of this example is to provide a very simple derivation scenario that can be used to test your change
request implementation.

35
Step Explanation Screenshot

1 Open the SAP Fiori

Launchpad and navigate to
the Data Quality
Management for Products
section. Start the Define
Derivation Scenarios
Products app.

2 Choose Create.

3 Enter the following data:

• Scenario ID:
Z194_PLANT_BY_MA
RA
• Scenario Name:
Derive plant
data from
material basic
data

In the Scenario Base Table

dropdown list, select Basic
Data (MARA).
In the General Information
section, enter the
Description MRP-data is
derived from material
basic data.

To narrow down the scope of

this derivation scenario,
maintain a scope
expression. Enter the
following Scope Description:
Scenario is only
applicable when the old
material number is
Z194_PLANT_BY_MARA.
Choose Create.

4 The derivation scenario is

now in status New. Choose
Send for Implementation.

36
Step Explanation Screenshot
5 The derivation scenario is
now in status To Be
Implemented. Choose
Prepare Scope Expression.

6 Choose OK to acknowledge
that the base table can no
longer be changed.

7 The scope expression is

generated. Meanwhile the
derivation scenario is in
status Generation Running.
Wait and choose Refresh.

8 In the General Information >

Scope Details section, select
the scope expression link.

37
Step Explanation Screenshot
9 You are navigated to the
BRFplus Workbench. The
(scope) expression is
already displayed. Choose
Edit.

10 In the Detail section, choose

Edit Operand > Use Direct
Value Range From > Select
Context Parameter.

11 Under Search Criteria, enter

*old* for Text and choose
Search.

12 In the result list, select

MARA > Old Matl Number.

13 In the input field right to the

operand, enter
Z194_PLANT_BY_MARA and
choose Activate.

14 The (scope) expression is

saved. Navigate back to the
derivation scenario.
TODO

38
Step Explanation Screenshot
15 Back in the derivation
scenario, the Scope Status
is Active. Choose Edit.

16 In the Derivation Rules >

Derivation Rules for Fields
section, choose Create.

17 Enter R1 as the Rule ID and

the Rule Name MRP data
by material group and
laboratory. As the Result
Table, select Plant Data
(MARC).

39
Step Explanation Screenshot
18 Enter the Rule Description
MRP data derived from
material group and
laboratory.

19 In the Fields > Condition

Fields section, choose Add.

20 In the Select Condition

Fields popup, enter the
search term LABOR and
press Enter. Select
MARA~LABOR from the
result list.

21 Enter the search term MATKL

and press Enter. Select
MARA~MATKL from the
result list.

22 Enter the search term WERKS

and press Enter. Select
MARC~WERKS from the
result list.

40
Step Explanation Screenshot
23 Choose Select.

24 All three selected fields are

transferred to the Condition
Fields.

25 In the Fields > Result Fields

section, choose Add.

26 In the Select Result Fields

popup, enter the search term
DISLS and press Enter.
Select MARC~DISLS (Lot
Sizing Procedure in
Materials Planning) from the
result list.

27 In the Select Result Fields

popup, enter the search term
DISMM and press Enter.
Select MARC~DISMM (MRP
Type) from the result list.

28 In the Select Result Fields

popup, enter the search term
DISPO and press Enter.
Select MARC~DISPO (MRP
Controller) from the result
list.

29 In the Select Result Fields

popup, enter the search term
DZEIT and press Enter.
Select MARC~DZEIT (In-
house production time) from
the result list.

41
Step Explanation Screenshot
30 In the Select Result Fields
popup, enter the search term
PRCTR and press Enter.
Select MARC~PRCTR
(Profit Center) from the
result list.

31 Choose Select.

32 All five selected fields are

transferred to the Result
Fields.

33 Choose Apply.

34 You are directed back to the

derivation scenario. Choose
Save.

42
Step Explanation Screenshot
35 Select the rule with the ID
R1 and choose Set Status >
To Be Implemented.

36 Navigate to the details of this

rule.

37 In the Implementation
section, choose Create
Decision Tables.

38 You are informed that the

decision table creation
started. Choose Refresh.

39 Click the link to the decision

table.

40 The BRFplus Workbench is

displayed. Choose Edit.

43
Step Explanation Screenshot
41 Insert two new rows by
choosing the plus button
twice.

42 For the Plant use the Direct

Value Input and enter 1010.
Choose OK.

Note: The entered values

are examples only.

43 Correspondingly, fill in the

values for the other fields
(see table on the right).

Note: The green columns

show fields, the other
columns define the
conditions.

44
Step Explanation Screenshot
44 Note: To access columns
that are initially not visible,
use the cursor at the bottom

45 Note: Decision tables can be

maintained using the Import
From Excel function.

46 Choose Save when you

have entered all your data.

47 Navigate back to the Define

Derivation Scenarios app.

45
Step Explanation Screenshot
48 Back on the page of the
derivation rule R1, close the
subscreen.

49 Select the derivation rule R1

and set the status to To Be
Reviewed.

Note: These changes of

statuses would typically be
done by different persons
being involved in the setup
of a derivation rule.

50 Then, change the status of

the rule to To Be Approved.

51 Then, change the status of

the rule to Approved.

Now, all BRFplus artefacts of

derivation rule R1 are active.

46
 Step Explanation Screenshot
52 In the column Execution, set
the execution switch to On.

Now, the derivation rule R1

will be executed in all MDG
processes where derivation
scenarios are applied.

4.3.2. Example Derivation Scenario for Business Partners

In this chapter, a simple derivation scenario for business partners is created. The derivation scenario derives values for
the search terms in the general business partner data depending on the correspondence language.
Note: The intention of this example is to provide a very simple derivation scenario that can be used to test your change
request implementation.

Step Explanation Screenshot

1 Open the SAP Fiori

Launchpad and navigate to
the Data Quality
Management for Business
Partners section. Start the
Define Derivation Scenarios
Business Partners app.

2 Choose Create.

47
Step Explanation Screenshot
3 Enter the following data:
• Scenario ID:
Z147_BP_simple
• Scenario Name:
Derive general
business partner
data

In the Scenario Base Table

dropdown list, select General
(BUT000).
In the General Information
section, enter the
Description General
business partner
attributes are filled.

To narrow down the scope of

a derivation scenario,
maintain the scope
expression. Enter the
following Scope Description:
Scenario will be
applied if search term
1 is 'BP_SIMPLE'. Choose
Create.

4 The derivation scenario is

now in status New. Choose
Send for Implementation.

48
Step Explanation Screenshot
5 The derivation scenario is
now in status To Be
Implemented. Choose
Prepare Scope Expression.

6 Choose OK to acknowledge
that the base table can no
longer be changed.

7 The scope expression is

generated. Meanwhile the
derivation scenario is in
status Generation Running.
Wait and choose Refresh.

8 In the General Information >

Scope Details section, select
the scope expression link.

49
Step Explanation Screenshot
9 You are navigated to the
BRFplus Workbench. The
scenarios’ scope expression
is already displayed. Press
Edit.

Note: For each derivation

scenario, a BRFplus
application is created, which
you find in the repository on
the left. In our example it is
the application
Z147_BP_SIMPLE.
If you choose Context
Overview, you see the
context objects that are
automatically provided. In
our example, all fields of
table BUT000 and the fields
of the Derivation Context are
provided.

50
Step Explanation Screenshot
10 In the Detail section, choose
Edit Operand > Use Direct
Value Range From > Select
Context Parameter.

11 Under Search Criteria, enter

*Search* for Text and
choose Search.

12 In the result list, select

Search term 1 and choose
Ok.

13 In the input field to the right

of the operand, enter
BP_SIMPLE and choose
Save.

14 The (scope) expression is

saved. Navigate back to the
derivation scenario.

51
Step Explanation Screenshot
15 Back in the derivation
scenario, the Scope Status
is Inactive Changes.
Change the scenario status
to To Be Reviewed by
choosing Send for Review.

Note: The status

management allows a 4-eye
principle. With the approval
of the scenario the scope
expression will be activated
in BRFplus.

Choose Approve.

The scope expression is

activated. Meanwhile the
derivation scenario is in
status Generation Running.
Wait and choose Refresh.

The derivation scenario is

now in status Approved. The
scope expression is in status
Active.
Choose Edit.

16 In the Derivation Rules >

Derivation Rules for Fields
section, choose Create.

52
Step Explanation Screenshot
17 Enter BP1 as the Rule and
the Rule Name Search
term by language.

18 As the Result Table, select

General (BUT000).

Enter the Rule Description

Add correspondence
language to search term
2.

The derivation rule BP1

should work as follows:
If the correspondence
language is DE (German),
search term 2 shall be filled
with “Deutscher Kontakt”.
For all other correspondence
languages, the existing
search term 2 shall be
extended by “_OTHERS”.

19 In the Fields > Condition

Fields section, choose Add.

53
Step Explanation Screenshot
20 In the Select Condition
Fields popup, enter the
search term language and
press Enter. Select BUT000-
LANGU_CORR (Business
Partner: Correspondence
Language) from the result
list.
Choose Select.

21 The selected field is

transferred to the Condition
Fields.

22 In the Fields > Result Fields

section, choose Add.

23 In the Select Result Fields

popup, enter the search term
SORT2 and press Enter.
Select BUT000-SORT2
(Search term 2 for business
partners) from the result list.

24 All selected fields are

transferred to the Result
Fields.

25 Choose Apply.

54
Step Explanation Screenshot
26 You are navigated back to
the derivation scenario.
Choose Save.

27 Select the rule with the ID

BP1 and choose Set Status
> To Be Implemented.
Note: Changing the status is
only possible if the derivation
scenario is in display mode.

28 Navigate to the details of this

rule.

55
Step Explanation Screenshot
29 In the Implementation
section, press Create
Decision Table.

Note: Preparing a scope

expression for a rule is
optional.
Note: The actions for
preparing a scope
expression or creating a
decision table are available
only in display mode.

30 You are informed that the

decision table creation
started. The rule is in status
Generation Running.
Choose Refresh.

31 Select the link to the

decision table.

56
Step Explanation Screenshot
32 The BRFplus Workbench is
displayed. Choose Edit.

33 Insert two new rows by

pressing the plus button
twice.

34 For the Correspondence

lang. use the Direct Value
Input and enter EN. Choose
OK.

Note: The Correspondence

lang defines the condition of
the derivation rule.

35 For Search term 2, use the

Direct Value Input and enter
English speaking. Choose
OK.

36 In the second row, use the

Direct Value Input for the
correspondence lang. and
enter the values shown on
the screenshot. Choose OK.

37 For Search term 2, use the

Direct Value Input and enter
Other language. Choose
OK.

57
Step Explanation Screenshot
38 Choose Save to save your
changes.

39 Navigate back to the Define

Derivation Scenarios app.

40 Back on the page of the

derivation rule BP1, close
the subscreen.

41 Select derivation rule BP1

and set the status to To Be
Reviewed.

Note: These changes of

statuses would typically be
done by different persons
being involved in the setup
of a derivation rule.

42 Then, change the status of

the rule to To Be Approved.

58
Step Explanation Screenshot
43 Then, change the status of
the rule to Approved.

Now, all BRFplus artifacts of

derivation rule BP1 are
active.

44 In the column Execution, set

the execution switch to On.

Now, the derivation rule BP1

will be executed in all MDG
processes where derivation
scenarios are applied.

59
5. TIPS AND TRICKS FOR IMPLEMENTING DERIVATION SCENARIOS

5.1. Derivation for Business Partner (Customer/ Supplier) and Language for
Address
Use Case:
You want to derive the language for the main address.

Solution:
You have to distinguish between the partner category “Company” and “Person/Group".

If you use the field BUT000-BU_LANGU in the derivation rule for partner category “Company”, you will receive a
message: “You may maintain the language for oral communication only in the case of persons (business partner
category "Person/Group"). In this case you are dealing with a business partner of the business partner category
"Organization". The language is ignored.”
You should use for partner category “Company” the field ADRC-LANGU.

If you use the field BUT000- BU_LANGU in the derivation rule for partner category “Person/Group" the value is derived
and stored, but you don’t see this field on the UI. The field is not in the standard UI configuration. A derived value for
field ADRC-LANGU is ignored.

5.2. Existing Derivation for Business Partner (Customer/ Supplier)

When creating rules, note that derivations are already available in central governance, which are part of the handler
classes. It does not make sense to implement the same derivations in MDQ, as these can lead to duplicate data, which
also leads to inconsistencies.

Existing derivations for the BP and its sub-entities are:

1. derivation of the grouping (BP_HEADER) is only executed for the customer / vendor like UIs
2. derivation of the address type (ADDRESS) depends on the creation of a new address (ADDRESS) -> classifies
the address either as organizational address (if BP is an organization or group) or as person address (if the BP
is a person)
3. derivation of the address GUID (BP_ADDR) depends on the creation of a new address (BP_ADDR or
AD_POSTAL)
4. derivation of the match codes for names (BP_CENTRL) depends on new/changed central data (BP_CENTRL)
5. derivation of tax jurisdiction code and related attributes (AD_POSTAL) depend on address data (AD_POSTAL)
6. derivation of postal match codes (AD_POSTAL) depends on address data (AD_POSTAL)
7. derivation of the time zone (AD_POSTAL) depends on address data (AD_POSTAL)
8. derivation of the description (BP_HEADER) depends on address and central data
9. derivation of the long phone number (AD_TEL) depends on phone number (AD_TEL)
10. derivation of the long fax number (AD_FAX) depends on phone number (AD_FAX)
11. international versions of the person name (AD_NAME_P) need to be synchronized in all addresses
12. derive a contact person (BP_CP_GEN) for contact person relationships (BP_REL or TD_BPREL)
13. derive the validity period of addresses (BP_ADDR)

Existing derivations for the customer and its sub-entities are:

1. !!! REQUIRED FOR CUSTOMER LIKE UI ONLY !!!
The creation of a BP root (BP_HEADER) entity, the change of the BP grouping or the cross enhancement of a
BP/vendor trigger the creation of a new customer entity (BP_CUSGEN). The entity is a standard customer.
2. The change of the BP root (BP_HEADER) entity might trigger a change of the standard customer general data
(BP_CUSGEN) entity.
3. The change of the BP root (BP_HEADER) entity might trigger a change of the standard customer partner function
(BP_CUSFCN) entities.
4. The creation of a multiple assignment (BP_MLT_AS) entity triggers the creation of a new customer (BP_CUSGEN)
entity.
5. The change of a customer general data (BP_CUSGEN) entity triggers the change of one or more customer
general data (BP_CUSGEN) entities.
6. The change of the account group in a customer general data (BP_CUSGEN) entity triggers the update of tax
indicator (BP_CUSTAX) and partner function (BP_CUSFCN) entities.

60
7. The change of a sales area (BP_SALES) entity triggers the update of partner function (BP_CUSFCN) entities for
the current assignment.
8. The change of a supplier general data (BP_VENGEN) entity triggers the change of one or more customer general
data (BP_CUSGEN) entities.
9. The creation of a customer sales area (BP_SALES) entity triggers the defaulting of some values of the same
entity.
10. The creation of a sales area (BP_SALES) entity triggers the creation/change of partner function (BP_CUSFCN)
entities.
11. The creation/change/deletion of a sales area (BP_SALES) entity triggers the creation/deletion of tax indicator
(BP_CUSTAX) entities.
12. The change of the BP root (BP_HEADER) entity might trigger change of the standard customer general
(CUSGENTXT) and / or sales area (CUSSALTXT) text entities.
13. The change of the account group in a customer general data(BP_CUSGEN) entity might trigger a change of the
customer's general (CUSGENTXT) and / or sales area (CUSSALTXT) text entities.
14. The change of the BP's central deletion flag (BP_CENTRL) might trigger setting all central deletion flags of the
customer(s) and the organizational units (BP_CUSGEN, BP_CUS_CC, BP_SALES)
15. The creation of a customer company code (BP_CUS_CC) entity triggers the defaulting of some values of the
same entity.

Existing derivations for the supplier and its sub-entities are:

1. !!! REQUIRED FOR VENDOR LIKE UI ONLY !!!
The creation of a BP root (BP_HEADER) entity, the change of the BP grouping or the cross enhancement of a
BP/customer trigger the creation of a new supplier entity (BP_VENGEN). The entity is a standard supplier.
2. The change of the BP root (BP_HEADER) entity might trigger a change of the standard supplier general data
(BP_VENGEN) entity.
3. The change of the BP root (BP Header) entity triggers the update of partner function (BP_VENFCN) entities for
the standard assignment.
4. The change of the BP Tax Number (BP_TAXNUM) entity might trigger the update of the standard supplier
(BP_VENGEN) entity.
5. The creation of a multiple assignment (BP_MLT_AS) entity triggers the creation of a new supplier
(BP_VENGEN) entity.
6. The change of a supplier general data (BP_VENGEN) entity triggers the change of one or more supplier
general data BP_VENGEN) entities.
7. The change of the alternative payee in a supplier general data (BP_VENGEN) entity triggers the update of
partner function (BP_VENFCN) entities.
8. The change of the tax number in a supplier general data (BP_VENGEN) entity might trigger a change of BP
tax number (BP_TAXNUM) entities.
9. The change of the account group in a supplier general data (BP_VENGEN) entity triggers the update of partner
function (BP_VENFCN) entities.
10. The change of a purchasing organization (BP_PORG) entity triggers the update of partner function
(BP_VENFCN) entities for the current assignment.
11. The change of a customer general data (BP_CUSGEN) entity triggers the change of one or more supplier
general data (BP_VENGEN) entities.
12. The creation of a purchasing organization (BP_PORG) entity triggers the creation of partner function
(BP_VENFCN) entities.
13. The creation of a purchasing organization (BP_PORG) entity the defaulting of some values of the same entity.
14. The change of the BP's central deletion flag (BP_CENTRL) might trigger setting all central deletion flags of the
supplier(s) and the organizational units (BP_VENGEN, BP_COMPNY, BP_PORG)
15. The creation of a supplier company code (BP_COMPNY) entity triggers the defaulting of some values of the
same entity.

5.3. Type-4 entities must have at least one attribute

Use Case:
For example, you want to derive a new role for a business partner and you have created a derivation scenario with a
rule for table BUT100.

Solution:
You must also maintain at least one attribute in the rule. Otherwise, the new role will not be derived because type-4
entities with initial attributes are filtered out in the derivation result.

61
5.4. Provide Data via Extra Data Provisioning – DB Lookup
Use Case:
You need data that are not part of the context of your derivation rule.
Note: The data that are visible in the context overview provided in the BRFplus workbench are supplied automatically.

For example, you want to derive the currency for the field WAERS in table KNVV using the customizing values
provided in table TVKO.

Solution:
Create a DB Lookup in the BRFplus workbench and call this DB Lookup for the corresponding field.
For example, create a database lookup GET_WAERS (get currency TVKO) as shown below:

Select this expression for the currency field:

62
Note: the search offers all expressions that have the correct element type (in this example: Text). By default you see
the expressions that are part of the BRFplus application defined by the derivation scenario
(ZMDQS_147_<scenario_id> or ZMDQS_194_<scenario_id>). If you want to use expressions that are part of another
application, you have to adjust the search criteria.

5.5. Access Change Request Data

Use Case:
You need to access data differently, depending on where the derivation scenario is executed.
Note: A derivation scenario can be applied in a change request, in a mass process and in a consolidation process.

For example, you create a new business partner and want to use the field COUNTRY of the address table ADRC as a
condition field to retrieve the correct sales organization. In a change request the value need to be read from the staging
area whereas for mass processing and consolidation the value is read from the process tables.

Solution:
In the definition of the derivation rule you have to set the flag that allows the configuration of additional condition fields.

In the BRFplus workbench, you have to add an additional column to the condition decision table using the table
settings. Here you call e.g. the case expression shown below. The usage field can be found in the derivation context.

63
MDF_COUNTRY is an example of a procedure call used to read the country field from the staging data.

The class the implements the procedure call of this example uses the following code:
"! <p class="shorttext synchronized" lang="en">Country for MDQ147_CUST_SALES_KNVV</p>
CLASS zcl_mdq147_cust_sales_knvv DEFINITION PUBLIC FINAL CREATE PUBLIC .

PUBLIC SECTION.
"! <p class="shorttext synchronized" lang="en">Get the country of the standard address</p>
"!
"! @parameter change_request | <p class="shorttext synchronized" lang="en">Change Request</p>
"! @parameter country | <p class="shorttext synchronized" lang="en">Country of the BP's standard address</p>
CLASS-METHODS get_country_standard_address
IMPORTING
!change_request TYPE usmd_crequest
RETURNING
VALUE(country) TYPE land1 .

PROTECTED SECTION.
PRIVATE SECTION.

"! <p class="shorttext synchronized" lang="en">Model-Ext-API instance</p>

CLASS-DATA model TYPE REF TO if_usmd_model_ext .

"! <p class="shorttext synchronized" lang="en">Get an instance of the Model-Ext-API</p>

"!
"! @parameter result | <p class="shorttext synchronized" lang="en">Model-Ext-API instance</p>
CLASS-METHODS get_model
RETURNING
VALUE(result) TYPE REF TO if_usmd_model_ext .

"! <p class="shorttext synchronized" lang="en">Get the BP ID from the Change Request</p>
"!
"! @parameter model | <p class="shorttext synchronized" lang="en">Model-Ext-API instance</p>
"! @parameter change_request | <p class="shorttext synchronized" lang="en">Change Request number</p>
"! @parameter result | <p class="shorttext synchronized" lang="en">Business Partner ID (as USMD_VALUE)</p>
CLASS-METHODS get_bp_no_of_change_req
IMPORTING
!model TYPE REF TO if_usmd_model_ext
!change_request TYPE usmd_crequest
RETURNING
VALUE(result) TYPE usmd_value .
ENDCLASS.

64
CLASS zcl_mdq147_cust_sales_knvv IMPLEMENTATION.

METHOD get_model.
IF model IS INITIAL.
"Get a model-ext instance.
cl_usmd_model_ext=>get_instance(
EXPORTING
i_usmd_model = 'BP'
IMPORTING
eo_instance = model ).
ENDIF.
result = model.
ENDMETHOD.

METHOD get_bp_no_of_change_req.
"Get the given change request's object list
DATA(keys) = VALUE usmd_ts_entity_data( ).
model->get_cr_objectlist(
EXPORTING
i_crequest = change_request
IMPORTING
e_count = DATA(count)
et_key_all = keys
).
"Abort further processing if there are no objects in the given change request.
CHECK count > 0.

"Get the (eventually temporary) Business Partner number.

READ TABLE keys WITH KEY entity = 'BP_HEADER' INTO DATA(key).
FIELD-SYMBOLS <tab> TYPE HASHED TABLE.
ASSIGN key-r_data->* TO <tab>.
LOOP AT <tab> ASSIGNING FIELD-SYMBOL(<any>).
result = <any>.
EXIT.
ENDLOOP.
ENDMETHOD.

METHOD get_country_standard_address.
DATA(model) = get_model( ).

"Create an internal table to receive the read addresses.

model->create_data_reference(
EXPORTING
i_fieldname = CONV usmd_fieldname( 'AD_POSTAL' )
i_struct = model->gc_struct_key_attr
if_table = abap_true
i_tabtype = model->gc_tabtype_sorted
IMPORTING
er_data = DATA(lr_data) ).
ASSIGN lr_data->* TO FIELD-SYMBOL(<entity_data_tab>).

DATA(bp_number) = get_bp_no_of_change_req( model = model change_request = change_request ).

DATA(select_options) = VALUE usmd_ts_sel( ( fieldname = 'BP_HEADER' sign = 'I' option = 'EQ' low = bp_number ) ).

"Read the Business Partner's addresses.

model->read_char_value(
EXPORTING
i_fieldname = CONV usmd_fieldname( 'AD_POSTAL' )
it_sel = select_options
i_readmode = if_usmd_model_ext=>gc_readmode_all_inact
if_no_flush = abap_true
IMPORTING
et_data = <entity_data_tab> ).

"Take the first available country.

LOOP AT <entity_data_tab> ASSIGNING FIELD-SYMBOL(<entity_data>).
ASSIGN COMPONENT 'REF_POSTA' OF STRUCTURE <entity_data> TO FIELD-SYMBOL(<any>).
IF sy-subrc = 0.
country = <any>.
EXIT.
ENDIF.
ENDLOOP.
ENDMETHOD.

ENDCLASS.

65
GET_COUNTRY_ADRC is an example of a database lookup to read the country field from the process table.

5.6. Debugging the Derivation for a Change Request

API CL_MDG_MDQ_RBWF_DERIVE writes an application log (transaction code SLG1) using log object FMDM and subobject
CREQUEST. The success/information messages in this log do not indicate a successful derivation. Whether the data you
expect to be derived actually got written to the change requests is not indicated here.

In this log there are typically the following relevant information messages:
• 'Derivation started' which means API CL_MDG_MDQ_RBWF_DERIVE got called
• 'Initialze mappings' which indicates the data mapping between central governance-based and MDQ Derivation-
based data structure could be initialzed
• 'Map change request data to objects for derivation' which indicates a successful data mapping
• 'Execute derivation' which indicates that the derivation API CL_MDG_MDQ_SERVICE_DERIVE has been called
successfully (This is independent from the success/failure of the actual derivation.)
• 'Map derived data to change request' which indicates a successful data mapping
• 'Derivation finalized' which means the processing in API CL_MDG_MDQ_RBWF_DERIVE ends

This application log does not show any errors or other messages that occur during actual derivation. It may however
contain errors e.g. when writing data to the change request (like in the next screenshot). As you can see the success
messages mentioned above are there anyways (at the beginning and end of the log).

66
To analyze/debug the MDQ derivation for a change request you may use program MDG_MDQ_SERVICE_DERIVE. For
analysis purposes you can trigger the MDQ derivation for a given change request. The derived data could either be
written to the change request (Save derived data) or discarded (Discard derived data). The latter option enables you to
repeat the analysis without writing derived data to the change request.

6. ADDITIONAL INFORMATION

6.1. Further Reading

Information on SAP MDG on SAP S/4HANA
• Exchange knowledge: SAP Community | Q&A | Blog

67
 • Try SAP Master Data Governance on S/4HANA for free: Trial Version
• Learn more: Latest Release | Webinars | Help Portal | How-to Information | Key Presentations

SAP Roadmap Explorer

• Please see the roadmap for SAP Master Data Governance

Related Information
• Learn more: Floorplan Manager for Web Dynpro ABAP | How to Adapt FPM | FPM Blog | How-to Information |
Service Mapping Tool | SAP S/4HANA Cookbook CVI |
Other
• Video for Define Derivation Scenarios
https://video.sap.com/media/t/1_lywvk6rb/65627981

6.2. SAP Notes

In addition to the detailed explanations written in this document, please see the following SAP Notes for further
important information.

Note Number Note Description

(Bugfix) MDQ-Derivations in Central Governance: Incorrect result at mapping errors,
3441690
Store messages in a suitable structure

Functional restrictions in MDG for Business Partner / Customer / Supplier with SAP
2313368
Master Data Governance 9.0
Functional restrictions in MDG for Business Partner / Customer / Supplier with SAP
2472845
Master Data Governance 9.1
Functional restrictions in MDG for Business Partner / Customer / Supplier in SAP Master
2656712 Data Governance 9.2 and on SAP S/4HANA 1809
Functional restrictions in MDG for Business Partner / Customer / Supplier on SAP
2816557
S/4HANA 1909
Functional restrictions in MDG for Business Partner / Customer / Supplier on SAP
2925030
S/4HANA 2020
Functional restrictions in MDG for Business Partner / Customer / Supplier on SAP
3070003 S/4HANA 2021
3194967 MDG Customer Connection 2021 for S/4HANA 2022
3043582 MDG Customer Connection 2020

1806108 Functional restrictions in MDG-M in MDG7 (incl. SP02)

2129261 Functional restrictions in MDG-M in MDG8
2284745 Functional Restrictions in MDG for Material with SAP Master Data Governance 9.0
2461516 Functional Restrictions in MDG for Material with SAP Master Data Governance 9.1
Functional Restrictions in MDG for Material in SAP Master Data Governance 9.2 and on
2656693
SAP S/4HANA 1809
2816571 Functional Restrictions in MDG for Material on SAP S/4HANA 1909
2948873 Functional Restrictions in MDG for Material on SAP S/4HANA 2020

68
2479869 Usage of Lean Classification with SAP Master Data Governance
3070012 Functional Restrictions in MDG for Material on SAP S/4HANA 2021
3219945 Functional Restrictions in MDG for Material on SAP S/4HANA 2022

69
www.sap.com/contactsap

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National
product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein.
This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may
be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or
functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on
these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/trademark for additional trademark information and notices.