Cómo proceder con las "copias de seguridad"

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