Documentation - DOKA-NG (Functional availability is per selected plan)

A description file - xxxSUP.INI - is compiled for each type of document whose messages are structured in a :TAG: data format. In addition, a second file - xxxOVR.INI - can be compiled to override descriptions for certain types of message.

These files contain all the information relating to both the format and description of the message types and tags required for incoming/outgoing processing and for preparing the PrettyPrint of messages. In particular, formatting details are important for mapping incoming processing, for instance.

The following files are currently available in DOKA:

For SWIFT messages, channel SWT

• SWTSUP23.INI and SWTOVR23.INI: as of Swift Release 22.Nov.2023
• SWTSUP20.INI and SWTOVR20.INI: as of Swift Release 21.Nov.2021 until Swift Release 2023
• SWTSUP.INI and SWTOVR.INI: valid as of Swift Release 18.Nov.2018 till before activating Swift Release 21.Nov.2021
• TAGSUP.INI and TAGOVR.INI: before Swift MT Release 18.Nov.2018

For DTALCR messages, channel DTA

• DTASUP23.INI and DTAOVR23.INI: as of Swift Release 22.Nov.2023
• DTASUP20.INI and DTAOVR20.INI: as of Swift Release 21.Nov.2021 until Swift Release 2023
• DTASUP18.INI and DTAOVR18.INI: valid as of Swift Release 18.Nov.2018 till before activating Swift Release 21.Nov.2021
• DTASUP.INI and DTAOVR.INI: before Swift Release 18.Nov.2018

For DTAEA messages, channel DTE

• DTESUP23.INI and DTEOVR23.INI: as of Swift Release 22.Nov.2023
• DTESUP20.INI and DTEOVR20.INI: as of Swift Release 21.Nov.2021 until Swift Release 2023
• DTESUP18.INI and DTEOVR18.INI: valid as of Swift Release 18.Nov.2018 till before activating Swift Release 21.Nov.2021
• DTESUP.INI and DTEOVR.INI: before Swift Release 18.Nov.2018

For DTA Guarantee messages, channel DTG

• DTGSUP23.INI and DTGOVR23.INI: as of Swift Release 22.Nov.2023
• DTGSUP20.INI and DTGOVR20.INI: as of Swift Release 21.Nov.2021 until Swift Release 2023
• DTGSUP18.INI and DTGOVR18.INI: valid as of Swift Release 18.Nov. 2018 till before activating Swift Release 21.Nov.2021
• DTGSUP.INI and DTGOVR.INI: before Swift Release 18.Nov.2018

For TradeConnect messages, channel TCO

• TCOSUP23.INI and TCOOVR23.INI: as of Swift Release 22.Nov.2023
• TCOSUP20.INI and TCOOVR20.INI: as of Swift Release 21.Nov.2021 until Swift Releae 203
• TCOSUP18.INI and TCOOVR18.INI: valid as of Swift Release 18.Nov.2018 till before activating Swift Release 21.Nov.2021
• TCOSUP.INI and TCOOVR.INI for TradeConnect messages, channel TCO before Swift MT Release 18.Nov.2018

For allNETT messages, channel ANT

• ANTSUP.INI and ANTOVR.INI

For DTA-IZV messages, channel IZV

• IZVSUP.INI and IZVOVR.INI

For SmartForms, channel DOI

• DOISUP23.INI and DOIOVR23.INI as of Swift Release 22.Nov.2023
• DOISUP.INI and DOIOVR.INI until Swift Release 22.Nov. 2023

For EasySend, channel ESY

• ESYSUP.INI and ESYOVR.INI

These files are not maintained using DOKA transactions, but can be edited using normal text programs. Amendments can also be made by importing xxxsup.ini.dif files using SYSUPD.

All lines beginning with a semi-colon are purely commentary lines.

