An Introduction: Data Medium Exchange Engine (DMEE)

An Introduction
To
Data Medium Exchange Engine (DMEE)
Abhijit Dani Girish Awade

Aravinda Kodlamogaru Nitin Deshpande
Februray 2005
Data Medium Exchange Engine
Background
In SAP, payment programs are used to process domestic and international payment transactions with customers and vendors. The payment programs
allow both incoming and outgoing payments and are used by following components of SAP: Accounts Receivable (FI-AR), Accounts Payable (FI-AP),
Treasury (TR), and Bank Accounting (FI-BL).
The overview of handling the open items using the payment programs is given below.
The payment programs create documents and supplies data to the payment medium programs. These payment medium programs in turn print either
a payment list, payment forms (for example, cheques) or create data carriers such as magnetic tape or floppy disks.
Payment forms and file formats are specific to country. These payment forms are designed by SAP script.
The payment medium programs store the data in the SAP print administration and in DME administration (where DME is used). This data is picked up
separately (per form or data carrier) and sent to printer or data carrier.
Apart from handling both incoming and outgoing payments, other features of payment programs are:
 Clearing open items between customers and vendors
 Inter-company payments, that is one company code pays centrally for others
 Paying or clearing any type of open item, for example clearing down payments
 Restricting access to the payment program by assigning authorizations
 Capable of processing domestic as well as foreign payments for vendors and customers.
Objective and Scope
Copyright © 2004 Wipro Technologies Page 2 of 26

Objective:
This document attempts to showcase ‘Data Medium Exchange Engine’, a new tool devised by SAP used to create payment medium formats. These
payment medium formats are configured using the tool ‘Payment medium workbench’ which overcomes the disadvantages of classical payment
medium programs used to configure and create the payment media sent by the organizations to their house banks.
Scope:
Scope of this document is limited to the configuration of payment medium format for the payment program (application area: PAYM) by using Data
Medium Exchange Engine.
Out of scope:
This document does not intend to cover the following topics. It is recommended to refer SAP help for these topics.
1. Configuration of Payment Medium workbench when Data Medium Exchange Engine (DMEE) format tree is used to generate a DME file for
a given payment method. However, a brief description of this tool is provided in the next section
2. Configuration of DMEE format tree for Incoming file formats (data medium exchange file that you receive – for example, an electronic bank
statement from your bank)
3. Use of tree types other than PAYM, such as UMS1, ASLD and WTRE.
4. DMEE node types for creating the XML file.
Payment Medium Workbench
In simple terms, Payment Medium Workbench is used to create payment media. This workbench provides a generic payment medium program for all
payment medium formats compared to the individual classic payment medium programs (RFFO*). SAP is going to use this generic tool in future and
will gradually phase out the classic payment medium programs (RFFO*) due to the range of advantages that it provides.
The generic payment medium program of PMW will have variants defined in customising. The user can decide on the layout of the note to payee, and
select differing notes to payee according to origin (vendors, customers, personnel, travel expenses, Treasury, online payments and so on).
This workbench provides the developers and functional consultants simple tools for changing without modifying the formats delivered or for setting up
new formats. This integrates the existing development tools (ABAP Dictionary, Function Builder) and also the DME Engine that make the PMW into a
workbench.
Advantages of PMW over classic payment medium programs:
1. The ability to adapt formats delivered to be customer or bank-specific easily and without modification, including separate selection
parameters on the payment medium program.
2. Simple tools for creating new formats (programming knowledge is not a requirement for using the DME Engine).
3. Customizing for the layout of the note to payee
4. Standard creation of payment advice notes with the new program RFFOAVIS_FPAYM.
5. Improved performance with mass payments (> 50,000)
6. Superior control and verification of payment procedure
7. Better sort functions with payment advice notes
8. Clearer to work with than the myriad previous payment medium programs
9. Easier to maintain and to extend
The Data Medium Exchange Engine (DMEE) is used to define file formats that meet the requirements of the companies. This is particularly important
as there is no worldwide or regional standard. In some cases, no country standard exists and the file must comply with bank-specific standards. With
no ABAP programming knowledge required, this tool enables you to flexibly define new formats and to efficiently modify existing ones. In addition,
DMEE can be used by calling applications to generate a DME file.
The following application areas in Financial Accounting use the formats implemented in DMEE and generate Data Medium Exchange files.

 Payment program
 Tax reporting
 Withholding tax reporting
Features
Following are the features of Data Medium Exchange Engine
 Creation of formats with a graphical DME tool
 Single program interface for all formats
 No coding for additional layouts or changes
 Transport of layouts is possible between the clients
 Generation of temse files which can not be tampered
Tutorial
The aim of this tutorial is to provide a demo on step by step configuration of DMEE with respect to a scenario used in BP Cassis project.
Note: To help easy reading, this section has been divided into two parts, one explaining the theoretical aspects and other explaining the simulation of
the scenario.
In BP Cassis SAP-FI implementation project, the payment programs F110 and F111 will run at least once in a day. Since SAP has come up with
Payment Medium Workbench for payment programs, we had to use this new tool for creating the payment medium and DMEE for creating different
payment medium formats for the two house banks ABC and YBC (names have been changed for confidentiality) of BP in Turkey. The two formats
required by these banks are attached below.
ABC Bank File

Format.doc
YBC Bank File

