Error en los envíos que no puedo detectar
 

Tengo varios clientes enviando a Producción, pero un cliente concreto no ha podido hacer ningún envío, y en principio no veo que le falte nada por configurar.
Tengo LOGs por todas partes, pero no salta ninguno. No sé si será cosa del certificado digital del usuario, etc. pero no consigo que "salgan" las facturas.

Los RF se generan (los guardo en xml para poder comprobar si tienen algo mal), pero en el momento de enviar, ahí se queda, y claro, ya tiene cientos de facturas pendientes de envío, reintentando cada 60 segundos...

Todo esto funciona con los demás clientes, así como en nuestras pruebas, etc.

¿Será el certificado? ¿Cortafuegos? ¿Librerías SSL? ¿Alguna forma de saber qué puede ser? El LOG no guarda nada!

O alguna forma de guardar la respuesta que se recibe de la AEAT en un XML antes de procesarlo? Así al menos puedo saber si se recibe algo o no!

¿Qué versión de windows tiene? Porque como tenga una anterior a W10 no es compatible con tls 1.2

Voy a ver si lo averiguo, pero dudo que sea anterior a Windows 10.

Y en cualquier caso... si fuera eso, no hay forma de detectarlo o lanzar el error en pantalla o algo? Porque con el código anterior no me salta nada.

Yo en los que hemos instalado hacia una prueba siempre del nif y si alguno era w7 me saltaba un error, en principio ha sido 1 u 2 creo, porque ya les comentamos que el equipo tenia que ser w10 o superior. Lo bueno de la prueba del nif es que si yo me despistaba y no miraba la versión del SO me cascaba antes de dejarselo puesto definitivamente.

Lo mejor que se me ocurre es que en tu programa detectes qué versión de windows tiene y si es antigua que de un mensaje.

Tiene W11.

Me refería a detectar errores de certificado o de conexión, porque no sé si con el try...except que tengo es suficiente, aunque debería.

Si es que es eso lo que falla, porque sigo sin saber qué más puede ser. Mira que como sea un certificado no válido o algo así...

¿Sabe alguien cómo guardar el XML que se recibe en la respuesta de la AEAT en un archivo? Sé como guardar el que envío (la petición) en el HTTPRIOBeforeExecute, pero no la respuesta, por si eso me ayuda en algo.

Yo puse una opción para que elimine los certificados caducados, porque tienen costumbre de añadir los nuevos pero no eliminan el caducado, esto da problemas y no envia nada, porque te toma el certificado caducado. En este caso creo que tambien te devuelve un mensaje. Lo raro que comentas que no les salte nada, ningún error, aviso, etc...

¿guardar el resultado?

evento: afterExecute

Supongo que ya has probado a hacer el envío sin ningún antivirus rulando

Tenemos prohibido desactivar cualquier antivirus o cortafuegos de los clientes. Por ahora solo puedo poner logs por todas partes a ver dónde se detiene.

En cualquier caso, si fuera antivirus o cortafuegos, debería dar error de conexión, pero no sé cómo detectar ese posible error en el código anterior.

Hola, si es AVG o Avast, el modulo Anti Track , falla y no deja conectar a las paginas de la aeat y ayuntamientos, a mi me costo un huevo hasta que descubrí que se avía instalado solo, un dia, ya no podía enviar ni entrar en las webs y yo no instale nada, modifica algo en las direcciones web en trafico y es cuando cae la conexion.

A mí me ha pasado de no poder subir o consultar facturas, decirle que lo desactive 1 hora, volver a hacerla prueba y funcionar


A partir de ahí el problema debería pasar a él y al que le instaló el antivirus...

Puede que si es un firewall no te esté respondiendo. La comunicación sale del equipo, el firewall la para y ahí se queda la cosa, no hay respuesta. Prueba a hacer un tracert con la ip de la aeat a ver si llega o se para en algún sitio entre medias. Desde Powershell puedes hacer comunicaciones parecidas a las que harías con el envío, por ejemplo enviando un xml de envío en archivo, a la aeat y ver si te aporta algo.

Al final el error estaba en que una de las facturas del bloque no tenía generado el RF (XM;L), y al crear el bloque para el envío, se colgaba y no continuaba con el proceso.

¿Por qué esa factura no tenía XML generado? Ni idea, está claro que algún fallo por nuestra parte que no supimos ver a tiempo. Al final se trataba de una factura con Total = 0 y quizás por eso ocurrió algo raro y no se generó el RF.

