XRechnung – Übersicht

Die Aktion XRechnung erzeugt aus Rechnungsdaten eine E-Rechnung im Format XRechnung 3.0.2 (UN/CEFACT CII), prüft sie mit dem offiziellen KoSIT-Validator und bettet sie auf Wunsch als ZUGFeRD / Factur-X in ein PDF/A-3 ein. Alles läuft lokal auf Ihrem PC; die Rechnung wird an niemanden gesendet.

Rechnungsdaten (JSON) ──▶ Prüfung der Daten ──▶ XML (CII) ──▶ KoSIT-Validator ──▶ ZUGFeRD-PDF (optional)
                                                                       │
                                               nur geprüfte Rechnungen gehen an die nächste Aktion (Mail, Ablage …)

• Wie die Daten aussehen und alle Parameter: Struktur
• Vom ERP-Druck zur versendeten XRechnung, Schritt für Schritt: Beispiel

Woher die Rechnungsdaten kommen

Die Rechnung ist ein JSON-Objekt mit den Kennungen der EN 16931 (BT1 Rechnungsnummer, BG4 Verkäufer, BG25 Positionen …). Meist steht der feste Teil (Verkäufer, Bankverbindung) einmal im Workflow, und der veränderliche Teil (Nummer, Käufer, Positionen) kommt per Skriptblock aus der gedruckten Rechnung, aus einer JSON-Datei oder von einer HTTP-Abfrage.

Sie müssen Ihr ERP nicht umbauen: Es genügt, dass die gedruckte Rechnung die Rechnungsdaten als Skriptblöcke enthält. Wie das ERP in einen Ordner druckt, steht unter PDF-Drucker.

Prüfung

Bevor eine XRechnung RUNOS verlässt, wird sie zweimal geprüft:

1. Prüfung der Rechnungsdaten (ValidateRequiredFields, Standard an) vor dem Schreiben der XML, nach der Spezifikation XRechnung 3.0.2: Pflichtfelder und -gruppen, Formate (Datum, Zahlen, höchstens zwei Nachkommastellen), Codelisten (Länder, Währungen, Einheiten, Steuerkategorien …), CustomizationID (BR-DE-21), Dokumentregeln (USt-IdNr., IBAN, Zahlungsart, Kontakt des Verkäufers), Zu- und Abschläge, Positionen (Menge × Preis), Umsatzsteuer-Aufschlüsselung und alle Summen (BR-CO-10 bis BR-CO-16). Fehler nennen Feld und Regel, z. B. BT-10 Buyer reference (BT10) is required.
2. KoSIT-Validator (ValidateWithKosit, Standard an): dieselbe Prüfung, die die Rechnungseingangsplattformen von Bund und Ländern durchführen (XML-Schema, Schematron der EN 16931 und der XRechnung).

Der Validator samt Java-Laufzeit ist in RUNOS enthalten und wird beim ersten Mal nach %LOCALAPPDATA%\RUNOS\KositValidator\ entpackt. Er startet im Hintergrund mit der ersten XRechnung oder, wenn Einstellungen → KoSIT-Validator mit Windows starten eingeschaltet ist, gleich mit RUNOS. Das Laden der Regeln dauert etwa 15–20 Sekunden (die erste Rechnung wartet so lange), danach dauert eine Prüfung deutlich unter einer Sekunde. Den Zustand sehen Sie unter Einstellungen → E-Rechnungs-Prüfung.

Wenn der Validator nicht startet

RUNOS spricht mit dem Validator über eine lokale Verbindung (127.0.0.1, nur auf diesem PC). Beim Start gilt:

• Der Validator hat 5 Minuten, um seine Regeln zu laden. Schafft er das nicht, zeigen die Einstellungen Fehler mit dem Hinweis, dass die Prüfregeln nicht geladen wurden. Meist war der PC ausgelastet; Starten versucht es erneut, ebenso die nächste Rechnung.
• Meldet der Validator, dass er bereit ist, hat er 60 Sekunden, um über 127.0.0.1 zu antworten. Antwortet er nicht, wechselt RUNOS in den Ersatzmodus: Jede Rechnung wird mit einem eigenen Aufruf des Validators geprüft, ohne lokale Verbindung. Das dauert pro Rechnung so lange wie das Laden der Regeln (etwa 15–20 Sekunden, auf langsamen PCs länger); mehrere Rechnungen werden nacheinander geprüft. Der Ersatzmodus gilt, bis Sie in den Einstellungen Neu starten wählen oder RUNOS neu starten.
• Kann der Validator aus einem anderen Grund nicht starten, wird die Rechnung ebenfalls mit einem eigenen Aufruf geprüft.

Die Einstellungen zeigen nur eine kurze Meldung. Die Einzelheiten stehen im RUNOS-Protokoll unter KoSIT: wie lange das Laden der Regeln dauerte, jede Art von Antwort der Statusabfragen (HTTP-Status, Verbindungsfehler, keine Antwort nach 5 Sekunden) und die letzten Ausgaben des Validators. Bei einer Supportanfrage senden Sie uns diese Einträge mit.

