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.

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

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

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

[ermendalenda]

Empezado por novatico

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

Nos va a llegar la complementaria a unos cuantos
Esta semana les doy descanso.

[CarlosArjonomia]

Empezado por ermendalenda

Nos va a llegar la complementaria a unos cuantos
Esta semana les doy descanso.

El trabajo que les estamos haciendo como beta testers no tiene precio.

[bmfranky]

Empezado por CarlosArjonomia

El trabajo que les estamos haciendo como beta testers no tiene precio.

La verdad es que no lo entiendo, nos dan 9 meses para crear los programas pero tecnicamente 0 para depurarlos, porque segun pone en los faq, si detectan que hay algun programa en produccon, usando el portal de desarrollo lo banearan, cuando deveriamos tener , los que teneis empresas variadas, mas de uno en produccion para ver por donde rompen, sino os digo que entre el 1 de julio y el 31 habra 300 versiones delmismo programa o mas...

¿Para qué se puede utilizar este entorno de PREPRODUCCIÓN?
Estos sitios web están destinados a ofrecer exclusivamente pruebas en un entorno de PREPRODUCCIÓN para facilitar la integración y validación de servicios que la Agencia Tributaria determine publicar en este entorno y se haya autorizado para que se puedan usar para realizar las pruebas. Estos servicios solo permitirán realizar pruebas de modelos y consultar los presentado en las mismas condiciones que los servicios en Preproducción.
Se recuerda que este entorno solo se debe utilizar para realizar este tipo de pruebas puntuales y en ningún caso para realizar pruebas masivas, validaciones integradas en procesos de presentación en producción, etc. Si se detectan usos que se consideren abusivos se podrán adoptar medidas para bloquear el acceso.

La verdad es una put**a,con lo bien que funciona un betatester en produccion, para corregir fallos.

[CarlosArjonomia]

Empezado por bmfranky

La verdad es que no lo entiendo, nos dan 9 meses para crear los programas pero tecnicamente 0 para depurarlos, porque segun pone en los faq, si detectan que hay algun programa en produccon, usando el portal de desarrollo lo banearan, cuando deveriamos tener , los que teneis empresas variadas, mas de uno en produccion para ver por donde rompen, sino os digo que entre el 1 de julio y el 31 habra 300 versiones delmismo programa o mas...

La verdad es una put**a,con lo bien que funciona un betatester en produccion, para corregir fallos.

Yo he decidido hacer un emulador del servicio en mi propio servidor. Haciendo una simulación a la petición a al AEAT con la mayoría de respuestas de correcto y errores. Ponerlo en producción a mis usuarios cuando tenga algo consistente y conforme lo voy desarrollando para simulando distintas respuestas hacer diferentes acciones. Una vez lo quiera poner en producción para la AEAT cambio la llamada simulada por la real y a rezar.

Edito para decir que mi software es muy simple, solo emite tickets. Alta, anulación, subsanación y muy esporádico alguna rectificativa.

[[newtron]]

Empezado por CarlosArjonomia

Yo he decidido hacer un emulador del servicio en mi propio servidor. Haciendo una simulación a la petición a al AEAT con la mayoría de respuestas de correcto y errores. Ponerlo en producción a mis usuarios cuando tenga algo consistente y conforme lo voy desarrollando para simulando distintas respuestas hacer diferentes acciones. Una vez lo quiera poner en producción para la AEAT cambio la llamada simulada por la real y a rezar.

Edito para decir que mi software es muy simple, solo emite tickets. Alta, anulación, subsanación y muy esporádico alguna rectificativa.

Igualmente esa es mi idea. Yo ya tengo estas opciones en el programa:


<<---- VERIFACTU ---->>


1-No activo (Para que no haga absolutamente nada sobre VeriFactu)

2-Sistema VeriFactu
3-Pruebas Sistema VeriFactu
4-Sistema NO VeriFactu
5-Pruebas sistema NO VeriFactu


Para que el cliente pueda activarlo en modo de pruebas cualquiera de las opciones VeriFactu/NO VeriFactu y que cuando llegue el día (ahora resulta que comienzan en días distintos según sea sociedad o autónomo) elija con cual quiere trabajar.


Ahora se me plantea el dilema que si, una vez llegado el momento, el cliente sigue usando la opción 1 (no activo) el programa seguirá funcionando como hasta ahora y pienso que igual no deberíamos dejar esa opción porque la aeat puede responsabilizarte de que está usando un programa no actualizado.


¿Ahora cómo le ponemos al niño?


Saludos.

[ermendalenda]

Empezado por newtron

