Dme

An Introduction
To
Data Medium Exchange Engine (DMEE)
Abhijit Dani
Girish Awade
Aravinda Kodlamogaru
Februray 2005
Nitin Deshpande
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:
Copyright 2004 Wipro Technologies
Page 2 of 37
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
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.
Page 3 of 37
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
RFFOAVIS_FPAYM.
payment
advice
notes
with
the
new
program
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
Page 4 of 37
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
Page 5 of 37
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
Page 6 of 37
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 dataselection 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
Page 7 of 37
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
Page 8 of 37
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.
Page 9 of 37
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
Page 10 of 37
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
Segment group
Use
Used to group segments
Page 11 of 37
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.
Page 12 of 37
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
Page 13 of 37
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 dataselection 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
Page 14 of 37
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
Reference
ID
SAP script
name
Short
descript.
Length
Type
Specify the name of attribute

unique node identification for
referencing purposes
An accompanying sheet is to be
printed when a file is generated
Short description
Any unique name like DOCNO

Any unique name like REF_ITEM1
Length of the node

Define the type of node
Conv.
Function
Internal data conversion function

for date/time/amount/character
string
Existence status of a format tree
node. (weather this node can be
outputted or not)
Like 8, 10 for char/numc type

Character/Numeric/Currency
Amount/Currency amount with +/- sign
Like for date format DD.MM.YYYY
You have to specify the Conv.function
as D.DDMMYYYY
Max 3 values you can specify
1. standard
2. mandatory
3. optional
Status
name of node in SAP script form

like Z_FORM1
Description of the node defined
Mapping procedures Block: Following procedures are available to select.

Mapping
Procedure
Meaning
Constant
The value is to be set to a constant
Page 15 of 37
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
Fig5
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
Page 16 of 37
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.
Field Name
Meaning
Value
Source
offset
Structure
Specify the offset value for field

contents for the element.
Specify the DDIC structure name
for mapping. 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).
Name of field from the above
structure selected
Key field for the internal table
that contains source data for
mapping.
This field is only relevant if you
have selected the structure for
note to payee data as the source
structure
Means that when a loop is
processed for an 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.
Any value , depends on the field

length
Available structure name
Field name
Key field
Entire Table
Available field name from the

structure
For payment formats, the
DMEE_PAYD structure is the
source structure for note to payee
data. The TYPE field is the key
field in this structure
It is a check box (X or space)
Page 17 of 37
Reference to other tree node Block: This block is available if Reference to tree node
Mapping Procedure is selected
Field Name
Meaning
Value
Refer. Node
ID
Specify the value of reference ID

of the referenced node for the
element. Here you can specify
another tree node as reference.
If you reference another tree
node, you define which node
information is to be used by
specifying a node attribute
Reference ID
Attribute
It has following values:

1 :Contents in output format
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.
Field Name
Meaning
Value
Exit Function If the mapping and conversion

Any Z Function.
Available Template Function is
rules available in 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.
Page 18 of 37
Fig6
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.
Field Name
Meaning
Value
Arg1-1
Argument field 1
Left side of condition
Arg1-2
Argument field 2
Three possible values :

1. Constant
2. Structure field
3. Reference ID
Make an entry in this field in the
following cases:
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
Page 19 of 37
that you want to be checked in the

condition.
Type
Type of the argument for a

condition
Operator
Logical Operator
Arg2-1
Argument field 1 Right side of

condition
Argument field 2 Right side of
condition
Type of the argument for a
condition
Right side of condition
Linking Operator
Right side of condition
Used to establish the logical
operation between two condition
lines.
Arg2-2
Type
Operator
Possible values are:

1. Argument is a constant
2 .Argument is a source-structure
field
3.Argument is a reference ID
Possible Values are:
=
Equal to
<>
Not equal to
>=
Greater than or equal to
<=
Less than or equal to
<
Less than
>
Greater than
Same as Arg1-1
Same as Arg1-2
Same as Left side Type
Possible values are:
AND -And
OR - Or
Fig 7
Page 20 of 37
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.
Field Name
Meaning
Value
Reference
ID
Specify the value of reference ID

