Dokumentenworkflow aus dem Druckdatenstrom

Der virtuelle Drucker trennt Anwendung und Ausgaberegeln

Aus Sicht der Fachanwendung verhält sich ein virtueller Drucker wie ein gewöhnliches Ausgabegerät. Der Benutzer wählt ihn aus oder die Anwendung verwendet ihn fest. Statt den Auftrag unmittelbar an Papier zu senden, nimmt ein zentraler Dienst den erzeugten Datenstrom entgegen. Typische Eingänge sind PostScript, PCL oder bereits vorbereitete PRN-Dateien.

Diese Trennung ist wertvoll, weil die Fachanwendung weiterhin ihren bekannten Beleg erzeugt, während Gestaltung und Folgeaktionen an einer zentralen Stelle gepflegt werden. Briefpapier, Logos, zusätzliche Kopien oder Zielwege müssen nicht auf jedem Arbeitsplatz einzeln eingerichtet werden. Die Trennung ist aber nur dann sicher, wenn Auftrag, Mandant und Dokumenttyp eindeutig erkannt werden.

Erkennung und Extraktion sind zwei unterschiedliche Prüfungen

Zuerst wird bestimmt, welcher Beleg vorliegt. Dafür eignen sich stabile Merkmale wie feste Kennungen, wiederkehrende Textbestandteile oder dokumentierte Layoutsignaturen. Eine bloße Seitenposition ohne Belegkontext ist riskant: Dieselbe Position kann in Rechnung, Gutschrift und Mahnung eine andere Bedeutung haben.

Erst nach der Klassifikation werden fachliche Felder extrahiert. Dabei geht es nicht nur um Text, sondern um Bedeutung und Vollständigkeit. Rechnungsnummer, Datum, Parteien, Positionen, Steuern und Summen benötigen passende Regeln. Plausibilitätsprüfungen erkennen fehlende Werte, falsche Formate und Widersprüche. Eine unbekannte Belegvariante wird angehalten, statt stillschweigend mit der nächstähnlichen Regel verarbeitet zu werden.

• Dokumenttyp und Variante eindeutig bestimmen
• Felder im Kontext der erkannten Variante lesen
• Vollständigkeit und fachliche Plausibilität prüfen
• Unbekannte Varianten in eine kontrollierte Nachbearbeitung geben

Aus einem Auftrag können mehrere abgestimmte Ergebnisse entstehen

Nach der Prüfung kann der Workflow das sichtbare Dokument gestalten, Papierkopien steuern, PDF-Dateien erzeugen, strukturierte Rechnungsdaten einbetten oder separat ausgeben und Indexdaten an ein DMS übergeben. Alle Ergebnisse sollten aus demselben verarbeiteten Auftrag hervorgehen. So bleiben sichtbarer Inhalt, XML, Kopien und Archivmetadaten fachlich verbunden.

Regeln können sich auf Dokumenttyp, Mandant, Empfänger, Betrag oder ausdrücklich gepflegte Merkmale stützen. Jede Regel braucht eine nachvollziehbare Reihenfolge und eine definierte Standardbehandlung. Besonders beim Versand ist Idempotenz wichtig: Ein wiederholter technischer Lauf darf nicht unbemerkt dieselbe Rechnung ein zweites Mal zustellen.

Status und Protokoll gehören zum Ergebnis. Der Betrieb muss erkennen können, ob ein Auftrag eingegangen, erkannt, validiert, ausgegeben, archiviert oder angehalten wurde. Ein Protokoll ersetzt keine fachliche Abnahme, macht aber den technischen Weg nachvollziehbar und unterstützt einen gezielten Wiederanlauf.

Fehlende Fachdaten können nicht aus dem Layout hergeleitet werden

Ein Druckdatenstrom enthält nur, was die Anwendung für die Ausgabe bereitstellt. Fehlt eine fachlich erforderliche Information, darf der Workflow sie nicht erraten. Ergänzungen aus gepflegten Stammdaten können sinnvoll sein, wenn Quelle, Zuständigkeit und Aktualisierung klar geregelt sind. Bei instabilen Layouts, zahlreichen Belegvarianten oder transaktionalen Rückmeldungen kann eine strukturierte Schnittstelle die bessere Architektur sein.

Vor der Umsetzung werden deshalb reale Varianten gesammelt und nach Häufigkeit sowie Risiko geordnet. Der Test umfasst Standardfälle, Sonderfälle, Fehlerfälle und Wiederholungen. Nach Layout- oder Versionsänderungen der Fachanwendung zeigt ein Regressionstest, ob Erkennung und Feldzuordnung weiterhin stimmen. So wird aus einer gelungenen Demonstration ein betreibbarer Dokumentenprozess.