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

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

Aquí en preguntas frecuentes hay esto (a ver si te aclara algo):

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

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

[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

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

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

Empezado por skatologiko

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

En los ejemplos de Batuz creo que tienes varios XML de anulación. Los ficheros enviados y las diferentes respuestas, tanto para TicketBAI como para Batuz.
https://www.batuz.eus/fitxategiak/Ba...os/Ejemplos.7z

[ARPE1]

¡Qué rapidez! Gracias.

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

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.

Hemos probado a enviar el fichero firmado generado directamente con funciones como:

Código Delphi [-]
IdHTTP1.Post(URL, SourceFile, ResponseStream);

o esta

Código Delphi [-]
sbxHTTPClient1.PostFile(URL, FileName);

En teoría así evitamos lo que comentas de cambio de codificaciones al cargar el fichero con Streams y compañía. El resultado es el mismo. Lo sorprendente es que si ese fichero lo enviamos con el programa SoapUI lo acepta sin problemas. Hemos "intentado" crear un LOG con los datos que se envían y comparado byte a byte con el nuestro y son idénticos.

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

Hemos probado todas las opciones y no hay manera, cada una nos falla en un punto diferente. Con la que más hemos conseguido es con las INDY del propio Delphi.

Gracias de nuevo de antemano.

[sEngine]

Asegurate de enviarlo asi

Código Delphi [-]
idhttp1.Request.ContentType := 'application/xml; charset=utf-8"';

Empezado por ARPE1

¡Qué rapidez! Gracias.


Hemos probado a enviar el fichero firmado generado directamente con funciones como:
Código Delphi [-]IdHTTP1.Post(URL, SourceFile, ResponseStream);

o esta
Código Delphi [-]sbxHTTPClient1.PostFile(URL, FileName);


En teoría así evitamos lo que comentas de cambio de codificaciones al cargar el fichero con Streams y compañía. El resultado es el mismo. Lo sorprendente es que si ese fichero lo enviamos con el programa SoapUI lo acepta sin problemas. Hemos "intentado" crear un LOG con los datos que se envían y comparado byte a byte con el nuestro y son idénticos.


Hemos probado todas las opciones y no hay manera, cada una nos falla en un punto diferente. Con la que más hemos conseguido es con las INDY del propio Delphi.

Gracias de nuevo de antemano.