DMEE

Sommario
Format-specific structure in DMEE...................................................................................................................3
Use of aggregation and own mapping in DMEE trees......................................................................................9
Exit modules in DMEE.....................................................................................................................................14
1.1 1.1 Templates for exit modules......................................................................................................14
1.2 1.2 Overview of interface parameters............................................................................................15
1.3 1.3 Overview of extended parameters...........................................................................................16
1.4 1.4 Usage of exit module................................................................................................................17
Use of conditions in DMEE-tree......................................................................................................................20
Format-specific structure in DMEE
SAP provided quite sophisticated mapping options mechanism that allows you to populate nodes in
DMEE tree with necessary values flexibly. Just to recap, you can use the following options:

 Constant values;
 References to fields in standard structure (e.g. FPAYH, FPAYHX, FPAYP for payment
medium purposes) as well as to fields in format-specific structures;
 References to existing tree nodes;
 Aggregations;
 User exits;
 Own mapping.

Apart from these mapping options, you can also use conditions technique to customize display of
certain nodes depending on certain conditions. Besides, SAP provided another option called format
specific structure that can be used to enhance the flexibility of tree customizing even more.

Let’s consider the use case. Imagine that for a typical payment order you need to output the
following information about the payee: company name, address details etc. Seemingly simple
requirement becomes more complicated when you should display this information in local language
for domestic payments, but in English for foreign payments. This requirement can be met by several
options e.g.:

 Configuring duplicate nodes for each element of payment medium (one storing value in
local language, another – in English) and applying conditions technique to make their
display dependable on some technical (language) key. Main drawback of this solution is that
you should maintain a lot of duplicate nodes.
 Developing user exit for each node that will automatically detect which address version to
retrieve and populate a node of tree with correct value. This option is a bit more efficient,
but you would have to develop separate user exit for each node of tree.

However, it seems that usage of format-specific structure will be more efficient solution. Format-
specific structure is a customer-defined structure that is assigned to payment medium and can be
used as a source of additional data primarily for those requisites that belong to a header part of
payment medium. Before proceeding to customizing of DMEE tree, you should decide which fields
you might need and create this structure in ABAP dictionary (transaction code SE11). Example of
such a structure can be found below:
Once the structure is activated, you should assign this structure to tree in transaction DMEE.
Assignment can be done on “Format attributes” tab of DMEE tree properties.

Once the structure is assigned to DMEE tree, you should be able to see overview of structure fields
beneath DMEE tree (under node “Source fields for format-specific structure”).
Choose option “Structure field” under mapping procedure options for a node, go to Source tab and
indicate structure name / field name to use an element.

Note, at this moment you can do the assignment, but at the runtime of payment program the
structure itself would be empty. Essentially there are two options to populate the structure with
values:

 Development: to develop user exit that would be triggered when new payment medium file
is created and will populate the structure with necessary values;
 Customizing: to link the structure to payment medium and save the values in program
selection screen variant.

The first option is more complicated and deserves to be considered in a separate post on
enhancements in APP. This post will cover only the second option.
As a first step in customizing, you should link the same structure to payment medium format. You
can do that in transaction OBPM1 or by the following menu path:

SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business
Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Proposal
Processing → Payment Media → Make Settings for Payment Medium Formats from Payment
Medium Workbench.

Format-specific structure should be indicated in field “Struct. for format parameters”:

You can also mark some of the fields of the structure as required fields. Navigate to tab “Format
Parameter Required” and add structure fields which should be mandatory to the table. This part of
menu provides search helps that enable you to choose only among fields of the structure assigned to
payment medium format.
Once the structure is assigned to payment medium format, you should maintain selection screen
variant for payment medium creation program in transaction FBPM. When you indicate payment
medium format with format-specific structure, a new button “Format Parameters” will be displayed.
Upon click on this button new window will pop-up enabling you to fill in values on selection screen
fields and save them into the variant (e.g. UA_IBIS_DEF). Example of selection screen can be
found below. Please note that fields Name and Name 2 are display as required entry fields in
accordance with format specific settings.

Afterwards, please make sure that this variant is assigned to combination of company code / house
bank in transaction OBPM4 or by the following menu path:

SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business
Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Proposal
Processing → Payment Media → Create / Assign Selection Variants.

An important feature of payment medium format is that it can be re-used across different company
codes / house banks. Thus, you can customize the PMW format and its tree centrally, but maintain
the values of format specific structures differently per company code / house bank (depending on
the settings of details’ levels of PWM format in OBPM1).
Example of resulting payment order layout can be found below:

If you want to experiment with format-specific structures, you can search for existing structures
delivered by SAP. You can go to SE11 and search for data structures starting with FPM* (at least a
lot of standard structures begin with this prefix e.g. FPM_CH_LSV, FPM_CH_DTA,
FPM_SEPA_IE etc). Apart from these, there are other potentially useful standard structures that can
be re-used. For instance, you might consider using structure FIPL_S_FRMTS_DMEE that was
originally delivered for EC Sales List for Poland.

When you work with the tree / payment medium that was provided by SAP, format-specific
structure might already be assigned. That’s why the structure, which is assigned to payment
medium format in OBPM1 is considered as SAP structure. However, you still have the option to
customize another structure in addition to predefined one. This structure can be assigned to payment
medium format in transaction OBPM3 or by the following menu path:

SPRO → Financial Accounting (New) → Accounts Receivable and Accounts Payable → Business
Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Proposal
Processing → Payment Media → Adjust Payment Medium Formats.

As you can see from the picture above, additional customer specific structure (i.e. FPM_CH_LSV)
has been specified as “Customer structure”. For this structure, you can also configure required fields
by navigating to menu “Format Parameter Required”. Afterwards, the selection screen in
transaction FBPM will be extended and will include fields from both structures.
Please note, you still can use fields from customer-specific structure in mapping for DMEE tree,
however you wouldn’t be able to see this structure in DMEE.

I hope you will find this post useful! Your suggestions and comments are welcome! You can also
find this post on Medium platform via the following link.

Best regards,

Bohdan Petrushchak

P.S. Disclaimer.

All sensitive information (bank accounts, company names etc.) used in this example is invented by
my own. If there is some coincidence with real-life companies, it is a purely accidental one. The
structure of the DMEE tree represents a real-life example although I modified it for the purposes of
this blog post.

Use of aggregation and own mapping in

DMEE trees

Hello, SAPers!

It’s been quite a while since I’ve posted my last post on use of conditions in DMEE trees. At the
time I’ve planned a couple of other posts about DMEE functionality, but due to packed schedule
managed to finalize first of them just recently. There is also some work in progress on other posts
and I hope it won’t take a long time to publish them here.

Typical requirement during designing of payment medium is to add a footer with some aggregated
information e.g. total amount to be paid, number payment orders etc. This requirement can be
achieved by use of aggregation in DMEE tree. Aggregation is a standard mapping option that
allows you to calculate total value for one node based on values of another node. Node of DMEE
tree that uses aggregation is also referred to as aggregation node.

Let’s suppose the layout of payment medium looks as follows:

DMEE tree that allows to generate payment medium that covers this requirement might have the
following structure:

Note: segments Header / Empty / Totals are assigned to level 1 of DMEE tree, whereas segment
Transactions is assigned to level 2 of DMEE tree. Header segment contains general information
pertaining to all payment operations that is displayed once. Empty segment is inserted into DMEE
tree to separate the transactions part from the footer part. Footer is a part of payment medium that is
supposed to contain aggregated information that will be displayed at the end of file. Transactions
segment is used to customize the properties of separate open items contained in payment proposal.

Let’s consider the aggregation options in more details.

1.1   Summation of values

First case to consider is summation of amounts. Before deep-dive into aggregation settings, make
sure that you’ve configured correct node types in DMEE tree (payment-related nodes should have
node type P – Currency Amount). Otherwise, aggregation will not work properly. Overview of
aggregation node can be found below:
Essentially, aggregation is just one of the options available under mapping procedure tab of DMEE
node configuration. Mapping itself should be performed on tab “Aggregation”. Please indicate
reference to ID of DMEE node whose amounts should be calculated (e.g. PAYMENT_AMT) and
aggregation type 1 (Summation of values). This aggregation type considers operation sign (+ / -)
during summation, whereas aggregation type 3 (Summation of Absolute Values) simply adds
absolute values. Since, it is not likely to generate payment orders with minus signs, option 1 can be
used to add all amounts.