Al menos gracias a estos pocos clientes que se atrevieron a enviar a Producción voluntariamente iremos puliendo estas cositas.

Efectivamente, por estas cosas se deben hacer pruebas de campo SIN RIESGO legal o comercial (es decir enviando al endpoint de pruebas) y si el registro esta mal efectivamente no parar la venta, porque eso que dice Hacienda de que "no hay que parar la venta" es una solemne tontería si según que errores (por ejemplo que no se creen los registros de facturación) los tienes que solucionar en el momento (y de estos errores se pueden dar y no ser causados por el software, sino venir de Windows, que es un virus en sí mismo), porque si no puedes tener un problema muy difícil de solucionar, y siempre con la espada de Damocles de la multa de 150.000/50.000€ rondando por encima . Cuantos de estos errores tendremos que solucionar todos que no habíamos previsto...
De verdad que no conozco software medianamente serio en el mundo mundial que se haya lanzado al mercado sin pruebas de campo, y menos de forma obligada por la autoridad, pero lo que más me sorprende de esto es que parece que todo el mundo lo ve muy normal, no ves una queja en redes sociales, ni en seminarios de esos que crea Hacienda o las grandes empresas de software, ni nadie se queja ahora que han metido el aplazamiento que uno de los condicionantes más importantes para que en diciembre faltaran un 80-90% de empresas a incorporarse a Verifactu es precisamente este.
Lo normal... lanzar software fiscal sin posibilidad de probarlo...:(

A ver si el 01/01/2027 cuando empiecen a enviar muchos le peta el programa a la AEAT y pagan ellos por no tener el programa adaptado.

Yo con las facturas a 0 ya he tenido varias movidas, o sea, todas las movidas las he tenido con las facturas a cero.
Una de ellas es que al no tener ninguna cuota con importe no generaba el detalle desglose y catapum,

Sí, yo también tuve que controlar esa misma circunstancia.

¿ Estáis teniendo problemas con el envío a PRODUCCION hoy por la mañana ??

A mí me está devolviendo como si el servidor de la AEAT estuviera fallando.

No, todo ok, menos un envio puntual a las 10:55 y otro a las 7:57, pero al reeenviarse ha dado ok, llevamos miles mandado sin más problemas

Y me puedes confirmar la URL de PRODUCCION.

yo tengo esta:
https://www1.agenciatributaria.gob.e.../VerifactuSOAP

lo que me extraña es que me está fallando sólo con un cliente que he revisado y todo en la configuración parece ok.

Sí, eses es el endpoint correcto.
Si me puedes decir que error te devuelve

En la conexión me devuelve un valor diferente a 200, que es el correcto, y eso que tengo configurados tiempos de espera a 10000, 15000, 30000, 60000

Deberias integrar más controles para poder verificar que ha pasado, por ejemplo yo no guardo solo las respuestas, tambien guardo 1 dia entero de los traces de cada conexión, y las cabeceras de respuesta, es la únbica forma de no volverte loco con estas historiass.

Por otro lado, hace un par de semanas yo recibia un resultado "100 Continue" acompañado más adelante con un "200 Ok" me llego el error (que tengo puesto que me lleguen todos por añadir otra capa de tranquilidad), y consulté que estaban subidos OK.

Se te pueden dar diversos casos de resultados distintos de 200 y que pueden ser finalmente validos, pero hay que verificarlos:
226
202
...
y el 100 acompañado del 200
Todos los distintos de 200 son una putada.
Tambien debes verificar que en ese cliente se actualice correctamente los certificados SSL:Certificado CA, Certificado de Confianza.. Pero podrias ver que error te da si tienes un trace y ver si el motivo es este.
Con ese dato de "distinto de 200", poco se puede investigar.

Eeroe 404 ayer a las 17.29
 

Un error puntual que antes no habia tenido, pero al siguiente reintenro se envió correctamente:
Sí os fijais en la fecha que devuelve 1/1/1970, significa que el endpoint estaba desincronizado, posiblemente un reinicio sin los servicios de reloj aún levantado.

¿ Usas la web del ROA para obtener la fecha y hora reales ?
A mi me ha pasado lo mismo que a tí, porque esa web ha tenido muchos problemas en las últimas semanas.

Sí, pero aparte del fin de semana que tenia desactualizado los certificados CA, no he tenido más problemas con la obteccion de la fecha/hora, el error me ha dado al enviar al endpoint de producción de verifactu de la aeat, pero una puntualidad, de vez en cuando tienen pequeñas caidas. Esperemos que este año les sirva para depurar un poco más los servicios.