xRechnung und Zugferd werden falsch ausgestellt

[FOC Solutions]

Gibt es hier eine Lösung denn wir bekommen immer mehr Rechnungen von Lexoffice Kunden zurück welche die Steuerberater nicht akzeptieren. Rundungsfehler in 3 und 4 Stelle. Es geht nur um 1 cent aber Lexoffice bringt es als Fehler.

Die Nachkommathematik ist schnell und einfach gelöst. Einfach in der X-Rechnung Exportvorlage diese Einstellungen verändern:

| Nummer : '0.0000', 'en-US' }} wird zu

| Nummer : '0.00', 'en-US' }}

Danach gibt es nur noch zwei Nachkommastellen. Diese Einstellung gibt in der X-Rechnungsvorlage knapp 10x, die müssen alle geändert werden.

 

[aws]

Wie ändert man das bei Zugferd? Finde es nicht in den Vorlagen.
Es werden nur 2 Kommastellen angezeigt aber es wird falsch gerundet. Oder liegt das an 1.9.8.0?

Danke!

 

[aws]

Es liegt nicht an Zugferd oder X-Rechnung, sonst JTL rundet einfach falsch und das gibt nun Probleme da geprüft wird. Auch nach neusten Updates von WaWi und Shop kommt:
Artikel Brutto 17,26 € x 3 VPE = 51,77 €

Jemand einen Tip wie man Netto-VK und Brutto-VK Preise fix eintragen kann oder dass es auf 2 Stellen gerundet wird. Da wird mit verschiedenen UST% verkaufen bringt es auch nichts nur den einen Preis rund zu halten.
Danke.

 

[JonasK]

Ich habe einen weiteren Fehler in Lexoffice entfernt. Bei mir fehlte außerdem noch der "BasisAmount" in der Originalen Export Datei steht es auskommentiert unter dem ActualAmount. Es muss einkommentiert werden (also das comment entfernt werden) und anschließend über das ActualAmount geschoben werden.

Vorher:

 <ram:SpecifiedTradeAllowanceCharge>
                        <ram:ChargeIndicator>
                            <udt:Indicator>false</udt:Indicator>
                        </ram:ChargeIndicator>
                        {%- comment -%} Allowance : Wertberichtigung Preisnachlass, Abzug  {%- endcomment -%}
                        {%- comment -%} BT-92 [1]{%- endcomment -%}
                        {%- comment -%} Der Nachlassbetrag ohne Umsatzsteuer {%- endcomment -%}
                        {%- assign sumOfInvoiceineNetAmountBT92 = NetPricePerUnit | Plus : sumOfInvoiceineNetAmountBT92 -%}
                        <ram:ActualAmount>{{ NetPricePerUnit | Nummer : '0.00', 'en-US' }}</ram:ActualAmount>
                        {%- comment -%} BT-93 [0..1]{%- endcomment -%}
                        {%- comment -%} Der Grundbetrag, der in Verbindung mit der "Document level allowance percentage" (BT-94) zur Berechnung des "Document level allowance amount" (BT-92) verwendet werden kann. {%- endcomment -%}
                        {%- comment -%} <ram:BasisAmount>{{ NetPricePerUnit | Nummer : '0.00', 'en-US' }}</ram:BasisAmount> {%- endcomment -%}
                        {%- comment -%} BT-94 [0..1]{%- endcomment -%}
                        {%- comment -%} Der Prozentsatz, der in Verbindung mit dem "Document level allowance base amount" (BT-93) zur Berechnung des "Document level allowance amount" (BT-92) verwendet werden kann. {%- endcomment -%}
                        {%- comment -%} <ram:CalculationPercent>0</ram:CalculationPercent> {%- endcomment -%}
                        {%- comment -%} BT-98 [0..1]{%- endcomment -%}
                        {%- comment -%} Der als Code angegebene Grund für den "Document level allowance amount" (BT-92) {%- endcomment -%}
                        <ram:ReasonCode>95</ram:ReasonCode>
                        {%- comment -%} BT-97 [0..1]{%- endcomment -%}
                        {%- comment -%} Der in Textform angegebene Grund für den "Document level allowance amount" (BT-92) {%- endcomment -%}
                        {%- comment -%} <ram:Reason>Fixed long term</ram:Reason> {%- endcomment -%}
                        <ram:CategoryTradeTax>
                            {%- comment -%} BT-95 [1]{%- endcomment -%}
                            {%- comment -%} Ein Code für das Umsatzsteuermerkmal, das auf den "Document level allowance amount" (BT-92) anzuwenden ist. {%- endcomment -%}
                            <ram:TypeCode>VAT</ram:TypeCode>
                            {%- comment -%} BT-95 [1]{%- endcomment -%}
                            {%- comment -%} Ein Code für das Umsatzsteuermerkmal, das auf den "Document level allowance amount" (BT-92) anzuwenden ist. {%- endcomment -%}
                            <ram:CategoryCode>{{ categoryCode }}</ram:CategoryCode>
                            {%- comment -%} BT-96 [0..1]{%- endcomment -%}
                            {%- comment -%} Der für den "Document level allowance amount" (BT-92) geltende und in Prozent angegebene Umsatzsteuersatz. {%- endcomment -%}
                            <ram:RateApplicablePercent>{{ position.VATRate | Nummer : '0.00', 'en-US' }}</ram:RateApplicablePercent>
                        </ram:CategoryTradeTax>
                    </ram:SpecifiedTradeAllowanceCharge>

