Messages in DOKA-NG are composed of the following parts:

• Document Panel
• Document Rules
• XML Elements
• RegisterDocument Rule

If one of these components is missing, the message cannot be prepared correctly.

Information on the page break can be found under Document Rules.

All rules, panels and XML elements directly connected to the messages are to be set at level 8. Customized new developments are to be set at level 6.

The structure of the letters is created dynamically. Because they position items relatively, only XML elements are used (i.e. no commands such as “PrintVertical” etc. are used, since they position items absolutely). This is the only way to secure continuous structure to the message.The structure of the documents is to be as flat as possible. Normally the use of two levels is sufficient.Letters in the product are structured according to German DIN standards, which means that four lines are left between recipient address, subject and salutation.

Literals in single quotes (“'Literal'”) are translatable and literals in double quotes (““Literal””) are not translatable. If literals are copied, the already existing translations will not be transferred and have to be edited manually afterwards.Ideally, the text should only be output using XML elements, not arguments, since this would make a subsequent global translation almost impossible (contexts are mostly not traceable any more).

Since it is possible for a message or parts of a message to be used in two or more business transactions, it is time-consuming and error-prone to create the message(s) each time from scratch and to maintain the message(s) later. In this case it is advantageous to centralize the respective sectors. A sub rule has been introduced for this purpose. It can be launched at any time from the respective location. The Modules used for this purpose are described in detail in chapter “Document Rules”.

If the whole document rule is sourced out into a central document rule, the following naming convention applies:

* “XMLPrt<Message Title>“If only a part of a document rule (e.g. the introduction text ) is sourced out into a central module, the following naming convention applies:

* “XMLPrtBody<Message Tile><Description of the rule content>”, e.g. XMLPrtBodyAdviceOfDocumentStart

A document panel has to be provided before a message can be generated.

A new document panel is created using the context menu in the “Module Explorer” in sector “Panels” by selecting “New Panel \ XML Document”.

The (technical) Name of the panel is made up usng the following structure:

“xxTyyyLn” (“xxT” = business sector, e.g. “RMT”; “yyy” = [main-] recipient of message, e.g. “ISS”; “L” = Letter [always]; “n” = consecutive number), e.g. “RMTISSL1”.

The Description should be easy to understand because it will be used later as short description for the respective letter on the message panel.

The properties “Visible” (Visualization in the tab bar) and “Popup Panel” should be disabled, since messages may only be displayed by clicking [Show] on the message panel (clear design).

The display size of the message on the screen can be found under “Size”. The default is set to 640 x 400 pixels.

Usually, the Security Level of the panel is 8.

The required Page Format can be selected on the tab “Format” (Default: “A4 [.XSI]”). The settings of the “*.”"XSI" file will be displayed in the field below. It is not possible to change the settings here. Those have to be changed directly in the file with a text editor.

Supported languages can be selected on the tab “Language” (standard: “German” and “English”). This enables the user to manage the languages available on the message panel. Furthermore, a default language has to be set (standard: “English”).

Technical comments (in English) can be entered on the “Comment” tab.

A page is subdivided into three areas:

• page header (“document header”)
• page body (“document”)
• page footer (“document footer”).

The arrangement of these areas is defined in a “\INI\*.XSI” file (Standard: “A4.XSI”). The letter is aligned here, i.e. settings of the margins (e.g. for positioning the recipient address). To apply a format which differs from the standard letter format (e.g. landscape), a new “*.XSI” file (for example. “A4landscape.XSI”) should be created.

To change the existing format, change the respective “*.XSI” file directly with a text editor. Please note that the changes need to be made for all three options (“first page”, “even pages” and “odd pages”). Differences between these three options are only allowed if reasonable (for example, if the following pages should have a smaller page header).

The standard settings for “A4.XSI” are:

• Left/right margin = 20/15 mm
• Top/bottom margin = 10 mm
• Start of text text body on 1st page = 46 mm (from the top margin)
• Start of text body on the following pages = 31 mm (from the top margin)
• Start of footer = 25 mm (from the bottom margin)

A header (page header) or footer (page footer) is defined outside of the “document” rule, i.e. within the “documentheader” or the “documentfooter” rules.

Within a header/footer rule a page header/footer can be defined for up to four situations (so-called header queues):

1. for the first page of the document (= “tdPageFirst”)
   
