Diferencia máxima de 120 segundos???

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

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?