of the referenced node for the
element. Here you can specify
another tree node as reference.
Controls how the aggregation
nodes are aggregated into the
target node.
Reference ID
Agg. Type
Possible Values:
1
2
3
Summation of values
Number of occurrences
Summation of absolute
values
Page 21 of 37
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.
Page 22 of 37
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
Page 23 of 37
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
Page 24 of 37
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
Page 25 of 37
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
Page 26 of 37
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
Page 27 of 37
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
Page 28 of 37
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.
Page 29 of 37
Mapping for Header Composite Element

ABC Bank Header Element Format
Element
Name
Tab
Block
CONSTA Attributes
NT1
Attributes
Source
Constant
BANK Attributes
PROCES
SING
Source
DATE
Attributes
CONSTA Attributes
NT2
Attributes
Source
Constant
BP BANK Attributes
BRANCH
NO
Source
Attributes
BP BANK Attributes
AC NO
Attributes
Source
Mapping
for
structure
field
Le
n
Typ
e
Cha
r
Conversio
n
Function
90000010
8
Cha
r
Structure Field
Structure : FPAYH
Field name: ZALDT
Cha
r
Constant
8
Cha
r
Exit Module
Exit
Function
Attributes
Source
Mapping
for
structure
field
TOTAMT Attributes
Attributes
Aggregat
ion
Aggregati
on
Value
Constant
Mapping
for
structure
field
CREATIO Attributes
N DATE
Mapping Procedure
ZDMEE_EXIT_GET_O
UR_BANK
12
Cha
r
CL
Structure Field
Structure : FPAYHX
Field name: UBKNT
Cha
r
D0YYYYM
MDD
Structure Field
Structure : SYST
Field name: DATUM
16
Curr
.
Amt
C0
Aggregation
Reference Id:
REF_AMT_01
Agg. Type
COUNT Attributes
Attributes
Nu
:1
Aggregation
Page 30 of 37
mc
Aggregat
ion
Aggregati
on
Reference Id:
REF_COUNT_03
Agg. Type
BLANK1 Attributes
Attributes
Source
Constant
CONSTA Attributes
NT3
Attributes
Source
Constant
BLANK2 Attributes
Attributes
Source
Constant
14
Cha
r
:1
Constant
(Blank No value)
Cha
r
Constant
00
48
Cha
r
Constant
(Blank No value)
YBC Bank Header Element Format

Element
Name
Tab
CONSTA
NT1
Attributes
Attributes
Source
Constant
Attributes
Attributes
TOTAMT
Block
Le
n
Typ
e
10
Cha
r
Conversio
n
Function
Mapping Procedure
Value
Constant
9999999999
15
Curr
.
C0
Aggregation
Amt
Aggregati Aggregati
on
on
Reference
REF_AMT_02
Agg. Type
POSTING
DATE
CONSTA
NT2
CONSTA
NT3
Attributes
Attributes
Source
Mapping
for
structure
field
Attributes
Attributes
Source
Constant
Attributes
Attributes
Cha
r
D0YYMMD
D
:1
Structure Field
Structure : FPAYH
Field name: ZALDT
14
Cha
r
Constant
(Blank No value)
Cha
r
Constant
Page 31 of 37
Id:
Source
Constant
Mapping for Detail Composite Element.

