El cálculo de la huella suministrada es incorrecta

[ermendalenda]

Empezado por emailesc

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...

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

[Carlos]

Empezado por ermendalenda

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.

[emailesc]

Empezado por ermendalenda

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

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é.

[ermendalenda]

Empezado por emailesc

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.

[Jarogo08]

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

[Carlos]

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.

[emailesc]

Empezado por Carlos

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.

Básicamente nosotros hacemos lo mismo, cuando toca generar un nuevo registro de facturación volvemos a recalcular la huella del registro anterior, si coincide con la que tenemos guardada seguimos creando el registro, si no, antes parábamos la creación de nuevos registros (y facturas) hasta tenerlo resuelto, ahora con el aporte de Jarogo08 solamente emitiremos una alarma, ya que además se debería haber respondido desde Verifactu en el registro anterior que la huella no coincide, y se arreglará más adelante, como el resto de registros que se pueden haber respondido con rechazos o aceptados con errores.
En principio no debe pasar nada por enviar el arreglo más tarde, ya que si bien hay un tiempo para enviar los registros de facturación (a la de ya), no lo hay para las rectificativas y subsanaciones. Y por otro lado incluso los de Hacienda dicen que la facturación no se debe parar (que ellos también cobran de ella).
Ahora la duda que se me plantea (esto es un sinvivir) es la siguiente: se pueden arreglar los rechazos que requieran una rectificativa desde otro SIF (del mismo OT), haciendo referencia a la factura rectificada. Pero, y ¿las subsanaciones? Lo estoy pensando mientras escribo, pero en el ejemplo que ha dado Jarogo08 creo que la subsanación de la factura 13 lo podría hacer también desde nuestro ERP (que tiene todos los datos de la factura y el registro) y no cambiaría nada... le sigo dando vueltas...

[bmfranky]

Empezado por emailesc

Básicamente nosotros hacemos lo mismo, cuando toca generar un nuevo registro de facturación volvemos a recalcular la huella del registro anterior, si coincide con la que tenemos guardada seguimos creando el registro, si no, antes parábamos la creación de nuevos registros (y facturas) hasta tenerlo resuelto, ahora con el aporte de Jarogo08 solamente emitiremos una alarma, ya que además se debería haber respondido desde Verifactu en el registro anterior que la huella no coincide, y se arreglará más adelante, como el resto de registros que se pueden haber respondido con rechazos o aceptados con errores.
En principio no debe pasar nada por enviar el arreglo más tarde, ya que si bien hay un tiempo para enviar los registros de facturación (a la de ya), no lo hay para las rectificativas y subsanaciones. Y por otro lado incluso los de Hacienda dicen que la facturación no se debe parar (que ellos también cobran de ella).
Ahora la duda que se me plantea (esto es un sinvivir) es la siguiente: se pueden arreglar los rechazos que requieran una rectificativa desde otro SIF (del mismo OT), haciendo referencia a la factura rectificada. Pero, y ¿las subsanaciones? Lo estoy pensando mientras escribo, pero en el ejemplo que ha dado Jarogo08 creo que la subsanación de la factura 13 lo podría hacer también desde nuestro ERP (que tiene todos los datos de la factura y el registro) y no cambiaría nada... le sigo dando vueltas...

Hola, la huella anterior no deberías re calcularla nunca, es desde mi punto de vista una perdida de tiempo de calculo y puede generar errores, guarda los datos necesarios de la huella anterior , en una tabla y recupera de ahí, el re calculo no lo veo necesario.

[emailesc]

Empezado por Jarogo08

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 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

Sí, es exactamente el error al que me refiero, y lo has explicado muy bien. Efectivamente con la huella H subsanamos la factura 13, y la huella anterior será la G, ya que lo encadenamos siempre al último registro. La verdad es que visto así, gráficamente, aparece mucho más claro, podemos ir hacia atrás desde la cadena H a la D verificando el encadenamiento, y este estará correcto, hasta llegar a la D, que seguirá mal en ese punto, pero se arregla posteriormente en la H, o si ponemos una columna más para los números de registro, el registro 17, factura 13, huella H. Con una sola subsanación se arreglaría el encadenamiento. De hecho no podría corregir el registro 14, factura 14, porque me daría exactamente la misma huella, ya que la corrección se hace posteriormente., y está encadenada correctamente con su registro anterior.
Gracias Jarogo08 por el ejemplo, me ha clarificado las cosas.

[bmfranky]

Hola, esta pregunta es recursiva aquí, se ha trasladado a verifactu en la aeat, varias veces y siempre contestan lo mismo, que subsanes con la huella del ultimo registro creado , aunque sea el que genero error, que es algo que tienen contemplado y no tendrá la mayor importancia, "Salvo que te pase de seguido", contestan lo mismo al limite de segundos, o timeout.


