Hallo,
wir evaluieren derzeit die Umstellung unseres bestehenden, eigenentwickelten Berichtssystems auf List & Label. Um eine fundierte Entscheidung treffen zu können, müssen wir sicherstellen, dass ein für uns absolut zentrales Funktionsprinzip unseres Altsystems in List & Label abbildbar ist.
Damit Sie unsere Anforderung präzise einordnen können, beschreiben wir nachfolgend, wie unser aktueller Berichtsgenerator fundamental arbeitet.
1. Ausgangssituation – Unser aktuelles System
Unser System (textbasiert, feste Schriftart) trennt die Berichtsdefinition strikt von der Berichtssteuerung. Es besteht im Wesentlichen aus drei Komponenten:
-
Die Berichtsvorlage (.RPT-Datei): Diese Datei ist eine reine Bibliothek von Layout-Blöcken. Sie enthält keine komplexe Steuerlogik, sondern definiert lediglich eine Sammlung von adressierbaren Blöcken (z.B. SEITENKOPF:1, DETAIL:5, DETAIL:7, LEER:23, LEER:25 usw.). Jeder Block ist ein Textbaustein mit Platzhaltern.
-
Die Datenquellen (.TXT-Dateien): Separate Textdateien, die die Rohdaten enthalten (z.B. 000 für Kopfdaten, 001 für Positionsdaten).
-
Die Steuerdatei (.PRG-Datei): Dies ist die eigentliche Steuerung. Sie wird zur Laufzeit komplett von unserem übergeordneten Programm (ISEntial) erzeugt.
2. Das zentrale Funktionsprinzip: Die “Steuerdatei”
Der Kern unserer heutigen Flexibilität – und damit der Kern unserer Frage – liegt in dieser Steuerdatei (.PRG-Datei).
Diese Steuerdatei ist im Grunde ein Skript bzw. eine detaillierte Befehlsliste für den Reporter. Unser Programm durchläuft die Geschäftslogik (z.B. die Auftragspositionen) und schreibt für jeden einzelnen Ausgabeschritt einen Befehl in diese Steuerdatei.
Jede Zeile der Steuerdatei ist ein Kommando, das dem Reporter sagt: “Nimm den nächsten Datensatz aus Datenquelle X und gib ihn mit Block Y aus der RPT-Datei aus.”
Beispielhafter Ablauf beim Erzeugen einer Auftragsbestätigung:
-
Unser Programm verarbeitet Position 1 (Typ ‘Artikel’). Es schreibt den Befehl 001 DETAIL:5 in die Steuerdatei (DataSource 001, Block DETAIL:5).
-
Unser Programm stellt fest, dass zu dieser Position eine Seriennummer gehört. Es schreibt sofort danach den Befehl 001 DETAIL:7 in die Steuerdatei.
-
Unser Programm sieht, dass ein Lieferdatum nötig ist. Es schreibt den Befehl 001 LEER:29 in die Steuerdatei.
-
Unser Programm verarbeitet Position 2 (Typ ‘Textzeile’). Es schreibt den Befehl 001 DETAIL:1 in die Steuerdatei.
-
Unser Programm entscheidet, dass nach Position 2 eine Zwischensumme fällig ist. Es schreibt den Befehl 007 LEER:25 in die Steuerdatei (DataSource 007 enthält die Summen).
Kurz gesagt: Die Berichtsvorlage (.RPT) ist nur ein “Set an Druckbausteinen”. Unser Hauptprogramm assembliert den Bericht zur Laufzeit, indem es eine Steuerdatei mit einer exakten Abfolge von Druckbefehlen erstellt. Wir können jeden Block zu jedem Zeitpunkt gezielt ansteuern und drucken, völlig “unmotiviert” von Datenbedingungen, sondern rein programmgesteuert.
3. Unsere Fragen an List & Label
Ist es in List & Label möglich, einen Bericht auf eine ähnliche, programmgesteuerte Weise zu “assemblieren”?
Können wir List & Label quasi als “Druck-Bibliothek” verwenden, bei der unsere Anwendung die Reihenfolge und Auswahl der zu druckenden Blöcke (Teilvorlagen, Tabellenzeilen, o.ä.) zur Laufzeit dynamisch vorgibt?
Konkret:
-
Gibt es einen Modus, in dem nicht eine Haupt-Datenquelle an den Bericht gebunden wird und LL die Schleife fährt, sondern unsere Anwendung die Schleife fährt und LL gezielt “PrintBlock(X)”-Befehle sendet?
-
Wie wäre das empfohlene Vorgehen? Welche Design-Muster oder Architektur (z.B. Einsatz von Teilvorlagen, Berichts-Containern, Ereignissen) würden Sie vorschlagen, um dieses Maß an externer Steuerung zu erreichen?
-
Wie können wir dabei Blöcke verwenden, die – wie unsere heutigen DETAIL:x- und LEER:x-Blöcke – selbst Felder aus unterschiedlichen Datenquellen (z.B. ‘Kopfdaten’, ‘Positionsdaten’, ‘Summendaten’) enthalten?
4. Ziel
Wir möchten verstehen, wie wir diese für uns essenzielle, programmgesteuerte Flexibilität in List & Label abbilden können, bevor wir mit einer technischen Umsetzung beginnen.
Vielen Dank im Voraus für Ihre Unterstützung und Ihre Einschätzung.
Gerne stellen wir bei Bedarf weitere Informationen oder Beispieldateien bereit.
Mit freundlichen Grüßen
René Ketterer