Format.doc
After the payment programs are run, the data from the SAP tables should be output to the target file based on the payment proposal and the file
should contain the fields as per the format specified in the attachment. This DME file will be sent to respective banks.
The various configurations required for generating the DME file by the calling applications such as Payment program when DMEE format tree is used
for different tree types, is explained in previous section.
SECTION A
The basic steps to be followed for configuring the DME Engine are given below.
1. Define Format Tree
2. Setup Header Attributes
3. Setup Nodes
4. Define Conditions and Aggregations
5. Define Mapping rules
6. Testing the Format Tree
7. Transportation and Maintenance
8. Generating data file

STEP1: DEFINE FORMAT TREE

Use the Transaction Code ‘DMEE’ to navigate to the DMEE application. Fig-1 shows the initial screen of DMEE.
Specify the application for which, format need to be implemented. e.g ‘PAYM’ which means that the application area is ‘payment program’. As of
release 4.6x, SAP has supplied following four tree types (application areas) for different application areas.
1. PAYM – Data Medium exchange for payment program
2. UMS1 – Advance return for tax on Sales/Purchases
3. WTRE – Withholding tax Reporting
4. ASLD – EC Sales List
Now specify the format tree for implementation. SAP has supplied different format trees for each application area and for different countries,
which can be copied and customized to individual requirements. If the Payment Medium Workbench is already configured with the format tree,
then specify the same name here for the format tree. PMW format and the DMEE format tree must have identical names.
Fig-1
During the definition of the format tree following actions are performed
1. Data selection
After you specify the application for which you wish to create a file format (such as the payment program) and assign a unique format tree
ID, the system executes a selection step. It selects all R/3 fields that are predefined for the particular application. These fields form the
source field inventory and are made available to you when you do the data mapping in step 3.
2. Definition of tree structure
In this step, you define the layout of the format tree in a hierarchical structure. This tree stores all data that is relevant to describe this file
structure: here you maintain the level structure of the file, the field structure, and the mapping and conversion of SAP source fields to file
target fields.
3. Data mapping
When you define your structure, you must link the fields in your file format to the corresponding fields in the R/3 System. This enables the
DME Engine to extract the required data from the appropriate fields when you later generate a file. There are several mapping procedures;
the most common ones are direct reference to R/3 fields or specification of a constant. You can also define more complicated mapping rules
by including conditions, aggregation, or user exits.
After the above steps have been completed, you activate your format tree and it can then be used for generating DME files from the defined
applications.
The screen is divided into three parts:
1. Tree structure
On the left side of the screen, you define your format tree by inserting nodes in a hierarchical structure.
2. Detailed view

When you insert a node in the format tree, detailed information is displayed to the right of the tree in the top frame. Here you specify
additional data depending on the type of node. The information is displayed like a card index; you navigate between different areas by
choosing the tab strips along the top.
You can display the details for any node by double-clicking it in the left-hand tree structure.
3. Source fields
The bottom right frame contains all source fields made available by the data-selection step. These fields make up the source field inventory;
you can select from them during the data-mapping process.
STEP2: SETUP HEADER ATTRIBUTES

In this step, you will set up the following header data for the format tree which is applicable to entire file
1. Administrative data
2. Format Attributes
3. Levels
4. Sort/Key fields
5. File data
Fig-2
A. Administrative data

- Specify short description and any documentation to your format tree in this screen. The documentation will be saved as text in SAP Script
editor.
- Version of the format tree will be assigned by the system as 0 for the active version and 1 for the subsequent maintenance version
B. Format Attributes
Here you specify a DDIC structure in the case of format-specific parameters and delimiter information. For some applications, it is possible to fill
additional parameters dependent on the DMEE format tree that has been selected. These additional parameters must come from a fixed DDIC
structure that must be assigned to the format tree. The fields from this structure are then made available as possible source fields during the mapping
process.
For format trees of the tree type PAYM, you can additionally specify that an accompanying sheet is to be printed when the file is generated. The
system supports the printing of both simplified sheets and sheets with subtotals. If you specify an accompanying sheet with subtotals, you must
maintain the key fields on the Sort/key fields tab strip.
C. Levels
Here you specify the number of levels in the format. In addition, you can define a repetition limit for each level. This value specifies how often a certain
level may be output. If this number is exceeded, the corresponding level cannot be output anymore. If the limit is reached for the uppermost level in
the format tree and additional data is to be processed, a second file is generated. If the limit is reached for lower levels, the preceding level is repeated
so that data can continue to be output for this level.
D. Sort/Key fields
Here you can specify how certain fields are to be sorted. For the payment program, for example, you can sort according to currency or account by
specifying the appropriate source field. If a sort field is additionally marked as a key field, then a change to the value in this field causes the
corresponding format level to end and new level is started.
Fig-3

If you indicate on the Format attributes tab strip that an accompanying sheet is to be printed, you maintain the key fields in the bottom half of this
section (Key fields for accompanying sheet sub totals). Then system will calculate the sub totals for these fields and then outputs it on the
accompanying sheet. In the background system uses an internal table of structure ‘FPM_SUMTABLE’ for storing the sum amounts before outputting
to file.
E. File data
Block: End of Segment
Here you specify whether segments are to be separated by carriage return or by line feed.
Block: Definition of Characters