Igualmente esa es mi idea. Yo ya tengo estas opciones en el programa:


<<---- VERIFACTU ---->>


1-No activo (Para que no haga absolutamente nada sobre VeriFactu)

2-Sistema VeriFactu
3-Pruebas Sistema VeriFactu
4-Sistema NO VeriFactu
5-Pruebas sistema NO VeriFactu


Para que el cliente pueda activarlo en modo de pruebas cualquiera de las opciones VeriFactu/NO VeriFactu y que cuando llegue el día (ahora resulta que comienzan en días distintos según sea sociedad o autónomo) elija con cual quiere trabajar.


Ahora se me plantea el dilema que si, una vez llegado el momento, el cliente sigue usando la opción 1 (no activo) el programa seguirá funcionando como hasta ahora y pienso que igual no deberíamos dejar esa opción porque la aeat puede responsabilizarte de que está usando un programa no actualizado.


¿Ahora cómo le ponemos al niño?


Saludos.

Yo le pondría una clave para cada modo y que te soliciten en que modo quieren trabajar, modo SII,, modo verifactu y nodonoverfifactu, y lo pones que se vea bien en que modo trabaja y solicitud por escrito.

[CarlosArjonomia]

Empezado por newtron

Igualmente esa es mi idea. Yo ya tengo estas opciones en el programa:


<<---- VERIFACTU ---->>


1-No activo (Para que no haga absolutamente nada sobre VeriFactu)

2-Sistema VeriFactu
3-Pruebas Sistema VeriFactu
4-Sistema NO VeriFactu
5-Pruebas sistema NO VeriFactu


Para que el cliente pueda activarlo en modo de pruebas cualquiera de las opciones VeriFactu/NO VeriFactu y que cuando llegue el día (ahora resulta que comienzan en días distintos según sea sociedad o autónomo) elija con cual quiere trabajar.


Ahora se me plantea el dilema que si, una vez llegado el momento, el cliente sigue usando la opción 1 (no activo) el programa seguirá funcionando como hasta ahora y pienso que igual no deberíamos dejar esa opción porque la aeat puede responsabilizarte de que está usando un programa no actualizado.


¿Ahora cómo le ponemos al niño?


Saludos.

En la opción 1 todo abierto para que puedan consultar, listar, exportar, estadísticas, etc. Pero la opción de emitir o cobrar facturas desactivada.

[antoine0]

Empezado por CarlosArjonomia

En la opción 1 todo abierto para que puedan consultar, listar, exportar, estadísticas, etc. Pero la opción de emitir o cobrar facturas desactivada.

Me parece una solución muy razonable. Si desactivas la opción de poder generar o modificar una factura después del 1/7/2025, me parece difícil multarte. El reglamento y todo siempre se aplica a la emisión de las facturas, que es la única cosa que se debe restringir.

Es cierto que un tramposo puede cambiar la hora del ordenador para ponerlo en el pasado, pero solo podrá emitir una factura con fecha 30/6/2025 o anterior; y si un cliente se deja engañar en agosto de esta manera, no creo que sea responsabilidad del desarrollador.
Bueno, estoy asumiendo que el programa prohíbe emitir facturas en el futuro, que me parece de cajón.

Luego tienes al hramposo con H de hacker que cambia el código del programa para saltarse el control sobre la fecha. Pero todos sabemos que no se puede cazar todos los liebres.

Y después que hayan ahora dos fechas es un lío. Estoy pensando muy fuertemente en tener dos versiones, una para personas físicas y otra para los demás, entre julio y diciembre de 2025...

[antoine0]

Empezado por newtron

Yo ya tengo estas opciones en el programa:

<<---- VERIFACTU ---->>

1-No activo (Para que no haga absolutamente nada sobre VeriFactu)

2-Sistema VeriFactu
3-Pruebas Sistema VeriFactu
4-Sistema NO VeriFactu
5-Pruebas sistema NO VeriFactu

Para que el cliente pueda activarlo en modo de pruebas cualquiera de las opciones VeriFactu/NO VeriFactu y que cuando llegue el día (ahora resulta que comienzan en días distintos según sea sociedad o autónomo) elija con cual quiere trabajar.

Una pregunta que me hago es poder (o no) volver a la opción 1 una vez se ha pasado a la opción 2 o 4. Tengo la sensación que no se debe permitir, de la misma manera que no se debe permitir pasar de la opción 2 a la 4 (o al SII) antes del 31 de diciembre si hay al menos una factura registrada en el año en curso. Pero imagino que hay casos (como un autónomo que se traslada al País Vasco o a Andorra) que pueden justificarse...