Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[espinete]

Empezado por newtron

Edito: Pero que yo me entere.... ¿este hilo es de Facturas electrónicas o de Verifactu?

Yo sigo sin entender la diferencia, la verdad.

Facturas electrónicas: facturae, face, sii o incluso un pdf firmado con certificado, si nos ponemos técnicos...
Verifactu: Evolución de la Ley Antifraude: Impresión de QR en ticket/factura + envío a Hacienda (aún sin urls de envío ni entorno de pruebas). Muy similar (presumiblemente) a TicketBAI.

He leído en algunos artículos que he encontrado online (suelen ser blogs de asesorías fiscales o de empresas de software) que Canarias y País Vasco estarán excluidas (entiendo que lo esté País Vasco porque ya tienen TicketBAI, pero Canarias?). Sin embargo no he encontrado nada oficial que indique eso.
También hay un lío de fechas para la entrada en vigor.

Incluso tengo amigos en otras empresas de software que dicen que debe ser la empresa de software de facturación la que suba a un espacio web propio todas las facturas para que los clientes puedan leerlas.

Ya me estoy volviendo medio loco...

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

Empezado por espinete

Verifactu: Evolución de la Ley Antifraude: Impresión de QR en ticket/factura + envío a Hacienda (aún sin urls de envío ni entorno de pruebas). Muy similar (presumiblemente) a TicketBAI.

La LeyAntifraude lo que hace es asegurar que una vez generada la factura se guarda de forma que no se pueda modificar (de ahí los temas de firma, encadenamiento,...).
Inicialmente hay 2 opciones o formas de trabajar para las faturas:

• Veri*Factu OFF, que significa que las faturas NO se envían, las guardarlas tú, hasta que hacienda te las requiera, si es necesario. En este caso te puede solicitar, por ejemplo, "las facturas de 1 mes" y habrá que ver cómo se las tienes que dar.
• Veri*Factu ON, que significa que (de forma similar a como se hace en TBAI) las facturas se deben enviar a hacienda inmediatamente después de generarlas.

Lo normal es que más adelante, la opción 2 (envío inmediato) sea la obligatoria, pero haciendo así, simplificas inicialmente el desarrollo (sepuede hacer en 2 fases), escalas la puesta en marcha (no todos optarán por la opción 2 inicialmente), das más tiempo a las empresas a implementar el segundo (que es más complejo),...

Empezado por espinete

Incluso tengo amigos en otras empresas de software que dicen que debe ser la empresa de software de facturación la que suba a un espacio web propio todas las facturas para que los clientes puedan leerlas.

Que debas almacenarlas tú si, que debas implementar los mecanismos para que el cliente pueda leerlas no lo he leído ni visto en ningún sitio. No tiene sentido. Para eso, activa Veri*factu (es decir, envíaselas a hacienda) y ellos se encargan de eso.

[espinete]

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

Que debas almacenarlas tú si, que debas implementar los mecanismos para que el cliente pueda leerlas no lo he leído ni visto en ningún sitio. No tiene sentido. Para eso, activa Veri*factu (es decir, envíaselas a hacienda) y ellos se encargan de eso.

Disculpa, pero sigo sin entender esta parte. ¿A quién te refieres con que tengo que almacenarlas "yo"? Supongo que te refieres al cliente (usuario del software), no yo como empresa desarrolladora del software.

Perdona, pero entre "cliente", "cliente final" y "nosotros" como empresa de software no entendí bien lo que quieres decir.

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

Empezado por espinete

pero sigo sin entender esta parte. ¿A quién te refieres con que tengo que almacenarlas "yo"? Supongo que te refieres al cliente (usuario del software), no yo como empresa desarrolladora del software.

Perdona, pero entre "cliente", "cliente final" y "nosotros" como empresa de software no entendí bien lo que quieres decir.

Perdón, me refiero al poseedor del software, al cliente.
La empresa desarrolladora no tiene que almacenar facturas de sus clientes. Sólo nos faltaba eso...

[[newtron]]

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

...
Que debas almacenarlas tú si, que debas implementar los mecanismos para que el cliente pueda leerlas no lo he leído ni visto en ningún sitio. No tiene sentido. Para eso, activa Veri*factu (es decir, envíaselas a hacienda) y ellos se encargan de eso.

Si no me equivoco el software tiene que estar preparado para el envío envíes o no precisamente para eso, para que si no envías datos y te requieren información puedas enviarla directamente así que al programa le da igual lo que decidas si enviar o no, siempre tendrá que estar preparado para enviar.

Por otro lado también creo que las empresas que están en el SII están exentas de este rollo del verifactu.

Saludos.

[antoine0]

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

Lo normal es que más adelante, la opción 2 (envío inmediato) sea la obligatoria, pero haciendo así, simplificas inicialmente el desarrollo (sepuede hacer en 2 fases), escalas la puesta en marcha (no todos optarán por la opción 2 inicialmente), das más tiempo a las empresas a implementar el segundo (que es más complejo),...

