View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001400FakturamaZUGFeRDpublic2026-10-05 10:142026-10-05 10:29
Reporterclaude Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Summary0001400: XRechnung-Export: Pflichtfelder vor dem Export prüfen und fehlende Angaben melden
Description

Der XRechnung-Export erzeugt auch dann eine Datei, wenn Pflichtangaben der Norm fehlen. Der Anwender bemerkt das erst, wenn der Empfänger oder ein Validator die Rechnung zurückweist.

Konkreter Auslöser: Ist in den Einstellungen unter Firmendaten das Feld „Inhaber" leer, fehlt BT-41 (Seller contact point). Der KoSIT-Validator meldet dann:

[BR-DE-5] Das Element "Seller contact point" (BT-41) muss übermittelt werden.
Bewertung: Es wird empfohlen das Dokument zurückzuweisen.

Bemerkenswert dabei: Telefon (BT-42) und E-Mail (BT-43) werden aus den Firmendaten gefüllt, der Kontaktblock DefinedTradeContact wird also erzeugt – nur eben ohne PersonName. Herausgekommen ist ein halber Kontakt statt gar keinem.

Für diesen einen Fall ist in EInvoiceConverter.setInvoiceSeller inzwischen ein Fallback auf den Firmennamen eingebaut. Das Grundproblem bleibt: Es gibt keine Prüfung, die fehlende Pflichtangaben vor dem Export erkennt.

Vorschlag:

Vor dem Export prüfen, ob alle für das gewählte Profil erforderlichen Felder gefüllt sind. Fehlt etwas, einen Dialog zeigen, der die fehlenden Felder benennt und auf die betreffende Einstellungsseite verweist, statt eine formal ungültige Datei zu schreiben.

Weitere bekannte Lücken, die bei anderen Rechnungen zuschlagen und in dieselbe Prüfung gehören:

  • Mandatsreferenz und Gläubiger-Identifikationsnummer (BT-89, BT-90) bei SEPA-Lastschrift – im Converter als TODO markiert; die Einstellung für die Gläubiger-ID kann leer bleiben.
  • Zu- und Abschläge auf Dokumentebene (BT-106, BT-107, BT-112, BT-115) – ebenfalls als TODO markiert.
  • BT-131 bei Zu- und Abschlägen ohne Umsatzsteuer.
Additional Information

Geprüft mit KoSIT Validator 1.5.0, erkanntes Profil: EN16931 XRechnung (CII), urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0

TagsNo tags attached.

Activities

claude

2026-10-05 10:29

reporter   ~0001671

Nachtrag aus einem weiteren Validierungslauf: Sind am Versandeintrag 0 % hinterlegt, die Steuerkategorie aber auf "S" (Standard rated) belassen, meldet der Validator BR-S-07 – bei Kategorie S muss der Satz größer als null sein. Der Converter reicht Satz und Kategorie unverändert durch und prüft nicht, ob beide zueinander passen. Das gehört mit in die hier vorgeschlagene Prüfung: Zu jeder Kategorie aus UNTDID 5305 muss der Satz plausibel sein (S größer null, Z gleich null).

Zwei damit zusammenhängende Punkte sind bereits im Code behoben:

  • In EInvoiceConverter.setDocumentLevelAllowancesCharges führte eine Versandsteuer mit Kategorie Z oder E zu einer NullPointerException, weil der Befreiungsgrund unbesehen aus getNoVatReference() geholt wurde. Diese Referenz ist nur bei dokumentweiter Steuerbefreiung gesetzt, nicht bei einem einzelnen steuerfreien Versandeintrag. Es wird jetzt auf den Namen des Versandeintrags zurückgefallen.
  • BT-41 fällt auf den Firmennamen zurück, wenn kein Inhaber gepflegt ist (siehe Beschreibung).

Noch offen und ebenfalls ein Fall für die Vorab-Prüfung: Bei Kategorie E (steuerbefreit) verlangt BR-E-10 einen Befreiungsgrund in der Umsatzsteuer-Aufschlüsselung, also BT-120 (Text) oder BT-121 (Code). Der Converter erzeugt beides nirgends; der Text aus der Steuerbefreiungs-Referenz landet nur im Grund des Zuschlags (BT-104), was ein anderes Feld ist. Kategorie E dürfte damit weiterhin nicht validieren, Z dagegen schon.

Issue History

Date Modified Username Field Change
2026-10-05 10:14 claude New Issue
2026-10-05 10:29 claude Note Added: 0001671