Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[[newtron]]

Hola a tod@s.


Según interpreto yo en lo que he leido sobre la ley TODOS los programas que salgan al mercado tendrán que ser VeriFactu 9 meses después de la publicación del desarrollo de la ley. Independientemente de eso el usuario final decidirá si envía de forma automática los datos o no pero el programa deberá de tener la opción de enviarlos a requerimiento de la aeat.


Saludos.

[sglorka]

Empezado por newtron

Hola a tod@s.


Según interpreto yo en lo que he leido sobre la ley TODOS los programas que salgan al mercado tendrán que ser VeriFactu 9 meses después de la publicación del desarrollo de la ley. Independientemente de eso el usuario final decidirá si envía de forma automática los datos o no pero el programa deberá de tener la opción de enviarlos a requerimiento de la aeat.


Saludos.

Creo que no lo has interpretado bien. Cito Orden Ministerial

Artículo 3. Particularidades aplicables a los “Sistemas VERI*FACTU”.
De acuerdo con lo previsto en el artículo 16.2 del Reglamento, se presumirá que los sistemas
informáticos que tengan la consideración de “Sistemas de emisión de facturas verificables” o
“Sistemas VERI*FACTU”, cumplen por diseño los requisitos y características que recogen el
resto de secciones del capítulo II de esta orden y, en tanto actúen como sistemas
VERI*FACTU, no les serán de aplicación los artículos 6.b), 6.c), 6.d), 6.e), 6. f), 7.f), 7.h), 7.i),
7.j), 8 y 9 de esta orden.

Según el reglamento, un sistema es VeriFactu si realiza la remisión voluntaria de los registros de facturación de forma inmediata, consecutiva, segura, etc.. y sus características está desarrolladas en el
Artículo 16. Especificaciones técnicas de la remisión voluntaria

Por lo tanto, si un sistema VeriFactu está exento de cumplir el Artículo 8. Conservación, accesibilidad y legibilidad de los registros de facturación no nos pueden pedir mediante requerimiento la remisión de los registros de facturación por que , primero, no estamos obligados a conservarlos (Artículo 8) y segundo, evidente, ya los tienen ellos.

[CarlosR]

DOCUMENTO SOMETIDO A TRÁMITE DE INFORMACIÓN PÚBLICA 21 DE FEBRERO DE 2022

Página 11, Artículo 8.
... habla de los requisitos que debe cumplir todo programa informático indistintamente de si se utilizará o no veri*factu.

Página 17, Artículo 16.
2-A los efectos de este Reglamente, se presumirá que los Sistemas de emision de facturas verificables cumplen por diseño los requisitos del artículo 8.2

Página 17, Artículo 17.
1-Es voluntario acogerse a veri*factu (QR y subida de datos a la AEAT automática)
No sólo es voluntario sino que puedes solicitar una explusión de la empresa por determinados factores.

¿ Qué haces si el cliente no se había acogido a veri*factu y decide acogerse en algún ejercicio ?
¿ Una versión del programa en función de cada situación ? El productor informático no puede obligar al cliente a tomar una decisión fiscal.

BOLETIN OFICIAL DEL ESTADO 06-12-2023

Página 161955,
... etandarización de los formatos de los registros que contienen la información generada, su aportación a la Administración Tributaria, ya sea mediante requerimiento singular...

Página 161956,
... necesidad de interactuar con tales datos en su formato nativo
b) Conseguir que todas las operacones que se realicen se graben en el sistema informático de manera segura, no manipulable, accesible...
d) Garantizar la integridad, autenticidad y trazabilidad de los datos registrados...

Página 161961,
apartados Dos y Tres. Habla sobre los requisitos a aplicar en los sistemas informáticos incluido veri*factu

Para concluir :

He estado en algunos weminar, entre otros uno en el que participaba el director general de informática y de inspecciones tributarias,
la conclusión mas o menos que comprendí (es difícil comprender a esta gente) fue que si usas veri*factu la AEAT no indagará mucho mas
en los sistemas informáticos porque ya tienen los datos allí.

