Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por sglorka

En referencia al tema de clientes acogidos al SII, y la tesitura de aplicar Verifactu o No Verifactu a dichos clientes o al resto de clientes yo tengo una opinión muy clara al respecto.
De ninguna de manera aplicaría No VeriFactu a ningún cliente, esté acogido al SII o no.

Esta recomendación no la hago yo, la hacen los responsables del desarrollo de Verifactu.
Lo han dicho en la conferencia de hace unos meses, lo han desaconsejado en las respuestas a las preguntas formuladas en la Aeat, los gabinetes de asesoramiento para la implantación de Verifactu te dicen que es imposible que puedas cumplir sin estar al filo de la sanción ya que el registro de eventos que han propuesto es indescifrable y por no decir el problemón que puedes tener por perder los registros de facturación de los últimos 4 años, o al menos una parte de ellos por fallo de copia de seguridad, secuestro de datos, etc.

Al cliente que se le ofrece No Verifactu hay que explicarle cuáles son las consecuencias y que como desarrolladores tendría que firmarnos un documento en el que, es la empresa, la que se hace responsable de las copias de seguridad, de tener los certificados al día, etc.

El hecho de estar en el SII te permite una demora de 3 días en remitir los registros de facturación a la Aeat, pero esto no quiere decir que le permitas editar la factura una vez expedida para que la modifique antes de enviarla si detecta un error. Esto está prohibido por el Reglamento de Facturación incluso antes de el desarrollo normativo de Verifactu y estarías incumpliendo el punto 201.bis de la ley. Por lo tanto, si estás acogido al SII te da igual que tu sistema sea Verifactu ya que no podrás modificar la factura expedida. Lo que debes hacer es, en vez de remitirla a Verifactu, la remites al SII. Las compras también se remiten al SII pero Verifactu está fuera de este tema así que no habría que hacer nada.

Esta es mi opinión por si a alguien le vale.

Llevas razón. Pero el que lo desarrolle va a tener una gran oportunidad de negocio, va a haber muchos negocios con problemas de conexión que la mejor opción será no verifactu

[Sistel]

Empezado por ermendalenda

Llevas razón. Pero el que lo desarrolle va a tener una gran oportunidad de negocio, va a haber muchos negocios con problemas de conexión que la mejor opción será no verifactu

Hola,

Eso mismo pensaba yo cuando se puso en marcha TicketBAI en el País Vasco: que muchos pequeños comercios no podrían cumplir por no tener conexión a Internet.

Ahora, casi 2 años después y dando servicio a más de 300 negocios (en su mayor parte TPVs de bazares, pequeños comercios y bares), no hemos tenido ni un solo caso donde no pudiesen cumplir por falta de conexión.
Los que no tienen contratado Internet por ADSL, cable o fibra, funcionan perfectamente con routers 4G con SIM de tarifas de datos baratas.

