KSeF-Code 450: «Błąd weryfikacji semantyki dokumentu faktury»

Was KSeF zurückgibt

In der Spezifikation der KSeF-API 2.9.0 hat der Status 450 einer Rechnung eine feste Beschreibung, «Błąd weryfikacji semantyki dokumentu faktury» (Fehler bei der semantischen Prüfung des Rechnungsdokuments). Was genau fehlerhaft ist, ergänzt KSeF im Feld details desselben Status. Das polnische Finanzministerium veröffentlicht keine Liste dieser Meldungen, es gibt also keine Tabelle nach dem Muster «450 bedeutet immer dieses Problem».

Es gibt aber Fälle, die das Ministerium in den Tests seiner eigenen Bibliothek ksef-client-csharp prüft und bei denen es genau den Code 450 erwartet:

• Ausstellungsdatum P_1 auf morgen nach polnischer Zeit gesetzt, weil KSeF P_1 in der Zeitzone Warschau liest und kein Datum akzeptiert, das nach dem Zeitpunkt des Empfangs der Rechnung liegt;
• DataWytworzeniaFa vor 2025-09-01T00:00:00Z, der untere Grenzwert dieses Feldes im Schema FA(3) 1-0E.

Was Sie in Odoo sehen

Rechnungen gelangen über das Odoo-Modul l10n_pl_edi zu KSeF, das in Odoo 18, 19 und 20 vorhanden ist. Antwortet KSeF, setzt es «KSeF Status» auf Rejected und schreibt eine Meldung in den Verlauf der Rechnung:

Aus der Antwort von KSeF liest Odoo den Code, die Beschreibung und die KSeF-Nummer. Das Feld details speichert es nicht (es hängt nur die Beschreibung von KSeF für den Code 500 an), daher kann Odoo allein nicht sagen, welcher Teil der Rechnung fehlerhaft war.

Wo Sie den Grund finden

Der Text von details kommt in der Antwort von KSeF auf die Abfrage des Rechnungsstatus. Wenn Sie aus Odoo senden, brauchen Sie jemanden, der ihn über die API ausliest, oder eine Prüfung der FA(3)-Datei vor dem Senden. Odoo 18, 19 und 20 enthalten eine Kopie des Schemas FA(3) im Modul, doch außerhalb der Tests verwendet es niemand: Die Datei geht an KSeF, ohne gegen das Schema validiert zu werden.

Odoo überwacht zwei Dinge. Es sendet keine Rechnung mit einem Datum nach heute in der Zeitzone des Benutzers («The move was skipped because it is future-dated»). Und es füllt DataWytworzeniaFa mit dem Zeitpunkt der Dateierzeugung in UTC, sodass die Grenze von 2025 nicht von einer in Odoo ausgestellten Rechnung stammen sollte.

So senden Sie sie erneut

1. Ermitteln Sie den Grund in details oder prüfen Sie die FA(3)-Datei gegen das Schema.
2. Korrigieren Sie die Daten in Odoo: Datum, Kunde, Positionen.
3. Setzen Sie die Rechnung auf Entwurf zurück. Bei einer abgelehnten Rechnung löscht Odoo ihren KSeF-Status, Nummer, Referenz und Sitzung.
4. Bestätigen Sie sie und senden Sie sie erneut mit der Option «by KSeF (e-Faktura)». Odoo sendet nur Rechnungen ohne KSeF-Status, ohne Schritt 3 geht also nichts hinaus.

Mit unserem Modul

Poland KSeF 2.0 Validator sendet keine Rechnungen an KSeF. Mit dem Abonnement FlexigoTech Cloud validiert es, wenn Sie vor dem Senden der Rechnung auf «Validate FA(3) (FlexigoTech Cloud)» klicken, die FA(3)-Datei gegen das Schema 1-0E und zeigt jeden Fehler als Zeile «[error] XSD (Pfad)» an: die Stelle in der Datei, ohne den Meldungstext, bis zu 100 Fehler. Das Ergebnis hält den Versand durch l10n_pl_edi nicht auf: Eine Rechnung «Not valid» geht trotzdem hinaus, wenn Sie sie senden. Es erkennt nicht, was KSeF nur auf seiner Seite prüft, etwa P_1 im Vergleich zum Zeitpunkt des Empfangs. Sobald l10n_pl_edi die Rechnung sendet, wird die frühere Validierung zu Expired, und das Modul prüft die Datei, die KSeF tatsächlich erhalten hat. In Odoo 17 validiert es die FA(3)-Datei, die an die Rechnung hochgeladen wurde.

Weiterlesen