xRechnung und Zugferd werden falsch ausgestellt

[sebjo82]

Siehe meine Nachricht von zuvor ... nicht die Ausgabe der 4 Stellen ist das Problem, das kann man auch selbst, zumindest in der XRechnung, beheben. Das Problem ist, dass JTL mit 4 Stellen rechnet, "alle anderen" nur mit 2 Stellen.

Beispiel:
in JTL 10 x 0,2440 EUR = 2,44 EUR + 0,4636 EUR USt = 2,90(36) EUR
rest der Welt. 10 x 0,24 = 2,40 EUR + 0,46 EUR USt = 2,86 EUR

Berechnung seitens JTL auf JTL Grundlage.
Prüfung laut Welt im Hinblick auf 2 Stellen. Hier entsteht der Widerspruch.

Bei JTL kommt in der Position eine andere Summe zusammen als in der Validierung. Umsatzsteuer im Beispiel zufällig "gleich", trotzdem unterscheidet sich die Endsumme.
Deswegen nutzt auch ein Runden im Formular auf 2 Stellen nichts, da der Betrag in der Positions-Summe und in der Endsumme und meist auch in der Steuer nicht mit den erwarteten Daten in der Validierung übereinstimmt. Also so in etwa denke ich.

Korrekt, es muss eine Korrektur-Position von in der Regel +-1 Cent in die X-Rechnung geschrieben werden, um den Rundungsfehler der bei Summierung der Netto-Einzelpositionen auftritt auszugleichen, damit der Vergleich mit Gesamt-Netto nicht fehlschlägt

Die bislang angesprochenen Lösungen greifen diese Problematik nicht auf

X-Rechnung Einzelposition darf max 2 Nachkommastellen haben
Wawi speichert 4
Also wird gerundet in der X-Rechnungsvorlage
Gesamt-Netto wurde mit 4 Nachkommastellen berechnet
Es kommt zur Differenz, wenn Lexware die Einzelpositions-Nettos aufsummiert und mit Gesamt-Netto vergleicht

Wie vermeidet man diese Differenz ohne 5 Jahre auf JTL zu warten?
Immer nur Netto-Preise mit 2 Nachkommastellen in der Wawi pflegen.
Und oder man arbeitet mit den angesprochenen Korrektur-Positionen von +- 1 Cent

Wenn jemand Hilfe bei der Implementierung braucht, sodass diese auch in Lexware importiert werden können, gerne per Nachricht melden

 

[Richard von Eggstätt]

Ich zitiere hier meine Buchhalterin, die seit Jahrzehnten im Geschäft ist: „Rundungsfehler sind ein alter Hut. Die gab es schon immer und die wird es immer geben.“
Also wir verkaufen z.B. auch Meterware mit einem Preis ab 0,03 EUR / Meter. Wie will man mit 3 Ct die korrekte MwSt. rechnen? Ich halte das für nicht so tragisch. Wichtig wäre tatsächlich, dass die X-Rechnung valide ist.

 

[sebjo82]

Ich zitiere hier meine Buchhalterin, die seit Jahrzehnten im Geschäft ist: „Rundungsfehler sind ein alter Hut. Die gab es schon immer und die wird es immer geben.“
Also wir verkaufen z.B. auch Meterware mit einem Preis ab 0,03 EUR / Meter. Wie will man mit 3 Ct die korrekte MwSt. rechnen? Ich halte das für nicht so tragisch. Wichtig wäre tatsächlich, dass die X-Rechnung valide ist.

Genau, es geht auch eher darum, dass X-Rechnungen ohne Meckern in Programme wie Lexware importiert werden können. Online-Validatoren, wie https://erechnungsvalidator.service-bw.de/ prangern diese Art Fehler nicht an. Daher ist es auch völlig ok diese Korrekturpositionen in die Rechnung zu schreiben

 

[marsblau]

Immer nur Netto-Preise mit 2 Nachkommastellen in der Wawi pflegen.

Problematisch wenn man glatte Preise haben möchte. Importiert man Brutto gerundet, rechnet JTL beim Netto auf 4-Stellen nach dem Komma runter anstatt beispielsweise Brutto und Netto zweistellig aus einem Import zu übernehmen. Ärgerlich, denn krumme Preise (und seinen es nur x,x9) möchte man ggf. nicht.

 

[Richard von Eggstätt]

Ich sehe die vierstellige Rechengrundlage duchaus als Vorteil. Bei sehr geringen Preisen, wie bei uns z.B. 3 Ct / Meter ist eine Steuerrechnerei nur zweistellig gar nicht wirklich möglich. Nur so, hatten wir 2024 eine Steuerdifferenz von nur 25 EUR (Rundungsfehler). Ich möchte mir das gar nicht ausmalen was wäre, wenn ausschliesslich mit zwei Nachkommastellen gerechnet werden sollte. Mir persönlich wäre nur wichtig, das in der E-Rechnung eben nur zwei Nachkommastellen ausgewiesen sind, damit das überkandidelte Lexware das auch frisst. Mehr muss von mir aus gar nicht sein.

 

[sah]

Im Guide heißt es etwas lapidar "Vorlagen der Ausgabe 2.0" verwenden, wie erstelle/konvertiere ich diese mit wenig Aufwand?

 

[frankell]

Hallo @sah,

