Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

Así ojeando por encima y habiendo desarrollado TicketBAI (hacienda del país vasco) veo que la idea es bastante parecida; Han cogido ideas imagino. Veo lo siguiente:


"permitiendo, en su caso, la simultánea o posterior remisión de la información de los mismos a la Administración tributaria"

=> En el pais vasco ya está previsto que la fatura se envíe en cuanto se genera o durante un periodo posterior (lo antes posible dice la documentación). Es decir, no es condicionante para generar la factura. Se puede crear una cola (con un proceso externo) que va realizando los envíos.

"los obligados tributarios remitan inmediatamente a la Administración tributaria, de forma automática y segura por medios electrónicos, todos los registros de facturación generados en sus sistemas informáticos"
=> Cada ticket/factura que se genere hay que enviarla. En el caso del pais vasco, para personas/autónompos/miniempresas que generan pocas facturas al mes, ellos proveen un sistema para poder introducirlas manualmente. Pero esto sólo sirve para quien genere 5/10 facturas al mes.

"la estandarización de formatos de los registros de facturación, se deberá incluir: código «QR»

=> Igual. En cada factura que se emite, debe incluir QR con la información. Ese QR (hay un punto más adelante que lo explica) el usuario puede leerlo (con el móvil, por ejemplo) y le debe llevar a una web con los datos de su factura. Así se asegura de que se ha enviado y de que es igual que la que él tiene en papel (o en su ticket).

Algo así, para que os hagáis una idea:


"La integridad e inalterabilidad de los datos registrados se asegurará utilizando cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los registros de facturación desde que hayan sido grabados en el sistema informático"
=> Entiendo que habrá que utilizar certificado/firma con todo lo que se envíe (JSON/XML/...).

"La trazabilidad de los registros de facturación, que deberán estar encadenados de manera que pueda verificarse su rastro siguiendo su secuencia de creación desde el primero al último."

=> Todos los registros/facturas, deben incluir una parte de la firma de la factura anterior (encadenamiento), de esta forma te aseguras de que "no desaparecen facturas". Eso trae bastantes problemas técnicos (por experiencia). Si por lo que sea no puedes encadenar con la anterior hay que poder justificar porqué. Algo así como justificar los huecos en la facturación.

Generación del registro de facturación de alta
Generación y contenido del registro de facturación de anulación.
=> Se prevee alta, modificación y anulación de facturas (que no es lo mismo que rectificativas).

"El receptor de la factura, ya sea empresario o consumidor final, podrá proporcionar de forma voluntaria determinada información de la misma a la Agencia Estatal de Administración Tributaria facilitando el código identificativo de carácter alfanumérico o mediante la lectura del código «QR»"
=> El que recibe la factura puede remitirla también a la AEAT. Es decir se pueden enviar facturas de compra (en el País vasco también). cosa que a la AEAT le facilita mucho el trabajo de "vigilancia", porque así puede "cuadrar" las que recibe de compra con las que recibe de Venta. Y si no "cuadran" pues multa al canto...


"LaAgenciaEstataldeAdministraciónTributariafacilitaráunarutaespecíficaensusede electrónica o a través de la aplicación que al efecto ponga a su disposición para recibir dicha información. El acceso a la sede electrónica o a la aplicación mostrará los datos del código identificativo de carácter alfanumérico o del código «QR» en formato legible"
=> La web que he mencionado anteriormente, donde escaneado el código de la factura/ticket en papel, obtienes info de la factura generada.
Como ejemplo, os muestro el QR de una factura generada para Guipuzcoa:



Si lo escaneáis, devuelveeste texto:
h_t_t_p_s://pruebas-ticketbai.araba.eus/tbai/qrtbai/?id=TBAI-B05430756-150222-BDM2BLewRizLS-007&s=SG&nf=3&i=36.00&cr=009
link: https://pruebas-ticketbai.araba.eus/...i=36.00&cr=009

Que es un link con los datos de la factura

[[newtron]]

Yo creo que lo suyo sería ir creando y manteniendo una lista de "especificaciones mínimas" que consensuemos entre todos y que deberían de tener nuestros programas para cumplir la dichosa normativa esta porque hay cosas que a mi no me quedan claras.