Nachher:

<ram:SpecifiedTradeAllowanceCharge>
                        <ram:ChargeIndicator>
                            <udt:Indicator>false</udt:Indicator>
                        </ram:ChargeIndicator>
                        {%- comment -%} Allowance : Wertberichtigung Preisnachlass, Abzug  {%- endcomment -%}
                        {%- comment -%} BT-92 [1]{%- endcomment -%}
                        {%- comment -%} Der Nachlassbetrag ohne Umsatzsteuer {%- endcomment -%}
                        {%- assign sumOfInvoiceineNetAmountBT92 = NetPricePerUnit | Plus : sumOfInvoiceineNetAmountBT92 -%}
                        <ram:BasisAmount>{{ NetPricePerUnit | Nummer : '0.00', 'en-US' }}</ram:BasisAmount>
                        <ram:ActualAmount>{{ NetPricePerUnit | Nummer : '0.00', 'en-US' }}</ram:ActualAmount>
                        {%- comment -%} BT-93 [0..1]{%- endcomment -%}
                        {%- comment -%} Der Grundbetrag, der in Verbindung mit der "Document level allowance percentage" (BT-94) zur Berechnung des "Document level allowance amount" (BT-92) verwendet werden kann. {%- endcomment -%}
                        {%- comment -%} BT-94 [0..1]{%- endcomment -%}
                        {%- comment -%} Der Prozentsatz, der in Verbindung mit dem "Document level allowance base amount" (BT-93) zur Berechnung des "Document level allowance amount" (BT-92) verwendet werden kann. {%- endcomment -%}
                        {%- comment -%} <ram:CalculationPercent>0</ram:CalculationPercent> {%- endcomment -%}
                        {%- comment -%} BT-98 [0..1]{%- endcomment -%}
                        {%- comment -%} Der als Code angegebene Grund für den "Document level allowance amount" (BT-92) {%- endcomment -%}
                        <ram:ReasonCode>95</ram:ReasonCode>
                        {%- comment -%} BT-97 [0..1]{%- endcomment -%}
                        {%- comment -%} Der in Textform angegebene Grund für den "Document level allowance amount" (BT-92) {%- endcomment -%}
                        {%- comment -%} <ram:Reason>Fixed long term</ram:Reason> {%- endcomment -%}
                        <ram:CategoryTradeTax>
                            {%- comment -%} BT-95 [1]{%- endcomment -%}
                            {%- comment -%} Ein Code für das Umsatzsteuermerkmal, das auf den "Document level allowance amount" (BT-92) anzuwenden ist. {%- endcomment -%}
                            <ram:TypeCode>VAT</ram:TypeCode>
                            {%- comment -%} BT-95 [1]{%- endcomment -%}
                            {%- comment -%} Ein Code für das Umsatzsteuermerkmal, das auf den "Document level allowance amount" (BT-92) anzuwenden ist. {%- endcomment -%}
                            <ram:CategoryCode>{{ categoryCode }}</ram:CategoryCode>
                            {%- comment -%} BT-96 [0..1]{%- endcomment -%}
                            {%- comment -%} Der für den "Document level allowance amount" (BT-92) geltende und in Prozent angegebene Umsatzsteuersatz. {%- endcomment -%}
                            <ram:RateApplicablePercent>{{ position.VATRate | Nummer : '0.00', 'en-US' }}</ram:RateApplicablePercent>
                        </ram:CategoryTradeTax>
                    </ram:SpecifiedTradeAllowanceCharge>

