Mustang-Import bricht mit NumberFormatException ab

Ein Rechnungsimport bricht mit NumberFormatException ab, obwohl die meisten Felder plausibel aussehen. Im archivierten Mustang-Bericht führt ein einzelner nicht akzeptierter Dezimalwert zum vollständigen Abbruch. Genannt werden unter anderem zusätzliche Leerzeichen und lokal formatierte Zahlen. Q1 Die Fehlermeldung muss einer konkreten XML-Stelle zugeordnet werden, bevor eine Reparatur sinnvoll ist.

Anzeigeformat und Datentyp unterscheiden

Eine für Menschen formatierte Zahl wie 1.234,56 ist nicht dieselbe Zeichenfolge wie der technische Dezimalwert 1234.56. XML Schema beschreibt für decimal eine Punktnotation ohne angehängte Einheit. Q2 Zugleich beweist jede Parserexception noch keinen fachlich falschen Betrag: Ein Importer kann beispielsweise Leerraum anders behandeln als eine vorgeschaltete Schemavalidierung.

Vom Abbruch zum betroffenen Feld

1. Unveränderte Eingabe bewahren. Sichere Datei, Prüfsumme, Importerversion und den ersten Fehler. Wiederholte Importe dürfen nicht versehentlich bereits verarbeitete Teile doppelt anlegen. Prüfe daher den bisherigen Verarbeitungsstatus.
2. Fundstelle ermitteln. Suche anhand des Stacktraces und der Importdiagnose den XML-Pfad sowie den Rohwert. Notiere nicht nur „Betrag falsch“, sondern beispielsweise die betroffene Position und das konkrete Zahlenfeld. Schwärze übrige Rechnungsdaten.
3. Schema und Fachwert getrennt prüfen. Lass die unveränderte XML gegen das vorgesehene Schema und Regelprofil prüfen. Ist sie dort gültig, aber der Import scheitert, ist eine abweichende Parserbehandlung ein wichtiger Befund. Scheitert bereits das Schema, korrigiere zunächst den Export an der Quelle.
4. Formatumwandlung gezielt nachweisen. Prüfe, ob Tausendertrennzeichen, Dezimalkomma, geschütztes Leerzeichen oder eine Einheit aus der Oberfläche in ein Zahlenfeld übernommen wurden. Eine globale Ersetzung kann andere Felder oder Zahlenwerte verändern. Verwende die bekannten Datentypen und Regeln des Ausgangssystems.
5. Fehler sichtbar isolieren. Ein betroffener Beleg sollte mit Fundstelle und Status in einer Prüfliste bleiben. Ein ungültiger Pflichtbetrag darf nicht stillschweigend als null importiert werden. Die Fortsetzung anderer Belege braucht eine eindeutige Zuordnung und Schutz vor Doppelverarbeitung.

Korrektur am richtigen Ort

Teste den reparierten Export beziehungsweise Importer mit dem ursprünglichen Fehler und repräsentativen gültigen Dezimalwerten. Vergleiche anschließend die importierten Beträge mit der Ausgangsrechnung. Ein verschwundener Stacktrace allein bestätigt keine richtige Datenübernahme.

Zur Übergabe reichen ein minimaler XML-Ausschnitt, Rohwert, Pfad, Stacktrace und Versionsstände. Diese Hilfe betrifft technische Datenverarbeitung und ersetzt keine fachliche Freigabe von Rechnungsbeträgen.

Häufige Fragen

Kann ich jedes Komma durch einen Punkt ersetzen?

Nein. Ohne Formatkenntnis können Tausendertrennzeichen und Dezimalstellen falsch interpretiert werden.

Soll der Importer bei Fehlern einfach null verwenden?

Nicht für einen ungeklärten Rechnungsbetrag. Ein sichtbarer Prüfstatus erhält die Information, dass dieser Wert nicht zuverlässig übernommen wurde.

Fall beschreiben