Duda sobre cómo actuar ante fallos hardware y verifactu

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

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

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

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

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