Falls jemand etwas überlesen hat hier nochmal meine Zusammenfassung:
- Basis Amount hinzufügen siehe oben
- Rundungsprobleme lösen: https://forum.jtl-software.de/threa...werden-falsch-ausgestellt.235557/post-1283011

| Nummer : '0.0000', 'en-US' }} wird zu

| Nummer : '0.00', 'en-US' }}

- Zuschläge/Abschläge Kommentar entfernen: https://forum.jtl-software.de/threa...werden-falsch-ausgestellt.235557/post-1279128

Hilfreich beim Debuggen war die Elster Seite & natürlich Chatgpt: https://www.elster.de/eportal/e-rechnung
Auch geholfen hat mir die JTL XRechnung Seite: https://guide.jtl-software.com/jtl-wawi/verkauf/x-und-zugferd-rechnungen-ausgeben/

Ich habe erst nicht ganz verstanden, dass man bei Lexoffice auch die (Rechnungs-) XML Datei (XRechnung) importieren kann, die man aus JTL als Ausgabe > Exportieren exportiert. Vielleicht hilft das jemandem der auch auf dem Schlauch stand.

Viel Erfolg allen!

 

[deliman]

Hallo,

gerade von einem Kunden auf folgenden Fehler aufmerksam gemacht worden (wie nutzen die XRechnung Vorlage Rechnung_XRechnung 3.0 CII (UNCEFACT)):
Statt dem hinterlegten Kontoinhaber wird im entsprechenden Feld der Bankname ausgegeben.

Überweisungen gehen dann natürlich zurück an den "Absender".

Zeile 807 in der Vorlage sieht bei uns so aus:
<ram:AccountName>{{ Company.BankName }}</ram:AccountName>

und muss aber so aussehen:
<ram:AccountName>{{ Company.AccountHolder }}</ram:AccountName>

 

[marsblau]

Die Nachkommathematik ist schnell und einfach gelöst. Einfach in der X-Rechnung Exportvorlage diese Einstellungen verändern:

| Nummer : '0.0000', 'en-US' }} wird zu

| Nummer : '0.00', 'en-US' }}

Danach gibt es nur noch zwei Nachkommastellen. Diese Einstellung gibt in der X-Rechnungsvorlage knapp 10x, die müssen alle geändert werden.

Das scheint doch das Problem gar nicht zu lösen?!

Hier die Ausgabe mit 4 Stellen:



Und hier nach der Korrektur auf 2 Stellen



Beide Versionen sind laut Lexoffice NICHT valide!
Die Gesamt-Nettosumme mit 153,18 ist auf Grundlage der 4-Nachkommastellen berechnet und ausgegeben.
Rechnet man alle Artikelpositionen mit 2-Nachkommastellen, sollten 153,16 herauskommen. Und soweit ich es verstehe, bemängelt auch Lexoffice genau dies, die angegebene Gesamtsumme stimmt nicht mit der Summe der Artikelpositionen überein.
Das bezieht sich auf die exportierte XML. Die Zugferd Version ist auch nicht valide laut Lexoffice, augenscheinlich aus dem gleichen Grund. Und nu?

 

