Wie erzeugt man heutzutage (Massen)Druckoutput?

[delora]

Hallo zusammen,

ich arbeite als Entwickler in einem international tätigen Unternehmen, welches als Dienstleister in der Energiebranche auftritt.
Unsere Software erzeugt Druckoutput in verschiedenen Formaten, welche zum Teil der Archivierung dienen (PDF) aber auch direkt an den Kunden gehen (PCL -> Papier).
Unsere Datenbasis wird in einer Oracle-Datenbank verwaltet.

Das von uns selbst entwickelte Drucksystem ist mittlerweile in die Jahre gekommen.
Wir verwalten unterschiedliche Formulare in inhaltlich und layoutmässig unterschiedlichen Ausprägungen (da international unterschiedliche Anforderungen an den Output).

Beispiel:

Zitat:

Anschreiben zur Rechnung für Land 1
...
Anschreiben zur Rechnung für Land n

Rechnung für Land 1
...
Rechnung für Land n

Mahnschreiben für Land 1
...
Mahnschreiben für Land n

Das Ganze ist objektorientiert gelöst, so dass es für jedes Formular eine Basis mit den Hauptfunktionalitäten gibt und dann für jedes Land abgeleitet die jeweiligen Spezialanforderungen.
Die benötigten Daten werden auf Zuruf innerhalb dieser Formulare zusammengesammelt und in eine Queue gestellt.
Aus dieser werden dann nachts unterschiedliche Druckengines aufgerufen (PDF, PCL...) die die Daten dann entsprechend umsetzen und den eigentlichen Output erzeugen.
Dieses ist alles native gelöst, d.h. wir benutzen hier keine Reporting-Tools oder so, sondern wird schreiben die PCL-, Postscriptbefehle usw. selber, inkl. der kompletten Formatierungen etc.
Zu dieser Aufbereitung gehören auch weiterführende Prozesse wie bspw. der Aufruf von Webservices zur Archivierung der Daten oder das Erzeugen von Mails, die den Druckoutput als Attachment mit auf die Reise bekommen.

Das ist alles schön und gut und funktioniert, aber was das für ein Moloch ist, könnt Ihr Euch sicherlich vorstellen.
Die Integration neuer Technologien wie bspw. QR-Codes usw. sind recht aufwändig, da sie auch immer in allen Druckengines implementiert werden müssen.
Des Weiteren bedarf es zwingend eines Programmierers (was für mich nicht unbedingt zum Nachteil ist :lol:), um kleinste Anpassungen am Layout oder so vorzunehmen.

Nun ist es so, dass im Rahmen einer Umstrukturierung auch das Layout unserer Dokumente (und das sind ein paar 100) angepasst werden soll.
So eine Runde haben wir zuletzt vor etwa 13 Jahren gedreht und zu meiner Schande muss ich gestehen, dass wir mit den Auswirkungen zum Teil heute noch zu kämpfen haben.
Es ist so viel, was man in dem Bereich zu beachten hat, seien es passende Seitenumbrüche, horizontale Ausdehnung von dynamischen Elementen usw.
Dieses in der aktuellen Infrastruktur umzusetzen, sehe ich als sehr kritisch.

Somit komme ich zu meinem eigentlichen Anliegen 8-)

Ich bin nun auf der Suche nach einer Alternative, die unser aktuelles Drucksystem ablösen soll.
Und da ich mich diesbezüglich auf dem aktuellen Markt gar nicht auskenne, wende ich mich an Euch und hoffe, ein paar nette Ideen zu bekommen :)

Fakten:

• Unsere Datenbasis wird weiterhin eine Datenbank sein. Welche, soll irrelevant sein.
• Unsere Datenbasis ist SEHR (!) groß! Wir sprechen von vielen vielen Milliarden Datensätzen.
• Der Umfang der zu erzeugenden Dokumente liegt derzeit bei mehreren 100, Tendenz steigend.

Must have:

• Die Texte müssen für jedes Dokument individuell übersetzbar sein (ja, nicht nur die statischen, sondern auch die aus der Datenbank gelesenen :stupid:).
• Da die Anzahl der täglich zu erzeugenden Dokumente hoch ist, muss das System sehr performant sein. Das impliziert, dass die Lösung skalierbar sein muss.
• Ein Layout für mehrere Formate. Soll heißen, dass ich festlege, wie das Ergebnis auszusehen hat, und das System erzeugt mir darauf basierend PDF, PCL, Postscript.... whatever.
• Über den Weg, wie der Output letztendlich erzeugt wird, möchte ich mir keine Gedanken machen müssen. Ich möchte also nicht an PDF-Spezifika oder so rumschrauben (aber können - siehe Nice to haves)
• Das Ganze soll softwareseitig gesteuert werden können, so dass auch Folgeverarbeitungen (siehe oben, Webservices usw.) erfolgen können.
• Die Lösung muss aktuell weiterentwickelt werden und auch dann noch funktionieren, wenn die Entwicklung irgendwann einmal eingestellt werden sollte.
• Das Layout muss flexibel gestaltet werden und mit unterschiedlichen Grafikformaten umgehen können (für Logos usw.) (ich möchte mich nicht mehr mit PCL-Macros rumschlagen müssen :wink:)

