Drucken

Um die Art und Weise wie in der Applikation gedruckt wird zu verstehen, sind zunächst einige Begriffserklärungen erforderlich.

Eine Nachricht kann ein Brief oder eine elektronische Nachricht sein. Eine Nachricht basiert immer auf einem existierenden Textdokument, welches über einen dazugehörigen Datensatz in der Tabelle SMH referenziert wird. Bei Nachrichten werden die folgenden Nachrichtenarten unterschieden:

Eine Primärnachricht ist ein Textdokument, welches in der Transaktion oder in einem Modul definiert ist und die initiale Erzeugung der Nachricht auslöst. Eine Primärnachricht wird als Textdokument mit einem dazugehörigen Datensatz in der Tabelle SMH gespeichert.

Eine Sekundärnachricht wird auf Basis von Versandinstruktionen aus dem Defaulting der Empfängeradresse gebildet. Die Sekundärnachricht ist ein Deckblatt mit einem Verweis auf die Primärnachricht, sofern die Primärnachricht bereits in dem Format gemäß Versandinstruktionen vorliegt. Andernfalls wird eine Tertiärnachricht erzeugt und in dem Deckblatt auf diese verwiesen. Eine Sekundärnachricht wird als Textdokument mit einem dazugehörigen Datensatz in der Tabelle SMH gespeichert.

Tertiärnachrichten sind konvertierte Primärnachrichten, die von Sekundärnachrichten in einem anderen technischen Format benötigt werden. Eine Tertiärnachricht wird als Textdokument mit einem dazugehörigen Datensatz in der Tabelle SMH gespeichert.

Ein zusätzliches Dokument welches manuell durch klicken des [ Neu] Buttons auf dem Panel “Anhänge” erzeugt wird.

Ein Anhang, entweder manuell erzeugt durch Anhängen eines existierenden Dokuments/Datei an ein Top Level Dokument über die Funktionen des “Anhänge” Panels oder automatisch erzeugt durch die Applikation.

Das Format, in dem eine Nachricht technisch erzeugt wird, z.B. XML, SFT oder TCO. In den Transaktionen kann es je Primärdokument für die verschiedenen Formate Regeln geben, die das jeweilige Format erzeugen. Es ist aber auch möglich, zwischen allen Formaten automatisch zu konvertieren (z.B. kann der Inhalt eines Briefes in eine SWIFT-Nachricht vom Typ MT799 bzw. MT999 konvertiert werden). Typischerweise ist ein technisches Format fest an einen technischen Versandweg gekoppelt (“Brief” per Post, “SWIFT”-Nachricht per SWIFT, …).

Ein technisches Formular (TEF) beschreibt die Papiersorte, auf der gedruckt werden soll, wie z.B. Briefbögen mit vorgedrucktem Briefkopf, Blankopapier oder Sicherheitspapier. Aus dem technischen Formular ergibt sich der zu verwendende Drucker und Schacht des Ausdrucks (in den die benötigte Papiersorte eingelegt ist).

Ein Applikationsformular bezeichnet ein logisches Formular, auf dem eine Nachricht ausgedruckt wird. Die Applikationsformulare “Original” und “Customer Copy” sind immer vorhanden. Diese beiden und weitere mögliche Applikationsformulare sind mit ihrem Langtext in der Codetable APFTYP gespeichert.

Ein Formularsatz gibt an, wie viele Exemplare einer Nachricht auf welchen Applikationsformularen gedruckt werden sollen. Außerdem werden im Formularsatz zu jedem Applikationsformular die Anzahl Ausdrucke und das technische Formular (Papiersorte) festgelegt.

Die ersten drei Stellen des sechsstelligen Keys eines Formularsatzes bezeichnen die Formularklasse. Die möglichen Formularklassen bestehen aus zwei Gruppen:

Die möglichen Formularklassen für Papierdokumente bezeichnen Kategorien von Papieren (wie z.B. Allgemeiner Brief , Garantieurkunde, Interne Notiz). Die möglichen Werte werden installationsspezifisch festgelegt (Embedded Codetable am Feld MLI:APFCLA).

Für jedes elektronische Medium (SWIFT, Telex, FAX, E-Mail) existiert eine zusätzliche Formularklasse.

Formularsätze werden über die Transaktion “Verwalten von Formularsätzen” (DBIAPF) erstellt, bzw. gepflegt und haben einen sechsstelligen Key (COD). Die ersten drei Stellen des sechsstelligen Keys bezeichnen die Formularklasse, die restlichen drei Stellen den Formularsatz innerhalb der Formularklasse.

In der Tabelle APF werden die Formularsätze gespeichert, wobei eine Zeile in APF die Werte für ein Applikationsformular innerhalb eines Formularsatzes beschreibt. Alle Zeilen in APF mit übereinstimmendem Key (COD) machen den Formularsatz aus.

