SAP Data Medium Exchange: A Guidebook for The SAP Consultant

Preface

“Our potential is one thing. What we do with it is quite another.”

― Angela Duckworth, Grit: The Power of Passion and Perseverance

Allow me to start by sharing that striking quote from one of my favorite books. In my perspective, that
quote clearly explains why I chose to create this book. We were all SAP Freshers at one point struggling
to understand technical concepts, processes, configurations, and more. To me, it was a challenge to really
understand the technical aspects of SAP as a fresher or junior consultant back then. The corresponding
trainings would be formal and quite extensive but I felt that I needed something more.

As a beginner at the time, I needed something a bit more casual and less technical. I naturally found myself
searching for extra learning materials online. This obviously involved numerous search engines, websites,
and even formal online trainings. After gathering those materials, I decided to tinker around with the
configurations in SAP. Why? Because I needed to understand why that setting was there in the first place.
What was its purpose?

After several years in the industry, so far, I have worked in a total of 3 Fortune 500 companies dealing
with SAP and even Non-SAP technologies. From support, management, project implementation, and
delivery to dabbling in other technologies as part of system integration work, I have gotten a taste of how
systems work with one another. This has opened up my perspective on technology and how enterprises
work – it has allowed me to see the bigger picture.

Being an SAP Consultant focusing on SAP FICO and SAP S/4HANA Finance, I decided to write this book that
focuses on SAP DME or Data Medium Exchange. This topic can be complex and confusing for beginners.
This is why I have written it in the simplest way I can.

My aim is to help you understand the topic rather than just knowing the configurations. This is why you
will see explanations on several settings as we go through the chapters. I hope that in turn, it helps you
see the whole DME picture.

What we will discuss:

• End to End Process of SAP DME and Testing

• SAP DME Overall Configuration
• SAP Transaction Code DMEE focused (Visual Comparison DME XML Tree and XML File Output)
• SAP DME Scenario: Modifying DME Trees and How to Generate DME File Output
• SAP Note to Payee Functionality
• SAP Question Bucket SAP Data Medium Exchange and XML DME Tree

Note:

• This book focuses on the DME XML Tree’s and XML File Output.
• Any resemblance to real data is purely coincidental.
• Examples used in this book are simplified for tutorial purposes and are loosely based on SEPA
Credit Transfer payment method.
• Scenarios and explanations in this book will focus on the country Belgium but in essence, the high-
level behavior would be similar to other countries.
• You need your own SAP ONE Support Launchpad access to open links to SAP Notes.
• The information contained in this book was originally published in Techlorean.com and this book
was created to provide an on-the-go copy or reference. Minor edits have been made on this book
to accommodate proper formatting and wording.
Contents
Preface .......................................................................................................................................................... 2
CHAPTER 1: What is DME in SAP? End to End Process and Testing ............................................................. 5
Process Flow ............................................................................................................................................. 5
How does DME relate to SAP Payments? ................................................................................................. 7
SAP DME Configuration (High Level and Summary) ................................................................................. 8
Testing Proper (DME Only – Quick) .......................................................................................................... 8
Testing Proper (Detailed) ........................................................................................................................ 10
CHAPTER 2: SAP DME Overall Configuration (Simple Explanation and Detailed Steps) ............................. 16
Configuration Objectives ........................................................................................................................ 17
OBPM1 .................................................................................................................................................... 17
FBZP......................................................................................................................................................... 19
DMEE ....................................................................................................................................................... 25
OBPM4 .................................................................................................................................................... 25
Summary ................................................................................................................................................. 27
CHAPTER 3: SAP DME Tree Configuration – DMEE Focused (Simple Explanation) .................................... 29
Configuration and Visualization .............................................................................................................. 30
Final Output ............................................................................................................................................ 54
CHAPTER 4: SAP Data Medium Exchange Scenario: Modifying DME Trees and How to Generate DME File
Output ......................................................................................................................................................... 63
Before Changes ....................................................................................................................................... 63
Change Proper ........................................................................................................................................ 64
Post Change Testing – How to Generate DME File ................................................................................. 69
CHAPTER 5: SAP DME Note to Payee Functionality .................................................................................... 84
What is a Note to Payee? ........................................................................................................................ 85
Configuration and Checklist .................................................................................................................... 85
Testing ..................................................................................................................................................... 98
Note to Payee Output ............................................................................................................................. 99
CHAPTER 6: SAP Question Bucket | SAP Data Medium Exchange and XML DME Tree............................ 102
About the Author ...................................................................................................................................... 109
Disclaimer.................................................................................................................................................. 109
CHAPTER 1: What is DME in SAP? End to End Process and Testing

DME stands for Data Medium Exchange and you can associate it with SAP Payments. For this chapter I
will use Belgium related scenarios to help you visualize.

This chapter assumes that you have already created the DME tree and it is ready for testing. If you need
guidance for the creation of the actual DME tree, it will be covered in another chapter. For now, let us
focus on the process, testing, and high-level information.

It has the same cycle, but you can expect slight differences (i.e. file format) in other countries or SAP
systems. Either way, you can read through this chapter to understand the purpose of DME.

Overview

• Process Flow
• How does DME relate to SAP Payments?
• SAP DME Configuration (High Level and Summary)
• Testing Proper (DME Only – Quick)
• How do I activate my tree? (Additional Help)
• Testing Proper (Detailed)
• Testing Steps Summary
• Additional Information / Tips

Process Flow

1. Accounting Documents exist that need to be paid through Payment Run (F110)

• Let us consider Vendor items due for payment.

2. Payment Run is executed (Proposal and Actual Run) which will generate a payment medium
file or output.

• Usually, payment medium file is generated for the Actual Run and NOT the Proposal to
prevent risky or erroneous scenarios.

• In this example, our payment medium file or output will be an XML file (pink box).

3. This XML file will be provided to the bank or it will be uploaded to an online banking system or
portal.
 • A good example would be Isabel since it has the capability to carry out multiple
transactions for several banks in one portal.

• .XML files usually have the payment information indicated.

• NOTE: This is where the payment medium output checking stops but you may proceed up
until the bank statement post processing.

4. When transactions have completed, the bank sends an Electronic Bank Statement (EBS). In this
example, Belgium banks send CODA or .COD files (white box) with the corresponding payment
details / transactions.

5. This .COD file or the Belgium Bank Statement is then uploaded to SAP through FEBC (program
RFEBBE00) where it will be “consumed” and converted to Multicash Format.

• If the file is interpreted and converted to Multicash Format, you will see the results in
FEBAN where you can do bank statement post processing such as clearing etc.

• If conditions are met upon file analysis, documents would be created. Here you can view
if the necessary amounts are posted to the intermediary bank GL accounts etc.

6. If SAP can see a fully met condition that triggers an Interpretation Algorithm, it will follow the
configured settings accordingly.

• For example: if conditions are met for Interpretation Algorithm 19 (Reference no. DME
management), it will proceed with the “auto clearing” setup.

You may refer to the full image below where the green circle signifies the starting point while the red circle
signifies the end point.
 Purple signifies SAP System, Blue signifies online banking, White signifies a file.

How does DME relate to SAP Payments?

From the process above, you can associate DME to the .XML file that generated as the payment medium
file. In the image below, I have colored it pink.

You may be wondering why the word DME was indicated in the 1st box. The reason is because DME is
triggered by the payment run (F110) and the output is the .XML file.

DME Output = Payment Medium Output; In our example it is the generated .xml file.
Formally speaking, DME creates a file that contains payment details and serves as instructions to the
bank. In our example, this was the .XML file.

In order to create the right file (that will be understood by the bank or online bank portal), it needs to be
setup in SAP.

Note: that DME does not solely pertain to .XML files. You can also generate the payment medium file as
a flat file. It would also depend on the linked ABAP program that creates these files. A custom program
can be built to accommodate different formats that are not doable in standard SAP.

SAP DME Configuration (High Level and Summary)

• Create Payment Medium Formats (OBPM1)

• Create Your DME Format Tree using the Data Medium Exchange Engine (DMEE)

• Link Payment Method to the Payment Medium Format (FBZP)

• Maintain Payment Medium Selection Variants / Assign Payment Medium Format to the house
banks concerned (OBPM4)

Testing Proper (DME Only – Quick)

If you want to do a quick test on your DME Tree, you can do so via DMEE transaction code. Note that this
will only show the sample output. It can be useful but if you want a realistic scenario you can follow the
steps provided below in Testing Proper (Detailed).

• DMEE Enter your Tree Type and Format Tree then click on the Test Active Version Button
(highlighted in red).

• You will be shown the screen below. Click on the Test Button. Once clicked, a new window will
show you the .xml sample output. There you can do a check of the .xml tags included and the
details as well.
NOTE: If you want to be sure, it is advisable that you do an actual test payment run to see the realistic
populated values. This can give you peace of mind on the tree output.

How do I activate my DME Tree? (Additional Help)

• In the DEV environment, go to transaction code DMEE and enter the Tree Type and Format Tree.
Then click on the Change button.

• You should see a Wand Button (Activate). Click on it to activate your tree.

• IMPORTANT: It is important to ensure that you save your DME Tree in a transport. It is equally
important to ensure that the ACTIVATION status is saved in the transport as well. If you are making
a change to an already existing DME Tree, be sure to create a copy and/or backup just in case.
 • You will know it is your version by checking on the Last Changed By logs:

• If there are other versions maintained, you can switch, compare, and do some checking by clicking
on Utilities > Versions > Version Management

Testing Proper (Detailed)

This will help you create test data and perform validations. It helps to have data you can reference from
production or you can also find applicable test data and create from reference (if applicable).

• FB01 Create Accounting Document for Payment Run

• Example: Posting Key 25 Outgoing Payment Vendor Number and Posting Key 35 Incoming
Payment. You can use the proper posting keys set up for your scenario / SAP system.

• If you have a reference document (or a good document existing in the test system) you
can “Post with Reference” and update the values according to your need.
• F110 Create Payment Run and narrow down data by specifying parameters such as vendor
number, company code, docs entered up to, payment methods, and even document number (in
free selection tab).

• When referencing from production, be sure to copy the entries in printout / data medium
tab. If it is blank, then leave it blank.

• I will create a separate post on detailed F110 inputs and testing.

• Execute Payment Proposal (no need for payment medium if you don’t need). After this
you can review the pulled documents and check if there are errors.

• Execute Payment Run (IMPORTANT: be sure to tick the Create Payment Medium
checkbox)

• If successful, you should see a green square light with details on Posting Orders.
Posting orders generated and completed 2 because I created 2 test documents due for payment. The
result also corresponds to the parameters set in F110.

• AL11 Check on the generated .XML file. If you have access to the file repository, you can directly
check there. If not, download the .XML file from AL11 via CG3Y (or refer to How to Download Files
from AL11) to double check on entries.

• Check on your payment medium output setup. If it is configured to save the payment
medium in a secured folder or directory, you will find it there. Logs can be seen in the
payment run of F110.

• Refer to the purple highlight to know what the filename is and where it was saved.

• Refer to the yellow highlight to check on the spool no. (if needed) through SP01.

• If you do not have an external .COD file generator you can pull any available .COD file from
production and manipulate the data carefully to match the details from payment run.

• If the .COD file can be provided from someone else, you can utilize it.

• FEBC Upload the test .COD file to SAP.

• If you encounter errors here it would most likely be the result of formatting issues.
 • FEBAN Double check results and perform post processing.

• This is where you check the populated fields and auto-clearing (if applicable)

Testing Steps Summary

• FB01
• F110
• AL11 (CG3Y to download if needed)
• FEBC
• FEBAN

1. FB01 Create Accounting Document for Payment Run

2. F110 Create Payment Run and narrow down data by specifying parameters such as vendor
number, company code, docs entered up to, payment methods, and even document number (in
free selection tab).

3. AL11 Check on the generated .XML file. If you have access to the file repository, you can directly
check there. If not, download the .XML file from AL11 via CG3Y (or refer to How to Download Files
from AL11) to double check on entries.

4. If you do not have an external .COD file generator you can pull any available .COD file from
production and manipulate the data carefully to match the details from payment run.

5. FEBC Upload the test .COD file to SAP.

6. FEBAN Double check results and perform post processing.

Additional Information / Tips

It is understood that the end to end testing in SAP will help you validate your work (aside from business
user confirmation). I personally tend to do an extra step outside of SAP. Allow me to explain why I do this.

Extra Step (Additional Test)

Ultimately, we are dealing with payments and bank related files. I mentioned that it is highly advisable to
do a “penny test” or a “euro cent test” in production with the help of the concerned business user in prior
to doing a bulk load of payments.

This small production test helps give the assurance that the changes are indeed working as expected. If
something goes wrong, it will be seen in the penny / euro cent test and you would have avoided messing
up bulk transactions in production.

As an added measure, I make use of an online tool called xml validator. IMPORTANT: I use this for Belgium
related validations and SEPA payments. I am sharing this as an optional extra step for you.

Once I have generated my payment medium output (xml file) in the test environment, I head over to
the online tool and upload the xml there for checking. Refer to the image below for what the tool looks
like.
Select the file and click on the Confirm File Button.

If the file is validated successfully, you will see green results (as seen in the image below). You also have
the following options in line with the uploaded .xml file:

• Download statement of account (CAMT)

• View the Processed Payment Information

• View the content of the uploaded file. There will be a black screen at the right side of the result
page showing the .xml file content. I have not included it in the screenshot for confidentiality
purposes.

Successful Validation

The screens above are for SEPA / Belgium related payments. The online tool I shared is utilized specifically
for that kind of validation. You might have noticed that it was able to understand the payment overview
in the file.
If you want to do other checks that are not covered by this tool, you can try searching for others or using
the usual xml validation tool found online but keep in mind that it more or less checks the syntax and not
necessarily the validity of “payment transaction”.
CHAPTER 2: SAP DME Overall Configuration (Simple Explanation and
Detailed Steps)

SAP DME Configuration

Previously, we had a deep dive discussion on transaction code DMEE where most of the configurations
are for the DME Tree creation. This time, we will focus on the overall configurations involved for DME.

The whole DME topic can be complex depending on the requirements and can be a handful to learn in
one sitting. As such, I have created a separate and detailed chapter for transaction code DMEE or DME
Tree creation. The rest of the configurations will be found in this chapter.

Recall: As seen in previous chapters, DME or Data Medium Exchange goes hand in hand with SAP
Payments. It is triggered through payment run where you can expect a payment medium output.

Overview

• Configuration Objectives
• OBPM1
• FBZP
• DMEE
• OBPM4
• Summary
• Additional Information
Configuration Objectives

Before we start with the actual configuration proper, let us try to understand our objectives. Ideally, we
want to be able to create a payment medium output. In this scenario (or for our example), we want to be
able to:

• Generate a payment medium output (XML file output) upon automatic payment run (F110).

• Ensure that SAP will pull the right payment medium output template by linking the concerned
payment method and country combination.

OBPM1

In this part of the configuration, you will create a payment medium format and define its settings. Please
remember to use the same name as your DMEE tree later on.

The payment medium format screen consists of the following sub folder settings:

1. Event Modules for Payment Medium Formats

2. Format Parameter Required Fields

3. Supplements for Payment Medium Formats

4. Text Fields for Reference Information

In the image below, we created payment medium format “SEPA_CT”, selected that entry, and clicked on
more details (see arrow).

OBPM1

You will encounter a similar screen below. This is where you will define the payment medium format
settings according to the format requirements.
OBPM1

