Zum Hauptinhalt springen

einvoice_data_invalid

HTTP 422 · code: "einvoice_data_invalid" · type: https://docs.formfeed.dev/errors/einvoice-data-invalid

Das Rendering erzeugt eine E-Rechnung, und aus seinen Rechnungsdaten lässt sich keine gültige bauen. Die Antwort kommt von einer von zwei Stellen:

  • Bevor etwas gerendert wird. Der _invoice-Block in data fehlt, ein Feld fehlt, ein Code steht nicht in seiner Liste, oder eine Summe geht nicht auf. errors nennt jeden Befund mit path, message und, wo eine gilt, der rule der EN 16931 oder der französischen Spezifikationen, die er verletzt; detail wiederholt den ersten. Es wird nichts gerendert, gezählt oder berechnet. Bei einem Batch nennt index den ersten fehlerhaften Eintrag, und nichts wird eingereiht.
  • Nach dem Rendern. Der Block hat diese Prüfung bestanden, und der Validator hat die fertige Datei trotzdem abgelehnt. Das Problem trägt dann einvoice, den Bericht des Validators, und render_id. Das Rendering ist failed und behält den Bericht. Es wird keine Datei gespeichert, und es wird kein gewöhnliches PDF stattdessen ausgeliefert. Ein fehlgeschlagenes Rendering kostet nichts.

Beispiel​

Vor dem Rendern abgelehnt:

{
  "type": "https://docs.formfeed.dev/errors/einvoice-data-invalid",
  "title": "E-invoice data invalid",
  "status": 422,
  "detail": "_invoice.totals.grand is 1142.41, but tax_basis plus tax_total is 1142.40 (BR-CO-15) (and 1 more)",
  "code": "einvoice_data_invalid",
  "errors": [
    {
      "path": "data._invoice.totals.grand",
      "message": "_invoice.totals.grand is 1142.41, but tax_basis plus tax_total is 1142.40 (BR-CO-15)",
      "rule": "BR-CO-15"
    },
    {
      "path": "data._invoice.totals.due",
      "message": "_invoice.totals.due is 1142.40, but grand less prepaid plus rounding is 1142.41 (BR-CO-16)",
      "rule": "BR-CO-16"
    }
  ],
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Nach dem Rendern vom Validator abgelehnt:

{
  "type": "https://docs.formfeed.dev/errors/einvoice-data-invalid",
  "title": "E-invoice data invalid",
  "status": 422,
  "detail": "The e-invoice breaks 1 rule of EN 16931",
  "code": "einvoice_data_invalid",
  "location": null,
  "render_id": "rnd_7da09ab6cd9946b798c187c2a9350852",
  "einvoice": {
    "profile": "en16931",
    "flavour": "factur-x",
    "spec_version": "1.09",
    "xml_url": null,
    "validation": {
      "valid": false,
      "schematron": "Factur-X 1.09.2 (Mustang 2.26.0)",
      "pdfa": null,
      "messages": [
        {
          "part": "xml",
          "severity": "error",
          "rule": "…",
          "message": "…",
          "location": "/rsm:CrossIndustryInvoice/…"
        }
      ]
    },
    "display": null
  },
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Häufige Ursachen​

  • Die Daten haben keinen _invoice-Block. Eine Vorlage, deren Einstellungen eine E-Rechnung festlegen, braucht ihn in jedem PDF-Rendering (path ist data._invoice).
  • Eine Summe, die nicht auf den Cent aufgeht (BR-CO-10 bis BR-CO-16), oder eine Umsatzsteueraufschlüsselung, die nicht zu den Positionen passt. Formfeed berechnet und rundet nichts für Sie.
  • Ein Betrag mit mehr als zwei Nachkommastellen, etwa eine Positionssumme, die nie gerundet wurde.
  • Ein Code, der nicht in seiner Liste steht: eine Einheit als hours statt HUR (BR-CL-23), ein Land, eine Währung.
  • Ein Feld fehlt, das die Norm verlangt: das Fälligkeitsdatum oder die Zahlungsbedingungen einer Rechnung mit Zahlbetrag (BR-CO-25), die IBAN einer Überweisung (BR-61), eine Kennung des Verkäufers (BR-CO-26).
  • Eine Rechnung zwischen zwei französischen Unternehmen ohne die Felder, die Frankreich verlangt, oder im Profil basic, das Frankreichs Reform nicht annimmt.
  • Das Profil basic mit einem totals.rounding ungleich 0, das dieses Profil nicht übertragen kann.

So beheben Sie es​

  • Korrigieren Sie die Felder, die errors nennt. Pfade beginnen bei data._invoice, und Listeneinträge zählen ab 0: data._invoice.lines[0].unit_code ist die Einheit der ersten Position. Die Feldreferenz sagt, was jedes Feld aufnimmt.
  • Finden Sie die Befunde, bevor Sie die Anfrage senden: Der Abschnitt E-Rechnung der Seiteneinrichtung im Editor listet sie für den Datensatz auf dem Bildschirm, und formfeed validate prüft jeden Datensatz einer Vorlage offline. Beide führen die Prüfung aus, die auch die API ausführt.
  • Trägt das Problem einvoice, lesen Sie einvoice.validation.messages: Jeder Befund hat seine rule und seine location, einen XPath in das XML. Das fehlgeschlagene Rendering behält denselben Bericht, in GET /v1/renders/{id} und im Render-Protokoll. Wenn die Daten aus Ihrer Sicht stimmen, senden Sie die render_id an support@formfeed.dev.
  • Welche Umsatzsteuerkategorie und welcher Satz für einen Umsatz gelten, ist eine Frage für Ihre Steuerberatung. Formfeed prüft nur, ob der Block zu Ihren Angaben passt.
  • Soll diese Anfrage aus einer Vorlage, die eine E-Rechnung festlegt, ein gewöhnliches PDF erzeugen, senden Sie "post": { "einvoice": false }.

Wiederholen?​

Nein. Dieselbe Anfrage liefert bei einer Wiederholung dieselbe Antwort; ändern Sie zuerst die Daten. Senden Sie die korrigierte Anfrage mit einem neuen Idempotency-Key oder ohne: Eine 4xx-Antwort wird 24 Stunden unter ihrem Schlüssel gespeichert, der alte Schlüssel liefert also wieder dieses Problem. Siehe Wiederholen.