Cita:
Empezado por ermendalenda
Como he comentado en este hilo, he encontrado una pequeña anomalia en la definición del control de flujos respecto al reglamento, por lo cual he rogado que lo revisen para aumentar el tiempo a un tiempo viable, como os he dicho me contestan que lo han entendido y que verán si aumentan el tiempo pero algo leve. Bueno lo que sea es bueno.
Os explico la inconsistencia con un ejemplo:
Si la hora de mi sistema es las 9:00:00 y acabo de remitir una factura en segundo plano y me ha devuelto t=60 o da igual lo que me devuelva y en primer plano genero una factura a la misma hora que no se ha enviado en ese paquete. Esta claro que tengo que esperar un minuto de un registro generado a las 9:00:00...
Perooooo, aquí viene lo bueno...
Resulta que mi sistema tiene justo 1 minuto de retraso, cosa contemplada en el reglamento y no tengo por que arreglarlo, otra cosa es que lo arregle, pero me permite el reglamento? SÍ
Resulta que me espero el minuto y lo que para el reloj de mi sistema son las 9:01:00 para ellos son las 9:02:00 y aunque tarde 1 milésima de segundo en enviarlo justo después del minuto, tomaaaa Error 2004, no señor, me he quedado con el culo al aire y mi control de flujo está dentro del reglamento.
Pues nada solo eso.
Es rebuscado, pero posibles y con tantos envíos seguro que se les da bastantes casos, además la mayoría no vamos a mandar el registro justo en segundo 61, xon lo cual se les multiplica el problema, no tiene que ser justo con relojes retrasados 60 segundos.
Bajo mi punto de vista tendrían que dejar 120 segundos para solucionarlo si quieren dejar 60 segundos de margen. A ver uq e hacen
|
Ya, pero programaticamnete deverias verificar , como ya comentamos la hora del timestamp de respuesta de la aeat, que para ello lo devuelven, con la de tu sistema, para efectuar las correcciones adecuadas, o pensabais que de repente incuian eso sin motivo...