2. for the last page of the document (”=” “tdPageLast”)
3. for all (other) pages (if no special header/footer is specified for the first/last page → also for these pages) (= “tdPage”)
4. special header/footer for one-sided documents (= “tdPageSingle”)

The output assigned to a particular queue is done by block instructions “beginheader/ -footer” “(<header/footer queue>) …” “endheader/ -footer”.Outputs outside the block instructions go into the “tdPageLast” queue.

A redefinition of the headers/footers takes place within “the document” rule(s). Another header/footer can be set as standard header/footer with:

beginheader/footer" [**without** queue definition] 
     print using <XML variable of the new dynamic header/footer>
endheader/footer.

This header/footer is from the current page on (including the current page) the new valid page header/footer. By assigning the header/footer to a particular position within the message (the directly preceding output is outside the header/footer area), the header/footer will be used independently from a particular page number from this page on, at this defined position.

Dynamically defined headers/footers take priority over the statically defined ones.

The static header or footer will be re-enabled for this page by an empty header/footer block (in this case it is important that no document output takes place).

The output of a letter on a message panel at a specific point in time is controlled by the “RegisterDocument” rule. This can be found with the “Module Explorer” under “Rules\Local Procedures”. The main component, however, is the “DefDocEot” rule. This rule is retrieved as follows:

“TRNMOD\TRNDOC.defdoceot( trigger , SubId , argDocPanNam , APFCOD , mandatoryFlag , argPtaInr , ObjMod , PanDsc , Role , argAdrBlk )”.

Description of the “DefDocEot” arguments:

1. “trigger” = 1. ID (as a rule ““TRN”” = Transaction/ ““SET”” = Settlement)
2. “SubID” = 2. ID (e.g. ““ISS1””, i.e. short form of the technical document name)
3. “argDocPanNam” = Tech. name of the document (e.g. ““\\RMTISSL1””)
4. “ApfCod” = Technical output option (normally ““LET””, which allows controlling the output tray)
5. “mandatoryFlag” = “1” mandatory/ “0” not mandatory/ “2” not mandatory, initially suppressed
6. “argPtaInr” = Address according to “PTAINR” (e.g. “RMDGRP\ISS\PTS\PTAINR”)
7. “ObjMod” = Which contract (object) does this document belong to? [e.g. “RecGetPath( RMDGRP )”]. This also controls whether messages from subcontracts of related transactions are part of the subcontract or main contract. In DOKA, messages are assigned to the subcontract. In LITDAV, for example, “RecGetPath (BRDGRP)” is used.
8. “PanDsc” = Determines the description of the document in the message table (message grid) [e.g. “GetDescription( RMTISSL1 )”]
9. “Role” = Determines the role in the message table (message grid) (e.g. ““ISS””). This argument is mandatory. If no role can be indicated (e.g. for internal messages) “OWN” should be set.
10. “argAdrBlk” = Address according to “ADRBLK”, if “PTAINR” is not available (e.g. “RMDGRP\ISS\PTS\ADRBLK”)

There is a call to DefDocEotCUS (level 5) procedure in DefDocEot.The in/out argument for this procedure is the mandatory flag, and this can overwrite the mandatory flag for all documents regardless of what is delivered with the DefDocEot call. This makes is possible to manage messages that are to be suppressed and those not, for each specific customer.

Useful rules for the manual control of the message output in “RegisterDocument” are:

• “TRNMOD\TRNDOC.SetMdtFlg( <SubID>, mandatoryFlag )” - Controlling the document defaults
• “TRNMOD\TRNDOC.SetCORTYPList( <trigger>, <SubID>, “LET” + CR + “TLX” + CR + “FAX” )” - Controlling the transmission channel
• “TRNMOD\TRNDOC.SetDOCUIL( <trigger>, <SubID>, <Language> )” - Controlling the document language
• “TRNMOD\TRNDOC.SetKeyAmount( <trigger>, <SubID>, ApfCod, <Amount>, <Currency> )” - Determines the key encrypted amount for Telex/S.W.I.F.T
• “xxDGRP\<Role>.IsRolSet” - checks, whether a specific party is available in the contract
• TRNMOD\TRNDOC.DOCSNFdefault ( <Trigger>, <SubID>, <delivery option> ) - Default of the delivery option, e.g. with “per certified mail”
• TRNMOD\TRNDOC.SetDocDat (“<trigger>, <SubID>, <DocDate datetype>) -” Sets the date of a message to another value (e.g. sending documents via second mail at another date than the first mail)