The files are divided into sections using lines that contain a concept in square brackets '[xxxxxx]'. Within each of these sections, there are further configuration details. The sections do not have to follow any particular sequence, neither do the lines with a section. However, in keeping with good practise, we would recommend sorting the details either alphabetically or numerically. Sections not required can be dispensed with.

Note: When importing patches using SYSUPD, new values are inserted at the beginning of each section.

Note: Sometimes there are no entries in TAGSUP.INI for pseudotags that pick up header information from SWIFT messages. Nevertheless, these tags can be used in mapping incoming messages. The tags and their formatting details are described in the 'ConvertSwift' function.

Note: If after changing the file error messages occur, that entries could not be found, the reason could be, that invisible characters (e.g. a BOM byte order mark) are standing in front of the square brackets. Remove the characters or insert a line feed, so that the square bracket is the first sign in line.

For each tag, pseudotag and each “MT-nnn” message type, this section holds the description formatted as:

“TAG = <Description>”     and/or     “MT-nnn = <Description>”

For tags that contain a code value displayed in the PrettyPrint as a long text, there can be an additional entry

“COD-<tag>-<type>   =  <Codetable>”

Whereby <tag> is the name of the tag, <type> the type of the tag's field format (see below). <Codetable> describes a codetable where the long text of the code contained in the tag is stored. This can be resolved using an embedded codetable in a data field by entering <MODULE>:<DATAFIELD>. The module must be linked in into the transaction, the PrettyPrint is called from.

Normally, tag descriptions in the [SWIFT-FIOTAG] section are stored in English. If the description is to be displayed in another (user) language in the PrettyPrint, a [SWIFT-FIOTAG-<uil>] section is to be set up, with <uil> = language code, e.g. 'DE'. All tags to be displayed in this language are to be formatted in the same manner as described above. If there is no foreign language description for a particular tag, the description is taken from the [SWIFT-FIOTAG] section.

This section contains both the definition of possible field format types and the definition of the tag format.

Field format types are defined using the line

“FMT<xxx> = <Sign><nnn>”

with <xxx> standing for the code of the format type, and <nnn> the 3-digit length of the (sub-) field. A minus sign '-' means that up to nnn characters appear, a plus sign '+' means that exactly nnn characters appear.

Types can be virtually assigned at will. However, a number are already in the source and are given special treatment there. Amendments/Renaming can have undesirable effects.

Example:

“FMTDAT = +006”     means that the “DAT” type contain precisely six characters

“FMTAMT = -018”    means that the “AMT” type can contain up to 18 characters.

The tag formats are defined in the lines

“    FLD<tag> =  <Format>”

whereby “<Format>” can comprise a combination of several details “<xxx>“    and/or    ”<xxx> *<nnn>”.

<tag> is the message tag and <xxx> the code for the type. The entry <*nnn> (read as “times” nnn), may follow when the tag comprises a number of up to nnn identical types (or lines). Alternatively, one or more <xxx> types can follow when a tag consists of several sub-fields

Example:

“FLD33B  =     AMT”    means that Tag 33B consists of an “AMT” subfield

“FLD31B  =     DAT T65 *4   ” means that Tag 31B consists of a DAT subfield and up to four additional T65 subfields.

In this section, tags are listed in a
“<tag>=Header”
line that form part of the 'header' when message files are imported which may comprise a header and several single messages. When the file is split into its component single files, the header details are transferred to each single message.

This section defines the maximum permitted length of a message, for each message type <xxx>, in a line
“<xxx>=<maxlen>“
providing it differs from the generally valid length permitted for the message channel.

These files contain entries that override the definitions provided in the xxxSUP.INI for the channel.

An [Mxxx] section can be created for each <xxx> message type that contains in the line
“TAG = <Description>“
a description that diverges from the normal description for the tag of this message.

Example:
In the TAGSUP.INI file the generally valid description of Tag 20 is  ”    20 = Transaction Reference Number”.

For the SWIFT MT 700 message, here in the [M700] section, the special 'divergent' description is “    20 = Documentary Credit Number.”

