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

Ce que renvoie KSeF

Dans la spécification de l'API KSeF 2.9.0, le statut 450 d'une facture en session a une description fixe, « Błąd weryfikacji semantyki dokumentu faktury » (erreur de vérification sémantique du document de facture). Le problème précis est ajouté par KSeF dans le champ details de ce même statut. Le ministère des Finances polonais ne publie pas la liste de ces messages : il n'existe donc pas de tableau du type « le 450 correspond toujours à ce problème ».

Il existe en revanche des cas que le ministère vérifie dans les tests de sa propre bibliothèque ksef-client-csharp et pour lesquels il attend précisément le code 450 :

• date d'émission P_1 fixée à demain selon l'heure polonaise, car KSeF lit P_1 dans le fuseau horaire de Varsovie et refuse une date postérieure au moment de réception de la facture ;
• DataWytworzeniaFa antérieure au 2025-09-01T00:00:00Z, la limite inférieure de ce champ dans le schéma FA(3) 1-0E.

Ce que vous voyez dans Odoo

Les factures parviennent à KSeF par le module l10n_pl_edi d'Odoo, disponible dans Odoo 18, 19 et 20. Lorsque KSeF répond, il passe « KSeF Status » à Rejected et écrit un message dans l'historique de la facture :

De la réponse de KSeF, Odoo lit le code, la description et le numéro KSeF. Il ne conserve pas le champ details (il ajoute seulement la description de KSeF pour le code 500), donc Odoo seul ne vous indique pas quelle partie de la facture a échoué.

Où trouver la cause

Le texte de details figure dans la réponse de KSeF à la requête de statut de la facture. Si vous envoyez depuis Odoo, il faut quelqu'un qui le lise depuis l'API, ou une vérification du fichier FA(3) avant l'envoi. Odoo 18, 19 et 20 incluent une copie du schéma FA(3) dans le module, mais hors des tests rien ne l'utilise : le fichier part vers KSeF sans être validé par rapport au schéma.

Odoo surveille tout de même deux points. Il n'envoie pas une facture datée après aujourd'hui dans le fuseau horaire de l'utilisateur (« The move was skipped because it is future-dated »). Et il remplit DataWytworzeniaFa avec le moment de génération du fichier, en UTC, si bien que la limite de 2025 ne devrait pas provenir d'une facture émise dans Odoo.

Comment la renvoyer

1. Trouvez la cause dans details, ou vérifiez le fichier FA(3) par rapport au schéma.
2. Corrigez les données dans Odoo : date, client, lignes.
3. Remettez la facture en brouillon. Pour une facture rejetée, Odoo efface son statut KSeF, son numéro, sa référence et sa session.
4. Confirmez-la puis renvoyez-la avec l'option « by KSeF (e-Faktura) ». Odoo n'envoie que les factures sans statut KSeF : sans l'étape 3, rien ne part.

Avec notre module

Poland KSeF 2.0 Validator n'envoie pas de factures à KSeF. Avec l'abonnement FlexigoTech Cloud, si vous cliquez sur « Validate FA(3) (FlexigoTech Cloud) » avant d'envoyer la facture, le module valide le fichier FA(3) par rapport au schéma 1-0E et affiche chaque erreur sous la forme d'une ligne « [error] XSD (chemin) » : l'emplacement dans le fichier, sans le texte du message, jusqu'à 100 erreurs. Le résultat n'empêche pas l'envoi par l10n_pl_edi : une facture « Not valid » part quand même si vous l'envoyez. Il ne détecte pas ce que KSeF ne contrôle que de son côté, comme P_1 par rapport au moment de réception. Lorsque l10n_pl_edi envoie la facture, la validation précédente passe à Expired et le module vérifie le fichier effectivement reçu par KSeF. Sous Odoo 17, il valide le FA(3) joint à la facture.

À lire aussi