Código 450 de KSeF: «Błąd weryfikacji semantyki dokumentu faktury»

Qué devuelve KSeF

En la especificación de la API de KSeF 2.9.0, el estado 450 de una factura en sesión tiene una descripción fija, «Błąd weryfikacji semantyki dokumentu faktury» (error de verificación semántica del documento de factura). Lo que falla en concreto lo añade KSeF en el campo details de ese mismo estado. El Ministerio de Finanzas polaco no publica la lista de esos mensajes, así que no existe una tabla del tipo «450 es siempre este fallo».

Lo que sí hay son casos que el Ministerio comprueba en las pruebas de su propia biblioteca ksef-client-csharp y en los que espera justo el código 450:

• fecha de emisión P_1 puesta en mañana según la hora polaca, porque KSeF lee P_1 en la zona horaria de Varsovia y no admite una fecha posterior al momento en que recibe la factura;
• DataWytworzeniaFa anterior a 2025-09-01T00:00:00Z, el límite inferior de ese campo en el esquema FA(3) 1-0E.

Qué ves en Odoo

Las facturas llegan a KSeF con el módulo l10n_pl_edi de Odoo, que existe en Odoo 18, 19 y 20. Cuando KSeF responde, pone «KSeF Status» en Rejected y escribe un mensaje en el historial de la factura:

De la respuesta de KSeF, Odoo lee el código, la descripción y el número KSeF. No guarda el campo details (solo añade la descripción de KSeF con el código 500), así que Odoo por sí solo no te dice qué parte de la factura falló.

De dónde sacar el motivo

El texto de details viene en la respuesta de KSeF a la consulta del estado de la factura. Si envías desde Odoo, necesitas a alguien que lo lea de la API o una comprobación del fichero FA(3) antes de enviarlo. Odoo 18, 19 y 20 traen una copia del esquema FA(3) dentro del módulo, pero fuera de las pruebas nada la usa: el fichero va a KSeF sin validarse contra el esquema.

Dos cosas sí vigila Odoo. No envía una factura con fecha posterior a hoy en la zona horaria del usuario («The move was skipped because it is future-dated»). Y rellena DataWytworzeniaFa con el momento en que genera el fichero, en UTC, así que el límite de 2025 no debería salir de una factura emitida en Odoo.

Cómo volver a enviarla

1. Saca el motivo de details o revisa el fichero FA(3) contra el esquema.
2. Corrige los datos en Odoo: fecha, cliente, líneas.
3. Restablece la factura a borrador. En una factura rechazada, Odoo borra su estado, número, referencia y sesión de KSeF.
4. Confírmala y envíala otra vez con la opción «by KSeF (e-Faktura)». Odoo solo envía facturas sin estado KSeF, así que sin el paso 3 no sale nada.

Con nuestro módulo

Poland KSeF 2.0 Validator no envía facturas a KSeF. Con la suscripción a FlexigoTech Cloud, si pulsas «Validate FA(3) (FlexigoTech Cloud)» antes de enviar la factura, valida el fichero FA(3) contra el esquema 1-0E y enseña cada fallo como una línea «[error] XSD (ruta)»: el sitio del fichero, sin el texto del mensaje, hasta 100 fallos. El resultado no frena el envío de l10n_pl_edi: una factura «Not valid» sale igual si la envías. No detecta lo que KSeF solo comprueba en su lado, como P_1 frente al momento de recepción. Cuando l10n_pl_edi envía la factura, la validación anterior pasa a Expired y el módulo revisa el fichero que recibió KSeF. En Odoo 17 valida el FA(3) que se sube a la factura.

Sigue leyendo