Konfiguration in der Version des Transaktions-Formulars
Ist die Konfiguration des Transaktions-Formulars korrekt eingerichtet, sieht die Information zur Beilegersteuerung im R-S für die Version des Transaktions-Formulars wie folgt aus:
Abbildung A
Abb. A (1): Zeigt an, das die Verwendung von physikalischen Beilegern erlaubt ist
Abb. A (2): Zeigt an, das die Verwendung von logischen Beilegern erlaubt ist
Abb. A (3): Es soll verhindert werden das optionale Beileger einen Porto-Sprung verursachen
Konfiguration in der Schema-Version
In der Schema-Version des Formulars sind nun drei logische Beileger definiert:
- LOG1 ist der logische Beileger 1 - als optional definiert
- LOG2 ist der logische Beileger 2 - als optional definiert
- LOG3 ist der logische Beileger 3 - als obligatorisch definiert
Ergebnis aus der Vorschau zur Schema-Version
Im Testdatenstrom für die Druckvorschau sind zwei Dokumente enthalten, welche nun nach den Beilagen-Regeln aus dem Transaktions-Formular, den logischen Beilegern aus der Schema-Version und den Einstellungen nach Post-/Portobedingen aus der Konfiguration des ReportWriters aufbereitet werden. Das Ergebnis ist eine PDF-Datei mit folgendem Inhalt:
Dokument1
- Blatt 1 - Dokument-Seite aus dem Transaktion-Formular
- LOG3 - der obligate logische Beileger aus der Schema-Version
- LOG1 - der erste optionale logische Beileger aus der Tabelle der logischen Beileger aus der Schema-Version
==> LOG2 wird weggelassen, weil dieser einen Porto-Sprung von Standard-Pist auf Kompakt-Post erzwungen hätte --> dies ist aber nicht erlaubt
Dokument2
- Blatt 1 - Dokument-Seite aus dem Transaktion-Formular
- LOG3 - der obligate logische Beileger aus der Schema-Version
- LOG1 - der erste optionale logische Beileger aus der Tabelle der logischen Beileger aus der Schema-Version
==> LOG2 wird weggelassen, weil dieser einen Porto-Sprung von Standard-Pist auf Kompakt-Post erzwungen hätte --> dies ist aber nicht erlaubt
Überblick
Inhalte