Control de flujo

[ermendalenda]

Empezado por bmfranky

No, de acuerdo, estoy de acuerdo en todo, he dicho que os daba y quitaba la razon, es que no me gusta darle la razon a nadie "Es broma".
A lo que me referia es que indicais que la forma de gestionar las facturas es incorrecto si no se crea un gestor de envios, que tenga en cuenta los tiempos y demas, y "Personalmente" indico que para un SIF monopuesto y con un bajo nivel de facturacion , no es necesario, solo eso, no es que este encontra de lo que indicais , ni me parezca, mal ni nada de eso, si lo ha parecido , me disculpo.

Nada hombre, no hace falta disculparse, es que no termino de entenderlo.
Si no entiendo mal propones:

A mi se me ocurre , por ejemplo:


Se inicia el servicio:
1 -> Contadores de tiempo, incidencias etc a 0, false, primer envio true, etc...
2 -> Consulta a la tabla en la que se insertan los registros de facturas, abonos, restificativas ,etc a enviar.(esta consulta se realiza periodicamente cada 1" por ejemplo...

Para mi esto es lo mismo que hacemos los demás, un servicio de control de flujos teniendo en cuenta los tiempos. No veo diferencia

[Neftali [Germán.Estévez]]

Empezado por bmfranky

La verdad es que siguiendo el ejemplo que me indicabas, pongamos que simplemente, para algunos en vez de 60" voy indicando caja 100 "*Pedidores" un segundo de diferencia,osea a unos 61, 62, 63 , etc.., la atencion por segundo la desplazo a 1000 por segundo que ahi si lo puedo asimilar, por decir algo, osea los descuadran , no necesariamente acia arriba, igual hacia abajo.

*Lo se no seria asi, pero es para que me se me entienda.

Lo siento, pero no te he entendido la explicación.

[bmfranky]

Empezado por ermendalenda

Nada hombre, no hace falta disculparse, es que no termino de entenderlo.
Si no entiendo mal propones:

Para mi esto es lo mismo que hacemos los demás, un servicio de control de flujos teniendo en cuenta los tiempos. No veo diferencia

Si, tienes razon, lo explico para el que no lo tenga claro, como seria la operativa, por que como tu mismo dices , se ve mucha gente que no lo pilla.

[bmfranky]

Empezado por Neftali [Germán.Estévez]

Lo siento, pero no te he entendido la explicación.

Simplemente que el tiempo a esperar, deve ser como bien dices para que no se le acumulen peticiones a la vez, cuando las empresas grandes por ejemplo 300 BK, con 10 cajas automaticas y pedidos online, etc, se pongan en hora punta al lio, simplemente con unos segundos de desfase, se desahogan, no es necesario que indiquen un porron de segundos demas de espera.
Perdon por no explicarme mejor.

[unomasmas]

Empezado por Logan05

Como es lógico estoy planteando el tema con paquetes, y yo me refiero a si la factura se pasa de plazo mientras está en la cola. ¿habría que marcarla antes de ser enviada? eso implicaría que hay que revisar si o si el paquete antes de enviarlo, imagina que hay una demora porque (por lo que sea) te dan un plazo de envío de 5 minutos, o 7, o una hora, es una incógnita.

Pues como dice newtron , "ahímasdao"... Pero entiendo que ese plazo (que ahora siempre es de 60 segundos) no pueda aumentar más allá del mínimo de 120 segundos que dan ahora para remitirla y si aumenta más de eso, también aumenten ese mínimo que ahora está en 120. Tienen que hacerlo así ¿No?

[unomasmas]

Empezado por Neftali [Germán.Estévez]

O me estoy perdiendo algo, a esto os va a dar errores.
1) Generáis 2 facturas con una diferencia de tiempo de 20 segundos y el tiempo que está devolviendo la AEAT para esperar entre envíos es de 60 sg. (por defecto)
2) Si intentáis enviar la facturas inmediatamente después de su generación, váis a tener problemas.

¿Es correcto?

