Vielen Dank für Ihre Frage! Das Problem ist bekannt und liegt zunächst nicht im Standard XRechnung begründet. Vielmehr ist es so, dass das der XRechnung zugrunde liegende Normenwerk EN16931 in den entsprechenden Syntaxmapping (CEN/TS 16931-3-3 – Electronic invoicing – Part 3-3: Syntax binding for UN/CEFACT XML Industry Invoice D16B) für die BG-3 PRECEDING INVOICE REFERENCE die Kardinalität normativ auf 0..1 festlegt. Aktuell wird der Fehler auf CEN-Ebene thematisiert, allerdings ist nicht von einer kurzfristigen Lösung auszugehen. Das Referenzieren von mehreren vorangegangenen Rechnungen ist in UBL-Syntax möglich.

Erstmal danke für ihre Antwort! Leider enthält ihre Antwort keine neuen Informationen für mich. Das Problem ist seit Jahren bekannt. Ich verstehe, dass das Problem in EN16931 und CII herrscht. Wird die Kosit/XRechnung mal etwas Druck auf europäischer Ebene machen? Für mich bedeutet es, dass in manchen Konstellationen nur UBL funktionieren wird. Die Kosit sollte evtl. explizit darauf aufmerksam machen. ZUGFeRD funktioniert aktuell nur mit CII, also können mit einer ZUGFeRD-Datei nicht alle Möglichkeiten einer Rechnung(XRechnung) abgedeckt werden. Vllt sollte Kosit auch nur noch das UBL-Format unterstützen.

Toll! Version 2.3 löst das Problem aber nicht vollständig.
BT-26 hat die Kardinalität 1..*.
Wieso 1 und wieso * ?

Da die EN16931 die Kardinalität auf 0..1 definiert, sind jegliche Änderungen der Syntax schön, aber helfen nicht wirklich.
In einem CIUS kann der niedere Teil der Kardinalität erhöht, bzw. der obere Teil verringert werden. Alle Änderungen wären eine Extension.

Grundsätzlich sind Extensions mit Vorsicht zu genießen, da sie eine bilaterale Abstimmung bedürfen. Ein CIUS hat ja den Vorteil, dass er von jedem Empfänger der die EN empfangen kann, ohne vorherige Abstimmung empfangen kann. Daher sind CIUS immer Extensions vorzuziehen, wenn es um einen breiten Einsatz geht.

Danke für die ausführliche Antwort und die neuen Informationen! Ich gehe davon aus, dass das semantische Datenmodell der EN16931 und das CII-Mapping angepasst werden. Wenn ich ihre Ausführungen richtig verstehe, dann wird wohl erst die XRechnung Version für Februar 2026 die Änderungen erhalten?
Kosit/XRechnung veröffentlicht 2x pro Jahr eine neue Version, die dann ab Februar bzw. August gültig sind. Wenn erst im Sommer 2025 die Revision der Semantik übernommen wird und danach das Syntax-Binding angepasst wird, dann kann eigentlich nur die XRechnung Version für Februar 2026 die Änderungen erhalten. Ich freue mich, dass an dem Problem gearbeitet wird. Aber leider wird die Lösung noch etwas auf sich warten lassen.
Falls meine Annahmen falsch sind, bitte korrigieren Sie mich.

Das kürzlich veröffentlichte ZUGFeRD 2.3 / Factur-X 1.0.07 Release hat die CII-Syntax auf die neuere Version D22B aktualisiert, die vollständig abwärtskompatibel zu D16B ist. Diese Version behebt das Problem der Kardinalität der BG-3 PRECEDING INVOICE REFERENCE und rückt damit näher an das semantische Modell der EN16931 heran (siehe Pressrelease). Theoretisch könnte die XRechnung dem folgen, aber offiziell steht D16B noch als Version im Amtsblatt der Europäischen Union, auch wenn D22B richtiger wäre. Der CEN/EC Process ist (noch) nicht auf Software ausgelegt. 🙄 Die CEN Prozesse erscheinen zu langsam und Ergebnisse nicht öffentlich einsehbar. Die EN16931-1 Amendments wurden dazu noch abgelehnt, aber wir hoffen die Revision der Semantik Mitte nächsten Jahres zu veröffentlichen. Das Syntax Binding wird dann "etwas später" auf die aktuellsten Syntaxen angepasst. (Dies sind persönliche Einschätzungen ohne jegliche Gewähr 🤗).

