Netto/ Brutto Rechnungen

[Papick G. Taboada]

Hallo in die Runde,

unsere Anwendung kann sowohl Netto wie Brutto-Rechnungen anlegen, da ändert sich dann die Berechnung des MwSt-Betrages.

Deswegen ist es für uns extrem wichtig, dass wir die MwSt-Beiträge definieren zu können.

Das ganze gibt es schon auf Github als Ticket:

https://github.com/ZUGFeRD/mustangproject/issues/144

Das ist aktuell das KO Kriterium für uns.

lg

Papick

[Jochen Stärk]

Hallo,

das tut mir dann sehr leid aber meines Wissens geht das mit e-invoicing derzeit nicht und ist in den frei verfügbaren Rechenregeln bspw. des EN16931-1 https://www.beuth.de/en/standard/din-en-16931-1/314992770 auch nicht erwähnt.

ciao

Jochen

--
You received this message because you are subscribed to the Google Groups "ZUGFeRD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zugferd+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zugferd/0e0f2f05-fe54-4570-bd0e-ca82b0647d35n%40googlegroups.com.

[Schmidt Thomas]

Ist eine interessante Fragestellung.

Wir stellen auch Rechnungen ohne Mehrwertsteuer.

Diese werden ab nicht per ZUGFeRD versendet.

Gruß Thomas 

Von meinem iPhone gesendet

Am 08.06.2023 um 20:24 schrieb Jochen Stärk <jochen...@gmail.com>:



To view this discussion on the web visit https://groups.google.com/d/msgid/zugferd/CACzwKgpEhy0QEv_uSvjeDY5J%2BhcwsGF__RM9iPOqhmRGhrvzyw%40mail.gmail.com.

[Sam Jost]

Da der Thread schon über ein Jahr alt ist meine Nachfrage:

Gibt es die Möglichkeit Brutto-Rechnungen in ZugFerd zu erstellen? Unser Kunde rechnet Patienten über Krankenkassen ab, für die Kassen und den Patient muss die Berechnung Brutto erfolgen und der Abrechnungsdienstleister/Kasse soll als Unternehmen natürlich die Rechnung zum Rezept als E-Rechnung bekommen.

Vielen Dank & schöne Grüße

Sam

[Martin Wagner]

Ich hoffe, ich lege mich nicht zu weit aus dem Fenster. Ich beschäftige mich erst seit kurzem mit Xrechnung bzw. ZugFeRD.

Ich suche daher verzweifelt Musterdaten, die zur Definition passen.

XRechnung erzeugt noch nur ein anderes Dateiformat. Also nicht mehr ausgedruckt bzw. PDF, sondern maschinenlesbar als XML-Datei.

Ich erstelle doch normale Rechnungen für das Ausland auch ohne Mehrwertsteuer. Also Brutto und Netto sind identisch.

Warum soll das nicht mit XRechnung gehen?

[Mauritz Funke]

Habe zwar direkt zum Thema nichts beizutragen, aber von der ZUFeRD Open Source Community gibt es unter: https://github.com/ZUGFeRD/corpus/ eine Zusammenstellung von verschiedenen Formaten und Anwendungsbeispielen. Dort kann man sich gut orientieren

[Martin Wagner]

Hallo

Danke für den Tipp. Die Seiten habe ich auch schon durchsucht. Leider passt alles nicht zusammen. Oder ich bin zu blöd.

Wenn ich die Spezifikation von XRechnung-V3.0.2 zugrunde lege, heißt dort z.B.

- BR-2 Eine Rechnung (INVOICE) muss eine Rechnungsnummer "Invoice number" (BT-1) enthalten.
- BR-3 Eine Rechnung (INVOICE) muss ein Rechnungsdatum "Invoice issue date" (BT-2) enthalten.
- BR-4 Eine Rechnung (INVOICE) muss einen Rechnungstyp-Code "Invoice type code" (BT-3) enthalten.

- BR-5 Eine Rechnung (INVOICE) muss einen Währungs-Code "Invoice currency code" (BT-5) enthalten.

Wenn ich dann die XML Dateien durchsuche, tauchen diese Begriffe nirgends auf.

Das einzige was auftaucht ist
   <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>

Der Code "360" für eine normale Rechnung, also "Invoice type code"

findet man unter

    <ram:TypeCode>380</ram:TypeCode>

Eigentlich erwarte ich eine XML-Datei idealerweise mit einem passenden PDF zum Vergleich nach folgendem Muster

    <ram: Invoicenumber >20241234</ram: Invoicenumber >

    <ram: Invoiceissuedate >20241011</ram: Invoiceissuedate >

    <ram: InvoiceTypeCode>380</ram: InvoiceTypeCode>

    <ram: Invoicecurrencycode >EUR</ram: Invoicecurrencycode >

Kannst du Licht ins dunkle bringen?

Danke Martin   

[Sam Jost]

Was ich brauche sind nicht Rechnungen ohne MwSt., sondern Rechnungen, bei denen der Einzelpreis Brutto ist und am Ende aus der Brutto-Summe die Nettopreise und MwSt. ausgerechnet werden.

So wie es bei Rechnungen für Endkunden Standard ist - der Bäcker schreibt ja keine Nettopreise auf seinen Beleg.

Problem sind die Rundungen: Wenn der Einzelpreis Brutto €9,99 ist, dann ist der Netto gerundet auf 2 Nachkommastellen €8,39

