Exit modules in DMEE

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.