Implementación VeriFactu en sistema multi-puesto

[espinete]

Buenas!

Hasta ahora he optado por la opción fácil: enviar las facturas a verifactu a medida que se van emitiendo. Hacienda dice que esto se permite pero que lo vigilarán para "evitar abusos".

(A mí me parece más abuso enviar 1000 facturas en 2 minutos que 3 facturas en 2 minutos, pero bueno).

Como no me fío, tendré que implementar la otra opción: el dichoso flujo de generación + envío cada X segundos con límite de 1000 facturas, control de tiempo de espera, etc.

En problema es que en mi caso (y supongo que en el de la mayoría), nuestra aplicación es multi-puesto, válido tanto para red local como a través de internet, donde uno de los PCs es el que guarda la base de datos (cliente/servidor) y el resto se conectan a él, ya sea en la misma red o desde otra sucursal, país, desde casa, etc.

Entiendo, por lo tanto, que lo suyo sería hacer lo siguiente:

1. Cada PC, a medida que hace una factura, genera el registro de facturación (el XML, para simplificar), obtiene el QR, etc. y guarda la venta en la BD. Esto es necesario para poder imprimir la factura, independientemente del envío.
2. Solo el Servidor, cada X segundos, se comprueba si hay facturas pendientes de envío, y hace el envío, con un límite máximo de 1000 facturas por envío.

Queda descartada la opción de que cada PC genere y envíe a verifactu por su cuenta, ya que mantener el flujo de <1000 y tiempo de espera, en varios PCs conectados, etc. es inviable, por no decir imposible.

Cosas a tener en cuenta:
- En el servidor, la aplicación que hace los envíos debe ser un .exe independiente, siempre abierto, en segundo plano (o un Servicio de Windows), ya que el programa no tiene por qué estar abierto en el servidor.
- Este programa se encargará solo de hacer los envíos. Los RF ya existen y están guardados en la BD, y estarán "enviados", "pendientes", "necesita subsanar", etc.
- Cumpliendo las condiciones de la AEAT, se irán haciendo los envíos de forma transparente para el usuario, salvo que haya "errores subsanables", en cuyo caso habrá que avisar al usuario

Esta es la parte que me preocupa un poco: cómo avisar al usuario. Si los envíos a verifactu se hacen solo en el servidor, los demás PCs no tienen comunicación en tiempo real con las respuestas de Hacienda, así que tendría que crear algún sistema que avise a quien tenga que avisar de que hay un problema en alguna factura que requiere subsanación o rectificativa.

Sería todo muchísimo más fácil, para nosotros y para el cliente, si se pudieran enviar las facturas sobre la marcha una a una, y no con el dichoso flujo y tiempo de espera.

¿Vosotros cómo tenéis pensado hacerlo?

[rci]

Empezado por espinete

Buenas!

Hasta ahora he optado por la opción fácil: enviar las facturas a verifactu a medida que se van emitiendo. Hacienda dice que esto se permite pero que lo vigilarán para "evitar abusos".

(A mí me parece más abuso enviar 1000 facturas en 2 minutos que 3 facturas en 2 minutos, pero bueno).

Como no me fío, tendré que implementar la otra opción: el dichoso flujo de generación + envío cada X segundos con límite de 1000 facturas, control de tiempo de espera, etc.

En problema es que en mi caso (y supongo que en el de la mayoría), nuestra aplicación es multi-puesto, válido tanto para red local como a través de internet, donde uno de los PCs es el que guarda la base de datos (cliente/servidor) y el resto se conectan a él, ya sea en la misma red o desde otra sucursal, país, desde casa, etc.

Entiendo, por lo tanto, que lo suyo sería hacer lo siguiente:

1. Cada PC, a medida que hace una factura, genera el registro de facturación (el XML, para simplificar), obtiene el QR, etc. y guarda la venta en la BD. Esto es necesario para poder imprimir la factura, independientemente del envío.
2. Solo el Servidor, cada X segundos, se comprueba si hay facturas pendientes de envío, y hace el envío, con un límite máximo de 1000 facturas por envío.

