E-Rechnung: Dokumentation
Die elektronische Rechnungsstellung wird in Deutschland und in ganz Europa zu einem wichtigen Bestandteil des Geschäftsbetriebs.
Ab 2025 wird Deutschland die elektronische Rechnungsstellung für B2B-Transaktionen verbindlich vorschreiben und damit dem Beispiel anderer EU-Länder folgen, die ähnliche Vorschriften eingeführt haben. Diese Verlagerung hin zur Digitalisierung von Rechnungsprozessen soll die Effizienz, Transparenz und Compliance erhöhen und gleichzeitig den Steuerbetrug reduzieren.
Um diese neuen Vorschriften zu erfüllen, müssen Unternehmen konforme E-Invoicing-Systeme implementieren, die elektronische Rechnungen in strukturierten Formaten wie XML oder UBL erstellen, versenden und empfangen können.
Gliederung
Generell
1. Allgemeine Übersicht zur E-Rechnung
E-Invoicing wird wird zu einem wesentlichen Bestandteil der Geschäftstätigkeit in Deutschland und ganz Europa werden.
Ab 2025 wird Deutschland die verpflichtende E-Rechnung für B2B-Transaktionen durchsetzen, analog zu anderen EU-Ländern, die ähnliche Regelungen bereits eingeführt haben. Diese Umstellung hin zur Digitalisierung der Rechnungsprozesse soll die Effizienz, Transparenz und Compliance erhöhen und gleichzeitig Steuerbetrug reduzieren.
Um sich an diese neuen Vorschriften anzupassen, müssen Unternehmen konforme E-Rechnungssysteme implementieren, die in der Lage sind, elektronische Rechnungen in strukturierten Datenformaten (wie XML) zu erstellen, zu versenden und zu empfangen.
Gesetzesgrundlage
Das Wachstumschancengesetz (WtChancenG) bildet die rechtliche Grundlage für die Einführung und Umsetzung der E-Rechnung in Deutschland. Es zielt darauf ab, Wachstumschancen zu stärken, Investitionen zu fördern, Innovationen zu unterstützen sowie die Steuervereinfachung und Steuerfairness zu verbessern. Dieses Gesetz ist Teil der Bemühungen, den elektronischen Rechnungsaustausch zu standardisieren und die Digitalisierung im Unternehmensbereich weiter voranzutreiben.
Weitere Informationen finden Sie hier:
Gesetz zur Stärkung von Wachstumschancen, Investitionen und Innovation sowie Steuervereinfachung und Steuerfairness (Wachstumschancengesetz) - Bundesfinanzministerium - ServiceWas sind E-Rechnungen?
Eine elektronische Rechnung (E-Rechnung) ist eine Rechnung, die in einem vorgegebenen strukturierten elektronischen Daten-Format im Sinne der europäischen Normenreihe EN 16931 ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht.
Wichtig: Per E-Mail versandte Rechnungen im PDF Format, stellen keine E-Rechnungen im Sinne der EU-Richtlinie dar. PDF-Rechnungen und Rechnungen in Papierform zählen ab 2025 als „sonstige Rechnung“.
Warum E-Rechnung?
Elektronische Rechnungen reduzieren den manuellen Aufwand und die Fehleranfälligkeit, da Daten direkt digital ausgetauscht werden können. Darüber hinaus verbessert die E-Rechnung die Transparenz und Nachvollziehbarkeit des Rechnungsprozesses und sorgt für eine erhöhte Compliance, insbesondere in Bezug auf steuerliche Anforderungen. Durch die digitale Automatisierung werden Kosten reduziert und der gesamte Rechnungsprozess beschleunigt.
Varianten der E-Rechnung
ZUGFeRD (PDF/A-3)
Das PDF/A-3 Format ist eine spezielle Variante des PDF-Standards, die für die langfristige Archivierung von Dokumenten verwendet wird. Im Kontext von E-Rechnungen ist PDF/A-3 besonders relevant, da es die Einbettung strukturierter Rechnungsdaten (XML) ermöglicht. Dies stellt sicher, dass sowohl die visuelle Darstellung als auch die maschinell lesbaren Daten in einem einzigen Dokument vorhanden sind, was für die Digitalisierung und den rechtssicheren Austausch von Rechnungen notwendig ist.
X-Rechnung (XML)
Die X-Rechnung ist der Standard für elektronischen Rechnungsaustausch mit öffentlichen Auftraggebern in Deutschland. Das verwendete XML-Format ist primär maschinenlesbar. Der Standard umfasst verschiedene technische Komponenten wie die Spezifikation des Standards, Mittel zur Validierung nationaler Geschäftsregeln (z.B. Schematron- und XSL-Dateien), Repräsentation von Codelisten im Genericode 1.0-Standard, eine Open-Source-Referenzimplementierung zur Überprüfung der Konformität von XML-Dokumenten, Testnachrichten und Unterstützung zur Visualisierung von Rechnungen.
Zur Visualisierung der XRechnungs-Datensätze wird in der Regel eine systeminterne Lösung verwendet, die die Weiterverarbeitung der Rechnungsdaten ermöglicht. Für die korrekte Anzeige und Verarbeitung von XRechnungen bieten diverse Systeme und Tools entsprechende Komponenten an.
E-Rechnung (Template)
Eine vorgefertigte Datenbank welche alle notwendigen Features für die Erstellung der E-Rechnung enthält kann bald in den Datenbankvorlagen abgerufen werden. Dieser Artikel wird bei der Veröffentlichung dieser Vorlage entsprechend aktualisiert.
Weiterhin befinden sich erläuternde Videos zur Einrichtung in Bearbeitung und werden ebenfalls in diesem Artikel veröffentlicht sobald sie zur Verfügung stehen.
Wichtig:
Das Template E-Rechnung erfüllt die Mindestanforderungen der E-Rechnungserstellung.
Es stellt aufgrund der vielfachen Gestaltungsmöglichkeiten im Zuge der Rechnungserstellung keine Lösung im Sinne einer Plug and Play Implementierung dar, sondern dient der erleichterten Adaptierung und Umsetzung der jeweiligen betrieblichen Erfordernisse durch Bereitstellung der erforderlichen Skripte und Funktionen.
Es liegt in der Verantwortung der Entwickler, die Rechnungsstellung für die eigenen Zwecke zu überprüfen und umzusetzen.
Technische Dokumentation
Dieser Abschnitt beschreibt die Implementierung und Nutzung der E-Rechnungs-Funktionen in Ninox zur Erstellung und zum Empfang von E-Rechnungen.
Technische Dokumentation: Eingangsrechnungen
Dieser Abschnitt dokumentiert die Schritte zur Verarbeitung einer Eingangsrechnung.
Zur Überprüfung der Eingangsrechnung ist es erforderlich, dass die E-Rechnung für einen Menschen lesbar gemacht wird, damit sie entweder zurückgewiesen oder akzeptiert und anschließend gebucht und beglichen werden kann.
Folgende Schritte sind erforderlich oder werden zumindest empfohlen:
E-Rechnungsdatei in Ninox verfügbar machen
E-Rechnung validieren
E-Rechnung auslesen
E-Rechnungsdaten in Ninox speichern
E-Rechnungsdaten visualisieren
1. E-Rechnungsdatei in Ninox verfügbar machen
Der Empfang einer E-Rechnung erfolgt meistens per E-Mail. Zur Verarbeitung mit Ninox muss die Rechnungsdatei in diesem Fall noch zu Ninox übertragen werden, was sich beispielsweise mit dem Ninox Mailhook bewerkstelligen lässt.
Alternativ kann die E-Rechnungsdatei an einen Datensatz angehängt oder in ein Feld vom Typ Bild hochgeladen werden.
Im E-Rechnungs-Template erfolgt der Upload über ein Feld vom Typ Bild. Diese Aktion löst dann ein Trigger-Script aus, welches die weiteren Verarbeitungsschritte anstößt.
2. E-Rechnung validieren
Nicht alle empfangenen Rechnungsdateien werden gültige E-Rechnungen sein:
Gültige Ausnahmen von der E-Rechnungspflicht
Kleinbetragsrechnungen bis 250 Euro
umsatzsteuerbefreite Umsätze
ausländische Lieferanten
Lieferanten, die im Rahmen der Übergangsperiode eine alternative Rechnungsform vereinbart haben
Ungültige E-Rechnungsdateien
Dateiformat ist unbekannt
PDF-Datei enthält keine XML-Daten
Rechnung ist nicht konform zu den formalen Anforderungen
Der Mustang Server bietet zum technischen Validieren einer E-Rechnung eine eigene API-Funktion.
Mustang Server-Funktion validate
Die Mustang Server-Funktion validate ist wie folgt auf englisch dokumentiert:`
Checks a PDF or XML file for syntactical and mathematical correctness. Input file must be a PDF/A file (Factur-X, Order-X, ZUGFeRD) or a XML file (Factur-X, Order-X, ZUGFeRD, XRechnung(CII)), output will be a XML report
Das bedeutet, dass diese Funktion als Eingabe eine E-Rechnungsdatei in einem der genannten Formate erwartet und als Ausgabe einen Ergebnisbericht im XML-Format liefert.
Im Open Source-Projekt Mustang Server sind Antworten und mögliche Fehlertypen dokumentiert:
Aufruf der Mustang Server-Funktion validate mittels Ninox Script
Aus Ninox können die Mustang Server-Funktionen mit Hilfe der Ninox Script-Funktion sendCommand() aufgerufen werden:
sendCommand(connectionName, command, options, files)
Im Fall von mustang/validate sieht der Aufruf beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /validate”; let requestBody := { "formData": { "file": "_files[0]" } }; sendCommand(connectionName, command, requestBody, files(this));
Die Parameter connectionName, command und requestBody sind inhaltlich zwingend so zu wählen wie im Beispiel dargestellt, damit der Aufruf an den Mustang Server gelingt und die Funktion ihre Aufgabe erfüllt.
In diesem Beispiel wird angenommen, dass die zu validierende Datei als erster Datei-Anhang im aktuellen Datensatz (this) gespeichert ist:
Die Ninox Script-Funktion files() liefert die angehängten Dateien eines Datensatzes als Array zurück.
Die sendCommand-Funktion nimmt das Array mit den Dateien als optionalen vierten Parameter entgegen.
Der Text
"_files[0]"referenziert per Namenskonvention den Array-Eintrag mit Index 0, also den ersten Eintrag.
Bei einem eigenen Einsatz dieser Funktion veränderbar ist dementsprechend folgendes:
Anstelle des ersten Eintrags aus dem Array mit den Dateien könnte mittels "_files[i]" für i als Array-Index ein anderes Array-Element ausgewählt werden. Lesbarer dürfte es allerdings sein, das Array mit den Dateien auf die gewünschte Datei zu beschränken und weiterhin Index 0 zu verwenden:
let file := file(this, Filename); sendCommand(connectionName, command, requestBody, [file])
Hierbei bezeichnet Filename den Namen des gewünschten Dateianhangs.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion in diesem Fall einen XML-Text mit dem Prüfungsergebnis.
3. E-Rechnung auslesen
E-Rechnungen haben verschiedene Formate, sowohl was den Dateityp betrifft (z.B. ZUGFeRD-PDF und XRechnung-XML) als auch was die Datenstruktur (z.B. CII, EBL) und die inhaltlichen Vorgaben (z.B. Profil EN16931) betrifft.
Mit Hilfe des Mustang Servers ist es möglich, die Rechnungsdaten im standardisierten JSON-Format in einer einheitlichen Struktur auszulesen.
Mustang Server-Funktion parse
Die Mustang Server-Funktion parse ist wie folgt auf englisch dokumentiert:
Reads a Factur-X file into an invoice object. Requires a PDF or CII or UBL XML file.
Das bedeutet, dass diese Funktion als Eingabe eine E-Rechnungsdatei in einem der genannten Formate erwartet und als Ausgabe die Rechnungsdaten im JSON-Format liefert.
Weitere Informationen zur Struktur der Rechnungsdaten, die der Mustang Server verwendet, sind im Abschnitt Mapping zu finden.
Aufruf der Mustang Server-Funktion parse mittels Ninox Script
Der Aufruf der Funktion /mustang/parse aus Ninox heraus ähnelt dem oben beschriebenen Aufruf der Funktion /mustang/validate bis auf das Verb im Funktionsnamen.
Der Aufruf sieht dann beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /parse”; let requestBody := { "formData": { "file": "_files[0]" } }; sendCommand(connectionName, command, requestBody, files(this));
Die Aussagen zu unveränderlichen und veränderbaren Parametern entsprechen den bei der Funktion mustang/validate genannten.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion hier im Erfolgsfall ein JSON-Objekt.
4. E-Rechnungsdaten in Ninox speichern
Bezüglich der Speicherung der E-Rechnungsdaten ist zwischen den folgenden Anforderungen zu unterscheiden:
E-Rechnungsdaten im Original GoBD-konform archivieren
E-Rechnungsdaten speichern, um sie in einer Geschäftsanwendung weiterzuverarbeiten, beispielsweise für folgende Zwecke:
Visualisierung
Rechnungsprüfung
Projektabrechnung
Zahlungsabwicklung
Cash-Flow-Management
Vorbereitende Buchhaltung
Management-Auswertungen
Die erste Anforderung folgt aus den gesetzlichen Vorgaben. Zu ihrer Erfüllung wird ein Dokumenten-Management-System (DMS) oder ein anderes konformes digitales Archivierungssystem benötigt. Im KMU-Bereich werden dazu häufig die Angebote der DATEV e.V. genutzt wie z.B. DATEV Unternehmen Online. Für den Online-Export zu DATEV bietet Ninox seit Januar 2024 eine Integrationslösung für Ninox Private Cloud-Kunden an. Weitere Informationen dazu sind über partner@ninox.com erhältlich.
Die zweite Anforderung zum Speichern ergibt sich aus der Geschäftsanwendung. Für die Speicherung von Daten bietet Ninox von Haus aus eine Vielzahl an Feldtypen. Hinweise auf die wichtigsten Felder im Mustang Rechnungsobjekt und Empfehlungen zur Auswahl sind im Abschnitt Mapping zu finden.
5. E-Rechnungsdaten visualisieren
Unabhängig vom Format der E-Rechnung ist eine Visualisierung der maschinenlesbaren XML-Rechnungsdaten erforderlich:
Bei Rechnungen im ZUGFeRD-Format gibt es zwar ein Rechnungsbild im PDF-Format, führend und rechtlich bindend sind jedoch die XML-Daten.
Bei reinen XML-Rechnungen ließe sich der Inhalt für Menschen nur sehr umständlich aus den XML-Daten entnehmen.
Falls die ausgelesenen Rechnungsdaten in Ninox-Tabellen gespeichert sind, lässt sich die Rechnung natürlich mit Hilfe dieser Felder visualisieren. Viele mögliche E-Rechnungsfelder sind jedoch äußerst selten oder möglicherweise nie relevant. Um die Übersichtlichkeit zu wahren und die Wartung der Ninox-Anwendung zu erleichtern, werden tendenziell nur die wichtigsten Rechnungsdaten in Ninox-Tabellen gespeichert. Um Nutzern dennoch ein vollständiges Bild der erhaltenen Rechnung zu bieten, müssen alle Rechnungsdaten anschaulich dargestellt werden können.
Mustang Server bietet zu diesem Zweck die Möglichkeit, aus den XML-Daten eine HTML-Ansicht zu generieren. Vorab müssen dazu bei ZUGFeRD-Rechnungen die XML-Daten extrahiert werden.
Mustang Server-Funktion extract
Die Mustang Server-Funktion extract ist wie folgt auf englisch dokumentiert:
Extracts XML from a zf/fx PDF or XML. Input PDF must be ZUGFeRD or Factur-X, XML must be xr,zf,fx or ox
Das bedeutet, dass diese Funktion als Eingabe eine E-Rechnungsdatei in einem der genannten Formate erwartet und als Ausgabe die Rechnungsdaten im XML-Format liefert.
Aufruf der Mustang Server-Funktion extract mittels Ninox Script
Der Aufruf der Funktion /mustang/extract aus Ninox heraus ähnelt dem oben beschriebenen Aufruf der Funktion /mustang/validate bis auf das Verb im Funktionsnamen.
Der Aufruf sieht dann beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /extract”; let requestBody := { "formData": { "file": "_files[0]" } }; sendCommand(connectionName, command, requestBody, files(this));
Die Aussagen zu unveränderlichen und veränderbaren Parametern entsprechen den bei der Funktion mustang/validate genannten.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion hier im Erfolgsfall einen Text im XML-Format.
Mustang Server-Funktion xmltohtml
Die Mustang Server-Funktion xmltohtml ist wie folgt auf englisch dokumentiert:
Visualisation from XML to HTML.
Das bedeutet, dass diese Funktion als Eingabe eine E-Rechnungsdatei im XML-Format erwartet und als Ausgabe die Rechnungsdaten im HTML-Format liefert.
Über den URL-Parameter language lässt sich eine der folgenden Ausgabesprache auswählen:
DE: deutschEN: englischFR: französisch
Aufruf der Mustang Server-Funktion xmltohtml mittels Ninox Script
Der Aufruf der Funktion /mustang/xmltohtml aus Ninox heraus ähnelt dem oben beschriebenen Aufruf der Funktion /mustang/validate bis auf das Verb im Funktionsnamen und ggf. den zusätzlichen URL-Parameter language zur Auswahl der Ausgabesprache.
Der Aufruf sieht dann beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /xmltohtml?language=DE”; let requestBody := { "formData": { "file": "_files[0]" } }; sendCommand(connectionName, command, requestBody, files(this));
Die Aussagen zu unveränderlichen und veränderbaren Parametern entsprechen den bei der Funktion mustang/validate genannten.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion hier im Erfolgsfall einen Text im HTML-Format.
Darstellung der HTML-Daten in Ninox
HTML Text als Dateianhang eines Datensatzes speichern
HTML in einem iFrame ausgeben
let myfileurl := fileUrl(mein_datensatz, "meine_rechnung.html"); html(--- <iframe width="99%" height="99%" src='{ myfileurl }' style="margin: 0; padding: 0; border: none;" class="viewer" /> ---)
Technische Dokumentation: Ausgangsrechnungen
Dieser Abschnitt dokumentiert die Schritte zur Erstellung einer Ausgangsrechnung.
Zu unterscheiden sind zwei Arten von E-Rechnungen:
ZUGFeRD
XRechnung
Folgende Schritte sind erforderlich:
E-Rechnungsdaten erfassen
E-Rechnungsdaten für PDF-Ausgabe aufbereiten (nur ZUGFeRD)
Dokument im Format PDF/A-3 erstellen (nur ZUGFeRD)
E-Rechnungsdaten für Mustang Server-Aufruf aufbereiten
E-Rechnungsdatei erstellen
ZUGFeRD
XRechnung
E-Rechnungsdatei visualisieren
E-Rechnungsdatei versenden
1. E-Rechnungsdaten erfassen
Um eine E-Rechnung zu erstellen, müssen zunächst die Rechnungsdaten erfasst werden.
Welche Daten erfasst werden müssen, hängt bei allen Rechnungen von den gesetzlichen Anforderungen ab. Bei E-Rechnungen ergeben sich weitere Anforderungen aus dem zu verwendenden Profil (z.B. EN16931). Weitere Informationen dazu sind im Abschnitt Mapping zu finden.
2. E-Rechnungsdaten für PDF-Ausgabe aufbereiten (nur ZUGFeRD)
Für den Fall, dass die E-Rechnung im ZUGFeRD-Format erstellt werden soll, wird ein Rechnungsbild im Format PDF/A-3 benötigt. Dies lässt sich mit Hilfe der Carbone-Druckfunktion in Ninox erstellen (dynamisches Drucklayout).
Um die Rechnungserstellung zu automatisieren, muss die Carbone-Druckausgabe per Ninox Script angefordert werden. Neben einer Vorlage, z.B. im MS Word-Format, werden die Ausgabedaten im JSON-Format benötigt.
Weitere Informationen zur notwendigen Aufbereitung der Druckdaten sind in der Dokumentation der Ninox Script-Funktion printAndSaveRecord() zu finden.
3. Dokument im Format PDF/A-3 erstellen (nur ZUGFeRD)
Die Basis einer E-Rechnung im ZUGFeRD-Format ist eine Datei im Format PDF/A-3. Diese lässt sich mit Hilfe der oben genannten Ninox Script-Funktion printAndSaveRecord() erstellen, indem ein optionaler Zusatzparameter mitgesendet wird:
printAndSaveRecord(this, "Invoices", { Name: "John Doe", Age: 42, _options: { pdfVersion: 3 } })
Die Festlegung des Formats PDF/A-3 kann alternativ auch in den Einstellungen des für die Rechnungserstellung genutzten Carbone-Drucklayouts vorgenommen werden.
Das erstellte Dokument sollte beispielsweise als Anhang eines Datensatzes gespeichert werden, damit es zur E-Rechnung weiterverarbeitet werden kann.
4. E-Rechnungsdaten für Mustang Server-Aufruf aufbereiten
Der Mustang Server nimmt Rechnungsdaten in Form eines JSON-Objekts entgegen.
Hinweise auf die wichtigsten Felder im Mustang Rechnungsobjekt und Empfehlungen zur Auswahl sind im Abschnitt Mapping zu finden.
5. E-Rechnung erstellen
5a. E-Rechnung erstellen im Format ZUGFeRD
Für den Fall, dass die E-Rechnung im ZUGFeRD-Format erstellt werden soll, muss das zuvor erstellte Dokument mit dem Rechnungsbild im Format PDF/A-3 mit den Rechnungsdaten in einem XML-Format angereichert werden.
Für das XML-Format stehen folgende Standards zur Auswahl:
UBL (Universal Business Language): Dies ist ein weit verbreiteter Standard für elektronische Dokumente, insbesondere Rechnungen. UBL wurde vom OASIS-Standardkonsortium entwickelt und zielt darauf ab, den Austausch von Geschäftsdokumenten zwischen Organisationen unabhängig von ihrer technischen Infrastruktur zu erleichtern. UBL bietet eine Bibliothek XML-basierter Schemata und ist dadurch äußerst anpassbar an verschiedene Branchen und Regionen.
CII (Cross-Industry Invoice): CII wurde von UN/CEFACT entwickelt und ist ein weiteres standardisiertes Format für elektronische Rechnungen, das auf hohe Flexibilität ausgelegt ist. Es soll vielfältige Geschäftsszenarien unterstützen und ist branchenübergreifend einsetzbar. CII basiert ebenfalls auf XML und wird häufig für europäische E-Invoicing-Systeme verwendet, insbesondere da es den EU-Vorschriften entspricht.
Zur Anreicherung eines Dokuments im Format PDF/A-3 mit Rechnungsdaten in einem der genannten XML-Formate hält der Mustang Server die Funktion combine bereit.
Mustang Server-Funktion combine
Die Mustang Server-Funktion combine ist wie folgt auf englisch dokumentiert:
Combine PDF/A file and JSON invoice object. Output PDF will be a ZUGFeRD/Factur-X PDF/A-3 file called invoice.pdf.
Requires a input PDF/A-1 or A-3 file, a format (ZUGFeRD = zf, Factur-X = fx or Order-X = ox), a version (usually 2 for ZUGFeRD and 1 for Factur-X) and a profile ("MINIMUM","BASICWL","BASIC","EN16931","EXTENDED" or "XRECHNUNG" for Factur-X, for ZUGFeRD 1 "BASIC","COMFORT" or "EXTENDED"). Order-X currently accepts only PDF/A-1 as input PDF.
Das bedeutet, dass diese Funktion als Eingabe ein PDF-Dokument im Format PDF/A und Rechnungsdaten in Form eines Mustang-JSON-Objekts erwartet und als Ausgabe die E-Rechnungsdatei im spezifizierten Format liefert.
Über Parameter können die Standard-Werte (Format: ZUGFeRD, Version: 2, Profile: EN16931) überschrieben werden.
Aufruf der Mustang Server-Funktion combine mittels Ninox Script
Der Aufruf der Funktion /mustang/combine aus Ninox heraus ähnelt dem oben beschriebenen Aufruf der Funktion /mustang/validate bis auf das Verb im Funktionsnamen und das Attribut json im formData-Objekt des requestBody-Parameters.
Außerdem können die oben genannten Parameter Format, Version und Profil übergeben werden.
Der Aufruf sieht dann beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /combine”; let requestBody := { "formData": { "file": "_files[0]", "json": { "number": "0001", "currency": "1", "issueDate": 1724803200000, "dueDate": 1726099200000, "deliveryDate": 1724803200000, "sender": { "name": "Lieferant GmbH", "zip": "80333", "street": "Lieferantenstraße 20", "location": "München", "country": "DE", "taxID": "201/113/40209", "vatID": "DE123456789", "globalID": "4000001123452", "globalIDScheme": "0088" }, "recipient": { "name": "Kunden AG Mitte", "zip": "69876", "street": "Kundenstraße 15", "location": "Frankfurt", "country": "DE" }, "zfitems": [ { "price": 5.5, "quantity": 1, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 4.9, "quantity": 1, "product": { "unit": "H87", "name": "Haustürlieferung", "description": "789", "vatpercent": "1", "taxCategoryCode": "3" } } ] } } }; let base64URL := sendCommand(connectionName, command, requestBody, files(this));
Die Aussagen zu unveränderlichen und veränderbaren Parametern entsprechen den bei der Funktion mustang/validate genannten.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion hier im Erfolgsfall eine ZUGFeRD-PDF-Datei im base64URL-Format. Diese lässt sich anschließend wie folgt speichern:
importFile(this, text(base64URL), "e-invoice.pdf");
5b. E-Rechnung erstellen im Format XRechnung
Mustang Server bietet mit der Funktion invoice2XML die Möglichkeit, Rechnungsdaten in eine E-Rechnungsdatei in einem reinen XML-Format zu erstellen.
Mustang Server-Funktion invoice2XML
Die Mustang Server-Funktion invoice2XML ist wie folgt auf englisch dokumentiert:
Invoice class to XML. Input must be JSON.
Das bedeutet, dass diese Funktion als Eingabe Rechnungsdaten in Form eines Mustang-JSON-Objekts erwartet und als Ausgabe die E-Rechnungsdatei im spezifizierten Format liefert.
Weitere Informationen zur Struktur der Rechnungsdaten, die der Mustang Server verwendet, sind im Abschnitt Mapping zu finden.
Aufruf der Mustang Server-Funktion invoice2XML mittels Ninox Script
Der Aufruf der Funktion /mustang/invoice2XML aus Ninox heraus ähnelt dem oben beschriebenen Aufruf der Funktion /mustang/combine bis auf das Verb im Funktionsnamen und den etwas anders gestalteten requestBody-Parameter.
Außerdem können die oben genannten Parameter Format, Version und Profil übergeben werden.
Der Aufruf sieht dann beispielsweise wie folgt aus:
let connectionName := “Mustang”; let command := “POST /invoice2XML”; let requestBody := { "body": { "number": "471102", "currency": "1", "issueDate": 1721260800000, "dueDate": 1722384000000, "deliveryDate": 1721952000000, "sender": { "name": "Lieferant GmbH", "zip": "80333", "street": "Lieferantenstraße 20", "location": "München", "country": "DE", "taxID": "201/113/40209", "vatID": "DE123456789", "globalID": "4000001123452", "globalIDScheme": "0088" }, "recipient": { "name": "Kunden AG Mitte", "zip": "69876", "street": "Kundenstraße 15", "location": "Frankfurt", "country": "DE" }, "zfitems": [ { "price": 9.9, "quantity": 20, "product": { "unit": "H87", "name": "Trennblätter A4", "description": "456", "vatpercent": "1", "taxCategoryCode": "3" } }, { "price": 5.5, "quantity": 50, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 5.5, "quantity": 24, "product": { "unit": "H87", "name": "Joghurt Banane", "description": "123", "vatpercent": "2", "taxCategoryCode": "3" } }, { "price": 9.9, "quantity": 3, "product": { "unit": "H87", "name": "Trennblätter A4", "description": "456", "vatpercent": "1", "taxCategoryCode": "3" } } ] } }; let base64URL := sendCommand(connectionName, command, requestBody);
Die Aussagen zu unveränderlichen und veränderbaren Parametern entsprechen den bei der Funktion mustang/validate genannten.
Als Rückgabe liefert Mustang und damit auch die sendCommand-Funktion hier im Erfolgsfall eine ZUGFeRD-PDF-Datei im base64URL-Format. Diese lässt sich anschließend wie folgt speichern:
importFile(this, text(base64URL), "e-invoice.pdf");
6. E-Rechnungsdatei visualisieren
Der XML-Teil einer selbst erstellten E-Rechnungsdatei kann genauso visualisiert werden, wie dies für eingegangene E-Rechnungen möglich ist - siehe entsprechender Abschnitt.
7. E-Rechnungsdatei versenden
Die fertige E-Rechnung muss zuletzt noch an den Empfänger zugestellt werden. Dies erfolgt üblicherweise per E-Mail. Dazu bietet Ninox die Ninox Script-Funktion sendEmail.
Ressourcen & Tools
Hier finden Sie eine Übersicht der benötigten Informationen für die Implementierung, einschließlich Mapping, Standards, API-Endpunkten und weiteren Tools.
Mapping
BT / Mustang Invoice class -Mapping
(BT = Business Terms)
Für detaillierte Informationen zu Anforderungen und Zuordnung der Business Terms in ZUGFeRD und XRechnung finden sich in den Bereichen ZUGFeRD und XRechnung Links zu den aktuellen Spezifikationen, Beispieldateien und zusätzlichen Ressourcen wie Validierungstools oder Foren.
Die Schnittstelle zwischen den unterschiedlichen Standards und Ninox bildet das Mustang Invoice Class JSON Schema. Ein ausführliches Mapping der BTs ist in diesem Artikel einsehbar. Detaillierte Übersichten und Tools finden sich im Bereich Mustang Server.
ZUGFeRD
ZUGFeRD Standard Dokumentation
Forum elektronische Rechnung Deutschland (FeRD):
Willkommen bei FeRDRessourcen:
Infopaket zum aktuellen ZUGFeRD Standard mit technischem Anhang, Codelisten und Beispieldateien als Download
Kontext zur Einführung der E-Rechnung in Deutschland, den Standards und aktuellen Entwicklungen in diesem Bereich
Die im Downloadpaket zur aktuell gültigen Spezifikation enthaltenen technischen Anhänge der einzelnen in ZUGFeRD abgebildeten Profile bilden in Verbindung mit den jeweiligen Beispiel-Rechnungsdateien die Grundlage für die Erzeugung valider E-Rechnungen und Abbildungen der entsprechenden BTs.
XRechnung
XRechnung Dokumentation
Informationsportal der KoSiT zur XRechnung:
XRechnung - XStandards Einkauf
Ressourcen:
Aktuelle Spezifikation des Standards XRechnung mit technischem Anhang und Beispieldateien als Download
Kontext zur Einführung der XRechnung in Deutschland, den Standards und aktuellen Entwicklungen in diesem Bereich
Die im Downloadpaket zur aktuell gültigen Spezifikation enthaltene Dokumentation, Syntax sowie Validation Tool und Beispieldateien bilden die Grundlage für eine erfolgreiche Implementierung des Standards in eigene Anwendungen.
Mustang Server
Server - Mustang Mustang Server
Ressourcen:
Handbuch Mustang Server
Mustang API Testumgebung
Mustang API Dokumentation
Link zu Testumgebung und Dokumentation:
https://api.usegroup.de:9443/devportal/apis
API Testumgebung Mustang Server
Link zur Mustang Server Testumgebung
Für die Umsetzung der Implementierung von E-Rechnungs-Funktionalitäten in Ninox ist die API Testumgebung des Mustang-Servers ein wertvolles Hilfsmittel.
Unter dem Menüpunkt “TryOut” können unter anderem in Ninox generierte Invoice Class JSON geprüft und umgewandelt, Validierungen durchgeführt und Rechnungsbestandteile (PDF/XML) kombiniert wie auch getrennt werden, ohne immer den vollen Prozess in der jeweiligen Anwendung durchlaufen zu müssen.
Darüber hinaus bietet die zugehörige Dokumentation (unter Documents) einen Überblick über das Mustang JSON Schema.
API Dokumentation Mustang Server
Link zur Mustang Server Dokumentation
Die Mustang Server API Dokumentation unter dem Menüpunkt Documents hält JSON Mustang Invoice Class Beispielschemata für Rechnungen (Invoice - ohne Mitgabe berechneter Werte wie Gesamtsumme etc. ), Berechnete Rechnungen (Calculated Invoice - mit Mitgabe bereits berechneter Werte) sowie Einzelbereiche der Schemate wie z.B. Zahlungsbedingungen (Payment Terms) bereit, die per Mapping mit den entsprechenden Daten aus Ninox zu befüllen sind.
In der API Testumgebung (unter “Try Out”) können die in Ninox integrierten Funktionen des Mustang Servers im Rahmen der Entwicklung auf kurzem Wege getestet werden.
Antwort
Content aside
-
1
„Gefällt mir“ Klicks
- vor 1 MonatZuletzt aktiv
- 425Ansichten
-
4
Folge bereits