SMH - Structured Message Header

This table keeps track of all messages handled by the application.
This includes incoming and outgoing messages.

In case multiple messages are located within one file multiple SMH entries might point to the same message file identifying the individual messages by different positions (MSGPOS and MSGLEN) within this
file.
In case a single message is split into more than one message file the individual SMH entries might be grouped together (GRPINR and GRPSEQ).

The messages are usually associated to a contract (OBJTYP and OBJINR) and a processing transaction (TRNTYP and TRNINR).

/

INR

Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter SMH. The field INR is used to maintain links from other tables into this table.

Unique internal ID of a record within the table. The INR is a text field, which is created by retrieving the next valid entry from the counter of this table. The field INR is used to enable links from other tables to this table.

For contractdata the INR also links the two tables xxD and xxT as associated entries hold the same INR.

Object type of the owning contract. (e.g. LID, GID). For messages, which are not yet associated to a contract, this field is left blank. Used together with OBJINR. For historical reasons this field has a lenght of 6 character, but for new entries only the first 3 are used.

Object type of the holding contract (e.g. LID, GID).

INR of the owning contract. For messages that are not yet associated to a contract, this field is left blank. Used together with OBJTYP.

Unique ID of the holding contract.

This field specifies the table the TRNINR is associated to. (Typically TRN)

This field specifies the table the transaction ID is associated to. (Typically TRN)

INR of the transaction which created or processed the document. This field is filled for every outgoing message on save. For incoming messages this field is filled during the save of the processing transaction.

Unique ID of the transaction that created or processed the document. This field is filled everytime an outgoing message is saved. For incoming messages, this field is filled when the processing transaction is saved.

Sub ID to uniquely identify a created message and get a defined order within a transaction. The counter value is taken from the field SMHNXT in the TRN.

Sub ID to uniquely identify a created message and get a defined order within a transaction.

Field to identify a message: This field is generated for created messages by the routine SMHEXT based on the TRNINR and the address identification.

For incoming SWIFT messages this field is used to join partial messages (i.e. TAG 27 where TAG 27 is filled but not '1/1'). For this purpose this field is filled as follows to contain sender, sender's reference, message type and TAG 27.

Mid( IO, 1, 8 ) + “ ” + Mid( SNDREF, 1, 16 ) + “ ” + Mid( MT, 1, 3 ) + Mid( T27, 1, 3 )

The field identifies a message. For incoming SWIFT messages this field is used to combine partial messages (e.g. TAG 27 where TAG 27 is filled but not '1:1').

Field to identifiy the Structured Message Header.

Field to identifiy the Structured Message Header.

On outgoing messages the message creating user.

For outgoing messages the field indicates the user creating the message.

Transaction, which created this SMH entry.

Currently only filled in autoregistration.

Transaction, which created this SMH entry.

Currently only filled in autoregistration.

On outgoing messages the date and time when the message was created.

For outgoing messages, the field defines the date and time when the message was created.

Direction of the message. Outgoing messages created by the application are marked with '>'. Incoming messages created by external applications or other parties are marked with '<'. Autoregistration and manual entered messages are marked as incoming with '<'. Internal incoming messages might be marked with '[' instead of '<' to mark them as internal

Direction of the message. Outgoing messages created by the application are marked with '>'. Incoming messages created by external applications or other parties are marked with '<'.

Path where the document is stored. The path should be relative to the data partition of the application. If the path is specified absolute this document might not be relocated.

Path where the document is stored. The path should be relative to the data partition of the application. If an absolute path is specified it might not be possible to relocated this document.

File ID of the document.

File ID of the document.

File extension of the document. This file extension is used to determine the type of document. The file extension is stored without the delimiting dot. To build the real file name DOCFIL has to be concatenated with a dot and with DOCFXT.

File extension of the document used to determine the type of document. The file extension is stored without the delimiting dot. To build the real file name, the document name, dot and the file extension have to be concatenated.

This field might either be empty if no protecting MAC has been created or it has to contain the MAC of the created message/document.

This field can either be empty if no protecting MAC has been created or can contain the MAC of the created message/document.

Field to identify the position of a single message within a multi message document. A value of zero refers to the whole document. A value of one refers to the first byte of the document file.

