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

[aar1]

Buenos días.

Estoy utilizando ChilKat para firmar el XML del TicketBai y como certificado digital uno de los certificados de PRODUCCIÓN de IZENPE. Al enviar el fichero XML al entorno de pruebas de Gipuzkoa el fichero es aceptado pero me devuelve el código 008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)

No sé si a alguno de vosotros os ha pasado lo mismo y si esto se debe al certificado digital que estoy utilizando.

Un saludo.

[bilbur]

Recibo mismo error 008


Firma y envío con PHP (en procesos separados)



Certificado FNMT


Investigaré y si encuentro "algo" lo comentaré aquí


Un saludo

[Galaxian]

Empezado por bilbur

Recibo mismo error 008


Firma y envío con PHP (en procesos separados)


Certificado FNMT


Investigaré y si encuentro "algo" lo comentaré aquí


Un saludo

Supongo que te ha pasado lo mismo que a mi y a aar1: que en vez de cargar el archivo XML se ha usado la función getAsString para obtener el XML firmado y enviarlo a batuz, pero hay una cosa que se debe tener en cuenta, y es que la cadena obtenida es ASCII, por lo que justo antes de la llamada a getAsString hay que usar put_Utf(true) para que la genere en UTF-8 o bien convertir el XML ASCII a UTF-8 antes de enviarlo.

[aar1]

Buenos días.

Problema solucionado, era por la codificación al enviar el XML firmado, hay que convertirlo a formato utf-8 antes de enviarlo al entorno de pruebas.

Chilkat dispone del objeto StringBuilder que contiene el método LoadFile y permite indicar el charset.

Muchas gracias por la ayuda.

[aar1]

Hola a todos.

Ahora estoy haciendo pruebas para enviar el documento LROE y me devuelve el error B4_1000002, Todos los registros incluidos en la petición son incorrectos.

He revisado la codificación de la información que se envía y está en utf-8.

Un saludo.

[Galaxian]

Empezado por aar1

Hola a todos.

Ahora estoy haciendo pruebas para enviar el documento LROE y me devuelve el error B4_1000002, Todos los registros incluidos en la petición son incorrectos.

He revisado la codificación de la información que se envía y está en utf-8.

Un saludo.

En el XML devuelto tienes la información de qué es lo que ha pasado. Ten en cuenta que está comprimido.

Para obtenerlo no puedes hacer un 'FullRequest...', ya que esas funciones no están pensadas para respuestas binarias sino JSON o XML, por lo que hay que hacer una petición por partes (por claridad he quitado el control de errores):

rest.SendReqStringBody("POST","/N3B4000M/aurkezpena",dat);
rest.ReadResponseHeader();

const char *cr=rest.responseHeader(); // Cabeceras

CkByteData rb;
rest.ReadRespBodyBinary(rb); // Cuerpo (aquí es donde está el XML comprimido)
const uchar *db64=rb.getEncoded("base64");

Ahora ya tienes el XML comprimido en base64, por lo que solo queda decodificar y descomprimir.

[aar1]

Muchas gracias Galaxian.

He conseguido leer el archivo XML que se envía de respuesta en el body y así poder corregir los errores que tenía en la generación del Ticket Bai.

Ahora ya obtengo la respuesta "correcto" por parte del entorno de pruebas de Bizkaia.

Un saludo.

[bilbur]

Empezado por Galaxian

Supongo que te ha pasado lo mismo que a mi y a aar1: que en vez de cargar el archivo XML se ha usado la función getAsString para obtener el XML firmado y enviarlo a batuz, pero hay una cosa que se debe tener en cuenta, y es que la cadena obtenida es ASCII, por lo que justo antes de la llamada a getAsString hay que usar put_Utf(true) para que la genere en UTF-8 o bien convertir el XML ASCII a UTF-8 antes de enviarlo.

Por fin he conseguido enviar a Guipuzcoa en pruebas facturas firmadas y recibir respuesta correcta.


En mi caso se trataba de firma mal realizada por no respetar el esquema XAdES/XMLDSI, por lo que he modificado mi esquema (el orden de los "<ds:Reference") y ya funciona bien.


Utilizo dos validadores de firma online:


http://tools.chilkat.io/xmlDsigVerify.cshtml


https://web.uanataca.com/pe/servicio...ma-electronica


El primero y previo a los cambios en mi esquema, el de chlikat me daba este resultado
Signature Verified
Number of Reference Digests = 3
Reference 1 digest is valid.
Reference 2 digest is valid.
Reference 3 digest is valid.
Pero era rechazado por Guipuzcoa


El segundo, uanataca, me daba el error de no respetar el esquema.


Ahora ya da correcto en los dos validadores y en el envío a Guipuzcoa


Pongo esto porque me fiaba (y me fio aunque un poco menos) de chlikat y pensando que el xml firmado era correcto buscaba corregir errores donde no correspondía.


