[sglorka]

Empezado por antoine0

Este requisito está imponiendo a los sistemas que controlen sus datos anteriores para asegurarse que no hay fraude.


Pero sí puedes usar huellas para cumplirlo. Y creo que te incentivan a esto...


No creo que vaya a tanto. Tienes que poder detectar si hay un registro alterado, y en tal caso avisar.
Nota también que un sistema puede cumplir avisando si hay meras sospechas de alteración, aunque los registros son los originales, solo si pasa algo que no le cuadra al programa.
Otra cosa: hay casos que precisan de ensanchar los registros del sistema de facturación. El sistema debe continuar a cumplir aunque necesariamente los registros ya no son los originales (que eran más estrechos).



Si cambias algún dato en un registro, siga una fecha o cualquier otra cosa, la huella SHA256 del registro no será la misma; si los registros están encadenados —es decir, la huella del precedente es parte de los datos del registro— cambiar la huella SHA256 de uno cambia todas los siguientes huellas; incluyendo entonces el último registro.

Por tanto, si al generar o validar un registro compruebas que la huella del precedente (él que era el último) no coincide con la esperada, sabes que hay alguna alteración, y debes señalarla.

Y ocurre que en su gran sabiduría, AEAT nos pide guardar dicha huella dentro del nuevo registro...


Me parece una manera complicada de cumplir con la normativa. Mi archivo actual de facturación pesa más de 500 MiB, no me veo calculando la huella SHA256 a cada vez que quiero generar un nuevo registro. Además, un fichero de base de datos tiene habitualmente bytes de relleno sin usar que puedan cambiar de valor sin alterar los registros en sí (aunque esto sí puede ser un ejemplo de lo que he escrito arriba sobre las sospechas).

Quizás no me expliqué correctamente antoine0. Yo me he puesto en la situación más extrema. Imagina que diariamente voy generando los registros de facturación encadenados y correctamente fechados. Si no los envío de forma automática si no que los almaceno hasta que me los requiera la aeat yo puedo volver a generar esos registros con otra realidad diferente y su encadenamiento y fechado bien definido utilizando programas que permiten el cambio en la fecha de creación del fichero y por ende, mi nueva colección de registros de facturación será correcta. Por eso, para cumplir con el el apartado a). La integridad e inalterabilidad de los registros de facturación de forma que, una vez generados y registrados, no puedan ser alterados sin que el sistema informático lo detecte y avise de ello.
me imagino que deberíamos hacer algo más para certificar que esos registros fueron los creados originalmente.