Mustangproject · Prüfbericht · Hilfe

Mustang: Prüfbericht mit & im Dateinamen ist kein gültiges XML

Trenne einen defekten Prüfbericht von einer ungültigen Rechnung und teste denselben Dateiinhalt mit neutralem Namen.

Quellenstand: 5. November 2026Redaktion: KAN KAI WORKSRedaktionell aktualisiert:

Kurzantwort

Ein nicht lesbarer XML-Prüfbericht ist kein positives Ergebnis der Rechnungsvalidierung. Im dokumentierten Mustang-Fall verursachte ein Ampersand im Dateinamen einen beschädigten Bericht. Vergleiche identische Dateibytes unter einem neutralen Testnamen und prüfe den Rohbericht auf vollständige, wohlgeformte Ausgabe. Ändere keine Rechnungsinhalte durch pauschales Ersetzen von „&“; ein Berichtsfehler und ein fachlicher Rechnungsfehler benötigen getrennte Behandlung.

Quellengrundlage: Q1 · Q2

Gilt für
Behandelt den berichteten Mustang-2.26.0-Fehler bei der Berichtserzeugung. Eine angekündigte Korrektur bestätigt weder ihre Veröffentlichung noch die Fehlerfreiheit einer konkret installierten Version.
So prüfst du das Ergebnis
Die geprüften Dateinamen liefern vollständige lesbare Berichte mit eindeutigem Dateibezug. Ein absichtlich fehlerhaftes Testdokument bleibt erkennbar abgewiesen, statt bei fehlendem Ergebnis als gültig zu gelten.
Deine erste Prüfung

Ist die Rechnung unverändert, während nur der Dateiname den Bericht verändert?

Prüfe mit einer Kopie und identischem Dateiinhalt einen neutralen Namen. Ein fehlender summary-Abschnitt darf in der Integration nicht als bestandene Prüfung gelten.

Die Rechnungsprüfung läuft, aber das Ergebnis-XML lässt sich nicht einlesen. Der Parser beanstandet ein &, und der erwartete summary-Abschnitt fehlt. Ein Mustang-Bericht nennt Version 2.26.0 und einen Dateinamen mit kaufmännischem Und als Auslöser. Q1 Die erste Frage betrifft hier die Berichtserzeugung, nicht automatisch den Rechnungsinhalt.

Drei Zustände sauber unterscheiden

„Geprüft und gültig“, „geprüft und ungültig“ sowie „Prüfung oder Bericht nicht auswertbar“ sind verschiedene Ergebnisse. Auch veraPDF führt Verarbeitungsausfälle gesondert von Konformitätsbefunden. Q2 Eine Integration darf das Fehlen eines auslesbaren Fehlers nicht als Erfolg interpretieren.

Mit unverändertem Inhalt testen

  1. Eingabe und Rohbericht sichern. Bewahre die Rechnung, den ungeparsten Prüfbericht und den ersten Parserfehler auf. Notiere Mustang-, Java- und Integrationsversion. Ein bereits verkürzter Logauszug kann genau die fehlerhafte Stelle verlieren.
  2. Neutral benannte Kopie anlegen. Verwende denselben Dateiinhalt unter einem einfachen Testnamen ohne Sonderzeichen. Vergleiche Prüfsummen, damit der Versuch ausschließlich den Namen verändert. Halte die Zuordnung zum Original fest.
  3. Berichte unabhängig einlesen. Prüfe beide Ausgaben auf Wohlgeformtheit und Vollständigkeit. Erscheint der Fehler nur mit dem ursprünglichen Namen, ist der Berichtspfad eingegrenzt. Das allein sagt noch nichts über die fachliche Richtigkeit der Rechnung.
  4. Fehlerstelle zuordnen. Steht der problematische Name im vom Validator erzeugten Bericht, gehört die Reparatur zur sicheren XML-Ausgabe beziehungsweise Serialisierung. Ersetze nicht pauschal alle & im Rechnungs-XML; gültige Entitäten und echte Inhalte können dadurch beschädigt werden.
  5. Automatische Entscheidung prüfen. Kontrolliere, was dein System bei Parserfehler, leerem Bericht und fehlender Zusammenfassung tut. Solche Dateien benötigen einen sichtbaren Prüfstatus. Sie dürfen weder unbemerkt freigegeben noch als erfolgreich vollständig validiert markiert werden.