Ejemplo de router 4G barato: https://www.amazon.es/TP-Link-MR100-.../dp/B085PFRFKX
Y tarifas de datos baratas de operadoras móviles:
- Simyo 4GB de datos mensuales sin llamadas: 2€ al mes (https://www.simyo.es/?homeNav=mobile)
- Digi tarifa Mini de 3GB de datos mensuales: 3€ al mes (https://www.digimobil.es/movil/)

Incluso para los que sí tienen conexión permanente a Internet por ADSL, cable o fibra, siempre recomendamos tener uno de estos routers 4G (con SIM de tarifa de datos económica) configurado como backup: si se les cae su conexión fija de Internet, su tráfico sigue saliendo, sin problemas por 4G.

Saludos

[sglorka]

Empezado por Sistel

Hola,

Eso mismo pensaba yo cuando se puso en marcha TicketBAI en el País Vasco: que muchos pequeños comercios no podrían cumplir por no tener conexión a Internet.

Ahora, casi 2 años después y dando servicio a más de 300 negocios (en su mayor parte TPVs de bazares, pequeños comercios y bares), no hemos tenido ni un solo caso donde no pudiesen cumplir por falta de conexión.
Los que no tienen contratado Internet por ADSL, cable o fibra, funcionan perfectamente con routers 4G con SIM de tarifas de datos baratas.

Ejemplo de router 4G barato: https://www.amazon.es/TP-Link-MR100-.../dp/B085PFRFKX
Y tarifas de datos baratas de operadoras móviles:
- Simyo 4GB de datos mensuales sin llamadas: 2€ al mes (https://www.simyo.es/?homeNav=mobile)
- Digi tarifa Mini de 3GB de datos mensuales: 3€ al mes (https://www.digimobil.es/movil/)

Incluso para los que sí tienen conexión permanente a Internet por ADSL, cable o fibra, siempre recomendamos tener uno de estos routers 4G (con SIM de tarifa de datos económica) configurado como backup: si se les cae su conexión fija de Internet, su tráfico sigue saliendo, sin problemas por 4G.

Saludos

Buen aporte. Gracias

[CarlosR]

Empezado por ermendalenda

Llevas razón. Pero el que lo desarrolle va a tener una gran oportunidad de negocio, va a haber muchos negocios con problemas de conexión que la mejor opción será no verifactu

En mi opinión NO veri*factu se aplicará en el ámbito de la gran empresa. No hay que olvidar que el webservice de la AEAT sólo permitirá 1000 registros por hora. 24000 registros día son totalmente insuficientes para las grandes firmas.
Sigo creyendo que hay oportunidad de negocio también para las pymes con el NO veri*factu. Pero hay que hilar muy fino puesto que si el fabricante es responsable puede verse inmerso en una infracción si incumple alguno de los requisitos. Y tengo dudas de hasta donde es responsable el cliente aunque te firme un documento que le obligue a asumir las responsabilidades del modelo NO veri*factu.

Particularmente intentaré cumplir con los dos requisitos tanto veri*factu como NO veri*factu hasta el día que se requiera tener el software listo. Ahí lo decidiré y si no veo claro el tema NO veri*factu entonces me quedaré solo con el veri*factu.


Saludos.

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

Empezado por CarlosR

En mi opinión NO veri*factu se aplicará en el ámbito de la gran empresa. No hay que olvidar que el webservice de la AEAT sólo permitirá 1000 registros por hora. 24000 registros día son totalmente insuficientes para las grandes firmas.

Tal vez me he perdido algo, pero esta información dónde aparece.
Se me ha escapado esto: sólo permitirá 1000 registros por hora

En este documento hay algo, pero habla de valores máximos.

Los valores máximos de estos parámetros podrán ser:

- n = 1.000 registros de facturación
- t = 120 minutos de espera entre envíos
<sfR:ControlFlujoEnvios>
<sf:MinimoRegistrosEnvio>1000</sf:MinimoRegistrosEnvio>
<sf:MinutosEsperaEnvio>120</sf:MinutosEsperaEnvio>
</sfR:ControlFlujoEnvios>

[CarlosR]

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

Tal vez me he perdido algo, pero esta información dónde aparece.
Se me ha escapado esto: sólo permitirá 1000 registros por hora

En este documento hay algo, pero habla de valores máximos.

Los valores máximos de estos parámetros podrán ser:

- n = 1.000 registros de facturación
- t = 120 minutos de espera entre envíos
<sfR:ControlFlujoEnvios>
<sf:MinimoRegistrosEnvio>1000</sf:MinimoRegistrosEnvio>
<sf:MinutosEsperaEnvio>120</sf:MinutosEsperaEnvio>
</sfR:ControlFlujoEnvios>

¿ Son 120 minutos entre envíos ? Tenía en mente que eran cada 60 minutos. No me había fijado en ese parámetro. Debí dejarlo pendiente en el código hasta que la AEAT pusiera en producción el webservice para verificar a partir de ahí. Lo revisaré.

Pues peor aún. Entonces serían 12000 registros día, ¿ no ?
Podrás enviar cada 2 horas paquetes de 1000 registros como máximo.

No veo a las operadoras de telefonía, gasísticas, eléctricas ni a las grandes superficies usar veri*factu.

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

Empezado por CarlosR

¿Son 120 minutos entre envíos ? Tenía en mente que eran cada 60 minutos. No me había fijado en ese parámetro. Debí dejarlo pendiente en el código hasta que la AEAT pusiera en producción el webservice para verificar a partir de ahí. Lo revisaré.
Pues peor aún. Entonces serían 12000 registros día, ¿ no ?
Podrás enviar cada 2 horas paquetes de 1000 registros como máximo.
No veo a las operadoras de telefonía, gasísticas, eléctricas ni a las grandes superficies usar veri*factu.

Creo que lo estás leyendo mal.
120 min. es un valor máximo. Pero puede ser 1 min.

Además la documentación dice:
"El sistema informático deberá esperar a tener acumulados n registros de facturación o a que transcurran t minutos desde el anterior envío, lo que ocurra primero."


O lo uno o lo otro, lo que ocurra primero.

[CarlosR]

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

Creo que lo está leyendo mal.
120 min. es un valor máximo. Pero puede ser 1 min.

Además la documentación dice:
"El sistema informático deberá esperar a tener acumulados n registros de facturación o a que transcurran t minutos desde el anterior envío, lo que ocurra primero."


O lo uno o lo otro, lo que ocurra primero.

Acabo de revisar el PDF de la AEAT ubicado en este url :
https://www.agenciatributaria.es/sta...ervicioWeb.pdf


En la página 23 habla de eso. No había entendido eso así como me lo expone. Pero podría ser, sí.
Gracias de nuevo por la aclaración.

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

Empezado por CarlosR

Acabo de revisar el PDF de la AEAT ubicado en este url :
https://www.agenciatributaria.es/sta...ervicioWeb.pdf

En la página 23 habla de eso. No había entendido eso así como me lo expone. Pero podría ser, sí.
Gracias de nuevo por la aclaración.

Te dice textualmente:
"En el caso habitual de parámetros (1,0), el sistema informático enviará los registros de facturación individualmente y sin tener en cuenta
tiempos de espera entre envíos."


Entiendo que esto de los parámetros, es para poder de forma dinámica balancear la carga en casos muy especiales.
Si en un momento dado tienen mucha carga, empezarán a enviar tiempos de espera más altos (y número de registros), para tener más tiempo de proceso. Eso minimiza peticiones a los servidores.

[Sistel]

Empezado por CarlosR

En mi opinión NO veri*factu se aplicará en el ámbito de la gran empresa. No hay que olvidar que el webservice de la AEAT sólo permitirá 1000 registros por hora. 24000 registros día son totalmente insuficientes para las grandes firmas.
Sigo creyendo que hay oportunidad de negocio también para las pymes con el NO veri*factu. Pero hay que hilar muy fino puesto que si el fabricante es responsable puede verse inmerso en una infracción si incumple alguno de los requisitos. Y tengo dudas de hasta donde es responsable el cliente aunque te firme un documento que le obligue a asumir las responsabilidades del modelo NO veri*factu.

Particularmente intentaré cumplir con los dos requisitos tanto veri*factu como NO veri*factu hasta el día que se requiera tener el software listo. Ahí lo decidiré y si no veo claro el tema NO veri*factu entonces me quedaré solo con el veri*factu.

Hola,

Yo ni loco le voy a poner un sistema No-Veri*Factu a algún cliente.
Hacienda recomienda usar Veri*Factu para librarse de posibles sanciones.
(Y las recomendaciones de Hacienda siempre hay que tomarlas como amenazas veladas)
Y si ponen algunos límites al número de facturas, ya darán una solución.

Saludos

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

Empezado por Sistel

Yo ni loco le voy a poner un sistema No-Veri*Factu a algún cliente.
Hacienda recomienda usar Veri*Factu para librarse de posibles sanciones.

Varias veces ya se ha comentado que ellos mismos recomiendan VERI*FACTU.
Personalmente no veo razones (a día de hoy) para implementar NO-VERI*FACTU (al final con este sistema también hay que implementar envío, para cuando hacienda lo solicite), así que no le veo ventajas.