Queda descartada la opción de que cada PC genere y envíe a verifactu por su cuenta, ya que mantener el flujo de <1000 y tiempo de espera, en varios PCs conectados, etc. es inviable, por no decir imposible.

Cosas a tener en cuenta:
- En el servidor, la aplicación que hace los envíos debe ser un .exe independiente, siempre abierto, en segundo plano (o un Servicio de Windows), ya que el programa no tiene por qué estar abierto en el servidor.
- Este programa se encargará solo de hacer los envíos. Los RF ya existen y están guardados en la BD, y estarán "enviados", "pendientes", "necesita subsanar", etc.
- Cumpliendo las condiciones de la AEAT, se irán haciendo los envíos de forma transparente para el usuario, salvo que haya "errores subsanables", en cuyo caso habrá que avisar al usuario

Esta es la parte que me preocupa un poco: cómo avisar al usuario. Si los envíos a verifactu se hacen solo en el servidor, los demás PCs no tienen comunicación en tiempo real con las respuestas de Hacienda, así que tendría que crear algún sistema que avise a quien tenga que avisar de que hay un problema en alguna factura que requiere subsanación o rectificativa.

Sería todo muchísimo más fácil, para nosotros y para el cliente, si se pudieran enviar las facturas sobre la marcha una a una, y no con el dichoso flujo y tiempo de espera.

¿Vosotros cómo tenéis pensado hacerlo?

Hola espinete, nosotros lo hacemos mas o menos como dices y cuando ocurre algún problema en el envío, informamos al usuario de lo ocurrido, para que tome las medidas necesarias, cuando pueda.
Puedes hacerlo de varias formas, he leído algunos posts que envían un correo electrónico para informar.
Nosotros creamos un registro en una tabla de la base de datos y en el programa tenemos una marca visual que se muestra si hay mensajes en esa tabla que estén pendientes de leer.
Saludos

[[newtron]]

Empezado por espinete

Buenas!

Hasta ahora he optado por la opción fácil: enviar las facturas a verifactu a medida que se van emitiendo. Hacienda dice que esto se permite pero que lo vigilarán para "evitar abusos".

(A mí me parece más abuso enviar 1000 facturas en 2 minutos que 3 facturas en 2 minutos, pero bueno).

Como no me fío, tendré que implementar la otra opción: el dichoso flujo de generación + envío cada X segundos con límite de 1000 facturas, control de tiempo de espera, etc.

En problema es que en mi caso (y supongo que en el de la mayoría), nuestra aplicación es multi-puesto, válido tanto para red local como a través de internet, donde uno de los PCs es el que guarda la base de datos (cliente/servidor) y el resto se conectan a él, ya sea en la misma red o desde otra sucursal, país, desde casa, etc.

Entiendo, por lo tanto, que lo suyo sería hacer lo siguiente:

1. Cada PC, a medida que hace una factura, genera el registro de facturación (el XML, para simplificar), obtiene el QR, etc. y guarda la venta en la BD. Esto es necesario para poder imprimir la factura, independientemente del envío.
2. Solo el Servidor, cada X segundos, se comprueba si hay facturas pendientes de envío, y hace el envío, con un límite máximo de 1000 facturas por envío.

Queda descartada la opción de que cada PC genere y envíe a verifactu por su cuenta, ya que mantener el flujo de <1000 y tiempo de espera, en varios PCs conectados, etc. es inviable, por no decir imposible.

Cosas a tener en cuenta:
- En el servidor, la aplicación que hace los envíos debe ser un .exe independiente, siempre abierto, en segundo plano (o un Servicio de Windows), ya que el programa no tiene por qué estar abierto en el servidor.
- Este programa se encargará solo de hacer los envíos. Los RF ya existen y están guardados en la BD, y estarán "enviados", "pendientes", "necesita subsanar", etc.
- Cumpliendo las condiciones de la AEAT, se irán haciendo los envíos de forma transparente para el usuario, salvo que haya "errores subsanables", en cuyo caso habrá que avisar al usuario

