Cómo proceder con las "copias de seguridad"

[espinete]

Supongo que hay varias formas de contemplarlo, pero nos acaba de surgir esta duda...

Normalmente el software permite realizar copias de seguridad, o de respaldo, en el formato que sea, etc. y obviamente, con una opción de restaurar/recuperar una copia de seguridad antigua, es decir, anterior a la fecha de hoy.

Esto ocurre bastante a menudo, por el motivo que sea: un PC que deja de funcionar, un virus, un daño irreparable en los archivos o en la BD, etc.

Imagina que el usuario no ha hecho copia de seguridad desde hace 20 días, o no sabe donde las guarda, o las guardó en un pendrive que perdió o que ya no funciona, o lo que sea.
Conclusión: tiene que recuperar datos de hace X días/semanas (todo eso después de culparte a ti por no tenerlas guardadas en tu casa también, claro, y de decir que el software de su cuñado es mágico y no le pasan estas cosas)

Total, ponte en ese caso:

- La última factura enviada a Hacienda fue ayer (la número 500), pero sin embargo en la BD del cliente, que es de la copia de hace X semanas, esa factura NO existe porque hemos viajado en el tiempo.
- La última factura que tiene el cliente en su BD/Historial, recién restaurada, es por ejemplo la 450. El resto se han perdido (aunque Hacienda sí que las tiene)

Aquí pueden pasar muchas cosas dependiendo de cómo hayamos afrontado este caso:
- que el encadenamiento lo hagamos usando una tabla que NO deba restaurarse/sobrescribirse nunca (así siempre sabremos la huella del último RF enviado aunque no lo tengamos en la BD, y podremos seguir enviando)
- usar el servicio de consulta de la aeat para obtener las últimas facturas, aunque no las tengamos en la BD. Al menos las tiene la AEAT
- al intentar crearlas a mano otra vez en el software, nos dé "duplicado", porque Hacienda ya las tiene

En fin... ¿cómo lo hacéis vosotros?

[Rja750]

Empezado por espinete

Supongo que hay varias formas de contemplarlo, pero nos acaba de surgir esta duda...

Normalmente el software permite realizar copias de seguridad, o de respaldo, en el formato que sea, etc. y obviamente, con una opción de restaurar/recuperar una copia de seguridad antigua, es decir, anterior a la fecha de hoy.

Esto ocurre bastante a menudo, por el motivo que sea: un PC que deja de funcionar, un virus, un daño irreparable en los archivos o en la BD, etc.

Imagina que el usuario no ha hecho copia de seguridad desde hace 20 días, o no sabe donde las guarda, o las guardó en un pendrive que perdió o que ya no funciona, o lo que sea.
Conclusión: tiene que recuperar datos de hace X días/semanas (todo eso después de culparte a ti por no tenerlas guardadas en tu casa también, claro, y de decir que el software de su cuñado es mágico y no le pasan estas cosas)

Total, ponte en ese caso:

- La última factura enviada a Hacienda fue ayer (la número 500), pero sin embargo en la BD del cliente, que es de la copia de hace X semanas, esa factura NO existe porque hemos viajado en el tiempo.
- La última factura que tiene el cliente en su BD/Historial, recién restaurada, es por ejemplo la 450. El resto se han perdido (aunque Hacienda sí que las tiene)

Aquí pueden pasar muchas cosas dependiendo de cómo hayamos afrontado este caso:
- que el encadenamiento lo hagamos usando una tabla que NO deba restaurarse/sobrescribirse nunca (así siempre sabremos la huella del último RF enviado aunque no lo tengamos en la BD, y podremos seguir enviando)
- usar el servicio de consulta de la aeat para obtener las últimas facturas, aunque no las tengamos en la BD. Al menos las tiene la AEAT
- al intentar crearlas a mano otra vez en el software, nos dé "duplicado", porque Hacienda ya las tiene

En fin... ¿cómo lo hacéis vosotros?

Asi por encima, sin profundizar y comprobar todo lo que te voy a decir, los tiros podrian ir por aqui:

Si tienes que entrar en el portal de hacienda para ver los registros enviados por tu cliente, tendrias que tener la firma digital de él, o entrar desde tu ordenador a su ordenador via remota y desde su PC entrar en hacienda. Seria buena practica tener en el menu principal del SIF un acceso al portal de la AEAT directamente. Meteria a mano el ultimo registro enviado en tu tabla de "registros_enviados" que debe tener cada cliente en su BD (no es obligatorio pero te quitara muchos dolores de cabeza) en tu campo huella pon la huella de registro, no del registro anterior con esto podrias seguir encadenando. Por mucho que quieras tener copias de seguridad actualizadas, siempre tendremos este problema porque algún registro se va a perder seguro, a no ser que dupliques las altas o servidores en espejo etc. Pero lo importante es que esos numeros que no se van a encontrar en la BD del cliente, esten declarados y tributados correctamente.

[[newtron]]

Eso es una movida importante que, efectivamente, habrá que ver cómo solucionar.


En el caso de pérdida de datos porque se ha recuperado una copia anterior en X facturas se pueden hacer dos cosas:


1- Pasar de esas facturas porque la aeat ya las tiene, no es problema. El problema es que seguramente el cliente querrá replicarlas para tener correcta la información.
2- Replicar las facturas aunque la aeat las tenga. El problema es cómo leches se replican sin tener que volver a enviarlas... se me ocurre retroceder contador y reenviarlas sabiendo que van a venir devueltas por duplicidad. Esto serviría pero es una chapuza.


No sé... la verdad es que es un tema que interesaría ver cómo resolver.

[Carlos]

Yo creo que hay 2 temas diferentes, muy diferentes.

Copias de seguridad del SIF... pués como hasta ahora ni más ni menos.

Copias de seguridad de los RF Veri*factu... pués no tienes porqué. Hacienda incluso te dice que no te pedirá los registros que ya has enviado.


Que se te pierde la información del último RF enviado a Veri*factu, pués debes tener un botón que te permita importar a la BB.DD. de tus RF el último RF enviado; y a partir de ese RF importado de Hacienda continuar enviando los que se generen a partir de ese momento.
Esto es lo que me respondió Hacienda.


Divide y vencerás.
El SIF por un lado y los RF por otro.

No me meto en modo No Veri*factu. Ahí ya no entro.

[Jarogo08]

Nosotros tenemos una opción que consulta las facturas que están en la AEAT. Desde esta opción, podrás detectar que la última que subiste es la 500, a pesar de que en el programa sólo habrá hasta la 450.
Desde esta misma pantalla, y estando situado en el registro de la factura 500, podremos "generar" esa factura en el programa. Sólo creamos el registro en la tabla de facturas e irá marcada de una manera concreta para saber que se creó desde esta opción y por tanto no genera registro de facturación.
Una vez creado este registro, la siguiente factura que hagamos va a ser la 501 (el número que le toca, porque nuestro contador sale del MAX()+1 de esta tabla). Entrará aceptada con errores, porque la huella anterior no será correcta (cogerá la de la factura 450, que es el último registro que tenemos en la tabla de registros de facturación). Pero bueno, entra igualmente... luego la subsanamos para que quede correcta y listo.


Podríamos llegar a coger incluso la huella que tiene esa factura para evitar que entre aceptada con errores (como dice Rja750), pero como tenemos estructurado el programa nos implicaría tocar y guardar cosas en la tabla de registros de facturación, y eso queremos evitarlo (integridad, inalterabilidad, bla bla bla).


Luego, con tiempo, se podrán recuperar las otras y meterlas en el programa si quiere el cliente (evidentemente no generarán registros de facturación, las tratamos como si fuera un traspaso de datos inicial: grabamos en la tabla de facturas pero no en la de registros de facturación)

[[newtron]]

Empezado por Jarogo08

Nosotros tenemos una opción que consulta las facturas que están en la AEAT. Desde esta opción, podrás detectar que la última que subiste es la 500, a pesar de que en el programa sólo habrá hasta la 450.
Desde esta misma pantalla, y estando situado en el registro de la factura 500, podremos "generar" esa factura en el programa. Sólo creamos el registro en la tabla de facturas e irá marcada de una manera concreta para saber que se creó desde esta opción y por tanto no genera registro de facturación.
Una vez creado este registro, la siguiente factura que hagamos va a ser la 501 (el número que le toca, porque nuestro contador sale del MAX()+1 de esta tabla). Entrará aceptada con errores, porque la huella anterior no será correcta (cogerá la de la factura 450, que es el último registro que tenemos en la tabla de registros de facturación). Pero bueno, entra igualmente... luego la subsanamos para que quede correcta y listo.


