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

Cosa restituisce KSeF

Nella specifica dell'API di KSeF 2.9.0, lo stato 450 di una fattura in sessione ha una descrizione fissa, «Błąd weryfikacji semantyki dokumentu faktury» (errore di verifica semantica del documento di fattura). Il problema specifico lo aggiunge KSeF nel campo details di quello stesso stato. Il Ministero delle Finanze polacco non pubblica l'elenco di quei messaggi, quindi non esiste una tabella del tipo «450 è sempre questo errore».

Esistono però casi che il Ministero verifica nei test della propria libreria ksef-client-csharp e in cui si aspetta proprio il codice 450:

• data di emissione P_1 impostata a domani secondo l'orario polacco, perché KSeF legge P_1 nel fuso orario di Varsavia e non accetta una data successiva al momento in cui riceve la fattura;
• DataWytworzeniaFa anteriore a 2025-09-01T00:00:00Z, il limite inferiore di quel campo nello schema FA(3) 1-0E.

Cosa vedi in Odoo

Le fatture arrivano a KSeF tramite il modulo l10n_pl_edi di Odoo, presente in Odoo 18, 19 e 20. Quando KSeF risponde, imposta «KSeF Status» su Rejected e scrive un messaggio nello storico della fattura:

Dalla risposta di KSeF, Odoo legge il codice, la descrizione e il numero KSeF. Non salva il campo details (aggiunge solo la descrizione di KSeF per il codice 500), quindi Odoo da solo non ti dice quale parte della fattura non è valida.

Dove trovare il motivo

Il testo di details arriva nella risposta di KSeF alla richiesta dello stato della fattura. Se invii da Odoo, ti serve qualcuno che lo legga dall'API o un controllo del file FA(3) prima dell'invio. Odoo 18, 19 e 20 includono una copia dello schema FA(3) dentro il modulo, ma fuori dai test nessuno la usa: il file va a KSeF senza essere validato contro lo schema.

Odoo controlla due cose. Non invia una fattura con data successiva a oggi nel fuso orario dell'utente («The move was skipped because it is future-dated»). E compila DataWytworzeniaFa con il momento in cui genera il file, in UTC, quindi il limite del 2025 non dovrebbe derivare da una fattura emessa in Odoo.

Come inviarla di nuovo

1. Recupera il motivo da details oppure controlla il file FA(3) con lo schema.
2. Correggi i dati in Odoo: data, cliente, righe.
3. Riporta la fattura in bozza. Per una fattura respinta, Odoo cancella il suo stato, numero, riferimento e sessione di KSeF.
4. Confermala e inviala di nuovo con l'opzione «by KSeF (e-Faktura)». Odoo invia solo le fatture senza stato KSeF, quindi senza il passo 3 non parte nulla.

Con il nostro modulo

Poland KSeF 2.0 Validator non invia fatture a KSeF. Con l'abbonamento a FlexigoTech Cloud, se premi «Validate FA(3) (FlexigoTech Cloud)» prima di inviare la fattura, il modulo valida il file FA(3) contro lo schema 1-0E e mostra ogni errore come una riga «[error] XSD (percorso)»: il punto del file, senza il testo del messaggio, fino a 100 errori. Il risultato non blocca l'invio di l10n_pl_edi: una fattura «Not valid» parte comunque se la invii. Non rileva ciò che KSeF controlla solo dal suo lato, come P_1 rispetto al momento della ricezione. Quando l10n_pl_edi invia la fattura, la validazione precedente passa a Expired e il modulo controlla il file effettivamente ricevuto da KSeF. In Odoo 17 valida il file FA(3) caricato sulla fattura.

Continua a leggere