1.2   Summation of instances

Another use of aggregation is to calculate number of instances and is mostly used to calculated total
amount of payment orders in one payment medium. Let’s suppose that for this example, you want
to output the line with fixed text and variable part e.g. Quantity of orders: qty, where qty stores
number of orders. Such requirement can be covered by use of “Own mapping (atoms)” in DMEE
tree. Settings of typical DMEE node that uses this option can be found below.
Essentially, own mapping implies that value of a certain DMEE node will be constructed as a
concatenation of several atoms allocated beneath this node (please refer to the picture DMEE tree
structure). In our case, the value of qty_of_orders node will be based on concatenation of atoms
qty_in_words (storing fixed texts) and qty (storing numerical part). You can control behavior of
concatenation via atom handling options. There are three possible options:

Option Behavior
Empty Take over values into element with fixed offset, default option
01 Simple concatenation without spaces
02 Concatenation with additional space between separate atom values

Options 01 and 02 are self-explanatory, whereas the default option is not that straight-forward and
deserves a separate explanation in another blog post. But in short, concatenation of values in this
case considers values in “Target offset” field from source node. For this example, atom values
would be concatenated with separation by space (option 02).
Node qty_in_words uses mapping procedure via constant value with text “Quantity of orders:”.
Whereas node qty uses aggregation as mapping option.

For this node, we use aggregation option 2 (Number of Occurrences). This node refers another node
via reference ID COUNTER which can be configured either as a technical node with any default
value (e.g. 1). Essentially, here you can reference any DMEE node that will contain non-empty
alphanumerical values, aggregation node will calculate how many times this node has been
displayed in payment medium regardless its content.

Example of resulting payment order layout can be found below:

I hope you will find this information useful if you are interested in topics around payment medium
workbench and DMEE trees.
All suggestions are welcome!

Best Regards, 

Bohdan Petrushchak

P.S. Disclaimer.

All sensitive information (bank accounts, company names etc.) used in this example is invented by
my own. If there is some coincidence with real-life companies, it is a purely accidental one. The
structure of the DMEE tree represents a real-life example although I modified it for the purposes of
this blog post.

P.S. This post can also be found on Medium platform under this link.

Exit modules in DMEE

Follow RSS feed Like
5 Likes 9,353 Views 18 Comments

Hello SAPers!

As promised earlier in some of my posts, here is an article on usage of exit modules in DME
engine. I hope this post would be of interest for you and will give some new insights on this
functionality. This post contains a lot of technical details, if you have any questions or need some
clarification, feel free to post them as comments.

1.1 1.1 TEMPLATES FOR EXIT MODULES

Exit module is one of mapping options that can be used in DMEE. The purpose behind its usage is
quite simple: whenever other mapping options are not sufficient (i.e. do not contain necessary
values and / or it is not possible to get this value via combination of these options), you can leverage
the power of ABAP to retrieve any value, including values from custom tables.

Before deep dive into usage of exit modules in DMEE, it is worth to consider some technical
aspects. From ABAP point of view, exit module is a function module (FM) that has a predefined
interface (i.e. combination of input / output parameters of certain types) and is called during
execution of standard program to enhance its logic. The notion of FM with predefined interface is
of paramount importance meaning that you cannot simply ask a programmer to write FM that will
execute some logic. You should know at least what is the interface that is supported by DMEE.
Thus, the best way to create new exit module is to find a standard template and copy it to Z* copy
(in transaction SE37).

SAP provided a couple of standard templates, which can be logically divided into two groups:

 FM templates with basic interface (DMEE_EXIT_TEMPLATE and DMEE_EXIT_TEMPLATE_ABA);

  FM templates with extended interface (DMEE_EXIT_TEMPLATE_EXTENDED and
DMEE_EXIT_TEMPLATE_EXTEND_ABA).

