ELDA-Bridge 1.4.0

Das Wichtigste in Kürze

• Krankenstandsbescheinigungen und Clearingmeldungen werden als übersichtliches A4-Dokument in deutscher Sprache gedruckt und als PDF abgelegt – statt als schwer lesbarer Rohtext.
• Gedruckt wird erst, nachdem WinLohn den Sendestempel geschrieben hat.
• Für bereits empfangene Rückmeldungen erstellt rebuild-print-ready die lesbare Fassung nachträglich.

Zwei Arten von Rückmeldungen, die ELDA an Dienstgeber zustellt, waren für die Menschen, die damit arbeiten müssen, nicht lesbar. Eine Krankenstandsbescheinigung kommt als Folge von Datensätzen fester Länge (je 550 Zeichen), eine Clearingmeldung als XML-Datei, deren eigentliche Nachricht Base64-kodiert darin steckt. Ausgedruckt lief ein Datensatz der Krankenstandsbescheinigung über den Seitenrand hinaus, und eine Clearingmeldung kam als Programmcode aufs Papier; die PDF-Kopie im Ordner print-ready brach denselben Rohtext nur nach 96 Zeichen um.

Ab dieser Version werden beide als übersichtliches A4-Dokument in deutscher Sprache ausgegeben — auf Papier und als PDF gleich —, aufgebaut nach der Organisationsbeschreibung Datenaustausch mit Dienstgebern (42. Ergänzung, 07/2026), Kapitel E.25 und J.1. Für Rückmeldungen, die bereits in den Ordnern liegen, erstellt der neue Befehl rebuild-print-ready die lesbare Fassung einmalig nachträglich.

Außerdem enthält diese Version die Übergabe des Sendestempels an WinLohn, die seit v1.3.0 hinzugekommen ist: eine Quittungsdatei, die das Lohnprogramm lesen kann, der Druck nach dem Sendestempel und eine geschützte Quittung.

Was der Bediener liest

Krankenstandsbescheinigung — eine Seite je Bescheinigung, damit jede beim betroffenen Dienstnehmer abgelegt werden kann: die versicherte Person (Name mit Titeln, Versicherungsnummer wie auf der e-card, Anschrift), der Dienstgeber, die Arbeitsunfähigkeit (Beginn; Ende oder „noch nicht gemeldet“; Grund; gegebenenfalls Fortsetzungserkrankung und AF-Melder), die Krankengeldzeiträume als Tabelle mit Beträgen in Euro sowie der zuständige Versicherungsträger mit Ansprechpartner. Eine Bescheinigung mit mehr als drei Krankengeldzeiträumen kommt in mehreren Sätzen und wird zu einer Seite zusammengeführt. Testdaten und Stornos tragen einen dunklen Balken, der nicht zu übersehen ist.

Clearingmeldung — ein Abschnitt je Clearingfall: Zustellungsgrund (neuer Clearingfall, Erinnerung, obsolet), Dringlichkeit, Versicherungsträger, Beitragskontonummer, Referenzwert, die versicherte Person (oder „kein Bezug zu einer versicherten Person“), die betroffene Meldung und Satzart, der Beitragszeitraum und das Ergebnis der Prüfung — mit dem erklärenden Text des Versicherungsträgers als Fließtext und den zugehörigen Angaben in einer kleinen Tabelle. Dieser Text steckte bisher unlesbar im Base64-Block.

Jede Seite nennt in der Fußzeile die Originaldatei: maßgeblich bleibt die empfangene Datei. Die Lesefassung beschriftet und formatiert nur, was in der Datei steht — sie rechnet nichts aus, deutet nichts, und ein unbekannter Code erscheint so, wie er empfangen wurde.

Wie es abgesichert ist

• Der rechtsverbindliche Beleg bleibt unberührt. Eine Rückmeldung wird weiterhin zuerst byte-getreu gespeichert und gegen datei.md5 geprüft; erst danach entsteht die Kopie. Ein Fehler dabei kostet die Kopie, nie die Rückmeldung — ELDA gibt jede Rückmeldung nur einmal heraus.
• Erkannt am Inhalt, nicht am Namen. Die tatsächlich gelieferten Clearingdateien heißen cm_<Nummer>.xml und nicht cm_<Datum>_<Uhrzeit>.xml, wie die Organisationsbeschreibung es angibt, und ihr XML enthält Namensräume, die die Beschreibung nicht zeigt. Die Elemente werden nach ihrem Namen ohne Namensraum gelesen; eine Änderung bei ELDA kann das Lesen deshalb nicht brechen.
• Was nicht sicher lesbar ist, behält die bisherige Auflistung. Eine unbekannte Version der Satzstruktur, ein abgeschnittener Datensatz oder fehlerhaftes XML führen zur bisherigen Rohtext-Kopie, und die Logzeile event=received-file-readable-fallback nennt den Grund. Ein fehlerhafter Inhalt in einem einzelnen Clearingfall kostet nur dessen Details.
• Keine Personendaten im Log. Protokolliert werden Art (kb, cm) und Layout der Kopie, nie ein Inhalt — diese Dateien enthalten Gesundheitsdaten.
• Papier und PDF können nicht voneinander abweichen. Die Seiten werden einmal gesetzt; das PDF zeichnet sie in Helvetica, der Drucker in Arial mit gleichen Zeichenbreiten. Es kommt weiterhin keine Fremdbibliothek hinzu.

