BYolivia · 2025

# Integración VeriFactu

Facturación electrónica obligatoria con la AEAT

Presentación del sistema de envío de facturas al sistema VeriFactu de la Agencia Tributaria, integrado en la suite de gestión empresarial.

## ¿Por qué VeriFactu?

### Obligación legal

- Reglamento de facturación electrónica (RD 1007/2023)
- Obligatorio para empresas y autónomos en España
- Cada factura debe enviarse a la AEAT en tiempo real
- Las facturas se encadenan con hash para garantizar integridad

### El reto técnico

- La AEAT usa SOAP/XML con firma digital
- Requiere certificado digital de empresa (FNMT/ACCV)
- TLS mútuo (mTLS) para autenticarse
- El software ERP (Dolibarr) no lo soporta de forma nativa

## El ecosistema del proyecto

Dolibarr ERP
datos de facturas
→
Backend
dolibarr-bff :5269
→
Front
doli-front :5173
→
VerifactuMidAPI
Go :6789
- - →
AEAT
VeriFactu
Implementado Dolibarr → Backend → Front → VerifactuMidAPI. El backend almacena el token que devuelve la API tras registrar el certificado.
Sin probar VerifactuMidAPI → AEAT. El envío real a VeriFactu no ha podido validarse por el tema del certificado. Es el único tramo pendiente de verificar.

## VerifactuMidAPI — Qué hace

- Recibe la factura en JSON (formato nativo o Dolibarr)
- Calcula el hash SHA-256 encadenado (norma AEAT)
- Genera el XML SOAP con todos los campos requeridos
- Firma digitalmente con el certificado de empresa
- Envía a la AEAT por SOAP con mTLS (TLS 1.2)
- Si la AEAT no responde → guarda en fallback local
- Devuelve el resultado al BFF

### Endpoints

`GET /health` | Estado
`GET /auth/public-key` | Clave RSA pública
`POST /auth/register` | Subir certificado P12
`GET /formats` | Formatos aceptados
`POST /facturas` | Alta de factura
`POST /facturas/anular` | Anulación

## Seguridad — Certificados y tokens

### Registro del certificado

- El front cifra la contraseña del .p12 con RSA (clave pública de la API)
- La API descifra, valida el P12 y lo almacena
- Soporta certificados FNMT y ACCV (multi-cert)
- La API extrae automáticamente los datos del emisor del propio certificado
- Devuelve un token de sesión para usar en los envíos

### Flujo de registro

Front: selecciona .p12 + contraseña
↓
Front: cifra pass con RSA pública
↓
API: valida, almacena, genera token
↓
BFF: guarda el token para futuros envíos

## Estado actual del proyecto

### VerifactuMidAPI (este repo — rama main)

✓ | Alta de facturas con hash encadenado
✓ | Anulación de facturas
✓ | Registro y validación de certificados P12
✓ | Soporte multi-cert (FNMT / ACCV)
✓ | Fallback local si AEAT no responde
✓ | TLS 1.2 + auto-fill datos emisor del cert
✗ | Consultas y subsanación (pendiente)

### Integración en el ecosistema (rama verifactu)

✓ | Front: subida del certificado P12
✓ | Front: cifrado RSA de contraseña
✓ | Front: recepción y uso del token
✓ | BFF: guardado del token en backend
⏳ | Pendiente de merge a main

La integración completa estaba bloqueada por el problema del certificado en la API, ya resuelto.

## Próximos pasos

### Inmediatos

- Merge de rama `verifactu` a main en front y BFF
- Pruebas end-to-end con el ecosistema completo
- Validar con certificado real en entorno de pruebas AEAT

### Siguientes funcionalidades

- Consultas a la AEAT (estado de facturas enviadas)
- Subsanación de facturas incorrectas
- Panel de estado VeriFactu en el front

El núcleo de la integración está completo y probado. El bloqueo original (gestión del certificado) está resuelto.