Mustang 2.26.0: Rundungsproblem triggert undokumentierte Exception

[Uwe Mock]

Mir wurde in Jes ein Problem beim Import von Metadaten aus einer e-Rechnung gemeldet.

Die Situation ist folgende:

Die Rechnung weist eine Position mit 2 Artikeln zu 84,03€ netto aus. Das waren offenbar mal 100€ brutto. Als Gesamt-Nettopreis der beiden Artikel werden 168,07€ ausgewiesen, als Gesamt-Bruttobetrag 200,00€.

Mustang 2.26.0 stört sich nun beim Extrahieren der Metadaten daran, daß das Brutto der 2 Artikel nur 199,99€ ergibt, und es fliegt eine ArithmeticException mit der Message "Payable total in XML is 200.00, but calculated total is 199.99 with tax basis 168.06 and with positions 168.06 = 168.06".

Mal abgesehen davon, daß die Nettobeträge in der Rechnung inkonsistent sind (2*84,03€ = 168,06€ und nicht 168,07€)...

Beim bloßen Extrahieren von Metadaten dürfte Mustang diese Inkonsistenz der Angaben nicht interessieren. Wenn ich ZUGFeRDInvoiceImporter.extractInvoice() aufrufe, frage ich Daten an und nicht das Ergebnis einer Validierung. Insofern das Format der Daten soweit korrekt ist, daß die Anfrage beantwortet werden kann, muß sie auch beantwortet werden - auch wenn die eigentlichen Daten unsinnig sind.

Bei ZUGFeRDInvoiceImporter.extractInvoice() sind zwei checked Exceptions dokumentiert: XPathExpressionException und ParseException. Es fliegt aber eine ArithmeticException. Das ist nicht nur die völlig falsche Exception ("Thrown when an exceptional arithmetic condition has occurred" - das ist hier nicht der Fall!), sie ist außerdem undokumentiert und auch noch unchecked, so daß man gar nicht weiß, daß Mustang (a) beim Aufruf von ZUGFeRDInvoiceImporter.extractInvoice() nicht nur das Format validiert, sondern auch eine Plausibilitätsprüfung über den Inhalt durchführt, und (b) daß man diese Exception abfangen sollte, damit das Programm weiterlaufen kann.

To Do:

• ZUGFeRDInvoiceImporter.extractInvoice() sollte nicht die Plausibilität  des Inhalts der Metadaten prüfen. Das könnte eine zusätzliche Methode machen oder extractInvoice() macht es optional, gesteuert durch einen Parameter.
• Inkosistenzen im Inhalt sollten nicht mit der ArithmeticException gemeldet werden, denn die ist für Situationen vorgesehen, in denen etwas nicht berechnet werden kann (z.B. Division durch 0). Bei der ParseException merkt man am Feld errorOffset, daß sie nicht die richtige sein kann. Vermutlich ist das eine Situation, in der eine eigene Exception sinnvoll wäre. Diese Exception sollte checked und ordentlich dokumentiert sein.

Ich werde derweil mal Ralf Heydenreich kontaktieren um nachzufragen, ob sich derlei Inkonsistenzen in Rechnungen überhaupt generell ausschließen lassen.

[jochen...@gmail.com]

Hallo,

Schon öfter gehört, probier mal zii.doIgnoreCalculationErrors(); 

ansonsten gerne Issue und / oder PR.

Die Idee ungeprüft zu importieren ist nett, aber ich weise mal darauf hin, dass es 

1. mittlerweile zur rechtlichen Obligenheit geworden ist, zumindest nur valide Rechnungen anzunehmen und zu verarbeiten (der Umsatzsteuer-Anwendungserlass empfielt auf S. 535,540,542 und 576 dazu dringend die Nutzung einer Validierungsanwendung) und

2. man mit nicht reproduzierbaren Zahlen dann auch nicht weiter arbeiten kann. Füge ich in die importierte Rechnung dann noch eine Position ein oder wandele sie in eine Bestellung, Korrekturrechnung oder einen Lieferschein um wird man um eine neuberechnung nicht umhinkommen 

3. Nicht nur um Fakturama geht: Selbst wenn dir Ralf sagt, dass er es dort hin bekommt, haben wir andere noch nicht normierte Rechenmethoden. Erstens explizit 

3.1 erlaubte,  Mein erstes Fokusbuch kostet bspw. brutto 10,01€ bei 7% USt, was es laut BuchPrG auch darf. Dummerweise erfolgt die Angabe des Nettobetrags in der Norm auf Centgenauigkeit, 9,35€ ergeben aber 10,00€ und 9,36€ netto ergeben 10,02€ und zweitens lediglich 

3.2 tolerierte,  so lesen wir bspw. in der ct1/2026 ("Programmierter Fehler auf Vodafone-Rechnung") dass man USt durchaus auch auf den Nettobetrag pro Position statt auf den Gesamtnettobetrag des Steuerfalls anwenden darf. Das ist weder in der aktuellen noch in der kommenden Ausgabe der Norm vorgesehen.

ciao

Jochen