validator-configuration-xrechnung
validator-configuration-xrechnung copied to clipboard
itplr-kosit
Vorzeichen bei Stornorechnung (Typ 381)
Gibt es eine Spezifikation / Vorgaben / Beispiele zu Stornorechnungen (kaufm.) vor allem hinsichtlich der zu verwendenden Vorzeichen (vgl. auch https://projekte.kosit.org/xrechnung/xrechnung/-/issues/23)?
Für den Fall dass eine komplette Rechnung storniert werden soll mit dem Dokumententyp 381. Laut https://www.xoev.de/sixcms/media.php/13/XRechnung+1.1+-+30.pdf sind die Vorzeichen egal - was ich mir aber nicht vorstellen kann. Mein Verständnis ist, dass die Vorzeichen / Summen positiv sind - also die Stornorechnung identisch zur stornierten Rechnung ist und sich lediglich im Dokumententyp unterscheidet? Oder sind in der Stornorechnung negative Vorzeichen bei Beträgen bzw. Anzahl zu verwenden. Falls negativ -> welche Summen, Einzelpreise, Anzahl muss negativ und welche positiv sein?
Wir generieren Stornos wie Gutschriften, das heisst positive Einzelpreise und negative Mengenangaben. Das Resultat ist dann ein negativer Gesamtbetrag.
@phax Nein. Mein Ticket bezog sich auf UBL und kann aus meiner Sicht nicht geschlossen werden, da die Frage unbeantwortet ist. Es gibt lediglich einen Kommentar von einem anderen User der schildert wie er das macht. Es ist aber keine verlässliche Aussage das dies per Spezifikation so zu tun ist. Ich wünsche mir hier eine begründete und nachvollziehbare Antwort von "verantwortlicher" Stelle
@phax Dementsprechend das Ticket bitte wieder öffnen damit ich nicht ein weiteres anlegen muss
@griesi007 Danke für den Hinweis! Das Ticket wurde unbeabsichtigt geschlossen.
@bdewein Danke. Besteht hier die Hoffnung auf eine Antwort, nachdem das Ticket bald 2 Jahre alt ist...Ich sollte ja nicht der einzige sein der Stornorechnungen benötigt :-)
@griesi007 Informationen zu Rechnungskorrekturen sind in Kapitel 13.1 der Spezifikation XRechnung zu finden.
Der Typ 381 „Credit Note“ ist für kaufmännische Gutschriften, nicht für Rechnungskorrekturen, vorgesehen. Für Rechnungsberichtigungen (eine Stornorechnung entspricht einer 100%igen Rechnungskorrektur) wird der Dokumententyp 384 „Corrected Invoice“ verwendet. In der Rechnungskorrektur werden die Vorzeichen der Mengenangaben (BT-129 Invoiced quantity) und der Beträge, die sich aus den Berechnungen mit den negativen Mengen ergeben, umgekehrt, während die in BT-146 (Item net price) und BT-148 (Item gross price) angegebenen Preise nach zu Grunde liegender EN 16931-1 nicht negativ sein dürfen (s. BR-27 und BR-28 / Kap. 12.2 der Spezifikation). Dadurch ergibt sich bspw. für eine Originalrechnung mit positivem Gesamtbetrag eine Stornorechnung mit negativem Gesamtbetrag.
@bdewein Vielen Dank. Meine Frage bezog sich ursprünglich auf kaufm. Gutschriften. Wie verhält es sich da mit den Vorzeichen? Analog? Ich denke es wäre hilfreich wenn Sie die Regelung bzgl. Vorzeichen in der Spezifikation ergänzen könnten. Soweit ich weiß ist darüber nichts zu finden, oder irre ich mich?
@griesi007 zu den kaufmännischen Gutschriften gibt es bzgl Vorzeichen keine Vorgabe seitens XRechnung. Es gab mal einen CR, dessen Ziel der Ausschluss negativer Vorzeichen bei Code 381 war, dieser wurde aber nach intensiven Beratungen auf Ebene DIN und CEN abgelehnt, siehe https://projekte.kosit.org/xrechnung/xrechnung/-/issues/71
darum gibt es keine weiter spezifizierenden Ausführungen in der Spezifikation XRechnung
these are good explanations. However, I vote for rephrasing some passenges in the spec in order to make these statements clear. For example, we should write in the spec that Stornorechung is a 100% Rechnungskorrektur. And that there are no rules on signs for "kaufmänicshe Gutschriften".
Ich hab ja keine Ahnung und soll nur Rechnungen in einem System generieren, aber soweit mir bekannt ist, besteht noch keine wirkliche Einigkeit, wie Storno-Rechnungen (nicht kaufm. Gutschriften) abzubilden sind.
Die Dokumentation in der Spezifikation XRechnung zu dem Thema ist jedenfalls völlig unzureichend.
Validatoren meckern meistens, wenn überhaupt irgendwelche Zahlen negativ sind. Und diejenigen unserer Kunden, die bereits mit ZUGFeRD-Rechnungen arbeiten, erwarten, dass bei Storno-Rechnungen abgesehen vom anderen Type-Code 384 statt 381 und dem deutlichen Hinweis auf die Stornierung (inkl. Verweis auf die ursprüngliche Rechnungsnummer und -datum) bezüglich der Zahlen genau so aussehen soll (inkl. Vorzeichen) wie die Originalrechnung.
@hvbtup @griesi007 Aus meiner Sicht ist die Dokumentation dazu klar, allerdings habe ich auch etwas Zeit benötigt, sie zu finden. Unter https://www.e-rechnung-bund.de/faq/e-rechnung/ steht dazu:
Wie sind Gutschriften und Rechnungskorrekturen anzugeben?
Im Bereich der Rechnungserstellung kann es notwendig sein, unterschiedliche Formen einer Gutschrift beziehungsweise einer Rechnungskorrektur auszuweisen. Die elektronische Rechnung erleichtert die Interpretation der enthaltenen Rechnungsdaten bereits durch Auswertung des Rechnungstyps im Feld BT-3:
Rechnungsberichtigung: Eine bereits übermittelte Rechnung muss korrigiert oder storniert werden. Hierzu wird eine Gutschrift ausgesprochen. Code in BT-3: „384“ (corrected invoice) Anmerkung: Eine Referenz auf die zu korrigierende Rechnungsgrundlage ist anzugeben (PRECEDING INVOICE REFERENCE, BG-3).
Kaufmännische Gutschrift: Dem Rechnungssteller wird unabhängig von vorhergehenden Rechnungen eine Gutschrift oder ein Gutschein zugeschrieben. Dies kann z.B. der Fall sein, wenn ein bestimmter Kunde in einem bestimmten Zeitraum ein gewisses Umsatzvolumen erzielt hat, was nun zur Erstattung oder Gutschrift führt. Code in BT-3: „381“ (credit note) Anmerkung: In diesem Fall sollte der Rechnungsbetrag kein zusätzliches negatives Vorzeichen tragen.
Vom Leistungsempfänger selbst erstellte Gutschrift: Der Leistungsempfänger erstellt eine Gutschrift gemäß § 14 Abs. 2 Satz 2 Umsatzsteuergesetz, bei der es sich um die Abrechnung einer Lieferung oder Leistung handelt. Code in BT-3: „389“ (self billed invoice)
So haben wir es bei uns auch umgesetzt:
- Bei einer Rechnungskorrektur verwenden wir Typ 384 (corrected invoice) mit Angabe der Nummer der ursprünglichen Rechnung. In diesem Fall werden die Beträge der Positionen mit negativem Vorzeichen angegeben, also ist auch der Rechnungsbetrag negativ. Das haben wir aus der Aussage bei Typ 381 geschlossen: "Anmerkung: In diesem Fall sollte der Rechnungsbetrag kein zusätzliches negatives Vorzeichen tragen."
- Bei einer kaufmännischen Gutschrift (teilweise auch als "Gutschein" bezeichnet) verwenden wir Typ 381 (credit note) und die Beträge sind positiv.
- Bei einer Eigenrechnung (Gutschrift gemäß § 14 Abs. 2 Satz 2 Umsatzsteuergesetz) verwenden wir Typ 389 (self billed invoice) mit positiven Beträgen.
Das gilt v.a. für XRechnung mit CII-Syntax. Bei XRechnung in UBL-Syntax gibt es geringe Abweichungen: Bei UBL gibt es für die kaufmännische Gutschrift ("Gutschein", ohne Bezug auf eine vorherige Rechnung) ein eigenes Schema (UBL-CreditNote-2.1.xsd). Für Rechnungskorrektur ist das Rechnungs-Schema (UBL-Invoice-2.1.xsd) unter Angabe des Typ 384 (corrected invoice) zu verwenden.
Hoffe, das hilft weiter.
BTW: In Österreich (ebInterface 6.1) ist es übrigens explizit erklärt, dass bei einer Rechnungskorrektur mit bezognener Belegnummer der Typ "SubsequentCredit" verwendet wird und die Beträge positiv sein müssen.
OK, also wenn ich richtig verstehe:
- Storno-Rechnung = vollständige Rechnungskorrektur ...
- ... und man stellt am besten später nochmal eine neue Rechnung (ohne expliziten Bezug auf die ursprüngliche-Rechnung oder die Storno-Rechnung) für die Leistungen.
- Bei den Positionen dreht man nur das Vorzeichen der Mengenangabe um. Durch die Berechnung dreht sich dann auch das Vorzeichen des Gesamtpreises (der Position) um.
- Rabatte auf Positionsebene beziehen sich (jedenfalls so, wie wir rechnen) auf den Einzelpreis. Da braucht man nichts ändern.
- Aber was ist mit Rabatten und Zuschlägen auf Rechnungsebene?
Ich würde vermuten, dass hier theoretisch auch nichts geändert werden muss, zumindest wenn mit prozentualen (und nicht absoluten) Rabatten gerechnet wird, da z.B. 20% Rabatt auf -100€ einen Abzug von -20€ bedeuten. Wenn man so rechnet, müsste alle Beträge und Summen (inkl. Steuern) am Ende genau den Zahlen aus der ursprünglichen Rechnung mal -1 entsprechen. Aber: Dann muss auch darauf achten, dass man beim Runden im Zweifel immer von 0 weg rundet, also bei negativen Zahlen abrundet statt aufrundet.
Einfaches Beispiel: Ursprüngliche Rechnung: ohne MWSt, nur 1 Posten von 0,10 €. Mit dem Kunden sind 25% Rechnungsrabatt vereinbart. Rabattberechnung: 25% von 0,10 € sind 0,025 €. Gerundet auf volle Cent 0,03 €. Zieht man diese ab, hat man eine Gesamtsumme von 0,07 €.
Storno-Rechnung dafür: Für die Positionen Menge -1, Einzelpreis 0,10 €, ergibt eine Summe von -0,10 €. Rabattberechnung: 25% von -0,10 € sind -0,025 €. Gerundet auf volle Cent sind das je nach Art der Rundung -0,03 € oder -0,02 €. Und wenn man diese abzieht, ergeben sich entsprechend -0,07 € oder (falsch) -0,08 €. Wenn die Software bei 0,005 € immer aufrundet (auch bei negativen Beträgen) kommt also etwas Falsches heraus.
Nachtrag: Wenn man z.B. in einer Oracle-DB mit NUMBER Feldern so rechnet, dann passt es. Hab genau dieses Beispiel ausprobiert.
OK, also wenn ich richtig verstehe:
* Storno-Rechnung = vollständige Rechnungskorrektur ... * ... und man stellt am besten später nochmal eine neue Rechnung (ohne expliziten Bezug auf die ursprüngliche-Rechnung oder die Storno-Rechnung) für die Leistungen. * Bei den Positionen dreht man nur das Vorzeichen der Mengenangabe um. Durch die Berechnung dreht sich dann auch das Vorzeichen des Gesamtpreises (der Position) um. * Rabatte auf Positionsebene beziehen sich (jedenfalls so, wie wir rechnen) auf den Einzelpreis. Da braucht man nichts ändern. * _Aber was ist mit Rabatten und Zuschlägen auf Rechnungsebene?_Ich würde vermuten, dass hier theoretisch auch nichts geändert werden muss, zumindest wenn mit prozentualen (und nicht absoluten) Rabatten gerechnet wird, da z.B. 20% Rabatt auf -100€ einen Abzug von -20€ bedeuten. Wenn man so rechnet, müsste alle Beträge und Summen (inkl. Steuern) am Ende genau den Zahlen aus der ursprünglichen Rechnung mal -1 entsprechen. Aber: Dann muss auch darauf achten, dass man beim Runden im Zweifel immer von 0 weg rundet, also bei negativen Zahlen abrundet statt aufrundet.
Einfaches Beispiel: Ursprüngliche Rechnung: ohne MWSt, nur 1 Posten von 0,10 €. Mit dem Kunden sind 25% Rechnungsrabatt vereinbart. Rabattberechnung: 25% von 0,10 € sind 0,025 €. Gerundet auf volle Cent 0,03 €. Zieht man diese ab, hat man eine Gesamtsumme von 0,07 €.
Storno-Rechnung dafür: Für die Positionen Menge -1, Einzelpreis 0,10 €, ergibt eine Summe von -0,10 €. Rabattberechnung: 25% von -0,10 € sind -0,025 €. Gerundet auf volle Cent sind das je nach Art der Rundung -0,03 € oder -0,02 €. Und wenn man diese abzieht, ergeben sich entsprechend -0,07 € oder (falsch) -0,08 €. Wenn die Software bei 0,005 € immer aufrundet (auch bei negativen Beträgen) kommt also etwas Falsches heraus.
Nachtrag: Wenn man z.B. in einer Oracle-DB mit NUMBER Feldern so rechnet, dann passt es. Hab genau dieses Beispiel ausprobiert.
Als Ergänzung zum Storno: für eine Stornorechnung gibt es aktuell keinen eigenen Rechnungstyp in der zugrundeliegenden Codeliste UNTDID 1001, darum der Umweg über die 100% Rechnungskorrektur mit Dokumententyp 384 wie im FAQ des Bundes beschrieben.
Zur Rundung haben wir einen eigenen Abschnitt unter https://xeinkauf.de/faq/xrechnung#rundung
Seitens CEN sind in den Schematrons die allermeisten Rundungsprobleme mittlerweile behoben worden. Sollten dennoch Rundungsprobleme auftreten so bitten wir um Zusendung der Rechnung nebst Prüfbericht an [email protected] oder um ein neues Ticket, da dieses Ticket hier bereits seit Oktober 2022 inhaltlich abgeschlossen ist aber leider nicht geschlossen wurde.
@hvbtup ich empfehle bei einer 100% Stornorechnung überhaupt nicht zu rechnen, sondern einfach die Menge und die relevanten zusammenfassenden Beträge aus der ursprünglichen Rechnung 1:1 zu übernehmen und zu negieren. Dadurch ist gewährleistet, dass keine Rundungsfehler entstehen können und die Stornorechnung wirklich zu 100% ein Storno der zugrundeliegenden Rechnung ist
Das geht natürlich auch, aber einfach ist das nur möglich, wenn man diese Beträge (auch im Einzelnen) tatsächlich alle gespeichert hat. Das ist bei uns nicht der Fall, wir speichern nur die Ausgangswerte für die Berechnung.
@hvbtup Das Speichern der Beträge hat hinsichtlich "Unveränderlichkeit" etliche Vorteile. Dadurch kann jederzeit in der Applikation immer derselbe Zustand angezeigt werden, auch wenn es später mal zu Änderungen der Berechnungslogik etc. kommen sollte. Hat sich bei uns seit Jahren bewährt. Ab dem Zeitpunkt ab dem die Rechnung versandt wurde, ist sie unveränderlich und es werden mit den gespeicherten Beträgen keine Berechnungen mehr angestellt.
Das wäre auch mein Plan gewesen, wenn ich auf der grünen Wiese anfangen könnte. Aber die Software läuft so seit deutlich über 30 Jahren, da sind solche grundlegenden Änderungen am Datenmodell nicht auf die Schnelle zu machen.
Hi,
gibt es hierzu eine akzeptierte Lösung, im Sinne von: die Validatoren lassen eine vollständige Stornorechnung auch passieren? Anbei ein Beispiel welches m.E. valide sein sollte bzw. dem entspricht, was hier diskutiert wurde. Dennoch schlagen verschiedene Validatoren fehl. Vielleicht übersehe ich aber auch etwas, jedenfalls haut die Steuerberechnung nicht mehr hin mit negativen Vorzeichen.
<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>PP-22018000106</cbc:ID>
<cbc:IssueDate>2018-09-24</cbc:IssueDate>
<cbc:DueDate>2018-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<cbc:Note>Folgende Lieferungen/Leistungen schreiben wir Ihnen gut.</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>12345678-12345-83</cbc:BuyerReference>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>PP-22018000105</cbc:ID>
<cbc:IssueDate>2018-09-24</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:AccountingSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="EM">[email protected]</cbc:EndpointID>
<cac:PartyName>
<cbc:Name>Seller Name</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Street 1</cbc:StreetName>
<cbc:CityName>Berlin</cbc:CityName>
<cbc:PostalZone>12345</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>DE 123 456 789</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Seller Company</cbc:RegistrationName>
<cbc:CompanyID>HR A 123</cbc:CompanyID>
<cbc:CompanyLegalForm>Vorstand: Mr. Seller</cbc:CompanyLegalForm>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Assistant</cbc:Name>
<cbc:Telephone>1234567890</cbc:Telephone>
<cbc:ElectronicMail>[email protected]</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="EM">N/A</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName>Kaulerstr. 23</cbc:StreetName>
<cbc:CityName>Berlin</cbc:CityName>
<cbc:PostalZone>12345</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>DE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Peter Pan</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>
<cac:Delivery>
<cbc:ActualDeliveryDate>2018-09-24</cbc:ActualDeliveryDate>
</cac:Delivery>
<cac:PaymentMeans>
<cbc:PaymentMeansCode>68</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID>DE1234567890</cbc:ID>
<cbc:Name>Seller Company</cbc:Name>
<cac:FinancialInstitutionBranch>
<cbc:ID>BANKDE</cbc:ID>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">-2.87</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="EUR">-15.13</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="EUR">-2.87</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>19.0</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">-15.13</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">-15.13</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">-18.00</cbc:TaxInclusiveAmount>
<cbc:PrepaidAmount currencyID="EUR">0.00</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="EUR">-18.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
<cac:InvoiceLine>
<cbc:ID>1</cbc:ID>
<cbc:InvoicedQuantity unitCode="C62">-2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">15.13</cbc:LineExtensionAmount>
<cac:Item>
<cbc:Name>Museumsinsel ermäßigt</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>T-1</cbc:ID>
</cac:SellersItemIdentification>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>19.0</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">7.56</cbc:PriceAmount>
<cbc:BaseQuantity>1</cbc:BaseQuantity>
</cac:Price>
</cac:InvoiceLine>
</ubl:Invoice>
Fehler aus einem Validator (https://erechnungsvalidator.service-bw.de/):
| Pos | Code | Adj. Grad | Text |
|---|---|---|---|
| val-sch.1.1 | BR-S-08 | error | [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is "Standard rated" and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). |
| Pfad: /ubl:Invoice/cac:TaxTotal[1]/cac:TaxSubtotal[1]/cac:TaxCategory[1] | |||
| val-sch.1.2 | BR-CO-10 | error | [BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131). |
| Pfad: /ubl:Invoice/cac:LegalMonetaryTotal[1] | |||
| val-sch.2.1 | PEPPOL-EN16931-R120 | error | |
| Pfad: /ubl:Invoice/cac:InvoiceLine[1] |
Für den InvoiceTypeCode 384 (Credit note) muss eine UBL CreditNote mit positiven Vorzeichen erstellt werden
Guten Morgen @phax ,
der InvoiceType 384 ist eine Korrekturrechnung (Correction Invoice). Laut Kosit ist das auch so zulässig:
https://www.xoev.de/sixcms/media.php/13/XRechnung+1.1+-+30.pdf
Habe meinen Fehler gefunden. Der Validator lässt die Datei zu, wenn LineExtensionAmount der Rechnungsposition auch negativ ist. Kurzum, mein Beispiel von oben funktioniert mit
<cbc:LineExtensionAmount currencyID=\"EUR\">-15.13</cbc:LineExtensionAmount>
Ah ja - sorry. Habe die Codes durcheinander gebracht. Du hast die Lösung eh schon gefunden. Statt
<cbc:InvoicedQuantity unitCode="C62">-2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">15.13</cbc:LineExtensionAmount>
setze die LineExtensionAmount negativ und die InvoicedQuantity positiv.
<cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">-15.13</cbc:LineExtensionAmount>
Evtl. muss dann auch noch der PriceAmount angepasst werden:
<cac:Price>
<cbc:PriceAmount currencyID="EUR">7.56</cbc:PriceAmount>
Ah ja - sorry. Habe die Codes durcheinander gebracht. Du hast die Lösung eh schon gefunden. Statt
<cbc:InvoicedQuantity unitCode="C62">-2</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">15.13</cbc:LineExtensionAmount>setze die LineExtensionAmount negativ und die InvoicedQuantity positiv.
<cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity> <cbc:LineExtensionAmount currencyID="EUR">-15.13</cbc:LineExtensionAmount>
Bei Rechnungskorrekturen werden die Vorzeichen der Mengenangaben und der sich daraus ergebenden Beträge umgekehrt. Im obigen Beispiel sollten sich daher die Vorzeichen von BT-129 "Invoiced quantity" und BT-131 "Invoice line net amount" entsprechen, um nicht gegen die Regel PEPPOL-EN16931-R120 "Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount":
<cbc:InvoicedQuantity unitCode="C62">-2</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="EUR">-15.13</cbc:LineExtensionAmount>
Evtl. muss dann auch noch der
PriceAmountangepasst werden:<cac:Price> <cbc:PriceAmount currencyID="EUR">7.56</cbc:PriceAmount>
Die in BT-146 (Item net price) und BT-148 (Item gross price) angegebenen Preise dürfen nicht negativ sein.
Korrekt. Obriges Beispiel ist valide, wenn nun LineExtensionAmount auch negativ ist. Hoffe, das Beispiel hilft auch anderen, weil es kein explizites Beispiel in den offiziellen Repos dafür gibt.
PS: Please note, that in the upcoming EN16931-1 revision, the Credit Note total will no longer allowed to be negative. It was decided in the CEN ballot last summer.
Internal CEN reference: question 7 - bullet 13 and/or internal GitHub issue 80
Der Code 384 sagt doch aus, dass es sich um eine "Corrected Invoice" handelt. Eine korrigierte Rechnung ist doch nicht automatisch ein Vollstorno. Natürlich gibt es Fälle, in denen ein Vollstorno notwendig ist, aber ich lese immer wieder von der Vorgehensweise, ein Vollstorno durchzuführen und mit einer vollständig neuen Rechnung zu korrigieren.
Wenn es aber bspw. nur die falsche Liefermenge ist, kann das dann nicht in einer 384-Rechnung erledigt werden? Natürlich birgt das wieder das Risiko, dass man eine 384-Rechnung selbst auch wieder korrigieren können muss (bei einem Vollstorno könnte man eine Korrektur des Vollstorno prozesstechnisch unterbinden - wäre ja unsinnig).
Was ist nun gelebtes Best Practise, wenn es um marginale Korrekturen (wie Artikelmengen) geht? Eine einzelne 384 mit dem Risiko, dass anschließende 384er folgen könnten, oder doch ein 384-Vollstorno und eine neue 380-Rechnung?
Mit einer Corrected Invoice (Type Code 384) kann eine Rechnung entweder teilweise oder vollumfänglich korrigiert werden. Letzteres würde einer Stornorechnung entsprechen.
Bitte beachten Sie, dass die oben eingefügten Screenshots der Spezifikation XRechnung in der Version 1.1 entnommen sind. Die aktuelle Version von XRechnung ist 3.0, die Informationen zu Rechnungskorrekturen und Gutschriften in der Spezifikation XRechnung wurden inzwischen überarbeitet.
Wir möchten Sie bitten, an dieser Stelle keine weiteren Kommentare zu posten. Dieses Ticket ist bereits seit zwei Jahren geschlossen, zudem hat sich die Diskussion inzwischen von der ursprünglichen Fragestellung entfernt. Darüber hinaus sollten Tickets in diesem Repository ausschließlich für Fehlermeldungen und Korrekturvorschläge genutzt werden, die Bezug auf den Source Code von validator-configuration-xrechnung nehmen. Bitte haben Sie daher Verständnis, dass die KoSIT an dieser Stelle keine weiteren Diskussionen zu fachlichen und Anwendungsfragen moderieren wird. Diese sollten in dafür vorgesehenen Foren diskutiert werden. Sie können für fachliche Fragen auch unser Postfach [email protected] nutzen.
With a corrected invoice (type code 384), an invoice can be either partially or fully corrected. The latter would be equivalent to a cancelation invoice.
Please note that the above screenshots are taken from the outdated specification XRechnung in version 1.1. The current version of XRechnung is 3.0, the information on invoice corrections and credit notes has since been revised.
We would kindly ask you to not post further comments, here. This issue has been closed for two years, and the discussion has since moved away from the original question. Furthermore, issues in this repository should only be used for error notifications or suggestions of improvement in reference to the source code of validator-configuration-xrechnung. Please understand that KoSIT will not moderate any further discussions on normative and application issues here. These should be discussed in forums provided for this purpose. You can also send mails to [email protected] for questions on the Standard XRechnung.