Here you can define the Amount of non-permitted/permitted characters.
For each format tree, you can enter a number of characters that are characteristic of the file format.
Either you specify that these characters are not allowed in the file.
Or you specify that these characters include exactly the permitted format characters
STEP3: SETUP NODES
Node is defined as an object that represents a hierarchy level in a format tree structure. They are used to model a file defined by a certain external
authority, such as a bank, government, or standardization organization. In most cases, it is possible to transfer to the format tree on a 1:1 basis the
structure in the file description that the authority provides. SAP recommends that each file field corresponds to an element in the format tree.
Each format tree begins with a root node called the header. It appears automatically at the top of the tree structure when you create a format tree, and
you can maintain the details on the right. Fig-1 displays the header on the left and its attributes on the right.
Below the header, you insert nodes to form the body of your format tree based on your file requirements. Likewise, details for the nodes can also be
maintained on the right. Different types of nodes can be inserted under a header node.
Node types
Each node type performs a different function and various data can be maintained accordingly in the detailed view. For additional information on nodes
and when to use certain node types, choose Extras  Node legend on the DMEE: Create/Change Format Tree <format tree> screen.
Below is an overview of node types in the DME Engine to create flat files and their use. Please note that the node types for creating the XML file are
different and is not in the scope of this document
Fig-4
Node Use

Segment group Used to group segments
Segment Represents a record in the target file
Composite Used to group elements
Element Represents a target field of the DME file
Atom Describes the link from the file definition to the internal R/3 structures
Technical node Element that is not output to a target file; it stores values that are used in
other tree nodes (elements, atoms) by a reference to this node
1. Segment Group
Always a new level in DMEE starts with segment group. Segment groups are used for arranging segments. Segment groups can be followed by either
segment groups or segments.
2. Segment
Segments represent a record in the output file. They need to have at least one composite or one element as sub nodes.
3. Composites
Composites are used to group the elements. If there is a common condition exists for a group of elements, this condition can be specified in the
conditions tab of the composite. Composites are closely related to Conditions. Refer STEP3 for conditions.
4. Elements
Elements represent the fields in the target file at different levels. Mapping rules are specified at element level.
5. Atoms
These nodes will be used, only if there is more than one mapping rule to be defined for an element. We have not used atoms for our scenario.
6. Technical Fields
Technical nodes are type of element which will not be output to the target file. Only elements will be written to output file. They store values that are
used in other tree nodes (elements, atoms) by reference to the technical node. For this reason, a technical node generally contains a reference ID.
STEP4: DEFINE CONDITIONS AND AGGREGATIONS (on composite level)
Conditions
By specifying the conditions for the nodes we can control the generation of a certain format tree node is processed during file generation.
Conditions can be defined for any node type. If one condition applies to several consecutive elements, you should define a composite. If you assign a
condition to a segment or a composite, it applies to the corresponding sub tree. In this way, for example, you can control that a complete record (a
segment, including all its elements defined as sub nodes) is not output to the file.
The conditional relationship for a node is defined under the view Conditions. Here you specify one of the following types of condition arguments and
the corresponding arguments:
 Constant
 Field in a source structure (from the source field inventory)
 Reference ID (of another node already defined in the format tree)
When a file is generated from one of the predefined applications, the system processes the format tree and checks each node for conditions. If a
condition is met, the system processes the node; if it is not, the node is ignored. If a condition for an upper-level node is not met, all sub nodes are
also ignored during processing.

Aggregations
We can aggregate the values for the specified nodes (called aggregation nodes) and assign this aggregated value to an element which can be output
to the target DME file
The aggregation function can be used at the end of a level or a file to:
 Add the total value of specified nodes
In this case, you can only specify aggregation nodes that are filled with values (elements). Example for this would be the amount of all
payments in a level.
 Add the number of nodes
In this case, you can specify any aggregation nodes because the system totals the number of occurrences, not specific values. Example for
this would be the number of payments in a level.
STEP5: DEFINE MAPPING RULES
After defining the nodes for the format tree, we have to define the rules by which R/3 source fields will be mapped to the target fields in a DME file. In
most cases, we specify how data is to be mapped to elements, the nodes in the DMEE format tree that represent these target fields. You can also
specify a mapping procedure and source information for atoms, which you define if an element contains several mapping rules.
List of the source fields which can be mapped to the elements for the application selected will be available in the source field inventory.
Source Field Inventory
For each DMEE tree type, a set of possible source fields is predefined by SAP. These fields form the source field inventory, which is generated
automatically during the data-selection step. You can select from these fields in the data-mapping process.
The source field inventory can consist of the following fields, depending on the tree type:
 Source fields for the application
These fields are dependent on the particular application.
 ABAP system fields
These fields are made available for each application. An example is the system date.
 Technical fields
These fields are additional ABAP system fields that are usually not selected in the data-mapping process. However, they are still made
available in the case that you require such source fields.
1. Source fields for note to payee (internal table)
These fields are specific to the tree type PAYM (payment program). If the appropriate settings are defined in Customizing for Payment
Medium Formats for the Payment Medium Workbench and you select one of these fields as your source field, then a value will be filled in
this target field.
 Parameters and source fields from Customizing
These fields are specific to the tree type WTRE (withholding tax reporting). By choosing one of these fields, you map data that has been
defined in Customizing and that remains unchanged.
When the elements are created under the composites, the system automatically displays the detailed view for an element in the right frame.
This includes the following tab strips:
 Attribute
 Source
 Conditions
 Aggregation

