SERES desde Odoo: EDI y factura a la Administración sin una capa de más

Hay tres formas de que una factura salga de Odoo y llegue a SERES: teclearla a mano en su portal, pasarla por un middleware de terceros, o conectar el ERP directamente. La plataforma no la eliges tú —te la impone un cliente grande o un contrato público—, pero el número de capas sí. Y cada capa de más es un sitio donde un estado se queda a medias.

El plazo de cuatro días lo implementamos mal dos veces seguidas: al final está el diff.

Lo único que decides: dónde vive el estado de la factura

La pregunta es de arquitectura: dónde vive el dato de que una factura fue aceptada. Fuera de Odoo, alguien lo mira en otra pantalla y lo copia a mano. Dentro, junto al asiento, se filtra, avisa y concilia sin que nadie teclee.

Los tres caminos, medidos en trabajo diario

En dinero no se pueden comparar sin saber tu volumen y tu contrato. En trabajo diario sí.

El del medio domina los resultados de búsqueda: quien lo vende tiene un producto que vender. Sin equipo técnico es razonable, pero sabiendo qué compras: una capa más donde mirar cuando algo no cuadra.

Qué documentos viajan, y en qué formato

El Real Decreto 238/2026, de 25 de marzo (BOE del 31, en vigor el 20 de abril) fija en su artículo 7.1 que la factura electrónica se ajuste al modelo semántico EN16931 y use una de cuatro sintaxis: CII, UBL, mensaje EDIFACT de factura o mensaje Facturae.

Dos detalles del mismo artículo condicionan cualquier integración: toda factura emitida por una plataforma privada de intercambio va firmada con firma electrónica avanzada (7.3), y lleva un código único con NIF del emisor, número y serie y fecha de expedición (7.5). Eso lo produce el ERP, no el conector.

Cuándo empieza a apretar es otra cosa: la disposición final cuarta difiere los efectos doce meses para quien facture más de ocho millones de euros y veinticuatro para el resto, contados desde la entrada en vigor de la orden ministerial que desarrolla la solución pública de facturación. La fecha la fija esa orden, no tú.

Los pedidos y los albaranes son otra historia: el reglamento solo nombra el mensaje EDIFACT de factura. El pedido y el aviso de expedición viven en el acuerdo bilateral con tu cliente: eso no lo obliga el BOE, lo obliga él, y las reglas las pone él.

FACe: qué cambia cuando el cliente es la Administración

Aquí la norma es anterior y distinta. El artículo 4.1 de la Ley 25/2013 obliga a facturar a la Administración por el punto general de entrada que corresponda a sociedades anónimas y limitadas, entidades sin nacionalidad española, establecimientos permanentes de no residentes, las UTE y varias figuras más de esa misma lista. Las Administraciones pueden excluir por reglamento las facturas de hasta 5.000 euros: pueden, no deben.

Tres cosas que no hay en un B2B normal: treinta días para presentarla desde la entrega efectiva (artículo 3); firma electrónica avanzada basada en certificado reconocido (artículo 5.1); e identificar los órganos administrativos destinatarios (artículo 9.1): oficina contable, órgano gestor y unidad tramitadora. Sin esos códigos la factura entra y rebota días después.

En Odoo hay una trampa de versión. El módulo del núcleo l10n_es_edi_facturae («Spain - Facturae EDI», LGPL-3) genera Facturae 3.2.2 y lo firma con el certificado de la compañía. Pero en Odoo 17 los roles de centro administrativo los trae un módulo aparte, l10n_es_edi_facturae_adm_centers («Administrative Centers Patch» en su manifiesto, marcado auto_install). En 18 y 19 ese módulo ya no existe: sus datos viven dentro del principal. Al migrar desde 17, comprueba que esos roles siguen en la base de datos.

El plazo de cuatro días: lo que dice el BOE, palabra por palabra

Se repite que «la Ley Crea y Crece da cuatro días para comunicar el estado de la factura». La ley no dice eso. La Ley 18/2022, en su artículo 12, modifica el artículo 2 bis de la Ley 56/2007, y sobre estados solo dice una frase: «El destinatario y el emisor de las facturas electrónicas deberán proporcionar información sobre los estados de la factura». El plazo está en el reglamento. Real Decreto 238/2026, artículo 10.3, literal:

