Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[CarlosR]

Muy buenas, compruebo que el hilo es largo. No lo he leido todo -todará entre hoy y mañana-.
Por eso si pregunto algo que ya haya sido tratado pido disculpas de antemano.
Mi pregunta si es que hay respuesta sería, ¿ cómo solucionásteis el problema de tener los datos propios de veri*factu en una tabla si las tablas suelen tener un buen número de campos y desde luego muchos mas que los que veri*factu necesita ? La Agencia Tributaria en su Ley dice que solo quiere ver esos datos, ningún otro.
En mi caso, llevo ya mas de 1 año trabajando en ello -entre otras cosas-, lo he solucionado aumentando un campo de contenido XML a las tablas de cabeceras de factura, exactamente igual al que se subiría a la AEAT mediante su servicio, con encadenado, etc. Por lo que es verificable desde la aplicación tanto los datos del registro como el contrastado campo XML.
Por ello tanto que la empresa se acoja a veri*factu como que no, el campo contendría los mismos valores.

¿ Cómo lo veis ?
Gracias de antemano y un saludo por el árduo trabajo de mantener este foro.

[antoine0]

Empezado por CarlosR

Mi pregunta si es que hay respuesta sería, ¿ cómo solucionásteis el problema de tener los datos propios de veri*factu en una tabla si las tablas suelen tener un buen número de campos y desde luego muchos mas que los que veri*factu necesita ? La Agencia Tributaria en su Ley dice que solo quiere ver esos datos, ningún otro.

Creo que tienes que contemplar los registros de Veri*factu como unas tablas paralelas a los datos de tu factura natural. Y el proceso de encadenación y demás corren contar estas tablas paralelas, no contra la(s) tabla(s) que contienen los numerosos datos de las facturas.

Digo tablas porqué en la mayoría de los casos hay por lo menos 2: una tabla con una fila por factura, y una tabla con una fila por tipo de IVA aplicable y cuota. Este modelo sirve en el caso que hay más de un tipo de IVA aplicable, la suma de estas bases imponibles para una determinada factura siendo el importe "bruto" de la factura.
Evidentemente, una vez que te has puesto en un modelo de datos donde hay más que una tabla, pueden haber muchísimo más que 2 tablas. Aquí vienen rectificativas, múltiples destinatarios y demás casos extraños.

[CarlosR]

Gracias por la rapidez. Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.
Revisaré mi código lo antes posible.

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

Empezado por CarlosR

Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.

Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.

[keys]

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

Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.

Que yo sepa Veri*Factu no dice que tengas que tener esos campos en la base de datos, sólo dice que el programa tiene que ser capaz de generar unos ficheros con esa estructura para poder enviarlos a hacienda, ademas de garantizar el hash y otra serie de cosas de las facturas.

Otra cosa es que este mejor o peor estructurada la base de datos por tener unas tablas diferentes, ya que al final estas guardando datos en tablas distintas y al final puede influir en el rendimiento de la aplicación.

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

Empezado por keys

Que yo sepa Veri*Factu no dice que tengas que tener esos campos en la base de datos, sólo dice que el programa tiene que ser capaz de generar unos ficheros con esa estructura para poder enviarlos a hacienda, ademas de garantizar el hash y otra serie de cosas de las facturas.

Otra cosa es que este mejor o peor estructurada la base de datos por tener unas tablas diferentes, ya que al final estas guardando datos en tablas distintas y al final puede influir en el rendimiento de la aplicación.

Totalmente de acuerdo.
En nuestro caso hemos decidido guardar siempre lo que se envía (SII, TBAI, VERI*FACTU,...). Pero es una decisión personal, en algunos casos no es obligatorio y como bien dices, si se hace tampoco tiene porqué ser en base de Datos. Esto es decisión nuestra.

[keys]

Gracias, es que era por si se me escapaba algo.

[CarlosR]

Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.

[sglorka]

Empezado por CarlosR

Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.

Yo tenía en mente también desarrollar el aplicativo para que cubriese el modo VeriFactu y el modo Requerimiento, pero esa idea voló de mi cabeza nada más ver en la OM, la tabla de eventos que hay que gestionar, además de hacerte cargo de la copia de seguridad de los registros de facturación durante los últimos 4 años que tienen que estar disponibles para un requerimiento. La aplicación no tiene porqué cubrir ambos modos, es más, creo que la inmensa mayoría sólo va a desarrollar VeriFactu y el cliente tendrá lentejas. El reglamento define un campo en el xml donde tú dices si tu aplicación va a trabajar en un modo u otro.