kommt darauf an, was genau Dein Ziel ist. Eine X-Rechnung "erzeugst" Du einfach, indem Du eine neue Exportvorlage vom Typ X-Rechnung anlegst. Möchtest Du ein ZUGFeRD, musst Du auch eine neue Speichervorlage (das sind die, die nicht mit dem Zusatz "(Veraltet)" versehen sind) anlegen. Nur dass die Speichervorlage für ein ZUGFeRD noch nicht editierbar ist. Das ist erst ab der Version 1.11 möglich.

 

[sebjo82]

Bedenkt bei Zugpferd, dass diese nur für B2B, NICHT für B2G gedacht sind (in Deutschland zumindest). B2G benötigt (falls überhaupt eine E-Rechnung gefordert wird) unbedingt XRechnung, d.h. eine .xml Datei

 

[Print-Green]

Leider können noch immer keine ordnungsgemäßen E-Rechnungen erstellt werden, wir haben schon viele Kundenanfragen immer mal wieder.

 

[faceofboh]

versteh nicht das sowas keine Priorität hat. Ich kann kaum an eine Behörde ne richtige Rechnung senden. Diese (schlechte) Lösung hier aus dem Beitrag macht rundungsfehler, und wieder muss die XML "Bearbeitet" werden. Das ist doch keine Lösung!

Rheinland-Pfalz ist ebenfalls besonders pingelig.

 

[sebjo82]

Ich habe eine funktionierende XRechnungs-Export-Vorlage erstellt, welche ich für einen kleinen Obolus anbieten kann. Bei Interesse gerne via DM melden

 

[okiehstc]

Hallo in die Runde,

hab da mal eine dumme Frage.
Gestern kam die Nachricht von JTL das endlich das Problem mit den 4 Nachkommastellen in der Zugpferd Rechnung behoben sein soll!

https://issues.jtl-software.de/issues/WAWI-80914

Status Gelöst

Kann mir eventuell jemand sagen ob man dazu ein Updat machen muss oder wie man nun in den Genuss einer eventuell funktionierenden Zugpferd Rechnung bei JTL kommt!

Wie wird die Änderung in der WaWi eingepflegt?
Geht das automatisch? (verwenden aktuell 1.10.12.0)

Dazu steht leider nichts geschrieben.

Vielen Dank

 

[FOC Solutions]

Hallo in die Runde,

hab da mal eine dumme Frage.
Gestern kam die Nachricht von JTL das endlich das Problem mit den 4 Nachkommastellen in der Zugpferd Rechnung behoben sein soll!

https://issues.jtl-software.de/issues/WAWI-80914

Status Gelöst

Kann mir eventuell jemand sagen ob man dazu ein Updat machen muss oder wie man nun in den Genuss einer eventuell funktionierenden Zugpferd Rechnung bei JTL kommt!

Wie wird die Änderung in der WaWi eingepflegt?
Geht das automatisch? (verwenden aktuell 1.10.12.0)

Dazu steht leider nichts geschrieben.

Vielen Dank

Lt. Ticket ist nur die X-Rechnung gefixt und nicht die ZUGFerD. Als Zielversion ist die WAWI 2.0 angegeben.

In der X-Rechnung kannst Du es selbst lösen, siehe: https://forum.jtl-software.de/threa...werden-falsch-ausgestellt.235557/post-1283011

 

[SevenDev]

Auch hier blickt man aktuell nicht mehr richtig durch.

Was genau muss bzw. kann man derzeit tun, um das grundsätzliche Rundungsproblem zu beheben? Lässt sich dieses Problem in JTL größtenteils oder sogar vollständig beheben? Also so, dass es wirklich in allen Bereichen korrigiert ist – nicht nur bei XRechnung und ZUGFeRD, sondern systemweit?

 

[arich001]

Lt. Ticket ist nur die X-Rechnung gefixt und nicht die ZUGFerD. Als Zielversion ist die WAWI 2.0 angegeben.

In der X-Rechnung kannst Du es selbst lösen, siehe: https://forum.jtl-software.de/threa...werden-falsch-ausgestellt.235557/post-1283011

Aber erst ab Version 2.* oder ?
Hab am WE auf 1.11.7 geupdatet und xrechnung und Zugferd neu hinzugefügt.....da ist überall noch Nummer : '0.0000', 'en-US' }} drin....mehrfach.
Bringt das überhaupt was wenn ich dann an allen Stellen in der Vorlage es auf 0.00 ändere, oder bleibt der Kern des Rundungsfehlers erhalten ?

 

[FOC Solutions]

Aber erst ab Version 2.* oder ?
Hab am WE auf 1.11.7 geupdatet und xrechnung und Zugferd neu hinzugefügt.....da ist überall noch Nummer : '0.0000', 'en-US' }} drin....mehrfach.
Bringt das überhaupt was wenn ich dann an allesten stellen in der Vorlage auf 0.00 ändere, oder bleibt der Kern des Rundungsfehlers erhalten ?

Das Rundungsproblem wird wohl erst mit der WAWI 2.0 gelöst, das JTL er dort intern auf zwei Nachkommastellen umstellt. Ob das flächendeckend passiert kann ich aktuell noch nicht sagen, wie die Auswirkungen sind wird sich zeigen.

Die Umstellung von Nummer : '0.0000', 'en-US' auf Nummer : '0.00', 'en-US' behebt zumindest das Problem, das Lexware die Rechnungen nicht annimmt bzw. verarbeiten kann.