PS: Und wenn es schneller gehen soll, gerne aktiv werden: Einfach dem DIN-Ausschuss "Elektronisches Geschäftswesen" beitreten (gegen eine Gebühr von 400€ bis 1300€, um dort mitzuarbeiten), sich anschließend ins CEN TC 434 entsenden lassen und Zeit sowie Engagement einbringen. Dann geht es "vielleicht" auch etwas schneller! 😎

PPS: Übrigens das ZUGFeRD Extended Profil eignet sich besonders für anspruchsvollere B2B-Rechnungen, wie es beispielsweise die Firma Würth bereits vorbildlich einsetzt.

Toll! Version 2.3 löst das Problem aber nicht vollständig. BT-26 hat die Kardinalität 1..*. Wieso 1 und wieso * ?
Das ist zwar etwas offtopic zu BG-3, aber ich möchte es dennoch kurz beantworten:

Ich bin erst seit 2019 co-editor beim EN16931 geworden, die Fehler die zuvor eingebaut worden sind werde ich versuchen bis Mitte nächsten Jahres im Syntax Binding zu fixen. 🤗

Schauen wir uns die Semantik an, ein Auszug aus dem Schaubild der XRechnung 3.0.2 Seite 26:

In CII D22B hat das CII XML Element für BG-3 auch die Kardinalität 0..n wie die Semantik (der gelbe Kasten oben)
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument

Das im gelben Kasten befindliche BT-26 hat in CII das XML Element und das XML wird mit einer Kardinalität von 1..1 angegeben:
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument/ram:FormattedIssueDateTime/qdt:DateTimeString

Aber schaut mal, da wurden 2 Elemente hinzugefügt und das darüberliegende Element
<ram:FormattedIssueDateTime> hat eine Kardinalität von 0..1 (hier das XSD aus dem extended Profile von ZUGFeRD 2.3)

(Zur Erinnerung: Wenn XSD keine Kardinalität erwähnt ist der Default von 1 gegeben.)

Ich bezog mich mit meiner Anmerkung auf die Version 3.0.1, womit die wohl veraltet war.

Jetzt habe ich mir die Version 3.0.2 gezogen und sage schon mal danke für die Korrektur.

Neue Frage im Zusammenhang:

Wenn ich für eine Schlussrechnung (Endrechnung) vorangegangene Abschlagszahlungen oder Anzahlungen aufführen muss, welchen Ort soll ich dafür wählen? Die Frage ist hierzu auch, wie ist UStG §14 (5) aufzufassen. Im Netz findet man weitgehend die Auffassung, dass jede Zahlung einzeln mit Datum, Betrag und MwSt. aufzuführen ist. Dass ich die Gesamtsumme per BT-113 übergeben kann ist mir natürlich bekannt. Wenn die Angabe der Gesamtsumme gesetzlich ausreichend ist, erübrigt sich meine Frage.

vg

Für jedes Thema bitte einen eigenen Issues - sonst wird's schwierig - danke

Ich möchte meine Auffassung noch etwas konkretisieren.

Einer Anzahlung oder einer Abschlagszahlung liegt gemeinhin eine entsprechende Anzahlungsrechnung oder Abschlagsrechnung zugrunde. Diese Begriffe können aber keinesfalls synonym verwendet werden. Gerade im Bauwesen kann man froh sein, wenn man auf den Betrag einer Abschlagsrechnung eine Abschlagszahlung bekommt.

Eigentlich kann ich keinen Zweck für die n-Kardinalität von BG-3 erkennen. Stattdessen fehlt ein Gruppe PRECEDING PAYMENT REFERENCE mit der Kardinalität 0 .. n. Das Analog in CII wäre dafür der Node SpecifiedAdvancePayment.

Es gibt hier also einen starken Zusammenhang mit dem aktuellen Thema des Threads.

vg