On the other hand, the SWIFT MT 103 message provides another description “    20 = Sender's Reference”.

For tags that contain a code value, which is displayed in the PrettyPrint in long text, there can be an additional entry

“COD-<tag>-<typ>   =  <Codetable>”

<tag> is the name of the tag, <type> the type of the tag's field format (see below). <Codetable> describes a codetable where the long text of the code contained in the tag is stored. This can be resolved this using an embedded codetable in a data field by entering <MODULE>:<DATAFIELD>.

Normally, tag descriptions in the [Mxxx] section are stored in English. If the description is to be displayed in another (user) language in the PrettyPrint, a [Mxxx-<uil>] section is to be set up, with <uil> = language code, e.g. 'DE'. All tags to be displayed in this language are to be formatted in the same manner as described above. If there is no foreign language description for a particular tag, the description is taken from the [Mxxx] section.

In the TCO message channel, there are tags that have various formats in different message types. The reason for this is that TradeConnect is capable of receiving/sending messages in DTALC/DTALCR and DTAEA formats, and the formats and tag descriptions for both of these channels is not identical. On the one hand, these messages contain tags that comply with SWIFT message tags, but also so-called 'M-tags' that contain additional information.

Since formats within a channel are uniform, however, DOKA works with a little trick.

The tags of one channel are converted from their actual Mnn value to a Nnn tag. This conversion is controlled using entries in Section [XXX], which XXX refers to the code for the prefix of the message file.

An individual section is to be entered for each file type to be converted. DOKA has decided in favor of converting tags of DTAEA messages.

Within a section, there are entries for how to proceed with different message types:

• “MT-yyy = YES       ” means that all yyy type tags indicated in this section are to be converted
• “MT-yyy = tag       ” means that only the specific tag indicated for the yyy type is to be converted and details of how a tag is to be converted.

Details of each tag are to be provided is a separate line:

• “M1   = N1”    means that all definition entries for an M1 tag are to be found in tag N1.
• For tag M1, the description and format defined under
• “N1 = <Description>”             and/or “FLDN1 =  <Format>“ 

in xxxSUP.INI are effective.

Note: When generating messages, tags are created/issued as they would later appear in the message file. Therefore, no N-tags are used in message rules.

In addition, there is for Bolero messages, channel BOL

• BOLSUP20.INI and BOLOVR20.INI: as of Swift Release 21.Nov.2021
• BOLSUP18.INI and BOLOVR18.INI: valid as of Swift Release 18.Nov. 2018 till before activating Swift Release 21.Nov.2021
• BOLSUP.INI and BOLOVR.INI: before Swift Release 18.Nov.2018
  

These bolsup-ini-files are only related to Bolero messages which refer to DTD-schema files. bolovr-ini files are always empty. However, given the divergent structure of Bolero messages (XML-files), these files do not follow the structure described before.

For XML messages, the PrettyPrint is created differently as with the afore mentioned FIN related 'tagged' messages. In XML messages there is always a 'path of elements' before the final field with a value. Therefore those elements have to be described in the xxxTXT.ini file. As these elements have always the same name, they need to appear only once in the xxxTXT.ini file.

All elements are shown in the pretty print and infor the full position of a value containing field in the message.

Example: The XML-element-path for an Instructing Agent = Sender of a messages is

<InstgAgt> 
  <FinInstnId>
    <BICFI>ABNANL2AXXX</BICFI>

In a PrettyPrint it is shown as:

Instructing Agent
  Financial Institution Identification
    Bank Identifier Code Of Financial Institution ...... ABNANL2AXXX

The long names of the elements refer to the specification documents of each channel. The full name per element is shown as per each channels specification.

• SXOTXT.ini is used for Swift MX messages.
• These messages are in XML format.

• TARTXT.ini is used for T2 RTGS messages.
• These messages are in XML format.

• BOLTXT.ini is used for Bolero XML messages.
• These messages are in XML format.