Products

Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer

Partner
Partner About
About



Home / Community / Blogs + Actions

Exit modules in DMEE

March 22, 2017 | 2,623 Views |

Bohdan Petrushchak
more by this author

FIN (Finance)

dmee | dmee tree | exit module | function module | pmw

share
0 share
0 tweet share
1

Follow

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 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 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 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 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.

Alert Moderator
 7 Comments
You must be Logged on to comment or reply to a post.

Abdul Hakim

June 10, 2017 at 2:10 am

Very useful blog. Thanks for sharing this with the community.

Thanks,

Hakim

Bohdan Petrushchak Post author

June 16, 2017 at 9:06 am

Hi Abdul,

Thanks for your feedback!

Regards,

Bohdan

Len Spinelli

July 30, 2017 at 10:13 pm

Outstanding.

Leo

Bohdan Petrushchak Post author

July 31, 2017 at 6:15 am

Hi Len,

Thanks for appreciation:)

Regards,

Bohdan

Sergey Chumakov

September 30, 2017 at 3:20 pm

Hi Bohdan.

Recently I’ve found out that DMEE exits now have different interface for
the incoming files.

*” IMPORTING
*” REFERENCE(I_INTERFACE) TYPE
DMEE_EXIT_INTERFACE_INCOM_ABA
*” EXPORTING
*” REFERENCE(E_VALUE)

Any hint how to use it?

Bohdan Petrushchak Post author

October 2, 2017 at 8:54 am

 Hello Sergey,

Thanks for pointing this out. I probably have to add small

clarification to this post – it dealt primarily with DMEE-engine
issues related to generation of outgoing file. I do not have any
experience dealing with user exits with
template DMEE_EXIT_INTERFACE_INCOM_ABA, but upon
quick check it seems that this particular interface is used for
handling of incoming files. Thus it is most probably used in
DMEE-trees with type MCSH “Conversion of Incoming File to
MultiCashMCSH Conversion of Incoming File to MultiCash”,
which can be used to convert non-standard text-based bank
statement to Multicash format, whereas I’ve been discussing
tree type PAYM.

From usage point of view, there shouldn’t be any difference,

you should stick to general rules for usage of exits and take
into account fields available for processing (via definition of
type DMEE_EXIT_INTERFACE_INCOM_ABA in SE11).

Regards,

Bohdan

Bobby Johnson

October 2, 2017 at 8:04 pm

Excellent article Bohdan! This was very enlightening, thank you for sharing!
Share & Follow
Privacy Terms of Use Legal Disclosure Copyright Trademark Sitemap Newsletter