Duda sobre cómo actuar ante fallos hardware y verifactu

[jakematespain]

Asunto: Duda sobre cómo actuar ante fallo de disco en TPV con Verifactu

Hola a todos,

Tengo una duda importante sobre cómo gestionar un caso y me gustaría saber cómo lo vais a plantear vosotros o cómo lo estáis haciendo actualmente.

Caso:
Cliente con un TPV funcionando en modo Verifactu, trabajando en local (la base de datos no está en la nube). El sistema realiza copias de seguridad automáticas al arrancar el programa del TPV.

Ahora bien, el cliente empieza a trabajar y, tras unas horas, sufre un fallo de disco (por apagón, disco dañado, etc.). Mientras el TPV ha estado funcionando, los envíos a la AET se han estado realizando correctamente.

Aquí es donde surgen mis dudas:

¿Qué hacer en estos casos?
Lógicamente, el cliente quiere volver a vender cuanto antes, así que lo primero es poner en marcha el TPV en otro PC. Se restauraría la copia de seguridad de la mañana, pero aquí aparece el problema:
al empezar a vender, se generarían envíos que ya se hicieron, lo que podría causar errores por envíos duplicados.

Posibles soluciones que me planteo:
Consultar el último envío registrado en la AET y forzar que la siguiente factura simplificada tenga el correlativo correcto según ese último envío.

Crear una nueva instalación para ese cliente, de modo que arranque como si fuera la instalación número 2 (en lugar de la 1 original). Cambiar los datos del software (identificador de instalación, etc.) como si se tratara de una nueva tienda, evitando así colisiones con el histórico de la instalación anterior.

¿Vosotros cómo lo gestionáis en estos casos? ¿Cuál creéis que es la mejor práctica?

Esto no es una situación hipotética. No creo que haya que preguntarse si puede pasar, sino cuándo pasará, y es importante tener un protocolo claro.

¡Gracias de antemano por vuestras respuestas!

[Jarogo08]

Empezado por jakematespain

Consultar el último envío registrado en la AET y forzar que la siguiente factura simplificada tenga el correlativo correcto según ese último envío.

Nosotros tenemos una opción para consultar los registros subidos a la AEAT y desde ella, situándonos en el último registro subido, permitimos forzar el número de la próxima factura / ticket que vayas a crear, precisamente para casos como estos.

Al cambiar el servidor tendremos que regenerar la licencia (si no no arranca el programa), con lo que el número de instalación también cambiará. Esto implica que el primer registro que envíes desde el nuevo equipo irá marcado como "Primer registro", que es lo que dice la ley que debe ser

Empezado por jakematespain

Crear una nueva instalación para ese cliente, de modo que arranque como si fuera la instalación número 2 (en lugar de la 1 original). Cambiar los datos del software (identificador de instalación, etc.) como si se tratara de una nueva tienda, evitando así colisiones con el histórico de la instalación anterior.

Ojo, aunque cambies el número de instalación las colisiones las vas a tener igual. El obligado tributario no cambia (sigue siendo el mismo CIF quien envía), por lo que si hace una hora mandaste la factura 1 y ahora vuelves a mandarla te va a dar registro duplicado aunque hayas cambiado el número de instalación.

Saludos

[rci]

Empezado por jakematespain

al empezar a vender, se generarían envíos que ya se hicieron, lo que podría causar errores por envíos duplicados.

Buenas, no acabo de entender cuando dices que "se generarían envíos que ya se hicieron".
Si restauras la copia de seguridad de primera hora, todas las facturas ya están enviadas.

Puede que te refieras a que si no cambias nada, al hacer una nueva factura utilizaría una numeración que ya se utilizó antes para otras facturas y eso si seria un problema, pero esto ya pasaba antes de Veri*Factu, no?
Al restaurar la base de datos tendrás que mover los contadores de facturas para que no se utilicen los números que ya se han utilizado (y enviado)

Nosotros también estamos pensando en este caso, que ocurrirá muchas veces.

El tema está en el tiempo en que se ha creado la última copia de seguridad y el momento en que falla el sistema. Si se han hecho facturas, esos datos se han perdido, esas facturas en nuestro ERP no están y no se pueden recuperar de la copia porque es anterior, y necesitamos que las facturas vuelvan a estar en el ERP. Pero los registros de facturación si que se han enviado.

