Control de flujo
 

Os cuento mi planteamiento por si le veis algún problema

Una vez generada una factura:

• [A] Si han pasado más de los 60 segundos preceptivos, se intenta enviar. Si surge algún problema de conexión, se añade a la lista de pendientes (si no está ya) y establezco la marca de "Incidencia" para el próximo envío.
• [b] Si no han pasado los 60 segundos, se añade a la lista de pendientes.

Un proceso se encarga de mirar cada X tiempo (no tengo claro cuánto ha de ser ese X tiempo) si hay facturas pendientes. Aquí distingo también dos circunstancias:

• [C] Si hay marca de incidencia, no se intenta la remisión (para evitar trabajo inútil). Se intentará la remisión aprovechando el envío de una nueva factura (estaríamos en el punto [A] de nuevo) o, en último caso, al cerrar la sesión.
• [D] Si no hay marca de incidencia, se intenta la remisión (volvemos al punto [A]).

Buenos días compañero.


No lo veo claro. El sistema (a mi forma de ver) es:


- Genero factura y la pongo directamente en la cola de facturas a enviar. Puede que no haya ninguna o puede que haya alguna pendiente de envío por lo que esta se agregaría a ese paquete.
- Se envía el paquete de posibles facturas pendientes, se recoge el tiempo a esperar para el siguiente envío, se vuelve a poner el programa en modo espera y se evalúan los resultados del último envío.

- Las facturas ok se olvidan y luego habrá que manejar manualmente las rechazadas porque casi con toda seguridad necesitarán una factura rectificativa.


Saludos.

El planteamiento me parece bien, pero en el momento de hacer el siguiente envío habrá comprobar que las nuevas añadidas a la cola no se hayan pasado de tiempo, porque si es así habría que marcarlas como incidencia aún antes de enviarlas ¿no?

Pues "ahímasdao". De forma normal las nuevas que se vayan añadiendo a la cola entrarán en tiempo y si no lo hacen es porque el servidor en la respuesta anterior haya enviado un tiempo para el siguiente envío superior a los 2 minutos. La verdad es que no sé si en caso de pasar del tiempo por instrucciones del servidor habría que enviarlas como incidencia o no. Buena cuestión para preguntar a soporte de Verifactu.


Saludos.

Date cuenta de que cuando se genera una factura esta se envía inmediatamente (vamos, se intenta enviar). Si no hay nada en cola, se envía sóla y no hay problema; si hay más en cola porque todavía no han pasado los 60 segundos desde el último envío, se envía con las demás (dentro del plazo); sólo si las otras que están en cola lo están porque hubo una incidencia, como la incidencia afecta a todo el paquete, esta última añadida se enviará junto con las otras con la marca de incidencia (aunque teóricamente estuviera en plazo)

Gracias newtron.

Creo que la idea es más o menos la misma. Yo decía que genero la factura y la envío pero en realidad lo que hago es ponerla en el paquete para enviar junto con otras posibles (las que puedan estar porque cuando se emitieron no había pasado el tiempo preceptivo de espera). En fin, los envíos se hacen cada X tiempo (por si hubiera alguna en la cola) y también inmediatamente tras la generación (si no ha pasado el tiempo entonces se pone en el paquete de cola). En cualquier caso, con cada envío se procesa todo el paquete.

Yo creo que esto es complicar demasiado el asunto. Me parece que la idea de "incidencia" sólo sirve para tomar en consideración la situación de envío fuera de tiempo. Que un paquete vaya marcado con incidencia servirá para tomar nota de las facturas que vayan fuera de tiempo pero no implica que en ese paquete no vayan facturas a tiempo.

De otra forma, el lío se propaga. Tenemos facturas con incidencia que podemos enviar y a la vez hemos generado algunas dentro de tiempo que no deberían ir con incidencia, pero ¿Hemos de comprobar cada una de las generadas para ver si entran en el paquete de incidencia o no? Vale, lo hacemos así y una queda fuera pero como hemos enviado el paquete con incidencia, hemos de esperar otros 60 segundos, por lo que esa que dejamos fuera, que no enviamos porque no cumplía con los requisitos de incidencia, resulta que cuando la vayamos a enviar ya está fuera de plazo y deberíamos marcar incidencia para ella. Me parece mucha, muchísima complicación añadida a lo complicado que resulta ya tener que controlar el flujo...

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.

Tiempo de espera.
 

Hola, lo de incidencia por tiempo de envio, no lo tengais tan en cuenta para las facturas en un mismo registro de envio, al recibir el paquete, ellos desglosan cada factura y saben por el timestamp cual estaba fuera de tiempo, no diran nada por ello, es mas el tiempo de envio es lo unico que esta exento de subsanacion, lo unico que quieren evitar es que la gente se acostumbre a hacer las facturas y enviarlas cuando se les ocurra, por eso ponen un tiempo, pero realmente no lo tienen en cuenta, es mas desde el principio , al enviar debugeando las facturas he tenido varias facturas con el error 2004, y tras diversas consultaas de mi parte y de otros compañeros, nos confirmaron que no necesita subsanacion.
Otra cosa seria que todos los envios de nuestro SIF, fueran marcados con incidencia, supongo que ahi si tendriamos algun problemilla.
Tened en cuenta que al responder el tiempo de espera, la operativa es:
1-> Esperar t Segundos o.
2-> Reunir 1000 registros.
Lo que se alcance primero.


Desde mi punto de vista, crearia una cola de envio automatizada que cada x segundos(o 1000 registros) ,por ejemplo 100", realizara el envio, si hay algun error* , activo el flag de incidencia y continuo agregando registros, la cola deveria intentar el reenvio automaticamente, en el momento que se hayan enviado todos los registros o el primer elemento a enviar este dentro de la franja de 120", se desactiva automaticamente el flag y se continuan enviando los mismos sin incidencia.


*Aqui habria que tener en cuenta que causo el error , para implementar la solucion y notificar la causa de la incidencia a la aeat, no es lo mismo, que el servidor de ellos no responda, que nosotros no tengamos internet, que se fuera la luz en pleno envio, que conteste duplicado...


Aunque yo no tengo previsto implementar la cola, de momento, puesto que en mi caso , si hoy no puedo hacer factura, perfectamente puedo cobrarle al cliente y enviar a fin de mes la misma, sin problemas.

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í, veo que hay demasiada gente que no entiende el control de flujos y lo interpreta mal
Esto me lleva a la conclusión de que va a ser tal el lío que no temdran mas remedio que abrir la.manoy permitir los envios antes de tiempo entre otras cuesriones. Sii no no van a tener capacidad de absorber esto

Hola, os doy y os quito la razon, :rolleyes:
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.

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 :D:D:D

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

t Segundos de espera.
 

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

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

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)

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".:cool:
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.^\||/

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.

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

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

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.

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.

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?

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

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


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.

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

Pos sii...:rolleyes:

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.

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.

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.

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

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

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.

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?