The TRNMOD\TRNDOC module contains the data structures and functions required to store information on all documents and messages that are created when a business transaction is stored.
The DOCEOT module list in TRNDOC contains one element (a module instance) for each message created (in the following text the term 'message' is used for all types of messages or documents irrespective of their technical structure). The list of messages is displayed both as a sequential list on the 'Messages' panel and in a tree structure on the 'Attachment' panel that refveals the hierarchical order of messages.
An element in DOCEOT can be uniquely identified either by its ID, assigned when the element is created, or its index within the DOCEOT module list, assigned by system functions.
Messages are created either automatically by opening application functions, primarily “TRNDOC.DefDocEot”, or interactively by user entries made on the 'Attachment' panel.
Important data fields of each DOCEOT element include:
Unique identification of element (document/message) in the DOCEOT grid.
(The index of a certain entry can change while a business transaction is being executed.)
| Value | Meaning |
|---|---|
| 1 | Primary Message A primary message is a text document, which is defined in a transaction or in a module. It triggers the initial creation of the message. A primary message is saved as text document with an appendant record in the table SMH. |
| 2 | Secondary (Forwarded) Message A secondary message is created to forward a primary message in line with mailing instructions (MLI), or by clicking the [Copy To] or [Send To] button on the message details panel. If the medium of the secondary message allows this (i.e. is either a letter, or allows attachments) a cover sheet with an internal link (in IDREF) to the primary message is created. Otherwise, the secondary message is created by transforming the content of the primary message into a format appropriate for the medium selected (e.g. a SWIFT MT 799). This transformation is determined by the “DOCEOT.DetermineConversion” rule. When a secondary message is saved, a record in the table SMH containing a link to the SMH of the primary message is created. The cover sheet itself can be suppressed. In this case, only the reference to the primary message is used. |
| 3 | Not used |
| 4 | Manually Created Top Level DocumentAn additional document created manually by clicking the [Add New] button on the attachment panel. |
| 5 | Attachment An attachment, created either manually by attaching an existing document/file to a top level document using functions on the 'Attachment' panel or created automatically by the application. |
Forwarding (LEV.is(“2”) ) and attachments (LEV.is(“5”)) are two alternative ways to forward documents. Which of the method is appropriate in each case basically depends on the technical and organisational circumstances.
Issues to be considered include:
Only [Send To] allows you to print a paper original with a cover sheet for mailing purposes (with different addresses on the two documents).
Forwarding messages via [Copy To]/[Send To]/(LEV.is(“2”) ) allows you to copy information over channels that do not generically support such functionality (e.g. SWIFT and other tagged formats). This automatically extracts content and transforms it to an appropriate message form, while attachments allows you to transport multiple messages in an unmodified form to (additional) recipients - providing this is permitted by the channel/transport medium (e.g. Email (any format) or Fax (printable formats only)).
Type of Copy
| Value | Meaning |
|---|---|
| O | Original |
| S | Send Original To (for LEV.is(“2”) only) |
| C | Send Copy To (for LEV.is(“2”) only) |
If this flag is set (i.e. <> space) this document will not be created/shown and the line in the Messages panel is shown as a disabled line.
This flag is set for optional level 1 documents, if the panel is 'suppressed' on the Details-Panel, or by passing mandatoryflag=2 to “defdoceot”.
As it is not created when the business transaction is stored, a suppressed message cannot be forwarded or attached to another document, i.e. such references to a document will be suppressed automatically when the referenced document is suppressed.
For LEV.is(“2”) IDREF contains ID of forwarded documents
For LEV.is(“5”) and ATTTYP=“INT”, IDREF contains ID of referenced document
For LEV.is(“5”) (i.e. attachments) only: ID of message where this entry is attached to (i.e. ID of parent)
Type of reference to an attached document.ATTTYP/ATTINR is filled only when LEV.is(“5”), so that this DOCEOT element represents an attachment
| SMH | Already existing SMH (incoming or outgoing) |
| FIL | Existing file |
| INT | Reference to document that is created in same transaction |
If “ismodified(ATTTYP)” this means that this entry has been added manually, i.e. cannot be deleted automatically but must be deleted manually (not only suppressed)
Identification of the attached document, the actual value depends on ATTTYP
| Value of ATTTYP | Meaning of Content |
|---|---|
| SMH | Contains SMH\INR of referenced, already existing SMH (incoming or outgoing) |
| FIL | Name of existing file, file was stored in “GetFullName( “tmp”, ATTINR )” and is copied to data/docs during “savdoc” |
| INT | Empty (IDREF contains ID of referenced document) |
Technical Format (Medium)
This is the format in which the message is technically created (e.g. XML, SFT, or TCO). Transactions can contain rules for each primary message that create the respective format. However, it is also possible to convert between two formats automatically (e.g. the content of a letter can be converted into a SWIFT message of type MT799 or MT999). The technical steps for such conversions are determined in the “DetermineConversion” rule. Typically, a technical format is permanently attached to a technical transmission channel ('Letter' to post, 'SWIFT' message to SWIFT, …).
Form Set
A form set defines the number of copies of the message to be printed on each application form. In a form set it is possible to define which technical form (type of paper) is to be used and how many copies are to be printed out for each application form.
Number of copies for each application form.
APFCPY1 contains the number of originals to be printed for this document, APFCPY2, APFCPY3, and APFCPY4 the number of copies for the respective application forms as defined by the Form Set.
For LEV.is(“2”) 'original' here means the number of originals of the cover sheet (i.e. the original of this DOCEOT entry)
For LEV.is(“2”) APFCPY5, APFCPY6, and APFCPY7 determines the number of copies of the forwarded document to be printed under this DOCEOT entry. If the entry is an entry with ORIFLG.is(“S”) these numbers are identical with the number of copies displayed for the primary message.
For secondary messages ( i.e. entries in the messages grid created in line with mailing instructions, or interactively by clicking the [Copy To] or [Send To] button) the form set defines the number of copies for the cover sheet (displayed in the first column) and the respective numbers for the forwarded document (in the second column). If the cover sheet is suppressed, the number of copies to be printed can be entered for the forwarded document (in the second column) only. In this case no cover sheet is generated or printed and the [Show] button in the messages list is disabled (as the forwarded message can be displayed in its original position in the grid only).
Attachments (and actually any document) can be printed automatically only if the application has a component that knows how to format this type of document. For this reason, generic attachments (such as documents attached using drag&drop) cannot be printed as their internal structure is unknown to the application. For such documents (where medium is 'File') the number of copies must be '0' for all application forms. Whether a message of one CORTYP can be attached to message of a given CORTYP is determined by the “TRNDOC.CheckAttachmentType” rule on level 5 (e.g. any file is allowed as attachment to an Email while only documents that can be output in .pdf format might be eligible to be attached to a telefax document (depending on technical fax interface).
Workflow entries that execute services required to handle different media types/communication channels are set when the message is saved in “DOCEOT.savdoc” by executing the corresponding “TRISM.WfmAdd_xxx” method (predefined or as implemented in project overlay).
In outgoing messages, additional information is often sent to the receiver. In SWIFT messages, this text is mainly found in Tag :72:. Such texts are usually captured in relevant text fields available on the Message Details panel. It is possible to default these text fields especially for certain messages. The “RegisterAddTxt” function can be used for this.
Text blocks are often used in outgoing messages that were previously defaulted in the transaction. In some cases, these text blocks can be edited by the user. Texts are usually defaulted in the user language. However, it is not unusual to want texts to be defaulted in the language of the respective document. If the user has changed the field in any way, the language of the text cannot be amended. If the contents of the text block has been determined (i.e. defaulted) by the application, it is possible to run the default again before the document is finally created. To do this a 'dummy' reference to the TRNMOD\TRNDOC\TXTDEFFLG field has to be entered in the appropriate default.
A number of channels are dealt with similarly when outgoing messages are compiled. The “GetUseCorTyp” function is used to assign these channels to each other. Here, for instance, FAX is usually converted to LET, etc. Internally, the CORTYP field from DOCEOT is converted to the CORTYP to be used. While the document is being output, the original entry for the field is temporarily ignored. However, if it is important to be able to recognize the actual CORTYP, this can be read from the TRNDOC\DOCCURORICORTYP field.
The “TRNMOD.SWTGetAllowedCodes” rule checks the codes that are permitted per Tag and message type. For each of these codewords supported by the rule and for which there is a prescribed formatting, another rule, “TRNMOD.CheckSWTCode”, runs a check. Alternatively, a rule that can be launched from “TRNMOD.CheckSWTCode” will run the check of the codewords.