Nice to have:

• Das Layout der Dokumente sollte auch von Nicht-Programmierern angepasst werden können, so dass die Länder in Eigenverantwortung Änderungen implementieren können. Wie sich soetwas unabhängig einer Kenntnis der zugrundeliegenden Daten allerdings realisieren lassen soll - keine Ahnung.
• Eine OpenSource-Lösung wäre natürlich schön. Nicht wegen des finanziellen Aspektes, sondern wegen der möglichen Mitgestaltung.
• Schön wäre es auch, wenn man sich um das Erzeugen des eigentlichen Outputs selber nicht kümmern muss, aber kann. Bedeutet, dass ich keine PDF-Engine programmieren, diese aber u.U. erweitern möchte, sollten benötigte Features nicht vorhanden sein.

Nicht-Anforderungen:

• Die Lösung muss nicht zwingend Delphi-basiert sein. (Java muss es aber auch nicht unbedingt sein :wink:)

Das ist erstmal das, was mir spontan so einfällt :)

Ich habe mich schoneinmal mit XSLT auseinander gesetzt, weiß aber nicht, ob dieses bei dem Umfang einsetzbar ist. Da fehlt es an Erfahrungen.

Ich freue mich über Eure Anregungen :)

[Neutral General]

Generell brauchst du Report-Generatoren. Da gibt es z.B. FastReport oder Quickreport (dann lieber Fastreport).
Aber wenn du dich in der Richtung mal umschaust wirst du sicherlich was finden.
Der Reportgenerator ist normalerweise ähnlich zu bedienen wie der Formular-Generator in Delphi.
Programmierkenntnisse sind normalerweise nicht erforderlich.

Wenn mich nicht alles täuscht gibt es bei fast allen (oder sogar alle) Report-Generatoren eine Option den Quelltext mitzukaufen. Kostet dann etwas mehr aber man kann die Engine als auch den Editor seinen wünschen anpassen. Wobei das eigentlich normalerweise nicht nötig ist.

[Sir Rufo]

Und für die Skalierbarkeit nimmt man etwas wie MSMQ, ActiveMQ, usw. und schiebt die Jobs in so eine Queue. An der Queue lauschen dann 1-n Systeme, die diese Jobs verarbeiten können.

[mjustin]

Wenn es Java sein darf:

http://www.jaspersoft.com/editions

In der Community Edition kostenlos, lizensiert unter AGPL.

Zitat:

Pixel Perfect Report Designer
Create very sophisticated Business Intelligence report layouts containing charts, images, subreports, crosstabs and much more with Jaspersoft Studio.

Zitat:

Reporting Engine
Java based reporting library uses data from any data source to compile and render pixel-perfect documents that can be viewed, printed, or exported in a variety of formats including HTML, PDF, Excel, OpenOffice and Word.

[Neutral General]

Zitat:

Zitat von mjustin (Beitrag 1342164)

Wenn es Java sein darf:

Ich gehe mal nicht davon aus, dass sie ihre Software nur deswegen komplett in Java neu schreiben wollen....

[mjustin]

Zitat:

Zitat von Neutral General (Beitrag 1342166)

Zitat:

Zitat von mjustin (Beitrag 1342164)

Wenn es Java sein darf:

Ich gehe mal nicht davon aus, dass sie ihre Software nur deswegen komplett in Java neu schreiben wollen....

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Wenn man unbedingt zur Laufzeit des Reports noch eigene Delphi-Funktionen aufrufen will, sollte man dies zuerst noch mal überdenken.

[Neutral General]

Zitat:

Zitat von mjustin (Beitrag 1342169)

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

[mjustin]

Zitat:

Zitat von Neutral General (Beitrag 1342170)

Zitat:

Zitat von mjustin (Beitrag 1342169)

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

Wenn die zu druckenden Daten - so wie im Posting beschrieben - erst in eine Queue gestellt werden, und dann daraus nachts verschiedene Druckengines die Ausdrucke erzeugen, kann das Austauschen der Druckengine schon eine Lösung sein. In der Queue stehen Daten, die von der Druckengine verarbeitet werden müssen. Da ist nichts Delphi-spezifisch.

[ernschd]

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

[Sir Rufo]

Zitat:

Zitat von ernschd (Beitrag 1342178)

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