Antes de Veri*Factu algunos de nuestros usuarios, si disponían de copias en papel de las facturas, las volvían a entrar a mano usando los mismos contadores para volver a tener las facturas tal como eran originalmente, pero claro esto ahora no se puede hacer sin "daños colaterales".
Al volver a crear las facturas, si se pueden entrar exactamente igual, se crearían nuevos registros de facturación de alta y se enviarían y se recibiría error de duplicado, aunque esto no seria problema si es exactamente la misma factura.
Pero podría pasar que no puedas entrar las nuevas facturas en la misma fecha, y luego ya serian facturas distintas (fecha expedición forma parte de la clave) y esto si seria un problema porque tendrías la factura dos veces en AEAT.

Con la consulta de registros de facturación enviados, podemos obtener los RF que no están en la base de datos restaurada y hemos pensado que a partir de esos datos podríamos ofrecer al usuario un modo especial con la posibilidad de crear nuevas facturas, con la misma numeración, fecha de expedición y los datos que aparecen en el RF, para que el usuario los acabe de completar. Que el programa no permita salvar si no coinciden los datos y evidentemente al salvar creará un registro de facturación nuevo, que se enviará y será rechazado por registro duplicado. De esta forma volverán a existir las facturas en el ERP y cada una tendrá 2 registros de facturación, el original y el nuevo (duplicado).
De cara a AEAT estará bien informado y de cara al ERP las facturas estarán como estaban (o prácticamente).
el problema de este planteamiento es si alguna factura fue rechazada y no podemos obtener el RF a partir de la consulta a AEAT.

Esta es nuestra idea pero de momento no lo hemos desarrollado ni probado.

Saludos

[Jarogo08]

Empezado por rci

Buenas, no acabo de entender cuando dices que "se generarían envíos que ya se hicieron".
Si restauras la copia de seguridad de primera hora, todas las facturas ya están enviadas.

Supongo que se refiere a que si ayer quedaste en la factura 100 y es hasta donde tienes en la copia, hoy generas y envías hasta la 105 y luego se te fastidia el disco y restauras la copia, vas a volver a crear la factura 101, 102, 103, 104, 105 y también con fecha de hoy. Al enviarlas te darán error de duplicado

Empezado por rci

Antes de Veri*Factu algunos de nuestros usuarios, si disponían de copias en papel de las facturas, las volvían a entrar a mano usando los mismos contadores para volver a tener las facturas tal como eran originalmente, pero claro esto ahora no se puede hacer sin "daños colaterales".

Ahora puedes hacer la consulta en la página de la AEAT y las ves igualmente (otra cosa es que al meterlas vuelvas a crear otros registros de facturación)

[espinete]

Creo que deberíamos ser conscientes de que en los próximos 6 meses va a haber problemas, errores, circunstancias no previstas, clientes que hagan cosas muy raras, etc. Hacienda no debería empezar a ponerse seria con esto hasta que pase un tiempo prudencial.

Lo digo porque, con TicketBAI por ejemplo, nosotros hemos tenido problemas muy raros y difíciles de resolver porque algunos clientes han hecho cosas muy raras que no hemos previsto. Y da igual que lo hagas: siempre habrá una situación que no esperabas.
Y en todos los casos los de TicketBAI nos han ayudado siempre y dado el visto bueno (incluso con facturas que se perdieron en el limbo).

Nuestra idea es tener el software preparado para hacer envíos de prueba a partir del 28 de Julio, pero tenemos clarísimo que vamos a ir haciendo retoques, mejoras, etc. poco a poco hasta que llegue el día 1.
Y si Hacienda se pone tonta, más tontos nos pondremos nosotros. No es normal que de un día para otro esta gente empiece a multar, sancionar o lo que sea. Ya bastante difícil es controlar todo lo que ellos pretenden que controlemos: cambios en el hardware, pérdida de datos, etc. Ni que fuéramos especialistas en seguridad.

[ermendalenda]