Notice how we specified “Electronic Payment Medium “and File Type “XML” since our example scenario
expects to generate an XML file.

For those wondering “What is FPM_SEPA?” You can refer to the last chapter of this book “SAP Question
Bucket”.

Moving forward to our sub folder settings, click on “Event Modules for Payment Medium Formats”.

Here you need to define all concerned exit modules / function modules that you will utilize in your DME
Tree creation / DMEE.

OBPM1
The next 2 sub folders are not necessarily needed for our scenario.

If you need to indicate settings for “Format Parameter Required Fields (required fields from the format
structure)” and “Supplements for Payment Medium Formats (additional format supplements), you may
do so.

The last sub folder “Text Fields for Reference Information”, is only utilized for Note to Payee functionality.
If you need to more about this setup, you can refer to the chapter “SAP DME Note to Payee Functionality”.
Else, you can just leave this blank for now and come back to it later on.

OBPM1 For Note to Payee Functionality

For more information about the format of the Payment Medium Workbench and the necessary
Customizing settings for SEPA CT, please check SAP Note 1062489.

FBZP

In this part of the configuration, you will configure the SAP Automatic Payment Program (transaction code:
F110).

The idea is to link the DME template to the proper payment method in FBZP such that when F110 is
executed, the linked payment medium format for our payment medium output will be generated.

In FBZP, we will focus on 2 buttons for the linkage proper.

• Pmnt methods in country (priority when using DME Engine)

• Pmnt methods in company code (additional information only)

FBZP

Pmnt methods in country (priority when using DME Engine)

Here you will select the country and payment method combination and click on more details as seen in
the image below.

FBZP

You should be presented with the screen below.

This is where we will configure the settings for our payment method. The basic settings are highlighted
below as well.
FBZP

FBZP

The significant part of this configuration lies in the yellow highlighted area. This is where you specify or
link the payment medium format.

Here we selected “use payment medium workbench” and specified the format “SEPA_CT”.

Ideally for each payment method and country combination, you should define the following basic
requirements:
 • Payment type (orange highlight): Specify if the payment method will be for outgoing or incoming
payments.

• Characteristics for classifying the payment method (green highlight): The method of payment
and its characteristics. In our example, we specified bank transfer and allowed for personnel
payments. The rest of the settings will be up to your requirements.

• Master record requirements (purple highlight): Requirements of a particular payment method

(such as the address requirement) that should be met for invoices to be paid with the payment
method. In our example, we required Bank Details, IBAN, and SWIFT Code. If those are not
maintained, then the payment run using this payment method should not push through.

• Document types (pink highlight): The document types used for posting and clearing documents.
These are standard SAP document types.

• Print program (yellow highlight): The print program and the print data set for the payment
method. This is where we linked the payment medium format.

For the next images, we will move on to the sub folders in this configuration:

• Currencies Allowed: This allows you to restrict the payment methods to a specific currency. If you
leave this blank, then the payment method is valid for all currencies. In our example, we restricted
the payment method “S” to EUR currency only.

FBZP

• Permitted Destination Countries: This allows you to restrict payment methods to specific
destination countries. In our example, we left the entry blank so that this payment method will
be allowed for ALL countries.
FBZP

• Note to Payee by Origin: This allows you to link Note to Payee settings from transaction code
OBPM2. You may refer to the chapter “SAP DME Note to Payee Functionality” for more
information.

To avoid information overload, this section will simply focus on the linkage of DME template.

Pmnt methods in company code

Going back to FBZP and clicking on the “Pmnt methods in company code” button, you will see the screen
below. Select the company code and corresponding payment method (emphasized in blue), then click on
more details (see arrow).
FBZP

The following settings below are simply provided for additional information purposes only.

For example, if I use Payment Method “S” and indicated a minimum amount of 1.000.000.000,00 EUR then
I should expect an error in F110 if I try to pay an invoice worth 100 EUR.

FBZP

On the bottom of the same screen, let us focus on the payment advice control area. This is another Note
to Payee functionality setting.
FBZP

Note that we will focus on DME related settings only to avoid information overload.

In essence: when it comes to linking a DME template or payment medium format, we focus on the
payment method – country level setting not on the company code level.

DMEE

In this part of the configuration, you will be creating the actual DME tree. Here you will configure the
actual settings, formatting, details, mapping, etc. of the DME tree. Basically, your payment medium output
should follow the format and structure as configured in transaction code DMEE.

As mentioned, you can refer to the next chapter for a detailed step by step guide. This chapter will mainly
focus on the rest of the configurations to avoid information overload.

OBPM4

In this part of the configuration, you will specify your payment medium format per company code and
house bank.
OBPM4

To edit a specific variant, click on Variant > Edit Variant.

OBPM4

This action will redirect you to the screen below. This setting focuses on the payment medium format and
print/output settings.
OBPM4 – Variant Edit

For those curious on the filename above, this is an example path that points to a server folder where the
payment medium files will be stored upon generation.

Meaning to say, when F110 is run and a payment medium output is created, the file should be stored in
the maintained server location.

Summary

• OBPM1 – Create Payment Medium Format

• FBZP- Link Payment Medium Output to Payment Method and Country Combination

• DMEE – Creation of DME Tree Structure and Format

• OBPM4 – Payment Medium Output separation (specify per company code and house bank
combination) + Payment Medium Format Print / Output Settings

Note

The example above is loosely based on SEPA Credit Transfer payment method so you may find some
similarities. The information below is created for tutorial purposes only but the general idea remains the
same for other payment methods. You need to be able to create the payment medium output format and
link it to the concerned payment method and country combination.

Hopefully by the end of this chapter, you will understand the purpose of the configurations.

Remember
The proper payment medium output may differ from country to country (country-specific) and some
banks may have other specific requirements. Be sure to consider those when you do your configurations.
CHAPTER 3: SAP DME Tree Configuration – DMEE Focused (Simple
Explanation)

SAP DME Tree Configuration – DMEE Focused (Simple Explanation)

In this chapter, we will focus on transaction code DMEE to understand how to configure the DME tree
and align it with the intended requirements. We will discuss a scenario where a sample DME tree will
be created and towards the end of the chapter, you should be able to see the file output.

This topic can be complex depending on the requirements and can be a handful to learn in one sitting. As
such, I have removed the other chunks of configuration and focused on the Data Medium Exchange Engine
(DMEE) or DME Tree creation for now.

As seen in previous chapters, DME or Data Medium Exchange goes hand in hand with SAP Payments. It is
triggered through payment run where you can expect a payment medium output.

Our example will show you a file output by form of an XML file. We will use this XML file to compare the
information seen on the file to transaction code DMEE. This approach will help you visualize the
configuration in DMEE in relation to the file output.

Overview

• Configuration and Visualization

• Creation of DME Tree
• DME Tree Properties
• DME Tree Creation of Nodes
 • Final Output
• Additional Information

Configuration and Visualization

As you know, our main transaction code for this chapter will be DMEE. Please be aware that the examples
used in this chapter are random and created for tutorial purposes to help you understand how DMEE
works

Creation of DME Tree

1. Go to Transaction Code DMEE, Enter the Tree Type and Format Tree, then click Create.

• Tree Type: PAYM

• Format Tree: Z_DMESAMPLE_XML

2. You will encounter the question “What kind of file would you like to create with the DMEE format?”.
In our example, we will be using XML. As such, click on the XML file button.
DME Tree Properties

3. You will now end up in the DMEE tree creation screen. For now, we have 1 row called “DMEE tree:
properties”. You need to fill out the tabs first before creating anything else. The screenshot below shows
that we are populating the “Administrative Data Tab”

• Short Description: Z_DMESAMPLE_XML DESCRIPTION

