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:

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. This post can also be found on Medium platform under this link.