|
Ojo con el timeout!!!
Hola, a raiz de que me han enviado un error 2004 "Aceptado fuera de tiempo" en un registro de ayer, les he preguntado y al final hay que tener en cuenta el parametro timeout de vuestros envios según como tengais el control de flujos para marcar como Incidencia="S".
En mi caso: Timeout = 120 -Genero y verifico que han pasado el tiempos de espera(60s) desde el anterior envio y envio Una factura a las 14:55:00 OK -Genero una nueva 14:55:02, y espero 60 segundos desde la anterior respuesta =14:55:01) -Procedo a enviar registro 14:56:01 y me salta error (timeout) en el primer intento(Incidencia puntual, que segun me han comentado tuvieron una caida momentanea) No me salta el error hasta pasado el tiempo del timeout 14:58:01 -Espero 10 segundos y reintento = 14:58:11 Auú estoy dentro del limite de 240 segundos desde la generacion a las 14:55:02 y sigo sin marcar como incidencia, que tenia prevista al tercer intento. -Procedo segundo intento, y se queda intentandolo hasta que la coge a los 60 s, respuesta a las 14:59:11, Error 2004, Aceptado con errores, y eso si os contesta, que ya me ha pasado que se lo come y no contesta Como veis, el software, ha intentado enviarlo correctamente dentro del limite, pero hay que tener en cuenta el timeout para marcarlo previamente como incidencia, por si el envio tarda. Solución: bajar el tiempo limite y tenerlo en cuenta para restar a los 240 segundos el timeout que le tengais puesto, aparte del margen que querais. |
¡¡¡Qué manera de complicarse/nos la vida tienen esa gente!!!
|
Me olvidé decir que lleva 2 dias pasandome en producción. ayer sobre las 14:51:00 cayo y no pude enviar hasta las 14:56:00
El dia 2 detecté 2 caidas sobre las: 17:40 y 19:15 Supongo que hay más y más habrán. |
Cita:
<!DOCTYPE html> <html lang="es"> <head> <meta name="site" content="Sede"/> <link href="/static_files/common/css/aeat.07.css" rel="stylesheet" type="text/css"> <meta title="AEATviewport" content="width=device-width, initial-scale=1.0" name="viewport"> <title>Agencia Tributaria: 503</title><meta name="ObjectId" content="58f37bde849c7710VgnVCM100000dc381e0aRCRD"/><meta name="keyword" content="erro5031"/> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta name="detalle" content="errores"/> </head> <body> <div id="body" data-template-id="cc1c55b3cac46710VgnVCM100000dc381e0aRCRD" class="s_Sede p_estandar t_informacion"> <header id="AEAT_header" class="header_aeat d-print-none d-app-none" > <!-- CABECERA --> <!--googleoff: index--> <a class="focus-only" href="#acc-main">Saltar al contenido principal</a> <div class="header-sup_aeat w-100"> <div class="container"> <div class="row"> <!-- CABECERA IZQUIERDA--> <div id="topIzquierda" class="pl-0"><nav class="header-contLogos_aeat"><a href="/Sede/inicio.html" title="Página de inicio" class="header-logosPrincipales_aeat"><span class="logoGobierno Sede">Logotipo Gobierno de España</span><span class="logoAEAT logoSite logoSede ml-2 overflow-hidden">Logotipo Organismo</span></a></nav></div><!-- CABECERA IZQUIERDA FIN --> </div> </div> </div> <!--googleon: index--> <!-- CABECERA FIN --> <!-- MENU --> <!--googleoff: index--><div class="w-100 bg-primary p-1"><div class="container"><div class="row justify-content-between align-items-center"><button class="header-btnMovil_aeat text-white d-lg-none col-2 btn btn-link" type="button" id="menuPrincipal"><i class="aeat-ico fa-ico-menu ico-size-2 w-100" title="Abrir menú móvil" aria-hidden="true" role="presentation"></i><span class="sr-only">Menú móvil</span></button><nav id="aeat_menuPrincipal" class="navbar-dark navbar navbar-expand-lg p-0 col-12 col-xl-8 col-lg-9 d-none d-lg-flex" aria-label="Menú principal"><!--clase para movil: header-navMovil_aeat--><ul class="navbar-nav"><li class="nav-item"><a href="#" class="py-3 px-4 nav-link dropdown-toggle invisible" role="button"><span>Aqui se cargarán las opciones del menú cuando estén disponibles</span></a></li></ul></nav></div></div></div><!--googleon: index--> <!-- MENU FIN --> .... |
Cita:
HTTP 503 – Service Unavailable El servidor de la Agencia Tributaria no está disponible temporalmente o no puede procesar la solicitud. Esto puede deberse a: 1. Mantenimiento o sobrecarga en el entorno Veri*Factu (pruebas o producción). 2. Caída temporal de los servicios SOAP/REST de AEAT. 3. Timeout de conexión por saturación de peticiones. 4. Configuración incorrecta de endpoint, si estás usando un entorno diferente (p. ej. envías aproduccion cuando el certificado es de pruebas 5. Otros problemas con el certificado |
Cita:
Lo mismo que con el error del certificado expirado. Esto que está respondiendo Veri*factu no es una respuesta estándar de Veri*factu. ¿Cómo quieren que controlemos errores que desconocemos y además en formatos no estándar Veri*factu? |
Cita:
|
Cita:
|
Cita:
Pero claro, ya tengo el de la firma y ahora este, y mañana? Que otro error que desconozco aparecerá? No debería ser esta la solución. No han creado un aplicativo nuevecito (Veri*factu), y antes de 'inaugurarlo' ya le tenemos que meter excepciones en su gestión? Por favor... que ya van unas cuantas. -La respuesta es "Correcto/a" (ya me da igual miro tanto en masculino como en femenino), "Incorrecto/a", "Aceptadoconerror",... quién es el chapucero que no le ha metido un código a esos literales? Al final aún deberemos dar gracias a que han codificado los errores. -Me responde que el NIF es NO censado, consulto a Veri*factu y me dicen que lo vuelva a enviar a las 48 horas. PERO ESTO QUE ES?!?! Y me dejo alguna otra perla. En fin. VERGÜENZA. |
Cita:
Pero trankis, ya os enterareis, saltará la liebre. Ya ya les he informado. |
Cita:
Cuando puedas, nos dices, please !!! Saludos |
¿Se retrasa su implantación hasta 2099?
:rolleyes: |
¿Nos indemniza Hacienda por los graves errores en el desarrollo de Veri-Fiasco? :rolleyes:
|
Sobre los 240 segs de margen
Estoy un poco pez en esta materia, y me lancé al abismo sin red previa. Los 240 segundos que mencionas como retraso máximo, entiendo que entre la fecha/hora de generación de una factura y su envío a la AEAT, en caso de lotes de 500, 1000 facturas, ¿se cuentan individualmente por cada una de ellas? o, al ser un lote, ¿se cuentan (los 240 segs), desde la primera o desde la última? He preparado un proceso que, primero realiza la facturación periódica, semanal, quincenal o mensual y una vez realizada, genera el lote con las facturas y las envía. Al leer tu post me he quedado helado...
Gracias de antemano, y un cordial saludo Fernando Alonso Morán |
Estoy un poco pez en esta materia, y me lancé al abismo sin red previa. Los 240 segundos que mencionas como retraso máximo, entiendo que entre la fecha/hora de generación de una factura y su envío a la AEAT, en caso de lotes de 500, 1000 facturas, ¿se cuentan individualmente por cada una de ellas? o, al ser un lote, ¿se cuentan (los 240 segs), desde la primera o desde la última? He preparado un proceso que, primero realiza la facturación periódica, semanal, quincenal o mensual y una vez realizada, genera el lote con las facturas y las envía. Al leer tu post me he quedado helado...
Gracias de antemano, y un cordial saludo Fernando Alonso Morán |
Cita:
No creo que sea un procedimiento correcto generar la facturación y luego generar el lote con las facturas. Pueden pasar mil cosas por las que las facturas se generen y al final no se genere el envío o que sea un proceso lento y algunas se envíen pasado el tiempo de incidencia por lo que yo recomendaría ir encolando factura por factura. De esta manera al generar la primera factura se enviaría y las demás se irían encolando hasta cumplir los 1000 registros o el tiempo devuelto para el próximo envío y así sucesivamente. Por ejemplo imagínate que haces 20 facturas de golpe, se enviaría la primera, se recoge el tiempo de espera hasta el siguiente envío (normalmente 60 sgs) y las facturas que generes en esos 60 sgs se enviarían en un solo paquete. Saludos. |
Cita:
Tengo un proceso que cada 'n' segundos (los que yo quiera o mínimo los indicados por Veri*factu en la última respuesta) va mirando si hay RF para enviar, sea 1 ó 'z' coge los que hay y los envía, y así cada 'n' segundos mencionados. |
Pero al final se trata de enviar las 20 facturas de golpe , o se envian 1 a 1 separadas ?????
Gracias |
Cita:
A ver... Imagina que no tienes ninguna factura pendiente de enviar en la cola. Emites una factura que se debe de enviar de forma inmediata y recoger la respuesta del tiempo de espera del siguiente envío (normalmente 60sgs). Las facturas que se encolen en esos 60 sgs. se tienen que quedar a la espera y cuando pase ese tiempo enviarlas todas en un paquete, se recoge el nuevo tiempo de espera y así sucesivamente. Por otro lado ya podemos entrar en matices como que si hay un error de comunicación y se pasa del tiempo de envío hay que marcar ese paquete como con incidencia, etc etc. |
Cita:
Hola Las que esten dentro del tiempo de envio(+60seg ó el tiempor que te devuelvan) hay que enviarlas juntas, excepto las que vaya tarde que van en otro lote como Incidencia. Ejemplo, revisas las facturas pendientes de envio y te encuentras: 3 facturas con hora de emision y contando desde este momento(hh:mm:ss) , han pas Sado entre 60 y 200/240 segundos ---> al mismo lote 2 facturas pasadas de tiempo (más de 200/240 segundos)--> mismo lote como incidencia 1 factura recien generada aún sin llegar a los 60segundos----> dejar en cola Excwpciones: Si tienes mas de 1000 facturas pendientes, divides en bloques de 1000 y el ultimo bloque las que resten y envias los lotes uno detras de otro. Actuañmente permiten el envio instantaneo sin respetar el tiempo de espera(pero no aconsejo por que pueden cambiar de opinióm) |
Cita:
Yo genero el XML y ahí se queda para siempre, si al enviarlo da error, pues reintentaré el envío y ya desde el primer reintento lo marcaré con 'incidencia', por que ha habido una incidencia, la que sea pero incidencia y me da igual que hayan transcurrido los 240 segundos o no; yo lo he enviado y he 'sufrido' una incidencia. En este XML no añadiré ni sacaré nada, sólo incorporaré la 'incidencia'. El siguiente XML tendrá su curso. Y ya quisiera saber que pasará cuando me de por enviar éste segundo XML (sin incidencia) antes que el primero con incidencia. Al final tendrán todos los registros y todas sus huellas consecutivas. |
Cita:
|
Cita:
De hecho acabo de revisar y detectar una en produccion que ha dado error de host 2 veces ( a las 11:17) y a la tercera ha entrado, me quedo mas tranquilo minimizando incidencias aunque sea culpa de ellos. Llrva razon carlos, aunque sea una respuesta eel xml, no está documentado ese tiempo, y aunque no ceeo que lo aminoren, es un pelin arriesgado estabkeces esos limites en el software. |
Puff si estan teniendo caidas todos los dias a la misma hora me temo que va a srr un lio gordo el año que viene como no se tenga bien controlado los flujos.
|
Cita:
|
Por cierto, otra pregunta...
Viendo como están definidos los registros de facturación, que se pide el bloque SistemaInformatico en cada uno de ellos, se supone que si mi cliente tiene diferentes SIF a medida (cada uno hace cosas distintas) y tengo una aplicación residente de envío de RF que recoge todos los RF de todos esos SIF y los envía separando los obligados tributarios, ¿se supone que se pueden meter en un mismo envío los RF de distintos SIF siempre que pertenezcan a un mismo obligado tributario, verdad? |
Cita:
Hola, bloques separados, eso ya lo han aclarado. |
Recuerda que según las "FAQ's para Desarrolladores" :
Un SIF se identifica universalmente por la “concatenación” de tres campos: Id.OEF (NIF) + Id.SIF + NºInstalación. Cualquier cambio en esos valores, te obliga a envíos separados. En tu caso, deberían cambiar el 2º y tal vez el 3º. |
Cita:
"Le confirmamos que la remisión puede incluir registros de facturación generados desde SIFs distintos. El único requisito es que el obligado tributario sea el mismo, ya que es un dato que se establece en la cabecera." Y tiene lógica, sino el bloque SistemaInformatico iría a nivel de lotes de RF (XML de remisión), y no dentro de cada RF individual. |
Cita:
|
Cita:
Mejor como las señales de trafico, hago caso a la más restrictiva, no me fio. Está claro que es mas lógico poder enviar en el mismo paquete, se discutio con ellos durante un par de semanas y decian que cada sif su bloque y que nada de bloques conjuntos ni por OT ni por nada. Están dando marcha atrás en varias cosas, y supongo que como no lo hagan van a tener millones de incidencias, una de ellas es lo que comentaba otro usuario, que le aceptan facturas con fecha anteriores siempre que la fechahorahuso... sea la la actual, o sea generacion ahora pero la factura antigua, al menos en el envio comenta que no la rechazan Bueno, mientras sea dar marcha atrás esta bien. |
Cita:
A mi hace unos meses me respondieron literalmente "El tiempo de espera entre envíos es por SIF y por cada obligado tributario". Nosotros tenemos un servicio que remite los RF de todos los SIF de cualquier obligado tributario: hacemos una query a la base de datos para cargar los pendientes de envío (que no han recibido error por envío previo) agrupados por obligado tributario, y justo después de la remisión de éstos remitimos los que tuvieron incidencia en envíos anteriores, independientemente de que no se hayan cumplido los 240 segundos (porque tal vez en un envío anterior ya dieron incidencia por haberte quedado sin Internet o el servidor estar caído). Por otra parte, en cuanto a los timeouts de espera de cara a remitir los registros, ya me respondieron también hace muchos meses que "pueden remitir los RF en cuanto hayan sido generados, siempre que hayan transcurrido más de 60 segundos desde la anterior remisión". Esto es por ejemplo cuando has dejado de facturar en el día y luego comienza un nuevo día, o tras un fin de semana en el que no has trabajado. Y en cuanto a los RF con incidencia, efectivamente me dijeron lo que aquí han comentado, lo de enviar los de Incidencia en un lote y el resto en otro. |
Cita:
|
Cita:
Lo ideal sería que se pudieran hacer envíos en hilos diferentes de manera simultánea, y no de manera secuencial, pero Delphi suele irse por la pata abajo con el uso de threads. |
Cita:
|
Cita:
Con los threads si yo he podido en vb6, cualquiera va a poder, es darle una vuelta. Si tienes problemas con que sea asincrono solo tienes que sacarlo fuera(otro prograna en segundo plano) controlando que no se cierre. |
Cita:
|
Ese error en todo caso, y en un monton dd lenguajes sale por hacer mencion a objetos (variables, tablas, indices de matrices) que no existen, ya sea por que estan ya cerradas o se han declarado como privadas y las esta intentando leer/asignar desfe otra instancia fuera del rango al que pertenece. Eso no es priblema de los triggers, en vb6 si que hay problema con los triggers que es dificilisimo hacer triggers totalmente asincronos, por no decir imposible
|
Yo tengo VeriFactu ejecutándose en un thread que tiene un timer y una propiedad de “PendienteEnvio” y “FechaNuevoEnvioAutorizado”.
Cuando genero una nueva factura marco el PendienteEnvio a True y si la fecha actual iguala o supera a la de FechaEnvioAutorizado hago el envío de todo lo pendiente. Leo el tiempo para el siguiente envío que me devuelve hacienda (en caso de error o no respuesta marco 60 segundos y espero ese tiempo con el timer. Si transcurrido el tiempo la variable de PendienteEnvio se ha vuelto a poner a True (porque se ha generado una o más facturas nuevas) se vuelve a hacer el envío y así sucesivamente. Este proceso está semiautomatizado gracias al componente de seccion31, aunque el thread hay que currárselo. Evidentemente tiene que establecer su propia conexión independiente con la BD, que creo que puede ser el principal fallo cuando no estás habituado a los threads. Con este sistema nunca se para ni interrumpe el trabajo del usuario con los envíos a VeriFactu, y nos ahorramos comprobaciones y envíos fuera de tiempo. Adicionalmente, cuando hay algún envío pendiente, si intentas cerrar el programa te pide que esperes antes de cerrar para asegurarse de que se realiza el envío. |
Cita:
|
| La franja horaria es GMT +2. Ahora son las 07:56:13. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi