Implementación VeriFactu en sistema multi-puesto

[Neftali [Germán.Estévez]]

Empezado por nincillo

¿creéis que sea "obligatorio" el que hash, encadenamiento etc se cree ya en el propio momento de generar la factura?. Realmente el retardo entre la generación de la factura y el envío, generación de hash, etc sería el tiempo programado entre envíos, que realmente sería el que nos indicó la propia hacienda en el envío anterior.

Nosotros hemos entendido que el registro de facturación debe generarse en el momento de crearse la factura.
Hay que tener en cuenta que puedes tener una incidencia (por caida de internet, por ejemplo) y que estés 1 día completo sin enviar. Si generas los registros al enviar, la fecha del registro podría no coincidir con la fecha de la factura y eso no puede ser (la ley dice que la fecha de la factura y del registro debe ser la misma). Si asignas la fecha de la factura al registro (de 1 día antes) tendrás registros del día X-1 que se han generado el día X. Raro.

Además está esta imagen, que creo que es la primera que puso la AEAT del funcionamiento de VERI*FACTU en la primeras presentaciones (y que ya pusimos en el foro). Fíjate en el orden de los puntos.


Te está diciendo:
1) Generar el RF
2) Enviar
3) "Simultáneamente" imprimir la factura con el QR.

Si por un problema (como hemos dicho antes) no puedes enviar, ya sea tuyo o que los servidores de la AEAT han caído, debes poder continuar con el funcionamiento del sistema. Y eso quiere decir que aunque no puedas hacer completar el paso (2), debes poder realizar los otros (1) y (3).

De todas formas tampoco aseguro que DEBA ser así 100%.
Así es como lo hemos hecho nosotros, porque como también tenemos la opción de NO-VERI*FACTU, necesitamos hacerlo al crear la factura para que el mismo proceso nos sirva para las 2 modalidades. De esta forma da igual si luego envías (VERI*FACTU) o no (NO-VERI*FACTU), el RF ya está creado.

[Faneka]

Nosotros lo tenemos igual, cuando se genera la factura se genera el RF, si se puede enviar se envia, sino se marca como incidencia y cuando haya conexión se envia, pero sino se puede enviar se puede imprimir con el QR la factura, que si el cliente en ese momento que la reciba lo leyera pues no estaría en la AEAT, pero bueno, es el proceso que hay que seguir, cuando se pueda enviar ya podría volver a comprobar que esta en la AEAT.

[Jarogo08]

Pues yo, a riesgo de liar todo un poco más, no tengo muy claro si tiene que ser así obligatoriamente.

Porque si hay que crear y enviar al momento... ¿que sentido tiene que puedas agrupar hasta 1000 registros en un sólo envío? tendrían que ser envíos individuales de 1 factura. Porque no creo que ningún programa sea capaz de crear 1000 facturas al mismo tiempo, en el mismo segundo.

Nosotros lo que hacemos es:

-al crear la factura ya le asignamos el QR y creamos el registro de envío.
-ese registro de envío se envía X segundos después, no al momento. Puede ser 1 segundo o 59, dependiendo del servicio. Pongo un ejemplo:

Tenemos el servicio que envía lo pendiente cada 60 segundos (realmente el tiempo lo marca la respuesta del envío anterior, pero para no liarlo más supongamos 60). Por tanto, si estoy haciendo un proceso de facturación del mes por ejemplo de 500 facturas y le lleva X minutos terminar, puede ser que el servicio saltara justo 10 segundos antes de empezar el proceso y no hubiera nada pendiente. Entonces volverá a saltar 1 minuto después (es decir, cuando el proceso de facturación lleva 50 segundos generando facturas). En ese momento puede detectar por ejemplo que hay 150 facturas y las envía. Saltará otra vez 1 minuto después, y ahí detecta por ejemplo otras 300 facturas. Otra vez dentro de 1 minuto y detectará otras X facturas... y así sucesivamente todo el día.

De esta manera la factura se va a enviar como máximo 60 segundos después de generarse, pero irán en bloques de X facturas, las que encuentre. Como decía al principio si tiene que ser sí o sí generar la factura y enviarla no le veo sentido a que se pueden agrupar hasta 1000 registros.

¿soy el único que lo ve o lo tiene planteado así?

[espinete]

Empezado por Jarogo08