Sí, es correcto. Por eso se trata de un intento (es una mala expresión; debiera haber dicho "se pone a la cola"). Lo que pasa es que en mi planteamiento esa cola se comprueba con dos eventos (Timer, o sea cada x tiempo revisa si hay algo que enviar y en el mismo proceso de ponerla en la cola: comprueba cómo está el asunto del tiempo para en caso de estar en plazo enviarla directamente sin necesidad de esperar a una nueva comprobación del timer).

[[newtron]]

Creo que estamos divagando con este tema más de la cuenta e igual lo estamos complicando. A ver... un ejemplo tontuno rollo lemmings :


Supongamos que tenemos un pasillo estrecho con una puerta. Al primero que llega se le abre la puerta, pasa y se cierra y al lado de la puerta hay una pantalla que dice 120, estos son los segundos que se ha respondido que faltan hasta que se vuelva a abrir. Todos los que van llegando se van quedando detrás del último que haya. Cuando el contador llega a 0 se vuelve a abrir, pasan todos los que hay esperando (siempre que sean menos de 1000), se vuelve a cerrar y el contador se vuelve a poner en 120. Y así sucesivamente.


No sé si he aclarado algo.


Saludos.

[bmfranky]

Empezado por newtron

Creo que estamos divagando con este tema más de la cuenta e igual lo estamos complicando. A ver... un ejemplo tontuno rollo lemmings :


Supongamos que tenemos un pasillo estrecho con una puerta. Al primero que llega se le abre la puerta, pasa y se cierra y al lado de la puerta hay una pantalla que dice 120, estos son los segundos que se ha respondido que faltan hasta que se vuelva a abrir. Todos los que van llegando se van quedando detrás del último que haya. Cuando el contador llega a 0 se vuelve a abrir, pasan todos los que hay esperando (siempre que sean menos de 1000), se vuelve a cerrar y el contador se vuelve a poner en 120. Y así sucesivamente.


No sé si he aclarado algo.


Saludos.

Si , pero ten en cuenta que si hay 1000 esperando, la puerta se abre sin necesidad que se acabe el tiempo.

[[newtron]]

Empezado por bmfranky

Si , pero ten en cuenta que si hay 1000 esperando, la puerta se abre sin necesidad que se acabe el tiempo.

Efectivamente querido Watson, el lemming número 1000 tiene la llave maestra y abre la puerta.

[bmfranky]

Empezado por newtron

Efectivamente querido Watson, el lemming número 1000 tiene la llave maestra y abre la puerta.

Pos sii...

[ermendalenda]

Buenas, por si os pasa o quereis controlar esto:

He forzado un cambio de fecha(como si fuera accidental) a 1 mes futuro y me ha pasado esto (lógicamente):
-Respuesta Verifactu (No se puede mandar a fechas futuras)
Vuelvo a poner la fecha correcta, arreglo el desastre rectificando o subsanando(no lo he pensado aun)
-Mi control de flujos se queda en espera de que llegue de nuevo esa fecha/hora + el "t".

He cambiado el control de flujos que si la diferencia de tiempo es mas de 3600(negativos) lo ponga a positivo para que vuelva a enviar y grabo la nueva hora/fecha de ultimo envio.

[[newtron]]

Empezado por ermendalenda

Buenas, por si os pasa o quereis controlar esto:

He forzado un cambio de fecha(como si fuera accidental) a 1 mes futuro y me ha pasado esto (lógicamente):
-Respuesta Verifactu (No se puede mandar a fechas futuras)
Vuelvo a poner la fecha correcta, arreglo el desastre rectificando o subsanando(no lo he pensado aun)
-Mi control de flujos se queda en espera de que llegue de nuevo esa fecha/hora + el "t".

He cambiado el control de flujos que si la diferencia de tiempo es mas de 3600(negativos) lo ponga a positivo para que vuelva a enviar y grabo la nueva hora/fecha de ultimo envio.

Puf... yo creo que si te has equivocado en la fecha (tanto p'alante como p'atrás) y te viene rechazada lo que procede es una rectificativa por sustitución.


Saludos.

[ermendalenda]

Empezado por newtron

Puf... yo creo que si te has equivocado en la fecha (tanto p'alante como p'atrás) y te viene rechazada lo que procede es una rectificativa por sustitución.


