Duda sobre cómo actuar ante fallos hardware y verifactu

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

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