Pues yo, a riesgo de liar todo un poco más, no tengo muy claro si tiene que ser así obligatoriamente.

Porque si hay que crear y enviar al momento... ¿que sentido tiene que puedas agrupar hasta 1000 registros en un sólo envío? tendrían que ser envíos individuales de 1 factura. Porque no creo que ningún programa sea capaz de crear 1000 facturas al mismo tiempo, en el mismo segundo.

Nosotros lo que hacemos es:

-al crear la factura ya le asignamos el QR y creamos el registro de envío.
-ese registro de envío se envía X segundos después, no al momento. Puede ser 1 segundo o 59, dependiendo del servicio. Pongo un ejemplo:

Tenemos el servicio que envía lo pendiente cada 60 segundos (realmente el tiempo lo marca la respuesta del envío anterior, pero para no liarlo más supongamos 60). Por tanto, si estoy haciendo un proceso de facturación del mes por ejemplo de 500 facturas y le lleva X minutos terminar, puede ser que el servicio saltara justo 10 segundos antes de empezar el proceso y no hubiera nada pendiente. Entonces volverá a saltar 1 minuto después (es decir, cuando el proceso de facturación lleva 50 segundos generando facturas). En ese momento puede detectar por ejemplo que hay 150 facturas y las envía. Saltará otra vez 1 minuto después, y ahí detecta por ejemplo otras 300 facturas. Otra vez dentro de 1 minuto y detectará otras X facturas... y así sucesivamente todo el día.

De esta manera la factura se va a enviar como máximo 60 segundos después de generarse, pero irán en bloques de X facturas, las que encuentre. Como decía al principio si tiene que ser sí o sí generar la factura y enviarla no le veo sentido a que se pueden agrupar hasta 1000 registros.

¿soy el único que lo ve o lo tiene planteado así?

El 50% de mis clientes enviarán una factura al día. Otros enviarán 1 factura por minuto COMO MUCHÍSIMO. Solo algunos casos (cafeterías o empresas con muchas cajas) enviarán más de una factura por minuto.
En nuestro caso, hacer el control de flujo, tiempos de espera, etc. será completamente innecesario (y un lío para nosotros y para el cliente), pero no queda más remedio que contemplarlo por si las moscas.

Hacienda ya me respondió hace unos días (la respuesta no recuerdo si la puse en este hilo o en otro) que "si nos ceñimos a lo que dice el reglamento, el envío debe hacerse de forma simultánea, es decir, al generar la factura, y no está prohibido, ni dará error, hacer los envíos una a una". PEEEERO, como no me fío un pelo de esta gente, tendré que implementar ambas opciones, no vaya a ser que a mitad de año cambien de opinión y nos pille a alguno de vacaciones

Sería todo más fácil si se enviara la factura al emitirla. Una a una. Sin nada de "incidencia", sin control de tiempo de espera, etc. (como ocurre con TicketBAI desde hace 2 años, y nadie se ha quejado ni ha explotado nada). Pero esta gente prefirió hacerlo así (que está muy bien para casos extremos, vale) y habrá que hacerlo, pese a que requiera más control, puede provocar más problemas, etc.

Yo de todas formas les envié un email hace unos días explicándoles las consecuencias y requisitos que supone usar el control de flujo. Incluso en las empresas debería haber un encargado de revisar si hay facturas con incidencias, pendientes, si se está ejecutando el "enviador", si se detuvo por algún problema y lleva días sin enviar...
En fin, no sé si ellos son conscientes de los inconvenientes, pero está claro que tendremos que pasar por el aro y los clientes tendrán que acostumbrarse a revisar cada cierto tiempo que no hay nada pendiente y que todo está "abierto y funcionando".

[Jarogo08]

Empezado por espinete

El 50% de mis clientes enviarán una factura al día. Otros enviarán 1 factura por minuto COMO MUCHÍSIMO. Solo algunos casos (cafeterías o empresas con muchas cajas) enviarán más de una factura por minuto

Claro... nosotros no tenemos esa casuística. A lo mejor en el día a día no vas a tener más de 3 o 4 facturas/tickets por minuto pero cuando llega la facturación a final de mes pueden aparecer en un par de minutos 500 o más facturas

Empezado por espinete

"si nos ceñimos a lo que dice el reglamento, el envío debe hacerse de forma simultánea, es decir, al generar la factura, y no está prohibido, ni dará error, hacer los envíos una a una"