Por otro lado parece ser que todo esta movida va enfocada a las operaciones de venta por lo que entiendo que no hay mucho que hacer en compras, pedidos, traspasos, etc.

Yo de momento solo me he leido el documento por encima para hacerme una idea de "lo gordo" pero habrá que ir demenuzando así que, si os parece, me atrevo a comenzar la lista con algo que está meridianamente claro (si me equivoco me rectificáis):

**********************************

LISTA DE ESPECIFICACIONES MÍNIMAS

- Control e identificación de usuarios al acceder al programa. Este usuario se incluirá en todos los registros de operaciones de venta e igualmente se llevará un "registro de eventos" de cuando accede, las operaciones de venta que hace y cuando abandona el programa.

**********************************
Esto lo podemos ir copiando/pegando/ampliando y rectificando según vayamos entendiendo.

Para empezar ahora mi pregunta es: este "registro de eventos" cómo crearlo y manejarlo.


Saludos

[antoine0]

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

"La integridad e inalterabilidad de los datos registrados se asegurará utilizando cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los registros de facturación desde que hayan sido grabados en el sistema informático"
=> Entiendo que habrá que utilizar certificado/firma con todo lo que se envíe (JSON/XML/...).

Es cierto que hay que usar certificados (o equivalente como cl@vePIN) para transmitir cualquier cosa a Hacienda, para autenticarse; de no ser así, eventualmente cualquier mengano podría remitir documentación en nombre de fulano; y entonces fulano podría decir a Hacienda que no es lo suyo, y así evadir cualquier control Entonces se precisa HTTPS/TLS con certificado de cliente. Nada nuevo aquí.

Pero lo citado no se refiere a eso; se refiere a los mecanismos dentro de la aplicación (o de la base de datos).
Y aunque se pueden usar firmas electrónicos para cada registro grabado, no creo que sea siempre necesario, sobre todo por dos razones: 1, en términos de CPU, no sale gratis la firma electrónica; y 2, para firmar de forma completamente automática, la clave privada debe ser bajo el control del proceso automatizado, la cual cosa crea un potencial agujero de seguridad; qué atrae más complejidad, lo contrario del efecto buscado. Imaginad la diferencia en termino de código y de debug entre:

1. Calcular (eventualmente en un disparador) el hash SHA-2 de los datos de un registro más las referencias y huella del registro anterior (que crea el encadenamiento);
   o
2. engancharse con un módulo HSM externo para grabar cada registro en la base de datos

Yo sé con cuál de los dos prefiero lidiar

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

Empezado por antoine0

Pero lo citado no se refiere a eso; se refiere a los mecanismos dentro de la aplicación (o de la base de datos).

La integridad e inalterabilidad de los registros de facturación de forma que, una vez registrados
los datos de facturación, éstos queden protegidos contra cualquier acción que comprometa la
exactitud, autenticidad y completitud de los datos almacenados, de manera que ninguno de los
datos registrados pueda ser alterado, ni por el propio sistema informático, ni por el usuario ni por
ningún dispositivo, sistema o programa informático o electrónico externo.

El sistema informático no dispondrá de ninguna funcionalidad que permita, de forma presencial o
remota, alterar u ocultar los datos originales previamente registrados.


Tienes razón, esto se refiere a los mecanismos desde tu aplicación (ya he dicho que lo había leído rápido), pero debería bastar con algo básico; No creo que haya que usar firmas ni hashes dentro del propio programa (a lo más si lo deseas, puedes encriptar BD, aunque poersonalmente no me gusta si no es estrictamente obligatorio).
1) Tu aplicación no debe permitir hacer "cosas raras" (B)
2) Una vez modificados los datos y enviados, tu aplicación no debe permitoir modificarlos.
3) Debes proteger el acceso a la Base de Datos (SGBD) con usuario/contraseña, de forma que nadie desde fuera pueda acceder a los datos y cambiarlos.

Con eso te aseguras esa integridad e inalterabilidad.

[antoine0]

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

No creo que haya que usar firmas ni hashes dentro del propio programa

