Hi ha tres maneres que una factura surti d'Odoo i arribi a SERES: teclejar-la a mà al seu portal, passar-la per un middleware de tercers, o connectar l'ERP directament. La plataforma no la tries tu (te la imposa un client gran o un contracte públic), però el nombre de capes sí. I cada capa de més és un lloc on un estat es queda a mitges.
El termini de quatre dies el vam implementar malament dues vegades seguides: al final hi ha el diff.
L'únic que decideixes: on viu l'estat de la factura
La pregunta és d'arquitectura: on viu la dada que una factura ha estat acceptada. Fora d'Odoo, algú ho mira en una altra pantalla i ho copia a mà. Dins, al costat de l'assentament, es filtra, avisa i concilia sense que ningú teclegi.
Els tres camins, mesurats en feina diària
En diners no es poden comparar sense saber el teu volum i el teu contracte. En feina diària sí.
| Camí | Qui tecleja | On viu l'estat | Què es trenca primer |
|---|---|---|---|
| Portal web, a mà | Una persona, factura a factura | Només al portal | El dia que aquesta persona falta. A Odoo tot continua «enviat» |
| Middleware d'un tercer | Ningú, mentre tot vagi bé | Al middleware, i de vegades també a Odoo | Els estats: dues veritats que no coincideixen |
| Connexió des de l'ERP mateix | Ningú | A Odoo, al costat de la factura | Si la plataforma canvia el canal, et toca a tu |
El del mig domina els resultats de cerca: qui el ven té un producte per vendre. Sense equip tècnic és raonable, però sabent què compres: una capa més on mirar quan alguna cosa no quadra.
Quins documents viatgen, i en quin format
El Reial decret 238/2026, de 25 de març (BOE del 31, en vigor el 20 d'abril) fixa a l'article 7.1 que la factura electrònica s'ajusti al model semàntic EN16931 i faci servir una de quatre sintaxis: CII, UBL, missatge EDIFACT de factura o missatge Facturae.
Dos detalls del mateix article condicionen qualsevol integració: tota factura emesa per una plataforma privada d'intercanvi va signada amb signatura electrònica avançada (7.3), i porta un codi únic amb NIF de l'emissor, número i sèrie i data d'expedició (7.5). Això ho produeix l'ERP, no el connector.
Quan comença a apretar és una altra cosa: la disposició final quarta difereix els efectes dotze mesos per a qui factura més de vuit milions d'euros i vint-i-quatre per a la resta, comptats des de l'entrada en vigor de l'ordre ministerial que desenvolupa la solució pública de facturació. La data la fixa aquesta ordre, no tu.
Les comandes i els albarans són una altra història: el reglament només anomena el missatge EDIFACT de factura. La comanda i l'avís d'expedició viuen en l'acord bilateral amb el teu client: això no ho obliga el BOE, ho obliga ell, i les regles les posa ell.
FACe: què canvia quan el client és l'Administració
Aquí la norma és anterior i diferent. L'article 4.1 de la Llei 25/2013 obliga a facturar a l'Administració pel punt general d'entrada que correspongui a societats anònimes i limitades, entitats sense nacionalitat espanyola, establiments permanents de no residents, les UTE i diverses figures més d'aquesta mateixa llista. Les Administracions poden excloure per reglament les factures fins a 5.000 euros: poden, no han de.
Tres coses que no hi ha en un B2B normal: trenta dies per presentar-la des del lliurament efectiu (article 3); signatura electrònica avançada basada en certificat reconegut (article 5.1); i identificar els òrgans administratius destinataris (article 9.1): oficina comptable, òrgan gestor i unitat tramitadora. Sense aquests codis la factura entra i rebota dies després.
A Odoo hi ha una trampa de versió. El mòdul del nucli l10n_es_edi_facturae («Spain - Facturae EDI», LGPL-3) genera Facturae 3.2.2 i el signa amb el certificat de la companyia. Però a Odoo 17 els rols de centre administratiu els porta un mòdul apart, l10n_es_edi_facturae_adm_centers («Administrative Centers Patch» al seu manifest, marcat auto_install). A 18 i 19 aquest mòdul ja no existeix: les seves dades viuen dins del principal. En migrar des de 17, comprova que aquests rols continuen a la base de dades.
El termini de quatre dies: el que diu el BOE, paraula per paraula
Es repeteix que «la Llei Crea y Crece dona quatre dies per comunicar l'estat de la factura». La llei no diu això. La Llei 18/2022, a l'article 12, modifica l'article 2 bis de la Llei 56/2007, i sobre estats només diu una frase: «El destinatario y el emisor de las facturas electrónicas deberán proporcionar información sobre los estados de la factura». El termini és al reglament. Reial decret 238/2026, article 10.3, literal:
«La información sobre los estados de la factura deberá remitirse en un plazo máximo de cuatro días naturales, excluyendo sábados, domingos y festivos nacionales, desde la fecha en que se produce el estado que se informa en cada caso.»
Ni dies hàbils ni dies naturals a seques: quatre dies naturals descomptant dissabtes, diumenges i festius nacionals, un tercer còmput. I el 10.1 posa l'obligació en el destinatari: quan envies, el termini el té el teu client; quan reps, el tens tu. Aquest apartat exigeix a més acceptació o rebuig comercial amb la seva data, i pagament efectiu complet amb la seva.
El cas: ens vam menjar el còmput dues vegades seguides
A la primera versió del nostre connector de SERES per a Odoo, el camp es deia verifactu_deadline i la columna deia «Plazo VeriFactu (4 días hábiles)». Dos errors en una etiqueta: ni surt de VeriFactu ni són dies hàbils. Així es veia a Odoo 19:

Vam canviar l'etiqueta i, amb ella, l'aritmètica: fora el bucle que saltava caps de setmana, dins una suma directa de quatre dies.
-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)
I aquí el segon error: llegir «quatre dies naturals» sense la coletilla que ve darrere. Amb el document de la captura, enviat el dimecres 8 de juliol de 2026, surten tres dates segons com es compti.
| Còmput | Data | Veredicte |
|---|---|---|
| 4 dies hàbils (v1) | dimarts 14 de juliol | Correcta per casualitat, etiqueta falsa |
| 4 dies naturals a seques (v2) | diumenge 12 de juliol | Dos dies abans, i en diumenge: exclòs |
| Article 10.3 del RD 238/2026 | dimarts 14 de juliol | El bo: descomptant dissabte 11 i diumenge 12 |
La lliçó: un termini així no s'escriu a mà en un camp calculat. Necessita el text del BOE al davant, un calendari de festius nacionals com a dada i un test del cas lleig, l'enviament de la vigília d'un pont. Un termini mal calculat no rebenta res: avisa tard, o avisa en diumenge.
«Enviada» no és «acceptada»
L'error més car d'aquestes integracions és donar per bona una factura que només està enviada. Un cicle honest té almenys sis estats (esborrany, XML generat, enviat, acceptat, rebutjat i error) i només dos, acceptat i rebutjat, diuen que algú a l'altre costat l'ha mirada. A la captura en conviuen quatre: esborrany, XML generat, acceptat i rebutjat.
Amb la mateixa honestedat: el canal de transport amb SERES encara no és operatiu en el que hem construït. El mètode que envia llança una excepció explícita (no hi ha entorn de proves d'autoservei) i els estats d'aquesta captura els posa una acció de demostració marcada com a tal al registre.
Una última dada, per si algú munta la recepció. El nostre mòdul cridava _get_edi_decoder sobre un recordset buit. A Community funciona. A Odoo.sh, que corre Enterprise, account_invoice_extract el sobreescriu amb un ensure_one(), i un account.move() buit rebenta amb «Expected singleton». Ho va detectar la build real; el banc de proves local, que és Community, ho donava per bo.
VeriFactu és una altra cosa, i arriba alhora
Confondre-les costa diners. La B2B regula el format i l'intercanvi entre empreses. VeriFactu regula el que fa el teu programari per dins en emetre: el registre encadenat i inalterable de cada factura. Cap de les dues cobreix l'altra. Si vas amb ambdues, comença per què és VeriFactu i com complir-lo amb Odoo.
Abans de decidir
- On viurà l'estat de cada factura, i qui el mira cada matí.
- Si el teu ERP signa amb signatura electrònica avançada i, amb l'Administració pel mig, si oficina comptable, òrgan gestor i unitat tramitadora surten a l'XML.
- I si algú t'ensenya una suite en verd, en què va córrer: Community en local i Enterprise a Odoo.sh no són el mateix.
Treure una capa no sempre és la resposta correcta, però gairebé sempre és la pregunta correcta: si la plataforma ve imposada, el que queda per decidir és si l'estat de les teves factures viu dins del teu ERP o fora.
Preguntes freqüents
El termini de quatre dies són dies hàbils o naturals?
Cap de les dues. L'article 10.3 del Reial decret 238/2026 diu «cuatro días naturales, excluyendo sábados, domingos y festivos nacionales». És un còmput propi, i l'obligació recau sobre el destinatari de la factura, no sobre qui l'emet.
Puc enviar la factura a l'Administració directament des d'Odoo?
Odoo genera el Facturae 3.2.2 i el signa amb el certificat de la companyia. Comprova que la factura porti oficina comptable, òrgan gestor i unitat tramitadora: a Odoo 17 aquests centres administratius vénen apart i a 18 i 19 ja són al mòdul principal. Sense ells, el punt general d'entrada la rebutja.
La factura electrònica B2B i VeriFactu són la mateixa obligació?
No. VeriFactu regula com genera i protegeix el teu programari cada registre de facturació per dins. La factura electrònica B2B regula el format i l'intercanvi entre empreses, amb el seu propi calendari. Complir una no et cobreix l'altra.
El que fem sobre això
Tens SERES imposat i Odoo per dins?
Explica'ns què t'exigeix el teu client i en quina versió d'Odoo estàs, i et diem què es pot fer des de l'ERP i què no. Escriu-nos a comercial@flexigobe.com o truca al +34 616 809 504.