Wieso PCL-Dokumente? Das Umsetzen in PCL sollte der Druckertreiber erledigen.

Und mit FastReport erzeugt man auch (direkt) keine PDF-Dokumente (es sei denn man ist sehr leidensfähig oder es ist einem egal, was da raus kommt).

[ernschd]

Habe ich so verstanden:

Zitat:

Must have:
...
Ein Layout für mehrere Formate. Soll heißen, dass ich festlege, wie das Ergebnis auszusehen hat, und das System erzeugt mir darauf basierend PDF, PCL, Postscript....

Wir drucken z.B. bei uns im Unternehmen die PCL-Dokumente ohne den Druckertreiber. Die Datei wird direkt auf den PCL-fähigen Drucker kopiert, und er legt von sich aus los.

[Sir Rufo]

Das habe ich auch gelesen, nur würde ich mich mit so etwas nie rumschlagen wollen (es müsste schon ein sehr ernster Grund vorliegen um mich zu überzeugen).

Da es solche Umsetzer schon gibt (Druckertreiber) bin ich dagegen das Rad neu zu erfinden.

[p80286]

Eine Alternative zu einem Reportgenerator, wäre u.U MS Office/open Office
Im Extremfall, können diese Dokumente/Vorlagen sich die notwendigen Daten von einer DB abholen, sich selbst erzeugen und auch ausdrucken. Rein theoretisch sollte jeder fortgeschrittene Anwender in der Lage sein, entsprechende Vorlagen zu erstellen.
Ich würde allerdings empfehlen die Dokumentengenerierung und DB-Abfrage über ein eigenes Programm abzuwickeln, was zumindest der Performance zuträglich wäre.

Gruß
K-H

[sh17]

also bei einigen "must have" würde ich eher vorschlagen, das Gehirnschmalz in einen eigenen neuen Generator zu stecken, als mir eine fertige Blackbox ans Bein zu binden.

[delora]

Hallo zusammen und ersteinmal vielen Dank für Eure Rückmeldungen :)

Das mit den PCL-Files wird bei uns ähnlich gehandhabt, wie bei ernschd.
Die PCL-Files werden bei uns native erzeugt; nicht über einen Druckertreiber, sondern durch Schreiben der Escape-Sequenzen...
Anschließend werden sie an einen Dienstleister geschickt, der den Papier-Output erzeugt.
So sparen wir uns eine große Druckstraße.
Die Archivierung der PDFs läuft bei uns intern.

Ob man bei einer Novellierung des Ganzen immer noch auf PCL setzt, würde ich jetzt in Frage stellen. 8-)
Das ist bei uns einfach historisch gewachsen und dieses Format haben wir halt immer mitgeschleppt, obwohl wir teilweise ganz schöne Kapriolen schlagen mussten, um irgendwelche Sachen zu integrieren.

Zitat:

Zitat von sh17 (Beitrag 1342204)

also bei einigen "must have" würde ich eher vorschlagen, das Gehirnschmalz in einen eigenen neuen Generator zu stecken, als mir eine fertige Blackbox ans Bein zu binden.

Theoretisch würde ich das auch gerne machen.
Leider haben wir nicht die Zeit, um uns über diese grundlegenden Sachen zukünftig Gedanken zu machen. Wenn Du ein Feature implementierst, dann implementierst Du es in x Druckengines.
Und dann musst Du es auch noch nahezu deckungsgleich hinbekommen. Das ist kein Vergnügen :pale:
Das ist ja der ausschlaggebende Grund, nach Alternativen zu suchen :(

Zitat:

Zitat von p80286 (Beitrag 1342198)

Eine Alternative zu einem Reportgenerator, wäre u.U MS Office/open Office

Hmm, das hört sich irgendwie komisch an. Ich weiß nicht. Ich fürchte, dass wir damit irgendwie schnell an unsere Grenzen stoßen werden. Ist nur so ein Gefühl :?

Ansonsten stehen Reportgeneratoren zur Debatte, an die ich auch am Anfang nachdachte.

Was haltet Ihr denn generell von XSL speziell XSL-FO?
Hat damit jemand Erfahrungen?
Oder ist das zu unflexibel? Zu inperformant?

Über weitere Tipps bin ich sehr dankbar :)

[mjustin]

Zitat:

Zitat von delora (Beitrag 1342206)

Was haltet Ihr denn generell von XSL speziell XSL-FO?
Hat damit jemand Erfahrungen?

In c't und i'x gab es zum Thema Drucken per XSL-FO einige Artikel aus der Praxis.

Über die Archiv-Suche sind sie noch zu finden: https://shop.heise.de/archiv/search/result?query=xsl-fo

zum Beispiel

XML hübsch gedruckt - XSL Formatting Objects schlagen die Brücke von XML zu PDF

