This table holds the information of all documents handled by the application.

For generated documents the entries are generated when saving the transaction. Generated documents are always linked to the contract and the generating transaction.

Incoming documents or messages are linked to the registration during the import. The transaction picking up the incoming message links the document to the contract.

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 holding contract (e.g. LID, GID).

Unique ID of the holding contract.

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

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 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.

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

Transaction, which created this SMH entry.

Currently only filled in autoregistration.

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 '<'.

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 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 can either be empty if no protecting MAC has been created or can contain the MAC of the created message/document.

(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 multi-message document file. A value of 0 specifies the rest of the document as document.

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 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.

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'.

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 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 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, 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 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, 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.

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 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.

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

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-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.

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

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.