You can leave the documentation blank for now since that will only generate a Warning.
4. Click on the next tab called “Format Attributes”. Here you will see entries for Format Data and Print
Accompanying Sheet. You can click on F1 on your keyboard per field to understand the usage more.

For XSLT Program, refer to additional information for more details.

In the example below, I indicated Structure FPM_SEPA in the format specific structure field so I can use
its fields later on when I do mapping configurations for format purposes. If you do not need this, you can
leave this blank.

• Fmt-spec.strct.: FPM_SEPA

• Print accompanying sheet: Without accompanying sheet

In this example, I do not need an accompanying sheet. If you need more information on this, you can
check out the SAP Note on Accompanying sheet for a DMEE format .
Here is a screenshot of the FPM SEPA Structure Parameters for SEPA Formats. This means that later on I
can use the components or fields later on when I do mapping for format purposes.

5. Click on the next tab called “Levels”. Here you will see a Level column and a Repetition Factor column.

• Level 0 – Repetition Factor 9999999

• Level 1 – Repetition Factor 1

• Level 2 – Repetition Factor 9999999

This may be intimidating, but simply think of this as how many times (repetition factor) the information
can be repeated per level.

What is the use of Levels in SAP DMEE?

Consider Scenario 1 above where we said Level 1 will only repeat once and Level 2 can repeat 9999999
times. Now look at Scenario 1.1. This means that Level 1 details will only occur once per output file and
Level 2 details can occur multiple times in an output file.

Level now talks about the hierarchy of the data in your output file. Level 1 can serve as the header or in
our example <Document> </Document>.

This time let us consider Scenario 2 where we added a Level 3 and set the repetition factor to 9999999.
This means that Level 3 can only occur multiple times in a file. If you notice, <Information> </Information>
details are within the <Payment Details></Payment Details> thus it being Level 3 in the hierarchy.

6. Click on the next tab called “Sort / Key Fields”. Here you will specify what type of information
(structure and field) you can find per level. In our example below, we are saying that we need some
fields from Structure FPAYH, and these details will be found on Level 2.

Since we specified Level 2, that means we expect these details can be repeated multiple times in one
output file.

If you select the Key Field, it means that any change in the value tells SAP that the level has ended. If you
select the No Sorting Field, then there will be no sorting whatsoever for that field in that specific level.

In our example, DOC1R is a field denoting a payment reference from Structure FPAYH and we indicated
Level 2. In this case, we can expect multiple payment references (up to 9999999 times) to occur in one
output file.
7. Click on the next tab called “File Data”. Here you need to specify which characters you want to allow
OR which characters you do not allow.

• Character Definition : Do Not Allow These Charact.

