Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[Sistel]

Hola,

Ya se ha abierto el plazo de presentación de observaciones al 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
La cosa va a traer cola ... para nosotros.

Saludos

[nuevo1234]

Empezado por Sistel

Hola,

Ya se ha abierto el plazo de presentación de observaciones al 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
La cosa va a traer cola ... para nosotros.

Saludos

Gracias por la información.

[ermendalenda]

Empezado por Sistel

Hola,

Ya se ha abierto el plazo de presentación de observaciones al 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
La cosa va a traer cola ... para nosotros.

Saludos

Sí alguien se ha leído las 79 páginas y puede hacer un resumen, se lo agradecería.

[Casimiro Notevi]

Son 19 páginas, no 79
El resumen:

No obstante, los obligados tributarios a que se refiere el
artículo 3.1 de dicho Reglamento deberán tener operativos los
sistemas informáticos adaptados a las características y requisitos
que se establecen en el citado Reglamento y en su normativa de
desarrollo a partir del 1 de enero de 2024

[[newtron]]

Cuñu.... ya podían haber dado algo más de plazo a ver si me daba tiempo a jubilarme.

[antoine0]

Empezado por Casimiro Notevi

Son 19 páginas, no 79
El resumen: los obligados tributarios a que se refiere el artículo 3.1 ... 1 de enero de 2024

Cuidado aquí: es cierto que para los clientes (usuarios finales) la fecha tope sería 2024 (que vendrá muy deprisa). Pero el mismo artículo dice

entrarán en vigor al día siguiente de su publicación en el Boletín Oficial del Estado y resultarán de aplicación para los obligados tributarios a que se refiere el artículo 3.2 del Reglamento en relación con sus actividades de producción y comercialización de los sistemas informáticos.

Y los del artículo 3.2 son los que fabrican y comercializan los sistemas, es decir, los informáticos. Que se supone que son los que leen este foro...

(Vale, es cierto que para los programadores del Open source, no es de aplicación.)

[Casimiro Notevi]

Pero lo mejor es esto

"Los obligados tributarios que ... utilicen sistemas informáticos para el cumplimiento de la obligación de facturación ".
Pues nada, a no usar sistemas informáticos, mejor esto:

[antoine0]

P.6 cáp. VII:

Todo sistema informático que se utilice para dar cumplimiento a las obligaciones contenidas en esta norma debe contar obligatoriamente con una declaración responsable...

Hay que certificar los sistemas, pero cada uno puede hacer lo suyo.

p.8 DF3ª

El presente Real Decreto y el Reglamento anexo entrarán en vigor al día siguiente de su publicación en el Boletín Oficial del Estado

O siga, hay que considerar que este documento de «consulta pública» es realmente exponer lo que será aplicable a los desarrolladores informáticos a los dos días de la aprobación. Ese día, los antiguos sistemas, no conformes, serán ilegales a la venta e instalación.

El mismo articulo sigue con

No obstante, los obligados tributarios a que se refiere el artículo 3.1 de dicho Reglamento deberán tener operativos los sistemas informáticos adaptados a las características y requisitos que se establecen en el citado Reglamento y en su normativa de desarrollo a partir del 1 de enero de 2024

Para los clientes, hay tiempo hasta 2024. Tenemos un año y medio para desarrollar y poner en marcha sistemas nuevos de facturación. Una nueva versión del Año 2000 + euro.

p.9 art.3.1

El presente Reglamento se aplicará a:... b) Los contribuyentes del Impuesto sobre la Renta de las Personas Físicas que desarrollen actividades económicas.

Todo el mundo está afectado; hasta el vendedor del mercado.

p.11 art.6

Delegación del cumplimiento. 1. Las obligaciones establecidas en este Reglamento a los obligados tributarios del artículo 3.1 podrán cumplirse materialmente por el destinatario de la operación o por un tercero

Los operadores del cloud podrán competir también.

p.11 art.7

Recursos informáticos necesarios para cumplir las obligaciones establecidas en este Reglamento. ... b) La aplicación informática que a tal efecto ponga a disposición la Administración tributaria.

Habrá una aplicación web de Hacienda para el «vendedor del marcado» arriba y demás.

p.11 art.8.1

El sistema informático deberá cumplir ... de forma automatizada: a) ... deberá generar, de forma simultánea o inmediatamente anterior a la expedición de la factura, un registro de facturación de alta. b) El sistema informático deberá tener capacidad de remitir información a la Administración tributaria de forma continuada ...

Se remite información en tiempo real de las facturas a Hacienda.

p.12 art.8.2

a) La integridad e inalterabilidad de los registros de facturación de forma que, una vez registrados los datos de facturación ... Cualquier necesidad de rectificación o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior,

Solo se pueden grabar facturas de una sola vez

Además, el sistema informático deberá permitir a la Administración tributaria el acceso inmediato

Nota mía: esto no es demasiado detallado, yo pienso que va a ser precisado más tarde.

b) La trazabilidad de los registros de facturación, que deberán estar encadenados

(Esta también se veía venir)