Podríamos llegar a coger incluso la huella que tiene esa factura para evitar que entre aceptada con errores (como dice Rja750), pero como tenemos estructurado el programa nos implicaría tocar y guardar cosas en la tabla de registros de facturación, y eso queremos evitarlo (integridad, inalterabilidad, bla bla bla).


Luego, con tiempo, se podrán recuperar las otras y meterlas en el programa si quiere el cliente (evidentemente no generarán registros de facturación, las tratamos como si fuera un traspaso de datos inicial: grabamos en la tabla de facturas pero no en la de registros de facturación)

Pues yo lo veo una opción estupenda.

[Faneka]

La verdad que no esta mal, eso si habría que recuperar las facturas que falten porque el cliente querra tener su contabilidad cuadrada, si solo recuperamos la última y hay un hueco de 50 mal vamos, jaja. Además que habra que generar los asientos, efectos, etc..., vamos como si se generaran de nuevo pero sin enviarlas. Me lo anoto como tarea pendiente
Para continuar por un numero concreto ahora que me acuerdo nosotros tenemos la opción de que la siguiente factura que se haga sea la número x. Esto es por ejemplo porque hay clientes que no reinician el contador en cada ejercicio, con lo que cuando hacen la primera del siguiente ejercicio quieren que continue por la factura número xxxx. Con esto podríamos salvar el que sigan generando facturas hasta restaurar las "perdidas".

[Jarogo08]

Empezado por Faneka

La verdad que no esta mal, eso si habría que recuperar las facturas que falten porque el cliente querra tener su contabilidad cuadrada, si solo recuperamos la última y hay un hueco de 50 mal vamos, jaja. Además que habra que generar los asientos, efectos, etc..., vamos como si se generaran de nuevo pero sin enviarlas.

Claro, claro... la opción que comento sólo es para poner el contador donde le tocaba y que no vuelvas a subir una factura con un número que ya existía.

Lo de recuperar los datos habrá que hacerlo igualmente si el cliente quiere, pero ya lo tratamos como un "traspaso de datos"

[Carlos]

Pero lo que se recupera de Hacienda no son facturas, son RF y entre sus datos está la huella que es precisamente lo que se necesita para enviar el próximo envío sin error a Veri*factu.

Imaginaos un OT que aplica retención de IRPF, pues en el RF no estará esa retención, no es su factura, es un RF.

Eso de recuperar RF y grabar datos en la tabla de facturas y no en la de RF... No sé. Lo veis adecuado?

[Carlos]

Empezado por Jarogo08

Podríamos llegar a coger incluso la huella que tiene esa factura para evitar que entre aceptada con errores (como dice Rja750), pero como tenemos estructurado el programa nos implicaría tocar y guardar cosas en la tabla de registros de facturación, y eso queremos evitarlo (integridad, inalterabilidad, bla bla bla).

En modo Veri*factu no existe la integridad, inalterabilidad, ... una vez enviado el RF, de hecho lo puedes borrar de tus tablas.

Empezado por Jarogo08

... pero como tenemos estructurado el programa nos implicaría tocar y guardar cosas en la tabla de registros de facturación, y eso queremos evitarlo ...

Pués precisamente de eso se trata, de guardar en la tabla de RF sus datos (y la huella lo es), todos sus datos, de esta manera sabes que se envió a Veri*factu.

Es tan 'defraudador' enviar una factura mal numerada que deje huecos, como enviar RF cuyas huellas no permiten la trazabilidad de los envíos.

[ermendalenda]

En mi caso contemplo 2 posibilidades, por que estoy solo:
1. Me pilla de vacaciones, reinstalacion rapida con nuevo numero de instalacion, solo teniendo en cuenta que los nuneradores de lss series sigan por el ultimo envio y si se pone dificil pues otra serie nueva, al haber una nueva instalaxion el encadenamiento es sin registro anterioe y ya cuando vuelva veo si hay que recuperar algo y mandarlo como subsanacion.
2- si veo que se puede arregkar rapido y no estiy en otro fregado, ya tengo consultas de lo enviado, recuperacion de copias etc.
El estar solo hay que considerar los planes B.

[espinete]

El hecho de que Hacienda ya tenga constancia de las facturas no te exime de la responsabilidad de tenerla también en tu SIF, porque siempre puede venir un cliente final que quiera hacer un cambio o devolución, y necesitarás esa factura (que has perdido) para hacerle la rectificativa, o incluso para consultar qué se le vendió, etc.