Hierarchy of all the Elements in DMEE tree as follows:

DMEE tree -> Segment Group -> Segment -> [Composite] -> Element
Detail description of all the tabs:
Attribute tab:
Attribute tab is used to define the Attributes for the element and select the Mapping Procedure for element definition. See Fig-5.
It has two blocks:
 Attribute Block
 Mapping Procedure Block
Attribute Block: This block has following definitions
Attribute Name Attribute Meaning Value

Name Specify the name of attribute Any unique name like DOCNO
Reference ID unique node identification for referencing Any unique name like REF_ITEM1
purposes
SAP script name An accompanying sheet is to be printed when a name of node in SAP script form
file is generated like Z_FORM1
Short descript. Short description Description of the node defined
Length Length of the node Like 8, 10 for char/numc type
Type Define the type of node Character/Numeric/Currency Amount/Currency amount
with +/- sign
Conv. Function Internal data conversion function for Like for date format DD.MM.YYYY
date/time/amount/character string You have to specify the Conv.function as ‘D.DDMMYYYY’
Status Existence status of a format tree node. (weather Max 3 values you can specify
this node can be outputted or not) 1. standard
2. mandatory
3. optional
Mapping procedures Block: Following procedures are available to select.
Mapping Procedure Meaning
Constant The value is to be set to a constant
Structure field A value is to be retrieved from a specific source field in the R/3 System
Reference to tree node An attribute (current value, length, or counter reading) of another DMEE format object that was already
defined is to be used
Aggregation A value related to a reference node is to be totaled and made available to this node
Exit module The standard mapping and conversion rules do not meet your requirements and you wish to specify an exit
module
Own mapping (atoms) Your mapping rules are dependent on conditions or if different parts of the element are to be filled from
different sources

Fig–5
Source tab:
Source tab is basically varies based on the selected Mapping Procedure.
It is the actual definition of the element. It has four blocks which are available based on the selected mapping procedure. See Fig-6
Blocks:
 Constant
 Mapping from structure field
 Reference to other tree node
 Exit function
Constant Block: This block is available if ‘Constant’ Mapping Procedure is selected.

Field Name Meaning Value
Constant Specify the constant value for the element, Any constant value
Mapping from structure field Block: This block is available if ‘Structure Field’ Mapping Procedure is selected.
Source offset Specify the offset value for field contents for the Any value , depends on the field length
element.
Structure Specify the DDIC structure name for mapping. Available structure name
This structure name also made available in
DMEE tree based on tree types. For certain
DMEE tree types, internal table name is also
made available in DMEE tree as source data
(note to payee data).
Field name Name of field from the above structure selected Available field name from the structure
Key field Key field for the internal table that contains For payment formats, the DMEE_PAYD structure is
source data for mapping. the source structure for note to payee data. The
This field is only relevant if you have selected the TYPE field is the key field in this structure
structure for note to payee data as the source
structure
Entire Table Means that when a loop is processed for an It is a check box (X or space)
internal table, it should start with the first line. If

this indicator is set, the entire table is used when

a loop is processed for an internal table -
regardless of whether parts of the table were
already used in other nodes.
If the indicator is not set, the loop continues with
the line of the internal table at which a previous
loop ended.
Reference to other tree node Block: This block is available if ‘Reference to tree node’ Mapping Procedure is selected
Refer. Node ID Specify the value of reference ID of the Reference ID
referenced node for the element. Here you can
specify another tree node as reference.
Attribute If you reference another tree node, you define It has following values:
which node information is to be used by 1 :Contents in output format
specifying a node attribute 1A :Contents in internal format
2 :Length
3 :Counter reading (within a format level)
4 :Only for DMEE tree: counter reading for
segments per file
Exit Function Block: This block is available if ‘Exit Module’ Mapping Procedure is selected.

Exit Function Any Z Function.
If the mapping and conversion rules available in
Available Template Function is
the system do not meet your requirements, you
DMEE_EXIT_TEMPLATE
can specify an exit module for an element or
atom. This is ABAP Function.
Fig–6

Condition tab:
By specifying the conditions for the nodes we can control the generation of a certain format tree node is processed during file generation. Conditions
can be defined for any node type. If one condition applies to several consecutive elements, you should define a composite. If you assign a condition to
a segment or a composite, it applies to the corresponding sub tree. In this way, for example, you can control that a complete record (a segment,
including all its elements defined as sub nodes) is not output to the file.
See figure Fig-7.

Arg1-1 Argument field 1 Three possible values :
Left side of condition 1. Constant
2. Structure field
3. Reference ID
Arg1-2 Argument field 2 Make an entry in this field in the following cases:
Left side of condition 1. If the argument refers to a structure field
(argument type 2), then enter the field name here.
2. If the argument refers to a reference ID
(argument type 3), then enter the node attribute here
that you want to be checked in the condition.
Type Type of the argument for a condition Possible values are:

Left side of condition 1. Argument is a constant
2 .Argument is a source-structure
field
3.Argument is a reference ID
Operator Logical Operator Possible Values are:
Left side of condition = Equal to
<> Not equal to
>= Greater than or equal to
<= Less than or equal to
< Less than
> Greater than
Arg2-1 Argument field 1 Right side of condition Same as Arg1-1
Arg2-2 Argument field 2 Right side of condition Same as Arg1-2
Type Type of the argument for a condition Same as Left side Type
Right side of condition
Operator Linking Operator Possible values are:
Right side of condition AND -And
Used to establish the logical operation between OR - Or
two condition lines.
Fig – 7

