SWIFT messages created in a business transaction are made up of two parts.

The first part of the message (logical header) contains the following pseudo SWIFT tags:

The second part of the message up to the trailing '-' comprises the actual SWIFT message (message body) in standard SWIFT format.

The SWIFT message is initially created as a .TXT file.

A check to determine if the maximum permitted message length has been exceeded is already run during the business transaction. Since the header is not yet completed at that point, it is possible in individual cases that the problem will only be detected by the SWIFT service SRVSWT. To prevent this situation from occurring, the module DOCIMM contains the variable SWTHEADIF, which indicates the number of characters that are to be added as a “safety margin”. In the product, this value is set to '60', representing the number of characters that normally results from the difference between the length of the pseudo SWIFT tag and that of the header added subsequently.

The service SRVSWT (usually called from within the transaction MGRTSK) uses the .TXT files to create new files which contain SWIFT messages in the format required for the SWIFT Terminal System (depending on the particular SWIFT Terminal used, both the message structure and the file extension may differ slightly). SRVSWT replaces the document header up to and including the EOH tag with a SWIFT Basic Header Block and an Application Header Block, and places the actual message (the message body) inside a SWIFT text block ( “{4: ” ). The resulting message is stored in a file with the file extension required for the relevant SWIFT Terminal.

If a SWIFT message exceeds the maximum length permitted for a SWIFT message (set in the INIT rule of SRVSWT), then SRVSWT splits the message into a sequence of messages (e.g. MT700 and MT701, in accordance with the SWIFT rules). This sequence of messages is saved in a single message file. If a message was split in this way, then additional SMH rows are generated (one for each message). These rows contain the INR of the original message in the field GRPINR, and the sequence number (first digit of tag 27) in the field GRPSEQ. MSGPOS and MSGLEN reflect the sequential position of the individual messages within the generated file. The fact that the message was split (i.e. that the message created during the transaction was split into the messages that were actually sent subsequently) is indicated in the SMH row of the originating message by setting GRPINR to its own INR and GRPSEQ to zero.

The display functions (SMHP.FRM) use this information to allow a user to display all versions as required: the original message and its PrettyPrint formatting, or the individual messages and their PrettyPrint representation.

If a message exceeds the maximum length in Tag 79, the automatically DOKA generates:

• in TAG 79 of the message, the text 'for Details see separate MT799' and
• one or more MT 799 messages with the complete texts.
  

For this purpose, TRNDOC contains the additional field TAG79TXT999.

Individual formatting and sending of messages to a communication system can be implemented in “SRVSWT.SendMessageCus”.