Sí, hay que usar huellas / hashes: mira al artículo 12; también a la letra ñ) del 10.1, dónde se especifica

ñ) El número y, en su caso, la serie de la factura anterior, la fecha de expedición y parte de la huella o «hash» del registro de facturación de alta correspondiente a la factura anterior, cuando no se trate de la primera factura expedida.

Se deduce que hay al mínimo una huella en todos los registros (salvo el primero).

Una cosita interesante es que en el artículo 11 (registros de anulación, cuando el 10 es para los registros normales) no hay un equivalente a la ñ. Entonces las anulaciones no están encadenadas por construcción (sigue de aplicación el 8.2 b que manda encadenar). Supongo que es por qué estos registros pueden ir opcionalmente mezclados con los normales en algunos sistemas (cuando los abonos se consideran como una forma más de factura).

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

Empezado por antoine0

Sí, hay que usar huellas / hashes: mira al artículo 12; también a la letra ñ) del 10.1, dónde se especifica
...

Creo que estás mezclando cuando se habla de registros, los que son de la propia aplicación, con los "registros de facturación" que se envían a la administración.

Cuando habla de esto:
Artículo 9.Generación del registro de facturación de alta

Se está refiriendo no a tu factura en BD, sino que ese "registro de facturación de alta" es el elemento que tú debes generar (XML, JSON,...) y que será enviado a la AEAT. Ese registro/fichero sí que va firmado, lleva encadenamiento, hash,...

Por eso luego habla de:
Artículo 11.Generación y contenido del registro de facturación de anulación

Lo mismo. Eso se refiere al XML/JSON que tú debes generar y envias cuando anulas una factura. En tu sistema la información de anulación no tiene porqué tener TODA la información que ahí se detalla. Piensa que tú para una anulación en tu sistema es posible que sólo necesites el ID de la factura inicial y FECHA de aulación y lo que ahí te pide es todo lo que se detalla en el artículo 11. Eso te está indicando que NO SE REFIERE a tu registro de BD, sino al "registro que envías".

Aquí deja claro que "el registro de facturación" NO ES tu registro de la Base de Datos, que tú puedes guardarlo como te convenga, sino a los ficheros que tú generas y envias a la administración:

Asimismo, los registros de facturación de alta y de anulación a que se refieren los mencionados
artículos deberán ser firmados electrónicamente. Esta firma electrónica no será obligatoria para
los sistemas informáticos que realicen la remisión de todos los registros de facturación a la
Agencia Estatal de Administración Tributaria según lo indicado en los artículos 15 y 16 de este
Reglamento

[ermendalenda]

El tema de garantizar los eventos es para mi el tema más complicado que nos han dejado ypodemos ir exponiendo ideas para no perdernos en generar infinitos datos intratables.
Hay que tener en cuenta:
-Estructura de los eventos para guardar en una base de datos
-Modo de garantizar la inviolabilidad de los registros.
-Que datos son propensos de grabar, ya que es tontería guardar la marcacion de las facturas, anulaciones etc ya que ya está guardada por otro lado y ya en si es un evento.
Por ejemplo:
¿Una empresa externa a la que le enviemos los eventos por webservice puede ser garantía de inviolabilidad?
Generar xmls o json firmados de miles de eventos va a tener una ocupación tremenda y manejar la petición de datos a través de esos ficheros firmados no es muy práctica, y generar una bd paralela para pedir los datos no es garantía de nada.
Vamos a intentar ser pragmáticos y buscar entre todos soluciones para esta problemática. Me parece absurdo este paso que dejan una puerta abierta a que cada uno decida que es un evento. Deslizar un dedo por la pantalla es un evento de mouse. Pulsar un producto y después eliminarlo es un evento más lógico de grabar. Fichar una entrada o salida de usuario por tener un módulo en el mismo software de facturación para el control horario, también es un evento, pero no es competencia de hacienda, ya que ese evento puede ser de un usuario que no factura, un limpiador, un cocinero.
Pienso que falta regulación y va a crear una laguna que para los informáticos se va a traducir en intranquilidad.

[antoine0]

No creo equivocarme.