Esta es la parte que me preocupa un poco: cómo avisar al usuario. Si los envíos a verifactu se hacen solo en el servidor, los demás PCs no tienen comunicación en tiempo real con las respuestas de Hacienda, así que tendría que crear algún sistema que avise a quien tenga que avisar de que hay un problema en alguna factura que requiere subsanación o rectificativa.

Sería todo muchísimo más fácil, para nosotros y para el cliente, si se pudieran enviar las facturas sobre la marcha una a una, y no con el dichoso flujo y tiempo de espera.

¿Vosotros cómo tenéis pensado hacerlo?

En lo esencial yo lo tengo así. Un programa montado en el servidor que recoge las facturas que van emitiendo los terminales y las va enviando según los tiempos de espera marcados. El tema es que no veo conveniente que cualquiera pueda recoger y manejar las respuestas de los envíos. Entiendo que debe de haber un encargado de estar al tanto de esto y que actúe en función al problema que se encuentre.



Yo tengo un problema importante y es que tengo unos pocos de programas distintos funcionando por ahí que tengo que adaptar por lo que he hecho es un programa "enviador" independiente del programa de gestión que sea que hace estas funciones y que recoge/devuelve ficheros de texto. El programa "enviador" me servirá para cualquier programa y me toca en cada uno de los programas de gestión ir generando los ficheros que leerá y posteriormente recoger las respuestas a esos envíos por lo que alguien se tendrá que encargar de recoger esas respuestas y ahí verá si ha habido incidencias y a partir de ahí que las maneje haciendo una rectificativa o lo que corresponda. De esta manera me ahorro algo de trabajo teniendo un programa común que se encarga de hacer los envíos y recoger las respuestas.


Resumiendo: Yo entiendo que debe de haber que alguien que "medio sepa" se encargue de manejar las respuestas puesto que en la mayoría de los negocios hay mucha gente que no tiene (ni debe) hacer otra cosa que vender y poco más.


Saludos.

[Jarogo08]

Empezado por rci

Nosotros creamos un registro en una tabla de la base de datos y en el programa tenemos una marca visual que se muestra si hay mensajes en esa tabla que estén pendientes de leer.

Nosotros esa marca visual la tenemos en el propio mantenimiento de facturas. Hemos creado un campo de "Estado" que tendrá los valores "Correcta/Aceptada con errores/Incorrecta".
Las correctas pintadas de verde, las incorrectas pintadas de rojo y las aceptadas con errores en amarillo (como un semáforo).

Cada vez que el usuario entre a la lista de facturas verá de manera muy rápida si tiene incidencias o no.

Saludos

[espinete]

Muchas gracias a todos por las respuestas.

Me alegra saber que lo que llevaba dándole vueltas en la cabeza desde hace tiempo es la forma correcta de hacerlo. Hasta ahora, con envíos "en tiempo real" era todo mucho más fácil. Además era más fácil corregir sobre la marcha los típicos errores de "falta NIF", "NIF no identificado"; etc. pero con el "enviador" solo en el servidor la cosa cambia un poco.

Los clientes/usuarios tendrán que acostumbrarse a que tenga que haber un "encargado" pendiente de estas cosas. Mira que luego la culpa es nuestra. Imagínate una empresa que lleve días sin enviar/corregir facturas porque no hay nadie ahí que se dé por aludido o que haga nada para corregir lo que está pendiente de subsanar

[espinete]

A raíz de esto... ¿Cómo lo haríais en un software en la nube?

Aquí no veo más remedio que enviar las facturas sobre la marcha. En un software 100% online (PHP por ejemplo) no veo forma de crear el mecanismo de control de flujo, salvo que cree un "cron job" o algo similar, que se ejecute cada X segundos y compruebe si hay facturas pendientes, del tenant/empresa que sea, y haga los envíos.

[gcqZW]

salvo que cree un "cron job" o algo similar, que se ejecute cada X segundos y compruebe si hay facturas pendientes, del tenant/empresa que sea, y haga los envíos.

Así es como lo hacemos nosotros, haces 6 tareas por minuto que comprueban la lista de envíos y van enviando las que tengan si se puede claro.

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