Cuando vaya avanzando un poco más, si a alguien le interesa, subiré lo que estoy desarrolando en PHP (sin dependencia de terceros ni para generar el xml, firmar ni enviar)


Un saludo a todos

[Galaxian]

Empezado por bilbur

Por fin he conseguido enviar a Guipuzcoa en pruebas facturas firmadas y recibir respuesta correcta.


En mi caso se trataba de firma mal realizada por no respetar el esquema XAdES/XMLDSI, por lo que he modificado mi esquema (el orden de los "<ds:Reference") y ya funciona bien.


Utilizo dos validadores de firma online:


http://tools.chilkat.io/xmlDsigVerify.cshtml


https://web.uanataca.com/pe/servicio...ma-electronica


El primero y previo a los cambios en mi esquema, el de chlikat me daba este resultado
Signature Verified
Number of Reference Digests = 3
Reference 1 digest is valid.
Reference 2 digest is valid.
Reference 3 digest is valid.
Pero era rechazado por Guipuzcoa


El segundo, uanataca, me daba el error de no respetar el esquema.


Ahora ya da correcto en los dos validadores y en el envío a Guipuzcoa


Pongo esto porque me fiaba (y me fio aunque un poco menos) de chlikat y pensando que el xml firmado era correcto buscaba corregir errores donde no correspondía.


Cuando vaya avanzando un poco más, si a alguien le interesa, subiré lo que estoy desarrolando en PHP (sin dependencia de terceros ni para generar el xml, firmar ni enviar)


Un saludo a todos

Para que la librería Chilkat genere una firma válida hay que hacer una pequeña corrección:

put_Behaviors("IndentedSignature,TransformSignatureXPath,ForceAddEnvelopedSignatureTransform,LocalSigningTime")

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

El día 26 de Marzo de este año se hicieron unas jornadas informativas para desarrolladores con el título:
"Especificaciones técnicas y funcionales del software TicketBAI".

El material (las presentaciones) y la grabación de la presentación específica para desarrolladores (de un poco más de una hora) ya están disponibles.
Por si alguien no tiene acceso a ellas, las subo al FTP y actualizo el primer mensaje.
http://terawiki.clubdelphi.com/Otros...n%20TicketBAI/

Son los PPTX de las presentaciones (español y euskera) y la grabación de Teams de la reunión.

[Galaxian]

He probado la estructura de la firma generada por Chilkak con el validador de ETSI (el más fiable por razones obvias), y el resultado es que cumple al 100% las especificaciones ETSI TS 101 903 v1.4.2

https://signatures-conformance-checker.etsi.org (es gratis pero necesita registro).

Ahí queda eso.

[Sistel]

Empezado por bilbur

Cuando vaya avanzando un poco más, si a alguien le interesa, subiré lo que estoy desarrolando en PHP (sin dependencia de terceros ni para generar el xml, firmar ni enviar)

Hola Bilbur.

Yo también trabajo en PHP y me interesa controlar todo el proceso (generación, firma y envío) dependiendo lo menos posible de librerías ajenas.
Cualquier información sobre el tema, me interesa.

Gracias

[bilbur]

Empezado por Sistel

Hola Bilbur.

Yo también trabajo en PHP y me interesa controlar todo el proceso (generación, firma y envío) dependiendo lo menos posible de librerías ajenas.
Cualquier información sobre el tema, me interesa.

Gracias

Hasta hoy tengo completo TBAI GIP


Genero xml
Firmo xml
Envio xml firmado a Gipuzkoa (curl php)

Todo OK

Ahora estoy con TBAI BIZ

Genero y firmo igual que TBAI GIP es lógico
No consigo envia a BIZ con curl php (llevo días sin avanzar nada)


Si te interesa, vamos por partes y probando lo que finciona

[Sistel]

Empezado por bilbur

...
Ahora estoy con TBAI BIZ
Genero y firmo igual que TBAI GIP es lógico
No consigo envia a BIZ con curl php (llevo días sin avanzar nada)
...

Hola Bilbur

¿Obtienes alguna respuesta al php-curl que lanzas?

Cuando, en su día, desarrollé el módulo de SII, tuve problemas con el php-curl.
Sin embargo me iba bien si lo lanzaba mediante shell_exec("curl --connect-timeout ...")
Así que lo dejé de esa manera.

Saludos

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

Empezado por bilbur

Ahora estoy con TBAI BIZ
Genero y firmo igual que TBAI GIP es lógico
No consigo envia a BIZ con curl php (llevo días sin avanzar nada)

Yo os diría que realizarais pruebas con Postman, por ejemplo, para probar las diferentes partes del proceso.
Por ejemplo, se pueden configurar los parámetros de cabecera, el certificado de envío y enviar uno de los ficheros de ejemplo de BATUZ; Con eso ya podréis obtener una respuesta como esta:



Que ya son códigos de error y respuesta de BATUZ.
A partir de ahí se trata de ir centrándose en otros aspectos.

