Tiempos de envios

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

[ermendalenda]

Ahi tampoco veo relacion de envio con encadenamientos.
Si estas generando los registros y lo envias a una central para que lo gestione (Por ejemplo como tercero) la pregunta es como puede enviar dichos registros ese tercero.
Por que para el tercero se le puede complicar como tenga que crear muchas hileras de envios.
Entonces el tercero, tiene que enviar un soap por cada obligado?, por que está claro que agrupar por obligados es lo mínimo, no creo que haya que hacer un soap por cada SIF.
Si tienes una empresa dedicada a dar el servicio de envio como tercero y tienes muchos clientes, crear multiples tareas para enviar los soaps y controlar los tiempos de cada uno no lo veo muy sensato.
Yo se que ya han hecho la pregunta de que se puede enviar varios sifs del mismo obligado en el mismo soap, la duda es si al enviar como tercero tiene el mismo tratamiento. Como no es un tema que me afecte, tampoco voy a preguntar, ya bastante les pregunto

[novatico]

Empezado por ermendalenda

Ahi tampoco veo relacion de envio con encadenamientos.
Si estas generando los registros y lo envias a una central para que lo gestione (Por ejemplo como tercero) la pregunta es como puede enviar dichos registros ese tercero.
Por que para el tercero se le puede complicar como tenga que crear muchas hileras de envios.
Entonces el tercero, tiene que enviar un soap por cada obligado?, por que está claro que agrupar por obligados es lo mínimo, no creo que haya que hacer un soap por cada SIF.
Si tienes una empresa dedicada a dar el servicio de envio como tercero y tienes muchos clientes, crear multiples tareas para enviar los soaps y controlar los tiempos de cada uno no lo veo muy sensato.
Yo se que ya han hecho la pregunta de que se puede enviar varios sifs del mismo obligado en el mismo soap, la duda es si al enviar como tercero tiene el mismo tratamiento. Como no es un tema que me afecte, tampoco voy a preguntar, ya bastante les pregunto

Te entiendo, a mí, tras enviar una consulta, me han llegado a llamar por teléfono para comentarla y resolverla, y aunque me dijeron que la respuesta también me la mandarían por escrito, no ha sido así. Por eso no la he publicado. Creo que también se han hartado de mí.

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