Duda sobre cómo actuar ante fallos hardware y verifactu

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