Diferencia máxima de 120 segundos???

[ermendalenda]

Hay otra, no mucho más pero mejorable

privado si queréis info

[YellowStone]

Con respecto a esto, ¿donde está establecido que la diferencia debe de ser máximo de 120 segundos (o lo establecido con la anterior respuesta al envío) con este campo?


En el documento de validaciones, lo único que dice es que este campo debe de ser "igual o inferior" a la hora del servidor de la AEAT, como es lógico.

5. FechaHoraHusoGenRegistro
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).

Si hay algún otro sitio donde se establezca otra cosa, ¿podéis indicarme donde?

[Maska10]

Empezado por YellowStone

Con respecto a esto, ¿donde está establecido que la diferencia debe de ser máximo de 120 segundos (o lo establecido con la anterior respuesta al envío) con este campo?


En el documento de validaciones, lo único que dice es que este campo debe de ser "igual o inferior" a la hora del servidor de la AEAT, como es lógico.





Si hay algún otro sitio donde se establezca otra cosa, ¿podéis indicarme donde?

Pues ahora mismo no recuerdo muy bien donde lo lei ... pero el caso es que cuando hacía envios con tiempo pasado de esos 120 segundos el servidor de pruebas me los rechazaba, probaré de nuevo a ver.

[ermendalenda]

Empezado por Maska10

Pues ahora mismo no recuerdo muy bien donde lo lei ... pero el caso es que cuando hacía envios con tiempo pasado de esos 120 segundos el servidor de pruebas me los rechazaba, probaré de nuevo a ver.

A ver, es un algoritmo lógico,
En cada respuesta te devuelven en el nodo [tiempo]
El tiempo mínimo que tienes que esperar para el siguiente envío o, en sí defecto,si tienes ya 1000registros, el envío tiene que ser inmediato si tienes registrosdespues de ese tiempo de espera, PEROOO, como puedes tener un minuto de diferencia de margen con el reloj de ellos, te dan ese minuto para enviar. Y como el tiempo inicial de espera que te Dan es de 60segundos pues después de un envío esperas 60 segundos para el siguiente y si tienes algo tienes 60 para enviar por eso hablamos 120segundos, pero depende del escenario del que te encuentres en cada instante.

[bmfranky]

Empezado por YellowStone

Con respecto a esto, ¿donde está establecido que la diferencia debe de ser máximo de 120 segundos (o lo establecido con la anterior respuesta al envío) con este campo?


En el documento de validaciones, lo único que dice es que este campo debe de ser "igual o inferior" a la hora del servidor de la AEAT, como es lógico.





Si hay algún otro sitio donde se establezca otra cosa, ¿podéis indicarme donde?

Simplemente fijese en lo que devuelve cuando hay error de desfase del registro.

El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos

[YellowStone]

Aún no he generado registros que superen el umbral, así que lo provocaré próximamente.

Lo que creo es que el documento de Validaciones, este extremo no está correctamente definido, pues hablan que esa fecha/hora debe ser menor o igual a la de la AEAT, es decir, que provocaría rechazo si es superior a la de la AEAT.

Se me ocurren varios casos en que puede suceder, que se envíe la factura, por ejemplo, el día siguiente, porque el último usuario conectado crea la factura, e inmediatamente sale del sistema y se marcha a su casa, la factura se puede quedar sin enviar porque aún no ha pasado el tiempo necesario para poder realizar el envío desde el anterior. Cuando se envíe, la fecha hora del registro es menor o igual a la de la AEAT, pero ya me estáis diciendo que me va a producir un aviso de error, supongo que sin rechazo, como dicen en el documento.

[Faneka]

Empezado por YellowStone

Aún no he generado registros que superen el umbral, así que lo provocaré próximamente.

Lo que creo es que el documento de Validaciones, este extremo no está correctamente definido, pues hablan que esa fecha/hora debe ser menor o igual a la de la AEAT, es decir, que provocaría rechazo si es superior a la de la AEAT.

Se me ocurren varios casos en que puede suceder, que se envíe la factura, por ejemplo, el día siguiente, porque el último usuario conectado crea la factura, e inmediatamente sale del sistema y se marcha a su casa, la factura se puede quedar sin enviar porque aún no ha pasado el tiempo necesario para poder realizar el envío desde el anterior. Cuando se envíe, la fecha hora del registro es menor o igual a la de la AEAT, pero ya me estáis diciendo que me va a producir un aviso de error, supongo que sin rechazo, como dicen en el documento.

