ZUGFeRD XML erstellen

[Rollo62]

Ich meine es gibt die Felder
Netto-Preis (BT-131): Rechnungspositionsbetrag ohne Steuern.
Steuersatz (BT-152): BT-152 repräsentiert den Mehrwertsteuersatz, der auf die Position angewendet wird (19% od 7%).
Steuerbetrag (BT-136): BT-136 ist das Feld für den Mehrwertsteuerbetrag auf Positionsebene.

Diese Werte sind als dezimaler Datentyp (Amount; XML-Datentyp: xs:decimal) eingebbar, mit meiner Meinung nach einer festen, definierbaren Stellenanzahl.

D.h. der Bruttopreis ist einfach BT-131 + BT-136, ebenfalls ein Dezimalwert mit definierter Stellenzahl.
Da sollte es keine Rundungsfehler geben.

Das ist aber nur was ich so aus Versuchen herausgefunden habe, das Kleingedrückte der Normen kenne ich nicht.

https://www.arbeitsagentur.de/datei/...e_ba030920.pdf

[BlueStarHH]

Zitat von Rollo62:

Da sollte es keine Rundungsfehler geben.

Doch gibt es. Ich verkaufe nicht seit gestern Rechnungssoftware Ich mache Dir nachher mal ein Beispiel mit konkreten Zahlen.

[BlueStarHH]

Ein Beispiel auf die Schnelle:

Privatkunde kauft ein Teil für 14,- EUR brutto.

Bruttorechnung:
14,00 / 1,19 = 11,76 netto

Wie soll das ganze in einer Nettorechnung aussehen? Geht nicht:
11,76 * 1,19 = 13,99 (1 Cent fehlt)

Einfach den Nettopreis erhöhen geht nicht, denn:
11,77 * 1,19 = 14,01 (1 Cent zu viel)

Hier ein Hinweis:

Zitat:

Die europäische Norm 16931 schreibt den Nettopreis als verbindliche Preisinformation vor. E-Rechnungen können daher nur auf Basis von Nettopreislisten erstellt werden.

Quelle auf die Schnelle: https://apps.datev.de/help-center/documents/1008456

[Rollo62]

Zitat von BlueStarHH:

ein Beispiel mit konkreten Zahlen.

Ja, Du meinst wahrscheinlich dass auf zwei Stellen gerundet wird.

Ausgangsdaten mit 2-Stellen nach dem Komma
11,560000 //2-Stellen
02,196400
13,756400

in der Rechnung zu 2-Stellen gerundet

11,56 // dies ist der passende Nettopreis
02,20 //
13,76 // zu diesem Bruttopreis

oder sehe ich das falsch?

Wenn Du von 3-Stellen nach dem Komma ausgehst und diese dann auf 2-Nachkommastellen rundest,
dann könnte es wohl Abweichungen geben.

Aber ist es nicht genau das, was es aktuell schon auf jeder Rechnung in gleicher Weise gibt?
Ist das eigentliche Problem, dass es dann keine "festen" Nettopreise im System gibt?

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Sorry für meine blöden Fragen, aber ich schreibe halt nur "simple" Rechnungen an meine Kunden, und es gab da niemals Probleme bzgl. Runden.
Vermutlich ist das bei Saturn und Aldi anders.

[BlueStarHH]

Zitat von Rollo62:

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Nein. In der E-Rechnung ist es eben nicht möglich, wenn ich dem Privatkunden etwas zu eimem bestimmten Bruttopreis verkaufen möchte/muss. Siehe mein Beipsiel oben. Der Kunde kauft etwas für 14,- Brutto. Es ist in diesem Fall nicht möglich eine E-Rechnung mit einer Gesamtbrutosumme von 14,- EUR auszustellen, da die E-Rechnung mit Nettopreisen auf Positionsebene arbeitet. Das gilt auch für Papiererchnungen, wenn es Bruttorechnungen sind.

[Harry Stahl]

Zitat von BlueStarHH:

Zitat von Rollo62:

Die ausgewiesenen Daten müssen halt in der Rundung und in der Summe am Ende passen, das ist doch möglich.

Nein. In der E-Rechnung ist es eben nicht möglich, wenn ich dem Privatkunden etwas zu eimem bestimmten Bruttopreis verkaufen möchte/muss. Siehe mein Beipsiel oben. Der Kunde kauft etwas für 14,- Brutto. Es ist in diesem Fall nicht möglich eine E-Rechnung mit einer Gesamtbrutosumme von 14,- EUR auszustellen, da die E-Rechnung mit Nettopreisen auf Positionsebene arbeitet. Das gilt auch für Papiererchnungen, wenn es Bruttorechnungen sind.

Privatkunden schickst Du sowieso keine X-Rechnung, da können die nichts mit anfangen. Die Verpflichtung gilt nur für B2B und B2G, Privatkunden kannst Du Rechnungen wie bisher zusenden.

[Rollo62]

Ok, sorry, ich muss das doch nochmal versuchen zu klären.

Ich meine es gibt zwei Methoden zur Berechnung, die Rück-Differenz-Methode (horizontale Methode) und Rück-Multiplikation (vertikale Methode).

Rundung.jpg

Es kommt natürlich immer eine Differenz beim Runden raus, von 0.01 Ct, was das Finanzamt aber normalerweise akzeptiert wenn es konsistent ist.

Hat sich da was geändert seit X-Rechnung?

[sh17]

Ja, dass der XRechnung-Validator damit derzeit nicht umgehen kann. Nur die ZUGFeRD v2.3 Validierung akzeptiert solche Differenzen.

[ADelph]

Moin,

ich arbeite mit ReportBuilder von Metaphors. Dort gibt es die Möglichkeit, in ein PDF per Stream, bzw. Datei eine XML-Datei einzufügen. Daher habe ich gedacht, dass ZUGFeRD eine gute Idee ist. Nun lese ich hier , dass PDFs mit der Einbettung möglicherweise für die Zukunft keine gute Idee sind. Also dann doch XRechnung.

Bei XRechnung habe ich das mit der Nameskonvention noch nicht klar: kann ich der XML-Datei einen beliebigen Namen geben? Ich lese dazu unterschiedliche Hinweise.

Eine XML-Datei im Format ZUGFeRD im Profil EXTENDED für eine einfache Rechnung kann ich erstellen. Probleme gibt es bei Validierungstools wenn ich mit Rabatten auf Positionsebene arbeite und Summen dann nicht stimmen. Da muss ich noch die Rundungsdifferenz einfügen. Das wird wohl funktionieren.

Wofür ich keine Beispiele gefunden habe, sind Rechnungen mit mehreren Bestellungen/Lieferscheinen (B/L), wobei die Positionen zum Teil zu berechnende Preise enthalten und teilweise nur die Position - sprich der Artikel - angegeben wird. Dann kann es auf B/L-Ebene Rabatte oder Zuschläge geben. Für die Rechnungssumme interessiert da nur das rabattierte Netto, die einzelnen Positionen sind quasi nur dazu da, zu zeigen wie sich der Betrag für den B/L ergibt. Wie ich das bei XRechnung darstellen soll, ist mir schleierhaft. Eine Serialisierung könnte ich mit "IncludedSupplyChainTradeLineItem" machen, aber wie kennzeichne ich, dass ein Betrag einer Position nicht zur Berechnung des Rechnungnettobetrags herangezogen werden soll, wohl aber ausgewiesen werden soll - so wie auf einer Papierrechnung eben?

So würde schematisch eine Rechnung aussehen:
Rechnung R01
Auftrag 12345
Pos 1 : 2,00
Pos 2 : 2,50
Pos 3
Summe 12345 : Netto 4,50, Rabatt 10% : 4,05

Auftrag 23456
Pos 1 : 3,00
Summe 23456 : Netto 3,00

Summe R01 : 7,05, Rabatt 5% : 6,70

Da fehlt mir zurzeit total der Durchblick.

Kennt jemand Beispiele dazu? Das würde mir schon sehr helfen.