Cita:
Empezado por ermendalenda
En el camppnde encadenamiento de cada factura enviada tienes que poner efectivamente el número de la anterior, pero las 2 anulaciones 3 y 4 carecen de número de factura, los números 3 y 4 son num3r9s correlativos que has puesto por seguir un orden, pero no es el número que piden. El encadenamiento tampoco es el número de factura que se anula eso es otro campo, en principio veo esos 2 errores de blockchain, el de las anulaciones y el de las repeticiones de envíos. Esperemos que lo aclaren
|
Efectivamente, los números de registros del 1 al 6 no son números de facturas; estos son, respectivamente, 22012, 22013, 22012, 22013, 22014 y 22015; las referencias a anteriores serían estos números, junto con el NIF del emisor, sus fechas, aquí 14/7, y sus respectivas huellas.
Resulta entonces en mi ejemplo que el registro 4 lleva el mismo número de factura que el registro 2, también mismo emisor, y también misma fecha de emisión de la factura; pero no la misma huella.
Realmente para realizar el encadenamiento, con solo la huella es suficiente (asumiendo que SHA256 es una función de hash perfecta). Las demás informaciones sobran, o mejor dicho son redundantes (y sabemos que estas redundancias ayudan y mucho al rendimiento).
Si resulta confuso, me parece hasta lógico, dado que en un diseño inicial, no había encadenamiento de los registros de anulación, esto se ha añadido en un segundo tiempo. No sé por qué, pero puedo ver dos razones:
- hay una posibilidad de fraude anulando registros, por ejemplo en relación con problemas con el sistema de llevar estos registros a Hacienda
- en practicas habituales, los registros de anulación serían mezclados con los registros de alta (por ejemplo tal como se ve si se mira empezando desde la contabilidad); sería por tanto el resultado del retorno de los editores de software