La verdad es que si has implementado bien en tu software, los métodos para calcular y registrar / recuperar las huellas anteriores, es muy difícil que se de el caso de error de encadenamiento, debería ser algo en lo que el usuario no pueda intervenir, tened en cuenta que este debe ser el ultimo paso antes del envío ( o puesta en cola), una vez sacado al envío/encolado , no se puede modificar nada que afecte a la creación de la huella, y si no podemos recuperar la huella anterior, es por fallos en la base de datos, y ahí seguro que tenemos mas problemas, que gestionar la subsanacion de la huella, por ejemplo una base de datos corrupta.

[ermendalenda]

Empezado por Jarogo08

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

Así es, pero es normal que piense que los siguientes encadenamientos están mal por que parten de uno erroneo, por eso añado que hay que tener en cuenta que para hacienda los demás están encadenando bien, aunque se basen en uno que han recibido mal(Aceptado con error de huella).

A raiz de este hilo pongo otro posible caso, que por lo que he visto en las exposiciones de algunos mensajes ed usuarios, se va a dar a menudo, a ver que pensais si es correcto:
-Se envia un registro con el nif incorrecto y lo rechazan
-Siguiente factura es correcta y la envio
-Si no me equivoco es aceptada con errores por que no encuentran el anterior encadenamiento que yo lo tengo pero me han rechazado, y por redondear más se ha enviado en el mismo lote que la anterior y no pude ni detectarlo para, si lo tengo controlado, proceder a la subsanación inmediata/automática, me he liado bastante.
-Con lo cual, también supongo: HAY QUE HACER 2 SUBANACIONES

Me respondo a mi mismo:
No hay devuelta de errores de encadenamiento, solo de la huella mal calculada y por tanto solo hay que subsanar/rectificar el del nif incorrecto

[emailesc]

Empezado por ermendalenda

Así es, pero es normal que piense que los siguientes encadenamientos están mal por que parten de uno erroneo, por eso añado que hay que tener en cuenta que para hacienda los demás están encadenando bien, aunque se basen en uno que han recibido mal(Aceptado con error de huella).

Sí, el tema viene de cómo nos lo reflejamos mentalmente: anteriormente cuando pensaba en la cadena situaba "al mismo nivel" el registro 13, el que está mal, y lo que sería la subsanación, el registro 17 de la factura 13, por lo que me decía, quitas un eslabón para arreglar otro, con lo cual el siguiente eslabón de la cadena ya no está enganchado. Ahora, viéndolo gráficamente, creo que es más una especie de "rotonda" o algo parecido

[ermendalenda]

Empezado por emailesc

Sí, el tema viene de cómo nos lo reflejamos mentalmente: anteriormente cuando pensaba en la cadena situaba "al mismo nivel" el registro 13, el que está mal, y lo que sería la subsanación, el registro 17 de la factura 13, por lo que me decía, quitas un eslabón para arreglar otro, con lo cual el siguiente eslabón de la cadena ya no está enganchado. Ahora, viéndolo gráficamente, creo que es más una especie de "rotonda" o algo parecido

Sí, además te digo que hasta para ello va a ser complicado de analizar los errores, sobre todo por la cantidad de "aceptado con errores" y por "el tiempo de espera para la subsanación" (que no han establecido), no creo que por que no subsanes algún "aceptado con errores" te vayan a enviar la inspección, ésto es más para que controles de que si se repite a menudo sí que vas a tener que actuar para reparar el problema, tendrán sus margenes de error para actuar.

Si te sirve de consuelo, he estado mirando "profundamente" varios softwares de TPV, y no he encontrado uno que cumpla 100% con todo lo que se regula en VERIFACTU y en el ROF, y sinceramente, no creo que estén buscando (al menos de momento) estás historias.

[emailesc]

No hay devuelta de errores de encadenamiento, solo de la huella mal calculada y por tanto solo hay que subsanar/rectificar el del nif incorrecto[/quote]
Hay un error, el 1180 Error en el bloque de encadenamiento, pero no creo que indique, efectivamente un error del encadenamiento en sí. Por lo que yo tenía entendido no se comprueba el encadenamiento en el envío. Esto es importante porque si ellos no devuelven un error de encadenamiento y nosotros no lo verificamos, no lo vamos a detectar hasta que nos lo requieran.

[CarlosArjonomia]

Empezado por emailesc

No hay devuelta de errores de encadenamiento, solo de la huella mal calculada y por tanto solo hay que subsanar/rectificar el del nif incorrecto Hay un error, el 1180 Error en el bloque de encadenamiento, pero no creo que indique, efectivamente un error del encadenamiento en sí. Por lo que yo tenía entendido no se comprueba el encadenamiento en el envío. Esto es importante porque si ellos no devuelven un error de encadenamiento y nosotros no lo verificamos, no lo vamos a detectar hasta que nos lo requieran.

Importante hacer nosotros mismos la trazabilidad de los encadenamientos, ya que ellos no la hacen y la podemos liar parda si no vigilamos esto.