"Latencia" al guardar facturas VeriFactu
 

Tenemos varios clientes enviando a VeriFactu desde hace meses, pero uno de ellos se queja de que ahora cuando hace una factura, tarda como 4-5 segundos en guardarse, y antes no (obvio).

Yo he estado haciendo pruebas y obviamente ahora tarda algo más porque para VeriFactu hay que hacer varias comprobaciones previas, obtener la fecha/hora REAL exacta, generar el XML, obtener el encadenamiento, etc.
El envío se hace en segundo plano, así que eso no me preocupa.

Sé que en parte va a depender de la potencia de cada PC (a mí no me tarda 5 segundos no de coña). Todavía hay gente que se compra un PC de 300 Euros y te dice "¡pero si es nuevo! cómo va a ser lento!?" (jajajaja, siempre me río con eso).

Total, que me gustaría saber si también os ocurre a vosotros y si habéis hecho algo para intentar reducir esa latencia. Yo he pensado en no comprobar la hora real con el ROA, o ver si hay otra más rápida.
La comprobación/validación previa, generación del XML y obtención del QR debe hacerse sí o sí antes de guardar la factura y mostrarla en pantalla o imprimirla, ahí no habrá mucho que rascar. Quizás hacerlo todo en un solo proceso y no en dos (ahora mismo tengo un .exe o DLL que hace las comprobaciones previas y otro que genera el XML). A lo mejor al ejecutar esos subprocesos externos es donde Windows tarda un poco más.

También entiendo que el antivirus o cortafuegos puede estar ralentizando en algunos casos...

Lo dicho, si alguien ha sufrido el mismo problema me gustaría saber si lo ha solucionado de alguna manera, o si no queda otra que esperar unos segundos inevitables y punto.

En nuestro caso encima el envio no se hace en segundo plano, cuando grabas la factura o facturas lanza un modulo que se ve en pantalla y comienza a generar los xml y mandarlos, si no hay problemas se cierra automaticamente (si activas la opcion de cerrar si no hay incidencias) pero si hay algún problema no se cierra el modulo y te indica que facturas tuvieron problemas. Lo que veo que comentas de obtención del QR es lo que no me quedo claro, yo no hago nada de QR cuando genero la factura, es a la hora de imprimirla cuando se compone el QR en ejecución para imprimirse, el QR no va a cambiar nunca, se obtiene de los datos de la factura (al menos es mi idea del QR). En general los clientes que estan enviando no se han quejado, pero un par de ellos si que han dicho que antes era más rápido,jaja, de hecho tienen equipos del año maria castaña. A uno de ellos para que no estuviera dando por saco cada x tiempo le hemos desactivado el VeriFactu directamente hasta nueva orden.

Con generar/obtener el QR me refiero en realidad a generar la cadena con la que se genera. En realidad el QR efectivamente se "genera" cuando se imprime.
Me refería a que en el proceso de creación del XML es cuando "se sabe" qué QR tendrá la factura impresa, por lo que es un proceso obligatorio.

Está claro que antes de VeriFactu las ventas se guardaban de forma instantánea, pero ahora, sintiéndolo mucho, habrá que esperar unos segundos.

Si tienen prisa, que compren más ordenadores. Y si no, a llorar a las puertas del Congreso.

La consulta de la hora exacta al ROA me tarda de 1,5 a 2 segundos de media. He estado probando alternativas (NTP a google, cloudflare o es.pool.ntp.org) y tarda de media 20 milisegundos.

Que le den al ROA, sorry.

¿Podrías indicar, mínimamente, unas pinceladas, el servicio que usas y cómo lo usas?
Esto de 20 milisegundos de media es muy goloso ;) ...

¡Gracias!

Yo no compruebo la hora...
Se supone que el ordenador mantiene la hora sincronizada mediante NTP. Hasta ahora no he tenido problemas al enviar los registros Verifactu.
Supongo que como mucho comprobaría la hora al iniciar la aplicación para ver si el ordenador y el servidor de hora están dentro del mismo minuto.

Nosotros tampoco validamos nada de la hora. No estamos teniendo problemas con los que estan en producción ni las pruebas que se hicieron y se hacen en desarrollo.

Exactamente hacemos igual ...
Y como bien dices, quizás al entrar al programa validaría la hora ...

De ahí mi pregunta a @espinete :D ...

Hola. No estoy hoy en la oficina. Básicamente le pregunté a ChatGPT si había una forma más rápida de comprobar la hora real sin tener que usar el servicio del ROA, y me puso un código para hacerlo vía NTP (con Indy) usando los servidores NTP de Google, Cloudflare y otros. Hice un proyecto de prueba para comparar ambos métodos y el resultado saltó a la vista.

En cualquier caso, creo que voy a optar por no comprobar la hora. Ya Windows sincroniza la hora con time.microsoft.com así que partir de la idea de que la hora del PC es siempre correcta.