Aquí veo varias cosas, no he leido todo el hilo y lo mismo ya te han respondido:
1-Si montas en otro tpv una copia debes cambiar el numero de instalación(Obligatorio), con lo cual lo que reenvies, estará duplicado en la AEAT para tí, pero no para ellos, ya que es otro SIF, y muy importante empezar un encadenamiento nuevo, no encadenar con el anterior.
2-Creo que es buena idea acceder al Servicio de consultas (webservice o web) para ver lo ultimo que hay enviado, y si tienes posibilidad de enviar lo pendiente de alguna forma como incidencia, con el número de instalación que correspondia, ya que el registro existia y no lo has modificado si has recuperado la copia, si solo lo tienes en tu BD, puedes tambien crear subsanaciones sin registro previo.

Tienes que tener en cuenta que si el problema que tienes es con la generacion de los registros para verifactu te dejan un margen para que el cliente pueda seguir vendiendo, pero sin emitir tiquets ni facturas y por supuesto sin QR, pero tienes que emitir algun documento como PRETIQUET o PREFACTURA e indicando claramente que tiene una incidencia puntual.

[jakematespain]

Gracias a todos por vuestras respuestas.
Desde nuestro software, al cambiar el número de tpv, se cambia la numeración para empezar desde 0. Los datos de las ventas hasta antes de la copia estarán, pero las ventas desde la copia hasta que se fastidio el disco no estarían, aquí creo que poco se puede hacer.

Como digo, como nosotros al cambiar el tpv, es como si fuera una instalación nueva, creo que lo que haremos es configurar como si fuera un nuevo tpv, nuevo numero de instalación,etc.

De esa forma, se crearan un nuevo registro de facturación asociado a esta nueva instalación (SIF).
Por ejemplo, si el último tiquet fue el 20251012345 (año-tpv-tiquets generados durante el año), ahora si indicamos que el tpv es el 2, tendremos la siguiente numeración 20252000001.

También se cambiará el número de facturación, para las facturas simplificadas, etc.

Creo que esto sería correcto, ¿veis alguna pega?

Gracias

[ermendalenda]

Empezado por jakematespain

Gracias a todos por vuestras respuestas.
Desde nuestro software, al cambiar el número de tpv, se cambia la numeración para empezar desde 0. Los datos de las ventas hasta antes de la copia estarán, pero las ventas desde la copia hasta que se fastidio el disco no estarían, aquí creo que poco se puede hacer.

Como digo, como nosotros al cambiar el tpv, es como si fuera una instalación nueva, creo que lo que haremos es configurar como si fuera un nuevo tpv, nuevo numero de instalación,etc.

De esa forma, se crearan un nuevo registro de facturación asociado a esta nueva instalación (SIF).
Por ejemplo, si el último tiquet fue el 20251012345 (año-tpv-tiquets generados durante el año), ahora si indicamos que el tpv es el 2, tendremos la siguiente numeración 20252000001.

También se cambiará el número de facturación, para las facturas simplificadas, etc.

Creo que esto sería correcto, ¿veis alguna pega?

Gracias

Sí, que nunca digas que has podidp perder registros y minimiza el riesgo todo lo que puedas, ppr ejemñlo con cppias de los registros en algun disco o servidor lo mas inmediatamente posible. Te en xuenta que está la ley de murphy, basta con que un cliente se de cuenta que tienes problemas, que como sea de los umtimos que hayas emitido tiquet con qr lo lea, y justo sean de lps que np vas a enviar nuca y rompen el encadenamiento, y eso es lo peor de lo peor.

[espinete]

Nosotros acabamos de darnos cuenta ahora de que esto puede ser realmente un problema. Me refiero a las copias de seguridad.

En las copias de seguridad se guarda toda la base de datos, con todas las tablas, etc. de una empresa. Es una copia exacta.
Si ocurre algo y hay que recuperar una copia de seguridad de ayer (o de hace un mes, que he visto casos), la tabla que guarda los RF, envíos, encadenamiento, etc. también está en esa copia de seguridad.
Eso significa que cuando hagamos una factura nueva, ese número de factura probablemente ya se ha hecho (y enviado). Además que el encadenamiento habrá "desaparecido".

Lo explico mejor con un ejemplo:
Día 1: hacemos la factura 100. Se guarda copia de seguridad.
Día 15: ocurre algo y hay que recuperar la copia del día 1, pero ya íbamos por la factura 200.

Cuando vayamos a hacer hoy una nueva factura (201), de la 100 a la 200 ya han sido enviadas, pero en el software no existen. Ni tenemos el encadenamiento de la 200.

