Tiempos de envios

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

[novatico]

Empezado por ermendalenda

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

¿ Y si lo combinas con esta otra pregunta respondida ?

¿A qué nivel se debe realizar la trazabilidad exigida en el reglamento y la orden «de requisitos de los sistemas informáticos de facturación (SIF)»: obligado tributario (OT), tienda, terminal punto de venta (TPV)…?

Los registros de facturación (RF) se deben encadenar de forma independiente dentro de cada SIF, y para cada OT (en el caso de que el SIF gestione la facturación de varios OT). Es decir, debe existir una única cadena de RF por cada par de valores distintos de (SIF; OT).
Por lo tanto, la respuesta a esta pregunta dependerá de cómo tenga organizado cada OT su forma de facturar y del número de OT cuya facturación se gestione en cada SIF empleado.
En relación con lo 1º (la organización de la forma de facturar por parte del OT), por ejemplo, si un OT dispone de varios TPV (en uno o diversos centros de venta, o tiendas) que expiden o gestionan la expedición de sus propias facturas de forma independiente a las del resto de TPV, cada TPV se considera que es un SIF, de acuerdo a la definición dada en el reglamento, así que deberá poseer su propia cadena de RF. De esta manera, el OT tendrá tantas cadenas de RF como TPV tenga.
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.

Me da la impresión que se refieren a envíos independientes, además recuerda que en la cabecera del envío, que es única, van los datos del OT.

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