Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[sglorka]

Originally Posted by 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]

Originally Posted by 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]]

Originally Posted by 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]

Originally Posted by 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.

[Sistel]

Originally Posted by 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]]

Originally Posted by 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.

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

Originally Posted by 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.

[CarlosR]

Originally Posted by 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]]

Originally Posted by 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.

[edari]

Originally Posted by edari

Gracias por las repuestas.


Voy a intentar a ver si consigo alguna forma para recuperar los datos del cerficado y poder validarlo...

Para mis amigos del símbolo de comando ( ) he conseguido poder consultar las fechas del certificado con el comando certutil

 certutil -dump -p pasword-certificado  nombre-certificado

o

 certutil -v -dump -p pasword-certificado  nombre-certificado

Este último da más información pero yo solo necesito la fecha de fin de vigencia del certificado (NotAfter)


Con esto daré un mensaje de aviso 30 días antes para que lo vaya renovando y sobretodo ni siquiera intentar el subir facturas a Verifactu/Tickebai si ya caducó

[novatico]

Originally Posted by Neftali [Germán.Estévez]

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

Neftalí, yo también había leído ese párrafo, pero no estoy seguro de como entenderlo:
Opción 1: La AEAT responderá habitualmente con los parámetros (1,0), lo que significará que podemos enviar un nuevo registro sin esperar
Opción 2: Mi SIF envía SIEMPRE los registros individualmente, y me puedo desentender del tiempo de espera.

¿ Tú como lo entiendes ?

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

Originally Posted by novatico

Neftalí, yo también había leído ese párrafo, pero no estoy seguro de como entenderlo:
Opción 1: La AEAT responderá habitualmente con los parámetros (1,0), lo que significará que podemos enviar un nuevo registro sin esperar
Opción 2: Mi SIF envía SIEMPRE los registros individualmente, y me puedo desentender del tiempo de espera.

¿ Tú como lo entiendes ?

Yo entiendo el 1.
"La AEAT responderá habitualmente con los parámetros (1,0), lo que significará que podemos enviar un nuevo registro sin esperar"

Eventualmente puede responder con otros parámetros (n,t) y habrá que hacer caso, pero ya indica que no será lo habitual

[novatico]

Originally Posted by Neftali [Germán.Estévez]

Yo entiendo el 1.
"La AEAT responderá habitualmente con los parámetros (1,0), lo que significará que podemos enviar un nuevo registro sin esperar"

Eventualmente puede responder con otros parámetros (n,t) y habrá que hacer caso, pero ya indica que no será lo habitual

Ya me temía yo eso.

Gracias por responder.

[Salma]

Buenas tardes.
Os cuento mi tema por si podéis ayudarme y aconsejarme. Yo tengo un software en la nube sectorial. Es un programa de gestión que a priori cumple la ley antifraude, ya que los clientes no pueden modificar nada, es decir, no pueden borrar facturas, no pueden borrar albaranes, no pueden manipular nada. Todo lo que nosotros hacemos queda debidamente registrado, quien ha hecho tal factura, a que hora, que usuario etc. He leido en algunos sitios que si tu software es así, realmente deberías hacer una declaración responsable diciendo no se puede manipular la facturación y ya está. En otros sitios he leido que hay que acogerse o no al verifactu. mis clientes son autónomos o pequeñas empresas. Hay muy pocos que trabajen con la administración, y lo hacen haciendo las facturas con Facturae.

Me aconsejais qué hacer?. Hay consultorías que me piden una pasta por no se muy bien qué.. No sé si contratar a un cisa, que me certifique la ineltarabilidad y poner en la página del erp que cumple con la ley anrifraude.


EStoy muy pez... si me podéis aconsejar.
mil gracias

[[newtron]]

Originally Posted by Salma

Buenas tardes.
Os cuento mi tema por si podéis ayudarme y aconsejarme. Yo tengo un software en la nube sectorial. Es un programa de gestión que a priori cumple la ley antifraude, ya que los clientes no pueden modificar nada, es decir, no pueden borrar facturas, no pueden borrar albaranes, no pueden manipular nada. Todo lo que nosotros hacemos queda debidamente registrado, quien ha hecho tal factura, a que hora, que usuario etc. He leido en algunos sitios que si tu software es así, realmente deberías hacer una declaración responsable diciendo no se puede manipular la facturación y ya está. En otros sitios he leido que hay que acogerse o no al verifactu. mis clientes son autónomos o pequeñas empresas. Hay muy pocos que trabajen con la administración, y lo hacen haciendo las facturas con Facturae.