Der saubere Weg - Herstellerunabhängiges Reporting mit XSL und Co.

[mm1256]

Zitat:

Zitat von delora (Beitrag 1342206)

Über weitere Tipps bin ich sehr dankbar :)

Hast du dir schon mal List&Label angesehen? Deutsches Produkt (Konstanz), kann - so wie ich es beurteilen kann - alles was du brauchst. Quellcode gibt's allerdings nicht. Aber, es ist das leistungsfähigste, flexibelste und schnellste Reporting-Tool das ich kenne. Wir setzen es roundabout 15 Jahre lang ein und hatten bisher auch keine nennenswerten Probleme. Und wenn's mal klemmt, gibt's eine gut erreichbare Hotline. :thumb:

[p80286]

Zitat:

Zitat von delora (Beitrag 1342206)

Zitat:

Zitat von p80286 (Beitrag 1342198)

Eine Alternative zu einem Reportgenerator, wäre u.U MS Office/open Office

Hmm, das hört sich irgendwie komisch an. Ich weiß nicht. Ich fürchte, dass wir damit irgendwie schnell an unsere Grenzen stoßen werden. Ist nur so ein Gefühl :?

Das mag sein. Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Und das selber bauen von PCL, Postscript und was für Druckerbefehlssprachen noch - Files, ist vollkommen unnötig und viel zu Fehlerträchtig. Für so etwas gibt es Druckertreiber!

Gruß
K-H

[Neutral General]

Zitat:

Zitat von p80286 (Beitrag 1342230)

Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Das halte ich für ein Gerücht.

[Sir Rufo]

Wenn man mehrere Sprachen unterstützen will, dann legt man sich pro Sprache ein Template an. Das wird dann durch die Engine mit den Daten gefüllt und fertig.

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1342233)

Zitat:

Zitat von p80286 (Beitrag 1342230)

Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Das halte ich für ein Gerücht.

Leidvolle Erfahrung (Stand vor drei Jahren)

Gruß
K-H

[Neutral General]

Zitat:

Zitat von p80286 (Beitrag 1342237)

Leidvolle Erfahrung (Stand vor drei Jahren)

Also es geht (zumindest mit den Reportgeneratoren mit denen ich bisher gearbeitet habe) definitiv.
Je nachdem welchem Generator man benutzt und was man genau will kann es schonmal etwas umständlich werden,
aber es müsste auf jeden Fall gehn.

[delora]

Zitat:

Zitat von mjustin (Beitrag 1342209)

In c't und i'x gab es zum Thema Drucken per XSL-FO einige Artikel aus der Praxis.

Danke für den Hinweis, werde ich mir mal anschauen :)
Von Euch hat damit niemand Erfahrungen?

Zitat:

Zitat von mm1256 (Beitrag 1342211)

Hast du dir schon mal List&Label angesehen?

Nein, das kenne ich noch nicht :) Werde ich mir mal ansehen. Vielen Dank!

Zitat:

Zitat von p80286 (Beitrag 1342230)

Zitat:

Zitat von delora (Beitrag 1342206)

Zitat:

Zitat von p80286 (Beitrag 1342198)

Eine Alternative zu einem Reportgenerator, wäre u.U MS Office/open Office

Hmm, das hört sich irgendwie komisch an. Ich weiß nicht. Ich fürchte, dass wir damit irgendwie schnell an unsere Grenzen stoßen werden. Ist nur so ein Gefühl :?

Das mag sein. Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Genau diese Aussage hätte ich jetzt eher hinsichtlich MS-Office gesehen :shock:

Zitat:

Zitat von p80286 (Beitrag 1342230)

Und das selber bauen von PCL, Postscript und was für Druckerbefehlssprachen noch - Files, ist vollkommen unnötig und viel zu Fehlerträchtig. Für so etwas gibt es Druckertreiber!

Das kann man so nicht sagen. Wie gesagt, das Ganze ist gewachsen und funktioniert seit 20 Jahren ganz gut ;)
Vor allem ist es rasend schnell :)

Des Weiteren muss man, um einen Druckertreiber bemühen zu können, ein fertiges Layout haben, das dieser auch verarbeiten kann.
Und das haben wir ja eben nicht.
Und wie ich schons sagte, möchten wir uns ja von dieser Technik auch verabschieden.

Zitat:

Zitat von Sir Rufo (Beitrag 1342236)

Wenn man mehrere Sprachen unterstützen will, dann legt man sich pro Sprache ein Template an. Das wird dann durch die Engine mit den Daten gefüllt und fertig.

Es handelt sich hier nicht nur um statische Texte, sondern hauptsächlich um dynamische, die aus der Datenbank kommen.
Da ist nix mit Template ;) Diese Texte müssen zur Laufzeit übersetzt werden (also der übersetzte Text muss zur Laufzeit anstelle des Originaltextes aus der DB geladen werden).

