To understand the way the application prints, it is important to define a number of concepts.

A message can be letters or electronic messages. A message is always based on an existing text document, which is referenced by a corresponding record in the SMH table. The following types of messages are available.

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.

A secondary message is created to forward a Primary Message due to mailing instructions 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 a letter or allows attachments) a cover sheet with an internal link to the Primary Message is created. Otherwise the secondary message will be created by transforming the content of the primary message into a format appropriate for the selected medium (e.g. a SWIFT MT 799). 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.

An additional document created manually by clicking the [ Add New] button on the “attachment” panel.

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.

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). Typically, a technical format is permanently attached to a technical transmission channel ('Letter' to post, 'SWIFT' message to SWIFT, …).

A technical form (TEF) describes the type of paper used for printing (for example, writing paper with preprinted letterhead (LTR), blank paper (BLK), or security paper (SEC). The technical form determines the printer to be used and the tray for the printout. The trays contain the various types of paper.

An application form is a logical form on which a message is printed on. The application forms 'Original' and 'Customer Copy' are always available. These two and any other possible application forms are stored together with their longtexts in the APFTYP codetable.

A form set defines the number of messages to be printed on each application form. In a form set it is possible to define which technical form (type of paper) has to be used and how many copies have to be printed out for each application form.

The first three digits of a six-digit key of a form set define the form class. The possible form classes consist of two groups:

The possible form classes for paper documents determine categories of papers (e.g. general letter , guarantee document, internal note). The possible values will be specifically determined for each installation (embedded codetable in the MLI:APFCLA) field.

A form class also exists for each electronic medium (SWIFT, Telex, FAX, Email).

Form sets are created/maintained using the “Maintaining Form Sets” (DBIAPF) transaction and have a six-digit key (COD). The first three digits determine the form class (category of paper) and the remaining three digits determine the form set (number of printouts) within the form class.

The values for an application form within a form set are defined in a line in APF. All lines in APF with matching codes result in the form set.

The table APF contains:

• The name of the form set in the COD column
• The code of the application form in the TYP column. A form set may contain up to four application forms
• The sequence of the application forms within the form set in the PRI (Priority) column. The first application form must always be 'ORI'ginal and the second one must always be 'COP'y (to ensure that the column headings in the message overview of the business transaction is correct)
• The default value for the number of printouts in the the CNT column
• An indicator that shows if the number in business transactions can be changed or not, in column EDTFLG.
• The technical form (type of paper) on which the application form is to be printed in column TEF.

Within the business transaction, a form set which is appropriate for the form class will be determined for each message. For paper documents the form class is determined by the business transaction. If an electronic transport medium is used (e.g. SWIFT, Telex, ..), the medium determines the form class. Example: within SWIFT, no 'Original' may be printed, because the original document is sent per SWIFT. The form set with the lowest lexicographic code of the form class (usually <Form Class>+'001') will be automatically defaulted by the system. If multiple form sets exist for the form class, the user can select one from these form sets.

If the definition of the form set allows this, the number of copies for some or all of the Application Forms of the Form Set for one message can be modified interactively.

For Secondary Messages the form set defines the number of copies for the cover sheet (displayed in the first column) and if the forwarding type is 'Copy To:' the respective numbers for the forwarded document (in the second column) if the medium itself is in letter format (i.e. is printed and transported physically on paper). No printout of 'Originals' of the forwarded Primary Message can be requested here.

For Secondary Messages that are forwarded as 'Send To:' the second column with the number of copies for the document (i.e. primary message) shows the respective numbers for the Primary Message (including number of originals).

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 icon in the messages list is disabled (as the forwarded message can be displayed in its original position in the grid only).

Attachments (and 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 (like documents attached using drag&drop functionality) can not 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.

When it comes to the interactive printing of documents/reports displayed, the client print system (Client Side Printing) is always used. Available printers can be selected using the operating system (e.g. Windows Print Dialog). A particular default printer for the application is not available. If other printouts are required from printers that are not directly connected (for branches or associates, for example), the Remote Client Printing function, described in the developer documentation, can allow these external systems to configure their own printers.

To print out a form set for a document, both printer and tray need to be defined for each technical form (type of paper) used in the form set. This ensures that the printout is in the vicinity of the user responsible for further processing and on the right type of paper. The same principle applies also to the printing of incoming messages. However, in this case only a technical form is specified (i.e. no form sets with multiple forms).

To define a user-dependent printer for each technical form (type of paper), printers and trays can be specified at the following levels:

1. User
2. User Group
3. Entity
4. Default

The different profile editors configure details for users (“Maintaining User Profiles” DBIUSR transaction), user groups (“Maintaining User Groups DBIUSG transaction) and entities (”Maintaining Entities“ DBIETY transaction) and for the default details are configured in the ”Task Manager“ MGRTSK in the panel for the service. There is space of this panel to define any follow-up level (USR → USG → ETY) used in the configuration. If there is no entry the search will continue on the next higher (following) level.

In the printout panel for each technical form, specifications can determine

• the printer/tray used for printing, if the user-dependent printer definition leads to no result (value for the fourth default)
• the level from which (1st until 4th) the search should start

In client/server installations, workflow-controlled printing allows users to determine whether the print system for the user interface (also called 'client side printing') or the print system for the application server (also called 'server side printing') is to be used. The selection of the printer depends on this choice.

In addition, the following applies to application servers running on a Unix operating system:

• the table of available printers can be maintained via the ”Maintaining Printer Configurations“ (DBIPRC) transaction
• before a message is printed out, a print job is generated for the SRVPRT process. SRVPRT converts the document into a postscript file. This file is then passed to the respective print queue of the server.

The ”Test Print System“ (SYSPRT) transaction can be used to verify whether the printer configuration functions as intended.

Various application forms for a completed business transaction can be printed out at various points in time in the workflow. This can be accomplished as follows.

Multiple instances of the print services (SRVPRT, SRVPRR, SRVPRS) can be processed within the Workflow Manager. All print instances are configured in a common configuration panel. For example, if SRVPRT is processed by the service order without condition, but SRVPRS is only to be executed after the SRVCOM commit service while at the same time the application form 'COP'y is processed in SRVPRT, but the 'ORI'ginal is printed in SRVPRS, the printed copy will be available as early as possible (e.g. release time). However, the original will only be printed when the transaction can no longer be rolled back (especially after the release).

The printout handled by the background manager is processed at random, i.e. not all documents belonging to one transaction are printed out consecutively. To facilitate assignment after the printout, 'Printcontext1' is automatically filled with the name of the print job (= TRNINR+sequential number of the document for this TRN). Printing this number out, for example, in a small font size in the footer of the left or right hand margin, makes it possible to determine which document belongs to which transaction. For this purpose the document footer needs to be adapted accordingly.

If documents are to be printed out for Group A, but not for Group B (e.g. automatic print out of incoming messages), the following trick may be helpful: set up a a new form that is used for printing, and a new printer 'ZERO'. For Group A, the form is printed out on a normal printer, for Group B, printer 'ZERO' is used. The print script is adapted in such a manner that no print out is generated for printer 'ZERO'.