Tarda poquisimo, yo he enviado 400 registros en un lote y no llega a 5 segundos, pero aquí hay que tener en cuenta distintas variablea:
Siempre vas tener una conexion estable y rapida?
Usas router de datos(tarjeta movil)?
Yo le tengo puesto parecido, 40 segundos, perp estoy pensando subirlo a 60 por que en algunas ubicaciones no llega fibra y tengo que usar datos.
Otra cosa importante es que el timeout lo tengas en cuenta restando a los 240segundos, por que si consideras que aun puedes enviar sin incidendia teniendo por ejempño, ya pasados los 210 segjundos, y hay un retardo puedes pasarte de los 240 y mejor que salte el timeout antes de llegar a lps 240 segundos y mandarlo como incidenxia posteriormente

O sea, que a los 240 segundos le resto mi timeout, y ése sería el tiempo para comparar el primer registro pendiente de envío con el último para saber si hay que añadir el campo Incidencia = S?

Abro debate?
Considerais racional tener que ir andando con calxular si se ha pasado los 240 segunfos para poner la marca de incidencia, que sentido tiene si te pasas del tienpo, lo avises o no lo avises, por ejemplo:
Corte de luz y habia registros pendientes, cuando encienda vemos que hay registros pendientes y si estan en tiempo podemos enviarlos y si no lo estan marcamos incidencia y enviarlo... de verdad que no encuentro el sentido, alguien controla todos los motivos por los que se van a mandar tarde, por que srria racional si se pudiera y hubiera una descripxion del motivo, si no es que no tiene sentido marcarlos
Yo lo veo una colada que nos han metido. Quizas, para acojonar mas?

Sí, sería lo recomendable. De hecho ya me ha psado, por eso ahora lo resto.
Simplemente puede pasar que tengas un problema de red puntual y se quede mas tiempo y se coma el timeout completo y acabe enviandolo en los ultinos segundos del timeout.

Dicen que los están aceptando fuera de tiempo sin tener que poner lo de Incidencia=S, en el futuro ya se verá si se ponen más estrictos. Pero si se están enviando con Incidencia, y lo registras también internamente en tu SIF o aprovechas para enviarte un mail de aviso, al menos ya sabes que algo raro está pasando con el SIF, con la conexión o con el servidor de la AEAT.

Sí, bueno lo del email ya es una cosa personal , eso o algun metodo de notificaciones, hay quien usa telegram para enviar los mensajes, supongo que el cometido es ese, acojonar un poco y que estemos alertas a estas cosas.

El problema es que en Delphi hay 3 tipos de Timeouts para los envíos por SOAP (componentes THTTPRIO): uno para establecer la conexión, otro para el envío y otro para la recepción de la respuesta. ¿cómo se puede hacer para usar un timeout general de, digamos, 30 segundos?

A ver, el más extenso en tiempo debe ser el de esperar la respuesta, te explico por qué:
Verifactu recibe inmediatamente lo que envianos, pero encola las respuestas, con lo cual si le entran 100.000 envios en un segundo, las reciben todas y posteriormente dan la respuesra una vez que analizan el fichero recibido y responden en orden de entrada
Con lo cual
Establecimiento dd conexion =10 segundos van sobrados
Timeout envio= 20 va bien
Respuesta= lo máximo que puedas 30 o 40 segundos.

¿Qur puede ocurrir?
Que enviado el lote no recibas respuesta, y tu programa te dé el timeout, para tí no está enviado, pero ellos lo han gestionado, y cuando vuelvas a enviar te puede dar uno más registroa duplicados cuando tu no los tenias marcados, eso es importante tenerrlo en cuenta.

Sí, eso ya pasaba con el SII, el famoso error 3000. Cuando se reciba el error de registro duplicado, en mi sistema pasaré dicho RF a la tabla de Enviados (si bien mi app va a funcionar exclusivamente en modo VeriFactu, quiero que exista un histórico de lo que se ha mandado). El problema es que en estos casos el CSV no se puede recuperar, ni siquiera desde la consulta de RF, aunque creo que es un campo que realmente me lo puedo ahorrar en la tabla.

Si hombre, lo tienen controlado, cuando mandas un regustro duplicado si ha tendio algun error te lo devuelven junto con la respuesta de registro duplicado.
O sea pueden devokverte registro duplicado y fuera de tiempo, eso significa que cuando se envió entro tarde y sin marcar incidencia.
Pero si lo mandaste xomo incidencia creo que se pierde el rastro de que lo mandaste xomo tal, tanto en consulta como en la respuesta de duplicado, pero eso ya lo puedes contemplar tú.

Que la gente no tenga excusas para enviar cuando le parezca.

En absoluto.

Yo, o no lo entiendo o lo tengo demasiado claro.

Que tiene que ver los segundos de timeout, los 240 segundos (no sé por que esa fijación/manía con esa cantidad) o los que sean con enviar con el indicador de incidencia?

Si hay incidencia, pues se envía con el indicador de incidencia sean los segundos que sean; ha habido una incidencia, pues indicador a 'S'. Es una incidencia, da igual cuando ocurra.
Es decir, controlo la incidencia no cuando se da.
Ojo. Para mi que Veri*factu esté caído es una incidencia como cualquier otra, solo que la provoca el propio Veri*factu.
Mi cometido es enviar a Veri*factu, si por el motivo que sea no puedo, estoy sufriendo una incidencia.