Modificar el fichero de ejemplo, por uno de los vuestros, y de ahí en adelante.

En el caso del ejemplo el problema del certificado (Interesado no identificado), porque la gente de BATUZ no admite certificados de prueba como si se hare en TicketBAI (**NOTA**, por si alguien lo está haciendo así que lo tenga en cuenta...)

Para la parte del JSON, también podéis utilizar uno de ejemplo que se puede descargar de aquí y modificarlo lévemente.

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

Empezado por aar1

pero me devuelve el código 008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)

No sé si a alguno de vosotros os ha pasado lo mismo y si esto se debe al certificado digital que estoy utilizando.

Nosotros hemos tenido este error.
Es debido (al menos en nuetro caso) a problemas en la codificación.
Normalmente en el paso entre la firma del XML y el envío.

Revisad si el contenido de lo que habéis firmado (justo después de firmar) es lo mismo que estáis enviando. Sobre todo revisad si en la razón social o en alguno de las cadenas que enviáis hay caracteres extraños (con acentos, tildes,...).

A veces el resultado del envío lo grabamos en fichero o trabajamos con Streams y sin darnos cuenta la codificación cambia. Revisad entre UTF8, UTF8 BOM y ANSI.

Revisad por ejemplo si estáis utilizando Streams, que la clase TStream en la creación posee opciones de codificación.

Al final nosotros acabamos comparando el contenido en cada paso (Editor Hexadecimal) y nos dimos cuenta de que el character Ó (de la razón social) al realizar la firma con los SBB se estaba cambiando (cofidicación implícita).

NOTA: Ahora estoy probando con esta empresa... .

[ARPE1]

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

Nosotros hemos tenido este error.
Es debido (al menos en nuetro caso) a problemas en la codificación.
Normalmente en el paso entre la firma del XML y el envío.

Revisad si el contenido de lo que habéis firmado (justo después de firmar) es lo mismo que estáis enviando. Sobre todo revisad si en la razón social o en alguno de las cadenas que enviáis hay caracteres extraños (con acentos, tildes,...).

A veces el resultado del envío lo grabamos en fichero o trabajamos con Streams y sin darnos cuenta la codificación cambia. Revisad entre UTF8, UTF8 BOM y ANSI.

Revisad por ejemplo si estáis utilizando Streams, que la clase TStream en la creación posee opciones de codificación.

Al final nosotros acabamos comparando el contenido en cada paso (Editor Hexadecimal) y nos dimos cuenta de que el character Ó (de la razón social) al realizar la firma con los SBB se estaba cambiando (cofidicación implícita).

NOTA: Ahora estoy probando con esta empresa... .

Hola, estamos intentando enviar el fichero a Guipúzcoa y no hay manera. La factura la graba en el sistema, ya que si volvemos a enviar el mismo fichero nos devuelve que ya está registrada. Pero la primera vez nos retorna error con el siguiente mensaje: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)"
Toda la pinta tiene que es por lo que indicas arriba ya que si enviamos el mismo fichero con la aplicación SOAPUI todo es correcto. Usamos los componentes INDY (versión 10.6) que trae delphi (versión 10.2) para hacer el envío. Al final ¿con qué componentes o de qué manera haces el envío para que no modifique el fichero en el proceso?

Gracias de antemano

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

Empezado por ARPE1

¿con qué componentes o de qué manera haces el envío para que no modifique el fichero en el proceso?

Aunque el mensaje diga eso, no te fies, no es que los componentes modifiquen el fichero en el envío.
Lo normal es que en algún punto del proceso, desde que generamos el fichero y lo firmamos, hasta que lo enviamos, sin querer estamos modficando la codificación.
A veces simplemente es al usar TStreams o grabar en disco y recuperar.

Revisad los pasos que estáis haciendo desde la firma hasta el envío y si en algún punto la codificación cambia, no porque lo hagáis expresamente, sino porque se esté haciendo sin daros cuenta.

En cuanto a los envíos en los mensajes del foro puedes ver que hay varios componentes que se están utilizando. En este mensaje tienes (en la parte inferior) un resumen de los diferentes componenetes que se usa para enviar:
https://www.clubdelphi.com/foros/sho...&postcount=436

* Opcion1: TNetHTTPClient
* Opción2: TRESTClient + TRESTRequest + TRESTResponse
* Opcion3: TsbxHTTPClient (SecureBlackBox)
* Opción4: Utilizando commandos CURL
* Opción5: Utilizando las Indy + OpenSSL
* ...

[skatologiko]

¿Alguien puede poner un ejemplo de algún archivo XML de anulación?

[tejano]

Empezado por skatologiko

¿Alguien puede poner un ejemplo de algún archivo XML de anulación?

Es un proceso algo similar a la emisión, crear la cabecera, codificar el xml del archivo ticketbai de la emisión en base 64, comprimirlo en gz y enviar la anulación.