Cola de envíos a la AEAT con reintentos

Si trabajas en la modalidad de Verifactu con envío, tu sistema tiene que hablar con la AEAT cada vez que emite o anula una factura. Y ahí hay una decisión de diseño que separa las integraciones que funcionan de las que dan problemas: enviar desde una cola, no desde el flujo de la venta.

Por qué no enviar «en directo»

La tentación es sencilla: se emite la factura y, en la misma petición, se llama a la AEAT. Funciona en pruebas. En producción tiene varios problemas:

• Si la AEAT tarda o no responde, tu venta se queda colgada.
• Si hay un error temporal, ¿se cancela la factura? Sería un disparate.
• Si el cliente recarga la página, puedes enviar el registro dos veces.
• Un pico de ventas puede saturar las llamadas y provocar rechazos.

Una venta no debe depender de que un servicio externo esté disponible.

El diseño correcto, en cuatro pasos

1. Se emite la factura y se guarda el registro con estado pendiente, en la misma transacción.
2. Un worker independiente recoge los pendientes.
3. Los envía a la AEAT y actualiza el estado según la respuesta.
4. Si falla, reintenta más tarde.

La venta termina en el paso 1. Todo lo demás ocurre aparte.

Estados que necesitas

Para saber en cada momento qué pasa, cada registro debería tener un estado claro:

• Pendiente: guardado, aún no enviado.
• En envío: un worker lo está procesando (evita que dos lo tomen a la vez).
• Aceptado: la AEAT lo ha recibido bien.
• Aceptado con errores: recibido, pero con avisos que hay que revisar.
• Rechazado: hay un error que requiere corregir y volver a enviar.
• Fallo temporal: no se pudo enviar (red, servicio caído), se reintentará.

Sin esta distinción, no sabes qué facturas están afectadas cuando algo falla.

Reintentos con cabeza

No todos los fallos se reintentan igual:

• Fallos temporales (la AEAT no responde, error de red): reintenta con espera creciente (por ejemplo, 1 min, 5 min, 30 min…).
• Rechazos por datos (un NIF mal escrito, un importe inconsistente): no reintentes a ciegas, porque fallará siempre. Marca el registro y avisa para que alguien lo corrija.
• Tiempos de espera: la respuesta de la AEAT indica cuánto debes esperar antes del siguiente envío. Respétalo.

Idempotencia: el seguro contra duplicados

Si un envío se hace pero la respuesta se pierde, ¿lo reenvías? Cada registro debe poder consultarse y reenviarse de forma segura. Se guarda un identificador y se comprueba el estado antes de volver a enviar. Esto evita duplicados.

Orden: la cadena importa

Los registros llevan una huella encadenada. Aunque el envío sea asíncrono, la cadena se crea en orden al emitir, no al enviar. El envío puede ir con retraso, pero el orden de creación no cambia.

Un panel para no volar a ciegas

Lo que más valor aporta, y lo que más se olvida: una pantalla donde ver cuántos registros hay en cada estado, con los errores legibles y la opción de reintentar. El día que algo falle, te dirá en segundos qué facturas están afectadas.

Cuándo no hace falta tanta cola

Con volúmenes muy bajos puedes simplificar: un proceso cada pocos minutos que revise los pendientes. Lo importante no es la herramienta (RabbitMQ, Redis, un cron) sino los principios: desacoplar, registrar estados, reintentar bien y no duplicar.

Dónde se aplica

Este diseño sirve igual en Spring Boot, en Node.js, en una tienda Magento o en cualquier ERP propio. Si quieres que lo diseñemos para tu sistema, cuéntame tu caso.

Preguntas frecuentes

¿Qué pasa si la AEAT está caída varias horas? Los registros quedan pendientes y se envían cuando vuelva, sin perder ventas.

¿Se puede reenviar un registro rechazado? Tras corregir el dato que causó el rechazo, sí. Hay que seguir el procedimiento correspondiente y dejar constancia.

¿Necesito RabbitMQ o Kafka? No necesariamente. Para muchos casos basta una tabla de pendientes y un proceso periódico bien hecho.