Me aconsejais qué hacer?. Hay consultorías que me piden una pasta por no se muy bien qué.. No sé si contratar a un cisa, que me certifique la ineltarabilidad y poner en la página del erp que cumple con la ley anrifraude.

EStoy muy pez... si me podéis aconsejar.
mil gracias

Si me equivoco que alguien me corrija.

No sé si he entendido tu pregunta pero ahora mismo ninguna aplicación cumple la ley antifraude. Lo de no poder modificar facturas es una mínima parte de lo que piden. Y no cumple nadie porque todavía no se ha acabado de desarrollar la ley que, entre otras cosas, pide que las aplicaciones tengan la posibilidad de enviar las facturas a un servidor determinado y con unas normas determinadas que todavía no se han aclarado.



Saludos.

[ermendalenda]

Originally Posted by Salma

Buenas tardes.
Os cuento mi tema por si podéis ayudarme y aconsejarme. Yo tengo un software en la nube sectorial. Es un programa de gestión que a priori cumple la ley antifraude, ya que los clientes no pueden modificar nada, es decir, no pueden borrar facturas, no pueden borrar albaranes, no pueden manipular nada. Todo lo que nosotros hacemos queda debidamente registrado, quien ha hecho tal factura, a que hora, que usuario etc. He leido en algunos sitios que si tu software es así, realmente deberías hacer una declaración responsable diciendo no se puede manipular la facturación y ya está. En otros sitios he leido que hay que acogerse o no al verifactu. mis clientes son autónomos o pequeñas empresas. Hay muy pocos que trabajen con la administración, y lo hacen haciendo las facturas con Facturae.

Me aconsejais qué hacer?. Hay consultorías que me piden una pasta por no se muy bien qué.. No sé si contratar a un cisa, que me certifique la ineltarabilidad y poner en la página del erp que cumple con la ley anrifraude.


EStoy muy pez... si me podéis aconsejar.
mil gracias

No te vale lo que hayas hecho más allá de que al menos ya lo tendrás estructurado para aplicar el desarrollo del reglamento.
Una cosa es el reglamento y otra el desarrollo técnico. Que lo tengas preparado según el reglamento no te vale, tienes que prepararlo según verifactu o no verifactu, a no ser que sean clientes acogidos al SII

[ermendalenda]

Quería decir que una cosa es la ley antifraude y otra el reglamento y el desarrollo técnico del mismo.
Hay que cumplir los 3 parametros.

[ermendalenda]

Madre mía la que se va a liar cuando le den más publicidad a Verifactu. Van a tener que ampliar el plazo hasta el 2028 o se cargan a medio país.

[edari]

Originally Posted by Salma

Buenas tardes.
Os cuento mi tema por si podéis ayudarme y aconsejarme. Yo tengo un software en la nube sectorial. Es un programa de gestión que a priori cumple la ley antifraude, ya que los clientes no pueden modificar nada, es decir, no pueden borrar facturas, no pueden borrar albaranes, no pueden manipular nada. Todo lo que nosotros hacemos queda debidamente registrado, quien ha hecho tal factura, a que hora, que usuario etc. He leido en algunos sitios que si tu software es así, realmente deberías hacer una declaración responsable diciendo no se puede manipular la facturación y ya está. En otros sitios he leido que hay que acogerse o no al verifactu. mis clientes son autónomos o pequeñas empresas. Hay muy pocos que trabajen con la administración, y lo hacen haciendo las facturas con Facturae.

Me aconsejais qué hacer?. Hay consultorías que me piden una pasta por no se muy bien qué.. No sé si contratar a un cisa, que me certifique la ineltarabilidad y poner en la página del erp que cumple con la ley anrifraude.


EStoy muy pez... si me podéis aconsejar.
mil gracias

No sé exactamente qué significa pero tengo entendido que para tener tu programa verifactu en la nube necesitas cumplir unos cuantos requisitos sobre los certificados de los clientes que tienes que almacenar en tu servidor...

[ermendalenda]

Envíos
Por si os sirve os pongo un ejemplo de un posible escenario:
-Envías el primer registro
Te responde que la próxima vez envíes mínimo 10 registros o esperes 500segundos.
Antes de esos 500 segundos no puedes enviar menos de 10 registros en el registro encapsulado, ya que te lo van a rechazar. Tendrías que enviar de 10 a 1000 Ntes de esos 500 segundos,
Te puede pasar que no tengas suficientes registros para cumplir la regla, entonces si te esperas el tiempo (500segundos), puedes enviar un encapsulado de 1 a 1000 registros.con lo cual, si tienes en cuenta lo que te solicitan, no vas a tener problemas en enviar todos los registros , teniendo en cuenta que esto es por SIF, no por empresa.