Yo los XML los envío y me echo a dormir, si no recibo respuesta (timeout, caída de electra, internet o lo que sea), tengo un indicador del estado del envío ('Xml generado') que no ha cambiado a 'Enviado' (otra cosa es su respuesta); y además guardo para cada RF de ese XML el error (el de electra evidentemente que no podré).

Ese indicador del estado lo veo en pantalla y cuando CREO CONVENIENTE le doy al botón para volver a enviar (que sólo actúa si el estado es 'Xml generado'). Mi sistema de envío ya me dirá si han transcurrido los segundos de espera que me indicó hacienda en el último envío y continuaré o no; y además me pregunta "¿Quiere añadir indicador de incidencia?" (ya lo automatizaré), le digo que si y se envía.

Y cuando me llame alguien (ya se ha dado el caso) lo hemos resuelto con el botón de 're-envío'.

Eso si, en los primeros meses tocará redactar las soluciones que se den a circunstancias concretas y EXPERIMENTADAS. Que la teoría es como los powerpoints, lo aguantan todo.
En este caso, en mi caso: "Si el estado del envío es 'XML generado'-->>PULSE EL BOTÓN AZUL."

Añado: Y de mientras el sistema va facturando, generando RF (en otro XML diferente con 'n' RF) y enviándolos. Todo sigue su curso.

¡Buenas tardes!

Seguro que lo tenéis controlado, por eso solo quería recordar lo que menciona la Orden Ministerial que regula el Verifactu, en el artículo 16, punto 4 párrafo 2.

Nosotros cada hora revisamos si hay registros que están pendientes de enviar (sea porque no había internet, se fue la luz, o porque el envío entero devolvió un SOAP Error (por ejemplo, servidor de la AEAT caído)) y, si hay alguno pendiente de enviar, lo intentamos enviar. Si se arregla, genial. Si no, en una hora se volverá a intentar, y así hasta que se envíe.

¡Espero que sirva! :)

Yo intento cads 10 segundos.
Y nada de boton de reintento, el reglamento es claro, automatico, y mejor si no es muy sacrificado.

Tampoco es necesario cada 10 segundos, con que lo intentes cada 60 segundos por ejemplo, creo que estarías cubierto. Y el sistema trabajaría 6 veces menos.

Ya está muy depurado el procediniento y en su momento lo analicé así, he visto otros que lo hacen cada 20 segundos, he optado por un poxo más de sguridad en el envio a cambio de un pelín más de recursos, y no he visto que afecte a nada aprciable.
Fijate que a más numero de intentos en instalaciones de escritorio, menos probabilidades dr enviar con incidencias por problemas puntuales de internet

La respuesta normal debería llegar como máximo en 1 o 2 sg (por tirar largo).
Si llegas a 30 (o yo diría 5 sg.) es que hay problemas.

En nuestro caso, tras cada envío, se realiza una pausa de los segundos que en la respuesta de la AEAT figuren.
Tras esto, se vuelve a comprobar si hay registros pendientes de enviar, cada 5 segundos mientras no los haya.
En el momento que haya registros pendientes, volvemos a empezar.

Por supuesto, es un proceso completamente independiente del proceso de facturación.

!! Ah, se me olvidaba !!. En mis pruebas y a los clientes que ya tengo instalados, la respuesta es inmediata. Siempre inferior a 2 segundos.

A aquellos de ustedes que ya les ha pasado lo de enviar con el tiempo superior a 240 segundos (error 2004), ¿el registro se queda en AceptadoConErrores o como Correcto?

Si consultas el servicio verás que pone aceptado con errores, es lo que toca la fibra. Como saber con el sevicio de consulta si está esperando subsanación
Que lio de verdad. Son malos?... noooo, lo siguiente.
Como nos va a transmitir un posible inspector ese problema? Te va a decir, ahh no pasa nada, si te han dicho que con el 2004 nada.. un mojón...

Vaya, me lo temía. Supongo que en estos casos, se le mostrará en la interfaz al usuario que hubo error pero que no debe hacer nada para subsanarlo, no sé. Demasiadas casuísticas....

Demasiadas, sí, y esto tiene un solo camino (o dos). No es un proyecto realista.

Es muy fuerte, un proveedor nuestro de acaba de ir con 6 facturas de vuelta por que le he advertido que está todo mal:
El pobre venia contento por que, aunque se ha gastado una pasta y a pesar de que lo hayan retrasado, ya estaba tranquilo que cumplia:
-Se ha gastado una pasta en el nuevo programa
-El importe del QR no coincide con el importe de la factura
-Los descuentos no los aplica en el importe total del QR ni supongo que en el registro, evidentemente.
-No envia nada, solo pone el QR.
-No le habian dicho que era imprescinbible poner el certificado para enviar.

"Aceptado con errores" creo recordar

No hay que hacer nada (o al menos nosotros no hacemos nada). El registro de Facturación es correcto (no hay que modificar nada) salvo que se ha enviado con retraso.

Ayer, precisamente ayer me encontré con la 1ra. factura simplificada con el QR!!!
Lo leo con el móvil y... apuntaba al entorno de pruebas y no encontró la factura, lástima.
Era el del desayuno, me dió una alegría (No estamos solos!!!), me duró hasta las 12.