Korrektur und Abnahme

Im Originalfall wird eine kommende Korrektur angekündigt; das ersetzt keine Prüfung der tatsächlich eingesetzten Version. Q1 Teste eine passende Änderung mit neutralem Namen, Sonderzeichen und einer bewusst fehlerhaften Testrechnung. Der Ablauf muss sowohl lesbare Berichte erzeugen als auch echte Fehler weiterhin erkennen.

Für Unterstützung sind Dateiname, bereinigter Berichtsausschnitt, Versionsstände und der Vergleich mit identischem Inhalt ausreichend. Vertrauliche Rechnungen müssen nicht vollständig geteilt werden, wenn eine synthetische Datei den Berichtfehler reproduziert. Dies ist eine technische Prüfung der Verarbeitung, keine rechtliche Freigabe eines Belegs.

Beispiel: Gleiche Datei, anderer Name, anderer Prüfbericht

Konstruiertes Diagnosebeispiel: Eine synthetische Testdatei liegt als probe.pdf und als probe & vergleich.pdf vor. Beide sollen bytegleich sein. Die folgende Gegenüberstellung plant eine Prüfung; sie behauptet keine tatsächlich beobachteten Ergebnisse.

  1. Gleichheit sichern: Vergleiche die Prüfsummen beider Kopien. Unterscheiden sie sich, wäre nicht nur der Name verändert und der Versuch müsste neu abgegrenzt werden.
  2. Ausgabe vollständig sichern: Verwende für beide Dateien denselben Validatorstand und dieselbe Konfiguration. Bewahre jeweils den vollständigen Rohbericht und die zugehörige Fehlermeldung getrennt auf.
  3. Ergebnis einordnen: Ein vollständiger gültiger Bericht, ein vollständiger ungültiger Bericht und eine nicht auswertbare Ausgabe sind drei verschiedene Zustände. Scheitert nur der Sonderzeichenname beim XML-Einlesen, ist die Berichtserzeugung eingegrenzt. Die Rechnung ist dadurch noch nicht als gültig beurteilt.

Erwartete Beobachtung: Die Berichte bleiben eindeutig ihren Eingabedateien zugeordnet. Fehlende Zusammenfassungen werden als fehlendes Ergebnis sichtbar und nicht stillschweigend als bestandene Validierung behandelt.

Erfolgskontrolle: Nach einer gezielten Korrektur liefern beide Namen lesbare, vollständige Berichte. Eine zusätzlich bewusst fehlerhafte Testdatei wird weiterhin als fehlerhaft erkannt. So prüfst du sowohl die Ausgabe als auch die Annahmelogik. Rechnungsinhalte werden für diesen Namensvergleich nicht verändert; insbesondere ist pauschales Ersetzen von Ampersands im Rechnungs-XML kein Teil des Tests.

Fachliche Grundlage: Mustangproject issue 1327: Ampersand in filename breaks XML report · veraPDF: CLI validation and reports.

Häufige Fragen

Ist die Rechnung wegen des Dateinamens falsch?

Der beschriebene Befund betrifft zunächst das erzeugte Ergebnisdokument. Die Rechnung braucht anschließend weiterhin ihre vollständige Prüfung.

Kann ich den Bericht einfach als Text durchsuchen?

Das kann bei der Diagnose helfen, ersetzt aber keine verlässliche strukturierte Auswertung und eindeutige Fehlerbehandlung.

Fall beschreiben

Unterstützung bei diesem Fehler

Wir können Berichtserzeugung, Parser und Annahmelogik deiner Rechnungsintegration prüfen.

Fall beschreiben →Passende Leistung: Daten & Weiterentwicklung

Quellen