[hphock]

@marsblau

Genau aus diesem Grund habe ich Ende letzten Jahres ein Plugin für JTL entwickelt, das speziell auf die Anforderungen der elektronischen Rechnungsstellung (XRechnung, ZUGFeRD & UBL) ausgelegt ist:
👉 hph JTL ZUGFeRD Plugin – hphock.de

Vorteile meines Plugins:​

• ✅ Korrekte Umsetzung aller Beträge und Felder gemäß den offiziellen Spezifikationen
• ✅ Fehlerfreie E-Rechnungen, die u.a. von Lexoffice, Rechnungseingangsportalen und öffentlichen Stellen akzeptiert werden
• ✅ Unterstützung von Rechnungskorrekturen/Gutschriften gemäß den Anforderungen der Formate
• ✅ UBL-Format zusätzlich in der Premium-Version enthalten
• ✅ Einfache Installation & Einrichtung, inkl. Integration über JTL-Workflows
• ✅ 14 Tage kostenlos testen – bei Nichtgefallen einfach stornieren

Ich würde mich freuen, wenn du die E-Rechnungserstellung mit dem Plugin einfach mal ausprobierst. Du findest alle Infos, Screenshots und eine Schritt-für-Schritt-Anleitung auf meiner Website:
🔗 https://hphock.de


Viele Grüße

 

[FOC Solutions]

Das scheint doch das Problem gar nicht zu lösen?!

Hier die Ausgabe mit 4 Stellen:

Den Anhang 124951 betrachten Den Anhang 124954 betrachten

Und hier nach der Korrektur auf 2 Stellen

Den Anhang 124957 betrachten Den Anhang 124960 betrachten

Beide Versionen sind laut Lexoffice NICHT valide!
Die Gesamt-Nettosumme mit 153,18 ist auf Grundlage der 4-Nachkommastellen berechnet und ausgegeben.
Rechnet man alle Artikelpositionen mit 2-Nachkommastellen, sollten 153,16 herauskommen. Und soweit ich es verstehe, bemängelt auch Lexoffice genau dies, die angegebene Gesamtsumme stimmt nicht mit der Summe der Artikelpositionen überein.
Das bezieht sich auf die exportierte XML. Die Zugferd Version ist auch nicht valide laut Lexoffice, augenscheinlich aus dem gleichen Grund. Und nu?

Die ZugFerD Metadaten sind aktuell nicht zu bearbeiten. Das kommt erst mit einer neueren WAWI Version, wir hoffen es kommt in der WAWI 1.11.

 

[marsblau]

@marsblau

Genau aus diesem Grund habe ich Ende letzten Jahres ein Plugin für JTL entwickelt, das speziell auf die Anforderungen der elektronischen Rechnungsstellung (XRechnung, ZUGFeRD & UBL) ausgelegt ist:
👉 hph JTL ZUGFeRD Plugin – hphock.de

Vorteile meines Plugins:​

• ✅ Korrekte Umsetzung aller Beträge und Felder gemäß den offiziellen Spezifikationen
• ✅ Fehlerfreie E-Rechnungen, die u.a. von Lexoffice, Rechnungseingangsportalen und öffentlichen Stellen akzeptiert werden
• ✅ Unterstützung von Rechnungskorrekturen/Gutschriften gemäß den Anforderungen der Formate
• ✅ UBL-Format zusätzlich in der Premium-Version enthalten
• ✅ Einfache Installation & Einrichtung, inkl. Integration über JTL-Workflows
• ✅ 14 Tage kostenlos testen – bei Nichtgefallen einfach stornieren