The main difference between these two interfaces is that extended interface allows you to check not
only the value of DMEE tree node that is currently being processed but also the values in other
nodes, which were generated previously. Besides, extended interface is a bit more flexible when it
comes to coding. These details will be explored later based on some examples. You can also check
OSS note OSS note 373145 (DMEE: enhanced interface for exit module), that delivered extended
interface for additional technical details.

1.2 1.2 OVERVIEW OF INTERFACE PARAMETERS

Below you can see screenshot of typical extended interface.

This interface has the following importing parameters:

 I_TREE_TYPE – type of DMEE tree (e.g. PAYM for payment related trees, UMS1 / UMS2 / UMS3 for
advance return for tax on sales / purchases etc.);
 I_TREE_ID – ID of DMEE tree.

Combination of these two parameters uniquely identify DMEE tree and are used to access its
settings in t-code DMEE. On technical level, basic templates DMEE_EXIT_TEMPLATE and
DMEE_EXIT_TEMPLATE_ABA have slight differences in ABAP types of these two interfaces
(check in SE37), otherwise they are the same.
  I_ITEM – importing parameter that contains the values of source fields for a specific application
(e.g. for tree type PAYM, this parameter will contain the values of all fields from structures FPAYH,
FPAYHX, FPAYP);
 I_PARAM – SAP recommends not to use this parameter;
 I_UPARAM – is a parameter storing values of format-specific structure;
 I_TAB – table that stores texts which comprise information relevant for note-to-payee.
 I_EXTENSION – information about values in other nodes. This parameter is available in extended
interfaces only. It consists of several sub-components, which will be covered a bit later.

The interface has a couple of exporting parameters, which differ only in type:

 O_VALUE – output value in a generic type;

 C_VALUE – character value;
 N_VALUE – numeric value;
 P_VALUE – currency value.

Essentially, FM should return value using type that corresponds to the type of tree node indicated in
DMEE tree. For instance, you will have empty field, if FM returns C_VALUE for a node that has
type N.

1.3 1.3 OVERVIEW OF EXTENDED PARAMETERS

As was already mentioned above importing parameter I_EXTENSION is available for FM with
extended interface only. Overview of parameter’s components and their types is summarized in
table below. You can check each type in transaction SE11 for more details.

As you can see, the only difference between templates with extended interfaces is in component
types, whereas their internal structures are the same. From history point of view, template
DMEE_EXIT_TEMPLATE_EXTENDED was introduced earlier. Starting from release 500 of
SAP_APPL component template DMEE_EXIT_TEMPLATE_EXTEND_ABA was added.

Parameter I_EXTENSION-NODE contains a lot of technical details related to the current node that
is being processed. Commonly useful would be the field NODE_ID, which corresponds to Node ID
as configured in DMEE:
Parameter I_EXTENSION-NODE_VALUES contains technical parameters and output values of
current node, whereas parameter I_EXTENSION-REF_TABLE contains a table with values of
other nodes.

Please note the following restriction! In extended interface, you can check the values of other
nodes, only if these nodes have reference ID.

1.4 1.4 USAGE OF EXIT MODULE

There are lots of possible scenarios, where user exits might be used. Quite common requirement is
to retrieve some requisite of company code e.g. from table T001Z that stores company code
additional data (t-code OBY6). Simple example of exit module for this purpose can be found below.
This exit module is checking the values of source structures for payment program, does selection of
necessary requisite into local variable and returns it to DMEE tree. This approach is universal i.e.
logic of the exit module doesn’t depend on the settings of particular DMEE tree. That’s why one
FM can be reused across different DMEE trees.

FUNCTION Z_DMEE_COMPANY_TAX_NUMBER.
*"--------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(I_TREE_TYPE) TYPE DMEE_TREETYPE_ABA
*" VALUE(I_TREE_ID) TYPE DMEE_TREEID_ABA
*" VALUE(I_ITEM)
*" VALUE(I_PARAM)
*" VALUE(I_UPARAM)
*" REFERENCE(I_EXTENSION) TYPE DMEE_EXIT_INTERFACE_ABA
*" EXPORTING
*" REFERENCE(O_VALUE)
*" REFERENCE(C_VALUE)
*" REFERENCE(N_VALUE)
*" REFERENCE(P_VALUE)
*" TABLES
*" I_TAB
*"--------------------------------------------------------------------

