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

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

[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

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

[ermendalenda]

Empezado por misteradrian

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.

Teniendoo en cuenta que no sé php y he probado con este comando

$certIssuer = str_replace("ó", "o", $certIssuer);
pero no entiendo por que no funciona, mientras alguien diga por que no va y si siempre vas a firmar con ese tipo de certificados puedes forzar y cambiar esto en el firmador.php:

$certIssuer = implode(', ', array_reverse($certIssuer));
por:
$certIssuer='CN=AC Representacion, OU=CERES, O=FNMT-RCM, C=ES';

[tejano]

Os informamos que a partir del 30 de noviembre se va a habilitar la validación de la licencia en el Entorno real en modo de pruebas (el cual estará disponible hasta el 10 de diciembre de 2021) con el objetivo de que se pueda verificar el correcto funcionamiento de los sistemas de cara a la apertura del Entorno real a partir del 1 de enero de 2022.

Es imprescindible, que de cara al 1 de enero de 2022, tengáis verificados los datos de la licencia a utilizar. Si los datos de la licencia no son correctos, provocará el rechazo de las anotaciones, tanto del alta como de la anulación, del subcapítulo 1.1 del LROE.

Cuando hablamos de los datos de la licencia, nos referimos a los datos del Software de facturación incluido en la Huella TicketBAI:



Todos los campos deben coincidir EXACTAMENTE con los datos proporcionados en el alta realizada en el Registro de Software Garante. Para identificar el Nombre del software con el que fue dado de alta, basta con revisar el documento de notificación enviado, donde aparece junto con la Licencia TicketBAI otorgada y el NIF de la empresa desarrolladora:

[skatologiko]

Buenas, me estoy volviendo loco para añadir todas las líneas de detalle con la librería Chilkat, ya que en Guipuzcoa hay que detallar la factura.
Si utilizo el método UpdatechildContent siempre se me actualiza el mismo IDDetalleFactura ¿Cómo puedo crear diferentes elementos de IDDetalleFactura? He probado con NewChild y NewChild2, pero no cierra el elemento anterior
¿Qué método utilizáis?