In spite of many advances in payment technology, it is common to be asked to remove special characters and national characters from payment files. This usually occurs in one of three situations:

• Certain payment layouts use special characters as line delimiters. Therefore, these characters cannot be contained in any descriptive text included on payments.
• Country clearing systems may not allow certain types of characters. For example, any characters outside of the permitted Kanji and Katakana languages in Japan without proper ? tags around the text cause payments to fail.
• Banks may have legacy processing systems that are unable to handle special characters.

To review a payment layout to add these function modules, the layout must first be called up for editing by executing the DMEE (Data Medium Exchange Engine) transaction code (Format Tree Maintenance Tool). The DMEE transaction code is not in the menu path, so you need to enter it directly. After you execute transaction code DMEE, the system displays the screen shown in Figure 1.

Figure 1

Selection of a payment format tree type

To change the payment layout, enter Tree Type paym. In the format field, enter CGI_XML_CT for the layout. Click the change button to change the layout as shown in Figure 1.

Within the format, the detailed conversion occurs at the lowest level of the file in which the data is selected from the Payment Medium Workbench (PMW) structures. There are multiple ways to set up a reference to the data from the SAP structures used by the PMW. Conditional atoms and nodes are two of the most common ways refer to the structures used to perform the data selection. Nodes are very straightforward, and simply refer to the field that should be selected from the payment structures. Conditional atoms are used when different fields should be selected for different cases for the same file field. For example, consider a scenario in which your bank requires you to include the name of the vendor that is receiving the payment. To meet this requirement, you need a way to populate the vendor name. For this example, assume this process can be accomplished by pulling values either from the Account Holder field or the Vendor name field. Conditional atoms are used in these situations, as shown in Figure 2. Conditional atoms are used when different fields are used to populate output upon meeting output criteria. In Figure 2, the account holder field (KOINH) is shown.  The important distinction for special characters and conversion between nodes and conditional atoms is ensuring the conversion is set at the lowest level. If a node is being used to select data from the PMW structures, then the conversion is added at the node level. If conditional atoms are used, the conversion is at the atom level.

Figure 2

The DMEE transaction showing the attributes for the Nm node of the payment tree

Next to the Conv. function field is the detail view: conversion icon . Click this icon to display additional conversion options for this field (Figure 3). Available conversion options are linked to the type of field. Figure 3 shows the character conversion options that are available.

Figure 3

Detail view: Conversion options

There are two sets of options to use for this field: Alignment and Additional options.

Alignment positions the data in the field either on the left, right, or as unjustified:

Left-justified aligns along the left margin starting in the first position.

Left-justified with ending zeroes aligns along the left margin starting in the first position and adds ending zeroes for the remaining places in the field up to the field length.

Right-justified aligns along the right margin starting in the first position.

Right-justified with leading zeroes aligns along the right margin starting in the first position and adds leading zeroes for the remaining places in the field up to the field length.

Unjustified does not specify any justification to the text in the field for alignment.

Additional options settings contain text formatting options to handle additional formatting:

All Characters in upper case converts all lowercase characters into uppercase characters.

Replace National Characters removes all national characters. This ensures only simple characters are used. SAP has a standard function module called SCP_REPLACE_STRANGE_CHARS. This function module is called when the setting to replace national characters is activated.

Remove special characters removes the following characters from the file: - + * / . : ; , _ ( ) [ ] # < > These special characters are a standard set provided by SAP.

Replace leading zeroes replaces zeroes with spaces in a field that is padded with leading zeroes.

Convert to Numeric characters takes a character string and converts it into a number using ABAP coding rules.

To replace national characters, select the Replace national characters check box and click the Copy button (refer back to Figure 3).

This check box must be selected for each field where the conversion is necessary. This setup completes conversions at a detailed level in the file.

The Exclude/Allow defined characters check box is combined with the values in the character definition box as shown in Figure 4. If the option for Do not Allow these character is used, then the values in the Charact. Box will be excluded. If the option for Allow Only These Charact. Is used, then only the characters within the Charact box will be included.

Figure 4

An example of special character definition for an XML file tree

If Do Not Allow These Charact. is selected, then the items in the Charact. Field are removed from the file. If Allow Only These Charact. is selected, then only the characters in the Charact. field can be used. The standard CGI XML layouts will be set up to exclude characters that are no permitted per the ISO20022 XML standard. These can be modified if additional characters are identified that cannot be sent to the bank by adding the characters to the list. Once you have selected one of the options, click the save button to save the values.

To better understand how an individual field conversion would work to remove characters, individual field values can be tested by using ABAP function modules. To preview how a function module would convert data for a file without running a payment program to create a file, select the function module by executing transaction code SE37. This action displays the screen shown in Figure 5 in which you enter SCP_REPLACE_STRANGE_CHARS in the Function Module field.

Figure 5

Testing a function module

Click the test function module icon  to execute the function module. Code page 1146 is used by default if no code page is specified by your payment layout within the ABAP for the function module. Paste text for conversion in the INTEXT field as shown in Figure 6.

Figure 6

Paste text into the INTEXT field for testing replacement of national characters

Click the execute icon  to see the results of the conversion as shown in Figure 7.

Figure 7

Results of data conversion for special characters

Finally, Figures 8 and 9 show the master data before conversion and the data on the payment file after the conversion. This example is displayed from vendor master data by executing transaction codes XK02 or XK03 and is part of the general vendor details. Figure 8 has several national characters as well as a # special character.

Figure 8

Vendor master data for a street address with national and special characters

Figure 9

Output of the XML payment

Now that the settings for the payment layout are saved, the changes can be tested for the appropriate payment program, such as F110 or F111. Generate a test file through the steps typically used by your organization for generating these payment files.

You have now successfully eliminated both the national characters and special characters that could cause your payment files to fail.