ZUGFeRD-E-Rechnung erstellen mit curl

Was Sie brauchen

• Einen API-Key. Legen Sie ihn in der App unter API-Schlüssel an und exportieren Sie ihn als FORMFEED_API_KEY. Zum Ausprobieren ist ein Test-Key (ff_test_…) richtig. Siehe Quickstart.
• curl. Sie brauchen curl und jq.
• Die Vorlage. e-rechnung aus dem E-Rechnungs-Beispiel: Kopieren Sie es von der Seite des Beispiels in Ihren Workspace, oder pushen Sie den Ordner mit der CLI (formfeed templates push --publish). Jede Rechnungsvorlage funktioniert genauso, sobald ihre Daten einen _invoice-Block haben.
• Die Daten. Die data.json des Beispiels neben dem Programm: ein _invoice-Block mit Verkäufer, Käufer, Positionen, der Aufschlüsselung der Umsatzsteuer und den Summen, benannt wie in der europäischen Norm EN 16931.
• Ein Plan mit E-Rechnungen. Live-E-Rechnungen setzen den Starter-Plan oder höher voraus. Mit einem Test-Schlüssel (ff_test_…) erzeugt jeder Plan Test-E-Rechnungen mit Testmarkierung auf der Seite, der Free-Plan bis zu 20 pro Tag.

Das Programm

Das Programm liest data.json, sendet sie mit dem Namen der Vorlage und post.einvoice, wartet auf das Ergebnis, wenn die API mit 202 antwortet, bricht mit der Meldung der API ab, wenn etwas nicht stimmt, und speichert die E-Rechnung.

set -e

render=$(jq '{template: "e-rechnung", data: ., post: {einvoice: {profile: "en16931"}}}' data.json \
  | curl -sS https://api-eu.formfeed.dev/v1/renders \
      -H "Authorization: Bearer $FORMFEED_API_KEY" \
      -H "Content-Type: application/json" \
      --data-binary @-)

# not done within 60 seconds: the answer is 202 and the render goes on in the background;
# its result answers the same way until the render has finished
while printf '%s' "$render" | jq -e '.status == "queued" or .status == "rendering"' > /dev/null; do
  sleep 2
  render=$(curl -sS "https://api-eu.formfeed.dev/v1/renders/$(printf '%s' "$render" | jq -r .id)/result" \
    -H "Authorization: Bearer $FORMFEED_API_KEY")
done

# every error is a problem document (RFC 9457) with a title and a detail
url=$(printf '%s' "$render" | jq -r '.download_url // error(.title + ": " + (.detail // ""))')
curl -sS -o e-invoice.pdf "$url"
printf '%s' "$render" | jq -r '"\(.id) \(.page_count) page(s), \(.units) unit(s)"'

Ausführen

Es gibt die ID des Renderings, die Seitenzahl und die verbrauchten Einheiten aus (mit einem Live-Schlüssel eine mehr als dasselbe PDF ohne XML), und e-invoice.pdf liegt neben dem Programm. Ein PDF-Viewer zeigt die Rechnung, seine Anhänge zeigen die factur-x.xml darin. Mit einem Test-Schlüssel wird das Rendering nicht gezählt, und jede Test-E-Rechnung trägt eine Testmarkierung, in jedem Plan.

export FORMFEED_API_KEY=ff_test_...
sh render.sh

Was an curl besonders ist

• jq schreibt das JSON. Weil jq den Body baut und keine String-Verkettung, werden Anführungszeichen, Zeilenumbrüche und Umlaute in der Eingabe korrekt maskiert.
• Fehler verschwinden nicht. error(…) lässt jq mit Titel und Detail des Problems abbrechen, wenn die Antwort ein Problem-Dokument ist, und set -e beendet das Skript dort, statt dem nächsten Befehl einen leeren String zu geben.
• Der Schlüssel geht nur an die API. Jeder Aufruf der API trägt den Authorization-Header. Die Datei kommt von einer signierten URL, die keinen braucht, also holt das letzte curl sie ohne Ihren Schlüssel.

Was das PDF zur E-Rechnung macht

• post.einvoice. macht aus dem PDF ein PDF/A-3, das die Rechnung als factur-x.xml trägt. Die Beispielvorlage erklärt dasselbe in ihrer settings.json, für sie ist die Zeile also optional; für Ihre eigene Rechnungsvorlage ist sie der eine Schalter.
• Der _invoice-Block. Verkäufer, Käufer, Positionen, Aufschlüsselung der Umsatzsteuer und Summen, benannt wie in der Norm; Einheiten und Steuerkategorien sind Codes (HUR, S). Die Vorlage druckt die Seite aus demselben Block, Seite und XML können also nichts Verschiedenes sagen.
• Die Prüfung. Bevor die Datei ausgeliefert wird, wird das XML gegen die Regeln der EN 16931 und das PDF gegen PDF/A-3b geprüft. Der Bericht steht in einvoice.validation des Renderings, und ein Wert, den die Seite nicht zeigt, steht in einvoice.display.missing.
• ZUGFeRD oder Factur-X. Eine Spezifikation unter zwei Namen, und dieselbe Datei. flavour entscheidet nur, welchen Namen und welches Release das Rendering meldet: ZUGFeRD 2.5 oder Factur-X 1.09.

