[netsistemas]

RESUMIENDO: La factura que falle, se debe reenviar con el nuevo HASH generado, pero llevará la HUELLA DEL ANTERIOR.
Pensarás que esta factura, pierde el enlace con la siguiente, y es cierto, pero esto se informa a hacienda, indicando en este segundo envio:
-> Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí)​

TODA LA CUESTIÓN AMPLIADA: (DUDA y resputa de chatgpt con un INVESTIGACIÓN en profundidad: Eso que se tira 20 minutos.
)

En el sistema de envio de facturas VERIFACTU que se implementará proximamente en españa, hay un envio de facturas ENLAZADAS. Cada una se enlaza con la anterior, medienate un hash, que incluye la factura anterior, incluido su hash y la fecha y hora de envio.
Creo ver un problema cuando se hace un envio maximo de facturas. Se que máximo son 1000, pero si una de ellas es rechazada, como puede ser que quede todo bien enlazado.
En un envio de 5 facturas, si falla la segunda, la tercera, apuntará a la segunda, pero esta factura numero 2 ha podido ser rechazada, por lo que habrá que volver a enviarla correctamente y por tanto su hash sería modificado, lo cual afecta a todas las siguientes, que sí que fueron registradas.
Necesito que me expliques con claridad como se hace este encadenamiento de facturas y como se soluciona este problema o como lo tiene en cuenta la hacienda de españa (AEAT). sOY UN informatico que está desarrollando el sistema de envio de facturas.

ChatGPT Plus
¿Podrías confirmar si estás buscando una explicación técnica y actualizada del mecanismo de encadenamiento de facturas en el sistema VERI*FACTU de la AEAT, en especial cómo se gestiona el caso de errores o rechazos en facturas intermedias dentro de un lote (hasta 1000 facturas)? ¿Quieres que profundice en documentación oficial y fuentes técnicas de la AEAT sobre este aspecto?

Tú dijiste:
sÍ.

ChatGPT Plus
Perfecto. Voy a investigar cómo funciona exactamente el encadenamiento de facturas en el sistema VERI*FACTU de la AEAT, incluyendo cómo se maneja el caso de errores o rechazos en envíos de lotes de facturas enlazadas (por ejemplo, si una factura intermedia es rechazada y su hash cambia al reenviarse). También revisaré cómo la AEAT espera que se manejen estos escenarios desde el punto de vista del desarrollador.