Nosotros creo que optaremos por hacer una opción en el SIF que permita "importar facturas no existentes desde la AEAT" o algo así, que cree los registros en la base de datos de facturas del SIF (si no existen ya, claro) pero que no se vuelvan a enviar a Hacienda.
Además, es la única forma de hacer que el software siga la numeración correlativa de facturas y no empiece por la 451 (que ya la tiene Hacienda) sino por la que realmente toca (la 501). No hay forma de engañar al software para que empiece por otro número no correlativo.

O como sugirió alguien: instalación nueva y cuando se haga la primera factura, entonces sí te pregunta por qué número quieres empezar, y ahí le pones el 501.

Pero claro, dejar que el usuario haga todo esto él solo es complicado, y no tenemos 3 o 4 clientes sino miles, así que hay que intentar hacerlo lo más intuitivo posible, rápido, transparente, etc. tanto para ellos como para nosotros.

Madre mía, se va a liar

[Rja750]

Hay que crear un algoritmo que importemos los RF´s de la AEAT donde estan todos los datos y volcar los datos en la tabla de Facturas y cuando termine el bucle, empezamos a volcar a la tabla de RF´s. El primer criterio que tenemos que tener en cuenta es el tipo de Factura.
-Si es una F1 sabemos que tenemos que volcar todos los datos, incluso los datos del cliente.
-Si es una F2 sabemos que tenemos que volcar sin datos de cliente.
Los datos están, lo que hace falta es volverlos a colocar en nuestro SIF. Si se fijáis en un registro del libro de registro o repositorio que tiene la AEAT, veréis todos los datos que nos hace falta para completar un registro de nuestra tabla de "Facturas" menos los conceptos, pero algo es algo. Si se completan las Facturas correctamente incluso se podrá rectificar.
En la tabla de Facturas tendríamos que poner un concepto inventado, solo un concepto porque esa factura recuperada solo tendrá una línea de detalle.
Creo que entre todos haremos una buena cabeza.

[espinete]

En efecto, está todo menos los conceptos, y el cliente los necesitará (por si le viene un cliente a hacer un cambio o devolución).

Lo que está claro es que serán situaciones de causa mayor, así que la responsabilidad no debería recaer toda sobre nosotros. Vamos, digo yo.

Nosotros tenemos que hacer funcionar el software, y que siga haciendo sus envíos a VeriFactu, así que deberíamos centrarnos en eso. Que el cliente pierda el contenido de las facturas ya NO es responsabilidad nuestra.
Lo que tenemos que conseguir es que pueda seguir enviando a VeriFactu sin errores, continuar con la numeración correlativa de facturas y respetar el encadenamiento.

Todavía no me he puesto a analizarlo con calma, pero creo que vamos bien encaminados: un botón/opción en el software, semi-escondido, para que en casos como este se puedan "importar RFs no existentes desde la AEAT". Al hacerlo, creamos en nuestras tablas de facturas los datos estrictamente necesarios, de forma que NO generen otro RF/envío, y obteniendo por lo tanto el último encadenamiento enviado, para continuar desde ahí.

Luego está la parte en la que al restaurar/recuperar una copia de seguridad antigua, no deberíamos sobrescribir la tabla que usemos para guardar los RFs enviados. Esa debería prevalecer siempre la versión más reciente, aunque también podrían importarse sus datos desde la AEAT.

En fin, cuando me ponga en serio intentaré ver los pros y contras o si hay alguna forma mejor de conseguirlo.

[ermendalenda]

Según que cliente, pero a un cliente de Retail con un problema de perdida de datos, y que le digss que es su problema, minimo adios cliente.
Vake que le recuperes como mencionas un par de registros o tres por que la subida al cloud es mas lenta que a verifactu. Pero una copia en la nube y constante para los que trabajan en software de escritorio, hoy en dia es fundamental.

[espinete]

Empezado por ermendalenda

Según que cliente, pero a un cliente de Retail con un problema de perdida de datos, y que le digss que es su problema, minimo adios cliente.

Pues adiós cliente, así de simple. Quien quiera software en la nube, que compre software en la nube. Quien quiera software de escritorio, que lo compre de escritorio.
Ambos tienen sus pros y sus contras. Lo que bajo ningún concepto vamos a aceptar es ser responsables de los PCs de los clientes. La mayoría no sabe ni buscar un archivo en el Explorador de Windows aunque lleven 20 años usando un PC. Sinceramente, no quiero clientes así, que usan un PC con Windows XP o 7 desde hace años, sin prestarle un mínimo de cuidado, mantenimiento, etc. creyendo que "eso va a funcionar siempre", lleno de virus, con el teclado manchado desde hace meses con teclas que no funcionan y que encima me culpen a mí de haber perdido los datos tras no haber hecho copias de seguridad en la vida. No, señor. Los datos los tienes tu en tu PC, no yo.