Wenn die Daten nicht stimmen

Ein Block, der eine Regel verletzt, lässt die Anfrage mit 422 einvoice_data_invalid scheitern, bevor etwas gerendert oder gezählt wird. Das Problem nennt jeden Befund mit seiner Stelle in den Daten und der verletzten Regel (BR-CO-15, …), und das Programm gibt Titel und Detail aus. Eine Datei, die die Prüfung nicht besteht, wird nie ausgeliefert und nie durch ein einfaches PDF ersetzt.

Was bei Ihnen bleibt

Formfeed erzeugt und prüft die Datei. Den Versand an Ihren Kunden, die Archivierung und die umsatzsteuerliche Behandlung der Rechnung übernehmen Sie. Wann eine E-Rechnung Pflicht ist, mit den amtlichen Quellen, steht auf der Seite zur E-Rechnung; Felder und Regeln stehen in der Dokumentation zur E-Rechnung.

Wenn die API nein sagt

• Eine Form für jeden Fehler. Fehler sind Problem-Dokumente (RFC 9457) mit type, title, status, detail, einem stabilen code und der request_id, die Sie dem Support nennen; die type-URL führt zu einer Seite über diesen Fehler. Die Liste steht in der Fehlerreferenz.
• Die üblichen. 401 unauthorized bei fehlendem oder widerrufenem Schlüssel, 404 template_not_found bei falschem Vorlagennamen, 422 template_runtime_error, wenn die Vorlage an den Daten scheitert, 429 rate_limited über den Anfragen pro Sekunde des Tarifs, 402 quota_exceeded, wenn die Einheiten des Free-Tarifs verbraucht sind (ein bezahlter Tarif rechnet weitere Einheiten ab, bis zu seiner Obergrenze).
• Sicher wiederholen. Senden Sie beim POST einen Idempotency-Key-Header und wiederholen Sie die Anfrage mit demselben Schlüssel, wenn Sie nicht wissen, ob der erste Versuch ankam: 24 Stunden lang liefert der Schlüssel die erste Antwort, statt erneut zu rendern und zu berechnen. Gespeichert wird die Antwort, sobald der erste Versuch beantwortet ist; wiederholen Sie also nicht, solange er noch laufen kann. Auch Probleme unter 500 werden gespeichert, eine korrigierte Anfrage braucht deshalb einen neuen Schlüssel.

Die Aufgabe um dieses Programm

Dieser Guide ist ein Programm. Was die Aufgabe darum herum braucht, von der Vorlage bis zu Limits und Preis, steht auf der Seite Rechnungs-PDF-API.

Weitere Guides für curl

• PDF-Rechnung aus JSON erzeugen mit curl
• HTML in PDF umwandeln mit curl
• Open-Graph-Bilder erzeugen mit curl
• PDFs aus einer CSV erzeugen mit curl
• PDFs zusammenfügen und mit Passwort schützen mit curl

FAQ

Welches Profil soll ich wählen?

en16931, die Voreinstellung, trägt jedes Feld der europäischen Norm; basic ist das kleinste Profil, das für sich allein eine Rechnung ist. Jedes andere Profil wird mit einvoice_profile_unsupported beantwortet.

Erzeugt Formfeed XRechnung?

Nein. Formfeed schreibt ZUGFeRD bzw. Factur-X: das XML in einem PDF/A-3. XRechnung und UBL gibt es nicht.

Was kostet eine E-Rechnung?

Eine Einheit zusätzlich zu ihrem Rendering, eine einseitige E-Rechnung kostet also zwei Einheiten. Live-E-Rechnungen setzen den Starter-Plan oder höher voraus; im Free-Plan erzeugen Test-Renderings bis zu 20 pro Tag. Siehe Preise.

Bekomme ich das XML als eigene Datei?

xml: "both" in post.einvoice speichert das XML zusätzlich neben dem PDF, und das Rendering verlinkt es als einvoice.xml_url. Im PDF steckt es so oder so.

ZUGFeRD-E-Rechnung in anderen Sprachen

• Node.js (TypeScript)
• Python
• PHP
• Go
• C# (.NET)
• Java
• Ruby