Respecto de las tablas que te traen loco, te haría una reflexión. A veces programamos para resolver un problema y una vez que tenemos el proceso funcionando lo cerramos y a otra cosa. No nos paramos a pensar cómo deberíamos actuar en caso de que dicho proceso tuviera que responder a un imprevisto. Mientras va todo bien el programa funciona pero si surge un problema, restauración del sistema con una copia de hace dos días por encriptación del equipo, envío incorrecto del algún campo como, fecha de operación, régimen tributario, huella calculada con un retorno de carro de más, etc. tenemos que poder resurgir de estas cenizas y que nuestro proceso pueda salir más o menos airoso.
Te digo esto porque da igual las tablas que uses para resolver el problema, te tienes que preguntar lo siguiente. ¿ Con la estructura que he diseñado para el mundo de las mil maravillas donde todo funciona, podría rehacerme de un imprevisto ?

En mi caso particular, le emisión de documentos de venta no la he tocado en el sistema. He creado tablas de apoyo, Cabeceras, Líneas de venta, Bases-Tipos-Cuotas, etc que almacenan una foto estática de cómo se ha emitido la factura, con descripciones de productos, nombre, dirección, provincia de cliente, etc. sin identificadores, sólo texto descriptivo. Estas tablas las uso para generar los registros de facturación y no guardan integridad referencial con mis tablas maestras. Cuando imprimo una factura ya no lo hago desde mis tablas de facturas si no de estas tablas de apoyo que están aisladas ( recuerda que si reimprimes una copia de factura debe decir lo mismo que la primera vez que lo hiciste, si has cambiado datos personales del cliente o descripciones de productos, no pueden influir en esta copia).
Estas tablas no participan de ningún repositorio de informes con lo que no penalizan la obtención de los mismos.

En resumen, espero que te sirva de un poco de ayuda.

[CarlosR]

Si, realmente es un tostón no acogerse a veri*factu. Por eso llevo ya mas de un año cambiando TODO el sistema de gestión. Entre otras cuestiones los logs y la identificación de cada registro. Hay un log para developers y otro para el que lleve el mantenimiento de la instalación y otro para el propio sistema. Allí se recogen todas las incidencias. Se necesita una buena auditoría, aunque nadie está libre de intervenciones externas. Eso sí, hay que registrarlo todo en los logs y no se pueden alterar.
Según yo leí en el comunicado del año 2022 parece ser que los aplicativos DEBEN TENER LAS DOS MODALIDADES. Es el cliente quien exige eso.
Puedes trabajar en la nube, es otra opción. Ahí puedes tener las copias automatizadas y controladas. Personalmente trabajo la mayoría con C++ builder pero tanto C++ como Delphi tienen un gran sistema cliente/servidor denominado DataSnap. Eso te da capas para trabajar en la nube con seguridad y potencia.
En fin, gracias por vuestro inestimable apoyo. Cualquier cosa que se necesite en el foro no hay mas que hacérmelo saber.

[edari]

Empezado por CarlosR

Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.

Yo no lo tengo tan claro.


Nosotros solo vamos a hacer la programar la opción Verifactu y tengo claro que es potestad de nuestros clientes si alguno quiere quedarse en el otro sistema abandonar nuestra empresa.

[Sistel]

Empezado por edari

Yo no lo tengo tan claro.
Nosotros solo vamos a hacer la programar la opción Verifactu y tengo claro que es potestad de nuestros clientes si alguno quiere quedarse en el otro sistema abandonar nuestra empresa.

Hola,

Soy de la misma opinión.
Nosotros ofreceremos sólo la opción Verifactu y al cliente que no le guste ... tiene otras ofertas en el mercado.

Saludos

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

Empezado por CarlosR

...pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no.
El aplicativo debe tener las dos versiones.

Yo no tengo claro esas afirmaciones.
No creo que el programa deba llevar las 2 implementaciones y no creo eso sea una decisión del cliente final.

Creo que tú puedes decidir implementar la opción de envío inmediato (con eso ya cumples con la ley) y vender tu programa con esa implementación.
Puedes justificar más o menos al cliente porqué tu programa funciona de esas manera, pero no creo que estés obligado a más.

Empezado por CarlosR

Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado.

Creo que estás mezclando cosas.
De verdad que no veo que tiene que ver el encadenamiento de los XML de las facturas que envías a la AEAT, con el diseño de tablas de tu aplicación.
Al final tú guardas facturas en tu Base de Datos (sea como sea), de cada factura generas un XML, le añades una parte del ultimo XML generado(encadenamiento) y lo firmas.

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