Ich würde mich freuen, wenn du die E-Rechnungserstellung mit dem Plugin einfach mal ausprobierst. Du findest alle Infos, Screenshots und eine Schritt-für-Schritt-Anleitung auf meiner Website:
🔗 https://hphock.de


Viele Grüße

Das ist für Online-Händler nicht praktikabel. Da zahlt man schon über 1000 EUR für eine hinkende Wawi und müßte bei beispielsweise lediglich 5000 Bestellungen im Monat ca. 500 EUR monatlich für die Rechnungserstellung abdrücken.

Das hier angesprochene Problem ist JTL-seitig damit leider noch immer nicht gelöst.

 

[hphock]

Das ist für Online-Händler nicht praktikabel. Da zahlt man schon über 1000 EUR für eine hinkende Wawi und müßte bei beispielsweise lediglich 5000 Bestellungen im Monat ca. 500 EUR monatlich für die Rechnungserstellung abdrücken.

Das hier angesprochene Problem ist JTL-seitig damit leider noch immer nicht gelöst.

Verständlich, dass die zusätzlichen Kosten auf den ersten Blick abschreckend wirken – aber ganz so hoch wie befürchtet sind sie in Ihrem Fall nicht. Der Premium-Tarif von HPH JTL ZUGFeRD ist gestaffelt – bei einem Belegvolumen von ca. 5000 Rechnungen im Monat würden Sie aktuell bei rund 140 € monatlich landen, nicht bei 500 € (siehe: hphock.de/e-rechnung/hph-jtl-zugferd-premium).


Zudem können Sie die Integration auch so einrichten, dass nur für Ihre B2B-Kunden E-Rechnungen erstellt werden. Dadurch reduziert sich das relevante Belegvolumen deutlich – und somit auch die Kosten.

 

[Vermessungsartikel]

Die Nachkommathematik ist schnell und einfach gelöst. Einfach in der X-Rechnung Exportvorlage diese Einstellungen verändern:

| Nummer : '0.0000', 'en-US' }} wird zu

| Nummer : '0.00', 'en-US' }}

Danach gibt es nur noch zwei Nachkommastellen. Diese Einstellung gibt in der X-Rechnungsvorlage knapp 10x, die müssen alle geändert werden.

Meine XML-Vorlage (die, die die Wawi 1.9.6. mitgebracht hat) hat schon die Einstellung "| Nummer : '0.00', 'en-US' }}" und trotzdem schreibt er vier Stellen nach dem Komma. Das OZG lehnt dies natürlich ab. Bei Rechnungen mit 10 und mehr Positionen ist das mehr als hässlich das händisch zu bearbeiten. JTL Ihr müsst hier handeln, schließlich zahlen wir monatlich Geld für die Software. Und das Plugin ist definitiv keine Option, eine Warenwirtschaft muss ordentliche und rechtliche korrekte Rechnungen erstellen!

 

[frankell]

Meine XML-Vorlage (die, die die Wawi 1.9.6. mitgebracht hat) hat schon die Einstellung "| Nummer : '0.00', 'en-US' }}" und trotzdem schreibt er vier Stellen nach dem Komma. Das OZG lehnt dies natürlich ab. Bei Rechnungen mit 10 und mehr Positionen ist das mehr als hässlich das händisch zu bearbeiten. JTL Ihr müsst hier handeln, schließlich zahlen wir monatlich Geld für die Software. Und das Plugin ist definitiv keine Option, eine Warenwirtschaft muss ordentliche und rechtliche korrekte Rechnungen erstellen!

Du gibst eine ZUGFeRD-Rechnung aus, oder?

 

[Vermessungsartikel]

Du gibst eine ZUGFeRD-Rechnung aus, oder?

Ja, aber es funktioniert auch bei der reinen XML (als Export) nicht. Bei beiden Vorlagen werden 4 Nachkommastellen ausgegeben, trotz der richtigen Formel wie oben gepostet.

 

[frankell]