¿Qué hacemos, no incluir la bd de los RF, etc. en las copias? ¿Y si se daña ese archivo de la BD concreto? ¿Comprobamos siempre antes de generar cualquier RF cual fue el último RF generado/enviado a Hacienda usando la Consulta a la AEAT, aunque tarde más?

[gcqZW]

Yo veo lo mas fácil, hacer consulta a la AEAT, sacar el ultimo id que le has enviado y seguir desde ahí

[emailesc]

Empezado por espinete

Nosotros acabamos de darnos cuenta ahora de que esto puede ser realmente un problema. Me refiero a las copias de seguridad.

En las copias de seguridad se guarda toda la base de datos, con todas las tablas, etc. de una empresa. Es una copia exacta.
Si ocurre algo y hay que recuperar una copia de seguridad de ayer (o de hace un mes, que he visto casos), la tabla que guarda los RF, envíos, encadenamiento, etc. también está en esa copia de seguridad.
Eso significa que cuando hagamos una factura nueva, ese número de factura probablemente ya se ha hecho (y enviado). Además que el encadenamiento habrá "desaparecido".

Lo explico mejor con un ejemplo:
Día 1: hacemos la factura 100. Se guarda copia de seguridad.
Día 15: ocurre algo y hay que recuperar la copia del día 1, pero ya íbamos por la factura 200.

Cuando vayamos a hacer hoy una nueva factura (201), de la 100 a la 200 ya han sido enviadas, pero en el software no existen. Ni tenemos el encadenamiento de la 200.

¿Qué hacemos, no incluir la bd de los RF, etc. en las copias? ¿Y si se daña ese archivo de la BD concreto? ¿Comprobamos siempre antes de generar cualquier RF cual fue el último RF generado/enviado a Hacienda usando la Consulta a la AEAT, aunque tarde más?

Nosotros guardamos en dos sitios: en la base de datos y en fichero en disco los XML normales, firmados y envío, además del log de cada registro (que tiene la huella generada). Estamos pensando en que la carpeta de esos archivos esté en una carpeta de Onedrive o similar (del cliente eso sí), que vaya haciendo copias según se crean los archivos. Sí el equipo peta al menos tendrás los archivos en la nube y podrás rehacer el todo. Esto para los clientes claro, también tenemos servicios SaaS centralizados pero esos va con copias continuas a otros servidores.

[espinete]

Empezado por gcqZW

Yo veo lo mas fácil, hacer consulta a la AEAT, sacar el ultimo id que le has enviado y seguir desde ahí

¿Pero esa comprobación la haces siempre, antes de generar nuevo RF? Sé que la consulta es rápida, pero no sé si fiarme de que un día tarde más de lo normal. A lo mejor en una cafetería que haga muchos tíckets por minuto lo veo delicado.
Quizás se podría hacer eso de consultar con la AEAT solo si se detecta algún salto en la enumeración o algo así, o siempre que se haya restaurado una copia de seguridad.
Tendré que darle una vuelta a ver...

[Faneka]

Yo creo que si se diera ese caso, con reiniciar el nº de instalación sobraría, con eso tambien reinicio los contadores de encadenamiento y demás, el siguiente envío se haría marcando el RF como primer envio.

[ermendalenda]

Si has enviado todo y pierdes datos en tu sistema, lo lógico (y obligatorio) es empezar con nuevo numero dr instalacion sin encadenar. No sé si te resuelve la duda
Edito:
Acabo de ver que han contestado justo igual

[espinete]

Empezado por ermendalenda

Si has enviado todo y pierdes datos en tu sistema, lo lógico (y obligatorio) es empezar con nuevo numero dr instalacion sin encadenar. No sé si te resuelve la duda.

No me queda claro que se tenga que usar otro "número de instalación" distinto. En realidad el PC/instalación es el mismo. Son los datos los que se han restaurado.

Va a estar super entretenido todo esto una vez empiecen los envíos

¿Cuándo se debe cambiar el número de instalación y, por lo tanto, empezar encadenamiento nuevo? Tener que cambiar el "número de instalación" si cambio de PC no lo termino de ver. La empresa es la misma, la enumeración es correlativa, etc. pero solo he cambiado de PC por uno nuevo.
Y tras una actualización del software, pues lo mismo: mismos datos, misma enumeración, misma empresa... no se debería iniciar un nuevo encadenamiento solo por eso.
¿Cuándo se debe cambiar entonces?