Tiempos de envios

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

Yo lo he pensado como 2 procesos distintos y en ese caso, lo veo más simple; Tal vez se me está pasando algo.
ACTUALIZO el mensaje para explicarlo mejor (me he dejado algunos detalles)...


PROCESO 1: Genera facturas las firma y las encola (en una tabla de BD)
PROCESO 2: Envía el contenido de la cola con un máximo de 1000 registros.

El PROCESO 2, cada X segundos coge lo que haya en la cola (tabla) y lo envía. El retorno devuelve los N segundos a esperar hasta el próximo envío.
a) Si hubiera más de 1000 registros en cola, se envían los 1000 primeros y X se coloca a 0 sg (no hace falta esperar para realizar el siguiente envío).
b) Si hubiera menos de 1000 registros, se envían y a X se le asigna el valor N (y es el tiempo a esperar hasta el próximo envío).

En nuestro caso tenemos N terminales que facturas y el envío es un servicio que se conecta directamente a la BD.

[rci]

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

Yo lo he pensado como 2 procesos distintos y en ese caso, lo veo más simple; Tal vez se me está pasando algo.

PROCESO 1: Genera facturas las firma y las encola (en una tabla de BD)
PROCESO 2: Envía el contenido de la cola.


El PROCESO 2, cada X segundos coge lo que haya en la cola (tabla) y lo envía. El retorno devuelve los N segundos a esperar hasta el próximo envío.
a) Si hubiera más de 1000 registros en cola, X se coloca a 0 sg (no hace falta esperar).
b) Si hubiera menos de 1000 registros, a X se le asigna el valor N (y es el tiempo a esperar hasta el próximo envío).

En nuestro caso tenemos N terminales que facturas y el envío es un servicio que se conecta directamente a la BD.

Nuestra idea inicial era hacerlo tal como indicas Neftali, todo igual excepto que pensábamos siempre enviar solo una factura.
Viendo los comentarios ... puede que tengamos que replantear lo de enviar un paquete de facturas. Algunos de nuestros clientes pueden hacer muchas facturas a lo largo del día y si entre envíos tenemos que esperar ...

Gracias

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

Empezado por rci

Nuestra idea inicial era hacerlo tal como indicas Neftali, todo igual excepto que pensábamos siempre enviar solo una factura.
Viendo los comentarios ... puede que tengamos que replantear lo de enviar un paquete de facturas. Algunos de nuestros clientes pueden hacer muchas facturas a lo largo del día y si entre envíos tenemos que esperar ...

Si por lo que fuera, hacen varias facturas muy seguidas (nosotros tenemos procesos masivos de facturación) podrías tener problemas enviando de 1 en 1.

[antoine0]

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

Yo lo he pensado como 2 procesos distintos y en ese caso, lo veo más simple; Tal vez se me está pasando algo.

PROCESO 1: Genera facturas las firma y las encola (en una tabla de BD)
PROCESO 2: Envía el contenido de la cola.

El PROCESO 2, cada X segundos coge lo que haya en la cola (tabla) y lo envía. El retorno devuelve los N segundos a esperar hasta el próximo envío.
a) Si hubiera más de 1000 registros en cola, X se coloca a 0 sg (no hace falta esperar).
b) Si hubiera menos de 1000 registros, a X se le asigna el valor N (y es el tiempo a esperar hasta el próximo envío).

Primera (pequeña) nota, el PROCESO 2 solo envía los primeros 1000 registros de la cola, no todos. Pero esto ya lo sabes.

Después veo otra tema lógico: si tienes 1999 registros en la cola, los primeros 1000 saldrán de seguida, pero los demás 999, más todos los demás que vendrán en el intervalo, van a tardar la totalidad de las N segundos.
Es un poco ineficiente. Pero ¿podría resultar un problema?
Depende del ritmo de llegada de los documentos, que puede ser más o menos regular. Pero como no tengo experiencia de un sistema que puede verse desbordado por el limite ese de los 1000, no consigo evaluar el tamaño de los problemas. Solo veo que los extremos no son casos con problema: un ritmo regular (x documento por minuto, fijo) no debe rellenar la cola con 1999 registros (N=180 s ⇒ x=666⅓ más de 11/s); por otro lado un ritmo completamente irregular, después de poner 1999 registros en cola, o 2999 o 3999, se va a parar para un rato muy superior a N segundos, por tanto no hay problema tampoco.

[ermendalenda]

Empezado por antoine0

Primera (pequeña) nota, el PROCESO 2 solo envía los primeros 1000 registros de la cola, no todos. Pero esto ya lo sabes.

Después veo otra tema lógico: si tienes 1999 registros en la cola, los primeros 1000 saldrán de seguida, pero los demás 999, más todos los demás que vendrán en el intervalo, van a tardar la totalidad de las N segundos.
Es un poco ineficiente. Pero ¿podría resultar un problema?
Depende del ritmo de llegada de los documentos, que puede ser más o menos regular. Pero como no tengo experiencia de un sistema que puede verse desbordado por el limite ese de los 1000, no consigo evaluar el tamaño de los problemas. Solo veo que los extremos no son casos con problema: un ritmo regular (x documento por minuto, fijo) no debe rellenar la cola con 1999 registros (N=180 s ⇒ x=666⅓ más de 11/s); por otro lado un ritmo completamente irregular, después de poner 1999 registros en cola, o 2999 o 3999, se va a parar para un rato muy superior a N segundos, por tanto no hay problema tampoco.