Nosotros usamos algo similar a lo que ya te han comentado.
Un servicio que se encarga de los envíos.
En el mantenimiento de facturas cada factura tiene una marca del estado.
Y en caso de que haya errores una marca que indica en el formulario principal que indica que hay incidencia (por si no entran en la selección de facturas).

Luego para más detalle se puede consultar, para una sólo factura, los estados por los que ha ido pasando, los registros de facturación, exportarlos,...

[gizmo2025]

Yo lo hago muy parecido a lo que dices, solo se diferencia en que el XML, lo genera el servidor, y no la generación de la factura en cada cliente. La generación de la factura si que me graba en mi propio registro de factura la huella, la huella anterior, fecha y hora, etc. , todos los campos especiales nuevos que me hacen falta para luego generar el XML de verifactu, pero la generacion del XML la realiza el servidor, y guarda en una nueva tabla de log para verifactu, todo tipo de detalle, incluso el XML enviado y el de respuesta, en la propia base de datos, junto con el id de cada factura (es decir si mando 100 facturas tengo como minimo 100 nuevos registros de ese log, uno para cada factura).


Esto lo he hecho asi porque si hago que sea la generacion de una factura la que genera el XML, entonces esta claro que tendria una unica factura en cada XML, y tengo entendido tiene que poder haber varias. Es decir, incluir en un mismo XML pues 100 facturas por ejemplo si se da el caso. De ese modo, el servidor mira que facturas tiene pdtes. de envio, y ya genera ese XML con las facturas pendientes.



Y me pasa un poco como a ti, yo marco de momento las facturas con un campo que me indica si esta pdte de enviar (cuando se generan y se graban en mi base de datos) , si el envio es correcto , si es un warning (Aceptada con errores) o si es un rechazo (No aceptada o incorrecto).



Y el problema que tengo es que aún no se que hacer con las que tengo marcadas como warning o con errores. Lo de que en el programa salga algún 'testigo' que avise a los usuarios de que hay facturas con problemas, seria un buen paso. Pero el rollo es si en funcion de cada caso el usuario tiene que hacer Anulacion, subsanacion, Factura rectificativa, etc..


Esto sin contar la de veces que me llamarán porque quieren modificar algo en una factura, ya sea que han facturado un albaran de mas, o de menos, o quieren añadir unas lineas entre las lineas de un albaran, que se han equivocado de cliente, en definitiva, puede pasar de todo.... Y lo de hacer rectificativa para todo, que sería lo facil para mi, tambien tiene su cosa...


En fin, que esto es de locos...

[nincillo]

Mi planteamiento también va por que sea el programa/servicio que corra en el servidor el que monitorice para buscar las facturas "nuevas" y cada x tiempo realmente genere los xml, genere un xml "conjunto" con hasta 1000 registros y ese sea el que envíe a Hacienda y luego procesar la respuesta almacenando la respuesta también en la base de datos.

Espero que este sea un planteamiento que cumpla con los requisitos, o ¿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.

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

[gizmo2025]

Empezado por nincillo

Mi planteamiento también va por que sea el programa/servicio que corra en el servidor el que monitorice para buscar las facturas "nuevas" y cada x tiempo realmente genere los xml, genere un xml "conjunto" con hasta 1000 registros y ese sea el que envíe a Hacienda y luego procesar la respuesta almacenando la respuesta también en la base de datos.

Espero que este sea un planteamiento que cumpla con los requisitos, o ¿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.

Hombre yo es que como digo, todo lo referente a los datos del XML e incluso la huella, lo genero y calculo todo al momento de crear la factura. Lo que digo que hace el servidor, es crear el XML, pero todos los datos (incluidos huella y huella anterior) ya estan totalmente grabados en la factura. En caso contrario si que podria tener problemas de encadenamiento, pero ya digo yo todo esto lo grabo y lo calculo al momento de crear la factura, y el servidor solo se encarga de generar y enviar el XML, pero todos los datos que se incluyen en el XML ya estan grabados previamente en la factura. Mas que nada porque yo tengo que poder hacer más facturas, y la siguiente factura tiene que saber cual es exactamente la huella anterior (que se calcula con los minutos y segundos exactos).

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