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.
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!
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 alghouth I modified it for the purposes of this blog post.
P.S. This post can also be found on Medium platform under the following link.