data:
ls_item type dmee_paym_if_type,
lv_stcd1 type stcd1.

ls_item = i_item.

select single paval

from t001z into lv_stcd1
where bukrs = ls_item-fpayh-zbukr
and party = 'SAPU01'. "individual tax number of company code in Ukraine
 if sy-subrc is initial.
c_value = lv_stcd1.
endif.

ENDFUNCTION.

To use exit module, choose the respective option on Mapping procedure tab and indicate its name
on the source tab.

Overview of assignment on the source tab can be found below:

As was mentioned previously, extended interface offers some additional flexibility. Let’s consider a
case, when you have two nodes in tree that should contain company code names – one in English,
another in local language (e.g. Ukrainian). Besides, let’s assume that the format implies that the
value of this node should be empty if country of payee is Russia. How can this requirement be met?

You can solve it by creating two nodes referencing the same exit module besides one technical node
with reference ID “VEND_COUNTRY” that will store the reference to country of vendor. Source
code might look as follows:
FUNCTION Z_DMEE_COMPANY_NAME.
*"--------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(I_TREE_TYPE) TYPE DMEE_TREETYPE_ABA
*" VALUE(I_TREE_ID) TYPE DMEE_TREEID_ABA
*" VALUE(I_ITEM)
*" VALUE(I_PARAM)
*" VALUE(I_UPARAM)
*" REFERENCE(I_EXTENSION) TYPE DMEE_EXIT_INTERFACE_ABA
*" EXPORTING
*" REFERENCE(O_VALUE)
*" REFERENCE(C_VALUE)
*" REFERENCE(N_VALUE)
*" REFERENCE(P_VALUE)
*" TABLES
*" I_TAB
*"--------------------------------------------------------------------

data:
ls_item type dmee_paym_if_type,
ls_ref_node type dmee_node_if_aba,
lv_name1 type text40.

ls_item = i_item.

" Dynamic selection of different values for different node IDs

case i_extension-node-node_id.
when 'N_5409292620'.
select single name1 title
from adrc into lv_name1
where addrnumber = ls_item-fpayhx-adrnr
and nation = space. " Standard version

c_value = lv_name1.
when 'N_5409292630'.
select single name1 title
from adrc into lv_name1
where addrnumber = ls_item-fpayhx-adrnr
and nation = 8. " Ukrainian version

c_value = lv_name1.
endcase.

" Checking value of another node

read table i_extension-ref_table
with key ref_name = 'VEND_COUNTRY'
into ls_ref_node.

if sy-subrc is initial and ls_ref_node-c_value = 'RU'.

clear: c_value.
endif.

ENDFUNCTION.

As you can see, usage of exit modules with extended interface allows you to populate DMEE nodes
dynamically (based on their ID) and also allows you to read the values of other nodes (i.e. node
with reference ID “VEND_COUNTRY”) and link some logic to these values. This approach might
be useful when you have several nodes with similar purpose – then you can create one FM that
centralizes their logic. However, major drawback of this approach is that by linking values to node
IDs, you loose the advantage of flexibility i.e. your exit module becomes dependent on one DMEE
tree and cannot be re-used without modifications in another DMEE for similar purpose.

I hope this post was useful! Your suggestions and comments are welcome!

Regards,

Bohdan Petrushchak

P.S. Examples in this post might seem quite trivial, but they are provided for demonstration
purposes only and are intended to deliver the basic idea behind this functionality.

Use of conditions in DMEE-tree

Hello, SAPers!

Quite recently I worked on implementation of budget payment orders (taxes, social payments etc.)
for our Client. First of all, I compared the structures of ordinary and budget payment orders and
found out that there is a dozen of extra fields in budget payment order that are not supported in an
ordinary payment order. So the task boiled down to add these extra fields to the existing DMEE-tree
(for ordinary payments), however output them only when certain conditions are met. I decided to
implement this requirement using conditions in DMEE-tree. As it turned out, this functionality is
quite simple, but when you try to use it for the first time it will take some time to understand the
mechanics behind it.  Let’s take a closer look at this functionality.