ABC Bank Detail Element Format
Element
Name
GET_CO
UNT
CONSTA
NT1
CONSTA
NT2
POSTIN
G DATE
CONSTA
NT3
CUST
BANK
BRANCH
NO
CUST
BANK
Tab
Block
Attrib
utes
Attribute
s
Sourc
e
Mapping
for
structure
field
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Mapping
for
structure
field
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Exit
function
Attrib
utes
Attribute
s
Ref ID Le
n
REF_COU
NT_03
Typ
e
Conversio
n
Function
Nu
m
Mapping
Procedure
Value
Structure Field
Structure :
SYST
Field name:
TABIX
Cha
r
Constant
9000001
Cha
r
Constant
1
Cha
r
Structure Field
Structure :
FPAYH
Field name:
ZALDT
Cha
r
Constant
8
Cha
r
Exit Module
ZDMEE_EXIT_
GET_CUST_BA
NK
12
Cha
r
CR
Exit Module
Page 32 of 37
ACC NO
Sourc
e
Exit
function
SYSDAT
E
Attrib
utes
Attribute
s
Sourc
e
Mapping
for
structure
field
AMT
Attrib
utes
Attribute REF_AMT_
s
01
ZDMEE_EXIT_
GET_CUST_BA
NK_NO
8
Cha
r
D0YYYYM
MDD
Structure Field
Structure :
SYST
Field name:
DATUM
18 Curr
.
C0
Exit Module
Amt
.
CONSTA
NT5
CONSTA
NT6
CONSTA
NT7
REFNO
POSTDT
PAYMEN
Sourc
e
Exit
function
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Constant
Attrib
utes
Attribute
s
Sourc
e
Mapping
for
structure
field
Attrib
utes
Attribute
s
Sourc
e
Mapping
for
structure
field
Attrib
Attribute
ZDMEE_EXIT_
CONV_AMT
5
Cha
r
Constant
00000
14
Cha
r
Constant
(Blank No
Value)
Cha
r
Constant
00
10
Cha
r
CL
Structure Field
Structure :
FPAYP
Field name:
XBLNR
Cha
r
D0YYYYM
MDD
Structure Field
Structure :
FPAYP
Field name:
BUDAT
10
Cha
CL
Exit Module
Page 33 of 37
T DOC
NO
CONSTA
NT8
utes
Sourc
e
Exit
function
Attrib
utes
Attribute
s
Sourc
e
Constant
r
ZDMEE_EXIT_
GET_PAYM_DO
C
20
Cha
r
Constant
(Blank No
Value)
YBC Bank Detail Element Format

Element
Name
Tab
Block
CUST
BANK
BRANC
H NO
Attrib
utes
Attributes
Sourc
e
Exit
function
CUSTBN Attrib
KNO
utes
AMT
Ref ID
Attributes
Sourc
e
Exit
function
Attrib
utes
Attributes REF_AMT
_02
Le
n
Typ
e
Conversi Mapping
on
Procedure
Function
Cha
r
Exit Module
ZDMEE_EXIT_GE
T_CUST_BANK_
YBC
Cha
r
CL
Exit Module
ZDMEE_EXIT_GE
T_CUST_BANK_
NO
15
Curr
.
C0
Exit Module
Amt.
Sourc
e
Exit
function
PAYMEN Attrib
T DOC utes
NO
Sourc
e
Attributes
REFERE
NCE
DOC
Attrib
utes
Attributes
Sourc
e
Exit
function
ZDMEE_EXIT_CO
NV_AMT
10
Cha
r
Exit
function
CONSTA Attrib
NT1
utes
Attributes
Sourc
e
Constant
CR
Exit Module
ZDMEE_EXIT_GE
T_PAYM_DOC
Cha
r
Exit Module
ZDMEE_EXIT_GE
T_REF_DOC
Cha
r
Constant
MO
Page 34 of 37
CONSTA Attrib
NT2
utes
Attributes
Sourc
e
Constant
Cha
r
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
Page 35 of 37
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
FI
Finance
FI-AR
Finance-Account Receivable
FI-AP
Finance -Accounts Payable
FI-BL
Finance -Bank Accounting
Page 36 of 37
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
Page 37 of 37

Dme

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Dme

Diunggah oleh

Hak Cipta:

Format Tersedia

An Introduction

Data Medium Exchange Engine

Data Medium Exchange Engine

Clearing open items between customers and vendors

Restricting access to the payment program by assigning authorizations

Capable of processing domestic as well as foreign payments for vendors and

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

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

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Withholding tax reporting

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

Setup Header Attributes

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

4. Define Conditions and Aggregations

Generating data file

STEP1: DEFINE FORMAT TREE

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

STEP2: SETUP HEADER ATTRIBUTES

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

STEP3: SETUP NODES

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Represents a record in the target file

Used to group elements

Represents a target field of the DME file

Describes the link from the file definition to the

Element that is not output to a target file; it

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

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)

Add the total value of specified nodes

Add the number of nodes

Copyright 2004 Wipro Technologies

Data Medium Exchange Engine

Source fields for the application

ABAP system fields

Source fields for note to payee (internal table)

Parameters and source fields from Customizing

Data Medium Exchange Engine

Hierarchy of all the Elements in DMEE tree as follows:

Specify the name of attribute

Any unique name like DOCNO

Length of the node

Internal data conversion function

Like 8, 10 for char/numc type