art 8.4

4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los sucesos producidos durante su uso, como el arranque y parada del sistema informático, la entrada y salida de usuarios ...

La log debe ser extensa (y encadenada, e inalterable, y se puede consultar por Hacienda, por supuesto).

p.13-14 art.10 Contenido del registro de facturación de alta.
A 1ª vista todo lo que está obligatorio en una factura, más la fecha-hora (timestamp) y las demás cositas informáticas que son de esperar.

p.15 art.11 Generación y contenido del registro de facturación de anulación.
Las anulaciones de facturas están previstas. Aparte.
Nota mía: no he visto menciones de las rectificativas.

p.15 art.12. Huella o «hash» y firma electrónica de los registros de facturación informáticos.

... según las especificaciones que se determinen.

Aún no está claro qué hash usar...

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 ... artículos 15 y 16

+ Firma electrónica, excepto las facturas «verificables» que se remiten automáticamente a Hacienda.
Éste sistema «verificable» no está completamente definido.

Disclaimer: no soy letrado este resumen solo es mi entendimiento a la luz de una 1ª lectura rápida del documento. Por favor léanse el documento por completo si están afectados. No son 79 páginas, solo son 19 y las 4 primeras son muy poco interesantes.

[antoine0]

Empezado por Sistel

Ya se ha abierto el plazo de presentación de observaciones al 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

Primero muchísimas gracias por la información.

El documento (PDF) está fechado del 21/02/2022 12:35:08. Sin embargo, en el texto de la página 7 (parte no normativa), 2º parágrafo, se lee:

El principio de transparencia se ha garantizado mediante la consulta pública previa (que finalizó el pasado mes de enero) ...

No es que me importa presentar observaciones o nada, pero se deduce del texto tal cual que ya está cerrado el plazo de la consulta pública. No estoy muy al tanto de las maneras de la administración Española, pero tengo la idea que pudiera ser un defecto de forma
En realidad la fecha tope es el 14 de marzo de 2022.

La cuestión, al final, es, ¿qué plazo debemos esperar para la presentación del proyecto en Consejo de Ministros y posterior aprobación? (a no ser qué vaya a pasar por la vía parlamentaria previa, pero no lo creo, no se estila hoy en día). ¿Diciembre? ¿Junio/julio de 2022?

[ermendalenda]

Buff, yo veo 2 cosas complicadillas para según que tipo de negocio:
Será obligatorio tener preparado el software para el envío inmediato de las facturas antes o la vez de su generación, espero que no sea obligatorio por que en sistemas lentos o con comunicación lenta (por ejemplo zonas con router de datos por 3g-4g) los clientes se pueden cabrear por una espera indeterminada de varios segundos, si además le añadimos un sistema de facturación centralizado con varios dispositivos generando facturas a la vez y hay que enviarlos en oden fifo.. Buff
Por otro lado el tema de las logs garantizado inviolabilidad etc, que eso nos lo dejan a nosotros, claro ahora en sistemas que no contemplen esa automatización en sus bases de datos búscate la vida y rompete la cabeza y que lo que hagas este dentro de los parámetros que ellos piensan que son inviolables. Por que yo puedo pensar que enviarle los datos a un webservice firmado puede ser suficiente, pero me pongo a pensar la de los logs que se generan según lo que piden y son muchísimos más datos que las facturas.
Los routers van a Petar del calentón y me veo un sin vivir todo el día acojonados con las averias

[antoine0]

Empezado por ermendalenda

Será obligatorio tener preparado el software para el envío inmediato de las facturas antes o la vez de su generación, espero que no sea obligatorio por que en sistemas lentos o con comunicación lenta

Creo que se contemplan dos clases de sistemas:

1. por una parte sistemas con buena conexión, con los cuales se suben los registros en directo a Hacienda; son los que llevan una buena conectividad (en base a las esperanzas de los clientes); estas facturas son las que son «verificables», indicadas con una mención VERIF*FACTU especifica, a las cuales son de aplicación el capítulo III artículos 15 y16
2. por otra parte las facturas donde los registros no se suben de inmediato; entonces no es un problema si tu conexión no te da tiempo a subir las facturas a Hacienda. La contrapartida: estas facturas se tienen que firmar electrónicamente (artículo 12, 2º alinea).
3. además está la aplicación web de Hacienda (que tienen los mismos requisitos de conectividad que las del 1.)

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

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

[PepCat]

Por si alguien le interesa, hay este webimar: https://leyantifraude.com/webinar-3-3-2022/

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

Gracias por el aviso.

[Sistel]

Hola,

Parece que la Agencia Tributaria va a premiar a los clientes que les envíen las facturas recibidas.
(Bastará con que escaneen el código QR de la factura recibida)

https://www.vozpopuli.com/economia_y...uda-pymes.html

Saludos

[oscarperez-1980]

No aplicarían ticket.bai decían juas.... Pues es un calco. Ya me lo avisaron los del país vasco hace 8 meses...
A enviar de forma inmediata toca.


https://www-autonomosyemprendedor-es...803026147.html