Mi duda surgió porque al principio hubo problemas con esos 3-4 minutos de diferencia que puede haber entre el PC del cliente y la hora real que tiene Hacienda en sus servidores. Vete tú a saber si el usuario se pasa de listo y le cambia la hora (o la fecha) al PC, o que tenga empleados teletrabajando en diferentes husos horarios

Ok @espinete ^\||/ ...
Gracias x tu respuesta! :)

Tenéis razón, el servicio del ROA lleva semanas funcionando mal, tal vez ocasionado por el incremento de consultas que nosotros hemos añadido en nuestros programas. En algunos clientes míos ha habido días que ha superado los 10 segundos en demorar la respuesta.

Algunos decís que no necesitáis consultar la hora real, que con la del ordenador, que debería estar sincronizada es suficiente. En mi caso tengo clientes acostumbrados a desactivar la sincronización y cambiar la fecha y la hora, y preguntaréis ¿ por qué ?. Pues porque hay pantallas en el SIF que al entrar toman por defecto la fecha del Sistema, y si tienen que introducir información de días pasados, les resulta más cómodo para no tener que estar tecleando la fecha correcta continuamente. También hay clientes que lo intentan para "falsear" la fecha de factura. Por todo ello, algunos necesitamos tomar la fecha y hora reales.

En mi caso, el primer cambio que hice fué tomar la fecha y hora reales desde el ROA, SOLO A LA ENTRADA EN LA APLICACIÓN, a la que incorporé un objeto "Timer" y pasándole lo devuelto por el ROA, conseguí establecer un reloj interno en mi aplicación, que hasta ahora no me da problemas.

Se que hay otros servicios en internet que responden en milisegundos, y posiblemente termine cambiando mi sistema.

Mismo problema con el Roa
Ha subido el tiempo de respuesta

Buenos días,

Perdonad, pero hay cosas que ni "harto de vino".

Verifactu no puede/debe penalizar la operativa comercial de la empresa.
El SIF debe poder funcionar sin "internet"; cuando vuelva a tener "internet" ya enviará lo pendiente.
Una de las condiciones a firmar por el cliente (visto lo que describís) debe ser que no puede alterar la hora real del sistema mientras se use el SIF.

La hora no debe (poder se puede) consultarse a cada envío, hacienda tiene una tolerancia más que suficiente para admitir registros "adelantados o atrasados".
El QR no precisa internet, se obtiene/genera en local.

El envío a Verifactu no tiene por que estar ligado/atado al proceso de emisión de la factura.
Se genera la factura, se imprime y acto seguido empieza el proceso de envío (si es en paralelo y deja libertad para generar una nueva factura mejor).
De esta manera este cliente con ordenador de la época de las "pesetas" casi no notará cambio.

Yo siempre compruebo la hora antes de generar factura.

Anda que no me ha pasado veces de un cliente haciendo facturas dos días con la fecha 01/01/1970 porque se le ha agotado la pila de la CMOS.

Teniendo en cuenta que no es lo mismo la fecha de emisión que la fecha de operación, y que la fecha real de la factura debe ser siempre la fecha REAL (no la que tenga el usuario en su PC de plastilina), no veo de más comprobar la hora real antes de hacer cada factura.
De hecho, lo veo casi obligatorio, que hay mucho listo por ahí escondido...

La fecha de factura es eso, una fecha. No tiene hora asociada.
Cuando envíes la factura a Hacienda, y esta vea que la parte "FECHA" es distinta a la que tiene, devolverá un error o advertencia.

El campo "FechaHoraHusoGenRegistro" incluye la hora, y ésta debe ser la hora exacta, porque Hacienda la compara con la suya, y si hay unos minutos de diferencia, te la rechaza o te la acepta con aviso.

La factura puede tener la fecha que quieras, pero ese campo no.

Para ser precisos, si la "FechaHoraHusoGenRegistro" se diferencia en 240 segundos a la de Hacienda, se debe marcar INCIDENCIA=S

Exacto. Por eso lo de usar la hora exacta. Y más teniendo en cuenta el huso horario por si acaso.

Probablemente funcione bien en el 99% de los casos, porque hoy en día la fecha/hora del PC es (debería ser) la correcta. Pero nunca se sabe, y es mejor prevenir y evitar errores/avisos, que tener que reenviarla como "incidencia" o que tu cliente te llame asustado diciendo cualquier tontería por no saber leer.

Yo para aliviar los problemas del ROA había puesto la sincronización sólo al entrar en la aplicación y un timer para refrescar cada hora (porque algunos de mis clientes son "mu propensos" a eso de cambiarle la fecha y hora al sistema, o a gastarle la pila al equipo y darse cuenta tres días después), pero con este hilo ya se me ha puesto la mosca tras la oreja, no creo que con mirar cada hora esté a salvo ... :(