Implementación VeriFactu en sistema multi-puesto

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

Yo tengo implementada las dos opciones:

1.- cada SIF envia SUS RF (tú caso)
2.- y un servicio que me envía (Esta opción la contemplo para el caso de uso de varios usuarios de la aplicacion conecatados al servidor mediante VPN con Escritorio Remoto, Por Ejemplo)

Viendo que la mayoría optaba por el servicio puse consulta para confirmar que como lo estaba haciendo era correcto. Por si acaso a alguien le sirve. Porque pienso que puede facilitar las cosas.

Adjunto Consulta y Respuesta:

Buenas tardes:

Sí, es correcta su interpretación y acorde a la normativa.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]





De: "" <>
Para: <[email protected]>
Fecha: 28/05/2025 16:51
Asunto: Consulta so envios de RF
________________________________________

Buenas tardes

Aunque en los lotes de envío de RF lo único que se exige es que sean del mismo OT (es decir, podría enviar de distintos SIF) al recibir la respuesta el “Tiempo de espera” lo debe cumplir el SIF. Entiendo que en una instalación con varios SIF pero que comparten la BD lo mejor sería que cada SIF envíe sus lotes de RF y así cada SIF tiene su “tiempo de espera”. Seria correcta esta forma de implementar el envío.

Gracias.

Un saludo. :-)

[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

[[newtron]]

Empezado por Jesusggc

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

Bueno... entonces ya estamos planteando otro escenario en el que hay conexión con el servidor y se envía la factura de forma automática al emitirla que es lo correcto. Por otro lado tampoco podemos olvidar que hay que emitir una factura impresa con un QR.

[Jesusggc]

Empezado por newtron

Bueno... entonces ya estamos planteando otro escenario en el que hay conexión con el servidor y se envía la factura de forma automática al emitirla que es lo correcto. Por otro lado tampoco podemos olvidar que hay que emitir una factura impresa con un QR.

Para este caso lo que yo haría es que el servidor mediante la misma llamada al EndPoint del API que factura me devuelve dicha factura en PDF (o envía por email) y que recibe el móvil que manda la orden de facturar. Yo no tngo a nadie que facture desde móvil pero si tngo otras aplicaciones móviles que lo hacen así.

La cuestión es que dentro de los requerimientos del sistema que la mayoría de las cosas las realice el SERVIDOR (Backend) eso sí es necesaria conexión a internet.

Un saludo.

[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

[jacju]

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 .
podrias poner un ejemplo de la creacion del RF al generar una factura y otro para enviarla, porque para enviar lo que se me ocurre es leer el RF y añadirlo al envio basandome en sus campos
como fechas y demas

Gracias