pues si lo quieren así que no habiliten la opción de mandar 1000 a la vez, y ya no habría dudas

Empezado por espinete

Incluso en las empresas debería haber un encargado de revisar si hay facturas con incidencias, pendientes, si se está ejecutando el "enviador", si se detuvo por algún problema y lleva días sin enviar...
En fin, no sé si ellos son conscientes de los inconvenientes, pero está claro que tendremos que pasar por el aro y los clientes tendrán que acostumbrarse a revisar cada cierto tiempo que no hay nada pendiente y que todo está "abierto y funcionando".

En nuestro caso, cada vez que queremos generar una factura nos avisa si hay alguna sin enviar desde hace más de 2 minutos, pero deja continuar. Así el usuario sabe que está pasando algo con el envío. Puede ser por ejemplo que no tenga internet durante un par de días y sea consciente y quiera seguir creando y acumulando facturas que se enviarán tan pronto se pueda, o puede ser que el servicio esté parado y de esta manera se entere y pueda ponerlo otra vez a funcionar antes de seguir acumulando registros para enviar

[Faneka]

Nosotros no tenemos ningún programa secundario que este esperando a que se generen las facturas para enviarlas. El programa cuando genera una o x facturas inmediatamente despues lanza el modulo que envia los RF, si hay alguna incidencia se muestra en pantalla directamente. Asi el cliente sabra si todo fue bien o hubo alguna factura que tiene que rectificar o subsanar.
Nuestros clientes no son de venta continua (TPV,...) , generaran la facturación una vez a la semana o algunas sueltas al día.

[Neftali [Germán.Estévez]]

Empezado por Jarogo08

Porque si hay que crear y enviar al momento... ¿que sentido tiene que puedas agrupar hasta 1000 registros en un sólo envío? tendrían que ser envíos individuales de 1 factura. Porque no creo que ningún programa sea capaz de crear 1000 facturas al mismo tiempo, en el mismo segundo.

Cuando habla de enviarla al momento, se refiere a que no puedes esperar 4 días como en el SII.
En esta caso y por los 60 segundos mínimos, se entiende que al momento es dentro de ese intervalo, por eso la posibilidad de enviar paquetes.

Empezado por Jarogo08

Tenemos el servicio que envía lo pendiente cada 60 segundos (realmente el tiempo lo marca la respuesta del envío anterior, pero para no liarlo más supongamos 60). Por tanto, si estoy haciendo un proceso de facturación del mes por ejemplo de 500 facturas y le lleva X minutos terminar, puede ser que el servicio saltara justo 10 segundos antes de empezar el proceso y no hubiera nada pendiente. Entonces volverá a saltar 1 minuto después (es decir, cuando el proceso de facturación lleva 50 segundos generando facturas). En ese momento puede detectar por ejemplo que hay 150 facturas y las envía. Saltará otra vez 1 minuto después, y ahí detecta por ejemplo otras 300 facturas. Otra vez dentro de 1 minuto y detectará otras X facturas... y así sucesivamente todo el día.
...
¿soy el único que lo ve o lo tiene planteado así?

Nosotros lo tenemos exactamente igual.

[_Io]

Buenas noches.

En un principio, pensé hacer lo mismo un servicio/aplicación en el servidor de datos, pero me daba cierta inseguridad que fallara por cualquier motivo y quedara el envío de facturas parado.

Al final decidí que cada puesto tuviera un hilo que periódicamente consulte la Bd y haga el envío.
Con una tabla de control consigo sincronizar todos los hilos de los diferentes puestos, sólo uno toma el control hace la gestión y deja el control.
En la tabla de control se encuentra el ID del hilo, hora de entrada, tiempo de espera de la AEAT, último eslabón del encadenamiento etc.
De esta forma, tengo la tranquilidad que hay más de un hilo trabajando.
Estos hilos, generan los registros de facturación los envías y crean los xml asociados.
En un principio me funciona, la única duda que tengo es el mantenimiento de la sincronización, en caso de futuros fallos que por ahora no salen.
A ver...

Saludos.

[Galahad]

hola ,buenas tardes.
tenemos una app en android para pda's que les permite a comerciales de la empresa crear una factura y enviarsela en el momento al cliente.
esta app tiene una base de datos local en cada pda.

Hasta ahora esas facturas se mandaban a un servidor central donde se daban de alta en la base de datos y se contabilizaban.