Zitat:

Zitat von p80286 (Beitrag 1342237)

Zitat:

Zitat von Neutral General (Beitrag 1342233)

Zitat:

Zitat von p80286 (Beitrag 1342230)

Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Das halte ich für ein Gerücht.

Leidvolle Erfahrung (Stand vor drei Jahren)

Verrätst Du mir, welchen Reportgenerator Du da benutzt hast?

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1342236)

Wenn man mehrere Sprachen unterstützen will, dann legt man sich pro Sprache ein Template an. Das wird dann durch die Engine mit den Daten gefüllt und fertig.

Schlecht formuliert:oops: , es geht um landesspezifische Besonderheiten (welche Unterlagen werden benötigt), und nicht um einen englischen, italienischen .. Brief.

Gruß
K-H

[Neutral General]

Man kann ja abhängig von einer Bedingung auch unterschiedliche Bänder ein- und ausblenden.
Damit sollte sowas ja auch machbar sein. Ist wie schon angedeutet evtl. etwas umständlich, aber sollte eigentlich gehn.

[p80286]

Zitat:

Zitat von delora (Beitrag 1342241)

Verrätst Du mir, welchen Reportgenerator Du da benutzt hast?

Da muß ich leider passen, es ging um eine Verwaltungssoftware für unsere Akten, und nachdem unsere (Brief-)Anforderungen nicht befriedigt werden konnten, hab ich es ganz schnell wieder vergessen.

Gruß
K-H

[p80286]

Zitat:

Zitat von delora (Beitrag 1342241)

Da ist nix mit Template ;) Diese Texte müssen zur Laufzeit übersetzt werden (also der übersetzte Text muss zur Laufzeit anstelle des Originaltextes aus der DB geladen werden).

Ein gutes Template kann damit umgehen!
(Ist allerdings nicht ganz so einfach wie die Werbung uns das glauben machen will)

Gruß
K-H

[delora]

Achso, nur um das nochmal klar zu machen:

Bei unseren Dokumenten handelt es sich nicht einfach nur um Templates, in denen ein paar Platzhalter ersetzt werden müssen.
Das mag jetzt geschwollen klingen, aber leider ist es so.
Wie ich schon sagte, bin ich in der Energiebranche tätig, genauer gesagt geht es um Abrechnungen/Rechnungen im Bereich Heizkosten.
Da wir international tätig sind, gibt es so viele verschiedene gesetzliche Grundlagen und Anforderungen, die bei der Berechnung berücksichtigt werden müssen; das ist echt kompliziert :?
Und dieser Umfang spiegelt sich auch im Druck wieder. Da gibt es so viele Sonderlocken die es zu berücksichtigen gibt. Alleine das Zusammensammeln der Daten sowie die Positionierung (ohne das Erzeugen des eigentlichen Zieloutputs) hat bei dem umfangreichsten Dokument (nur eins!) schon knapp 10 Tausend Zeilen Code (inkl. Kommentarzeilen natürlich))
Und da bin ich mittlerweile echt unsicher, ob ein proprietäres Produkt soetwas leisten kann :(
Ist halt keine WISO-Steuersoftware :twisted:

Ihr habt mir auf jeden Fall viele gute Ansätze geliefert, von denen ich einige Weiterverfolgen werde.
Und vielleicht meldet sich ja jetzt jemand und sagt 'Hey, das ist bei uns genau so und wir machen das so und so' *träum* ;)

Ist halt sehr schwer, zu evaluieren, ob eine Lösung für einen das Richtige ist. Wenn man da über Wochen in die falsche Richtung entwickelt...

[Lemmy]

Zitat:

Zitat von p80286 (Beitrag 1342237)

Zitat:

Zitat von Neutral General (Beitrag 1342233)

Zitat:

Zitat von p80286 (Beitrag 1342230)

Für ein
'Sehr geehrter #Anrede# #Name# hiermit kündigen wir zum nächsten 1.'
ist ein Reportgenerator bestimmt gut zu gebrauchen. Wenn allerdings noch ein (paar) Logos dazu kommen und abhängig von der #Sprache# sich auch Teile des Briefes ändern sollen, dann ist/war so mancher Reportgenerator überfordert.

Das halte ich für ein Gerücht.

Leidvolle Erfahrung (Stand vor drei Jahren)

ich habe 2005 für ein Telekommunikationsunternehmen eine Abrechnungssoftware fertig gemacht, die Rechnungen wurden mit FastReport 3 erzeugt, incl. Steuerung einer Kouvertiermaschine (so Geschichten wie Flyer mit beilegen wenn weniger als 2 Blätter um Porto zu sparen; Druck von Werbung auf die Rechnung wenn noch genug Platz auf der letzten Seite ist,....)
Alles kein Thema mit einem vernünftigen Reporter. Und gerade was dynamische Reports anbelangt (die aus unterschiedlichen Templates zusammen gesetzt werden) ist das auch kein großes Thema.