Hablo siempre de los registros de facturación de alta o de anulación, colectivamente llamados registros de facturación en el reglamento (¿hay más tipos posible?)
No creo que el formato de estos registros siga descrito en el reglamento más allá de ser una compilación de varios datos (art.8) o elemento de información (art. 9-11). De hecho, creo que la forma puede variar según las operaciones que se realizan. Lo que se pide es que la compilación siga siempre integre e inalterable, y que se pudiera demostrar.

Dentro de las operaciones está subir los registros a Hacienda (art. 15.1). Esta vía soluciona efectivamente gran parte del problema (art. 16.2 dice que «cumplen por diseño» el 8.2), elimina la firma digital, quedando en practica solo el tema de la huella, arreglar el 10.1 ñ (datos de la factura anterior), generar el QR y, last but not least, la log, ya que todas las demás cosas deben existir en cualquier sistema de facturación actualmente conforme; además evidentemente de empezar con una base claramente limpia (dónde no se puede trastear con los datos, dónde las facturas se graban de una sola vez etc.)

En tal caso, la DFÚ (última página) promete un O.M. que definirá (apartados a, c, d, e y g) la huella, la forma de dichos registros cuando se suben y un largo etc. Dicho de otra manera, falta mucho para entrar en detalle.
Por ejemplo, yo leía que la huella, parte del registro descrito en el artículo 10, está sometida al art. 8.1 b y por tanto debe ser generado en el momento de la emisión de la factura, un momento que veo distintamente anterior a la subida del registro a Hacienda. Pero es cierto que tu lectura, que se genere la huella solo en el momento de subir los datos, actuando directamente sobre el registro en la forma que se envía a Hacienda, se puede defender.

Sin embargo, yo me planteaba sobre todo en el caso opuesto, cuando no se suben los registros a Hacienda, que para mi es lo más probable en un primer tiempo, es decir, antes que los informáticos de Hacienda hayan puesto en marcho el nuevo sistema y que se haya estabilizado las especificaciones de la O.M.

[Zento]

Os veo muy pesimistas... Dos cosas que me daban miedo y con las que me quedo más tranquilo:

• Con una declaración responsable del desarrollador, suficiente. Nos ahorramos que nos auditen el código y los costes que hubiera conllevado.
• Según la disposición adicional tercera, si tu programa soporta SII, ya tienes la mitad de la faena hecha, pero creo que de incluir el hash de la anterior no nos libramos, y algo de complicación técnica nos van a incorporar.

[ermendalenda]

Empezado por Zento

Os veo muy pesimistas... Dos cosas que me daban miedo y con las que me quedo más tranquilo:

• Con una declaración responsable del desarrollador, suficiente. Nos ahorramos que nos auditen el código y los costes que hubiera conllevado.
• Según la disposición adicional tercera, si tu programa soporta SII, ya tienes la mitad de la faena hecha, pero creo que de incluir el hash de la anterior no nos libramos, y algo de complicación técnica nos van a incorporar.

El pesimismo está fundado en que hay mucho trabajo que hacer en relativamente poco tiempo, ya que no podemos dejar de lado otros proyectos que son más productivos para las empresas, se pueden dar otros enfoques que lea viene bien a ciertas empresas pero no a todas, unos dicen que es una oportunidad de venta, pero no puede ser optimismo para todos. Depende de las circunstancias de cada uno

[[newtron]]

A ver... una idea tontuna que me pasa por la cabeza.


Según quiero entender lo que quieren es que el fichero donde se guardan los eventos no se pueda manipular pero no dicen cómo hacerlo ni con qué técnicas. ¿Sería una tontería ir metiendo registros con los textos encriptados en una tabla y luego poner un visor desde el programa para verlo o exportarlo? De esta manera los datos no se podrían tocar pero si visualizar y sería algo relativamente fácil de implementar.


Por otro lado, el tema de enviar los datos creo que no es obligatorio, ¿no?.



Saludos.

[keys]

Empezado por newtron

A ver... una idea tontuna que me pasa por la cabeza.


Según quiero entender lo que quieren es que el fichero donde se guardan los eventos no se pueda manipular pero no dicen cómo hacerlo ni con qué técnicas. ¿Sería una tontería ir metiendo registros con los textos encriptados en una tabla y luego poner un visor desde el programa para verlo o exportarlo? De esta manera los datos no se podrían tocar pero si visualizar y sería algo relativamente fácil de implementar.


