Last Review: 26th July 2019
Reading time: 15 minutes
How to create your own Payment Format?
During our implementation projects we will face the need to create new payment formats to ensure our payments are successfully processed by the banks.
In the following blog, we will explore with some practical examples on how we can use the Map Payment Format Data Fiori app (SSCUI 500283, task 100558).
Let’s first start to explore the app Map Payment Format Data
On the left-hand side of the screen, you can see the nodes of the file. A node is an element that stores information or gets information.
On the right-hand side, you can see all the properties and attributes of each node.
Every format is defined by properties and these are stored in the top node of the format. Let’s explore these properties into more detail.
In the Attributes tab, you can give a Description to the format, assign a tag (for example, you can use this to tag your format to a specific institution or country).
The Format Parameter Structure relates to pre-delivered structures by SAP with standard content.
In the File Data tab, you can define the exclusion of certain characters, if required. This will exclude all the other characters from the string you defined.
This can be useful for banks that do not accept special characters, which means that you can easily ensure these are excluded to prevent errors.
Levels and repetition factors indicate the levels of nodes and how many times they can appear in a file.
For example, you can define a header level with only one repetition factor, which means that this level will only appear once and a Line Item level can be repeated up to 9999999 times in the output file.
You can assign payment data fields to the levels in the file and indicate how the fields should be sorted.
If sort field is selected as a key field, then a change to the value in this field causes the corresponding format level to end. You need to define the key fields correctly to ensure that, during file generation, the sequence of the different levels is output as they are defined in the format.
If you want the company code (FPAYH-ZBUKR) to be at level 1, you may specify it as shown above.
As the repetition factor for Leve1 is 1, this information is only displayed once in the Media file. If you have 2 company codes, then the media file would be split into two separate output files for the two company codes.
These structures refer to the DDIC structures, specifically FPAYHX structures, on which we will focus in more detail.
Variables can be used in order to store the results of simple mathematical operations. These variables can then be referenced in calculation nodes or other nodes where they can be assigned.
Variables can be of type numeric or date. Additionally, if required an initial value can be maintained for the variable.
Variables may be used to add a counter to the header for the number of items in a file if required.
Some banks may not allow empty nodes. So you may need to ensure that the output file will not be generated with empty nodes.
This is possible with Post Processing functions. SAP delivers different functions that you may use.
Having explored the generic attributes of the payment format, let’s create more nodes now.
Types of Nodes
There are different types of nodes used in flat files and .xml files. Let’s look at them one by one.
Element
Used in both xml and flat file. This is used to get values for the media file. For each element, it is necessary to define its attributes and a mapping procedure (we will explore this in more detail later). It is possible to have xml attributes as subnodes.
XML attribute
Used in xml file only. This can be a subnode of an element that will contain specific attibutes to the main node.
For example, in the below screenshot an XML attribute xmlns is assigned atoms ISO and Para.
This attribute will inherit the values from the assigned atoms. In this example, one of the atoms is assigned a constant value, while the other atom determines the value for a structured field based on an assigned condition.
Technical Node
Used in both xml and flat file. This is used as a node that is not present in the media file, but is used to store information that will be used in other nodes and can act as reference to other nodes.
In most files, technical node are similar to variables and can be used to create a counter which can then be referenced in other items of the file, such as an aggregation.
If, by any chance, you want to use the technical node in the output file, you can convert the technical element into an element.
Atom
Used in both xml and flat file. This can be used to output more than one value to a single value based on a condition. You need to create an atom when you define more than one mapping rule for an element.
Let’s take the following example: one element node that can take the output value of the payment method and it can be CHK or TRF (check or transfer).
You should create a top node “payment method” and two subnodes as atoms. One atom should be a constant CHK assigned to the condition that this atom should output value if the check is used in the payment method. On the other hand, the second atom should output the constant TRF in case no check is created in the payment method used.
Calculation Node
This is used in both xml and flat files to output the result of a mathematical operation. The source for these operations can be constants, references ID’s, structure fields or variables.
Flat Files have other specific nodes
Segment Group
This is used to group segments. Segment groups can include segments or other segment groups. In most cases, a new level in a format begins with a segment group.
Segment
This represents a record in the target file. In an active payment format mapping, each segment must have at least one composite or one element as a subnode. If you create a segment that contains only segments and segment groups as subnodes, you can convert then the node to a segment group.
Composite
This is used to group elements. For example, you use a composite when one condition applies to several consecutive elements.
Mapping and Conditions
Each node has a source. We call it mapping procedure, because we are mapping payment information into a tag/node.
There are several mapping procedures we can use.
Constant
When a specific node is required to have a fixed value, the mapping procedure Constant should be used. It is possible to determine the desired length, the type of field, a conversion function (which will apply a specific format to the field, for example: leading zeros), and the constant value to be populated.
Structure
When the payment run is being carried out, data structures will be created in order to store payment related information. Standard structures are delivered, so we can use this stored information to populate a node on the payment file.
Reference to node
A reference ID can be assigned to a node, to uniquely identify it for future reference. This will make for an easier selection of a multiple use case field and we only need to assign a value to the first one, and then assign the other nodes to that identifier.
Aggregation
The reference ID (explained above) can also be used with the Aggregation mapping procedure.
The options for aggregation are doing the Sum of Values, a counter for the Number of Occurrences, or the Sum of Absolute Values.
Variable
This can be used in order to store the results of simple mathematical operations. These variables can then be referenced in calculation nodes or other nodes where they can be assigned.
Conditions
Conditions can be applied to a node, so that a rule is defined, that will influence the population of that node.
Here is an example of how these conditions may be:
In this case, the system will check if a specific structure field is equal to a constant, and this node will be populated.
This will always be applied as a logic, and can be combined with multiple items (meaning several logics, using operators “and”, “or”.
In the next blog of this series we are going to provide real life examples and show you how we can build mapping in order to satisfy certain requirements.
Other blogs in the series:
Blog I - Accelerator for Payment Media
- SAP Managed Tags:
1 Comment