Aggregation tab:
This tab is available if ‘Aggregation’ Mapping Procedure is selected.
We can aggregate the values for the specified nodes (called aggregation nodes) and assign this aggregated value to an element which can be output
to the target DME file.
See figure Fig-8
The aggregation function can be used at the end of a level or a file to:
 Add the total value of specified nodes
In this case, you can only specify aggregation nodes that are filled with values (elements). Example for this would be the amount of all
payments in a level.
 Add the number of nodes
In this case, you can specify any aggregation nodes because the system totals the number of occurrences, not specific values. Example for
this would be the number of payments in a level.

Reference ID Specify the value of reference ID of the Reference ID
referenced node for the element. Here you can
specify another tree node as reference.
Agg. Type Controls how the aggregation nodes are
Possible Values:
aggregated into the target node.
1 Summation of values
2 Number of occurrences
3 Summation of absolute
values
Fig-8

STEP6: TESTING THE FORMAT TREE
The DME Engine provides a testing function by which we can test active versions of format trees before they are used to generate a file.
Activation
While working on the format tree, we maintain version 001 of the DMEE format tree. After finishing maintenance of the format tree, we can activate it
so that it can be used to generate a DME file from one of the defined applications.
During activation, system checks the inconsistencies like errors and warnings. If there are issues, maintenance version 001 is maintained. Once all
errors are corrected, active version 000 is assigned.
Testing
Testing feature provided by the DME Engine is for small-scale tests only. You can employ it, for example, to test the effects of new conversion rules or
to determine if the offset is correct within a line or record. It is not intended to check an entire format tree – but rather a few lines – as it is very difficult
to manually generate all application data correctly.
STEP7: TRANSPORTATION AND MAINTENANCE
Transportation
Both active and maintenance versions of format trees can be transported to other systems. The logical transport object for a DMEE format tree is
R3TR DMEE; this contains all associated database tables. To transport a format tree, choose either Format tree  Transport on the initial screen of
the DME Engine.
The DME Engine also supports an upload/download of format trees as an alternative to the transport:
 Upload format tree
You can upload a format tree that you have as an XML file. To do so, choose Format tree  Upload XML file on the DMEE initial screen.
You then specify the file name and the presentation server or URL address.
 Download format tree
You can download a format tree and create an XML file on your PC that contains all format tree information. To do so, choose Format tree
 Download XML file on the DMEE initial screen. After you specify which version you wish to download (active or maintenance), you enter
the tree type, format tree ID, and a name for the XML file.
Maintenance
After activating a format tree, two versions exist in the system: the active version (000) and the maintenance version (001). You always maintain
version 001. When making changes to the maintenance version, you can always return to the last active version. You would want to do this, for
example, if you make changes to the maintenance version, save it, and decide later that you do not want to keep these changes. To return to the last
active version, on the DMEE initial screen choose Edit  Maintain active version.
When you return to the last active version, it overwrites the maintenance version.
Only two versions exist in the system at any given time. Once you modify a maintenance version and activate it, this is the only active version that
exists – at this point it is not possible to return to an earlier active version.
Both the active and maintenance versions can be transported to other systems.
STEP8: GENERATION OF DATA FILE
The format tree created is used by a calling application to generate a DME file. As mentioned before, the system currently supports the use of the
DME Engine from three Financial Accounting applications: payment program, tax reporting, and withholding tax reporting.

SECTION B
This section explains the steps to be followed for setting up the DMEE for the scenario in BP
STEP 1: DEFINE FORMAT TREE

Specify ‘PAYM’ for tree type and ‘Z_BANK_FORMAT’ for format tree and click ‘create’. The screen displayed is shown in Fig-2.
STEP2: SETUP HEADER ATRIBUTES

A. Administrative data
Short description: Specify description for the format tree you specified.
B. Format Attributes
Select the option ‘Without accompanying sheet’
C. Levels
Maintain levels 0, 1 and 2 to represent header and line (item) information for the format. Level 0 indicates highest level which is the format
tree itself. Level 1 can be attributed to the information stored at header record of the file such as Invoice number, Date, Document type etc. Level 2
represents the item level information for the header invoice such as item no, amount, ref no etc. Level 3 can be used, if there are multiple long texts for
one invoice line. But in our example, we have not used this case.
Specify the maximum possible repetition factor (9999999) for each level.
D. Sort/Key fields
Three fields are used for sorting for the format tree Z_BANK_FORMAT.
1. Paying company code (FPAYH-ZBUKR),
2. House Bank (FPAYH-HBKID)
3. Reference to the paid document (FPAYP-DOC2R).
Company code and House bank are at level 1 as they are available in header structure FPAYH and Reference document will be at level 2 as it is
available in items structure FPAYP. This field will be used to differentiate the line items, without which there will be only one item line for a combination
of company code and house bank at header.
Refer the Fig-3. All three fields will be specified as key fields. If the fields are already defined in the configuration of Payment Medium Workbench
under payment formats level of detail, they can be specified as ‘No Sorting’ in this screen as they are already presorted while the payment program is
run.
No action is required for the format tree Z_BANK_FORMAT as we are not using any accompanying sheet
E. File data
Select carriage return and Line feed options and select ‘Only permit these characters’ and do not specify any characters in ‘Charctr’ field to
allow all the characters.
STEP3: SETUP NODES

