Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[yaedev]

___________________________________________________________________

NOTA MODERADOR: Voy a ir modificando este hilo inicial (como hemos hecho en otros casos) para ir recopilando los links, ficheros y asuntos importantes de este hilo, que se prevee que va a ser largo.

Los que estéis interesados en el tema de "La ley antifraude" suscribiros a este hilo para recibir las notificaciones.
os pido que mantengamos este hilo específicamente para este tema.
___________________________________________________________________

Se ha habilitado una nueva sección dentro del FTP del club, donde se irán copiando/almacenando los documentos, para tenerla accesible en cualquier momento. No sólo tiene que ser documentación "oficial", si se cree conveniente que otros documentos, códigos o información pueden ser útiles, también se pueden incorporar (basta con que aviséis a algún moderador o a mi mismo).
https://terawiki.clubdelphi.com/Otro...LeyAntifraude/


LINKS, ENLACES Y DATOS DE INTERES --------------------------------------------------------------------------

• (28/02/2024) Publicado documento con PREGUNTAS y RESPUESTAS del seminario (webminar) sobre VERI*FACTU de Febrero del 2024. Descargable desde la web de hacienda y desde el FTP del club.
• (22/02/2024) Presentaciones realizadas en el seminario del día 11 de febrero de 2024 (PDFs).
• (16/02/2024) Algunas diapositivas importantes de la presentación (webminar) que ha realizado la AEAT para aclarar puntos importantes. En este mensaje están las de caracter general y en este mensaje las de caracter más técnico.
• (15/02/2024) Facturas enviadas por un tercero; Autorización de obligado tributario [PDF]; Acceible en el FTP del Club
• (27/12/2023) Descripción del Servicio Web (v1.0) Documento PDF
• (20/12/2023) Diseños de registro de facturación (v0.5.0) Documento de Excel
• (20/11/2023) Publicación de preguntas y respuestas de la reunión explicativa sobre el "estado proyectos sistema informáticos". Descargar PDF con preguntas y respuestas de la reunión.
• (06/11/2023) Reunión explicativa sobre el "estado proyectos sistema informáticos". Descargar PDF con las diapositivas.
• (27/07/2022)1ª Publicación con datos del Sevicio web, registro de alta y registro de anulación
• (30/06/2022) Página Web (URL) donde se irá publicando la documentación sobre el proyecto VERI*FACTU (AEAT)
• (10/04/2022) Vídeo sobre Lay antifraude; Participan José Borja Tomé (director de Informática de la AEAT y Javier Hurtado Puerta (director del Departamento de Inspección Financiera y Tributaria de la AEAT)
• (01/06/2021) Primera versión del Boletin Oficial de las Cortes Generales (PDF)
• (10/06/2021) Primera versión del Boletin Oficial delEstado (BOE) en PDF
• Enlace a la Certificación NF525
• (22/02/2022) Publicación de documentación preliminar;
  Proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria:
  https://www.hacienda.gob.es/Documentacion/Publico/NormativaDoctrina/Proyectos/21022022-RD-reglamento-digitalizacion.pd
  

SERVICIOS Y ESQUEMAS --------------------------------------------------------------------------

• Definición de servicios (WSDL)
• Definición de tipos comunes (XSD)
• Esquema de las operaciones (Alta y baja) (XSD)
• Esquema de respuesta de las operaciones (Alta y baja) (XSD)

INFORMACION AEAT --------------------------------------------------------------------------
Web de información y publicación de novedades (AEAT)
Buzón de correo para dudas técnicas: verifactu@correo.aeat.es


CALENDARIO --------------------------------------------------------------------------

• (11/10/2021) Entrada en vigor de la ley.

===================================================================


(NOTA del Moderador)
Modifico este primer mensaje y lo "reaprovecho" para crear el resumen del hilo.
A modo de resumen, a este primer mensaje se le irán añadiendo datos a medida que vayan apareciendo.

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

_________________________________________________________________________

NOTA MODERADOR: Voy a aprovechar este segundo mensaje para colocar aquí la recopilación de códigos utiles que van saliendo a lo largo de
este hilo (en sus mensajes) para que estén más accesibles.
__________________________________________________________________________


Generar XML de la Factura

• Generación RegistroFacturacion ALTA y XML para guardar y leer después (primer prototipo).
• https://www.clubdelphi.com/foros/sho...postcount=1077 Primera versión para generar "algo" del XML utilizando SOAP.
• Genear XML de la fectura "a pelo" usando VB 6
• Código para generar encapsulamiento y envio, totalmente funcional para face y faceb2b Realizado en [b]PHP[/
• Código para generar el Registro de Alta y extraer el XML de la factura

...

Firmar XML
...

Calcular el HASH 256
https://www.clubdelphi.com/foros/sho...postcount=1026 (código dll para realizar el cálculo)
https://www.clubdelphi.com/foros/sho...postcount=1479 (código en .NET)

Validación del HASH 256
https://hash.online-convert.com/es/generador-sha256 Web para validar el hash generado

Generar QR
...

Envío del fichero
Utilizando commandos CURL
* Enviar utilizando commandos CURL (primera aproximación)
...


Otros códigos relacionados
Utilizando commandos CURL
* Obtener fecha y hora online (JSON) utilizando commandos CURL

[Casimiro Notevi]

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

Al final pasará como con la factura electrónica.
Cada comunidad la suya (y lo peor, dentro de cada comunidad, cada provincia la suya -como está pasando con TicketBAI- ), con datos distintos, especificaciones distintas,...
Para cada admministración un dineral gastado (que al final lo pagamos nosotros) y para las empresas imposible de asumir.
Se resume en que no hay programas que soporten factura electrónica a nivel nacional, porque es imposible de mantener las N diferentes.
País de pandereta!!!

[yaedev]

Al final se está haciendo muy engorroso desarrollar sistemas de facturación...que pesadez... si lo llego a saber cojo otra área.

A raíz de esta nueva ley, y dado que los desarrolladores también vamos a ser presuntos culpables, habrá que ir con lupa que acciones hay que restringir o no en el software.

¿En vuestro software permitís que se puedan modificar y eliminar facturas o tickets? En la mayoría de software te dejan modificar y eliminar, a ver porque esta acción no tiene porque ser siempre con finalidad fraudulenta. Sino algo tan simple que cuando revisas la factura antes de enviarla, te das cuenta que está mal. No vas a hacer una rectificativa si aún no la has entregado a nadie...Pues al menos tienes la opción de editarla o eliminarla (cuando te sale más a cuenta crearla otra vez desde cero).

El software cuando ya no debería de dejar eliminar o modificar la factura o ticket: ¿Cuándo ya le has dado a "guardar nueva factura" o "guardar nuevo ticket"?

[Casimiro Notevi]

Es que por mucho que quieran controlar, no va a servir para nada, porque siempre habrá alguna forma de "bordear" ese control.

Es lo mismo que con los controles "antipiratería", no sirven para nada, y el único al que fastidia es al que ha comprado legalmente.

[mamcx]

Empezado por yaedev

¿En vuestro software permitís que se puedan modificar y eliminar facturas o tickets? En la mayoría de software te dejan modificar y eliminar, a ver porque esta acción no tiene porque ser siempre con finalidad fraudulenta. Sino algo tan simple que cuando revisas la factura antes de enviarla, te das cuenta que está mal. No vas a hacer una rectificativa si aún no la has entregado a nadie...Pues al menos tienes la opción de editarla o eliminarla (cuando te sale más a cuenta crearla otra vez desde cero).

Aqui en Colombia el tema de la factura es casi asi de complicado. Una vez hecho un documento, no se puede deshacer, solo enmendar. Tambien porque una vez emitido una numeracion no se puede reusar.

Como lo hago? Tengo un esquema de "estado del documento" maso:

Código Delphi [-]
enum DocStatus
    Draft
    Pending
    Processed

Mientras esta en "Draft" el usuario puede hacer lo que quiera. "Pending" esta por confirmarse y desde aqui no se puede alterar o modificar.

Esto funciona muy bien y a los usuarios les gusta el icono con colores que identifica el estado.

[PepCat]

El poder modificar facturas (al menos en España) es una “mala costumbre” que llegamos arrastrando desde los inicios de los primeros programas de gestión y que muchas empresas siguen mentalizadas en que esta opción es imprescindible.

Hace unos años tuve una experiencia muy curiosa sobre este tema. En una empresa usaban un ERP que yo había desarrollado, este ERP permitía modificar y anular facturas y de igual forma los asientos contables se permitían modificar y/o anular. Para el jefe financiero y el resto de personal administrativo estas posibilidades eran imprescindibles y no quería renunciar de ninguna forma.

Esta empresa creció y fue adquirida por una multinacional que rápidamente sustituyo el antiguo ERP por el suyo. El nuevo ERP no permitía realizar ninguna modificación ni en facturas ni en contabilidad. Es decir, cada vez que había un error en una factura se hacia una de abono y se generaba una nueva (y esto ocurría varias veces al día) todo esto generaba muchísimo ruido contable, pues bien, al principio el director financiero no le gusto, pero al cabo de un par de meses se acostumbraron sin ningún problema. Es más, el director financiero se convenció que este sistema era mucho mejor que el anterior sistema, porque de esta forma, todo quedaba registrado.

¿Os imagináis la cantidad de problemas que los desarrolladores nos ahorraríamos si nuestros programas no permitiesen retroceder las facturas?

Por otra parte, si se quiere evitar el fraude, ¿porque no pasar todas las empresas al SII?

El SII es un sistema que ya está desarrollado, funcionando y totalmente probado, además como la mayoría de nuestros ERP’s ya están preparados para el SII, la transición no sería tan traumática (al menos para nosotros).

[yaedev]

He estado echando un vistazo de lo que se cuece en otros países de la UE, y sí, hay algunos que llevan haciéndolo hace tiempo. Por lo que se ve en España, tarde y mal como siempre.....En el caso de Francia, por lo que he leído en alguna web, el software tiene que cumplir los requisitos y estar certificado. Mirando los precios de la certificación no es nada barato! (que si 800€ por no se qué, que si suma 600€ por no se cuantos, que si consultas a 200€/hora ) Este es el punto que más miedo me da, que nos crujan con las certificaciones y las auditorías para poder ser un "fabricante de software legal". Y según tengo entendido, cada vez que actualizas debes pasar la certificación de nuevo....Para los pequeños programas de facturación o gestión (sin contabilidad ni nada) y sin mantenimientos obligatorios, no sé hasta que punto nos va a ser viable seguir...

Luego el tema de los programas que hemos creado a medida a autónomos, tiendas o microempresas, ya verás tú cuanto tengas que decir que tendrá que desembolsar una pasta para adaptarlo y poder seguir usando su software a medida. ¿Y el tiempo humano para poder adaptarlos todos?

Por otra parte, si se quiere evitar el fraude, ¿porque no pasar todas las empresas al SII?

Claro. Lo lógico sería eso. Un único sistema antifraude, no doscientos mil....

En Francia creo que es un único también. Al igual que Portugal, como comenta casimiro....

[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