Saludos.

Si, bueno, pero a donde quería ir es que he tenido que cambiar el control de flujos de envios para esos casos.

[[newtron]]

Empezado por ermendalenda

Si, bueno, pero a donde quería ir es que he tenido que cambiar el control de flujos de envios para esos casos.

No entiendo, igual es porque no sé (o no entiendo) exactamente cómo tienes orientado el control de flujo. Yo en particular lo tengo por orden de "caida", es decir, me da igual la fecha que tenga el documento, ni el de delante ni el de detrás. Según se van emitiendo en ese mismo orden los voy encolando y si me viene alguna rechazada por el motivo que sea directamente se gestiona una sustitutiva porque (de forma normal) habrá pocas que se puedan subsanar.


Saludos.

[ermendalenda]

Empezado por newtron

No entiendo, igual es porque no sé (o no entiendo) exactamente cómo tienes orientado el control de flujo. Yo en particular lo tengo por orden de "caida", es decir, me da igual la fecha que tenga el documento, ni el de delante ni el de detrás. Según se van emitiendo en ese mismo orden los voy encolando y si me viene alguna rechazada por el motivo que sea directamente se gestiona una sustitutiva porque (de forma normal) habrá pocas que se puedan subsanar.


Saludos.

Hola
Por el tiempo de espera entre envios. No por el orden
Si el reloj del equipo se me ha puesto en marzo, el último envio lo tengo registrado como marzo, con lo cual si cuando ponga correctamente la hora del equipo no lo gestionaban no va a enviar las siguientes facturas hasta marzo + 60s

[bmfranky]

Empezado por ermendalenda

Hola
Por el tiempo de espera entre envios. No por el orden
Si el reloj del equipo se me ha puesto en marzo, el último envio lo tengo registrado como marzo, con lo cual si cuando ponga correctamente la hora del equipo no lo gestionaban no va a enviar las siguientes facturas hasta marzo + 60s

Hola, para evitar eso mismo, no seria mejor que el temporizador, no tenga en cuenta la fecha hora, sino que se genere una interupcion de por ejemplo 50" + el t que devolvio hacienda?
Asi no tienes problema en los tiempos de espera, ademas de que puedes aprovechar el timestamp en la respuesta para mantener en hora el tiempo del sistema, sin problemas.

Ten en cuenta que el primer envio, es inmediato en el momento de iniciar el servicio, puesto que no hay un tiempo de espera devuelto por la aeat si acabas de iniciar, a partir de ahi, controlas tu los tiempos, no absolutos , sino relativos a tu temporizador interno y los tiempos devueltos por la aeat.

Osea si tu temporizador aun no es cero, encolas todo lo que te llegue, sin tener en cuenta la fecha hora del registro, cuando llegue a 0 envias, de ahi a no apurar mucho contando 50" + el default 60" = 110" , no creo quye haya problemas en enviar, procesar los registro en 10", por muchos que sean.

[[newtron]]

Puffffffffffffff.... yo de momento no entro a controlar esas cosas... en el futuro ya veremos.

[BorjaRRR]

Buenos días,


He estado haciendo pruebas y todos los envíos me devuelven ok independientemente del tiempo entre envíos. He probado a lanzar dos envíos en un intervalo de unos segundos y también con un intervalo de mas de dos minutos, todos me devuelven ok.

Tenía entendido que había que realizar los envíos con un mínimo de 60 segundos (lo que devuelven en la respuesta) y un máximo de 120 (60 + margen 60).
¿Esto es correcto?



Saludos

[gcqZW]

Si no me equivoco por ahora esta en pruebas y deja mandar de forma seguida, pero ten cuidado que a algunos les han baneado temporalmente debido a eso.

[BorjaRRR]

Creo que estaba enviando mal los registros. En el campo FechaHoraHusoGenRegistro de cada registro le estaba metiendo la hora actual con los cual todos los registros iban con el mismo valor de FechaHoraHusoGenRegistro.
Ahí está la clave, entiendo que ese campo debe llevar el instante en el que se genera la factura y es ahí donde hacen las comprobaciones de los tiempos de envío.
¿Esto es así o me equivoco?