[bmfranky]

Hola, ya se que me diréis que es una burrada, pero forzar al cliente a hacer copias de seguridad cada X,(Yo las hago al salir del programa , pero soy muy neurótico y de momento tardan unos minutos), no seria una opción también?, haber puede ser una función en segundo plano, para que el cliente no se de ni cuenta, al final de cuentas, han de invertir en métodos para evitar apagones y demás, un pequeño cloud para hacer copias de seguridad, tampoco es que sea una barbaridad.
Podemos hacer pequeñas copias diarias y totales semanales por ejemplo y mas ocurrencias como poner discos en espejo de los datos, etc...
Otra cosa en lo que son muy claros, es que al reinstalar el programa aunque sea una copia de seguridad , se ha de poner un nuevo id, y por consiguiente empezar de nuevo el encadenamiento, así que solo hay que leer el ultimo registro enviado para saber el numero de factura, y empezar de nuevo desde ahí.

[Jarogo08]

Empezado por bmfranky

Hola, ya se que me diréis que es una burrada, pero forzar al cliente a hacer copias de seguridad cada X,(Yo las hago al salir del programa , pero soy muy neurótico y de momento tardan unos minutos), no seria una opción también?, haber puede ser una función en segundo plano, para que el cliente no se de ni cuenta, al final de cuentas, han de invertir en métodos para evitar apagones y demás, un pequeño cloud para hacer copias de seguridad, tampoco es que sea una barbaridad.
Podemos hacer pequeñas copias diarias y totales semanales por ejemplo y mas ocurrencias como poner discos en espejo de los datos, etc...
Otra cosa en lo que son muy claros, es que al reinstalar el programa aunque sea una copia de seguridad , se ha de poner un nuevo id, y por consiguiente empezar de nuevo el encadenamiento, así que solo hay que leer el ultimo registro enviado para saber el numero de factura, y empezar de nuevo desde ahí.

Pero al final no vas a evitar la pérdida datos... si haces una copia a las 10 de la mañana y otra a las 12 (poniéndonos muy optimistas), perderás los tickets/facturas creados en esas 2 horas. Y dependiendo del negocio, pueden ser 1-10-50-100 documentos tranquilamente. Con lo cual estás en el caso inicial de este hilo.

No veo nada fácil como evitar la pérdida de datos: habrá empresas en las que se puedan poner métodos más fiables (y más caros) pero en otros no podrás pasar como mucho de la copia diaria. Este es el principal motivo por el que nosotros descartamos hacer el modo No Verifactu

[Carlos]

Perdonad, pero... esto de la pérdida de facturas y demás que tiene que ver con Veri*factu?

Acaso en el 2022 no se podían perder las facturas?

Que si, que estamos con el SIF y demás, pero le estáis dando bombo a unos temas que ya existían antes de Veri*factu e incluso antes del Reglamento de Facturación (o como se llame).

Que si primero hago los registros de facturas a partir de los RF que recupero de Hacienda.... no será que primero hago los registros de RF que son precisamente lo que estoy recuperando de hacienda?

Y después ya veremos como recupero las facturas, que sin su detalle tendrán la misma información que los RF !!!!!

Entonces, para que recuperar regenerar los registros de facturas si estoy duplicando la información que ya está en los RF?

Lo que necesito para enviar el siguiente XML lo tengo en los RF recuperados (incluido el último número de factura), no me hacen falta los registros de facturas.

Si aparece una devolución pues la gestionaré a mano con lo que tenga, pero si no estaré desarrollando para 4 devoluciones en un supuesto de pérdida de facturas?

Cuantas facturas se han perdido en los últimos 10 años?

Estoy matando moscas a cañonazos?

Da la sensación que la facturación se ha inventado ahora con Veri*factu.

No sé si me explico bien.

Y disculpad mi atrevimiento.

[ermendalenda]

No solo no es nuevo, ahora el sistema tiene que garantizar la conservación, y lo unico que te libras en no conservar son los registros enviados, me rrmito a la ley antifraude.