Nachkommastellen außerhalb der Positionen

[luansalaj]

Hallo Zusammen,

zunächst einmal vielen Dank an @stephanstapel für die tolle Arbeit!

Ich habe eine Frage und stoße gerade an meine Grenze und zwar geht es um das Thema Nachkommastellen. Auf Positionsebene kann ich beispielsweise einen Wert von 43.6452 angeben. Wird dieser im Anschluss mit der Menge 10 multipliziert, wird im LineTotalAmount 436.35 reingeschrieben, anstelle von 436.352.

Jetzt zu meiner offensichtlichen Frage, wie kann ich das fixen bzw. wie ist das gesamte Thema Nachkommastellen allgemein gedacht? Ist es überall nur mit zwei Nachkommastellen möglich bis auf Positionsebene?

Würde mich über eine Rückmeldung sehr freuen.

Vielen Dank und viele Grüße!

[stephanstapel]

Hallo @luansalaj ,
hier gab es eine vergleichbare Diskussion und einen Screenshot aus der Dokumentation:
#398 (comment)

[Tragen]

Das Problem ist dass die Summen dann aber nicht übereinstimmen, gerade wenn man noch Rabatte auf den Preis hat.
Die Validatoren akzeptieren alle mehr Nachkommastellen, aber wenn ich weniger habe und es zu Rundungsdifferenzen kommt, dann werfen die eine Fehlermeldung aus.

[Dirksche]

Ich denke die Implementierung ist hier korrekt.
"DIN EN 16931-1:2020-12" ("EN 16931-1:2017+A1:2019 + AC:2020 (D)") gibt für BT-131 "Nettobetrag der Rechnungsposition" als "zulässige höchste Anzahl an Dezimalstellen" die Zahl 2 an. Manche Werte dürfen halt nur zwei Nachkommastellen haben. Siehe Tabelle 26 "Zulässige Anzahl an Dezimalstellen" in EN 16931.
Es gibt auch Validatoren (ich denke https://www.portinvoice.com/), welche es anmerken, wenn man für BT-131 mehr als 2 Nachkommastellen hat, weil es dann nicht mehr genau den Vorgaben von EN 16931 entspricht. Ob eine Rechnung deshalb abgelehnt wird, ist eine andere Frage.

Wir haben auch Probleme mit Rundungsdifferenzen. Wahrscheinlich werden wir BT-114 "Rundungsbetrag" dafür verwenden, damit die Endsumme mit der von uns "üblicherweise" berechneten Endsumme übereinstimmt. Eine andere Überlegung wäre, alle Nettobeträge erstmal auf zwei Nachkommastellen zu runden. Aber dafür müssten wir unsere interne Rechnungserstellung ändern.

[Tragen]

Wir haben das gleiche Problem.
Selbst wenn wir die Positionsbeträge auf 2 Nachkommastellen runden haben wir noch das Problem dass der Rabatt in der Position auch nur 2 Nachkommastellen hat und somit auch nicht richtig funktioniert.
Ich schaue mit BT-114 mal genauer an.

[Tragen]

Irgendwie geht der "Standard" in einigen Fällen mal wieder an der Realität vorbei. 🤷
Da kann Stephan nichts dafür, aber es ist nervig.
Wir werden vor dem drucken einer Rechnung eine Warnung anzeigen dass das PDF und das XML nicht übereinstimmen und im XML die Rundungsinfos als Text zur Rechnung mit übergeben.

[Dirksche]

Irgendwie geht der "Standard" in einigen Fällen mal wieder an der Realität vorbei. 🤷
Da kann Stephan nichts dafür, aber es ist nervig.

Sehe ich auch so. Standards werden oft von Leuten geschrieben, die die nicht benutzen müssen.

[stephanstapel]

Das ist alles richtig und ich kann den Unmut gut nachvollziehen.

Vergesst bitte nicht, dass die Rechnungen nicht nur korrekt erzeugt werden müssen, sondern auch von den Kunden Eurer Nutzer verarbeitet werden müssen. D.h. eine Implementierung zum Erzeugen von Rechnungen betrifft hunderte oder tausende von Kunden, die die Informationen aller gleichermaßen interpretieren können müssen. Man kann sicher davon ausgehen, dass bei jedem nutzenden Unternehmen Kunden vorhanden sind, die nicht mit mehr als 2 Nachkommastellen umgehen können - genau wie natürlich auch Nutzer vorhanden sind, die Cent-Rundungsdifferenzen (zurecht) nicht akzeptieren.
Andere Nachkommastellen als im Standard vorgesehen verschiebt nur das Problem an eine andere Stelle.

Wenn jemand Zeit haben sollte und mich hierbei unterstützen kann:
#352

wäre das super. Slack ist allerdings afaik ausschließlich für Extended verfügbar