La acepta con errores, así que tampoco es tan grave pienso yo. Se puede quedar tranquilamente.

[ermendalenda]

Empezado por YellowStone

Aún no he generado registros que superen el umbral, así que lo provocaré próximamente.

Lo que creo es que el documento de Validaciones, este extremo no está correctamente definido, pues hablan que esa fecha/hora debe ser menor o igual a la de la AEAT, es decir, que provocaría rechazo si es superior a la de la AEAT.

Se me ocurren varios casos en que puede suceder, que se envíe la factura, por ejemplo, el día siguiente, porque el último usuario conectado crea la factura, e inmediatamente sale del sistema y se marcha a su casa, la factura se puede quedar sin enviar porque aún no ha pasado el tiempo necesario para poder realizar el envío desde el anterior. Cuando se envíe, la fecha hora del registro es menor o igual a la de la AEAT, pero ya me estáis diciendo que me va a producir un aviso de error, supongo que sin rechazo, como dicen en el documento.

Hola, donde viste lo de igual o menor, he mandado registros con 5 segundos por delante y se los ha comido
Si mandas muy tarde tienes que marcarlo como incidencia. Y te recomiendo un apr de cosas, proceso en segundo plano de envío ue no lo puedan cerrar y una comprobación al apagar el equipo

[Faneka]

Revisando he visto que si desde que se creo el RF hasta que se envia han pasado más de 120s lo marco como incidencia, no es normal que tarde tanto, algo esta pasando, así que como dijo ermendalenda yo tambien lo marco como incidencia.

[YellowStone]

<tikR:RefExterna>199184</tikR:RefExterna>
<tikR:EstadoRegistro>AceptadoConErrores</tikR:EstadoRegistro>
<tikR:CodigoErrorRegistro>2004</tikR:CodigoErrorRegistro>
<tikR:DescripcionErrorRegistro>El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos. /tikR:DescripcionErrorRegistro>

Como era de esperar, tenéis toda la razón.

Habrá que marcar entonces como incidencia antes del envío, que ahí ya sabemos si nos pasamos o no de los 120 segundos.

Gracias a todos.

[YellowStone]

Empezado por ermendalenda

Hola, donde viste lo de igual o menor, he mandado registros con 5 segundos por delante y se los ha comido
Si mandas muy tarde tienes que marcarlo como incidencia. Y te recomiendo un apr de cosas, proceso en segundo plano de envío ue no lo puedan cerrar y una comprobación al apagar el equipo

Lo de igual o menor está especificado en el documento de validaciones. Está claro de que no es así.

Lo del proceso en segundo plano, así lo estoy haciendo, y lo que quería decir con lo de cerrar la aplicación, es que si queda algo por enviar y aún no han pasado los 60 segundos (o los que sean que indique Hacienda), aunque hagas el proceso si no es la hora no envía. No sé, algo habrá que pensar para estos casos. Supongo que en nuestros clientes grandes este problema no existirá porque siempre habrá alguien con el programa abierto, pero los pequeños con 1 sólo puesto o pocos puestos, son los que casi me preocupan más. Pero bueno, esto creo que ocurrirá raramente. Se hace al día siguiente lo de incidencia, y tiramos para adelante.


De todos modos, ojo, porque estoy viendo que aunque las marque como "aceptadasconerrores", hay que proceder a su "subsanación". Ver puntos 4.3 y 4.4 del documento de validaciones. ¿o si le ponéis incidencia no las marca como aceptadas con errores?

[ermendalenda]

Yo no creo que hay que subsanarlos en ese caso, ya que en la O.M. pone más adelante que este pueden requerir que aportes por que han sido las incidencias, aunque esto se dará, supongo, en casos extremos de demasiadas incidencias. Aunque no estaría de más que alguien lo consultara, pero no 1lo veo lógico, ya les has identificado que hay un problema y sería un doble trabajo y puede darse el caso que hayas tenido un problema de varios días y no vas a mandar 2 veces lo mismo, como incidencia y después como subsanacion, no lo veo.
Yo le he puesto que si no envía. A los 110 segundoa o más bien a [t]+50(es más correcto) que lo marque, pata dejar esos 10 segundos de margen de envío por posibles ralentizaciones o descuadres de horas respecto a la hora de ellos
Perdona perdona, corrijo, di lo has enviado sin marcar incidencia es otra historia, habrá que consultar si hay que mandarlo posteriormente como subsanacion, ya que en ese caso es que no tienes bien el control de flujo para identificarlo antes ee enviarla de que esta fuera de hora o tienes el reloj mal.