TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[elcharlie]

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

Si os parece bien, podemos ir recopilando links, documentación, enlaces,... y las podemos ir añadiendo al mensaje #1 del hilo, para que estén disponibles de forma fácil.

Pues estaría genial, porqué yo tengo que empezar de ya!

[tejano]

Hola, alguien sabe cuando tardan en decir si el registro del Software Garante es correcto o hay que añadir más documentación?
Desde el día 1 de Junio que lo mande de nuevo la documentación a la DFB , todavía no nos han contestado. Me gustaría tenerlo antes de irme de vacaciones para estar más relajado.
Graciasssss

[luismartin]

Empezado por tejano

Hola, alguien sabe cuando tardan en decir si el registro del Software Garante es correcto o hay que añadir más documentación?
Desde el día 1 de Junio que lo mande de nuevo la documentación a la DFB , todavía no nos han contestado. Me gustaría tenerlo antes de irme de vacaciones para estar más relajado.
Graciasssss

Hola tejano. Si te refieres a registrar vuestra empresa y software en la DFB para la emisión de facturas por el sistema TBAI, yo no hice esa gestión, lo hizo mi jefa, pero te puedo decir que no le costó apenas tiempo en que nos incluyeran. Yo insistiría porque 15 días sin contestación me parece mucho.

[tejano]

Empezado por luismartin

Hola tejano. Si te refieres a registrar vuestra empresa y software en la DFB para la emisión de facturas por el sistema TBAI, yo no hice esa gestión, lo hizo mi jefa, pero te puedo decir que no le costó apenas tiempo en que nos incluyeran. Yo insistiría porque 15 días sin contestación me parece mucho.

Gracias Luismartin, a ver si hay suerte y me dicen algo en breve, porque me imagino que andarán con bastante trabajo.

[tejano]

Hola!!!! No sé si os ha pasado a alguien, a la hora de generar el link o código QR, si la firma en sus 13 primeros caracteres tiene símbolos como "-", "+", ..... da error el link

Como por ejemplo

https://batuz.eus/QRTBAI/?id=TBAI-A4...3207.07&cr=216

Podéis decirme si os ha pasado al alguno? Ya no sé si es problema del programa o lo es del entorno de pruebas.

Gracias

[Sistel]

Empezado por tejano

Hola!!!! No sé si os ha pasado a alguien, a la hora de generar el link o código QR, si la firma en sus 13 primeros caracteres tiene símbolos como "-", "+", ..... da error el link

Como por ejemplo

https://batuz.eus/QRTBAI/?id=TBAI-A4...3207.07&cr=216

Podéis decirme si os ha pasado al alguno? Ya no sé si es problema del programa o lo es del entorno de pruebas.

Gracias

Hola tejano,

Ese tema ya se trató en este hilo.
Mira en la página 32 y sucesivas

Saludos

[tejano]

Empezado por Sistel

Hola tejano,

Ese tema ya se trató en este hilo.
Mira en la página 32 y sucesivas

Saludos

Muchas gracias Sistel, cambiado, probado y funciona bien como indicas.

Gracias

[luismartin]

Buenos días. Conseguido funcionamiento en entorno de pruebas de Gipuzkoa.

Ahora estoy peleándome con Batuz y el LROE (Bizkaia). Pero sólo obtengo errores 400 del servidor. No consigo que acepte las peticiones. ¿ Alguien sabría decirme el por qué? Creo seguir las especificaciones.

Para los de PHP (aunque no creo que sea difícil de entender por otros). Este es el código de la petición, a ver si alguien ha pasado por este trance ya:

Código PHP:

    // codificamos a gzip la cadena XML del LROE, 
    // la cual contiene a su vezl el XML del TicketBAI codificado en base64, conforme a las especificaciones
    $gzipStr = gzencode($xmlStr);

    $cabeceras = array(
        'Accept-Encoding: gzip',
        'Content-Encoding: gzip',
        'Content-Length: ' . mb_strlen($gzipStr),
        'Content-Type:  application/octet-stream',
        'eus-bizkaia-n3-version: 1.0.',
        'eus-bizkaia-n3-content-type: application/xml',
        'eus-bizkaia-n3-data:  {"con": "LROE", "apa": "1.1", "inte": {"nif": "' .
        $nif . '","nrs":"' .
        $nombre . '"},"drs": {"mode": "240","ejer": "' . $ejercicio . '"}}',
    );
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_POST, 1);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');
    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
    $resp = curl_exec($ch); 