Es cierto. No es exactamente como lo has puesto pero te he cogido la idea creo.
Pongamos una empresa que manda todo a un servidor central (el corte inglés por ejemplo), en ocasiones le puede pasar que por ejemplo genere 1500 registros envía 1000 se le queden 500 por enviar y al esperar los 60 segundos o el tiempo que le pongam (Si NO HA VUELTO A LLEGAR A LOS 1000 REGISTROS) lo más probable es que algunos registros de esos primeros 500 del FIFO van a llegar tarde y CHAN error 2004
Se quejaran y tendrán que mejorar y repensar el control de flujos. Supongo que si mandas 1000 devolverán 0 o 1 en [t] es la forma de corregir el problema.

[CarlosArjonomia]

Empezado por ermendalenda

Es cierto. No es exactamente como lo has puesto pero te he cogido la idea creo.
Pongamos una empresa que manda todo a un servidor central (el corte inglés por ejemplo), en ocasiones le puede pasar que por ejemplo genere 1500 registros envía 1000 se le queden 500 por enviar y al esperar los 60 segundos o el tiempo que le pongam (Si NO HA VUELTO A LLEGAR A LOS 1000 REGISTROS) lo más probable es que algunos registros de esos primeros 500 del FIFO van a llegar tarde y CHAN error 2004
Se quejaran y tendrán que mejorar y repensar el control de flujos. Supongo que si mandas 1000 devolverán 0 o 1 en [t] es la forma de corregir el problema.

Una empresa que genere mas de 1000 tickets por minuto seguramente estará acogida al SII, difícilmente entre en verifactu.

[bmfranky]

Empezado por CarlosArjonomia

Una empresa que genere mas de 1000 tickets por minuto seguramente estará acogida al SII, difícilmente entre en verifactu.

Seguramente, pero un detalle.

c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o
deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío,
la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva
actualización del valor del parámetro «t».
Ejemplo de respuesta con el parámetro de tiempo de espera de 60 segundos entre envíos:
<sf:TiempoEsperaEnvio>60</sf:TiempoEsperaEnvio>

Segun esto, al llegar a los 1000 registros hay que enviar si o si, sin esperar el tiempo.
Nadie de los que realizais envios masivos, ha hecho la consulta?
Aparte que los que seguramente lleguen a esa cifra, seran los que realicen envios por 3ºs , se me ocurre por ejemplo una, gestoria que c entralice los envios de facturas de sus clientes.

[ermendalenda]

Empezado por CarlosArjonomia

Una empresa que genere mas de 1000 tickets por minuto seguramente estará acogida al SII, difícilmente entre en verifactu.

Todavía no está claro que un grupo de empresas o una asesoría, o un intermediario.. no pueda enviar como tercero a todas las del grupo,en un lote, ya se sabe?

[CarlosArjonomia]

Si tengo un paquete que no se ha podido enviar en tiempo por algún motivo técnico. Falta de luz, internet, fallo de ordenador.

Cuando envió el xml pendiente tengo que marcar incidencia en S en ese xml y seguir con normalidad supongo. La incidencia es S o N, no se indica texto descriptivo de la misma.

[novatico]

Empezado por ermendalenda

Todavía no está claro que un grupo de empresas o una asesoría, o un intermediario.. no pueda enviar como tercero a todas las del grupo,en un lote, ya se sabe?

Del documento de Preguntas Frecuentes:

En relación con lo 2º (número de OT gestionados por el SIF), si un SIF permite la gestión de la facturación de varios OT (como puede ser el caso de un SIF utilizado por una gestoría para llevar en él la facturación de varios OT que son clientes de esa gestoría), dicho SIF deberá tener una cadena independiente por cada OT cuya facturación gestione.


Yo creo que esto supone envíos independientes.

[ermendalenda]

Empezado por novatico

Del documento de Preguntas Frecuentes:

En relación con lo 2º (número de OT gestionados por el SIF), si un SIF permite la gestión de la facturación de varios OT (como puede ser el caso de un SIF utilizado por una gestoría para llevar en él la facturación de varios OT que son clientes de esa gestoría), dicho SIF deberá tener una cadena independiente por cada OT cuya facturación gestione.


Yo creo que esto supone envíos independientes.

Bueno, realmente la cadena de emvios(encadenamiento) puede ser independiente a que se envíe en el mismo paquete(soap)

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

Empezado por CarlosArjonomia

Una empresa que genere mas de 1000 tickets por minuto seguramente estará acogida al SII, difícilmente entre en verifactu.

En esos casos hay que comunicarlo a hacienda (si los volúmenes de la empresa son muy grandes) y hay excepciones. En esos casos para esa empresa se varía el tema de los límites para evitar estos problemas.

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

Empezado por antoine0

Primera (pequeña) nota, el PROCESO 2 solo envía los primeros 1000 registros de la cola, no todos. Pero esto ya lo sabes.

Corrijo el original, aunque lo tengo en la cabeza, no me he explicado bien.

El PROCESO 2 envía lo que hay en la cola con el límite de paquetes de 1000. Y diría que si envía 1000, no hay que esperar para enviar el resto. Es decir, al enviar paquetes de 1000, la restricción de tiempo para enviar el siguiente paquete desaparece (justo para evitar esto).
Por otro lado, empresas que envían un volumen muy grande pueden solicitar que los límites de tiempo (sólo para ellos) no afecten, justo para estos temas. Pero son excepciones que se han de solicitar a la AEAT.