Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por bmfranky

Otra cosa, hasta ahora las cuotas de itv, las incluia a final de factura , sin añadirle iva ni nada, como "Cobrada a nombre de cliente", por no desglosar porque a la cuaota de trafico no se le deve añadir IVA.
Sabeis como lo tendria que incluir ahora en verifactu y en las futuras facturas electronicas?, Gracias como siempre por vuestras respuestas.

Si no estoy equivocada (no conozco nada a las ITVs), estos "cobrado a nombre del cliente" son suplidos. Si es así, no entran en la base imponible de la factura (art. 78. Tres. 3º Ley 37/1992, y de aquí no soportan IVA), y no hay que reportarlos a Hacienda. Pero se supone que se debe entregar al cliente, junto con tu factura, el justificante del pago que has realizado en nombre de tu cliente.

Respecto de las facturas electrónicas, es una muy buena pregunta. Aprovecho que no es el foro adecuado para no contestar

[bmfranky]

Empezado por antoine0

Si no estoy equivocada (no conozco nada a las ITVs), estos "cobrado a nombre del cliente" son suplidos. Si es así, no entran en la base imponible de la factura (art. 78. Tres. 3º Ley 37/1992, y de aquí no soportan IVA), y no hay que reportarlos a Hacienda. Pero se supone que se debe entregar al cliente, junto con tu factura, el justificante del pago que has realizado en nombre de tu cliente.

Respecto de las facturas electrónicas, es una muy buena pregunta. Aprovecho que no es el foro adecuado para no contestar

Si, la copia que te da la itv del pago, va a nombre del cliente siempre, yo no lo incluiria en la factura, pero luego el pago si lo hacen con tarjeta o transferencia no cuadra, por eso lo apunto en la factura, de ahi preguntar como , puesto que como exento de IVA, no creo, o no se que clase de exencion apñlicar.

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

Empezado por rfernandez

La duda es que como hay la obligación de imprimir el código QR para la trazabilidad Verifactu deducimos que cada tíquet, factura simplificada, debe llevar su QR por lo que se deben reportar a Verifactu todas los tiquets, facturas simplificadas, aunque sabemos que no hace falta reportar una a una sino que se pueden reportar en bloque.

Empezado por Sistel

Lo primero que debes tener en cuenta es que cada ticket generado (actualmente los "tickets" se llaman facturas simplificadas) debe ser tratado de forma individual.
Debe incluir su código QR y debe ser enviada su información, de forma inmediata (nada más generarse) al sistema Verifactu de la Agencia Tributaria.

Ya sé que esto romperá tus esquemas pensados para agrupar los tickets de cada día y procesarlos después. Pero es lo que hay.
Cada "ticket" es una factura simplificada individual. Y debe ser tratada de forma inmediata.

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.

Concretamente el esquema de funcionamiento segun la documentación es este:

2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser tenido en cuenta para el siguiente envío.

El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.

El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t» entre envíos.
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»


Es decir, puede decidir enviar registros de forma individual (nosotros lo hacemos así porque nuestras empresas no generan tickets y el volumen ens más pequeño), pero también puedes hacer envíos agrupados de hasta 1000 registros. Y aunque nosotros no lo hagamos, nuestro sistema debe estar preparado par ello.


En este documento lo tienes todo explicado:
https://terawiki.clubdelphi.com/Otro...Web_v0.3.0.pdf

6.3.1.1.Mecanismo de control de flujo.

6.4.2. Respuesta de alta y anulación de registros de facturación.
Todos los registros de facturación de la remisión tienen estado “Correcto”.
Ya asume que puedes enviar N registros en un envío de Alta o Anulación

3.Esquema general de funcionamiento.
...
El número máximo de registros por envío es de 1.000.
La unidad de información, representada por un registro de facturación, podrá ser
aceptada, rechazada o aceptada con errores, consecuencia de las validaciones que se
realizan en el momento de la remisión.

[[newtron]]

Efectivamente. Según se entiende los tickets hay que enviarlos de forma unitaria independientemente que al enviar se envíen por paquetes de n tickets/facturas. Hay que tener cuidado con esto porque en el SII si que hay una manera de enviar en un solo registro un grupo de tickets indicando desde-hasta y los totales pero esto parece que no se aplica en VeriFactu.


Saludos.