Zunächst zur ursprünglichen Fragestellung: das semantische Datenmodell der EN 16931, auf dem XRechnung als CIUS der EN basiert, sieht für BG-3 eine Kardinalität von 0..* vor. Dies ist in der Version D21B von CII, auf die die aktuelle Version der EN 16931 referenziert und für die das Syntaxmapping in CEN/TS 16931-3-3:2017 Electronic invoicing – Part 3-3: Syntax binding for UN/CEFACT XML Cross Industry Invoice D16B definiert wurde, nicht umsetzbar.
XRechnung als CIUS der EN 16931 muss gemäß der normativen Vorgaben beide Syntaxen unterstützen.
Das Problem ist, wie bereits festgestellt wurde, schon länger bekannt und wird behandelt (dass solche Prozesse auf Normungs-/Standardisierungsebene etwas langwieriger sein können, liegt in der Natur der Sache).
Die Lösungsmöglichkeiten innerhalb von XRechnung sind begrenzt. Um BG-3 in CII wie UBL einheitlich abbilden zu können, müsste die Kardinalität von BG-3 für das semantische Datenmodell eingeschränkt werden, somit würde eine Einschränkung, die innerhalb einer Syntax besteht, auf die semantische Ebene transferiert und damit allgemeingültig. Aktuell ist für XRechnung keine derartige Anpassung vorgesehen.

Änderungen am semantischen Datenmodell oder anderer normativer Vorgaben (wie z.B. der referenzierten Version einer Syntax) der EN 16931, welche derzeit im Hinblick auf die Anforderungen aus dem B2B-Bereich überarbeitet wird, werden nach deren Veröffentlichung in XRechnung umgesetzt werden. Normative Versionen von XRechnung (welche Änderungen am semantischen Datenmodell enthalten) können am 31.1. und 31.7. eines Jahres veröffentlicht werden und treten nach einer Übergangsfrist von 6 Monaten in Kraft. Sie liegen also richtig in der Annahme, dass nicht von kurzfristigen Anpassungen auszugehen ist.

Nun ein allgemeiner Hinweis: zur Wahrung der Übersichtlichkeit nutzen Sie bitte dieses Repository für Themen, die technische Fragestellungen den Standard XRechnung betreffen. Für fachliche Fragen bezüglich XRechnung kann das Funktionspostfach [email protected] genutzt werden. Sofern diese normative Aspekte der EN 16931 betreffen, kann die KoSIT dabei unterstützen, Fragestellungen in den entsprechenden Gremien einzubringen. Für technische Fragen bezüglich der CEN-Schematron Regeln nutzen Sie bitte https://github.com/ConnectingEurope/eInvoicing-EN16931. Diskussionen zu Formaten, die nicht in den Zuständigkeitsbereich der KoSIT fallen (z.B. ZUGFerD), sollten in den dafür vorgesehenen Foren erfolgen und werden hier ggf. gelöscht werden.

Toll! Version 2.3 löst das Problem aber nicht vollständig. BT-26 hat die Kardinalität 1..*. Wieso 1 und wieso * ?

Hier handelt es sich um einen editoriellen Fehler in der Spezifikation XRechnung, der mit der Version XRechnung 3.0.2 korrigiert wurde.

Okidoki & Danke

Ich habe mein Anliegen jetzt mal an die genannte Mail-Adresse geschickt.

vg

Okidoki & Danke

Ich habe mein Anliegen jetzt mal an die genannte Mail-Adresse geschickt.

vg

Danke :)

Zunächst zur ursprünglichen Fragestellung: das semantische Datenmodell der EN 16931, auf dem XRechnung als CIUS der EN basiert, sieht für BG-3 eine Kardinalität von 0..* vor. Dies ist in der Version D21B von CII, auf die die aktuelle Version der EN 16931 referenziert und für die das Syntaxmapping in CEN/TS 16931-3-3:2017 Electronic invoicing – Part 3-3: Syntax binding for UN/CEFACT XML Cross Industry Invoice D16B definiert wurde, nicht umsetzbar.

Kurze Korrektur zu Deinem Text: In EN16931 wird D16B verwendet und nicht D22B.

Wie in meinem von Dir gelöschten Kommentar erwähnt, schreibt das Amtsblatt der Europäischen Union L266 von 2017 dies vor.
Außerdem wäre, wie ebenfalls dort erwähnt, die Lösung für das BG-3-Problem im CII für Euch möglich, indem ihr auf D22B aktualisiert, um näher am semantischen Modell der EU-eRechnung zu bleiben. Es wäre wünschenswert, wenn das Amtsblatt klargestellt hätte, dass auch spätere, kompatible Versionen zulässig wären und die Technical Advisory Group solche Versionen listen könnte.