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

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

[tejano]

Empezado por tejano

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.

Perdona, se me olvidaba el fichero de anulación, esta firmado, hay que firmarlo al igual que el de la emisió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.

[ARPE1]

Sí, así lo tenemos pero no hay manera.

Código Delphi [-]
   ... 
    wXML := 'prueba.xsig';
    wURL := 'https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta';
    idhttp1.Request.ContentType := 'application/xml; charset=utf-8';
    IdHTTP1.Request.BasicAuthentication := False;
    wCer := 'CERT_TEST.pfx';
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.CertFile := wCer;
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.KeyFile  := wCer;

    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Mode   := sslmClient;
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1_2; // sslvSSLv23; //sslvTLSv1_1;
    wML.Position := 0;
    Try
      IdHTTP1.Post(wURL, wXML, wMR);
      wMR.Position := 0;
      memo1.Lines.LoadFromStream(wMR, TEncoding.UTF8);
      label1.Caption := IntToStr(IdHTTP1.Response.ResponseCode) + ': ' + IdHTTP1.Response.ResponseText;
    Except
      On E:Exception do
        memo1.Lines.Add(E.Message);
    End;

Gracias por la respuesta.

[batuzail]

Empezado por ARPE1

Sí, así lo tenemos pero no hay manera.

Código Delphi [-] ... wXML := 'prueba.xsig'; wURL := 'https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta'; idhttp1.Request.ContentType := 'application/xml; charset=utf-8'; IdHTTP1.Request.BasicAuthentication := False; wCer := 'CERT_TEST.pfx'; IdSSLIOHandlerSocketOpenSSL1.SSLOptions.CertFile := wCer; IdSSLIOHandlerSocketOpenSSL1.SSLOptions.KeyFile := wCer; IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Mode := sslmClient; IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1_2; // sslvSSLv23; //sslvTLSv1_1; wML.Position := 0; Try IdHTTP1.Post(wURL, wXML, wMR); wMR.Position := 0; memo1.Lines.LoadFromStream(wMR, TEncoding.UTF8); label1.Caption := IntToStr(IdHTTP1.Response.ResponseCode) + ': ' + IdHTTP1.Response.ResponseText; Except On E:Exception do memo1.Lines.Add(E.Message); End;


Gracias por la respuesta.

Hola, a mi me pasaba lo mismo me volví loco con la codificación utf-8, al final el problema era que el nombre del cliente tenía un acento, limpia de carácteres un poco raros todos los strings y prueba, yo tras hacer eso puedo enviar sin problema.


Suerte