Ojo con el timeout!!!

[Carlos]

Empezado por ermendalenda

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)

Yo eso del tiempo de espera de los 240 segundos, de los 1246 segundos, de los que sean.... pues que no, que esto no lo puedo gobernar, no depende de mi, ni está publicado por hacienda, de hecho el mensaje de error (en la lista de mensajes de error) no menciona los segundos.

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.

[novatico]

Empezado por Carlos

Yo eso del tiempo de espera de los 240 segundos, de los 1246 segundos, de los que sean.... pues que no, que esto no lo puedo gobernar, no depende de mi, ni está publicado por hacienda, de hecho el mensaje de error (en la lista de mensajes de error) no menciona los segundos.

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.

Lo de los 240 segundos te aparece en la respuesta con error que te devuelve hacienda si, entre la "FechaHoraHusoGenRegistro" del Registro de Facturación y la actual de Hacienda se han superado y no has marcado "Incidencia=S".

[ermendalenda]

Empezado por novatico

Lo de los 240 segundos te aparece en la respuesta con error que te devuelve hacienda si, entre la "FechaHoraHusoGenRegistro" del Registro de Facturación y la actual de Hacienda se han superado y no has marcado "Incidencia=S".

Es correcto como lo hace Carlos "también", pero a mi en una contestacion me pusieron que si despues de varios intentos no entra que ya puedo marcarlo como incidencia aunque esté en los 240segundos, yo hago 2 o 3 intentos cada 10 segundos así que tampoco me arriesgo mucho.
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.

[ermendalenda]

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.

[razorxxx]

Empezado por ermendalenda

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.

Esto se olía. Hablamos de millones de peticiones por segundo, ya pueden tener los servidores de la NASA porque creo que esto va a ser la tónica a partir de enero.

[razorxxx]

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?

[ermendalenda]

Empezado por razorxxx

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?

Hola, bloques separados, eso ya lo han aclarado.

[novatico]

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

[razorxxx]

Empezado por ermendalenda

Hola, bloques separados, eso ya lo han aclarado.

Pues me acaban de responder justo lo contrario:

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

[razorxxx]

Empezado por novatico

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

Se identifica con esas claves de manera unívoca en los sistemas de la AEAT, pero es indiferente para la remisión, porque cuando la AEAT reciba el XML va a registrar cada RF en su SIF y Nº instalación correspondiente. Al menos eso es lo que se deduce de la respuesta que me dio la AEAT y que tienes en el post anterior. Aún no he probado a hacer un envío de esta forma (actualizaré el post desde que se me dé el caso).

[ermendalenda]

Empezado por razorxxx

Se identifica con esas claves de manera unívoca en los sistemas de la AEAT, pero es indiferente para la remisión, porque cuando la AEAT reciba el XML va a registrar cada RF en su SIF y Nº instalación correspondiente. Al menos eso es lo que se deduce de la respuesta que me dio la AEAT y que tienes en el post anterior. Aún no he probado a hacer un envío de esta forma (actualizaré el post desde que se me dé el caso).

Eso era la primera respuesta, hace un par de meses cambiaron, entonces ¿vuelve a ser como la primera?
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.

[razorxxx]

Empezado por ermendalenda

Eso era la primera respuesta, hace un par de meses cambiaron, entonces ¿vuelve a ser como la primera?
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.

Aquí uno se vuelve loco, porque el que te responde es el funcionario de turno, y claro está, habrá algunos mejor formados que otros. De hecho, en ocasiones, tienen que escalar las preguntas a otros departamentos para poder darte una respuesta.

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.

[ermendalenda]

Empezado por razorxxx

Aquí uno se vuelve loco, porque el que te responde es el funcionario de turno, y claro está, habrá algunos mejor formados que otros. De hecho, en ocasiones, tienen que escalar las preguntas a otros departamentos para poder darte una respuesta.

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.

Lo de enviar prrimero los que no tienen incidencia te has liado supongo, es justo al revés, el envio tiene que ser por orddn dd generación, aunque el retsrdo del envio de los rrgusttos con incidencias te provoque una nueva incidencia, pero ya te digo, aquí cada uno va a hacer lo que quiera, ya verás.

[razorxxx]

Empezado por ermendalenda

Lo de enviar prrimero los que no tienen incidencia te has liado supongo, es justo al revés, el envio tiene que ser por orddn dd generación, aunque el retsrdo del envio de los rrgusttos con incidencias te provoque una nueva incidencia, pero ya te digo, aquí cada uno va a hacer lo que quiera, ya verás.

Mmmm la verdad que no está claro, porque si por intentar enviar primero los que tienen incidencia te pasas de los 240 segundos en los que no la tenían, al final podrías tener todos en incidencia. Al final, como los de incidencia se envían en un lote separado y ya tenían incidencia yo creo que da igual cuándo los reenvíes. De hecho, en la Orden Ministerial decían que "En caso de que alguna incidencia técnica impida la remisión voluntaria en las condiciones indicadas se deberá proceder a la remisión de los registros de facturación en cuanto sea posible, respetando el orden temporal de generación de los registros de facturación....El sistema informático deberá reintentar periódicamente, al menos una vez cada hora, el envío de los registros de facturación pendientes de remitir.".

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.

[Casimiro Noteví]

Empezado por razorxxx

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

Creo que más de uno no está nada de acuerdo con esa afirmación

[ermendalenda]

Empezado por razorxxx

Mmmm la verdad que no está claro, porque si por intentar enviar primero los que tienen incidencia te pasas de los 240 segundos en los que no la tenían, al final podrías tener todos en incidencia. Al final, como los de incidencia se envían en un lote separado y ya tenían incidencia yo creo que da igual cuándo los reenvíes. De hecho, en la Orden Ministerial decían que "En caso de que alguna incidencia técnica impida la remisión voluntaria en las condiciones indicadas se deberá proceder a la remisión de los registros de facturación en cuanto sea posible, respetando el orden temporal de generación de los registros de facturación....El sistema informático deberá reintentar periódicamente, al menos una vez cada hora, el envío de los registros de facturación pendientes de remitir.".

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.

Purs lo mismo has interpretado lo que te he puesto en negrita un poco regu. Y lp que has puesto en negrita no solo se refiere a los que estan en incicidencia "pendientes de remitir"
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.

[razorxxx]

Empezado por Casimiro Noteví

Creo que más de uno no está nada de acuerdo con esa afirmación

Bueno, una vez en una versión ya más antigua de Delphi recuerdo hacer pruebas con hilos y recuerdo a cada rato recibir AccessViolation y errores similares. Tal vez hoy en día la cosa está mejor, si nos pusieras un ejemplo que funcione bien te lo agradecería en el alma, porque así podría crear un hilo diferente por cada obligado tributario. Saludos.

[ermendalenda]

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

[DarkDudae]

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.

[razorxxx]

Empezado por ermendalenda

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.

Los que ya tenéis un buen recorrido con el tema de envíos y gestión de respuestas...., ¿cuánto habéis calculado que suele tardar de media en responder el servidor de la AEAT? Lo digo por si mi timeout de 30 segundos es mucho o poco.