Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[Casimiro Notevi]

[CarlosArjonomia]

Hola, ¿Navarra queda en un limbo con esto de verifactu?

[ermendalenda]

Si no recuerdo mal, en el último webinar del exj3fe de inspección de hacienda, Javier Hurtado, posiblemente se acoja a Verifactu al igual que pasó con el SII.

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

Empezado por seccion_31

Programa demostracion alta-anulacion facturas verifactu, que incluye un simulador de respuesta muy basico.
El programa con fines educativos, permite añadir y anular desde archivos excel facturas, enviarlos a la AEAT ó simular un envio.

La direccion de descarga esta en:
https://github.com/seccion31/verifactu-delphi-demo

Espero que este medianamente correcto y sirva de guia a los mas despistados, entre los que me incluyo.

Gracias por el aporte [seccion31].
Subo el proyecto al FTP del club, junto a un fichero TXT con una pequeña descripción y el link a github (original).
https://terawiki.clubdelphi.com/Otro...go-proyectos_/

Actualizo también el segundo mensaje del hilo, donde iremos recopilando códigos útiles.

[[newtron]]

Empezado por seccion_31

Programa demostracion alta-anulacion facturas verifactu, que incluye un simulador de respuesta muy basico.

El programa con fines educativos, permite añadir y anular desde archivos excel facturas, enviarlos a la AEAT ó simular un envio.

La direccion de descarga esta en:

https://github.com/seccion31/verifactu-delphi-demo

Espero que este medianamente correcto y sirva de guia a los mas despistados, entre los que me incluyo.

Cualquier correccion y sugerencia seran bienvenidos.

Gracias compañero.

[ermendalenda]

Hay una revisión de la imagen del QR.
No esperes nada bueno.
Sigue quedándose donde dijeron y además presionan un poco más con el mensaje de inmediatez.
Si un cliente pasa el QR, antes decían que aún no se ha subido y que lo intenten un poco más tarde, ahora lo han cambiado por aún no lo han subido por que han podido tener una incidencia puntual.
Una vueltecita más de tuerca jeje.

[frrr@grupo3rs.c]

Off-Topic

Alguien puede aclararme una duda. Si se produce un crimen con una hacha comprada en la ferretería del pueblo, se presupone que el criminal es el que usa el hacha para realizar el crimen, NADIE IMPUTA AL VENDEDOR DE LA FERRETERIA. Entonces porque en el tema que nos ocupa VERI*FACTU, y después de leer y analizar TODO lo que se ha publicado en este foro, planteo la pregunta :

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

Bajo mi opinión, el desarrollador ha de realizar la aplicación VRI*FACTU cumpliendo la normativa de facturación ya publicada, a partir de este momento termina toda su responsabilidad.

Quien puede evitar que el usuario realice las facturas con sino negativo en lugar de realizar una rectificativa. Por el mismo motivo, se puede emitir una factura sin IVA porque se trate como si fuera Canarias o intracomunitaria siendo esto realizado por error.

Disculpad si me he pasado con mis apreciaciones y si alguien quiere anotar su opinión , la guardare con aprecio.

Un saludo

[ermendalenda]

Empezado por frrr@grupo3rs.c

Off-Topic

Alguien puede aclararme una duda. Si se produce un crimen con una hacha comprada en la ferretería del pueblo, se presupone que el criminal es el que usa el hacha para realizar el crimen, NADIE IMPUTA AL VENDEDOR DE LA FERRETERIA. Entonces porque en el tema que nos ocupa VERI*FACTU, y después de leer y analizar TODO lo que se ha publicado en este foro, planteo la pregunta :

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

Bajo mi opinión, el desarrollador ha de realizar la aplicación VRI*FACTU cumpliendo la normativa de facturación ya publicada, a partir de este momento termina toda su responsabilidad.

Quien puede evitar que el usuario realice las facturas con sino negativo en lugar de realizar una rectificativa. Por el mismo motivo, se puede emitir una factura sin IVA porque se trate como si fuera Canarias o intracomunitaria siendo esto realizado por error.

Disculpad si me he pasado con mis apreciaciones y si alguien quiere anotar su opinión , la guardare con aprecio.

Un saludo

Estoy de acuerdo. Muchos casos en los que el cliente actúe "equivocadamente" con mala fe o erróneamente, puede pasar que nos salpique. Estoy seguro que el desarrollo reglamentario final nos va a dar trabajo en cuanto a requerimientos que el cliente no sabe solucionar y tendremos que ir creando herramientas para que el cliente sea lo más autosuficiente posible, pero nos van a dar por el ojete seguro.
Posiblemente te pase lo mismo que nos pasa a todos, cosas que antes no controlaban vamos a tener quenpegarnos muchas horas sin dormir.

[frrr@grupo3rs.c]

Empezado por ermendalenda

Estoy de acuerdo. Muchos casos en los que el cliente actúe "equivocadamente" con mala fe o erróneamente, puede pasar que nos salpique. Estoy seguro que el desarrollo reglamentario final nos va a dar trabajo en cuanto a requerimientos que el cliente no sabe solucionar y tendremos que ir creando herramientas para que el cliente sea lo más autosuficiente posible, pero nos van a dar por el ojete seguro.
Posiblemente te pase lo mismo que nos pasa a todos, cosas que antes no controlaban vamos a tener quenpegarnos muchas horas sin dormir.

Pero en ese caso estamos hablando de COMPETENCIA DESLEAL con respecto a contables y asesores fiscales, salvo que el desarrollador este capacitado y titulado en ambas categoría CONTABLE y ASESOR, y este caso creo que es muy difícil encontrarlo.

[ermendalenda]

Empezado por frrr@grupo3rs.c

Pero en ese caso estamos hablando de COMPETENCIA DESLEAL con respecto a contables y asesores fiscales, salvo que el desarrollador este capacitado y titulado en ambas categoría CONTABLE y ASESOR, y este caso creo que es muy difícil encontrarlo.

Se que, por ejemplo, en Portugal, muchas empresas de desarrollo han tenido que chapar. No te interesa meterte en temas legales para perder el tiempo a no ser que tengas un primo ministro o un padre juez del supremo
Te dirán que si tienes que contratar una auditoría para fiscalizar correctamente todo es nuestro problema.

[Noe277]

Empezado por frrr@grupo3rs.c

Pero en ese caso estamos hablando de COMPETENCIA DESLEAL con respecto a contables y asesores fiscales, salvo que el desarrollador este capacitado y titulado en ambas categoría CONTABLE y ASESOR, y este caso creo que es muy difícil encontrarlo.

Ya han estado comentado que los asesores y contables deberían empezar a reorientar sus negocios. La hacienda va a ser quien te haga los impuestos y a no ser que sea una empresa que tenga la capacidad de hacer algo de ingeniería fiscal para pagar menos los asesores los tiene crudo.

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

Empezado por frrr@grupo3rs.c

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

Bajo mi opinión, el desarrollador ha de realizar la aplicación VRI*FACTU cumpliendo la normativa de facturación ya publicada, a partir de este momento termina toda su responsabilidad.

Yo creo que es así.
Al final lo que pretendes es que tu programa no facilite el "trabajar mal". Si tu programa es correcto y el cliente "trabaja mal" (por no decir en B) la responsabilidad es suya. Lo único que tu programa no debería facilitárselo.

[antoine0]

Empezado por frrr@grupo3rs.c

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

No soy letrado, pero esto me recuerda una cuestión básica de derecho civil: las obligaciones y las responsabilidades.
Un asesor tiene obligación de medíos; no tiene responsabilidades sobre las consecuencias de sus consejos.
El desarrollador tiene obligación de resultado, y eso incluye la responsabilidad de producto que distribuye (realmente, la obligación de corregir sus errores y defectos).

No creo que los desarrolladores tienen responsabilidad fiscal o contable (y seguro que tiene todas las responsabilidades). Tienen la responsabilidad de suministrar un producto que cumple la normativa, nada más.[/quote]

[xevi]

Por lo que voy leyendo en este foro y muchas conversaciones sobre el tema de la ley 1007/2023... parece ser que CADA VEZ TENGO MÁS CLARO el desarrollo de mi aplicación de facturación SOLO para clientes que esten adscritos forzosamente o voluntariamente al SII.

Imaginad el tema como está, que legalmente, tenemos más a perder los desarrolladores de software de facturación (de momento, porqué vendran más y más cambios en otras aplicaciones), que los propios usuarios de nuestras aplicaciones.
En este caso que os comento, imaginad un cliente empresa/autónomo que voluntariamente decide (o le convecemos) entrar en el SII, esta nueva ley 1007/2023 se la pasa por el forro, con perdón de la expresión, y nosotros como desarrolladores del SIF, también. Solamente, entiendo yo, haciendo una comprovación del egistro y poniendo una nota al arrancar el SIF que el aplicativo SOLO es utilizable para aquellos que esten adscritos al SII, tema resuelto. Ni QRs, ni trazabilidad, ni custódia... nada de nada!!!
Asi, pues, el aplicativo SIF puede seguir siendo, incluso... Excel!!!

