El cálculo de la huella suministrada es incorrecta
 

Hola,

En las anulaciones me esta saliendo este error, no consigo saber que esta mal. Podeis echarme una mano please?
Esta es la anulacion:
Esta es la respuesta:

Básicamente hago esto:
Huella = devuelveHuella(CIF, NUMER FACTURA SIMPLE QUE ANULO, FECHA DEL ENVIO DE LA FACTURA, LA ULTIMA HUELLA ENVIADA, FECHA)
Dudo de si la fecha es la del envio de la factura que anulo o la acual, pero he probado las dos y tengo el mismo error... No sé por donde tirar

Simple
Mete en una variable los valores de los camposCIF, NUMER FACTURA SIMPLE QUE ANULO, FECHA DEL ENVIO DE LA FACTURA, LA ULTIMA HUELLA ENVIADA, FECHA , y mandalos a pantalla o a un txt para poder verificar si te xoincide con los valores que te devuelven en la respuesta y encontrarás el error rápido.
Yo envion siempre esos valores del ultino registro generado a un txt(machacando el txt) por si hay algun problema y me ha servido varias veces dd verificacion.

Solucionado, que vergüenza... eran los nombres!!
IDEmisorFacturaAnulada, me faltaba donde dice ANULADA.

Bueno, revisándolo como me comentabas lo vi.

Vaya tela!!! Ya lo he visto en las estadisticas del INE, has bajado un 1,25 puntos el ranking de confianza general al gremio de desarrolladores de SIF. Ten cuidado que nos afecta a todos.:D

:D estoy con varias facturas electrónicas de varios países, sueño con nodos!

Joder macho, te van a convalidar hasta el C2 para todos los idiomas.

Una pregunta, en teoría, ante un rechazo o una aceptación parcial del envío de un registro de facturación, no necesitamos parar la venta para arreglarlo, podemos hacerlo más tarde mandando las correspondientes subsanaciones o rectificativas, excepto en el caso los errores en el encadenamiento, porque en caso de no hacerlo tendríamos que subsanar después toda la cadena de facturas, desde el error hasta la última factura emitida, lo cual, con sistemas que están continuamente facturando puede ser un gran problema. Nosotros al menos lo tenemos así: antes de generar un nuevo registro se verifica el encadenamiento del registro anterior. Si hay un error de encadenamiento (que entiendo que trabajando normalmente van a ser muy muy raros y por una confluencia de factores) la venta se para y se tiene que subsanar. Las demás respuestas no paran la venta. ¿Vosotros lo tenéis así o tenéis otro planteamiento? porque para la venta un sábado noche en un establecimiento de comida rápida te puede dar un infarto...

Solo tienes quw subsanar el que rompa el encaddnamiento, que será el que te ha devuelto el error, siempre que los demás sigan encadenando con este último, si son 2 pues 2 a subsanar.
Efectivamente puedes seguir facturando y ya lo subsanas cuando "te pille de buen humor"

En el caso del encadenamiento nosotros lo verificamos, aunque somos solo Verifactu, al intentar generar un nuevo registro de facturación, por lo que de ocurrir siempre va a ser un solo registro. Subsanarlo en principio debería ser algo fácil y rápido (si no salen cosas raras). Si lo arreglas en el momento (parando la facturación), Ok, sigues facturando con la cadena correcta.
Pero si lo dejas, o desactivo la verificación o no te das cuenta del error y sigues facturando, imaginemos que 100 facturas antes de darte cuenta, cuando subsanas el registro 0, el que tiene el error, no tengo claro si pierdes el encadenamiento, ya que al emitir la subsanación el registro 1, que estaba encadenado con la anterior huella 0 errónea, ya no queda encadenado correctamente, porque ahora la huella anterior es otra. Y así hasta la 100. ¿no tendrías que subsanar toda la cadena o lo estoy entendiendo mal?

Hola, puedes/tienew encadenar con el último, incluso si el último es el malo,.
Solo el erroneo.
Incluso si quiere puedes automatizar ese proceso de subsanacion, pero está claro que si pasa es que, normalmente, tienes algún error que debes tambien arreglar en el software.

Por ahora solo me ha pasado en pruebas, ya que estoy trabajando con varios centros y a veces al pasar de uno a otro no actualizo todo lo que debería. En teoría trabajando en un solo centro no debería pasar, pero cosas mas raras hemos visto todos, por confluencia de factores o por errores en la programación, así que si es un error que puede ocurrir... ocurrirá y además cuando mas inadecuado sea: un sábado por la noche con el local lleno, un inspector de hacienda en plena inspección, las impresoras rotas, la línea de internet caída y dos empleados de baja, uno de ellos el gerente...;)

Yo no tengo muy claro eso de comprobar que se ha hecho un envío correcto y en caso contrario pararlo todo porque, efectivamente, puede ser un problema. Por otro lado creo que no han puesto plazo para las subsanaciones/rectificaciones así que yo en particular lo que hago es un proceso que cuando se quiere revisa los envíos para manejar las devoluciones.

