Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[Sistel]

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

Una puntualización a lo que dice [sistel] y podemos comentarlo si estoy equivocado.
Como bien dice, los tickets se tratan a nivel Individual, cada uno con su QR y su registro de facturación, pero el envío puede ser agrupado (o eso creo yo). Es decir, puedes hacer un envío de n Registros de facturación juntos.
Es más, hay que tener el sistema previsto para hacerlo así, porque la AEAT tiene previsto que en momentos de saturación, te puedan obligar a esperar "t" segundos o que el envio tenga como mínimo "n" registros.
...

Hola,

Efectivamente los envíos deben hacerse respetando el control de flujo que marque Verifactu.
Creo que dicho control de flujo ya no tendrá en cuenta el envío de un número mínimo de facturas en bloque, sino sólo el tiempo.
En caso contrario, se podría dar el caso de que se quedase esperando un número mínimo de facturas que puede ser que no se alcance en muchos días (o meses)

Si al final es así, sólo control de tiempo, aunque se permita el envío por bloque de facturas, mi opinión es que, si no es obligatoria dicha agrupación en bloque para su envío, es preferible enviar una a una para tener mejor control por nuestra parte.

En TicketBAI-BATUZ también se permite la agrupación de facturas en un envío.
Pero nosotros los enviamos individualmente, lo que nos permite un mejor control.

Saludos

[[newtron]]

Empezado por Sistel

Hola,

Efectivamente los envíos deben hacerse respetando el control de flujo que marque Verifactu.
Creo que dicho control de flujo ya no tendrá en cuenta el envío de un número mínimo de facturas en bloque, sino sólo el tiempo.
En caso contrario, se podría dar el caso de que se quedase esperando un número mínimo de facturas que puede ser que no se alcance en muchos días (o meses)

Si al final es así, sólo control de tiempo, aunque se permita el envío por bloque de facturas, mi opinión es que, si no es obligatoria dicha agrupación en bloque para su envío, es preferible enviar una a una para tener mejor control por nuestra parte.

En TicketBAI-BATUZ también se permite la agrupación de facturas en un envío.
Pero nosotros los enviamos individualmente, lo que nos permite un mejor control.

Saludos

Por lo que yo entiendo el control del número de facturas a enviar creo que será un número máximo, no mínimo. Es decir, que si te devuelve un valor 10 en el número de facturas y tienes solo 3 para enviar podrías enviar esas 3, lo que no deberías de enviar serían 13. En el caso de tener 13 para enviar se deberían de enviar esas 10 máximas y en la respuesta te dirá cómo puede enviar las posibles restantes que pudieras tener pendientes.


Saludos.

[sglorka]

Empezado por newtron

Por lo que yo entiendo el control del número de facturas a enviar creo que será un número máximo, no mínimo. Es decir, que si te devuelve un valor 10 en el número de facturas y tienes solo 3 para enviar podrías enviar esas 3, lo que no deberías de enviar serían 13. En el caso de tener 13 para enviar se deberían de enviar esas 10 máximas y en la respuesta te dirá cómo puede enviar las posibles restantes que pudieras tener pendientes.


Saludos.

El control de flujo se hará sólo con un parámetro "t" en segundos. El número de ítems a enviar ya está limitado por diseño (1000 registros). Esto lo aclararon en la presentación de principio de año.

Artículo 16. Especificaciones técnicas de la remisión voluntaria

Control de flujo de remisión de registros para los sistemas Veri*factu.

• Muy probablemente simplificará para contemplar solo un factor de tiempo. El máximo de registros a remitir por envío ya está limitado a 1.000 registros (limitado por Diseño de Registro).
• El parámetro no variaría con frecuencia. Una vez definido será estable. No se pretende complicar la implementación de los SIF.
• El tiempo máximo entre envíos se fijará tomando como unidad “segundos”. El valor del parámetro no está pensado para contemplar horas ni días.
• Ejemplo: Valor t=60. El SIF deberá remitir todos los registros de facturación generados en el último minuto.
• El control de flujo no tendrá aplicación “práctica” para empresas con escasos volúmenes de facturación, ya que no superarán el umbral definido.

[[newtron]]

Empezado por sglorka

El control de flujo se hará sólo con un parámetro "t" en segundos. El número de ítems a enviar ya está limitado por diseño (1000 registros). Esto lo aclararon en la presentación de principio de año.

Artículo 16. Especificaciones técnicas de la remisión voluntaria

Control de flujo de remisión de registros para los sistemas Veri*factu.

• Muy probablemente simplificará para contemplar solo un factor de tiempo. El máximo de registros a remitir por envío ya está limitado a 1.000 registros (limitado por Diseño de Registro).
• El parámetro no variaría con frecuencia. Una vez definido será estable. No se pretende complicar la implementación de los SIF.
• El tiempo máximo entre envíos se fijará tomando como unidad “segundos”. El valor del parámetro no está pensado para contemplar horas ni días.
• Ejemplo: Valor t=60. El SIF deberá remitir todos los registros de facturación generados en el último minuto.
• El control de flujo no tendrá aplicación “práctica” para empresas con escasos volúmenes de facturación, ya que no superarán el umbral definido.

Gracias por la aclaración.

[xamminf]

Empezado por Sistel

Hola,

Efectivamente los envíos deben hacerse respetando el control de flujo que marque Verifactu.
Creo que dicho control de flujo ya no tendrá en cuenta el envío de un número mínimo de facturas en bloque, sino sólo el tiempo.
En caso contrario, se podría dar el caso de que se quedase esperando un número mínimo de facturas que puede ser que no se alcance en muchos días (o meses)

Si al final es así, sólo control de tiempo, aunque se permita el envío por bloque de facturas, mi opinión es que, si no es obligatoria dicha agrupación en bloque para su envío, es preferible enviar una a una para tener mejor control por nuestra parte.

En TicketBAI-BATUZ también se permite la agrupación de facturas en un envío.
Pero nosotros los enviamos individualmente, lo que nos permite un mejor control.

Saludos

Hola Sistel,

¿ Por qué mejor control ?
Existiendo la limitación del flujo, me pareciera a mi que el envio en bloques va a ser, en la practica, obligatorio. Si t=10, no podemos esperar 10 segundos para enviar una factura despues de otra.
Bloques en este caso me parecen necesario y luego parsear la respuesta que será también un bloque de respuestas.

[Sistel]

Empezado por xamminf

Hola Sistel,
¿ Por qué mejor control ?
Existiendo la limitación del flujo, me pareciera a mi que el envio en bloques va a ser, en la practica, obligatorio. Si t=10, no podemos esperar 10 segundos para enviar una factura despues de otra.
Bloques en este caso me parecen necesario y luego parsear la respuesta que será también un bloque de respuestas.

Hola,

El problema viene si de un bloque de facturas enviadas unas son aceptadas como correctas, otras no aceptadas y otras aceptadas parcialmente.
Hay que separar cada una de ellas y estudiar cómo tratarlas.

Y si en el bloque había, por ejemplo, una factura normal y otra rectificativa sobre la anterior y la primera no ha sido aceptada y la segunda sí parcial o totalmente.
El lío que se puede montar es descomunal.

Por eso, para mí (siempre que se pueda), una a una y una después de otra.

Saludos