¿Que compromete el SII a nuestros clientes???
Haber de enviar a hacienda los registros de facturación (facturas emitida i recibidas), con un sistema mas "laxo", diría yo.
Tienen cuatro días para poder hacer el envío. El sistema és muy ágil por lo que he ido utilizando en un par de clientes que lo está utilizando... y nos permite "rectificar" registros mientras no lo hayamos enviado al SII

Como yo tengo ya funcionando mi parte de envios a hacienda del SII...
No se... me lo estoy planteando y és la salida con menos responsabilidades que me puedo echar sobre mi persona. Hacienda no perdona ni un resbalón, cualquier pequeño fallo en nuestro aplicativo se puede convertir en una arma muy peligrosa para nuestros intereses.
VERI*FACTU ni NO VERI*FACTU... SII

[Sistel]

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

... Lo único que tu programa no debería facilitárselo.

Hola,

En nuestras aplicaciones ponemos controles de todo tipo y con ellos esperamos que el cliente no pueda realizar determinadas acciones.
El problema es que el cliente suele darle muchas vueltas a las cosas y siempre encuentra resquicios que no habíamos previsto para obtener lo que quiere hacer.
La picaresca del cliente es infinita y no es raro que encuentre métodos (inimaginables por nosotros) para saltarse nuestros controles.

Saludos

[Sistel]

Empezado por xevi

Por lo que voy leyendo en este foro y muchas conversaciones sobre el tema de la ley 1007/2023... parece ser que CADA VEZ TENGO MÁS CLARO el desarrollo de mi aplicación de facturación SOLO para clientes que esten adscritos forzosamente o voluntariamente al SII.

Imaginad el tema como está, que legalmente, tenemos más a perder los desarrolladores de software de facturación (de momento, porqué vendran más y más cambios en otras aplicaciones), que los propios usuarios de nuestras aplicaciones.
En este caso que os comento, imaginad un cliente empresa/autónomo que voluntariamente decide (o le convecemos) entrar en el SII, esta nueva ley 1007/2023 se la pasa por el forro, con perdón de la expresión, y nosotros como desarrolladores del SIF, también. Solamente, entiendo yo, haciendo una comprovación del egistro y poniendo una nota al arrancar el SIF que el aplicativo SOLO es utilizable para aquellos que esten adscritos al SII, tema resuelto. Ni QRs, ni trazabilidad, ni custódia... nada de nada!!!
Asi, pues, el aplicativo SIF puede seguir siendo, incluso... Excel!!!

¿Que compromete el SII a nuestros clientes???
Haber de enviar a hacienda los registros de facturación (facturas emitida i recibidas), con un sistema mas "laxo", diría yo.
Tienen cuatro días para poder hacer el envío. El sistema és muy ágil por lo que he ido utilizando en un par de clientes que lo está utilizando... y nos permite "rectificar" registros mientras no lo hayamos enviado al SII

Como yo tengo ya funcionando mi parte de envios a hacienda del SII...
No se... me lo estoy planteando y és la salida con menos responsabilidades que me puedo echar sobre mi persona. Hacienda no perdona ni un resbalón, cualquier pequeño fallo en nuestro aplicativo se puede convertir en una arma muy peligrosa para nuestros intereses.
VERI*FACTU ni NO VERI*FACTU... SII

Hola,

No creo que tarden mucho en hacer obligatorio Veri*Factu aunque se esté en el SII.
De hecho, por ejemplo, en las Haciendas Forales del País Vasco es obligatorio TicketBAI aunque se esté en el SII.

Y con la obligación de factura electrónica (que al final unificarán con Veri*Factu) Hacienda irá controlando cada vez más hasta tener la contabilidad de todos los negocios en sus manos, en tiempo real.

Tiempo al tiempo.

Saludos

[CarlosR]

Empezado por frrr@grupo3rs.c

Off-Topic

Alguien puede aclararme una duda. Si se produce un crimen con una hacha comprada en la ferretería del pueblo, se presupone que el criminal es el que usa el hacha para realizar el crimen, NADIE IMPUTA AL VENDEDOR DE LA FERRETERIA. Entonces porque en el tema que nos ocupa VERI*FACTU, y después de leer y analizar TODO lo que se ha publicado en este foro, planteo la pregunta :

Porque se esta derivando TODA LA RESPONSABILIDAD FISCAL Y CONTABLE sobre el desarrollador de la aplicación VERI*FACTU, cuando legalmente el/los responsables son los GESTORES Y LOS ASESORES FISCALES que son los que tienen que indicar al cliente/empresa la forma de actuar a partir de la publicacion de las normas VERI*FACTU y son lo que tienen que controlar los distintos conceptos y artículos contables/fiscales.