Ni días hábiles ni días naturales a secas: cuatro días naturales descontando sábados, domingos y festivos nacionales, un tercer cómputo. Y el 10.1 pone la obligación en el destinatario: cuando envías, el plazo lo tiene tu cliente; cuando recibes, lo tienes tú. Ese apartado exige además aceptación o rechazo comercial con su fecha, y pago efectivo completo con la suya.

El caso: nos comimos el cómputo dos veces seguidas

En la primera versión de nuestro conector de SERES para Odoo, el campo se llamaba verifactu_deadline y la columna decía «Plazo VeriFactu (4 días hábiles)». Dos errores en una etiqueta: ni sale de VeriFactu ni son días hábiles. Así se veía en Odoo 19:

Cambiamos la etiqueta y, con ella, la aritmética: fuera el bucle que saltaba fines de semana, dentro una suma directa de cuatro días.

-def _add_business_days(start, days):
-    current, added = start, 0
-    while added < days:
-        current += timedelta(days=1)
-        if current.weekday() < 5:  # Mon-Fri
-            added += 1
-    return current
+STATE_REPORT_DEADLINE_DAYS = 4
...
-    doc.verifactu_deadline = _add_business_days(doc.sent_date, 4)
+    doc.state_report_deadline = doc.sent_date + timedelta(days=STATE_REPORT_DEADLINE_DAYS)

Y ahí el segundo error: leer «cuatro días naturales» sin la coletilla que viene detrás. Con el documento de la captura, enviado el miércoles 8 de julio de 2026, salen tres fechas según cómo se cuente.

La lección: un plazo así no se escribe a mano en un campo calculado. Necesita el texto del BOE delante, un calendario de festivos nacionales como dato y un test del caso feo, el envío de la víspera de un puente. Un plazo mal calculado no revienta nada: avisa tarde, o avisa en domingo.

«Enviada» no es «aceptada»

El error más caro de estas integraciones es dar por buena una factura que solo está enviada. Un ciclo honesto tiene al menos seis estados —borrador, XML generado, enviado, aceptado, rechazado y error— y solo dos, aceptado y rechazado, dicen que alguien al otro lado la ha mirado. En la captura conviven cuatro: borrador, XML generado, aceptado y rechazado.

Con la misma honestidad: el canal de transporte con SERES todavía no está operativo en lo que hemos construido. El método que envía lanza una excepción explícita —no hay entorno de pruebas autoservicio— y los estados de esa captura los pone una acción de demostración marcada como tal en el registro.

Un último dato, por si alguien monta la recepción. Nuestro módulo llamaba a _get_edi_decoder sobre un recordset vacío. En Community funciona. En Odoo.sh, que corre Enterprise, account_invoice_extract lo sobrescribe con un ensure_one(), y un account.move() vacío revienta con «Expected singleton». Lo detectó la build real; el banco de pruebas local, que es Community, lo daba por bueno.

VeriFactu es otra cosa, y llega a la vez

Confundirlas cuesta dinero. La B2B regula el formato y el intercambio entre empresas. VeriFactu regula lo que hace tu software por dentro al emitir: el registro encadenado e inalterable de cada factura. Ninguna de las dos cubre a la otra. Si vas con ambas, empieza por qué es VeriFactu y cómo cumplirlo con Odoo.

Antes de decidir

• Dónde va a vivir el estado de cada factura, y quién lo mira cada mañana.
• Si tu ERP firma con firma electrónica avanzada y, con Administración de por medio, si oficina contable, órgano gestor y unidad tramitadora salen en el XML.
• Y si alguien te enseña una suite en verde, en qué corrió: Community en local y Enterprise en Odoo.sh no son lo mismo.

Quitar una capa no siempre es la respuesta correcta, pero casi siempre es la pregunta correcta: si la plataforma viene impuesta, lo que queda por decidir es si el estado de tus facturas vive dentro de tu ERP o fuera.

Preguntas frecuentes