Bloqueo envio

[ermendalenda]

Hola.
Mirad esto no es la primera vez que me pasa, y debida a la gran cantidad de tiquets que se generan, me temo que cada varios días me va a pasar, siempre en fin de semana.
Acabo de tener un aviso de envio en fuera de tiempo, pero fijaos:
- Comienzo envio 12:04:13 despues de esperar el anterior y el registro ya tenia algunos segundos, se generó a las 12:03:26.
- Pues bien, a pesar de tener los timeouts en 40 segundos, el curl se queda enganchado y me dan la respuesta a las 12:07:52.
- Bicheando por todos lados, parece ser que es posible que el servidor bloquee por cargas excesivas, firewall internos, bugs.. y los envios no puedan saltar por que hay actividad TCP,
- O sea, cuando empiecen todos a enviar, que va a pasar?
-Y yo me quedo con el 2004, espero que lo tengan contemplado.
- Joder esto no lo tenia yo previsto. voy a tener que hacer otro hilo de matar envios si se pasa de tiempo.


- Voy a reportarselo a ver que me dicen

[ermendalenda]

Aaaahhh ya creo que tengo la solución, mañana la pruebo, hay que añadir 2 parametros máa al curl. Jajaja vaya tela de paranetros:

--speed-time 10 --speed-limit 1

Esto significa:
Si en 10 segundos no llegan 1 byte, aborta SIEMPRE.

Aunque he mandado la consulta para ver si me tengo que asustar para estos temas ocasionales del error 2004, creo que la respuesta puede ser interesante

[Carlos]

Empezado por ermendalenda

Aaaahhh ya creo que tengo la solución, mañana la pruebo, hay que añadir 2 parametros máa al curl. Jajaja vaya tela de paranetros:
--speed-time 10 --speed-limit 1

Esto significa:
Si en 10 segundos no llegan 1 byte, aborta SIEMPRE.

Aunque he mandado la consulta para ver si me tengo que asustar para estos temas ocasionales del error 2004, creo que la respuesta puede ser interesante

Precisamente estos días he añadido a mi solución un botón que:
-busca todos los errores 2004 que no se han 'revisado'.
-clona los RF correspondientes a estos errores con fecha y hora del momento de la clonación (cada RF debe tener su propia fecha y hora de creación).
-dejo los 'nuevos' RF preparados para enviarse como subsanación junto con todos los RF que existan para enviar.
-marco los errores 2004 como 'revisados'.
-cuando debe generarse un nuevo envío, se creará el XML correspondiente y se enviará.
-seguimos para bingo.

[ermendalenda]

Empezado por Carlos

Precisamente estos días he añadido a mi solución un botón que:
-busca todos los errores 2004 que no se han 'revisado'.
-clona los RF correspondientes a estos errores con fecha y hora del momento de la clonación (cada RF debe tener su propia fecha y hora de creación).
-dejo los 'nuevos' RF preparados para enviarse como subsanación junto con todos los RF que existan para enviar.
-marco los errores 2004 como 'revisados'.
-cuando debe generarse un nuevo envío, se creará el XML correspondiente y se enviará.
-seguimos para bingo.

Hola.
Si no me equivoxo, el 2004 no necesita de subssanacion, solo tenerlo en cuenta para revisar el software(control de flujos)
Tienw pinta quw he malinterpeetado: "este caso se excepxiona de ser subsanado" y twnga algun condicionante que no haya interpretado yo.

[Carlos]

Empezado por ermendalenda

Hola.
Si no me equivoxo, el 2004 no necesita de subssanacion, solo tenerlo en cuenta para revisar el software(control de flujos)
Tienw pinta quw he malinterpeetado: "este caso se excepxiona de ser subsanado" y twnga algun condicionante que no haya interpretado yo.

Eso mismo interpreté yo en una primera lectura, una vez releído crei entender que si que precisaba subsanación.
Debo releerlo nuevamente, aunque ya en una respuesta de Veri*factu me decían que no precisaba subsanación.
Yo por si acaso lo tengo preparado, me ha costado poco.
De paso me ha servido para ver si encaro algún otro caso fácil de resolver, como el de NIF no censado que enviaría con el tipo 'No censado'; pero esto de momento no lo he tocado.

