Skip to Content

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.

You must be Logged on to comment or reply to a post.
  • Hi Bohdan,

    Thank you for taking time in publishing this. I have had some of my doubts cleared through you work.

    In a week or 2, I shall be starting to implement the first set of xml files transmission between our organisation and BNP Paribas in countries like Singapore, India, Hong Kong. Would be kind enough in helping me figure out some of the points

    1. Is CGI_XML_CT format to be used as I think there are no country specific SAP formats for the aforementioned countries and make changes accordingly or what are the formats that you think are generic that would suit any country for me to modify.
    2. Versions like ISO 20022 XML pain.001.001.03 are what I found - are there any specific notes that I need to check before going ahead with the implementation - or in other words what are the mandatory requirements/questions that I need to ask the bank before going ahead with the implementation.
    3. I do not know any coding - if a functional module needs to be used in DMEE; is there any notes/material available that I need to learn to develop any funtional module

    Thanks once again for your time in helping the newcomers like us by publishing such work.

    Best Regards,






    • Hi SAP Learner 2017,

      Thank you for interest in my blog, glad to hear that you've found it useful. You've posted a lot of question which range from very generic to very specific nature. I'm not sure that comments part to this blog is the best place to discuss them, but I'll try to comment a bit.

      1. This is quite specific question, I didn't work with DMEE-formats from any of the countries mentioned by you and I do not know what are your local requirements. Thus, I cannot answer whether CGI_XML_CT is a good format, nor can I recommend any other available format. I would suggest to open this question in a dedicated Q&A part of the SAP forum.

      2. The same applies to this question - you can search OSS-portal looking for notes that cover your country-specific requirements. You - as an expert for local specific - should be able to assess better than me, what is available in the system "out-of-box" and what should be added / fine-tuned etc.

      3. If you do not have any background in development at all, I would suggest to get in touch with local developer and ask him to help you out with your development request. Otherwise, it will take some time to master basic coding techniques before you would be able to write something. Besides, if you do not know ABAP, it is unlikely that your system administrator will give you developer access to the system. Without developer access you won't be able to write anything. From long term point of view, I have plans to write a couple of blog posts on enhancements related to DMEE-applications. So maybe, they would be of interest for you.



  • Hi Bohdan,

    Thank you for taking time in replying back to me. First of all - apologies for a delayed response, as I was traveling.

    Your feedback is highly appreciated - will chalk out a path accordingly.


    Best Regards,



  • Hi Bohdan

    I have a requirement in a DME payment format so that a condition will be met only when processing the first payment document, not for subsequent payments - our bank requires a different tag for the first payment in the file compared to subsequent payments in the same file.
    Can I do this using a counter?


    • Hi Jonathan,

      Yes, you can try to do that by combining a conditions technique and a counter of line items – see my other articles on this topic. Essentially, you will have to set up a condition that will check the counter value and if it is equal to constant value “1”, then you display some fixed value for the first payment, if not – you will display another value in accordance with your bank’s requirements.




  • Hi Bohdan,

    would like to ask how can you combined two fields in one line? let say if Country is US, then NAME1 and NAME2 of customer should be combined.

    Best Regards


    • Hi Chandrahasan,

      No, I cannot share it. The mechanism I've described is universal i.e. can be used for any payment file format if you understand it properly. Please check the post again, it contains enough details to understand how this mechanism works.