Nosotros no paramos todo por un envío incorrecto, puesto que no hace falta, se puede arreglar luego. Pero el caso de los errores de encadenamiento es distinto, si solo tienes que subsanar el registro erroneo y la cadena queda correcta, aunque hayas emitido otras facturas entre medias, bien, no paras, sigues y ya se hará, pero si por un error de encadenamiento tienes que restaurar toda la cadena, tienes que parar, porque si no la bola se hace cada vez más grande

Sí, todo eso pasa, es dificil preveee todos los problemas y sobre todo cuando confluyen varios, por eje.plp que se vaya el switch y ya te pasa lo de internet y si tienea las impresoras en red puea lo mismo.
Yo iguañmente hagl algo parecido a lo que comenta el compañero, aunque no paro la facturacion, no emito el doxumento xomo factura, si no como prefactura indixando en la mismade que hay una incidencia puntual y que pueden dejar un correo o venir despues por la factura, y si no tienes impresora se lo apuntan en un papel.
La aeat no quieres que dejes de facturar(vender), pero ai que nada mas resolverlo se envie todo
Por cierto , a mi me pasa la rotura de encadenamiento pero lo detecto antes de generar/enviar y ya se pone el sistema en modo alarma y solo emite prefacturas hasta que se arregle, pero para arreglarlo la primera opxion es semiautomatica, ya que creo que hay que esperar a um buen momento para hacerlo, y en cada nueva emision de prefacturaa advierto al usuario de que tiene que reparar

Veri*factu no es excusa para parar el negocio.
Si hay una incidencia, la que sea, que precise no enviar a Veri*factu, pues no se envía; se sigue facturando, se sigue imprimiendo las facturas, SE SIGUEN GENERANDO LOS REGISTROS DE FACTURACIÓN con su fecha y hora. Y mientras se busca que ha pasado; una vez resuelto se genera el XML con los 'n' RF (máximo 1000 por cada envío creo) y se envían con el indicador de incidencia. Y se documenta TODO que cuando vengan a cobrar (siempre cobran) se pueda explicar.

El arreglo del encadenamiento de un solo registro no lleva nada si lo detectas a tiempo: nosotros tenemos un botón que regenera el Registro de Facturación, lo encadena al erróneo y lo manda como subsanación. Es solo darle al botón. Pueden ser 10 segundos, pero eso sí mientras no se puede facturar. No obstante, aun así si pudiera evitar la parada lo preferiría. Mañana le preguntaré a los de Verifactu a ver si con subsanar el registro con el encadenamiento roto vale o en caso de que hubiese registros posteriores, habría que arreglar la cadena. Ya os contaré.

Ok, preguntalo, aunque ya te digo que esa pregunta a los de verifactu es recursiva, pero entiendo que te lo quieras asegurar, muy normal.

No sé muy bien a que te refieres con error de encadenamiento, pero no tienes que parar nada ni arreglar todas las que se hicieron posteriores. Sólo tienes que arreglar la que te dio error.

Pongo un ejemplo, y así también nos dices si es el error del que hablas

Factura Huella Huella Anterior
10..............A..............-
11..............B..............A
12..............C..............B

Ahora supongamos que subes la factura 13 pero obtienes mal la huella anterior, y por tanto te dará error:

13..............D..............X -> debería ser C, pero mandé X y devuelve error de huella

Ahora sigues haciendo más facturas, sin error

14..............E..............D
15..............F..............E
16..............G..............F

Cuando quieras corregir la factura 13 (aunque sea una semana después), tendrás que crear otro registro de facturación (una subsanación) y debe ser algo como esto:

13..............H..............G -> ahora ya va a entrar correcta

Como ves, no hay que corregir más que la que te dio error, las otras entraron correctas. No sé si me expliqué bien o si es el error del que hablas

Yo creo que el problema es mucho más gordo.

Hacienda contempla casos que no dependen de nosotros: caída de internet, hardware estropeado, cliente que devuelve lo que sea, el usuario que se equivoca de NIF, de % IVA, que el sistema de hacienda esté caído, ...

Pero no contempla que el software tenga errores y más aun cuando emitimos una declaración responsable de que hace lo que debe hacer; que si, que los ficheros se corrompen y todo lo demás

Yo intentaré evitar ese marrón de huellas incorrectas de la siguiente manera:

-Cuando creo el XML en ese momento cojo el RF que voy a enviar, busco su anterior (último tratado/enviado), genero la huella y la GUARDO (sólo guardo la última).
-En el siguiente registro hago lo mismo y además comparo la huella generada con la que tengo guardada, si coinciden sigo generando el XML y guardo la nueva última huella
-Si no coinciden permito que el SIF haga su tarea, que genere registros RF y busco el error, cuando lo soluciono envío los registros pendientes indicando valor en el campo 'incidencia'.

Es que no sé que es peor, enviar el XML 5 horas / 2 días más tarde o enviar una cadena de registros en donde se ha roto la trazabilidad de las operaciones, o no tomar medidas para evitar el error.
Al final cobraran, como siempre.