Um MS Office/LibreOffice würde ich einen Bogen machen: die Steuerung müsste zwangsläufig über OLE/COM erfolgen, was leider fehlerträchtig geworden ist vor allem weil bei so Sachen auch gerne mal Virenscanner unerwartet zuschlagen...

Und wenn das ganze von einem "normalen" Anwender geändert werden sollte, scheidet im Grunde alles aus, was keinen grafischen Editor hat, weil es sonst ganz bitter wird und am Ende wieder "nur" der Entwickler Änderungen machen kann.

[Neutral General]

Delora schau dir mal FastReport oder auch List&Label (wobei ich persönlich noch nicht mit List&Label gearbeitet habe) an.
Das wird viele Fragen besser beantworten als irgendwelche Erfahrungen/Beispiele von hier.

Bin mir zu 99% sicher dass FastReport oder List&Label genau das ist was du brauchst.
Je nachdem wie Komplex gewisse Dinge sind muss man für gewisse Sachen eben unterschiedliche Reporte erstellen.
Im Zweifelsfall pro Land einen Report (Rechnung_de.fr3, Rechnung_fr.fr3, Rechnung_us.fr3, ...).

Und wie gesagt: Du musst nur 1x die Reportengine im Code initialisieren und dann die benötigten Daten an den entsprechenden Report weitergeben und fertig.
Das erstellen der Reporte geht wie gesagt komplett ohne Programmierkenntnisse. Es sei denn du möchtest irgendwelche interaktiven Sachen drin haben vielleicht.
(D.h. der Report soll nicht (direkt) ausgedruckt werden sondern der Benutzer kann noch mit dem Report interagieren und der Report ist mehr eine GUI mit Funktionalität als ein reiner Ausdruck - aber das scheint ja eh nicht das zu sein was du brauchst - von daher sind keine Programmierkenntnisse erforderlich).

[Sir Rufo]

Zitat:

Zitat von delora (Beitrag 1342241)

Zitat:

Zitat von Sir Rufo (Beitrag 1342236)

Wenn man mehrere Sprachen unterstützen will, dann legt man sich pro Sprache ein Template an. Das wird dann durch die Engine mit den Daten gefüllt und fertig.

Es handelt sich hier nicht nur um statische Texte, sondern hauptsächlich um dynamische, die aus der Datenbank kommen.
Da ist nix mit Template ;) Diese Texte müssen zur Laufzeit übersetzt werden (also der übersetzte Text muss zur Laufzeit anstelle des Originaltextes aus der DB geladen werden).

Die statischen Texte gehören ins Template, die dynamischen sind Teil der Daten und für die Beschaffung sollte das Template nicht verantwortlich sein. Wenn die Engine die Daten mit dem Template zusammenfügt, dann muss alles soweit bereit sein, dass wirklich nur noch zusammengefügt werden muss.

Das Übersetzen der dynamischen Texte erfolgt also mindestens ein Schritt vorher.

[p80286]

Zitat:

Zitat von Lemmy (Beitrag 1342254)

Um MS Office/LibreOffice würde ich einen Bogen machen: die Steuerung müsste zwangsläufig über OLE/COM erfolgen, was leider fehlerträchtig geworden ist vor allem weil bei so Sachen auch gerne mal Virenscanner unerwartet zuschlagen...

hast Du dafür Beispiele? bei uns funktioniert das eigentlich ganz gut, da gibt es keinen Ärger mit Virenscannern.

Zitat:

Zitat von Lemmy (Beitrag 1342254)

Und wenn das ganze von einem "normalen" Anwender geändert werden sollte, scheidet im Grunde alles aus, was keinen grafischen Editor hat, weil es sonst ganz bitter wird und am Ende wieder "nur" der Entwickler Änderungen machen kann.

der "normale" oder auch der "fortgeschrittene" Anwender, sind ja sehr relative Einordnungen.
Die Erfahrung lehrt leider daß Du Recht hast.

@Delora
Ich werde das Gefühl nicht los, daß Ihr vieles so macht wie Ihr es macht, weil Ihr es schon immer so gemacht habt. Vielleicht wäre es jetzt sinnvoll, falls machbar, sich zu überlegen wie man es machen würde wenn man keine Altlasten hätte. Das kostet nur etwas Zeit und etwas Papier.

Gruß
K-H

[sh17]