(1=Begin of Document, 0=Whole Document) Field to identify the position of a single message within a multi-message document. A value of 0 refers to the whole document. A value of 1 refers to the first byte of the document file.

This field specifies the length of a message within a multimessage document file. A value of 0 specifies the rest of the document as document.

This field specifies the length of a message within a multi-message document file. A value of 0 specifies the rest of the document as document.

In case a message is technically split into additional split messages, or other secondary copies of the original message are created (e.g. a SWIFT copy sent via x99) this field holds the INR of the original main message. In case incoming messages are joined to build the logical complete message the same applies. Thus all logically grouped together SMH entries are linked by filling this field with the INR of the first or the main message. Not yet linked messages which need to be joined with other messages have to keep this field empty, as this flags not yet processed partially messages.

If a message is technically split into partial messages, or if other secondary copies of the original message are created (e.g. a SWIFT copy sent via x99), this field contains the unique ID (INR) of the original main message. The same applies to incoming messages merged to build the logical complete message. Thus, all logical SMH entries grouped together are linked by filling this field with the INR of the first, or the main, message. For messages not yet linked that need to be merged with other messages this field has to be kept empty, as these flags do not process sub-messages.

If a group of SMH entries is built by filling the GRPINR field the sequence of the messages is specified by this field.

GRPSEQ=0 indicates the group leader

For outgoing split messages (i.e.SWIFT): Original message before split gets GRPSEQ=0

For outgoing messages with attachments (e.g. TC, EML,BOL): GRPSEQ = 0 for 'Main message'=Group leader GRPSEQ > 0 for attachments

For incoming multipart messages that are joined (e.g. SWIFT) GRPSEQ = 0 for message 1/x

For incoming multipart messages with attachments (e.g. TC, EML, BOL) GRPSEQ = 0 for main message GRPSEQ > 1 for attachments

If a group of SMH entries is formed by filling in the INR field, this field specifies the sequence of the messages.

'0' indicates the group leader

For outgoing split messages (e.g. SWIFT): Original message before split gets GRPSEQ=0

For outgoing messages with attachments (e.g. TC, EML,BOL): GRPSEQ = 0 for 'Main message'=Group leader GRPSEQ > 0 for attachments

For incoming multipart messages that are joined (e.g. SWIFT) GRPSEQ = 0 for message 1/x

For incoming multipart messages with attachments (e.g. TC, EML, BOL) GRPSEQ = 0 for main message GRPSEQ > 1 for attachments

Defines the message structure/syntax used to create/interpret the message. On outgoing messages the value of this field is taken from the CORTYP of the DOCEOT entry. On incoming messages the value of this field is defined by the processing service.

Defines the message structure/syntax used to create/interpret the message.

Defines the service for the message structure/syntax used to create/interpret the message.

Defines the service for the message structure/syntax used to create/interpret the message.

Application form used to print the message.

'NOP' means 'Message cannot be printed'

Application form used to print the message.

'NOP' means 'Message cannot be printed'.

Identifier to be used to address a receiver in the used communication media. For example Swift BIC, Telex no., Fax no. Email address, etc.

Identifier to be used to address a receiver in the used communication media. For example Swift BIC, Telex no., Fax no. Email address, etc.

Contains a sequence of up to 10 entries of 5 bytes each that describes how many copies are to be printed.

