Control de flujo

[ermendalenda]

Empezado por bmfranky

Hola, os doy y os quito la razon,
No es lo mismo, facturar las facturas una a una que por "bala" que seas, te da igual esperar 1 minuto, es mas o menos lo que tardas en introducir los datos , previsualiza y demas, que como vosotros gestionar un multi puesto que en 20" te pueden generar 10 facturas o mas, si es una caja que coje los datos de un codigo de barras y los asigna en decimas de segundo, ya me diras, entonces, no es la misma forma de plantear el control de flujo.
En mi caso es el siguiente, enpiezo a facturar realizo una consulta a la aeat para ver que este el servidor activo sino saco un mensaje para realizar una proforma y cuando haya conexion facturar y enviar, relleno lo necesario e intento enviar la factura, si todo OK, inicializo un timer con un flag que me impide enviar nada hasta que pasen los t segundos que devolbio hacienda.
Hasta el momento , incluso con las pruebas moñas tardo unos 45" en selecionar el tipo de factura, introducir algo en la mas sencilla que es un F2, previsualizar y enviar que en mi caso lo he dividido en 2 modulos independientes , y proceder el envio, esperar 15" mas no es problema, "OJO EN MI CASO".
En vuestro caso , si o si, se deve implementar un gestor de envios independiente, que solo recoja las facturas que se le pasen , encadenadas o encadenandolas el, haga los intentos de envio y demas gestiones, sin asistencia del usuario, exceptuando fallos catastroficos, diria yo.


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

->no vacia y primer envio a true, se hace consulta a aeat , asignando fecha y registro del primer envio en cola , se compruban todos los registros, descartan los ya enviados si los
hay , se realizan las diversas comprobaciones para ver si los registros de la bbdd coinvciden con los de la aeat, se envia los restantes con incidencia si timestamp superior a actual
+120".
->no vacia y tiempo de espera =0 o 1000 registros, envio inmediato. se pone el contador = a tiempo devuelto + 50 segundos.
-> tiempo de espera --1;
3 -> se van apilando, desapilando los registros segun sea necesario y se repite sucesivamente el punto 2.


Para apagar el servicio, se intenta primero vaciar la cola pendiente y luego se deja apagar.

Estoy equivocado en mi planteamiento?

Hola Bmfranky.
Has tenido en cuenta si te devuelven 3600segundos de espera? Por que he visto que hay gente que np
El problema es que muchos proponen enviar la factura inmediatamente aunque tengan que esperar.

[bmfranky]

Empezado por ermendalenda

Hola Bmfranky.
Has tenido en cuenta si te devuelven 3600segundos de espera?

Ya te digo yo , que 3600 segundos no te van a devolver, el tiempo de espera, lo han introducido para que no enviemos cada 20" 1 registro, 1 al minuto, 1 a la hora, no van ni a mirarlo, tiempo al tiempo, con ello, no es logico que ellos mismos generen incidencias de envio por el timestamp.
Ademas si nos devuelven 1 hora , pues o habreis llegado al limite de 1000 registros o se envia como incidencia.
Ya querria yo tener el problema de terminar 12 coches al dia y no poder facturarlos, por el tiempo de envio

[ermendalenda]

Empezado por bmfranky

Ya te digo yo , que 3600 segundos no te van a devolver, el tiempo de espera, lo han introducido para que no enviemos cada 20" 1 registro, 1 al minuto, 1 a la hora, no van ni a mirarlo, tiempo al tiempo, con ello, no es logico que ellos mismos generen incidencias de envio por el timestamp.
Ademas si nos devuelven 1 hora , pues o habreis llegado al limite de 1000 registros o se envia como incidencia.
Ya querria yo tener el problema de terminar 12 coches al dia y no poder facturarlos, por el tiempo de envio

Bueno, esa decisión digo yo que será cuestión de los parámetros que ellos tengan. Por que si esransaturados y deciden eso para todos se puede liar gorda si nadie hace caso al control de flujos u todos han optado por tener 1 minuto

[bmfranky]

Empezado por ermendalenda

Bueno, esa decisión digo yo que será cuestión de los parámetros que ellos tengan. Por que si esransaturados y deciden eso para todos se puede liar gorda si nadie hace caso al control de flujos u todos han optado por tener 1 minuto

Ojo, @elmendalenda, yo no he dicho 1 minuto yo siempre hago referencia a los t segundos que ellos devuelven, igual en vez de se 60" , son 20", porque ven que tus envios son muy espaciados...

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

Empezado por bmfranky

Ya te digo yo , que 3600 segundos no te van a devolver, el tiempo de espera, lo han introducido para que no enviemos cada 20" 1 registro, 1 al minuto, 1 a la hora, no van ni a mirarlo, tiempo al tiempo, con ello, no es logico que ellos mismos generen incidencias de envio por el timestamp.

Yo creo que de normal no van a cambiar los tiempos, pero me da que esta opción está pensada para evirtar sobrecargas en sus servidores.
Estoy pensando en momentos puntuales (final de mes) que la gente genere muchas facturas (o muchas empresas generándolas).

Con esto minimizas las peticiones realizadas a sus servidores.


Si cada 60 sg. tienes 100.000 peticiones, basta con enviar 120 sg. para tener la mitad o 240 sg. para tener un a cuarta parte (con el doble/cuadruple de facturas, eso si, pero no es lo mismo).

[bmfranky]

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

Yo creo que de normal no van a cambiar los tiempos, pero me da que esta opción está pensada para evirtar sobrecargas en sus servidores.
Estoy pensando en momentos puntuales (final de mes) que la gente genere muchas facturas (o muchas empresas generándolas).

Con esto minimizas las peticiones realizadas a sus servidores.


Si cada 60 sg. tienes 100.000 peticiones, basta con enviar 120 sg. para tener la mitad o 240 sg. para tener un a cuarta parte (con el doble/cuadruple de facturas, eso si, pero no es lo mismo).

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.

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

[ermendalenda]

Bmfranky

Acabo de releer tu mensaje de control de flujos y creo que haces un control de flujos lógico según el requerimiento, pero me ha liado cuando has puesto que estabas en acuerdo y desacuerdo. No entiendo en qué pinto tienes el desacuerdo.
El problema es que hay posta anteriores en que proponen un control de flujos no acorde a los tiempos (t)

[bmfranky]

Empezado por ermendalenda

Acabo de releer esto y creo que haces un control de flujos lógico según el requerimiento, pero me ha liado cuando has puesto que estabas en acuerdo y desacuerdo. No entiendo en qué pinto tienes el desacuerdo.
El problema es que hay posta anteriores en que proponen un control de flujos no acorde a los tiempos (t)

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.

[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

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