Sin otro ánimo de parecer un PESADO quería aclarar mi post. Grcias por vuestras participaciones.
Cada una me aporta una nueva forma de comprender el proceso de integración y enriquece el producto final.
Un saludo a todos.

P.D. "No existen preguntas sin respuesta, solo preguntas mal formuladas." -Laurence Fishburne-

[antoine0]

Empezado por CarlosR

¿ Qué haces si el cliente no se había acogido a veri*factu y decide acogerse en algún ejercicio ?

Lo mismo que tu haces si tu cliente te dice que se ha acogido a una opción inusual del Código aduanero, o decide emitir algunas facturas acogidas al IVA en otro país de la U.E. (para poner ejemplos): le explicas a tu cliente que tu programa no es un todopoderoso y que este caso no lo contempla (en la actualidad; siempre dejar opciones comerciales...)

¿ Una versión del programa en función de cada situación ?

Esto me da a pensar que el precio de los programas no-Veri*factu (o con las dos opciones) pueden salir más caros que los programas solo Veri*factu; e incluso que la diferencia puede ser notable.
Y creo que sería bastante lógico, además.

El productor informático no puede obligar al cliente a tomar una decisión fiscal.

No es lo que estas haciendo, si le dices a tu cliente que no lo puedes acompañar en su viaje si él toma tal decisión.
Dicho de otra forma: si implementas solo la parte Veri*factu, lo debes poner bien claro en la documentación comercial, para que le cliente no se equivoque comprando el programa inadaptado.
Y si tienes clientes ya y no piensas desarrollar la opción no-Veri*factu, ahora parece un buen momento para pensar en el mensaje marketing que hay que diseñar para explicar a estos clientes 1º que les va a costar el cambio iniciado por el gobierno (incluso cosas como poner el sistema de facturación conectado a internet, o el tema de los certificados), y 2º que solo está la opción de acogerse al Veri*factu, si se quieren quedar contigo y tener menos inspecciones de Hacienda. O algo así (no soy bueno en marketing ).

[jlmoli_67]

Buenas, tengo un problema que llevo tres dias sin poder solventar y que esta relacionado con los destinatarios.

No tengo narices de crear el siguiente nodo con el wsdl importado dentro de RegistroAltaFacturas (..prewww2.aeat.es|static_files|common|internet|dep|aplicaciones|es|aeat|tikeV1.0|cont|ws|SistemaFac turacion.wsdl)


<sum1: Destinatarios>
<sum1: IDDestinatario>
<sum1: NombreRazon>XXXXX</sum1:NombreRazon>
<sum1:NIF>XXXXX</sum1:NIF>
</sum1:IDDestinatario>
</sum1: Destinatarios>

Para empezar no puedo asignar la propiedad NIF a PersonaFisicaJuridicaType pero si me aparece dicha propiedad para PersonaFisicaJuridicaESType.

Como lo lo habeis hecho ? Alguien por favor me podria ayudar mostrandome el codigo a generar para poder crear el dichoso destinatario?


muchas gracias de antemano

[jlmoli_67]

Ya lo consegui, gracias.

Tengo ya casi todo el xml. Lo poco que me queda creo que no me dara problemas.

El codigo lo desarrolle en vb .net y lo tengo bastante avanzado. Si alguien lo necesita sera un placer darselo.

[ermendalenda]

Empezado por jlmoli_67

Ya lo consegui, gracias.

Tengo ya casi todo el xml. Lo poco que me queda creo que no me dara problemas.

El codigo lo desarrolle en vb .net y lo tengo bastante avanzado. Si alguien lo necesita sera un placer darselo.

Gracias jlmoli_67

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

Lo pongo aquí porque es un tema importante.

Estraído de las dispositivas de la AEAT, de este PDF:
https://www.agenciatributaria.es/sta.../Novedades.pdf




Según el párrafo señalado, yo entiendo que la AEAT asume que puede haber sistemas sólo diseñados como VERI*FACTU. Si eso no estuviera permitido ya ni lo pondrían aquí.

[CarlosR]

Pues sí, había visto ese PDF y creo que hasta lo tengo impreso, pero por alguna razón no lo recordaba.
Queda meridianamente claro.

Gracias.