Por otro lado, el tema de enviar los datos creo que no es obligatorio, ¿no?.



Saludos.

Habrá que esperar a que diga algo hacienda, para ver si establece la forma de hacer las cosas o no. En cuanto a los eventos, si tu los metes en una base de datos con un usuario y contraseña ya estas garantizando que no se puedan modificar desde fuera. Luego lo tendrás que gestionar en tu programa.

Los datos no son obligatorio que los envíe el contribuyente, pero entiendo que si es obligatorio que el programa permita realizar el envío. Ya que hacienda le puede solicitar las facturas para una inspección, y eso habrá que hacerlo en el formato que defina hacienda o eso me ha parecido entender.

De todas formas creo que lo mejor es esperar a que hacienda (que somos todos) empiece a sacar cosas. Aunque se puede ir adelantando algo.

[antoine0]

Empezado por ermendalenda

... no podemos dejar de lado otros proyectos que son más productivos para las empresas, ...

Me parece raro que lo ves de esta manera.
De mi punto de vista, esto va a generar un MONTÓN de trabajo para las empresas que se dedican a este negocio, ya que básicamente todo las empresas españolas deben actualizarse, en un espacio de tiempo breve.
Es cierto que hay otras opciones como ir a por el cloud que serán seguramente privilegiadas e incentivadas (con los multimillonarios fondos europeos y la «digitalización»), pero quedará mucho pastel para repartirse. Hasta el punto que, si no se demora el proyecto, creo que dentro de varios meses es posible que veamos una «crisis» cuando el calendario apretará un poco más y empezará a escasear los informáticos, con la consecuente subida de los precios para las empresas que no se habrán asegurado en tiempo, y entonces un aluvión de dinero para las empresas de informática (y también después un bajón cuando la bonanza se acabará y otra crisis para 2026 debida al crecimiento brutal pero corto, pero esto será otra cosa). ¡Y también más dinero para los informáticos! O siga, un nuevo efecto Euro, aunque en menor escala.

Para las empresas de desarrollo, incluso las pequeñas, ahora es el momento de contratar y formar personal nuevo para poder hacer frente a la subida el año que viene; efectivamente es una inversión, entonces no es productivo a (muy) corto plazo. Pero los que se dedican a esto deben saber a veces invertir para ¡recoger más ganancias más tarde!

[antoine0]

Empezado por newtron

... quieren es que el fichero donde se guardan los eventos no se pueda manipular pero no dicen cómo hacerlo ni con qué técnicas.

Es que no estás leyendo el documento correcto. Éste es un texto legislativo, que fija el marco dentro del cual actúan los inspectores, entre otras cosas. Dice cosas importantes, como por ejemplo que no hay que certificarse, basta con declaración responsable. El documento técnico que esperas será la orden ministerial (leed la última página).

¿Sería una tontería ir metiendo registros con los textos encriptados en una tabla y luego poner un visor desde el programa para verlo o exportarlo? De esta manera los datos no se podrían tocar pero si visualizar y sería algo relativamente fácil de implementar.

Esto se llama seguridad por la oscuridad, en el mundo de la seguridad y el universitario está muy mal visto, y me imagino que a Hacienda no le hará ninguna gracia.
Hasta yo esperaría en un par de años una consulta vinculante que efectivamente lo prohíba.

Por otro lado, el tema de enviar los datos creo que no es obligatorio, ¿no?

De lo que he leído, no, no lo es. Implica firma electrónica de cada registro, pero los datos se quedan dentro de las empresas. Y deben existir acceso sencillo y rápido a los registros en supuesto de control.

Un compañero mío me hizo remarcar que el objetivo de todo eso es dar a Hacienda un acceso directo a los datos de facturación de las empresas (mismo objetivo general que el S.I.I.)
Leyendo el reglamento con esta visión, hay dos vías: si se suben los registros o se usa la aplicación web de Hacienda, pues los datos de las facturas están en un fichero que gestiona Hacienda, se puede analizar por todos los lados sin demora, objetivo conseguido.
En el otro caso, hay varias provisiones en el texto que demuestran el objetivo de Hacienda: las más claras son el art. 14 de la pág. 16, y pág. 12 art. 8.2 a), 4ª alinea (subrayo yo):