Ahora, por el verifactu y la gestión del encadenamiento...nos planteamos que no sean facturas sino albaranes y que luego el sistema cree la factura y se la mande al cliente, pero claro,, entiendo que lo ideal es que siguiesen siendo facturas,, en este caso,, la aplicación de android debería de encargarse de su propio encadenamiento, ¿no ? pueden ser varios pda's, cada uno con su número de serie..., y luego transmitir al servidor dichas facturas ya gestionadas.
Pero claro,, eso implica en la aplicación de android tener acceso al certificado de la empresa, los envios y gestión al servicio web...
mucha complejidad y capas,,,
¿ alguien se encuentra en una situación similar ?

[[newtron]]

Empezado por Galahad

hola ,buenas tardes.
tenemos una app en android para pda's que les permite a comerciales de la empresa crear una factura y enviarsela en el momento al cliente.
esta app tiene una base de datos local en cada pda.

Hasta ahora esas facturas se mandaban a un servidor central donde se daban de alta en la base de datos y se contabilizaban.

Ahora, por el verifactu y la gestión del encadenamiento...nos planteamos que no sean facturas sino albaranes y que luego el sistema cree la factura y se la mande al cliente, pero claro,, entiendo que lo ideal es que siguiesen siendo facturas,, en este caso,, la aplicación de android debería de encargarse de su propio encadenamiento, ¿no ? pueden ser varios pda's, cada uno con su número de serie..., y luego transmitir al servidor dichas facturas ya gestionadas.
Pero claro,, eso implica en la aplicación de android tener acceso al certificado de la empresa, los envios y gestión al servicio web...
mucha complejidad y capas,,,
¿ alguien se encuentra en una situación similar ?

Alguno no, nos encontramos muchos en esa situación y creo que la decisión genérica es no hacer facturas desde los dispositivos móviles, hacer albaranes y emitir las facturas en los ordenadores de la oficina que se encargarán de hacer los envíos.



Saludos.

[Jesusggc]

Empezado por newtron

Alguno no, nos encontramos muchos en esa situación y creo que la decisión genérica es no hacer facturas desde los dispositivos móviles, hacer albaranes y emitir las facturas en los ordenadores de la oficina que se encargarán de hacer los envíos.



Saludos.

En estos casos lo recomendable es crear una API en el servidor y que los móviles mediante llamadas a sus Endpoints le den la orden de facturar. Así realmente el que factura es el servidor. Pero claro es necesaria una conexión permanente al menos en el momento de facturar. En este caso hay un único SIF que es el servidor que alberga el Backend

Saludos

[jacju]

Empezado por Neftali [Germán.Estévez]

Nosotros hemos entendido que el registro de facturación debe generarse en el momento de crearse la factura.
Hay que tener en cuenta que puedes tener una incidencia (por caida de internet, por ejemplo) y que estés 1 día completo sin enviar. Si generas los registros al enviar, la fecha del registro podría no coincidir con la fecha de la factura y eso no puede ser (la ley dice que la fecha de la factura y del registro debe ser la misma). Si asignas la fecha de la factura al registro (de 1 día antes) tendrás registros del día X-1 que se han generado el día X. Raro.


Te está diciendo:
1) Generar el RF
2) Enviar
3) "Simultáneamente" imprimir la factura con el QR.

Si por un problema (como hemos dicho antes) no puedes enviar, ya sea tuyo o que los servidores de la AEAT han caído, debes poder continuar con el funcionamiento del sistema. Y eso quiere decir que aunque no puedas hacer completar el paso (2), debes poder realizar los otros (1) y (3).

De todas formas tampoco aseguro que DEBA ser así 100%.
Así es como lo hemos hecho nosotros, porque como también tenemos la opción de NO-VERI*FACTU, necesitamos hacerlo al crear la factura para que el mismo proceso nos sirva para las 2 modalidades. De esta forma da igual si luego envías (VERI*FACTU) o no (NO-VERI*FACTU), el RF ya está creado.

Yo lo hago como ha expuesto el compañero @gizmo2025, pero por tener otra opcion ( la que planteas ),
me surge unas dudas de como creas el xml del RF al generar la factura, si lo haces con el Soap o manual y luego a la hora de enviar como recoges esa informacion para enviarlo .
me podrias poner un ejemplo.

Gracias