Create the nodes for our example as given below
 Create Segment Group
Right click on the header segment and select ‘Create Segment Group’ from the context menu.
Name this segment group as ‘AR[SG]’ (Account Receivables) in the right hand screen and provide short description as ‘Header Segment
Group’ in the ‘Description’ field. Specify the level as ‘1’.
Do not specify any conditions in the ‘Conditions’ tab at this time. This has been explained later in the document.

 Create Segment
We had requirement to send the data to two house banks of BP in Turkey. They are ‘ABC’ and ‘YBC’. The file formats for each bank had
one ‘Header’ record and multiple ‘Detail’ records.
Create a segment under the segment group by right click of mouse -> create segment -> as sub node
Name this segment as ‘Header[Seg]’ in the right hand screen and provide short description. The level for this segment will be ‘1’ as this
represents the header record in the file. There are no conditions to be specified at this level.
To represent ‘Detail’ records of ABC and YBC bank formats, we have to create one more segment group under the segment group
‘AR[SG]’. This new segment group will be called as ‘Detail[SG]’ with description as ‘Detail Segment Group’. Since, this new segment group
represents detail lines of the bank formats, which are for header lines, it should be created as sub node under the segment ‘Header[Seg]
instead of the segment group ‘AR[SG]’.
Hence, place the cursor over the node ‘Header[Seg]’ , right click and create the segment group ‘Detail[SG]’ as sub node. Please note that
the level of this segment group should be ‘2’ as it represents the detail records of the bank formats
As given above, to represent the detail records of the two bank formats, we need to have segments. Create segment ‘ABC[Seg]’ and
‘YBC[Seg]’ as sub nodes under the segment group ‘[Detail[SG]’ as explained above. Again, level of these segments will be ‘2’ as they are
under the segment group ‘Detail[SG]’ which represents level ‘2’.
As mentioned above, the segments need to have at least one composite or one element as sub node
 Create Composites
The header records for two banks of BP had varying number of fields as shown in the attached documents.
Since we are going to use only one format tree for both banks, we should be able to select the header record appropriately based on some
condition. Composites can be used for this purpose.
Create a composite under the segment ‘Header[seg]’ called ‘ABC[comp]’ with description as ‘Composite for ABC bank’ by right clicking on
the segment node. This will be used to group some fields/elements for header record of bank ABC.
Create one more composite at the same level as ‘ABC[Comp]’ under segment node. Call this as ‘YBC[Comp]’ with description as
‘Composite for YBC bank’. This will be used for grouping some fields/elements for header record of bank YBC.
In order to control the fields for the two bank formats at detail level and to satisfy the condition of having at least one composite under a
segment, composites need to be defined for segments ‘ABC[Seg]’ and ‘YBC[Seg]’. Create the composite ‘YBC_Detail[Comp]’ under the
segment ‘YBC[Seg]’ and ‘ABC_Detail[Comp]’ under the segment ‘ABC[Seg]’. These composites may hold the conditions which govern the
elements underneath them, but it is not mandatory.
 Create Element
Elements will be created under the composites at header and detail segment levels as per the format required by the bank. Referring to the
ABC and YBC bank formats, create the fields with following names. These fields are part of the header record in the file for ABC and YBC
bank. Mapping rules for these fields are explained in step 5.
A. Fields under header composite ‘ABC[Comp]’ for ABC bank.

CONSTANT1
BANK PROCESSING DATE
CONSTANT2
BP BANK BRANCH NO
BP BANK AC NO
CREATION DATE
TOTAMT
COUNT
BLANK1
CONSTANT3
BLANK2
B. Fields under header composite ‘YBC[Comp]’ for YBC bank.
CONSTANT1
TOTAMT
POSTING DATE
CONSTANT2
CONSTANT3
After adding the above fields for the two header record composites, the left hand screen should look like this.

Fig-9
Similarly create the following fields for the detail records. These fields will be part of detail records for ABC and YBC bank formats.
A. Fields under detail composite ABC_Detail[Comp] for ABC bank

CONSTANT1
CONSTANT2
POSTING DATE
CONSTANT3
CUST BANK BRANCH NO
CUST BANK AC NO
SYSDATE
AMT
CONSTANT5
CONSTANT6
CONSTANT7
REFNO
POSTDT
PAYMENT DOC NO
CONSTANT8
B. Fields under detail composite YBC_Detail[Comp] for YBC bank
CUST BANK BRANCH NO
CUSTBNKNO
AMT
PAYMENT DOC NO
REFERENCE DOC
CONSTANT1
CONSTANT2
After adding the above fields for the two detail composites, the left hand screen should look like this.

Fig-10
 Atoms
No Atoms created
 Technical Fields
No Technical Fields are used here
STEP4: DEFINE CONDITIONS AND AGGREGATIONS (At composite level)
 Conditions
Specify the following condition for the composite ‘ABC[Comp]’ in its Conditions tab.
Arg1-1 = ‘FPAYH’ (Structure)
Arg1-2 = ‘HBKID’ (Field)
Type = ‘2’ (Indicates it is structure field)
Arg2-1 = ‘ABC’
Arg2-2 = ‘‘

Type = ‘1’ (Indicates it is a constant)
Similarly specify ‘YBC’ as Arg2-1 for the composite ‘YBC[Comp]’
As per this condition, the header record with the elements listed below the composite will be created only if the house bank is either ‘ABC’ or
‘YBC’ and the header record will be written to the file with appropriate elements listed under that header.
 Aggregations
In order to use this facility, we have to select the mapping procedure ‘Aggregation’ for any element which should be aggregated. On the
Aggregation tab strip, you enter the reference IDs of the nodes you wish to aggregate and the aggregation type – how the aggregation
nodes are to be totaled to the target node (either summation of values or of total number of occurrences).
For our scenario, we have used aggregation for the fields TOTAMT and COUNT in the header records to display the total of amounts at
detail lines and the number of detail records processed for a header record. More information on set up of aggregation and reference values
are given in the ‘STEP5: Define mapping rules’
STEP5: DEFINE MAPPING RULES

Mapping for ABC and YBC elements
For the application PAYM, payment program data (after processing) is stored in the tables REGUH and REGUP tables. Payment medium data is
prepared as per the bank format structures for ABC and YBC banks, the elements at header and detail records will be mapped as given below
Only required field names and values are shown here.
Mapping for Header Composite Element
ABC Bank Header Element Format
Element Name Tab Block Len Type Conversion Mapping Procedure
Function
Value
CONSTANT1 Attributes Attributes 8 Char Constant
Source Constant 90000010
BANK Attributes Attributes 8 Char Structure Field
PROCESSING
DATE Source Mapping for Structure : FPAYH
structure field
Field name: ZALDT
Source Constant 8
BP BANK Attributes Attributes 4 Char Exit Module
BRANCH NO
Source Exit Function ZDMEE_EXIT_GET_OUR_BANK

BP BANK AC Attributes Attributes 12 Char CL Structure Field
NO
Source Mapping for Structure : FPAYHX
structure field
Field name: UBKNT
CREATION Attributes Attributes 8 Char D0YYYYMMDD Structure Field
DATE
Source Mapping for Structure : SYST
structure field
Field name: DATUM
TOTAMT Attributes Attributes 16 Curr. C0 Aggregation
Amt
Aggregation Aggregation Reference Id: REF_AMT_01
Agg. Type :1
COUNT Attributes Attributes 5 Numc Aggregation
Aggregation Aggregation Reference Id: REF_COUNT_03
Agg. Type :1
BLANK1 Attributes Attributes 14 Char Constant
Source Constant (Blank – No value)


Source Constant 00
BLANK2 Attributes Attributes 48 Char Constant
YBC Bank Header Element Format

Element Name Tab Block Len Type Conversion Mapping Procedure
Function
Value
TOTAMT Attributes Attributes 15 Curr. C0 Aggregation
Amt
Aggregation Aggregation Reference Id: REF_AMT_02
Agg. Type :1
POSTING Attributes Attributes 6 Char D0YYMMDD Structure Field
DATE
Source Mapping for Structure : FPAYH
structure field
Field name: ZALDT
Source Constant 0
Mapping for Detail Composite Element.

ABC Bank Detail Element Format
Element Tab Block Ref ID Len Type Conversion Mapping Procedure
Name Function
Value
GET_COUNT Attributes Attributes REF_COUNT_03 5 Num Structure Field
structure field
Field name: TABIX
Source Constant 1
POSTING Attributes Attributes 8 Char Structure Field
DATE
Source Mapping for Structure : FPAYH
structure field
Field name: ZALDT
Source Constant 8
CUST BANK Attributes Attributes 4 Char Exit Module
BRANCH NO
Source Exit function ZDMEE_EXIT_GET_CU
ST_BANK
CUST BANK Attributes Attributes 12 Char CR Exit Module
ACC NO
Source Exit function ZDMEE_EXIT_GET_CU

ST_BANK_NO
SYSDATE Attributes Attributes 8 Char D0YYYYMMDD Structure Field
structure field
Field name: DATUM
AMT Attributes Attributes REF_AMT_01 18 Curr. C0 Exit Module
Amt.
Source Exit function ZDMEE_EXIT_CONV_A
MT
Source Constant (Blank – No Value)
Source Constant 00
REFNO Attributes Attributes 10 Char CL Structure Field
Source Mapping for Structure : FPAYP
structure field
Field name: XBLNR
POSTDT Attributes Attributes 8 Char D0YYYYMMDD Structure Field
Source Mapping for Structure : FPAYP
structure field
Field name: BUDAT
PAYMENT Attributes Attributes 10 Char CL Exit Module
DOC NO
Source Exit function ZDMEE_EXIT_GET_PA
YM_DOC
Source Constant (Blank – No Value)
YBC Bank Detail Element Format

Element Tab Block Ref ID Len Type Conversion Mapping Procedure
Name Function
CUST BANK Attributes Attributes 3 Char Exit Module
BRANCH NO
Source Exit function ZDMEE_EXIT_GET_CUST
_BANK_YBC
CUSTBNKNO Attributes Attributes 3 Char CL Exit Module
Source Exit function ZDMEE_EXIT_GET_CUST
_BANK_NO
AMT Attributes Attributes REF_AMT_02 15 Curr. C0 Exit Module
Amt.
Source Exit function ZDMEE_EXIT_CONV_AMT
PAYMENT Attributes Attributes 10 Char CR Exit Module
DOC NO
Source Exit function ZDMEE_EXIT_GET_PAYM
_DOC
REFERENCE Attributes Attributes 8 Char Exit Module
DOC
Source Exit function ZDMEE_EXIT_GET_REF_
DOC
Source Constant MO


Source Constant 0
STEP6: TESTING THE FORMAT TREE

Activation:
Activate the format tree Z_BANK_FORMAT by choosing Format Tree -> Activate
Testing:
To test the format tree Z_BANK_FORMAT, follow the steps given below
1. On the initial screen of the DME Engine, choose Format tree  Test active version
The DMEE Test Data screen appears. The system displays the source structures for the particular application, each followed by the most
commonly selected source fields for that structure. If you need to test fields not included here, you can add fields via the standard layout
function.
2. Next you enter the data you wish to test.
Only enter data in those fields that are specified in the format tree as actual source fields.
3. To start the test, choose File  Test
4. On the Data output dialog box that appears, the system displays in list form the results for the data you entered as they would appear in an
actual DME file.
If you do not enter data in the fields for which mapping rules are defined in the format tree, these fields remain empty when the test version
is output. Fields defined as constants are output accordingly.
STEP7: TRANSPORTATION AND MAINTENANCE

Please refer section ‘STEP7: TRANSPORTATION AND MAINTENANCE’ of Section A.
STEP8: GENERATION OF DATA FILE

In customizing for Payment Medium Formats for the Payment Medium Workbench, the format tree Z_BANK_FORMAT will be defined as a payment
medium format for the PAYM tree type.
After the configuration of Payment Medium Workbench (not in the scope of this document) and DMEE, the payment program will be run using
transaction codes F110 or F111. In background, the calling application (payment program) carries out the following steps:
1. Selects data from the SAP tables based on the criteria defined in payment program screen and fills the transfer structure with this
data
2. Calls DMEE modules with the data that has been selected
3. Obtains an internal table with data as per the rules defined in Z_BANK_FORMAT tree structure
4. Writes data to a file or to File/TemSe/... and, in the case of PAYM, possibly updates DME administration
A sample output file generated during this process is shown below

Fig-11
Glossary
DDIC Data Dictionary

DMEE Data Medium Exchange Engine
FI Finance
FI-AR Finance-Account Receivable
FI-AP Finance -Accounts Payable
FI-BL Finance -Bank Accounting
PMW Payment Medium Workbench
TR Treasury
TEMSE Temporary Sequential File
XML Extended Markup Language

References
This document takes the input from the following sources.

1. SAP help documentation site – help.sap.com
2. sap.ittoolbox.com

An Introduction: Data Medium Exchange Engine (DMEE)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Introduction: Data Medium Exchange Engine (DMEE)

Uploaded by

Copyright:

Available Formats

An Introduction

Data Medium Exchange Engine (DMEE)

Abhijit Dani Girish Awade

 Clearing open items between customers and vendors

 Restricting access to the payment program by assigning authorizations

Objective and Scope

Copyright © 2004 Wipro Technologies Page 2 of 26

Payment Medium Workbench

3. Customizing for the layout of the note to payee

5. Improved performance with mass payments (> 50,000)

6. Superior control and verification of payment procedure

7. Better sort functions with payment advice notes

9. Easier to maintain and to extend

Data Medium Exchange Engine

Copyright © 2004 Wipro Technologies Page 3 of 26

 Withholding tax reporting

Following are the features of Data Medium Exchange Engine

 Creation of formats with a graphical DME tool

 Single program interface for all formats

 No coding for additional layouts or changes

 Transport of layouts is possible between the clients

 Generation of temse files which can not be tampered

ABC Bank File

YBC Bank File

Copyright © 2004 Wipro Technologies Page 4 of 26

STEP1: DEFINE FORMAT TREE

2. Definition of tree structure

The screen is divided into three parts:

Copyright © 2004 Wipro Technologies Page 5 of 26

STEP2: SETUP HEADER ATTRIBUTES

Copyright © 2004 Wipro Technologies Page 6 of 26

Copyright © 2004 Wipro Technologies Page 7 of 26

Block: Definition of Characters

STEP3: SETUP NODES

Copyright © 2004 Wipro Technologies Page 8 of 26

Segment group Used to group segments

Segment Represents a record in the target file

Composite Used to group elements

Element Represents a target field of the DME file

STEP4: DEFINE CONDITIONS AND AGGREGATIONS (on composite level)

 Field in a source structure (from the source field inventory)

 Reference ID (of another node already defined in the format tree)

Copyright © 2004 Wipro Technologies Page 9 of 26

 Add the total value of specified nodes

 Add the number of nodes

STEP5: DEFINE MAPPING RULES

Source Field Inventory

 Source fields for the application

These fields are dependent on the particular application.

 ABAP system fields

1. Source fields for note to payee (internal table)

 Parameters and source fields from Customizing

Copyright © 2004 Wipro Technologies Page 10 of 26

Hierarchy of all the Elements in DMEE tree as follows:

Detail description of all the tabs:

Attribute Block: This block has following definitions

Attribute Name Attribute Meaning Value

Mapping procedures Block: Following procedures are available to select.

Mapping Procedure Meaning

Constant The value is to be set to a constant

Copyright © 2004 Wipro Technologies Page 11 of 26

Constant Block: This block is available if ‘Constant’ Mapping Procedure is selected.

Copyright © 2004 Wipro Technologies Page 12 of 26