Bajo mi opinión, el desarrollador ha de realizar la aplicación VRI*FACTU cumpliendo la normativa de facturación ya publicada, a partir de este momento termina toda su responsabilidad.

Quien puede evitar que el usuario realice las facturas con sino negativo en lugar de realizar una rectificativa. Por el mismo motivo, se puede emitir una factura sin IVA porque se trate como si fuera Canarias o intracomunitaria siendo esto realizado por error.

Disculpad si me he pasado con mis apreciaciones y si alguien quiere anotar su opinión , la guardare con aprecio.

Un saludo

Estoy de acuerdo en que el responsable debería ser el que hace uso de la herramienta y no quien la crea, sino todas las armas blancas estarían prohibidas. Es una vigilancia social encubierta.

Es un paso mas para que ejerzan de "guardianes" los que crean el soft.
No obstante no debe confundir "veri*factu" con "NO veri*factu".
En el caso veri*factu el responsable no es el que crea el soft sino el que lo usa. La responsabilidad del fabricante está en último caso en que el sistema pueda enviar a la AEAT la información generada por la empresa que usa el software. No hay responsabilidad del fabricante del software, salvo su buen funcionamiento como no debería ser de otra manera.
Otra cuestión muy muy distinta es el caso de acogerse al modelo NO veri*factu. Aparte de generar, vigilar, certificar información tal como los registros y los eventos (y un montón de cosas mas) el responsable de los datos es el fabricante del soft. Esto es una opción, el cliente que quiera ese soft ha de pagarlo y no puede tener acceso a los datos o al menos a modificarlos. Significa el uso si o si de la nube. Un buen seguro, muchas copias y un buen equipo jurista. Eso se soluciona con la billetera. Supongo que hay pocas excepciones que necesiten esta opción.

Pero si se acoge al modelo solo veri*factu no debería preocuparse mucho. Impida desde el programa que el cliente no pueda cambiar nada y poco mas. Si el cliente accede por fuera del programa y cambia algo es responsabilidad del cliente puesto que el soft no permite tales cambios y ya ha registrado en la AEAT en su momento las facturas.

Un saludo.

[jlmoli_67]

Buenas.


Me podriais aclarar si este planteamiento es correcto, por favor?. Vuelvo a estar muy liado


tenemos una factura de 1000 Euros + 210 Euros de IVA. Por un error en la misma, necesitamos hacer una rectificación, siendo el importe correcto 800 Euros + 168 de IVA:

• Emitimos primero una factura ordinaria en negativo de -1000 Euros (y -210), es decir, la factura original pero en negativo.
• Emitimos una nueva factura ordinaria de 800 (+168) .
• En este caso no se rellenan los datos “base rectificada”, “cuota rectificada” y las estadisticas a nivel de articulos e inventario cuadrarian, etc.

gracias por vuestra ayuda.

[keys]

En principio esta bien. Pero no estas emitiendo una factura simplificada por sustitución.Para hacer una factura rectificativa por sustitución tienes que emitir una sola factura.

- Emitimos una nueva factura Rectificativa por sustitución de 800 (+168) . y en la base rectificada pones 1000 y en la cuota rectificada 210. Esto rectifica toda la factura inicial.
dejándola a 0.

Un saludo. Yo creo que esto sería lo mas correcto.

[Sistel]

Empezado por jlmoli_67

Buenas.


Me podriais aclarar si este planteamiento es correcto, por favor?. Vuelvo a estar muy liado


tenemos una factura de 1000 Euros + 210 Euros de IVA. Por un error en la misma, necesitamos hacer una rectificación, siendo el importe correcto 800 Euros + 168 de IVA:

• Emitimos primero una factura ordinaria en negativo de -1000 Euros (y -210), es decir, la factura original pero en negativo.
• Emitimos una nueva factura ordinaria de 800 (+168) .
• En este caso no se rellenan los datos “base rectificada”, “cuota rectificada” y las estadisticas a nivel de articulos e inventario cuadrarian, etc.

gracias por vuestra ayuda.

Hola,

Lee la respuesta 48 de https://www.batuz.eus/es/preguntas-f...0&actualPage=2
Ahí explican las 2 posibles operativas en el caso de factura rectificativa por sustitución:
- Si se informa la base y cuota de la factura original, sólo tienes que emitir esa factura rectificativa por sustitución.
- Si no se informa de la base y cuota de la factura original, debes emitir una factura normal pero de importes negativos y una factura rectificativa con los nuevos importes.

Si se emite una factura rectificativa por diferencias sólo tienes que emitir una factura rectificativa de las diferencias entre la original y lo que debería haber figurado.

Nota: Eso es así en TicketBAI. Y supongo que en Verifactu será igual.

Saludos