Every entry contains the application form (icf APF\TYP e.g. 'ORI' or 'CPY' in byte 1-3 and a string giving the number of copies to be printed for this form in byte 4 and 5 (e.g. '01').

Contains a sequence of up to 10 entries each of 5 bytes that describes how many copies are to be printed.

This field identifies the sender/receiver of this message. If the address of this message is taken from the database, the INR of the PTA identifying the used address is stored here. If no database address is taken this field is left blank.

This field identifies the sender/receiver of this message. If the address for this message has been taken from the database, the ID of the party that defines the address used is stored here. If an address is not taken from the database this field is left blank.

A=SMH Attachments means, ORISMHINR contains INR of SMH containing document F=File Attachment means, DOCxxx contains name of file attachment

A = SMH Attachments, i.e. the ID of the original message comprises the ID of the SMH containing document F = File Attachment, i.e. DOCxxx contains the name of file attachment

If the message is a automatically created copy or replace of an original message the INR of the original SMH is stored here.

If the message is a copy or replacement of an original message created automatically, the ID of the original SMH is stored here.

This field is filled to mark partial incoming messages. Thus messages for which the number of partial messages is greater one and GRPINR is not yet set.

If not empty, the message is not yet complete. The field contains the number of partial message, i.e. “1/2”.

If the message is complete, GRPINR/GRPSEQ fields are used to group the partial messages together and this field is reset to a blank value.

This field is filled to mark partial incoming messages, i.e. messages for which the number of partial messages is greater than 1 and INR field has not yet been set.

If the field is not empty, the message is not yet complete. The field contains the number of the partial message, e.g. “1/2”.

If the message is complete, INR and sequence fields are used to group the partial messages together and this field is reset to empty.

Technical type of message received or sent.

Technical type of message received or sent.

If a relevant amount for this message can be determined the currency of this amount might be stored here. Otherwise this field is left blank.

If a relevant currency for this message can be determined the currency can be stored here. Otherwise, the field is left blank.

If a relevant amount for this message can be determined this amount might be stored here. In this case the associated currency has to be stored in RELCUR.

If a relevant amount for this message can be determined, this amount can be stored here. In this case the associated currency also has to be stored.

This entity might be optional used to define an entity used as sender of this message. This field is sometimes named 'logo entity' as for paper output the letterhead + senders address is defined by this entity.

This entity might be optional used to define an entity used as sender of this message. This field is sometimes named 'logo entity' as for paper output the letterhead + senders address is defined by this entity.

list of additional receiver (additional to SNDKEY) currently used for Email only

every line contains one receiver <type of copy> tab <receiver>

where <type of copy> is one of the following: cc: bcc: sendto: (currently not used)

List of additional receiver (additional to field 'Receiver Key') currently used for Email only. Every line contains one receiver.

This table is defined on entity level with separate entries for each entity. This field holds the EXTKEY of the owning entity to identify the logical owner of this entry. This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity are visible to the user.

This field holds the external key of the owning entity to identify the logical owner of this entry.

This field is filled automatically during insert and is used as filter when accessing the database. Without special implementation only entries of the currently active entity are visible to the user.

STP-Nachricht: Straight Through Processing

STP-Message: Straight Through Processing

Field holding the concatenated and normalized sum of all search fields used by quick search. This is one of the fields set in a SdbSetNRMFields method defined in the table definition module.

Field holding the concatenated and normalized sum of all search fields used by quick search. This is one of the fields set in a SdbSetNRMFields method defined in the table definition module.

Key to allow for checking of dublicate allnett attachments send to allNETT customers.

Build same ways as EXTKEY but allow for 50 digits

TRNINR + “:” + PANDSC

Key to allow for checking of dublicate allnett attachments send to allNETT customers.

Build same ways as EXTKEY but allow for 50 digits

TRNINR + “:” + PANDSC

Where applicable, this field will be filled with the SWIFT UETR.

SWIFT UETR is used to globally identify payment messages in order to allow to request the status of any payment by any participant in the payment chain at any time.

This field will be filled with a UETR.

UETR (Unique End-to-End Transaction Reference) is mandatory part of many payment standards, e.g. the SWIFT GPI, Swift CBPR+ and T2 RTGS. It provides an universally unique end-to-end reference across a payment transaction. It is used to globally identify payment messages in order to allow to request the status of any payment by any participant at any time. The UETR is generated by the initiating party of a payment message.

Outgoing messages For Swift FIN MT messages, the UETR is added to the field 121 of the payment message (e.g. MT103, MT202) by the SWIFT message service. For ISO20022 based payment messages (e.g. Swift CBPR+, T2 RTGS etc) it is part of the “Payment Identification” block and added by the message service for XML messages.

Incoming messages For the incoming messages, as the application does not handle incoming payment messages, the UETR is only displayed but not mapped.

This field holds the version counter to keep track of the version history of an SMH entry. The individual versions are controlled by entries in the SLG table.

This field holds the version counter used to keep track of the history of an entry of this table. The individual versions are managed by entries in the SLG table.