Condition technique is a standard functionality in DMEE that enables you to control whether a node
would be processed during the generation of payment orders or not. Basically, if the condition for a
separate node is not fulfilled then the node will not be processed and hence not displayed in the file
with payment orders. The conditions can be configured for any node type. If the condition should
apply to several fields, you can apply it to a composite node ( ) or a segment ( ) that contain these
fields.

For configuration of conditions you can reference either the field values in source structures (i.e.
FPAYH, FPAYHX and FPAYP) or the values in another nodes of DMEE-tree. We will consider
the implementation of both cases. The following are typical fields used in configuration of
conditions:

 
– Arg.1-1 contains reference value that should be checked (reference node, source structure
(FPAYH, FPAYHX and FPAYP) or a constant value);

– Arg.1-2 contains the field of the source structure or a node attribute that should be checked (e.g.
1A – contents in internal format; 1 – contents in output format if some conversion was applied etc.).
The list of all options can be checked via help options (F1). In case you specified the constant value
in Arg.1-1, this column should be empty.

– Type contains the reference to an argument type of reference value (1 – constant value, 2 – field
in source structure, 3 – reference ID).

– Operator specifies which logical comparison should be applied to the reference value in order to
fulfill condition criteria.

– Arg.2-1 contains the comparison value against which the reference value should be compared (the
same possible values as for Arg.1-1).

– Arg.2-2 contains the attributes of the value (the same possible values as for Arg.1-2);

– Type for the comparison value serves the same purpose as for the reference value.

– Operator contains the linking operator and is used in case of several conditions (AND – if both
conditions should be met; OR – if some of the conditions should be met).

1.1 Condition via Reference to another Node of DMEE-Tree

Case: for foreign vendors additional field with information on house bank SWIFT code should be
displayed.

First of all, you have to configure the reference node. You can use the existing fields of the DMEE-
tree or you can define technical nodes ( ) to store reference values that should not be displayed in
payment order. If there are several technical nodes, you can create separate segment to group them
together. In this example a segment with technical node will be used. In any case, specify
meaningful reference ID for the node whose value should be checked e.g. VEND_COUNTRY. You
can use all standard mapping options to fill this field. In this case a field from the source structure
will be used (FPAYH-ZLAND). Example of reference node can be found below.
Remark: DMEE-tree for this example uses segment with two elements LABEL and VALUE. Label
element is mapped to a constant text value (tag) that by default equals to the name of the segment
e.g. “CLN_BANK_SWIFT=”. Value element contains the actual value of the payment order tag.
Typical example can be found below:

Condition will be applied on segment level, thus it will effect both elements. In order to meet stated
requirements, the following condition was configured:

This solution might be good if you use the DMEE only for a specific country (e.g. Ukraine in my
case). But if you want to configure it more flexibly in order to use across several countries you will
have to modify and check whether vendor country equals the country of company code. This data is
available in source structure (FPAYHX-LAND1). The condition should be configured the following
way:

 
Alternatively, you can use complex condition containing the list of specific countries for which the
condition applies e.g.:

In any case, the result would be the same (except the third option): there would be additional line
with house bank SWIFT code for the second payment (payment to a foreign vendor).

1.2 Condition via Fields of Source of Structure

Let’s consider another case building on a previous one. Suppose you want to display IBAN number
for a foreign vendor (if it is configured in master record). For a local vendor, bank account number
should be displayed instead (if there is no IBAN number).

The first complex condition checks whether the country of vendor is the same as the country of
company code and there is no IBAN in master record. If both of these conditions are met, the
segment will be processed and bank number will be output (source: FPAYH-ZBNKN). If one of
them is not met, the segment will not be processed.

The second condition checks whether the country of vendor differs from the country of company
code and there is IBAN in master record. Similarly, if both conditions are met the segment will be
processed and IBAN number will be output in file (source: FPAYH-ZIBAN).

As can be seen from the attached screenshot, bank number of the local vendor is displayed in tag
RCPT_ACCOUNT and IBAN number for a foreign vendor in tag RCPN_IBAN.