Warum lokale Verbindungen auf einem PC nicht durchkommen, kann RUNOS nicht feststellen. Möglich sind z. B. Sicherheitssoftware, die Netzwerkverkehr prüft, oder Richtlinien des Unternehmens; das ist im Einzelfall mit der IT zu klären.

Keine ungeprüfte Rechnung

Kann die Rechnung weder über den Validator im Hintergrund noch mit einem eigenen Aufruf geprüft werden, schlägt die Aktion fehl, auch wenn FailOnKositReject aus ist. So gelangt keine ungültige oder ungeprüfte Rechnung zu den folgenden Aktionen.

XRechnung oder ZUGFeRD?

Format	Was es ist	Für wen
XRechnung (XML)	reine Daten-Datei nach XRechnung 3.0.2	öffentliche Auftraggeber (mit Leitweg-ID in BT10) und alle, die strukturierte Rechnungen verlangen
ZUGFeRD / Factur-X (PDF)	lesbares PDF mit eingebetteter XML	Geschäftskunden, die ein PDF ansehen und die Daten trotzdem maschinell verarbeiten möchten

RUNOS erzeugt ZUGFeRD in den Profilen XRECHNUNG und EN 16931. Beide enthalten die vollständige Rechnung. MINIMUM, BASIC WL, BASIC und EXTENDED bietet RUNOS bewusst nicht an.

Die Ansicht E-Rechnung

Unter E-Rechnung (XRechnung) in der Aktivitätsleiste füllen Sie eine Rechnung Feld für Feld aus und sehen sofort das Rechnungs-JSON, die erzeugte XML und die Prüfungen. Für Rechnungen im Workflow verwenden Sie die Aktion XRechnung mit ihrem Formular im Editor.

Element	Funktion
Formular	alle Felder der XRechnung 3.0.2 nach Gruppen. Pflichtfelder mit *, die Beschreibung aus dem Standard beim Überfahren der Beschriftung. Wiederholbare Gruppen mit … hinzufügen.
Beispiel laden / Leeren	gültige Beispielrechnung laden / alles leeren
Summen berechnen	Positionsbeträge (BT-131), Umsatzsteuer-Aufschlüsselung (BG-23) und Summen (BG-22)
JSON	das Rechnungs-JSON zum Kopieren in einen Workflow; JSON übernehmen lädt ein eingefügtes JSON ins Formular
XML / Prüfung	die erzeugte XRechnung und dieselbe Datenprüfung wie in der Aktion
Speichern	speichert die XML, sobald alle Pflichtfelder gefüllt sind

Nutzen Sie sie, um mit dem ERP-Anbieter die nötigen Felder festzulegen, den festen Teil der Rechnung vorzubereiten oder eine abgelehnte Rechnung Feld für Feld zu korrigieren. Den KoSIT-Validator führt erst die Aktion aus.

Formular im Editor

Im Diagramm des Workflow-Editors hat die Aktion ein Formular:

• Rechnung: Quelle Felder, JSON-Datei (InvoiceJsonFile) oder JSON-Text (InvoiceJson). Wählen Sie Datei oder Text, werden die eingetragenen Feldwerte entfernt; das lässt sich rückgängig machen.
• Felder: erzeugt aus dem Katalog der XRechnung 3.0.2 und nach Gruppen (BG) geordnet. Pflichtfelder tragen *, die Beschriftung zeigt beim Überfahren die Beschreibung aus dem Standard, Codefelder bieten gängige Codes an. Wiederholbare Gruppen wie die Rechnungspositionen (BG-25) fügen Sie mit … hinzufügen hinzu und entfernen sie wieder. Nur Pflicht- und ausgefüllte Felder blendet den Rest aus, Mit Beispiel füllen setzt eine Beispielrechnung ein. Jedes Feld nimmt Text oder Werte, die Sie aus der Testansicht hineinziehen.
• Ausgabe: Standard (XRechnung 3.0, XRechnung 3.0 Extension oder EN 16931 (ZUGFeRD)) und XML in einem Ordner speichern mit Ordner und Dateiname. Ist es aus, bleibt die XML in einem temporären Arbeitsordner; spätere Aktionen erhalten sie trotzdem als {{FilePath}}.
• Prüfungen und Berechnung: Summen berechnen, Zahlen mit Dezimalkomma, Pflichtfelder und Regeln prüfen, Mit dem KoSIT-Validator prüfen, Eine abgelehnte Rechnung lässt die Aktion fehlschlagen sowie Prüfbericht behalten mit Ordner für Berichte.
• ZUGFeRD-PDF erzeugen mit PDF der Rechnung, Skriptblöcke aus dem PDF entfernen und Dateien anhängen (eine pro Zeile).

ContextKey, PrettyPrint, ProfileID und ZugferdConformanceLevel erscheinen unter Weitere Parameter, wenn sie gesetzt sind. Welcher Parameter hinter welchem Feld steht, zeigt die Struktur. Schritt testen in der Testansicht erzeugt und prüft die Rechnung wirklich, mit den Daten der Schritte davor.