• +^”$%&{[]}=`*~#;_!’

DME Tree Creation of Nodes

8. You are now done with the DMEE tree properties. You can now create nodes according to your needs.
As a refresher, below is a Node Legend for you to refer to. You can always go to Extras > Node Legend
for information. Click on the Information Icon to obtain details for each.
It can be quite technical, but I have added some personal keywords per node. Feel free to use your own
keywords according to how you best understand them.

Node Key Words

Element XML Tag

XML Attribute Details inside an XML Tag

This won’t show up in the XML file. You can define exit modules / function modules
Technical Node
here or even store values from other nodes here.

To define a mapping rule or more than one mapping rule. You need to display
certain values in one line from different fields. For example, use 3 atoms to output
Atom
the combination of 3 difference numerical codes from diff fields from SAP to make
up a one liner combination like “Field1 + Field2 + Field3” = “AA123BB”

Selected Node You double clicked the node and have it currently selected. You are viewing this
for Detail View node.

Reference ID of
You have entered details in the Reference ID field in the Node.
Node
 Reference to
You referenced another Node (by indicating the Reference ID either through
Another Node
mapping rules, conditions, or aggregation).
Exists

SAP DME Node Legend

9. Right click on DMEE tree: properties and Select Create Element. You should have a New Element as
seen in the screenshot below.

Let us analyze our XML file below. We want to show the <Document></Document> tags in the output file
and we need to make sure it only occurs once.

10. In our New Element row, we filled up the details below.

• Name: Document (This will output <Document> </Document> tags)

• Short Description: Document Tag

• Level: 1 (We put level 1 meaning I want this to repeat only once)

• Mapping Procedure: No Mapping (No mapping It is just a tag we want to output.)

• Other Tabs: Leave BLANK

11. Now let us consider the scenario that we need to put extra details IN the <Document> tag. Refer to
the XML file below where we see details such as “xmlns” and “xmlns:xsi”.

• Detail 1: xmlns = “urn:iso:std:iso:20022:tech:xsd:pain.001.001.03″

• Detail 2: xmlns:xsi = http://www.w3.org/2001/XMLSchema-instance

Inside the document tag we have xlmns and xlmns:xsi and their corresponding information. This means
that we can create an XML Attribute to add extra details IN our <Document> tag.

XML Attribute 1 xmlns

XML Attribute 2 xmlns:xsi

12. Right click on the 1st element you created (Document) and select Create Attribute.
You should have the following screen below:

13. Let us create XML Attribute 1. We can expect this XML Attribute to include details within the
<Document> tag.

XML Attribute 1 xmlns

• Name: xmlns

• Short Description: xmlns attribute

• Mapping Procedure: Own Mapping (Atoms)

If you need to change the default value of Atom handling simply select an option.

14. This time, let us create XML Attribute 2. Right click on the 1st element you created (Document) again
and select Create Attribute. We can also expect this XML Attribute to include details within the
<Document> tag.

XML Attribute 2 xmlns:xsi

• Name: xmlns:xsi

• Short Description: xmlns:xsi attribute

• Mapping Procedure: Own Mapping (Atoms)

You can drag the XML attributes up or down in the tree to arrange them.

By now, hypothetically speaking the XML output would be the image below. We have the xmlns and
xmlns:xsi but we are missing the details for each attribute.

We are still missing the details for each:

• Detail 1: xmlns = “urn:iso:std:iso:20022:tech:xsd:pain.001.001.03″

• Detail 2: xmlns:xsi =http://www.w3.org/2001/XMLSchema-instance

15. On the XML Attribute (xlmns), right click and select Create Atom.
You should have the following screen below:

16. Enter the additional details needed for this XML Attribute 1

• Name: ISO

• Short Description: ISO Details Atom

• Length: 70

• Type: Character

• Mapping Procedure: Constant (This is a fixed value all the time. It will output the same value)

We declared the length as 70 since our structure FPM_SEPA says the length of XMLNS is 70. The same
approach follows thereafter.
17. Click on the next tab called “Source”. Here will copy paste the constant value as needed.

• Constant: urn:iso:std:iso:20022:tech:xsd:pain.001.001.03

Note that if you need this value to be present ALL the time, you can follow by clicking on the Conditions
tab and specifying the conditions below.
For reference on the conditions:

• Arg 1-1 reference value that should be checked (our example stated the structure)

• Arg 1-2 field value

• Type argument type (1 for constant value, 2 for field in source structure, 3 for reference ID)

• Operator logical comparison for the conditions

• Arg 2-1 comparison value

• Arg 2-2 comparison value field value

• Type argument type for comparison value (same as previous Type)

• Operator linking operator used if you have several other conditions / lines (AND / OR values only)

• Press F1 button on keyboard to double check further per entry.

18. Enter the additional details needed for this XML Attribute 2

• Name: ISO

• Short Description: ISO Details Atom

• Length: 70

• Type: Character

• Mapping Procedure: Constant (This is a fixed value all the time. It will output the same value)
19. Click on the next tab called “Source”. Here will copy paste the constant value as needed.

• Constant: http://www.w3.org/2001/XMLSchema-instance

Now that we are done with our XML attributes in the <Document Tag>, let us level up our scenario.

20. Consider that within the <Document> </Document> tags, we need to include payment details as
seen in the XML file below. This means that we need to add <Payment Details> </Payment Details> tags
in our tree.
21. Right click on the (Document) element node and select Create Element as Subnode. We are doing
this because we are considering that the Payment Details go within the Document tags.

22. You should have a sub node element under Document. You can now fill in the details as seen below.

• Name: PaymentDetails

• Level: 2 (This means that payment details can occur multiple times in 1 output file)

• Mapping Procedure: No Mapping (No mapping It is just a tag we want to output.)

• Other Tabs: Leave BLANK

By now you have created the <PaymentDetails> </PaymentDetails> tag within the <Document>
</Document> tag.

23. Now let us add to our scenario and consider that we need several information within the
<PaymentDetails> as seen in our XML file below.

From the file we can see that we need the following information below:

• Paying Company Code

• House Bank

• Bank Account Number

• Name of Payee

• Payment Reference

• Currency

• Amount

For this example, recall that we can create the xml tags accordingly as Elements (sub node elements to
<PaymentDetails>. From here, I can introduce the concept of “Mapping Procedure: Structure Field”.

In SAP, we can obtain the needed information from these standard SAP structures. Consider the
breakdown below. Screenshots also provided for the structure and field.
Payment Details Needed

Information Name of Tag Structure Field

Paying Company Code CompanyCode FPAYH ZBUKR

House Bank HouseBnk FPAYH HBKID

Bank Account Number BankAcct FPAYHX UBKNT

Name of Payee PayeeName FPAYH ZNME1

Payment Reference PayRef FPAYH DOC1R

Currency Currency FPAYH HWAER

Amount Amount FPAYH RWBTR

This means you can now create the different tags in the DME tree and map them to the existing SAP
structures. You know that these structures have specific fields that are in line with the data you need as
well.

Here we see FPAYH-ZBUKR

Here we see FPAYH-HBKID

Here we see FPAYH-DOC1R

Here we see FPAYH-HWAER

Here we see FPAYH-RWBTR

Here we see FPAYH-ZNME1

Here we see FPAYHX-UBKNT

24. Now let us add those details by right clicking on the PaymentDetails node and select Create Element
As Subnode.

You can now enter the details as seen below.

• Name: CompanyCode

• Short Description: CompanyCode Element

• Length: 4 (We just followed the length indicated in the corresponding structure-field)

• Type: Character (We just followed the data type indicated in the corresponding structure-field)
 • Level: 2 (This means that we can expect multiple instances of this in one output file)

• Mapping Procedure: Structure field (We will indicate the corresponding structure-field in the
Source tab)

25. Click on the next tab called “Source”. Here you can specify the corresponding structure and field for
this node as seen below. Basically, when you generate the DME output, it should pull the value from
the corresponding structure and specified field.

26. Now you can create the next node. In this case, right click on the CompanyCode element and select
Create Element Same Level. This option is selected because the next few payment details will be on the
same level. There are no further details within each of these payment details.
You should have the following screen below where you can continue the same approach up until the last
request detail which is Amount.

Follow the same process of creating an element at the same level. Below is the continuation for BankAcct.
Note: for amount be sure to indicate that it is Type Numerical because we are talking about a numerical
value. You may be confused why Length is “10” instead of what is specified in the structure, but you can
consider it as a limitation measure to keep the amount value to 10 digits only.

The same approach applies where you map the corresponding structure and field.
27. Finally, we are complete without DME tree. If you have not saved your creation yet, be sure to hit
the Save button where you can save the setup in a Workbench Request as seen below.

Final Output

Our Final XML Output should be the screenshot below.

Comparing it to our DME tree:

<?xml version="1.0" encoding="UTF-8"?><Document

xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"><PaymentDetails><CompanyCode>CCCC</CompanyCode><HouseBnk>HSBK</HouseBnk><
BankAcct>1234512345</BankAcct><PayeeName>Random Services
Incorporated</PayeeName><PayRef>03052020REF1234</PayRef><Currency>EUR</Currency><Amou
nt>1000.22</Amount></PaymentDetails></Document>

Additional Information

Format Tree Name and Structure Format in OBPM1

It is important to note that the format tree name you create in DMEE must be the same as the payment
medium format name you enter in OBPM1. Also, don’t forget to indicate the structure format specified in
DMEE in OBPM1 as well.
XSLT Program for Postprocessing

You can specify an XSLT Program for Postprocessing before the DME output file is finally generated. This
can be used to enhance the structure of the format tree. The program is declared in the “DMEE tree:
properties” Format Attributes Tab.

Reference ID of Node and Reference to Another Node Exists

We can assign the Reference ID to once of our nodes in the DME Tree. In the screenshot below, you see
Reference ID “REFID1” in <CompanyCode>. Notice how the tree shows the Reference ID’s beside the
CompanyCode node.

Let us say I added that Reference ID so I can reuse the information later on. For example, I create another
Element / Node called “Payment Footer”. I then put the Mapping Procedure as “Reference to tree node”.
In the next tab “Source”, you will see that I entered “REFID1” to the source.

Alternatively, I can also opt to indicate Mapping Procedure “Aggregation” and go to the Aggregation Tab.
This can output the number of occurrences based on the Aggregation Type selected.

This is of course a trivial example. You can realistically use this approach if you want to output the number
of transactions in an output file etc.
Technical Nodes

If there is a requirement that cannot be fulfilled by the standard mapping procedures, you can create a
technical node and specify an exit module to include a custom Function Module to accommodate the
additional requirements.
In the example below, we entered Exit Function “Z_DMEEXIT_ADDTL”. Please keep in mind that whatever
Function Module or Exit Function you decide to input here, it needs to be reflected in transaction code
OBPM1 (Event Modules for Payment Medium Formats) as well.

XMLNS and XLMNS:XSI Formatting

You can utilize SAP Formatting Structure FPM_SEPA as mapping for XMLNS and XLMNS:XSI formatting.
Simply create an Atom under the XML Attribute xmlns or xmlns:xsi and specify the corresponding
structure and field. Screenshots below.
XML Attribute xmlns
XML Attribute xmlns:xsi

Structure of DME File and SAP Example

There are different structures of DME Files depending on the requirements. In the example below, there
are other nodes utilized. Here we see a Root, Header Record, Total etc. You can freely explore this Format
Tree example as it will give you firsthand overview on how it is used.
CHAPTER 4: SAP Data Medium Exchange Scenario: Modifying DME Trees
and How to Generate DME File Output

This chapter will provide a step by step scenario of making a minor change in the SAP DME Tree and the
testing that follows thereafter.

In this scenario, I will update and existing DME Tree. Only 1 attribute will be changed to reflect a Mapping
Procedure of Structure instead of Exit Module.

Overview

• Before Changes
• Change Proper
• Post Change Testing – How to Generate DME File
• Additional Information

Before Changes

Before making any changes whatsoever to the DME Tree it is important to create a backup copy of the
current active version. This means that you have something to go back to in case there are issues with
your modifications.

• Go to Transaction Code DMEE

• Enter the Tree Type and Format Tree Concerned

• Click on Format Tree > Download XML file

• Generated XML file will be your backup copy

NOTE: In case you need to restore the DME tree to the backup, you can repeat the steps but select Upload
XML file instead. If the XML file is stored on your laptop, select location as “P” Presentation Server then
select the backup file.

Change Proper

1. Go to Transaction Code DMEE and Enter the Tree Type and Format Tree to be updated.

2. Take note of the DMEE Tree: Properties such as the Last Changed By USERID, DATE, and, TIME.

This is important because these details (highlighted in dark pink) will be your basis to check if the DME
Tree is updated.
3. Go to or Locate the node you need to change. Notice how the current values are the following
(highlighted in red):

• Length: Blank

• Mapping Procedure: Exit module

• Exit Function: DMEE_EXIT

4. Now we will do our change proper by updating the Mapping Procedure from Exit Module to Structure.
I changed the following (highlighted in black):

• Length

• Mapping Procedure is now Structure Field

• Source Tab > Source Offset

• Source Tab > Structure

• Source Tab > Field Name

 • Exit Function: REMOVED

Structure: FPAYHX Field Name: RENUM

See Additional Information section below to get insight on why we used the mentioned structure and
field name.

5. As soon as I have done my changes, I will click on the Save Button. This will prompt a Workbench
Transport Request. Simply fill up the details to create your Transport.

6. If I am sure with the changes, I will now click on the Activate Tree Button (blue wand) and make sure
that action is saved in the transport request I created earlier.
7. By Activating the Tree, you should be prompted with a transport request selection then you will
receive the notification “Format Tree Activated”.

Note: Save the tree activation in the SAME transport.

8. You can double check the changes by Selecting the Display option on Transaction Code DMEE. You
will be prompted with a question “Which version would you like to display”. Select Active Version.
9. To ensure that you have activated the tree and changes have been saved, check the DMEE Tree:
Properties. This would have been updated to the most recent change. In the screenshot below, the color
updated from dark pink to light pink (signifying the change).

NOTE: You can always switch your DME tree view by going to Utilities > Versions > Version Management
and select the version you want to check.

Post Change Testing – How to Generate DME File

Now we will generate a “realistic” DME file from the updates we have done. I say “realistic” because we
can always do a quick test in TCode DMEE to check the XML structure.

In my experience, that is not enough. That approach only provides a high-level test of the output. It is
always best to do a payment run to see the values that will be populated in the payment medium output.

Remember that DME File = Payment Medium Output.

The steps below assume we are in the test environment and the transport has been moved to the QA
environment.

1. First, you need to go to TCode FB01 to create a document that is due for payment. Example: Posting
Key 25 Outgoing Payment Vendor Number and Posting Key 35 Incoming Payment. You can use the proper
posting keys set up for your scenario / SAP system.
2. Second, you will go to TCode F110 to do a payment run. Enter a Run Date and Payment Identification.

3. Go to the Parameter tab and fill in the details (in line with the test document you created). The goal
is to pull the test document (that is due for payment) through the parameters. Make sure to specify the
right payment method that triggers the DME setup.
4. I tend to leave the Free Selection Tab blank if I am sure that it will only pull the test document just
created. If you want to narrow down your search, you can add some restrictions.

5. For the Additional Log Tab, I tick all the relevant checkboxes I prefer to show up on the payment run
log.
6. I also leave the Printout / Data Medium Tab blank since the current configuration in SAP will work
just fine without it. It will still trigger the DME payment medium format accurately.

NOTE: At the end of the day, it is best to pattern a realistic scenario in production. So, if you need to specify
a printout in your test, feel free to do so.

7. Finally, you can save the payment run parameter details.

8. This time we will do a Payment Proposal Run by clicking on the “Proposal” Button. At this point,
you do not need to tick the create payment medium checkbox.
9. Once done, you can check on the proposal details by clicking on the Proposal Button (with eyeglasses
icon). In the screenshot below you will notice that it was able to successfully pull the test document and
the corresponding details.

10. This time we will finally do a Payment Run by clicking on the “Payment Run” Button. At this point,
you NEED to tick the create payment medium checkbox. By doing this step, you will generate the DME
file.
11. If payment run goes well, you will see the posting order results below. You can click on the
“Payment” button to review the details.
In the screenshot below you will notice that the vendor, company code, payment method, and generated
document number details are included in the log.

The format used for payment medium is also included (highlighted in dark pink). You can also find the
location of where the generated DME file (payment medium output) was saved (highlighted in light
purple).
12. Depending on the setup, the DME file can go to a designated secured folder or you can always check
through transaction code AL11. In my case, I can directly go to the secured folder to check on the
generated file. I can also do a quick check on the generated xml details by viewing the file.
Additional Information

How do I know which Structure and Field to use for SAP DME Tree?

Structure: FPAYHX Field Name: RENUM

In our example, we used Structure FPAYHX and Field Name RENUM. Basically, this approach is telling the
DME tree to pull a specific populated value (RENUM) from the indicated structure (FPAYHX). In simple
words: we want the DME file to include a reference number from the payment run.

To help you visualize, let us first refer to Table REGUT with the field RENUM.
Enter the Company Code, Narrow down to exclude proposal run entries, Limit date (Run On) based on
testing

Notice how the Reference Number field name coincides with technical name RENUM. To help you
visualize the technical names easier, you can go to Extras > Change Settings > Select Technical Name as
Column Heading.

Extras > Change Settings

Select Technical Name as Column Heading

You should now see the technical names as headings and quickly check on the Reference Number
(RENUM). This is the reference number you can refer to for table checking.

In line with what we found in Field RENUM, let us now go to TCode SE11. To search for the corresponding
Structure: Select Data Type then choose “Search for Structures”.
Data Type > Search for Structures

In the Find Structures window, enter “BFIBL_PAYM” package then click on the Check Button.
BFIBL_PAYM is the standard SAP ABAP Package for Payment Medium.
Package: BFIBL_PAYM

You should now see a list of available Structures for your review / analysis. Once you have selected a
Structure, double click on the row to see more details. In our example, we used FPAYHX Structure to
target the “Payment Medium: Prepared Data for Payment”.
Double click on the selected Structure

You should eventually end up with the screen below. Notice how we can see the specific component
“RENUM” as the Reference Number. Thus, the utilization of FPAYHX-RENUM.

What is the link of FPAYHX and Table REGUT?

To get a high-level overview on how they relate to one another, you can always click on the Where-Used
Button (three-arrow box beside the activation wand) of Structure FPAYHX. You can then try to locate
Function Module “FI_DME_ADMINDATA_FILL” and double click on it.
FPAYHX Where-Used List > FI_DME_ADMINDATA_FILL

After double clicking on the Function Module, you should see the code below. Notice how there are
instances of FPAYHX and REGUT. Both are related to DME administration and the creation of the DME
output / file. You can explore more at your own pace by looking through the code if needed.

You can explore more at your own pace by looking through the code if needed.
CHAPTER 5: SAP DME Note to Payee Functionality

SAP Note to Payee Functionality

DME or Data Medium Exchange goes hand in hand with SAP Payments. It is triggered through payment
run where you can expect a payment medium output. For example, by form of an XML file etc.

For this chapter, we will focus on the SAP DME Note to Payee functionality. In most cases, the client may
need the Note to Payee information to be part of your DME output. This information is important because
it can be part of a legal requirement and / or it simply must be provided to the bank or payee.

Overview

• What is a Note to Payee?

• Configuration and Checklist
• Testing
• Note to Payee Output
• Additional Information
• Summary
What is a Note to Payee?

According to SAP Help, it is a field on a data medium containing information on paid line items relevant
for the business partner. The number and length of the note to payee fields are defined in the payment
medium format, whilst the content itself is defined in the note to payee.

For me, you can simply think of it as a sticky note (or post-it) that is part of the payment transaction. It
contains the payment information for the concerned business partner / vendor/ entity. In some cases, it
may even contain a payment reference note.

At the end of the day, we want to be able to include those Note to Payee details (according to the given
requirements) and output those details as part of the DME or payment medium output file.

You should note that (in general) there is no set or fixed format for Note to Payee details. It will always
depend on the request / requirements of the client.

Configuration and Checklist

The easiest or straightforward approach to including a Note to Payee in DME is to create a Function
Module (FM). Throughout my career, I have mostly encountered custom function module enabled setups
for Note to Payee functionality. This is most likely due to the flexibility it can provide in terms of
requirements. As such, we will focus or prioritize that approach.

On a high-level overview, you can refer to the checklist or transaction code list below for the Note to
Payee setup in DME.

• OBPM1

• OBPM2

• FBZP

• DMEE

Let us go through each of these transaction codes.

OBPM1 Payment Medium Formats

Make sure there is a defined Payment Medium Format. If not, create one. Highlight the concerned
payment medium format that will be used for DME Note to Payee functionality.

Select the Text Fields for Reference Information as highlighted below. Here you can define the types of
text fields for the reference information. Again, this information is defined in the SAP Help document
linked earlier.

SAP Help Document Screenshot

OBPM2 Note to Payee

You can directly go to transaction code OBPM2 or click on the Note to payee button from OBPM1. It will
direct you to the same screen below.

Create your Note to Payee entry (Example: “Z_NTP_FORMAT” masked in purple) and enter the custom
Note to Payee function module.
Input the function module

In our example we indicated “Z_DMEE_NOTETOPAYEE”. This function module should be triggered or

called during payment run or proposal run whenever the user selects the “Create Payment Medium”
checkbox.
Note: The results of triggering this function module should be stored in Table DFPAYHT in SAP. You can
double check some entries after payment run or proposal run below. Multiple lines can be stored per
payment run or proposal run. This basically covers the layout portion of your Note to Payee.

If needed, this function module logic can cover the ruling “note to payee should not be empty”.
After indicating the function module, double-click on “Default Note to Payee”. Here we will define the
actual content.

From the screenshot below, we see that there are several notification types (from 1 to 5) for line number
1. The entries below are for example purposes.

The Note to payee text is declared in SAPscript format. You can refer to this SAP Help Document on Using
SAPscript Symbols or SAPscript Formatting Options.
You can also utilize the Preview Button to further check. We put 3 items below because our maintenance
in OBPM1 consists of 3 types only.

After clicking on the Check Button, you should see this type of output:

FBZP Customizing: Maintain Payment Program

After defining OBPM1 and OBPM2, you need to go to transaction code FBZP. Here you will assign the note
to payee to the specific payment method (on country level per origin). This should trigger the
configuration when you run the payment program or F110 with create payment medium checkbox
selected.

In the scenario below, I selected the country and specific payment method. After highlighting the row,
double-click on “Note to Payee by Origin”.

Remember the purple highlighted masking? We declared the Note to Payee and named it
as Z_NTP_FORMAT. This time, we are linking it to the country and payment method through FBZP.

Some of you may be wondering why there is no Origin specified. In the scenario below it should cover FI-
AP as the SAP system (and corresponding setup) focuses on F110 only. The Note to Payee format is shared
across origins.

If you need to distinguish or maintain the origins, you can refer to SAP Note 1977304 for guidance. This
SAP Note covers origins that distinguish between F110, F111, FI-AP (vendor), FI-AR (customer), loan
management, treasury management, in-house cash, etc.
If you have executed some payment runs already, you should be able to find this origin details in table
REGUH. Our scenario will pull the details below where all consists of FI-AP.

Again, you can click on the Note to payee button to go back to OBPM2 if needed.

As additional check, you can also go to FBZP > Payment Methods in Company Code > Select the Company
Code and Payment Method > Scroll Down to Payment Advice Control area.

This setting is not applicable if you are using DME as seen in the information screen (F1), but it could help
to check on this in case needed.
DMEE DME Engine

Now we can go to transaction code DMEE to modify our DME Tree. This is the part where we link the Note
to Payee in DME. Enter the tree type and format tree concerned.

Here you need to consider that a separate function module should be created. Recall that we created
function module that focuses on the Note to Payee layout. Once payment run or proposal run triggers the
create payment medium checkbox, the details will be stored in table DFPAYHT.
On the DMEE standpoint, the other (or second) function module should pull these values from DFPAYHT
table (corresponding to the specific payment run).

For a simpler explanation, think of this function module as an instruction to SAP to please get all related
payment proposal / run details from DFPAYHT and put all these values as a one-liner in the DME Tree.

Please note that you are not directly accessing the table. Rather you are utilizing the given FPAYH
Structure. This means the code would most likely obtain information from these structures instead of
directly getting values from DFPAYHT.

The screenshot below shows the approach of linking the Function Module on the preferred DME Node as
an Exit Function. This type of approach considers the need for flexibility. If standard or usual DMEE
mapping options still does not meet the requirements, the function module should help you with those
requirements.

Here we created the function module Z_DMEE_EXIT_NTP and defined it in the DME Tree as an Exit
Function.
Alternatively (without the additional function module), you can also declare the DMEE_PAYD structure
and corresponding Field TEXT as several Atoms in the DME Tree.

Recall the Node Legend in DMEE

In some cases, you may need to include additional details in the DME. You can also utilize Structure
FPAYHX and Field Name (REF**) like REF05 as mapping.

In the screenshot below, we used standard structure FPAYHX and Field Name REF05 as mapping.
Please do not forget the Conditions tab as needed:

For further visualization, we can see that the Structure FPAYHX has Component REF05 where we can freely
define what is indicated. This is a screenshot from transaction code SE11.
Before you can fully utilize them, these component types need to be declared in OBPM1 under Event
Modules for Payment Medium Formats (specifically under Event 5). Here you need to specify the custom
function module you will be creating to accommodate the additional information.

It is in the function module that you can mention what the REF** fields (user-defined / additional info) will
contain. For example, if you need REF05 to contain a FIK code (for Denmark payments) or any other
requirement, you can specify it in the FM.

Testing

As mentioned, the Note to Payee functionality changes will be triggered during a payment run or payment
proposal (F110) when the “create payment medium” checkbox is selected upon execution.

This will be your main testing or validation proper. You can also refer to chapter on Modify and Generate
SAP DME Tree File where detailed steps of generating the DME file is shown.
Note to Payee Output
The screenshot below is an example of how the Note to Payee information is seen on a DME / Payment
Medium Output file in XML format. The tags used <Ref></Ref> will not be the same for all cases as the
requirement will differ depending on the scenario or client. The same goes for the content.

Additional Information

Function Modules

Earlier we talked about needing two function modules. One to store payment details in Table DFPAYHT
and another to retrieve those values to be included in your DME tree.

The developer does not need to create this function module from scratch because SAP has a standard
template or sample as reference. The developer can copy this FM sample as guidance.

You can view these function modules through transaction code SE37.

FI_PAYMEDIUM_SAMPLE_DETAILS
DMEE_EXIT_TEMPLATE_ABA

For alignment, the table below shows our example function modules and which standard FM was used as
reference.

Function Module based on scenario Standard SAP Sample / Template

Z_DMEE_NOTETOPAYEE (OBPM2) FI_PAYMEDIUM_SAMPLE_DETAILS

Z_DMEE_EXIT_NTP (OBPM1 and DMEE) DMEE_EXIT_TEMPLATE_ABA

Make sure that the exit function modules are defined in OBPM1 according to the type of event.
Summary

• Note to Payee functionality can be considered as a legal requirement and / or mandatory

information for payment transactions.

• There is no set or fixed format for Note to Payee details. It depends on the request / requirements
of the client.

• You can test the DME output or Note to Payee functionality by doing a payment run and selecting
the create payment medium checkbox upon execution.

• In most cases, requirements that cannot be fulfilled by simple or standard DMEE configuration
will require the creation of function module/s for flexibility purposes.

• OBPM1 > OBPM2 > FBZP > DMEE

CHAPTER 6: SAP Question Bucket | SAP Data Medium Exchange and XML
DME Tree

In this chapter, you will find some questions related to SAP Data Medium Exchange, XML DME Tree, and
Payment Medium Output. We will go through each of them and discuss the corresponding
answers. Relevant SAP Notes will be provided as well.

Most of these questions have been originally asked on my social media platforms and were added as a
part of this SAP Question Bucket chapter. I think that it is a great source of added information for you to
learn from other people’s questions.

Please note that some of the questions have been paraphrased and slightly modified for easier
understanding.

Overview of Questions

• Is there an SAP DME Tree Template for SEPA_CT and SEPA_DD?

• How do you connect F110 to a specific DME XML template? For example, we have different
Payment Methods in F110 and want each payment method to trigger a corresponding DME XML
template.
• In SAP DMEE / DME, what is the purpose of Conversion Function?
• While creating company code and house bank, the level indicated in the DME node is 2. Why can’t
it be in level 0 for DME XML file output?
• In SAP DMEE / DME, how do Reference ID’s work?
• What is the use of the FPM_SEPA structure fields XMLNS and XSI in SAP DME Tree Properties
Format Attributes Tab?

Is there an SAP DME Tree Template for SEPA_CT and SEPA_DD?

Yes, there are existing templates for SEPA_CT and SEPA_DD DME Trees provided by SAP. You can refer to
the following SAP Notes:

• SEPA_CT 1062489 + 1305012 + 1360908

• SEPA_DD 1090321 + 1401975 (with update)

Important: Always ensure to search for latest updates on the SAP Notes for SEPA_CT and SEPA_DD. Please
read and pay special attention to the attachments contained in the SAP Notes. That is where you will find
the template, sample output, mapping guides, etc.

Remember: There are prerequisites stated in the SAP Notes. Be sure to implement and check on the
prerequisites to avoid errors.

How do you connect F110 to a specific DME XML template? For example, we have different Payment
Methods in F110 and want each payment method to trigger a corresponding DME XML template.

Other alternative versions of the question could be:

 • “How do you generate multiple payment medium output files in one F110 run?”

• “How to Generate Multiple DME template output files in one F110 run?”

• “How to attach / link DME file in FBZP?”

To do this, you can:

1. Go to Transaction Code FBZP

2. Click on Payment Methods in Country Settings

3. Select / Highlight the Country and Payment Method in concern

4. Click on More Details or Ctrl+Shift+F2

5. Navigate to the “payment medium” section (screenshot below)

How do you connect F110 to a specific DME XML template?

For each payment method per country there is an entry where you can specify the Payment Medium
Format (utilizing the payment medium workbench radio button). This is also seen in the image above.

It is a 1:1 setting meaning 1 payment method per country is to 1 Payment Medium Format. As long as you
indicate the payment methods in your F110 Automatic Payment Program parameters, it should pull the
corresponding DME config.

Important: This is also considering that your FBZP configurations are accurately configured to pull those
payment methods during F110 run.

In SAP DMEE / DME, what is the purpose of Conversion Function?

As mentioned in the SAP Help Document “Conversion of Source Data”, this field or function allows you to
convert data to the needed format in your DME file.

The screenshot below shows an example where the amount that is pulled from Structure FPAYH Field
Name RWBTR should be converted to “AR.2” format.

This means that when the payment medium output file is generated, the data pulled for the (Amount)
Node should follow the specified conversion format.
In SAP DMEE / DME, what is the purpose of Conversion Function?

If you click on the puzzle icon / attributes button beside the Conv. Function field, you will notice a similar
setting in the image below.

In SAP DMEE / DME, what is the purpose of Conversion Function?

The conversion function is not limited to amounts. By exploring the list or available options further, you
will find other conversion options for date, time, etc.

Important: To prevent errors ensure that you do not use standard conversion function and mapping
procedure ‘Exit module’ simultaneously for the same node.
While creating company code and house bank, the level indicated in the DME node is 2. Why can’t
payment details be in level 0 for DME XML file output?

This question refers to the images below:

You will notice that the DMEE tree properties has Level 0 and 2 with 9999999 as the repetition factor. This
means that Level 0 and Level 9 tagged details can be expected to repeat multiple times.

Why are payment details not in Level 0 of DME Tree Config?

In the next image, you will see that the house bank element shows Level 2 for its configuration.

Thus, the question… “Why can’t it be set to Level 0 if Level 0 can repeat multiple times?”

Why are payment details not in Level 0 of DME Tree Config?

The house bank is maintained at level 2 because in this example we are considering house bank as part of
the payment details / information within the Level 1 tag. It considers hierarchy as visualized in the DMEE
focused chapter.

One way of looking at this is that we are organizing the information using that hierarchy so the “other
system” can read the xml file properly.

In the image below showing a high-level example of an XML file, the <HouseBnk></HouseBnk> tags
are within the <PaymentDetails></PaymentDetails> tags. As such, it wouldn’t be realistic to indicate
House Bank as Level 0 because that detail should be within the Level 1 Tag.

Example of SAP DME XML File Output

Important: The scenario provided in the chapter is loosely based on existing standard DME trees for xml
such as SEPA_CT payments but made simpler for tutorial purposes. You’ll notice that in the SAP template
for SEPA_CT DME tree (SAP Note 1062489), it will contain the same levels tab configuration for Level 0,1,2
(where Level 0 is 999…9 and you will also see a level 3).

In SAP DMEE / DME, how do Reference ID’s work?

In SAP DMEE / DME, how do Reference ID’s work?

For Reference ID, you can refer to “Reference ID of Node” in the Additional Info section of the DMEE
focused chapter. The Reference ID’s basically allow you to “reuse the information later on” where you can
call that ID in another node as mapping.

What is the use of the FPM_SEPA structure fields XMLNS and XSI in SAP DME Tree Properties Format
Attributes Tab?

The question refers to the image below where FPM_SEPA was populated in the DMEE Format Specific
Structure field under Format Attributes Tab.

What is the use of the FPM_SEPA structure fields XMLNS and XSI in SAP DME Tree Properties Format
Attributes Tab?

The purpose for including the mentioned structure is mentioned in SAP Note 1360908 where it addresses
some issues / concerns in the payment medium file output where attributes steer away from ISO
(International Organization for Standardization).

The same SAP Note also mentions the need to include structure FPM_SEPA in the SEPA_CT Payment
Medium Format configuration (OBPM1) Struct. for format parameters field. Refer to the image below.

FPM_SEPA in the Structure for Format Parameters OBPM1

On a high-level note, you can simply think of it as a way to standardize attributes relating to XML (XMLNS,
XSI, SCHEMALOCATION) and prevent frequent modifications to the DME Tree.

Ideally, you want the XML payment medium output file to be utilized as needed and (of course) be readable
for banks. The way to ensure that “readability” is to follow standardized formatting.
About the Author

“Techlorean” is the official pen name and handle of the writer behind Techlorean.com. Back when she
was an SAP Fresher, she recalls being clueless about SAP and having such a hard time learning it. She
hopes to ease this difficulty for others in the same scenario through educational, easy going, and reflective
learning materials.

Today, she is an experienced SAP Functional Consultant with background in support, management, and
project implementation / delivery. She dabbles in other technologies (non-SAP) as part of system
integration work so you might find some posts relating those technologies to SAP. When she is not doing
consultant work, you can find her writing, enjoying a cup of coffee, and enjoying life.

She believes in continuous learning and writing to educate. Her writing style focuses on providing simple
yet detailed explanations. As such, you can expect a casual non-technical tone to her writing.

• Read more at Techlorean.com

• If you are looking for another learning alternative through self-paced online courses, you can visit
Techlorean.com/sapcourses
• Have something to say? Send an email to techlorean@gmail.com

Disclaimer
Techlorean is not an affiliate of SAP SE.

Techlorean.com. All Rights Reserved. The download of this document is for informational and educational
purposes only. It does not constitute professional advice and does not establish any kind of consultant-
client relationship by your use of this document. This content is for your own personal, non-commercial,
non-transferrable, informational use only as per your agreement to our website’s Terms and Conditions.
The content, organization, gathering, compilation, magnetic translation, digital conversion and other
matters related to our website are protected under applicable copyrights, trademarks, and other
proprietary (including but not limited to intellectual property) rights, and, the copying, redistribution, use
or publication by you of any of our products or any part of the website is strictly prohibited.