Además, el sistema informático deberá permitir a la Administración tributaria el acceso inmediato y, en su caso, extracción de todos o parte de los datos registrados.

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

Empezado por Zento

Os veo muy pesimistas...

Empezado por ermendalenda

El pesimismo está fundado en que hay mucho trabajo que hacer en relativamente poco tiempo

Yo también os veo pesimistas y "ansiosos"
Hay que esperar, por ahora con lo que hay no se puede hacer nada en la práctica. He intentar hacer algo ahora creo que puede generar una pérdida de tiempo después.

Hay que esperar a que definan y concreten protocolos, formatos de fichero, documentación, ejemplos, entornos de pruebas,...y todo lo necesario para poder implementar esto dentro de las distintas aplicaciones.

En cuanto al tiempo, si es necesario ampliarán plazos como han hecho en el pais vasco. Los colegios profesionales y las asociaciones empresariales, presionaron para que así fuera. Pueden multar a un 2% de las empresas si no llegan a plazo, pero no pueden multar al 30% de las empresas si los plazos no han sido los adecuados.

Paciencia, paciencia, paciencia,...

[antoine0]

Empezado por keys

Los datos no son obligatorio que los envíe el contribuyente, pero entiendo que si es obligatorio que el programa permita realizar el envío. Ya que hacienda le puede solicitar las facturas para una inspección, y eso habrá que hacerlo en el formato que defina hacienda o eso me ha parecido entender.

No me queda claro esta visión. Leo el art. 14 pág. 16 que lo describe, y veo (14.2) que se puede remitir a Hacienda, previo requisición, una copia del backup (definido en 8.2 c), pero suministrarlo en CDROM o llave USB parece perfectamente admisible (además de enviarlo), y no me consta que el formato de esta copia lo define Hacienda (en lo que he leído hasta la fecha, pero hay que esperar el punto c de la orden ministerial al respecto, como me lo hizo remarcar ayer Neftali).
Además, el art. 14.1 permite acceso directo por los inspectores al sistema, pero deja claro que se trata de un control presencial, aquí no hay envíos.

[Casimiro Notevi]

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

Yo también os veo pesimistas y "ansiosos"
Hay que esperar, por ahora con lo que hay no se puede hacer nada en la práctica. He intentar hacer algo ahora creo que puede generar una pérdida de tiempo después.
Hay que esperar a que definan y concreten protocolos, formatos de fichero, documentación, ejemplos, entornos de pruebas,...y todo lo necesario para poder implementar esto dentro de las distintas aplicaciones.
En cuanto al tiempo, si es necesario ampliarán plazos como han hecho en el pais vasco. Los colegios profesionales y las asociaciones empresariales, presionaron para que así fuera. Pueden multar a un 2% de las empresas si no llegan a plazo, pero no pueden multar al 30% de las empresas si los plazos no han sido los adecuados.
Paciencia, paciencia, paciencia,...

[antoine0]

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

Hay que esperar, por ahora con lo que hay no se puede hacer nada en la práctica.

Sí se puede: las empresas que tienen personal listo para hacer de futuros controladores de futuras (y esperadas) certificaciones, y también los programas de «formaciones» colindantes (tipo lo que existe en Francia, ver principio del hilo) deben empezar ya el programa de formación para convertirlos en verdaderos informáticos que sudan código Pascal. ¡Ya!

[antoine0]

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

En cuanto al tiempo, si es necesario ampliarán plazos como han hecho en el pais vasco. Los colegios profesionales y las asociaciones empresariales, presionaron para que así fuera. Pueden multar a un 2% de las empresas si no llegan a plazo, pero no pueden multar al 30% de las empresas si los plazos no han sido los adecuados.

Muy cierto

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

Empezado por Sistel

...proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf

Añado este documento al primer hilo del post, que mantendremos como índice y recopilación de los más importante, como hemos hecho en otros casos.