[ermendalenda]

Joder vaya lio, por un lado esto:
"0.7.2 21/05/2024 Eliminación de la categorización de errores admisibles subsanables y no subsanables. El error en el campo FechaHoraHusoGenRegistro se excepcionada de la necesidad de subsanación. "
Por otro esto en el mismo documento:

"Si se ha informado en el campo FechaHoraHusoGenRegistro una fecha y hora mayor que la fecha del sistema de la AEAT, admitiéndose un margen de error. Se excepciona este error de la necesidad de ser subsanado."

Pero en el listado de errores, en la parte de errores que necesitan ser subsanados, esta incluido el 2004.

,¿necesito un abogado?

[ermendalenda]

Voy a hacerte caso, por equivakencia a las reglas de trafico: a 2 señales de tráfico se hace caso a la más restrictiva, y si está en la tabla de errores subsanables es más coherente hacerle caso que a una explicación sesgada y posiblemente, igualmente malinterpretada por el canal de ayida, por que evidentemente crea confusión.
Y lo que tengo clsro es que ese error lo voy a evitar aunque tenga que matar el proceso de envio si no hace caso al timeout y a las 2 opciones nuevas que añado para que salte. Cada vez que emita un envio pararelamente un trigger que vigile y de un tiempo de espera que si no se cumple, tacatá, fuera proceso y a volver a intentarlo, y se acabó el "bloqueo" y si veo que sigue pasando, poe que a pesar de matar el proceso se quede algo internamente (no visible) procesando, le mando un reinicio a la maquina y se acabó.

[Carlos]

Bueno, como son unas horas en las que estoy tranquilo me he dedicado a recopilar información al respecto del error 2004.

En el listado de errores (a 02/10/2025) se indica:
"2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:"

Ojo, este margen podría ser en exceso y en defecto? Es decir, haber enviado demasiado tarde el RF o haber enviado demasiado 'pronto' el RF. Se me entiende?
En defecto? Fecha/hora futura? Es absurdo, pero cobra sentido si leemos más información al respecto (más abajo punto 4.3.1).

En el documento "Validaciones_Errores_Veri-Factu.pdf" de fecha 02/10/2025.

* en el inicio del documento, HISTÓRICO DE REVISIONES, se indica:
"0.7.2 21/05/2024 Eliminación de la categorización de errores admisibles subsanables y no subsanables. El error en el campo FechaHoraHusoGenRegistro se excepcionada de la necesidad de subsanación."


* en el apartado 3.1.3, punto 20-FechaHoraUsoGenRegistro se indica:
"Se validará que la FechaHoraHusoGenRegistro sea menor o igual que la fecha del sistema de la AEAT, admitiéndose un margen de error. En caso de superar el umbral, se devolverá un aviso de error (no generará rechazo)."

Ojo, dice 'MENOR'.


* en el apartado 3.1.4, punto 6-FechaHoraUsoGenRegistro se indica:
"Se validará que la FechaHoraHusoGenRegistro sea menor o igual que la fecha del sistema de la AEAT, admitiéndose un margen de error. En caso de superar el umbral, se devolverá un aviso de error (no generará rechazo)."

Ojo, dice 'MENOR'.


* en el apartado 4.3.1 se indica:
"Si se ha informado en el campo FechaHoraHusoGenRegistro una fecha y hora mayor que la fecha del sistema de la AEAT, admitiéndose un margen de error. Se excepciona este error de la necesidad de ser subsanado."

Ojo, dice 'MAYOR'. (1)


Quizás debe ser un error en la redacción del documento, pues la mención 'MAYOR' al respecto de no subsanación, me obliga a que si es MENOR la FechaHoraHusoGenRegistro sí que debo subsanar.

Una vez releído y ante esta duda he optado por desarrollar una función que subsane semiautomáticamente este error 2004; no sé si deberé utilizarla pero de momento estoy preparado para ello.