Research completed in 14m· 19 fuentes
Encadenamiento de facturas en VERI*FACTU: funcionamiento técnico
Introducción
VERI*FACTU es el sistema de la Agencia Tributaria Española (AEAT) para garantizar la integridad y trazabilidad de las facturas emitidas mediante encadenamiento criptográfico de los registros de facturación. Cada factura generada por un Sistema Informático de Facturación (SIF) lleva asociada una huella hash única, calculada a partir de sus datos esenciales, que sirve como “fingerprint” digital​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. Esta huella se incluye en la siguiente factura emitida, creando una cadena inalterable: cualquier modificación de una factura alteraría su hash y ya no coincidiría con el incluido en la factura siguiente, evidenciando la manipulación. A continuación, se detalla cómo se construye técnicamente esta huella encadenada y cómo se maneja la consistencia de la cadena en envíos por lotes (hasta 1000 facturas a la vez) incluso si alguna factura intermedia es rechazada por la AEAT.
Cálculo de la huella criptográfica de una factura
¿Qué es la “huella” (hash) de un registro de facturación? En VERI*FACTU, la huella es un resumen criptográfico SHA-256 aplicado a ciertos datos clave del registro de la factura​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. Se calcula solo sobre campos específicos de la factura, no sobre la totalidad del documento. Esto produce un código de 256 bits (generalmente representado en 64 caracteres hexadecimales) único para esos datos; incluso el cambio mínimo en la información original produciría una huella completamente diferente​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. La huella actúa como identificador único inmutable de la factura dentro del sistema. Datos incluidos en el cálculo del hash: Para las facturas de emisión (registro de alta), la AEAT define un conjunto concreto de campos que se concatenan para calcular la huella​
AGENCIATRIBUTARIA.ES
. Los principales campos incluidos (en este orden) son:
NIF del emisor de la factura (IDEmisorFactura).
Serie y número de la factura (NumSerieFactura).
Fecha de expedición de la factura (FechaExpedicionFactura).
Tipo de factura (TipoFactura, por ejemplo F1 para factura completa).
Cuota total del impuesto (CuotaTotal, suma de las cuotas de IVA/IGIC).
Importe total de la factura (ImporteTotal, con impuestos).
Huella del registro anterior (Huella del Encadenamiento del registro previo).
Fecha y hora de generación del registro (FechaHoraHusoGenRegistro, con zona horaria).
Estos campos se extraen del fichero XML de la factura y se unen en una sola cadena de texto con el formato nombreCampo=valorCampo separados por &, siguiendo exactamente el orden indicado por la AEAT​
AGENCIATRIBUTARIA.ES
. El nombre de cada campo es literal (según el esquema XML) y el valor es el dato correspondiente tal cual figura en la factura, aplicando solo normalizaciones menores (trim de espacios en extremos y uniformidad de decimales)​
AGENCIATRIBUTARIA.ES
​
AGENCIATRIBUTARIA.ES
. Por ejemplo, si <NumSerieFactura> 12345678 / G33 </NumSerieFactura>, en la cadena se añade NumSerieFactura=12345678 / G33​
AGENCIATRIBUTARIA.ES
. Si un campo numérico como <ImporteTotal>123.1</ImporteTotal> se informa con un decimal, se considera equivalente a 123.10 a efectos del hash (es decir, los ceros finales no alteran el resultado)​
AGENCIATRIBUTARIA.ES
. En caso de que algún campo no tenga valor (o no aplique), igualmente se incluye su nombre seguido de =, pero sin ningún valor detrás​
AGENCIATRIBUTARIA.ES
. Una vez construida esta cadena de entrada (codificada en UTF-8), se le aplica el algoritmo SHA-256 para obtener la huella final​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. Esa huella (el hash resultante, normalmente expresado en hexadecimal) se almacena como un campo más dentro del propio registro de la factura en el SIF y en el envío a AEAT​
SEDE.AGENCIATRIBUTARIA.GOB.ES
.
Encadenamiento de facturas mediante hash
Inclusión de la huella previa en la siguiente factura: El sistema VERI*FACTU implementa la trazabilidad obligatoria encadenando cada registro de factura con el anterior. En la práctica, esto significa que cada nueva factura incorpora en sus datos la huella hash de la factura anterior, antes de calcular su propia huella​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. Como vimos, el campo Huella forma parte de los datos de entrada del hash; para la factura n, ese campo contendrá el hash calculado de la factura n-1. De este modo, al calcular la huella de la factura n, en el cómputo ya está entrelazado el identificador criptográfico de la factura previa. Esta “cadena” de hashes asegura que las facturas queden secuencialmente ligadas: si alguien alterara una factura anterior (por ejemplo, para eliminar ventas), cambiaría su hash y ya no coincidiría con el valor almacenado en la siguiente factura, rompiendo la cadena y delatando la manipulación. Factura inicial de la cadena: En cada sistema o serie de facturación habrá un primer registro (p.ej. la primera factura tras implementar VERI*FACTU o tras iniciar el año) que no tiene una factura previa. En ese caso, el campo de huella anterior se envía vacío. Por ejemplo, la primera factura de un SIF tendría en la cadena de entrada algo como ...&ImporteTotal=123.45&Huella=&FechaHoraHusoGenRegistro=01-01-2024T10:00:00+01:00 (obsérvese Huella= vacío)​
AGENCIATRIBUTARIA.ES
. La AEAT permite ese valor en blanco para iniciar el encadenamiento. A partir de ahí, cada registro de factura de alta incluirá siempre la huella calculada del registro inmediatamente anterior en el tiempo. Es importante destacar que el encadenamiento se realiza independientemente de la numeración de factura o la serie – lo que cuenta es el orden temporal de generación de los registros​
ESCURA.COM
. En otras palabras, el hash de encadenamiento siempre se refiere al último registro de facturación generado previamente por el SIF (en ese mismo sistema o cadena), garantizando una secuencia cronológica consistente. La AEAT verifica en cada envío la coherencia de la huella encadenada: recalcula internamente el hash de cada registro recibido y comprueba que coincide con el valor informado, y que el hash declarado como “anterior” coincide con la huella de la última factura aceptada previamente para ese emisor​
SEDE.AGENCIATRIBUTARIA.GOB.ES
. Si hubiera discrepancias (hash mal calculado, o referencia a una huella anterior que no concuerda), el registro sería rechazado por inconsistencia. Gracias a este mecanismo, mientras el SIF calcule correctamente las huellas y envíe la anterior en cada nueva factura, se asegura una trazabilidad robusta — cada factura queda encadenada a la siguiente de forma que no se puedan omitir ni falsificar registros sin ser detectados.
Envío por lotes y gestión de rechazos
Envío de facturas en lote: La plataforma VERI*FACTU soporta el envío electrónico de registros de facturación tanto de uno en uno como en lotes de hasta 1000 facturas por solicitud (siempre que correspondan al mismo obligado tributario). En un envío por lote, el SIF agrupa hasta mil registros (cada uno con su propia huella encadenada) y los remite conjuntamente. La AEAT procesa cada registro individualmente dentro del lote, respondiendo para cada factura si fue aceptada o si contiene errores. Importante: aunque se envíen juntas, todas las facturas del lote deben pertenecer a la misma cadena temporal (i.e. al mismo SIF o serie que lleva el encadenamiento correspondiente) para mantener la lógica de la huella anterior. La secuencia de hashes en el lote continúa la cadena: por ejemplo, si el último registro enviado anteriormente tenía la huella H_prev, la primera factura del nuevo lote llevará Huella=H_prev; luego la segunda factura del lote tomará la huella de la primera, y así sucesivamente. En resumen, el lote no rompe la secuencia, solo agrupa varios eslabones consecutivos de la cadena para enviarlos de una vez. Rechazo de una factura intermedia: Puede ocurrir que, al enviar un lote, alguna factura dentro de él sea incorrecta (p.*ej. datos obligatorios erróneos, NIF inválido, cálculo de hash mal formado, duplicidad, etc.) y la AEAT la rechace, mientras que otras facturas del mismo lote son válidas. ¿Qué sucede con la cadena en este caso? Según aclara la AEAT, no se rechaza el lote completo si el resto de registros están correctos, solo se rechaza la(s) factura(s) individual(es) con error​
ESCURA.COM
. Las facturas anteriores al registro rechazado ya habrán sido aceptadas normalmente, y las posteriores también pueden ser aceptadas (la respuesta del servicio indicará aceptación parcial del lote). Esto implica que facturas posteriores en el lote pudieron referenciar en su campo Huella a un registro que, en esa primera instancia, no fue admitido. A priori parecería que la cadena queda rota; sin embargo, la trazabilidad no se compromete, porque el encadenamiento se rige por el orden de generación de los registros, no por la secuencia numérica de las facturas​
ESCURA.COM
. Es decir, aunque una factura del medio fuese rechazada en el envío, en la cronología del SIF esa factura existió (se generó con cierta fecha/hora) y las siguientes se encadenaron a ella en aquel momento. La AEAT conserva esa referencia temporal de encadenamiento. Subsanación (reenvío) de la factura rechazada: Dado que un registro rechazado no puede alterarse ni “borrarse” (no se puede simplemente corregir el mismo envío erróneo), la solución es emitir un nuevo registro de facturación para esa misma factura con los datos corregidos, manteniendo su lugar en la secuencia temporal. La AEAT ha dispuesto un mecanismo de sustitución para estos casos: el nuevo registro de la factura debe enviarse indicando un “Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí)​
ESCURA.COM
. Con esta etiqueta, se deja claro que este envío corrige a un registro anterior que falló. En la práctica, el SIF generará un nuevo XML de esa factura (con la corrección necesaria, por ejemplo corregir un importe mal puesto) pero manteniendo los datos de identificación (misma serie/número, fecha de expedición original, etc.), y muy importante: conservará la referencia hash al registro previo de la cadena. De ese modo, al recalcular la huella para la factura subsanada, quedará nuevamente encadenada correctamente entre la anterior y la siguiente. Mantenimiento de la consistencia de la cadena: Gracias al procedimiento anterior, la consistencia del encadenamiento queda asegurada. Retomando el ejemplo, supongamos un lote con cuatro facturas (F1, F2, F3, F4) encadenadas: F1 no tiene huella anterior; F2 incluye la huella de F1; F3 incluye la huella de F2; F4 incluye la huella de F3. Si F3 es rechazada por un error, las facturas F1, F2 y F4 resultan aceptadas en ese envío inicial (F4 fue aceptada a pesar de contener la huella de F3)​
ESCURA.COM
. Ahora el desarrollador del SIF corrige F3 y la reenvía como sustitutiva. Esta Factura 3 (corregida) llevará el indicador de subsanación y tomará como huella anterior la de F2 (es decir, se inserta en la cadena después de F2, como originalmente debía). Al calcularse su nueva huella H3', es posible que H3' difiera de la huella original H3 (porque cambiaron datos para corregir el error). Sin embargo, la factura F4 que ya fue aceptada mantiene en AEAT la referencia a H3 (la huella original de F3). ¿Está entonces rota la cadena? Desde el punto de vista de la trazabilidad temporal, no: internamente la AEAT vincula los registros por su secuencia de generación y sabe que la F3 original fue sustituida por F3 corregida. La “brecha” queda cerrada con la nueva F3 sustitutiva, y la cadena cronológica de hashes (F1 → F2 → F3' → F4) permanece íntegra. En otras palabras, la trazabilidad se mantiene porque está ligada al orden en que se generaron los registros de facturación, no estrictamente a la secuencia numérica de las facturas físicas​
ESCURA.COM
. Desde la perspectiva del sistema, las facturas posteriores no necesitan reenviarse ni modificarse, ya que sus registros eran válidos. La AEAT simplemente actualiza la cadena insertando el nuevo registro subsanado en la posición correspondiente. Gracias a esto, una vez aceptada la factura corregida, la empresa tendrá sus cuatro facturas F1–F4 registradas correctamente y encadenadas en el orden debido, cumpliendo los requisitos de VERI*FACTU.
Conclusiones
El encadenamiento de facturas en VERI*FACTU se logra incorporando el hash de la factura previa en cada nuevo registro y calculando un SHA-256 sobre los campos clave, lo que garantiza que cada factura quede criptográficamente vinculada a la anterior. Este diseño aporta una alta seguridad: cualquier alteración rompe la cadena de hashes y puede ser detectada por la AEAT. En escenarios prácticos de envío masivo (por lotes), el sistema está preparado para preservar la consistencia incluso si alguna factura es rechazada: solo ese registro erróneo se subsana con un nuevo envío (marcado adecuadamente como sustitución), sin invalidar ni reprocesar el resto del lote​
ESCURA.COM
​
ESCURA.COM
. En resumen, la trazabilidad de la cadena de facturas se asegura manteniendo el orden temporal de los registros y encadenando sus huellas, de modo que el historial de facturación queda íntegro y verificado de extremo a extremo. Referencias: La información técnica aquí presentada se basa en la documentación oficial de la AEAT (FAQs de VERIFACTU, especificaciones técnicas de cálculo de huella​
AGENCIATRIBUTARIA.ES
​
SEDE.AGENCIATRIBUTARIA.GOB.ES
) y aclaraciones de sus expertos en foros y seminarios recientes​
ESCURA.COM
​
ESCURA.COM
, garantizando que los detalles reflejen fielmente el funcionamiento previsto del sistema VERIFACTU.




Fuentes





Tú dijiste:
en el ejemplo que me dices, la factura F3 debe ser enviada por segunda vez, indicando
Tipo de registro” sustitutivo y marcando el indicador de subsanación de error a “S” (Sí)​
Perfecto, pero la duda es que se envia con el nuevo hash acorde al nuevo timestamp o se envia el primer hash que se generó. En caso de generar el nuevo hash, ¿como saba la factura F4 el hash anterior si esta ha cambiado en el segundo envio?


ChatGPT Plus
He encontrado la información que necesitas.

🔑 Respuesta técnica a tu pregunta:
Cuando envías una factura corregida (F3 en tu ejemplo), debes seguir el siguiente procedimiento:

Generación de un nuevo hash:

Al reenviar F3 con el tipo de registro sustitutivo y el indicador de subsanación de error a “S” (Sí), debes generar un nuevo hash.

Este nuevo hash se genera con los datos corregidos y con la nueva fecha y hora de generación (timestamp).

Encadenamiento con la factura anterior (F2):

Al generar el nuevo hash de F3, debes incluir como HuellaAnterior el hash de la factura F2, que ya fue aceptada previamente.

Es decir, el hash nuevo de F3 no hace referencia al hash antiguo de la F3 errónea, sino que se enlaza directamente con el hash de F2.

¿Qué pasa con F4 (ya aceptada) que apuntaba al hash anterior de F3?:

Aquí está la clave: F4 NO se ve afectada.

Aunque F4 apuntaba al hash incorrecto de F3 (el original que fue rechazado), en el sistema de la AEAT queda registrado que F3 ha sido corregida.

La AEAT mantiene la consistencia de la cadena mediante la cronología de envíos, y la nueva F3 se inserta en la secuencia como válida.

El hash de F4 no se modifica, pero el sistema de la AEAT sabe que existe un registro sustitutivo válido para F3.

Conclusión:

Al reenviar F3, creas un nuevo hash basado en los datos corregidos y la nueva fecha/hora.

F4 sigue apuntando al hash antiguo de F3, pero la AEAT permite esto porque la subsanación se registra como una corrección oficial.

No es necesario reenviar F4 ni modificar su hash.