[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

[richidemola]

Joder, todavía me acuerdo cuando empezaron a obligar a enviar factura electrónica a la administración, era imposible enviar una factura el día 1 de cada mes, el sistema siempre caido y te la rechazaban, tenías que esperar a enviarla dos o tres días cuando el sistema no estaba tan saturado, ahora con verifactu sacan la mierda esto de tener que esperar x segundos hasta el siguiente envío, a ver lo que aguanta el sistema así, cuando lo que tendría que hacer es mejorar la infraestructura para que no se sature.

[Logan05]

Empezado por richidemola

Joder, todavía me acuerdo cuando empezaron a obligar a enviar factura electrónica a la administración, era imposible enviar una factura el día 1 de cada mes, el sistema siempre caido y te la rechazaban, tenías que esperar a enviarla dos o tres días cuando el sistema no estaba tan saturado, ahora con verifactu sacan la mierda esto de tener que esperar x segundos hasta el siguiente envío, a ver lo que aguanta el sistema así, cuando lo que tendría que hacer es mejorar la infraestructura para que no se sature.

Me gustaría saber cuanto volumen tienen previsto esas lumbreras, porque cuando empecemos todos (casi tres millones de empresas en España) a mandar TODOS los tickets simultáneamente lo van a flipar.

[bmfranky]

Empezado por Logan05

Me gustaría saber cuanto volumen tienen previsto esas lumbreras, porque cuando empecemos todos (casi tres millones de empresas en España) a mandar TODOS los tickets simultáneamente lo van a flipar.

Estableceremos horas punta de facturacion... ;-)

[antoine0]

Empezado por bmfranky

Estableceremos horas punta de facturacion... ;-)

Pídelo a Google, te van a dar un bonito gráfico con colores, diciéndote que es mejor enviar las facturas entre las 03:45 y la 04:00 que está en verde

[xamminf]

Empezado por Logan05

Me gustaría saber cuanto volumen tienen previsto esas lumbreras, porque cuando empecemos todos (casi tres millones de empresas en España) a mandar TODOS los tickets simultáneamente lo van a flipar.

Lo fliparán ellos y las empresas que en muchos casos paralizarán facturación (V.E.N.T.A.S.) por colapso de quien continuamente pone palos en las ruedas del dinamismo económico pidiendo mil y una exigencias

[sglorka]

En respuesta a una consulta que me realizaron, adjunto proceso de rectificación en dos pasos para recuperación de cuotas, Caso 6

https://sede.agenciatributaria.gob.e...023V-FINAL.pdf

Ejemplo 3: Disminución de base imponible por impago
La factura nº3 de base imponible 1.000 € y cuota 210 € va a ser objeto de rectificación por impago, eliminando la totalidad de la cuota repercutida.

Opción 1: La modificación por sustitución supondría emitir una factura rectificativa con base imponible de 1.000 € y cuota 0, en la que se indicará que la rectificación
realizada es de 1000 € por la base imponible rectificada y 210 € por la cuota rectificada.

Los campos y claves a consignar en el Libro registro de Facturas Expedidas son:
Tipo Comunicación: A0
Tipo Factura: R2 / R3
Tipo Rectificativa: S
Importe Rectificación: se informará de dos campos adicionales con “la base
rectificada” 1.000 y la “cuota rectificada” 210..
Importe total: se indicará el importe final válido 1.000.
Desglose IVA: base imponible: 1.000, cuota repercutida 0.

Opción 2: La modificación por sustitución supondría emitir una factura con base imponible de -1000 €, cuota de -210 y una factura rectificativa en la que se indicará que la base imponible es de 1.000 € y la cuota 0€.
En la primera factura los campos y claves a consignar en el Libro registro de Agencia Tributaria Suministro Inmediato de Información (S.I.I.)26
Facturas Expedidas son:
Tipo Comunicación: A0
Tipo Factura: F1
Desglose IVA: se indicará el importe que se rectifica con signo contrario (base
imponible: (-1.000), cuota repercutida (-210).)

En la segunda de las facturas rectificativas los campos y claves a consignar en el
Libro registro de Facturas Expedidas son:
Tipo Comunicación: A0
Tipo Factura: R2 / R3
Tipo Rectificativa: S

Importe Rectificación: se informará de dos campos adicionales con “la base rectificada” 0 y la “cuota rectificada” 0.
Importe total: se indicará el importe final válido 1.000
Desglose IVA: base imponible: 1.000, cuota repercutida 0

[Sistel]

Empezado por richidemola

Joder, todavía me acuerdo cuando empezaron a obligar a enviar factura electrónica a la administración, era imposible enviar una factura el día 1 de cada mes, el sistema siempre caido y te la rechazaban, tenías que esperar a enviarla dos o tres días cuando el sistema no estaba tan saturado, ahora con verifactu sacan la mierda esto de tener que esperar x segundos hasta el siguiente envío, a ver lo que aguanta el sistema así, cuando lo que tendría que hacer es mejorar la infraestructura para que no se sature.

Sí, esperemos que monten una infraestructura de red suficientemente potente.
Actualmente, no debería ser problema, porque hay medios para hacerlo.
De hecho, ya casi todos los países de la UE tienen montado algún sistema equivalente a Verifactu funcionando.

Saludos