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.

Die Prüfung sollte nicht erst beim Export greifen, sondern bereits im Steuersatz-Editor.

Beobachteter Fall: Ein von Hand angelegter Steuersatz mit dem Namen „15 Prozent", Code S und Wert 0 – die Prozentzahl stand nur im Namen, das Wertfeld war nie gefüllt worden. Die Anwendung nimmt das kommentarlos an. Folgen:

• In der Rechnung wird keine Umsatzsteuer ausgewiesen, ohne jeden Hinweis. Das fällt erst auf, wenn man die Summen nachrechnet.
• Beim XRechnung-Export verletzt dieselbe Kombination BR-S-07 (Kategorie S verlangt einen Satz größer null) und das Dokument wird zurückgewiesen.

Vorschlag: Beim Speichern eines Steuersatzes prüfen, ob Code und Satz zueinander passen – Code S verlangt einen Satz größer null, Code Z verlangt null, Code E verlangt null und zusätzlich einen Befreiungsgrund. Das ist dieselbe Regel, die auch die Vorab-Prüfung beim Export braucht; sie ließe sich an einer Stelle umsetzen und von beiden Seiten aufrufen.

Der Steuersatz-Editor fällt damit in denselben Aufgabenbereich wie dieses Ticket: Die Daten sind formal unvollständig, und der Anwender erfährt es erst, wenn ein Dritter die Rechnung ablehnt.