Vi un post en la web de Batuz indicando que ayer día 17, el entorno de pruebas no estaba operativo, con lo cual, di por sentado que era eso. Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.

No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

[tejano]

Empezado por luismartin

Buenos días. Conseguido funcionamiento en entorno de pruebas de Gipuzkoa.

Ahora estoy peleándome con Batuz y el LROE (Bizkaia). Pero sólo obtengo errores 400 del servidor. No consigo que acepte las peticiones. ¿ Alguien sabría decirme el por qué? Creo seguir las especificaciones.

Para los de PHP (aunque no creo que sea difícil de entender por otros). Este es el código de la petición, a ver si alguien ha pasado por este trance ya:

Código PHP:

    // codificamos a gzip la cadena XML del LROE, 
    // la cual contiene a su vezl el XML del TicketBAI codificado en base64, conforme a las especificaciones
    $gzipStr = gzencode($xmlStr);

    $cabeceras = array(
        'Accept-Encoding: gzip',
        'Content-Encoding: gzip',
        'Content-Length: ' . mb_strlen($gzipStr),
        'Content-Type:  application/octet-stream',
        'eus-bizkaia-n3-version: 1.0.',
        'eus-bizkaia-n3-content-type: application/xml',
        'eus-bizkaia-n3-data:  {"con": "LROE", "apa": "1.1", "inte": {"nif": "' .
        $nif . '","nrs":"' .
        $nombre . '"},"drs": {"mode": "240","ejer": "' . $ejercicio . '"}}',
    );
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_POST, 1);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');
    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
    $resp = curl_exec($ch); 


Vi un post en la web de Batuz indicando que ayer día 17, el entorno de pruebas no estaba operativo, con lo cual, di por sentado que era eso. Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.

No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

A ver si te sirve como lo envío yo

curl --insecure --cert-type P12 --cert nombre_certificado:contraseña_certificado -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"CIF\",\"nrs\":\"NOMBRE_EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary "@c:\tmp\consulta.gz" --output c:\tmp\respuesta.gz -D c:\tmp\cabecera.txt

y me funciona bien, comprimo con el 7z

Saludos

[luismartin]

Empezado por tejano

A ver si te sirve como lo envío yo

curl --insecure --cert-type P12 --cert nombre_certificado:contraseña_certificado -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"CIF\",\"nrs\":\"NOMBRE_EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary "@c:\tmp\consulta.gz" --output c:\tmp\respuesta.gz -D c:\tmp\cabecera.txt

y me funciona bien, comprimo con el 7z

Saludos

Hola tejano. He intentado la prueba por línea de comandos, teniendo ya generado el gzip, en un fichero llamado lroe_1624012540.gz, pero me da problemas . Por lo visto, algo del certificado, pero parece más cosa del certificado del servidor (lógicamente, he ocultado datos sensibles):