Lo veo de manera distinta, visto desde una empresa que opera. Creo que las dos opciones están por quedarse tiempo. Las grandes empresas con desarrolladores internos, CPD etc. se van a quedar en opción 1, al mínimo para garantizar el máximo de confidencialidad (caso extremo sería las compañías extranjeras, que puede que no se fíen tanto del Estado español). A no ser que a las pocas años esta opción se esfuma dentro de una opción 0 que no has mencionado: estar acogido al S.I.I., que de lo que hemos leído hasta la fecha ¿permitiría? evitar completamente la obligación de tener un S.I.F. tal como lo define el proyecto de RDL de febrero.

Después de leeros aquí, tengo más certezas que la mayoría de las PyMEs y la mayoría de los desarrolladores independientes van a ir a por la 2ª, que probablemente es también la opción preferida por Hacienda por el momento (a ver cómo quedará cuando la ley evolucionará más rápidamente que la capacidad de respuesta de los desarrolladores de Veri*factu). Concretamente para un desarrollador, me parece más lógico ir directamente por la opción 2. Y no creo que siga más complejo: cierto que hay que gestionar el envío inmediato y luego dibujar e imprimir el QR en casi tiempo real (con las relaciones que implican con el hardware); pero Hacienda está equilibrando las cosas en no reclamar en copión 2 firmar todos los registros en el momento de emitir la factura (también en casi tiempo real, y no sabemos exactamente los requisitos para el sellado de tiempo que va detrás); y creo que el esfuerzo de desarrollo es comparable. Además los que ya han pagado el peaje TBAI llevan cierta ventaja.

[ermendalenda]

Empezado por antoine0

Lo veo de manera distinta, visto desde una empresa que opera. Creo que las dos opciones están por quedarse tiempo. Las grandes empresas con desarrolladores internos, CPD etc. se van a quedar en opción 1, al mínimo para garantizar el máximo de confidencialidad (caso extremo sería las compañías extranjeras, que puede que no se fíen tanto del Estado español). A no ser que a las pocas años esta opción se esfuma dentro de una opción 0 que no has mencionado: estar acogido al S.I.I., que de lo que hemos leído hasta la fecha ¿permitiría? evitar completamente la obligación de tener un S.I.F. tal como lo define el proyecto de RDL de febrero.

Después de leeros aquí, tengo más certezas que la mayoría de las PyMEs y la mayoría de los desarrolladores independientes van a ir a por la 2ª, que probablemente es también la opción preferida por Hacienda por el momento (a ver cómo quedará cuando la ley evolucionará más rápidamente que la capacidad de respuesta de los desarrolladores de Veri*factu). Concretamente para un desarrollador, me parece más lógico ir directamente por la opción 2. Y no creo que siga más complejo: cierto que hay que gestionar el envío inmediato y luego dibujar e imprimir el QR en casi tiempo real (con las relaciones que implican con el hardware); pero Hacienda está equilibrando las cosas en no reclamar en copión 2 firmar todos los registros en el momento de emitir la factura (también en casi tiempo real, y no sabemos exactamente los requisitos para el sellado de tiempo que va detrás); y creo que el esfuerzo de desarrollo es comparable. Además los que ya han pagado el peaje TBAI llevan cierta ventaja.

Correcto, la opción 2 es la más viable para las empor3sas grandes, no veo que de confidencialidad puede haber en enviar las bases e impuestos, de todas formas hay que hacerlo, si no por un lado por otro. Sobre todo en empresas que tengan franquicias, piensa que la central de franquicias quiere el mínimo de problemas en la gestión de datos de sus franquiciados que suelen usar los softwares impuestos por el franquiciador y ante requerimientos posteriores de hacienda por estar acogido a la opción 1 se puede complicar. Con la opción 2 puedes tener complicaciones en el desarrollo pero una vez corregido los bugs te quitas de problemas.
Por otro lado las firmas con certificados(opcion 1) tb tiene la complejidad del mantenimiento de dichos certificados. Y para la opción 2, como lucho te pedirán el certificado para pedir la @clave o para enviar con dicho certificado, q7e si te caduca te devolverá un error y se queda en cola hasta que cambies/renueves el certificado, que xomo he dicho si tienes que firmar con certificado en el instante de emitir el tiquet para hacer el encadenamiento puedes tener un gran problema.

[antoine0]

Empezado por espinete

Incluso tengo amigos en otras empresas de software que dicen que debe ser la empresa de software de facturación la que suba a un espacio web propio todas las facturas para que los clientes puedan leerlas.

Aquí si creo que tus amigos se han equivocado de hilo. Lo de subir las facturas a algún espacio web privado tiene sentido para la casuística de las facturas electrónicas (para que los pobres clientes finales sin recursos pueden leerlas), pero no veo por ningún lado dónde esto tiene que algo que ver con el tema Veri*factu y tener un sistema informático de facturación conforme a intentos de fraude, dónde a todas luces sería justificado utilizar un espacio web público (como TBAI o VeriFactu).