rebuild-print-ready: die bereits empfangenen Rückmeldungen

Rückmeldungen, die vor dieser Version empfangen wurden, behalten ihre unlesbare Kopie, und ELDA gibt sie kein zweites Mal heraus. Einmal je Ordner mit Rückmeldungen ausführen:

elda-bridge.exe rebuild-print-ready --input-path "<Ordner der Rückmeldungen>" --dry-run
elda-bridge.exe rebuild-print-ready --input-path "<Ordner der Rückmeldungen>"

• Die empfangenen Dateien werden ausschließlich gelesen. Geschrieben wird je Krankenstandsbescheinigung und Clearingmeldung print-ready\<Name>.pdf; eine alte Kopie wird über eine temporäre Datei ersetzt. Keine andere Datei wird angefasst.
• Ein zweiter Lauf schadet nicht: Eine Kopie, die bereits aktuell ist, wird erkannt und bleibt, wie sie ist (rebuild.unchangedFileCount=).
• Eine Kopie, die gerade in einem PDF-Programm geöffnet ist, kann nicht ersetzt werden. Sie behält ihren alten Inhalt, der Lauf meldet rebuild.status=failed und endet mit 1, und der Bediener sieht das Fenster „Druckfassungen nicht erstellt“. PDF schließen und den Befehl erneut starten.
• --input-path ist Pflicht: Das Lohnprogramm legt die Rückmeldungen meist in einem eigenen Ordner ab (--confirmation-output-path), den keine Einstellung kennt. Den Befehl für jeden solchen Ordner ausführen, und für einen Ordner fallback-replies, falls es einen gibt.

Ebenfalls in dieser Version: die Übergabe des Sendestempels an WinLohn

• --result-file schreibt nach jedem Lauf eine Quittung, die das Lohnprogramm lesen kann — Sendestempel: Ja|Nein, Klasse, Ausstiegscode, Protokollnummer, Vorgangsnummer, Dialog, Meldungstext —, weil WinLohns exe keinen Exit-Code lesen kann. Sendestempel: Ja kann nur ein send erzeugen; ein Lauf, der schon an der Argumentprüfung scheitert, überschreibt keine vorhandene Quittung; print-files und rebuild-print-ready lehnen die Option ab.
• Gedruckt wird nach dem Sendestempel. Der Sendelauf druckt nicht mehr selbst; er hält in <quittung>.drucken fest, was er geholt hat, und print-files --from-result-file "<quittung>" druckt genau das, nachdem WinLohn den Stempel geschrieben hat.
• Dialog: Ja|Nein in der Quittung sagt WinLohn, ob die Brücke bereits ein Fenster gezeigt hat, damit nur ein Programm den Bediener warnt.
• --offer-delete-on-rejection bietet nach einer endgültigen Ablehnung die Löschentscheidung an, löscht nach einem angenommenen Senden aber nie — das Ankreuzfeld in WinLohn behält das letzte Wort.
• Das Löschfenster schließt sich nach erfolgreichem Löschen, statt „Behalten“ als einzigen Ausweg übrig zu lassen.

Was bewusst nicht enthalten ist

• Keine Klartexte für den Status einer Clearingmeldung. meldungStatus und meldungStatusZusatz (z. B. NV, IA) erscheinen so, wie sie empfangen wurden. Die Liste dieser Codes veröffentlicht nur die ÖGK auf ihrer Webseite, und sie ändert sich zum Jahreswechsel; eine im Programm hinterlegte Tabelle wäre früher oder später falsch.
• Keine Deutung einer unbekannten Satzstruktur. Gesetzt wird nur die aktuelle Version 02 der Krankenstandsbescheinigung; jede andere behält die Rohtext-Auflistung, statt falsche Daten oder Beträge auf einen Beleg zu schreiben.
• Keine Lesefassung für mitteilung_*-Mitteilungen; sie werden wie bisher nicht gedruckt.

Hinweise zur Aktualisierung

1. Einmal je Ordner mit Rückmeldungen die lesbaren Fassungen erstellen: elda-bridge.exe rebuild-print-ready --input-path "<Ordner der Rückmeldungen>" --dry-run, die aufgelisteten Dateien prüfen und den Befehl danach ohne --dry-run erneut ausführen.
2. Überwacht eine Druckautomatik oder ein „Hot Folder“ den Ordner print-ready, diese vor Schritt 1 anhalten: Jede ersetzte Kopie sieht für sie wie eine neue PDF-Datei aus und würde erneut gedruckt.
3. Geöffnete PDF-Dateien aus print-ready schließen, bevor Schritt 1 ausgeführt wird; eine geöffnete Kopie kann nicht ersetzt werden und wird als failed gemeldet.
4. Ein Aufrufer, der den print.*-Block nach Zeilenposition liest, sieht eine Zeile mehr, print.readableFileCount=; Aufrufer, die Schlüssel=Wert auswerten, sind nicht betroffen.
5. Die Voraussetzungen sind unverändert: Windows 7 SP1 / Server 2008 R2 oder neuer mit .NET Framework 4.5 oder neuer und TLS 1.2 für den Echtbetrieb.