$ curl --insecure --cert-type P12 --cacert cert_certFNMTEmpresa.pfx --pass contraseña -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"BXXXXXXXX\",\"nrs\":\"NOMBRE EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary lroe_1624012540.gz --output respuesta.gz -D cabeceras_respuesta.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 80.245.2.232...
* TCP_NODELAY set
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to pruesarrerak.bizkaia.eus (80.245.2.232) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* error setting certificate verify locations, continuing anyway:
*   CAfile: cert_certFNMTEmpresa.pfx
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4450 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [527 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [134 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: jurisdictionC=ES; jurisdictionST=BIZKAIA; jurisdictionL=BILBAO; businessCategory=Government Entity; postalCode=48009; C=ES; ST=BIZKAIA; L=BILBAO; street=GRAN V�A 25; O=BIZKAIKO FORU ALDUNDIA - DIPUTACION FORAL DE BIZKAIA; OU=IT; serialNumber=P4800000D; CN=pruesarrerak.bizkaia.eus
*  start date: Jul  3 12:41:06 2020 GMT
*  expire date: Jul  3 12:41:06 2022 GMT
*  issuer: C=ES; O=IZENPE S.A.; OU=BZ Ziurtagiri publikoa - Certificado publico EV; CN=CA de Certificados SSL EV
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
} [5 bytes data]
> POST /N3B4001M/kontsulta HTTP/1.1
> Host: pruesarrerak.bizkaia.eus
> User-Agent: curl/7.64.0
> Accept: */*
> Accept-Encoding:gzip
> Content-Encoding:gzip
> Content-Type:application/octet-stream
> eus-bizkaia-n3-version:1.0
> eus-bizkaia-n3-content-type:application/xml
> eus-bizkaia-n3-data:{"con":"LROE","apa":"1.1","inte":{"nif":"BXXXXXXXX","nrs":"NOMBRE EMPRESA"},"drs" :{"mode":"240","ejer":"2021"}}
> Content-Length: 18
> 
} [18 bytes data]
* upload completely sent off: 18 out of 18 bytes
* OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104
100    18    0     0  100    18      0     68 --:--:-- --:--:-- --:--:--    68
* Closing connection 0
curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104

Como decía, lroe_1624012540.gz es donde tengo el gzip conteniendo el XML del LROE (que a su vez contiene la factura TBAI)

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

Empezado por luismartin

...Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.
No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

Igual que envías datos en la cabecera de la petición, en la respuesta también llega información en los datos de cabecera.
¿Puedes poner esa cabecera?

Puede ser algo como esto, por ejemplo:

eus-bizkaia-n3-numero-registro=
eus-bizkaia-n3-tipo-respuesta=Incorrecto
Keep-Alive=timeout=5, max=100
X-Powered-By=Undertow/1
eus-bizkaia-n3-mensaje-respuesta=Todos los registros incluidos en la petición son incorrectos.
eus-bizkaia-n3-codigo-respuesta=B4_1000002
Connection=Keep-Alive
Content-Encoding=gzip
Content-Length=8332
Date=Tue, 25 May 2021 08:17:36 GMT
Content-Type=application/xml;charset=UTF-8
eus-bizkaia-n3-identificativo=94716

[Sistel]

Empezado por luismartin

...

Código PHP:

    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_POST, 1);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');
    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
    $resp = curl_exec($ch); 


Hola luismartin,

Yo también lo hago con PHP, siguiendo, prácticamente, el mismo modelo que presentó en este hilo el colega Bilbur.

Las únicas diferencias que encuentro es que yo no utilizo ninguna de estas dos líneas:

Código PHP:

    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1); 


CURLOPT_SSLKEYPASSWD - Si tienes el certificado convertido a PEM, no necesitas password alguna.
CURLOPT_SSL_VERIFYPEER - Ya está, por defecto en TRUE desde la versión 7.10 de Curl

Saludos

[misteradrian]

Hola de nuevo señoras y señores,
lo primero de todo muchas gracias por toda la información subida a este foro, con mención especial a bilbur por todo el tema del firmador en php, que me ha venido genial.

Y precisamente al utilizar este firmador me da una serie de fallos a la hora de dar de altas facturas que quisiera corregir.

A la hora de enviar las facturas me da el siguiente aviso.
008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#xmldsig-ea406c2f-bf64-e988-ed62-0b8afb482297-signedprops" failed to verify. [src/xml2signatureobj.cpp(315)]

y comprobando el xml con la herramienta de chillkat, me dice lo siguiente:

Signature Verified
Number of Reference Digests = 3
Reference 1 digest is invalid because the computed digest differs from the digest in the XML.
Reference 2 digest is valid.
Reference 3 digest is valid.

Qué casualmente coincide con el mismo campo de la respuesta de Gipuzkoa.
Supongo que viene dado por el valor de la variable,

Código PHP:

$this->SignedProperties 


que a su vez llama al generateGUID de el XMLTools de bilbur.

Código PHP:

$this->signatureID             = $tools->generateGUID('xmldsig-'); 


Pero revisando el foro no he sacado nada en claro sobre qué probar para modificar este error.
Supongo que tendré que modificar este XMLTools y generar un valor de digest válido, la cosa es que no sé cual.

Un saludo y gracias de antemano.

[misteradrian]

Empezado por misteradrian

Hola de nuevo señoras y señores,
lo primero de todo muchas gracias por toda la información subida a este foro, con mención especial a bilbur por todo el tema del firmador en php, que me ha venido genial.

Y precisamente al utilizar este firmador me da una serie de fallos a la hora de dar de altas facturas que quisiera corregir.

A la hora de enviar las facturas me da el siguiente aviso.
008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#xmldsig-ea406c2f-bf64-e988-ed62-0b8afb482297-signedprops" failed to verify. [src/xml2signatureobj.cpp(315)]

y comprobando el xml con la herramienta de chillkat, me dice lo siguiente:

Signature Verified
Number of Reference Digests = 3
Reference 1 digest is invalid because the computed digest differs from the digest in the XML.
Reference 2 digest is valid.
Reference 3 digest is valid.

Qué casualmente coincide con el mismo campo de la respuesta de Gipuzkoa.
Supongo que viene dado por el valor de la variable,

Código PHP:

$this->SignedProperties 


que a su vez llama al generateGUID de el XMLTools de bilbur.

Código PHP:

$this->signatureID             = $tools->generateGUID('xmldsig-'); 


Pero revisando el foro no he sacado nada en claro sobre qué probar para modificar este error.
Supongo que tendré que modificar este XMLTools y generar un valor de digest válido, la cosa es que no sé cual.

Un saludo y gracias de antemano.

Vale señor@s, me respondo a mí mismo por si a alguien le sirve.

He revisado de nuevo de arriba a abajo el foro y he encontrado el error. (Otra cosa es solucionarlo)

El error viene en concreto de un campo dentro de la firma

<ds:X509IssuerName>CN=AC Representación,  OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El certificado es un certificado de la FNMT y en el campo CN, la palabra Representación es la que me da errores a la hora de verificar el xml por chillkat, por la tilde en la ó.

Supongo que tendré que encontrar la manera de codificarlo de manera correcta en php, ya que tengo puesto el visual studio code a ISO 8859-1 y ticketbai lo requiere en utf-8.

Si corregís esta tílde a la hora de pasarlo a chillkat no os da ningún error y los 3 digest son válidos.

Un saludo y espero que sirva a los nuevos que venís con esto.

[ermendalenda]

Empezado por misteradrian

Vale señor@s, me respondo a mí mismo por si a alguien le sirve.

He revisado de nuevo de arriba a abajo el foro y he encontrado el error. (Otra cosa es solucionarlo)

El error viene en concreto de un campo dentro de la firma

<ds:X509IssuerName>CN=AC Representación,  OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El certificado es un certificado de la FNMT y en el campo CN, la palabra Representación es la que me da errores a la hora de verificar el xml por chillkat, por la tilde en la ó.

Supongo que tendré que encontrar la manera de codificarlo de manera correcta en php, ya que tengo puesto el visual studio code a ISO 8859-1 y ticketbai lo requiere en utf-8.

Si corregís esta tílde a la hora de pasarlo a chillkat no os da ningún error y los 3 digest son válidos.

Un saludo y espero que sirva a los nuevos que venís con esto.

Buenas, yo uso firmador.php y tengo ese acento y no me da problemas
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Chilkat valid en los 3 digest y sin errores al enviar.
Es extraño lo que dices, ya somos muchos los que lo usamos y hubiera dado más problemas.
Lo único que veo diferente es que entre la "," y "OU" (", OU=CERES") tienes 2 espacios, no creo que sea problema.
Tienes el XML con esta cabecera?
<?xml version="1.0" encoding="UTF-8"?>

[misteradrian]

Empezado por ermendalenda

Buenas, yo uso firmador.php y tengo ese acento y no me da problemas
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Chilkat valid en los 3 digest y sin errores al enviar.
Es extraño lo que dices, ya somos muchos los que lo usamos y hubiera dado más problemas.
Lo único que veo diferente es que entre la "," y "OU" (", OU=CERES") tienes 2 espacios, no creo que sea problema.
Tienes el XML con esta cabecera?
<?xml version="1.0" encoding="UTF-8"?>

Hola de nuevo lo primero de todo gracias por tu contestación.
Quizás no me expresé del todo bien. Efectivamente el firmador es una maravilla y funciona correctamente.
El caso es que yo tengo puesto mi editor de textos y los datos que obtengo en la base de datos en ISO8859-1 y el envío los requiere siempre en UTF-8.
Entonces cuando hay tildes se me transforman a caracteres extraños (Pasa lo mismo si en cualquier campo como el nombre lleva alguna tilde).
Y pues cuando lo visualizo y lo paso a chillkat o lo envío para ticketbai Gipuzkoa , los errores de la firma venían derivados de esos caracteres extraños por la codificación derivadas de las tildes.
Resumiendo, problemas de derivados de codifcación.

Lo único me ha surgido una duda nueva a ver si alguien me la puede responder.
¿La variable digest dentro del nuevo array POLITICA_FIRMA_ALAVA como lo puedo calcular?

Un saludo y mil gracias de nuevo de verdad,
sin este foro no podría estar tirando este proyecto hacia delante.

[elcharlie]

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

[edari]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente, pero por si acaso, ¿habéis probado vosotros si os funciona bien?

Mismo caso que tú

[sEngine]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

a mi tampoco me va, mismo error

[adolphsys]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

Yo tampoco puedo comprobar facturas en Araba, también me da parámetros incorrectos...