Diferencia máxima de 120 segundos???

[Maska10]

Buenas gente,

Me explota la cabeza con esto de la diferencia horaria ... el campo FechaHoraHusoGenRegistro se completa cuando se genera el fichero de alta, es decir, cuando se hace la factura simplificada o factura regular (o anulación o lo que sea), vale que lo vamos a enviar al instante (o en mi caso con un temporizador de 1 minuto), pero leñe:

- ¿que pasa si el usuario tiene un corte de suministro de red?
- ¿que pasa si tenemos una respuesta del envio anterior de esperar 60 segundos?

Esta restriccion de FechaHoraHusoGenRegistro no tiene sentido . ¿como lo gestionais?

Saludos.

[Faneka]

Yo he puesto desde que creo el primer registro de facturación hasta que lo envio un contador y si se pasa de 120' marco como incidencia la cabecera, en principio no debe pasar más de unos segundos entre la creación y el envio. De momento lo tengo así, no se si le dare alguna vuelta más.
Por otro lado si no se puede enviar porque hay un corte, fallo router, el certificado esta caducado, etc.. lo marco tambien con incidencia S y cuando se pueda enviar se enviara.

[[newtron]]

Empezado por Faneka

Yo he puesto desde que creo el primer registro de facturación hasta que lo envio un contador y si se pasa de 120' marco como incidencia la cabecera, en principio no debe pasar más de unos segundos entre la creación y el envio. De momento lo tengo así, no se si le dare alguna vuelta más.
Por otro lado si no se puede enviar porque hay un corte, fallo router, el certificado esta caducado, etc.. lo marco tambien con incidencia S y cuando se pueda enviar se enviara.

Si, creo que no hay otra.

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

[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

[ermendalenda]

Adjunto imagen de como lo tengo

[ermendalenda]

Para añadir el scrip de apagado, que puede ser un exe, un bat....
se añade desde [ejecutar programa](cmd)/gpedit.msc
desspues vas en las directivas de seguridad local a [Configuracion del equipo][configuracion de windows][Scripts de inicio apagado] y en el lado derecho eliges apagado y le añades lo que quieras ejecutar.
Adjunto Imagen

[ermendalenda]

Ya he enviado la consulta a verifactu si es necesario enviar la subsanacion.
Me responderán rápido como es habitual