XSL-FO ist definitiv ein Blick Wert. Mittels der FO-Prozessoren können auch jede Menge Ausgabe-Varianten erzeugt werden. Würde ich Report.XY auf jeden Fall vorziehen. Zumindest war das mein Eindruck. Am Ende haben wir unsere Druck-Engine doch nochmal umgeschrieben. Aber wenn wieder die Entscheidung ansteht, ist XSL-FO wieder im Boot.

[hoika]

Hallo,
ich werfe mal QuickPDF in die Runde.

Hier kommt es aber auf die Komplexität der Dokumente an.

Bei List&Label hatte mir daals missfallen (Version 6-10 ...),
dass das alles sehr statisch war.
Mittlereise kan man das Teil aber auch komplett dynamisch benutzen.

Im Vergleich zu Crystal Reports war L&L ein Traum.


Heiko

[mm1256]

Zitat:

Zitat von hoika (Beitrag 1342269)

...Bei List&Label hatte mir damals missfallen (Version 6-10 ...),
dass das alles sehr statisch war.
Mittlereise kan man das Teil aber auch komplett dynamisch benutzen.

Im Vergleich zu Crystal Reports war L&L ein Traum.

Heiko

Ich benutze L&L seit Version 4. Mittlerweile sind wir bei Version 21. Das kann man mit den Versionen VOR Version 12 nicht mehr vergleichen. Ab Version 16 gab es dann neben den üblichen Erweiterungen dank Einsatz von Multithreading einen Performance-Schub um ca. 80%.

Was die Steuerung des Ausdrucks (und die vorher gegangene Diskussion um Templates) anbelangt. Man kann die Druckausgabe entweder automatisiert über die Datenbank (TDataSet) ablaufen lassen, oder den Ausdruck selber manuell Datensatz für Datensatz erledigen. Diese Flexibilität ist auch mir wichtig, weil beim Ausdruck manchmal (also nicht immer) Daten erst während des Ausdruckes zusammengestellt werden müssen. Beispielsweise beim Druck eines Lieferscheines oder einer Rechnung die dazugehörigen Seriennummern, das Aufmaß, oder bei Leistungspositionen die Zuordnungen.

Der grafische Formulardesigner (mit echtem Preview, also ganz anders als z.B. bei FastReport) wird mitgeliefert. Jeder der sich damit beschäftigt (auch neugierige Kunden) kann den bedienen. Man kann ihn aber auch sperren, was ich über die Benutzerverwaltung wahlweise mache.

[delora]

Hallo zusammen,

ich denke, dass ich mir den List&Label mal ansehe. Die Infos auf der Homepage sind ja ganz ansprechend. Und eine 30 Tage Testversion gibt es auch (obwohl ich in dem Zeitrahmen wahrscheinlich nicht so viel reißen kann :lol:)
Und wenn das nichts ist, werde ich mir mein XSL-FO Buch nochmal herholen.

Zitat:

Zitat von p80286 (Beitrag 1342264)

@Delora
Ich werde das Gefühl nicht los, daß Ihr vieles so macht wie Ihr es macht, weil Ihr es schon immer so gemacht habt. Vielleicht wäre es jetzt sinnvoll, falls machbar, sich zu überlegen wie man es machen würde wenn man keine Altlasten hätte. Das kostet nur etwas Zeit und etwas Papier.

Da hast Du vollkommen recht - ich habe das auch so gesagt, dass das Ganze gewachsen ist, wir uns aber davon trennen möchten - daher bin ich hier ;)

Nochmals vielen Dank für Eure Ideen!

[juergen]

@hoika,
der TE spricht von Milliarden Datensätzen, da sollte Geld keine Rolle spielen und die Entscheidung IMHO für die größten Hersteller in diesem Bereich gefällt werden (SAP (Crystal Report) usw.).
Wir nutzen (noch) Crystal Report, mich würde mal die Aussage interessieren, was an L&L besser ist wie bei Crystal Report. Das hört sich interessant an! Ich hatte vor längerer Zeit auch mal L&L getestet, konnte damals (Version 14?) keine so großen Vorteile erkennen um CR zu ersetzen.

Zitat:

Zitat von hoika (Beitrag 1342269)

Im Vergleich zu Crystal Reports war L&L ein Traum.Heiko

[mjustin]

Anstelle Template zu verwenden die manuell erstellt sind, könnte man versuchen das gesamte Layout dynamisch zu erzeugen. Das geht bei einigen mir bekannten Reportgeneratoren entweder indem man die Reportdefinitionsdatei per Code erzeugt, oder über ein Layout-API.
Dann würde man nur noch ein Programm benötigen, das über diese API die gewünschten Variationen der Reportlayouts erzeugt.

Mit diesem Programm würde man den Report dann aus Bausteinen zusammensetzen, die speziell dem geschäftlichen Feld angepasst sind.

Das Zusammenbauen kann hart kodiert im Code ablaufen:

Code:

Quartalsabrechnung := TQAbrechnung.Create;
Quartalsabrechnung.AddInfoBlock(...);
Quartalsabrechnung.AddWerbungsBlock(...);
QuartalsabrechnungLayout := Quartalsabrechnung.ErstelleLayout;
LayoutRepository.AddLayout(REPORT_QA, QuartalsabrechnungLayout);

An das generierte Layout werden dann alle Datensätze übergeben.

Code:

ReportGenerator := TRG.Create;
ReportGenerator.Layout := LayoutRepository.LoadLayout(REPORT_QA);
ReportGenerator.LoadDataSet(...);
ReportGenerator.CreateReport;
...

Manuelle Nachbearbeitung der generierten Layouts sollte dann nicht mehr stattfinden.


p.s. Auf jeden Fall würde ich vermeiden, zur Laufzeit des Reportgenerators noch Code mit Datenbankzugriff auszuführen. Eine Funktion, die innerhalb des Ausdrucks noch Lookupfelder in der Datenbank nachschlägt wäre ein No-Go. Für die saubere Trennung wäre es zum Beispiel möglich, die Daten als XML Dokument bereitzustellen.

[Valle]

Hi,

ich weiß nicht ob ich hier etwas sinnvolles zu beitragen kann, aber bevor ich es verschweige, teile ich mal unsere Lösung mit.

Ich bin in der Webentwicklung bei einem Reiseunternehmen tätig, wo wir natürlich auch einige Dokumente wie beispielsweise Rechnungen drucken müssen.

Wir verwenden Python im Backend. Mit unserem Python Framework benutzen wir auch eine Templating Engine für Python. Mit dieser können wir nicht nur HTML generieren, sondern auch LaTeX Dateien. Mit Schleifen und If-Abfragen sind wir so recht mächtig in der Generierung der LaTeX-Quelldateien. Mittels selbst definierten Dokumenttypen und LaTeX-Befehlen ist das Generieren daher auch recht einfach.

Änderungen an den Templates waren oft schwierig, meist aber nur, weil das System über seine ursprünglichen Grenzen gewachsen ist und wir keinen LaTeX-Profi im Team haben. Bei einer eventuellen Neuentwicklung würde ich den Weg über LaTeX allerdings erneut gehen. Diesmal mit mehr Augenmerk auf Modularität, Unicode (!!!) und einfacheres Debugging.

LaTeX Generierung ist nach meinem Empfinden alles andere als rasend schnell. Ich weiß aber auch nicht von welchen Maßstäben wir reden. Weiterhin umfasst unser Volumen nur wenige Dokumente pro Tag. Allerdings lässt sich diese Technik denke ich problemlos vertikal und horizontal skalieren.

[mm1256]

Zitat:

Zitat von juergen (Beitrag 1342276)

@hoika,
der TE spricht von Milliarden Datensätzen, da sollte Geld keine Rolle spielen und die Entscheidung IMHO für die größten Hersteller in diesem Bereich gefällt werden (SAP (Crystal Report) usw.).
Wir nutzen (noch) Crystal Report, mich würde mal die Aussage interessieren, was an L&L besser ist wie bei Crystal Report. Das hört sich interessant an! Ich hatte vor längerer Zeit auch mal L&L getestet, konnte damals (Version 14?) keine so großen Vorteile erkennen um CR zu ersetzen.

Zitat:

Zitat von hoika (Beitrag 1342269)

Im Vergleich zu Crystal Reports war L&L ein Traum.Heiko

Das Problem ist ja, wenn man sich mal auf eine Lösung eingeschossen hat, ist ein Wechsel sehr zeitaufwändig. Nicht nur wegen der Programmierung, sondern auch wegen der Neugestaltung der Formulare bei den Kunden. Und darum ist man natürlich erst mal skeptisch. Das ist normal.

Unsere erste Lösung war damals auch CR. Ist schon eine ganze Weile her (wie schon gesagt, seit L&L Version 4) und mit Sicherheit kein Vergleich mehr mit heutigem Stand. Was mich damals letztendlich überzeugt und den Ausschlag für den Wechsel gegeben hat, war die Performance und die Flexibilität. Wenn ich will, kann ich den kompletten Ausdruck mit einer eigenen Druckschleife generieren. Ich muss dann zwar alle Variablen und Felder selber erzeugen. Das ist die Grundlage für die Flexibilität, aber, ein einmaliger Programmier-Vorgang. Ich habe Druckschleifen die laufen schon jahrelang ohne jegliche Änderung, denn wenn der Kunde etwas ändern/ergänzen möchte, neue Berechnungen braucht usw. dann passiert das alles im Formular-Designer.

Ein Nachteil von L&L könnte sein, dass man roundabout 20 Dateien (dll's) mitliefern muss. Bisher hatte ich aber damit kein Problem.