Diferencia máxima de 120 segundos???

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

[YellowStone]

Hoy voy a probar a mandarlo fuera de plazo como incidencia, a ver si la respuesta es la misma. Luego digo.

[ermendalenda]

Te la va aceptar ok.

Por otro lado, cuando me refiero a segundo plano, me refiero además, que este en otro ejecutable que no puedan cerrar, además, tanto Windows como Linux tienen opciones para ejecutar programas al apagar el equipo, con lo cual puedes meterme que se espere el tiempo que necesites para enviar lo que quede pendiente y si no queda nada cerrar la aplicación y ya se apaga automáticamente.
Ten en cuenta que en Windows si le das a apagar se cierra todo y después ejecuta lo que hayas puesto en la hilera de apagado, con lo cual tienes que reabrir el programa de envío y cerrarlo cuando acabe lo pendiente