VeriSys por dentro: FSM, cadena SHA-256 y comunicación AEAT en tiempo real

VeriSys™ se diseñó alrededor de tres máquinas de estados (FSM) independientes pero coordinadas. Cada una resuelve un problema distinto y entre las tres cubren todo el ciclo de vida fiscal de una operación.

1. FSM de Documento: gobierna el ciclo de vida de la factura desde borrador hasta archivo (incluye rectificativas y anulaciones).
2. FSM de Registro fiscal: gobierna la relación con la AEAT — pendiente, enviando, aceptado, rechazado, reconciliado.
3. FSM de Integridad: gobierna la cadena de hashes — verifica que cada registro nuevo encaja con el anterior antes de persistir.

Las tres FSMs corren en paralelo. Una operación de venta dispara transiciones simultáneas en las tres y todas tienen que aceptar la transición — si una falla, la operación entera se aborta.

El núcleo de VeriSys es una tabla de decisión declarativa con 18 reglas que mapean una situación fiscal a una acción concreta.

Cada regla tiene la forma:

id: rule_R4_diff_vat
when:
  doc_type: invoice
  has_aeat_register: true
  delta_field: vat_amount
  delta_kind: differences
then:
  action: emit_R4
  legal_ref: "Art. 80.7 LIVA"
  side_effects: [chain_to_original, notify_customer]

El motor no toma decisiones por heurísticas: aplica reglas deterministas. Si una situación no encaja en ninguna regla, la operación se bloquea y se le pide al usuario que aclare el contexto. Esto es deliberado: preferimos que VeriSys diga «no sé qué hacer» antes que tomar una decisión incorrecta.

Las 18 reglas cubren todos los casos previstos en el RD 1007/2023, el RD 1619/2012 y la Orden HAC/1177/2024. Cuando la AEAT publica una nueva especificación, añadimos reglas a la tabla — el motor no tiene que cambiar.

Cada registro VeriFactu generado por VeriSys lleva un campo HuellaTBAI calculado como:

SHA-256(
  hash_anterior +
  numero_serie +
  fecha_emision +
  importe_total +
  nif_emisor +
  ...
)

El primer registro de la cadena (génesis) usa un hash de relleno definido por la AEAT. El segundo incluye el SHA-256 del primero. El tercero el del segundo. Y así sucesivamente.

Si alguien altera un registro pasado, el hash deja de coincidir con el siguiente y la cadena se rompe. La AEAT detecta el corte automáticamente. VeriSys también: el monitor de integridad en tiempo real recalcula la cadena cada noche y avisa si encuentra discrepancias.

Este monitor no es opcional: viene activo en todas las cuentas de FactuTPV.

VeriSys habla con los servicios web de la AEAT mediante SOAP 1.1, el protocolo que define la sede electrónica para los registros VeriFactu.

El flujo es:

1. VeriSys construye el SOAP envelope con el registro firmado.
2. Lo envía al endpoint https://www[1-7].aeat.es/wlpl/... según el ámbito (real o pruebas).
3. Espera la respuesta. Si llega Aceptado, marca el registro como confirmado.
4. Si llega Rechazado, lee el código de error, identifica si es transitorio (reintenta) o permanente (genera subsanación).
5. Si no llega respuesta en tiempo, programa un reintento con backoff exponencial y reconciliación periódica.

El reconciliador nocturno recorre todos los registros enviados y los contrasta con la AEAT para detectar desajustes (por ejemplo, registros que VeriSys cree enviados pero la AEAT no tiene). Esto cubre el caso de cortes de red durante el envío.

Una factura puede tener documentos hijos: rectificativas, anulaciones que la cancelan, sustitutivas que la reemplazan. Lo que no puede pasar es que se anule una factura que ya tiene una rectificativa pendiente, o que se rectifique una factura ya anulada.

VeriSys mantiene un grafo dirigido acíclico (DAG) de cada cadena documental. Antes de cualquier operación, el motor analiza el grafo:

• ¿Tiene la factura documentos hijos? Si sí, los lista al usuario y le pide confirmación.
• ¿Está ya en estado terminal (anulada, archivada)? Si sí, bloquea la operación.
• ¿Está pendiente alguna respuesta de la AEAT? Si sí, espera o avisa.

Esta política es lo que evita que un usuario se meta en líos sin querer. Es también lo que más nos ahorra llamadas de soporte: el motor responde por nosotros.

El RD 1007/2023 obliga a entregar la factura al cliente, pero no a guardar evidencia de cómo. La inspección sí lo pide.

VeriSys guarda automáticamente la evidencia de cada entrega:

• Impresión: timestamp, ID de la impresora, hash del PDF impreso.
• Email: dirección destinatario, message-id, timestamp de aceptación del SMTP.
• WhatsApp: número destinatario, ID de mensaje, timestamp de entrega.
• Descarga PDF: timestamp, IP cliente, user-agent.

Toda esta evidencia es exportable a CSV/JSON y firmada con el mismo SHA-256 chain, así que es auditable y no falsificable.

VeriSys tiene 832 tests automáticos que se ejecutan en cada commit. Cubren:

• Todas las transiciones de las 3 FSMs (cobertura 100%).
• Todas las 18 reglas de la tabla de decisión legal.
• Casos de error de la AEAT documentados en la Orden HAC/1177/2024.
• Reconciliación con timeouts simulados, datos corruptos, hashes alterados.
• Pruebas de carga: 10.000 facturas/hora sin pérdida ni desorden.

Cuando la AEAT publica una nueva versión de las especificaciones, lo primero que hacemos es añadir tests antes de tocar el código. Si los tests pasan en verde, el código está listo para producción.

Esa disciplina es lo que nos permite mantener VeriSys en producción sin un solo error de cumplimiento.