Verifactu en Spring Boot: cómo integrarlo

Mucha facturación seria vive en aplicaciones Java: ERPs internos, sistemas de gestión de pedidos, plataformas que llevan años funcionando. Si la tuya es de Spring Boot y emite facturas, Verifactu te toca. La buena noticia es que Spring Boot es un terreno cómodo para resolverlo, si se hace con orden.

El punto de partida: dónde nace la factura

Antes de escribir código hay que responder una pregunta que parece tonta: ¿en cuántos sitios de tu aplicación se crea una factura?

En sistemas con años suele haber más de uno: el servicio principal, un proceso por lotes que factura a fin de mes, una pantalla de administración que permite emitir manualmente, un servicio de abonos. Todos ellos son «puntos de emisión» y todos deben pasar por la misma capa de Verifactu. Si dejas uno fuera, tendrás facturas sin registro.

Registro en la misma transacción

Este es el punto técnico más importante. El registro de facturación debe guardarse en la misma transacción que la factura. Con @Transactional es sencillo si lo diseñas así desde el principio:

• Si se guarda la factura pero falla el registro, se deshace todo.
• Si se guarda el registro pero falla la factura, tampoco queda nada colgando.

Lo contrario, que es lo habitual cuando se «añade después», produce facturas sin registro o registros sin factura. Y esos huecos son difíciles de explicar.

La huella encadenada y la concurrencia

Cada registro lleva una huella (un hash) que incluye la del registro anterior. En un sistema con varios usuarios facturando a la vez, aquí aparece el problema real: dos peticiones simultáneas no pueden encadenarse al mismo registro anterior.

Hay que garantizar un orden estricto. Las formas habituales son un bloqueo sobre el último registro, una secuencia en base de datos o un proceso único que numere. No hay una única respuesta correcta; depende de tu volumen y de cómo esté tu base de datos.

El QR y el documento

La factura que recibe el cliente debe llevar el código QR y la leyenda que toque. Si generas PDFs con JasperReports, iText o plantillas HTML, es un cambio acotado: añadir el QR a la plantilla existente. No hay que rediseñar el documento.

Envío a la AEAT sin bloquear la venta

El envío debe estar desacoplado de la emisión. Tu aplicación emite la factura, guarda el registro y lo deja pendiente. Un proceso aparte, ya sea un @Scheduled, una cola con RabbitMQ o Kafka si ya la tienes, o un job sencillo, lo envía a la AEAT:

• Con reintentos si hay un fallo temporal.
• Respetando el tiempo de espera que indica la propia respuesta.
• Dejando constancia de cada intento y de cada error.

Con esto, una caída de la AEAT no para tu negocio. Y tienes un listado donde ver qué está aceptado, pendiente o rechazado. Hay más sobre este diseño en cola de envíos a la AEAT.

Monolito o microservicios

Si tu sistema tiene varios servicios que emiten facturas, hay que decidir quién mantiene la cadena. Lo más sensato es un único servicio responsable de los registros, al que los demás piden que registre. Repartir la cadena entre varios servicios es la receta para romperla.

Lo que suele salir al revisar

Cosas que encuentro con frecuencia en aplicaciones Java antiguas:

• Facturas que se editan directamente en base de datos para corregir errores.
• Numeración gestionada a mano o con huecos.
• Abonos que no están ligados a la factura original.
• Procesos batch que facturan sin pasar por el servicio principal.

Ordenarlo antes de empezar ahorra mucho dolor después.

Cuánto trabajo es

Depende más de la claridad de tu flujo de facturación que de Spring Boot en sí. Con un flujo ordenado, la integración es acotada. Con un flujo disperso, primero hay que concentrarlo. Lo explico en adaptar un ERP propio a Verifactu y tienes el enfoque general en Verifactu para Spring Boot.

Si tienes una aplicación Java y no sabes por dónde empezar, cuéntame cómo factura y lo vemos.

Preguntas frecuentes

¿Necesito actualizar Spring Boot? Depende de la versión y de Java. Se revisa antes de empezar y se evita tocar lo que no hace falta.

¿Funciona con JPA y con JDBC? Sí. Lo importante es poder guardar factura y registro de forma consistente.

¿Puedo integrarlo sin parar el sistema? Normalmente sí, con un despliegue por fases y pruebas previas en un entorno separado.