Die Tabelle APF enthält:

• In der Spalte COD den Namen des Formularsatzes.
• In der Spalte TYP den Code des Applikationsformulars. Ein Formularsatz darf maximal 4 Applikationsformulare enthalten.
• In der Spalte PRI (Priorität) die Reihenfolge der Appllikationsformulare innerhalb des Formularsatzes. Das erste Applikationsformular muss immer “ORI”ginal, das zweite immer “COP”y sein (damit die Spaltenbeschriftung in der Nachrichtenübersicht der Geschäftstransaktion korrekt ist).
• In der Spalte CNT den Defaultwert für die Anzahl Ausdrucke.
• In der Spalte EDTFLG ein Kennzeichen, ob die Anzahl in der Geschäftstransaktion änderbar ist oder nicht.
• In der Spalte TEF das technische Formular (Papiersorte) auf dem dieses Applikationsformular gedruckt werden soll.

Innerhalb der Geschäftstransaktion wird für jede Nachricht ein Formularsatz, passend zur Formularklasse, festgelegt. Für Papierdokumente wird die Formularklasse durch die Geschäftstransaktion bestimmt. Wenn ein elektronisches Transportmedium (SWIFT, Telex, ..) verwendet wird, bestimmt das Medium die Formularklasse (z.B. darf bei SWIFT kein “Original” gedruckt werden, da das Original per SWIFT versandt wird). Der Formularsatz mit dem lexikographisch kleinsten Code für die Formularklasse (üblicherweise <Formularklasse>+“001”) wird automatisch vorgeschlagen. Wenn für die Formularklasse mehrere Formularsätze existieren, kann der Benutzer aus diesen eine abweichende Auswahl treffen.

Für Sekundärnachrichten definiert der Formularsatz die Anzahl Kopien für das Deckblatt (angezeigt in der ersten Spalte) und, wenn der Versandtyp “Kopie an:” ist, die entsprechende Anzahl für das weitergeleitete Dokument (in der zweiten Spalte) sofern das Medium selbst ein Brief-Format ist (d.h. ausgedruckt und physisch auf Papier transportiert wird). Der Ausdruck von “Originalen” der Primärnachricht kann hier nicht eingestellt werden.

Für Sekundärnachrichten, die als “Sende an:” weitergeleitet werden, zeigt die zweite Spalte mit der Anzahl Kopien für das Dokument (d.h. die Primäre Nachricht) die entsprechende Anzahl für die Primäre Nachricht (inklusive Anzahl Originale).

Wenn das Deckblatt unterdrückt wird, kann die Anzahl der zu druckenden Kopien nur für das weitergeleitete Dokument angegeben werden (in der zweiten Spalte). In diesem Fall wird kein Deckblatt erstellt oder gedruckt und das Icon in der Nachrichtenübersicht ist deaktiviert (da die weitergeleitete Nachricht nur an ihrer ursprünglichen Position im Grid angezeigt werden kann).

Anhänge (und eigentlich jedes Dokument) kann nur automatisch gedruckt werden, wenn die Applikation weiß, wie dieser Dokumententyp zu formatieren ist. Aus diesem Grund könnnen generische Anhänge (wie per Drag&Drop angehängte Dokumente) nicht gedruckt werden, da ihre interne Struktur der Applikation nicht bekannt ist. Für solche Dokumente (mit Medium “File”) muss die Anzahl Kopien für alle Formularsätze “0” sein.

Für den interaktiven Ausdruck von angezeigten Dokumenten oder Reports wird immer das Drucksystem des Clients (Client Side Printing) verwendet. Die hier möglichen Drucker werden über die Funktionen des Betriebssystems (z.B. Windows Druckdialog) ausgewählt. Ein spezieller Standarddrucker für die Applikation ist nicht vorhanden. Werden Ausdrucke von nicht direkt angeschlossenen Druckern benötigt, z.B. für Filialen oder Partner, kann über die in der Entwickler-Dokumentation beschriebenen RemoteClientPrinting-Funktionen gesteuert werden, dass diese externen Systeme ihre eigenen Drucker konfigurieren können.

Um automatisch einen Formularsatz für ein Dokument ausdrucken zu können, muss für jedes im Formularsatz verwendete technische Formular (Papiersorte) bestimmt werden, auf welchem Drucker und in welchem Schacht dieser Ausdruck erfolgen soll (damit der Ausdruck in der Nähe des für die weitere Hantierung verantwortlichen Benutzers und auf der gewünschten Papiersorte erfolgt). Das gleiche Prinzip wird für den Ausdruck aus Service für eingehende Nachrichten verwendet, allerdings wird hier nur ein technisches Formular spezifiziert (also kein Formularsatz mit mehreren Formularen).

