Por qué tumba el envío entero
El documento de validaciones de la AEAT distingue tres tipos de comprobación: estructurales, sintácticas y de negocio. Las estructurales miran que el XML cumpla el esquema, con sus etiquetas obligatorias, y si fallan el rechazo es del mensaje completo. Ese rechazo llega como un SoapFault y no queda registrada ninguna factura de la petición, tampoco las que estaban bien.
El texto de la lista oficial lo dice tal cual: «El XML no cumple el esquema. Falta informar campo obligatorio.» Está en el primer apartado, el de los códigos que rechazan el envío completo.

Lo que hace el módulo para que no llegue
Un solo registro mal formado arrastraría a todos los demás del mismo envío. Para evitarlo, el módulo valida cada registro contra el esquema oficial de la AEAT antes de mandarlo. Lleva una copia de ese esquema dentro, el fichero SuministroLR.xsd con sus dependencias, y el recorrido es este:
- Al publicar la factura Se crea su registro de facturación, que ya no cambia.
- En la siguiente vuelta de la cola Cada registro pendiente se convierte en XML y se valida contra el esquema.
- Si un registro no lo cumple Se da por rechazado en Odoo con el mensaje del esquema, sin código de la AEAT, y no sale.
- El resto Sale a la AEAT en la misma petición, sin el registro malo.
Así, un registro defectuoso no se lleva por delante las facturas buenas que viajan con él.
Cómo lo verás en Odoo
En la cola de envío, el registro detenido aparece en Failed con el mensaje del validador en el último error, en lugar de un código de cuatro cifras. Ese mensaje nombra el elemento que falta o que sobra, que es justo lo que necesitas para saber de dónde viene. En la lista de registros de facturación, su estado es «Rechazado AEAT», aunque la AEAT no llegó a verlo.

Antes incluso del esquema, hay datos sin los que el módulo ni siquiera construye el XML, y te lo dice con su propio mensaje:
Company … has no NIF for Veri*Factu.cuando la empresa no tiene NIF.Record … has no tax breakdown (Desglose) to declare.cuando el registro no tiene desglose de impuestos.
Si el 4102 llega de la AEAT
Si la respuesta con el 4102 viene de la propia AEAT, el registro pasó la validación local y la AEAT lo rechazó con su esquema. La explicación razonable es que el esquema de la AEAT y la copia que lleva el módulo ya no coinciden. En ese caso no sirve de nada reenviar: escríbenos a comercial@flexigobe.com con la respuesta completa, el campo Raw Response de la cola, para revisar la copia del esquema.
¿Puedo corregir el dato y reintentar?
Depende de dónde esté el dato. La cabecera se arma en cada envío con los datos de la empresa de ese momento: si el fallo estaba en el nombre, corrígelo y usa Reintentar Selección en Errores AEAT. Si estaba en el NIF, corregirlo no basta, porque el NIF también entró en la huella de cada factura al publicarla y el reenvío vuelve con el 2000. Si el dato está en el registro de la factura, el reintento manda lo mismo y volverá a fallar. En esos dos casos, escríbenos.
¿Se pierde la factura?
No. El registro sigue en Odoo, encadenado, y la cola procesa lo pendiente cada 1 minuto en cuanto el problema se resuelve.
Sigue leyendo
Comprobado en el código del módulo (versión 20.0) y en las fuentes enlazadas
Fuentes
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Código del módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Código del módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): data/verifactu_crons.xml
- Código del módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Código del módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_registro.py
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/err
- Código del módulo: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cadena.py
