Maßeinheiten in XRechnung – BT-130 und BT-150
Eine Herausforderung bei der Umsetzung der XRechnung Spezifikation für ERP Hersteller kann die Einbindung von Maßeinheiten via Codelisten sein. Oftmals definieren Kunden frei ihre eigenen Einheiten, was die Übertragung auf Codelisten sehr schwierig macht.
Üblicherweise werden zu Rechnungspositionen Mengen und Maßeinheiten angegeben, sodass der Empfänger weiß auf welcher Grundlage die Position berechnet wurde. Die beiden Felder BT-130 und BT-150 der XRechnung Spezifikation bilden genau das ab, mit mehr oder minder gültigen Vorgaben zu deren Inhalt. Wir erklären kurz, wie die Felder spezifiziert und zu befüllen sind, sowie wie die finaX XRechnung API die Verwendung der Felder löst.
Die Spezifikation für E-Rechnung Maßeinheiten. Codelisten oder Freitext
Der Auszug aus der Spezifikation Standard XRechnung 3.0.2 vom 20.06.2024 zu BT-130:
Die für die “Invoiced quantity” (BT-129) geltende Maßeinheit. Die Maßeinheit muss unter Anwendung der in UN/ ECE Rec No 20 Intro 2.a) beschriebenen Methode aus den Listen UN/ECE Recommendation No. 20 „Codes for Units of Measure Used in International Trade“ und UN/ECE Recommendation No 21 „Codes for Passengers, Types of Cargo, Packages and Packaging Materials (with Complementary Codes for Package Names)“ ausgewählt werden.
Die Maßeinheit muss also aus einer der beiden Listen (”Codes for Units of Measure Used in International Trade” oder “Codes for Passengers, Types of Cargo, Packages and Packaging Materials…” gewählt werden. Weiterhin besagt diese Spezifikation:
In den meisten Fällen ist es nicht erforderlich, dass Verkäufer und Erwerber diese Listen vollständig in ihren Anwendungen implementieren. Verkäufer müssen nur die erforderlichen Einheiten für ihre Güter und Dienstleistungen unterstützen. Erwerber überprüfen lediglich, ob die in der Rechnung verwendeten Einheiten mit denen in anderen Dokumenten zum Erwerb (wie z. B. Vertrag, Katalog, Bestellung oder Lieferschein) identisch sind.
Die Implementierung der vollständigen Listen ist nicht notwendig. Da wir bei finaX für Kunden aus allen Industrien Rechnungen erzeugen, müssen wir auch die kompletten Codelisten zur Verfügung stellen.
Die Validierung von Maßeinheiten von XRechnungen mit KoSIT Validator
So streng die Spezifikation klingt – die Realität verhält sich etwas anders. Die tatsächliche Validierung via des offiziellen KoSIT Validators ist etwas nachsichtiger mit Maßeinheiten.
Zuerst ein Beispiel zu einer Einheit aus den offiziellen Codelisten – Kilogramm – Code “KGM”. Wir erstellen eine Beispielrechnung und validieren diese. Das Ergebnis – die Rechnung ist konform und kann weiterverarbeitet werden:
Nun erstellen wir eine Rechnung mit einer von uns gewählten freien Einheit “Packung”. Die Rechnung enthält nun 2 Fehler: Die Felder BT-130 und BT-150 sind nicht mit Codes aus den beiden Listen befüllt. Nichtsdestotrotz lautet die Bewertung: “Es wird empfohlen das Dokument anzunehmen und zu verarbeiten, da die vorhandenen Fehler derzeit toleriert werden.” Die freien Einheiten in den Textfeldern werden also aktuell toleriert. Wie lange dies so bleibt ist uns aktuell nicht bekannt.
Freie Maßeinheiten mit finaX XRechnung API
finaX befürwortet generell eine strenge Einhaltung der XRechnung Spezifikation. Zusammen mit unseren Kunden haben wir jedoch eine Möglichkeit erarbeitet die Validierung für Maßeinheiten etwas aufzulockern: Der Validation Mode
.
Ab Version 1.4.17
der finaX API ist es möglich den Parameter validation_mode
zu übergeben, welcher entweder strict
oder lax
sein kann. strict
ist hierbei der Standardwert, falls der Parameter nicht übergeben wird.
Wird nun eine freie Maßeinheit verwendet, wird zunächst folgende Meldung zurückgegeben:
{
"detail": [
{
"field": "invoice_line[0].invoiced_quantity_unit_of_measure_code",
"message": "Value error, Invalid invoiced_quantity_unit_of_measure_code 'Packung'. Use enum or set valiation mode to 'lax'.",
"type": "value_error",
"value": "Packung"
}
]
}
Übergibt man nun zusätzlich den Parameter "validation_mode": "lax"
wird die Validierung zugunsten der freien Verpackungseinheiten gelockert und es wird ein XML mit folgenden Parametern erzeugt:
Die Details zum Validation Mode sind auch nochmal in unserer Dokumentation erläutert.
finaX und Feedback
Die Umsetzung des lax
Validierungsmodus haben wir mithilfe des Feedbacks unserer Kunden umgesetzt und nun bereits im Einsatz. Wir nehmen das Feedback unserer Kunden ernst und helfen ihnen einfach und unkompliziert XRechnungen mithilfe unserer API zu erzeugen.