Für die benutzerabhängige Bestimmung des Druckers für jede technische Form können auf folgenden Niveaus Drucker und Schacht je nach technischem Formular (Papiersorte) konfiguriert werden:

1. Benutzer
2. Benutzergruppe
3. Entity
4. Default

Die Konfiguration erfolgt in den Profil-Editoren für Benutzer (Transaktion “Verwalten von Benutzerprofilen” DBIUSR), Benutzergruppen (Transaktion “Verwalten von Benutzergruppen” DBIUSG) und Entity (Transaktion “Verwalten von Entities” DBIETY) und für den Default interaktiv im “Taskmanager” MGRTSK im Panel für den Service. In diesem Panel wird auch definiert, auf welchem Niveau das Nachfassen (USR → USG → ETY) für das Ermitteln der Konfiguration beginnen soll. Fehlende Einträge führen dazu, das auf der nächst höheren (folgenden) Ebene weitergesucht wird.

Im Panel des Service kann für den Ausdruck jedes technischen Formulars spezifiziert werden:

• auf welchem Drucker / Schacht gedruckt werden soll, wenn die benutzerabhängige Druckerbestimmung kein Ergebnis liefert (Wert für 4. Default)
• ab welchem Niveau (1.- 4.) die Suche beginnen soll

Für den Workflow-gesteuerten Ausdruck kann in Client/Server-Installationen bestimmt werden, ob der Druck über das Drucksystem des Benutzerinterfaces (auch “client side printing” genannt) oder über das Drucksystem des Applikationsservers (auch “server side printing” genannt) erfolgen soll. Die Auswahl der verfügbaren Drucker ist hiervon abhängig.

Bei Applikations-Servern, die unter einem Unix-Betriebssystem laufen, gilt zusätzlich:

• Die Tabelle der verfügbaren Drucker kann über die Transaktion “Verwalten von Druckerkonfigurationen” (DBIPRC) gepflegt werden.
• Bevor eine Nachricht ausgedruckt wird, wird ein Druckauftrag für den SRVPRT-Prozess erzeugt. SRVPRT konvertiert das Dokument in eine Postscript-Datei und übergibt diese an die entsprechende Druckerwarteschleife des Servers.

Mit der Transaktion “Test Drucksystem” (SYSPRT) kann verifiziert werden, dass die Konfiguration der Druckersteuerung wie beabsichtigt funktioniert.

Verschiedene Applikationsformulare für eine abgewickelte Geschäftstransaktion können zu verschiedenen Zeitpunkten im Workflow ausgedruckt werden. Dies wird wie folgt erreicht:

Mehrere Instanzen des Druckservice (SRVPRT, SRVPRR, SRVPRS) können innerhalb des Workflow-Managers ausgeführt werden. Die Konfiguration für alle Instanzen des Druckservice erfolgt in einem gemeinsamen Konfigurationspanel. Beispiel: Wird durch die Serviceorder der Service SRVPRT ohne Vorbedingung ausgeführt, der Service SRVPRS aber erst nach dem Commit-Service (SRVCOM ) und gleichzeitig in der Konfiguration des Printservices das Applikationsformular “COP”y in SRVPRT verarbeitet wird - das “ORI”ginal aber in SRVPRS gedruckt wird - steht die gedruckte Kopie frühestmöglich (z.B. schon für die Freigabe) zur Verfügung. Das Original wird aber erst dann gedruckt, wenn die Transaktion nicht mehr zurückgerollt werden kann (also insbesondere nach der Freigabe).

Die Druckausgabe aus dem Hintergrund-Manager erfolgt in wahlfreier Reihenfolge, d.h. nicht alle zu einer Transaktion gehörenden Dokumente werden direkt hintereinander ausgedruckt. Um die Zuordnung nach dem Ausdruck zu erleichtern, wird der “Printcontext1” im Ausdruck automatisch mit dem Namen des Druckjobs (= TRNINR+Laufnummer des Dokumentes für diese TRN) gefüllt. Wenn diese Nummer z.B. im Fuß am linken oder rechten Rand in klein gedruckt wird, kann man feststellen, welche Papierdokumente zu einem Vorgang gehören. Hierfür sind die Dokumenten-Footer entsprechend anzupassen.

Soll für eine Gruppe A gedruckt werden und für eine andere Gruppe B nicht (Beispiel: automatischer Ausdruck von Eingangsnachrichten), kann mit folgendem Trick gearbeitet werden: Es wird ein neues Formular eingerichtet, auf dem zu drucken ist. Außerdem ein neuer Drucker “NULL”. Das Formular wird für Gruppe A auf einem normalen Drucker, für Gruppe B auf dem Drucker “NULL” gedruckt. Das Druckscript wird so angepasst, dass es für den Drucker “NULL” keinen Printoutput erzeugt.