(1) Me están diciendo que puedo enviar facturas y RF con fecha futura (enviar el 29/mm/aaaa con fecha 01/mm+1/aaaa), y que los acepta, y que no los debo subsanar?
No, por que las rechazaría por fecha factura futura (error 1112).

OFF TOPIC-NOTA: son unos cracks. El error 1235 y 1236 son idénticos.

[ermendalenda]

Me confirman que no es necesria la subsanacion, no obstante le he enviado la exposición completa.

[Carlos]

Empezado por ermendalenda

Me confirman que no es necesria la subsanacion, no obstante le he enviado la exposición completa.

Tal como está redactado se debe subsanar si o si; por que el código de error que se recibe para el caso de MENOR es el mismo que para el caso de MAYOR, con lo cual no sabes por qué tienes el error, por tanto a subsanar.

De lo que digan si no está en manuales/procedimientos/órdenes ministeriales/leyes... no me puedo fiar nada. Es un problema que tengo, he visto algún que otro CallCenter y como en todas partes te encuentras al genio y al incompetente.

Lo suyo, (que lo tengo en cartera de hace 4 meses) es enviar una consulta vinculante. Igual que para el error de NIF no censado (vaya barbaridad me respondieron).

[ermendalenda]

el parametro speedtime no ha dado resultado me ha hecho otra espera de 5 minutos y ha enviado al final de ese tiempo, y el dichoso 2004 que dicen que no pasa nada, pero no es agradable, entre otras cosas por que me llega el aviso y tengo que estar repasando.
La putada es que solo me pasa en 2 SIF's de unos 50 que tengo de momento instalados.
Nuevo parametro de curl que estoy probando para que no mantenga la conexion activa:
--no-keepalive
lo he agregado junto con los 2 de speedtime
Usado para que no mantenga/fuerce que la conexion se mantenga activa, si detecta que no hay actividad "cataplum" por lo que sea, o eso espero.

Alguien lo usa?

[razorxxx]

Empezado por ermendalenda

Me confirman que no es necesria la subsanacion, no obstante le he enviado la exposición completa.

No es necesaria la subsanación, pero me pregunto ¿sigue en pie aquello de que si la diferencia entre la fecha de generación del primer RF a enviar y el último supera los 240 segundos hay que marcar el envío como Incidencia=S?

Y a todas estas, en SIF funcionando en modo VeriFactu, ¿seguís leyendo la hora del ROA para marcar la fecha de generación de los RF?

[ermendalenda]

Empezado por razorxxx

No es necesaria la subsanación, pero me pregunto ¿sigue en pie aquello de que si la diferencia entre la fecha de generación del primer RF a enviar y el último supera los 240 segundos hay que marcar el envío como Incidencia=S?

Y a todas estas, en SIF funcionando en modo VeriFactu, ¿seguís leyendo la hora del ROA para marcar la fecha de generación de los RF?

Sí y Sí.
1. Pueden ocurrir algunos escenarios muy muy concretos en los que se envien sin la marca:
- Que no hayas controlado bien el control de flujo en algún punto.
- Que a pesar de enviar en tiempo no tengas controlado en el envio que en 1 situación de cada 50.000 el envio se quede esperando la respuesta y lo envie a los 5 minutos. Es raro pero pasa esegún el método de envio y los parametros que le tengais puesto, y no hablo de los timeouts, que según que método al ver que aún hay actividad TCP, no salta el timeout.
En las respuestas me dicen que ese error no es subsanable y además que no me preocupe que solo es un control para que yo verifique que la hora del reloj de mi sistema puede no estar ajustado adecuadamente.
Mi conclusión, si tienes un 2004 de vez en cuando(cada 40000 ó más envios y normalmente manejas bien el control de flujo enviando incidencias, sin problema.
Lo del control de hora lo veo importante sincronizzarlo con el ROA, por supuesto, es más a windows le he desactivado cualquier otra sincronización de hora/fecha y lo hago por software.

Importante: a ver que pasa con el cambio horario después del verano de 2026.... Hay que estar pendiente y tenerlo en cuenta a ver como van a actuar vuestros programas según como controleis ese cambio horario.