Würde ich aber €8,39 Netto in den Beleg schreiben, dann lautet der berechnete Bruttopreis €9,98 und nicht €9,99

Würde ich den Nettopreis (verkehrt) aufrunden auf €8,40, dann berechnet sich daraus der Bruttopreis zu €10,00.

Sprich, ich hab keine Chance als Preis in der Position €9,99 Brutto zu bekommen. 

Daher meine Frage: Wie kann man in ZugFerd /Factur-X eine Rechnung ausgehend von den Bruttopreisen statt den Nettopreisen erzeugen? Und natürlich mit korrekt berechneter MwSt.

Schöne Grüße

Sam

[Matthias Hanft]

Sam Jost schrieb:

>
> Daher meine Frage: Wie kann man in ZugFerd /Factur-X eine Rechnung ausgehend von den Bruttopreisen statt den Nettopreisen erzeugen? Und natürlich mit korrekt berechneter MwSt.

Meiner Meinung nach ist das nicht vorgesehen und geht daher grundsätzlich nicht.

E-Rechnungen sind ja eh nur für B2B vorgeschrieben, und da rechnet man immer
mit Nettopreisen. Ich glaube nicht, dass der Bäcker für seine "Brutto-Brötchen"
jemals E-Rechnungen ausstellen wird (und das muss er ja auch gar nicht).

Die einzige Möglichkeit für sowas könnte sein (noch nicht ausprobiert), das
Feld BT-114 "RoundingAmount" zu verwenden: "der Betrag, der dem Rechnungs-
gesamtbetrag hinzuzufügen ist, um den zu zahlenden Betrag zu runden".

Also praktisch sowas:

LineTotalAmount 8,39
TaxTotalAmount 1,59
RoundingAmount 0,01
GrandTotalAmount 9,99

Das ergibt wenigstens rechnerisch die richtige Summe. Aber schön ist das nicht
(und die Einzelpositionen brutto auszuweisen, geht sowieso nicht).

Gruß Matthias.

[Andreas Mause]

... war das nicht so, dass inzwischen Rundungsdifferenzen bei xRechnungen zugelassen sind? Hatte da was gelesen.

[Sam Jost]

Das Feld BT-114 ist für Rundungsungenauigkeiten bzgl. des bereits bezahlten (BT-113) und des noch zu zahlenden (BT-115) Betrags.

Das für Brutto/Netto-Rundungsdifferenzen zu benutzen klappte bei uns mit den Validatoren leider nicht.

Schöne Grüße

Sam

goo...@hanft.de schrieb am Montag, 14. Oktober 2024 um 10:02:46 UTC+2:

[Sam Jost]

Omoc schrieb:

> war das nicht so, dass inzwischen Rundungsdifferenzen bei xRechnungen zugelassen sind?

Wäre mir neu. Die Validatoren von ZugFerd / Factur-X beanstanden solche Rundungsdifferenzen jedenfalls ganz klar.

(X-Rechnung ist ja ein anderes Format als ZugFerd / Factur-X, aber auch da wäre mir das neu)

Schöne Grüße Sam

[Andreas Mause]

... das hier hatte ich gelesen: "Einführung von zulässigen Rundungsungenauigkeiten (englisch „Slack“). Somit führen geringe Abweichungen bei den ausgewiesenen Steuerbeträgen nicht mehr automatisch zu einem Fehler. Als gutes Beispiel kann ein Bruttopreis von 9,99€ herangezogen werden, der sich nicht als Nettopreis mit zwei Nachkommastellen und 19 % Umsatzsteuer abbilden lässt. Ein solcher Slack wird auch im Rahmen der Überarbeitung der EU-Norm zur elektronischen Rechnung thematisiert, kann jedoch vorerst nur im Profil EXTENDED genutzt werden."

[Sam Jost]

Ah, ok, Quelle scheint diese hier zu sein:  Neue-ZUGFeRD-Version-2.3-veroeffentlicht (ferd-net.de)

Das klingt tatsächlich vielversprechend - gibts da irgendwo ein praktisches Beispiel wie welche Felder dafür ausgefüllt sein müssen?

Schöne Grüße

Sam

[Sam Jost]

Haben etwas recherchiert: Es wird oft angegeben, dass man den Bruttopreis je Position in das Feld BT-148 (GrossPriceProductTradePrice) schreiben soll, aber das Feld ist laut anderer Doku für den in Shops oft "Streichpreis" genannten Netto-Preis vor Abzug eines Rabatts gedacht. 
Und den GrossPrice mit Rabatt als Brutto zu verwenden funktioniert nicht (spätestens wenn man beides kombinieren muss, also Preis abzgl. Rabatt inkl. Steuer).

Den Slack gibt es somit nur in der Summe, dort darf er scheinbar sogar bis zu 100 Cent hoch sein. 

Hat man nun aber eine fiktive Rechnung mit 101 Positionen zu je Brutto 9,99 Euro, so summiert sich der Slack auf über die erlaubte Differenz.

Ohne ein extra Feld für den Bruttopreis und davon ausgehend ein Rückwärts rechnen des Nettopreises sowohl pro Position wie auch in Summe kann das mathematisch nicht aufgehen.

In Theorie klingt das ja vielversprechend, aber ich sehe keinen Weg wie das in der Praxis funktionieren kann nur mit diesem erlaubten Slack.

Schade!

Vielen Dank für den Input!

Schöne Grüße

Sam