Ja, aber es funktioniert auch bei der reinen XML (als Export) nicht. Bei beiden Vorlagen werden 4 Nachkommastellen ausgegeben, trotz der richtigen Formel wie oben gepostet.

Bei der ZUGFeRD-Ausgabe wäre es noch erklärlich. Aber bei reinem XML-Export nicht. Guck bitte mal, ob Du wirklich die richtige Zeile erwischt hast. Denn wenn ja, wäre das ein Fall für ein Ticket bei JTL.

 

[marsblau]

Korrigiert mich bitte wenn ich falsch liege ... aber selbst wenn es im XML auf 2 Stellen gekürzt wird, ist die Berechnung falsch, da es auf Grundlage der 4-Stellen Berechnung seitens Wawi die Werte übernimmt. Und sobald es ein paar Positionen oder Stückzahl mehr sind, läuft es am Ende auf Rundungsfehler.

Und die Rundungsfehler sind ja das relevante. Da dann beispielsweise die Bruttosumme bzw. Mehrwertsteuer zum Netto-Betrag nicht passend ist.

 

[frankell]

Korrigiert mich bitte wenn ich falsch liege ... aber selbst wenn es im XML auf 2 Stellen gekürzt wird, ist die Berechnung falsch, da es auf Grundlage der 4-Stellen Berechnung seitens Wawi die Werte übernimmt. Und sobald es ein paar Positionen oder Stückzahl mehr sind, läuft es am Ende auf Rundungsfehler.

Und die Rundungsfehler sind ja das relevante. Da dann beispielsweise die Bruttosumme bzw. Mehrwertsteuer zum Netto-Betrag nicht passend ist.

Korrekt. Das hat JTL, wenn ich mich richtig entsinne, auch erkannt. Nur die Umsetzung wird wohl erst im Zuge einer Generalrevision von Auftrag/Rechnung geschehen.

 

[Jürgen Jester]

Hi, es ist in der Tat zum Verzweifeln. Ich habe auch gerade die Nachkommastellen verändert und frustriert erkannt, dass sich das nicht auf das PDF, sondern nur die einzelne XML im Anhang bezieht. Da wir nur B2B Kunden haben sind aktuell fast alle Rechnungen unbrauchbar - erst Recht wenn eine Kundengruppe Rabatt bekommt, dann haut es mit den Beträgen durch die Berechnung/Rundung nie hin. Echt eine Schande, dass das Programm so einen krassen Pferdefuß hat. Ist denn eine Art "Generalrevision von Auftrag/Rechnung" angekündigt?
Viele Grüße,
Jürgen

PS: Ich habe ein Ticket geöffnet - wir sind ratlos.

 

[frankell]

Ist denn eine Art "Generalrevision von Auftrag/Rechnung" angekündigt?

Ich kann es grad nicht auf die Schnelle zitieren, aber meine Erinnerung sagt ja. Natürlich ohne jede Angabe eines Zeithorizonts, wann damit zu rechnen ist.

 

[Jürgen Jester]

Ich kann es grad nicht auf die Schnelle zitieren, aber meine Erinnerung sagt ja. Natürlich ohne jede Angabe eines Zeithorizonts, wann damit zu rechnen ist.

Hi, bitte alle mithelfen! Ich bekam diese Antwort vom Support:

>> Zu dem Thema haben wir aktuell ein Bug-Ticket offen. Den aktuellen Status sowie die voraussichtliche Lösungsversion, sofern bekannt, sehen Sie hier im Issue-Tracker: 👉 https://issues.jtl-software.de/issues/WAWI-80914 👈
>> Gerne können Sie sich mit Ihren Kundencenter-Daten im IssueTracker anmelden und mit einem Vote und einem Kommentar aktiv Einfluss auf die Priorisierung des Tickets in der Entwicklung nehmen.

Ich habe gevotet - aber man kann leider nur einmal ... bitte dort mit dem Login für das Kundencenter anmelden und voten 👍

Danke und kommt gut ins Wochenende,
Jürgen

 

[marsblau]

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.