This transaction is used to maintain field mappings for incoming messages.

This transaction allows fields in an incoming electronic message to be assigned to fields in the application. The field definition enables incoming messages to be mapped automatically to the fields in the related business transaction.

Note: If a message type cannot be mapped to a target transaction, the transaction “Routing of Pending Items” (SPTROU) is specified as target transaction. If a target transaction can be determined, but no mapping has been stored, all fields for the incoming message are displayed in the target transaction under “Unmapped”. If the mapping is unsuccessful because a codetable entry is missing, the fields that have not been mapped are also moved to “Unmapped”.

The following transactions can be started by clicking the icons in the list below for:

• Adding a Field Mapping
• Modifying Field mappings
• Deleting Field Mapping
• printing field mapping(s) for incoming messages.
• creating Field Mapping List
• showing Version Log of the modifications to the field mapping(s) for incoming messages.

• to Export Field Mapping for Incoming Messages
• to Import Field Mapping for Incoming Messages

After selecting the source format (via the “Source” combobox) and the message type, message tags (Tag) mappings with the application fields (Destination Field) are displayed in the table at the bottom of the panel. The associated transaction in each case is displayed in the field with the same name.

The “transaction” can be entered or searched using the icon which will display all the transaction mappings of the entered message type.

Note on SWIFT Score messages: Score messages are MT798, where 77E contains an embedded customer-to-bank or bank-to-customer message. The mapping must be created for the embedded message. Both the MT798 and the embedded message each contain a tag :20:. For tag :20: of the embedded message, REF.2 has to be entered in the subtype for the mapping.

To support especially the testing of incoming messages due to regulatory changes such as SWIFT 2018/2020 with different character sets (‘X’, ‘Z’) or mapping requirements for the same message type, it is possible to handle one alternative mapping per message type and target transaction.

The checkbox “Alternative mapping” will display the alternative mappings and allows the user to apply any changes if required. Depending on the SWIFT activation date (defined in Maintaining System Configuration), the application will use the correct mapping in the “Manager for Incoming Messages”.

With the introduction of New Sequences in Guarantees, many field tags have been used in both the sequences with the same name. To identify the same field tag in different sequence, Sequence (B, C) is added as a suffix to the Sub ID in the mapping.

In addition, an option is provided to copy an existing mapping from the database, or to copy a definition from an external file .

Select the existing field mapping you want to modify, then click the icon. It is possible to modify or delete existing field descriptions, or to add new field descriptions by using “-/+” buttons.

“Overwrite” must be checked if any existing field content in the target field is to be replaced by the field content of the current message.

“Transformation” describes how the tag content is to be transferred to the application. It is possible, for example, to transform a BIC directly into an address, a code into long text, etc..

The most frequently used transformation is 'Codetable'. If an 'embedded Codetable' has been defined for the target field that is to be used, then the “Argument” column must be left empty; otherwise the codetable to be used must be entered there. Doing so causes the codetable entries used in the message to be displayed correctly in the application (e.g.: MT 700 mapping of 'Type of LC' (LCRTYP) to LETOPN).

If the values in the message that are available for a field are identical with the longtexts in the application, then the transformation 'Codetable' is selected together with the table that is also assigned to the application field. In this context it is irrelevant, in which language the longtext is known in the system.

If there are other values available that can unambiguously be assigned to the values known or stored in the application, a transformation table has to be defined. This table has to include the value known or stored in the application as a key and the longtext as the message value. This is handled differently if the message contains several different values that are to be assigned to the same key: in this case, a transformation table is defined whose key is at least one digit longer than the key of the field in the application. The longtexts are then assigned to the desired key, and an additional sequential number (or language flag) is assigned also.
This makes the keys of the transformation table formally unique once again. When a value is copied to an application field, the attached part is removed again, however, so that only the part known in the application remains.

However, it must borne in mind that the resulting values may have to be returned again by the application (e.g. in the execution confirmations back to TradeConnect). If the mapping is not unique, it has to be determined which unique value needs to be returned (for example, from the constellation of several field contents) when sending back the data.

During this transformation, a check is run to see if the field content exists in the form of a code in the codetable nominated in the “Argument” column (empty = embedded Codetable of the target field). If not, nothing is transferred. An example would be currency details that can be checked against the CURTXT codetable.

This transformation resolves the field content from the incoming message against the codetable indicated in the “Argument”' column and the code, including its long text from the codetable, is made available in “Unmapped”. The result is that fields that cannot be transferred automatically and only contain a code are displayed to the user in a comprehensible form. The user can then decide what needs to be done on the basis of this information. To define such a transformation, a codetable with the codes from the field in the incoming message needs to created first. The text that is to be displayed in Unmapped together with the code needs to be entered in the “Text” column.

'Neg. Amount' is used to provide a tag that in terms of content represents a negative amount, with a 'minus' sign in the application, i.e., to display a negative amount (e.g.: MT707 to LETAME. Tag 33B contains 'Decrease Amount'; however, in messages it is passed on without the leading minus sign. In the application, this tag is entered in the field “Increase Amount” by setting the transformation as a negative amount.)

A 'Numeric Value' is used for fields that use the Sub-ID 'NBR' to specify that this is a numeric field.

'BIC Resolution' is used to resolve a BIC (Bank Identifier Code) contained in an incoming message into an address stored in the application.

As with BIC Resolution, but for BICs represented by a 12-digit terminal code. The terminal code is removed. If the branch code is 'XXX', this is also removed prior to the resolution.

The resolution of an address by means of a key contained in the incoming message, which is used to authenticate the address. The address is resolved for a specific channel using the values stored in PTM table.

Fields that are not to be used can be skipped by selecting 'Ignore'. As a result, they will not appear in the “Unmapped” list in the transaction.

This transformation method makes it possible to include fields in the mapping rules yet still display them under “Unmapped” in the transaction. Unlike the situation in 'Codetable for Unmapped', content will not be transformed. The field content for the incoming message is displayed one-to-one in “Unmapped”. Technically, such mapping entries are not necessary, but they can enhance the documentation of the use of tags in incoming messages.

'Text to date' converts a 6-digit (YYMMTT) or 8-digit (YYYYMMTT) date in text format to a date field of type 'Date'.

The 'TradeConnect-ID' is used for the mapping of TradeConnect messages.

Tags in a message in which 2 parts of variable length separated by '/' can be mapped accordingly using this function. TX1 then takes the field contents before the '/', and TX2 takes the field contents after the first '/'.

Transformation logic based on the Purpose code (tag 22A of a SWIFT MT760) is available if the same tag of the same sequence needs to be mapped to different destination fields based on the purpose codes.

Purpose codes as arguments can be defined either for Transformation as ‘Purpose code (22A)’ or for ‘BIC Resolution’.

Allowed purpose codes are ISSU, ISCO and ICCO. Internally the logic is designed in such a way that all other purpose codes (such as the ones for the amendment) adapt accordingly.

Purpose codes ADVI, ACNF, ISAB, ISAW, ADVA, ACNA, ISUA will pick the same mapping defined for ISSU.
Purpose code ISCA will pick the same mapping defined for ISCO.
Purpose code ICCA will pick the same mapping defined for ICCO.

Select the field mapping to be deleted and then click the icon. After confirmation of the deletion, the selected field mapping is deleted from the database.

Field mappings (also: field maps) can be imported or exported via the and buttons. The transaction “Export Field Mapping for Incoming Messages” is used for exporting, and the transaction “Import Field Mapping for Incoming Messages” is used for importing.

Field Mapping