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

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

Empezado por Galaxian

Hay que tener en cuenta que la librería chilkat reconoce la cabecera 'Content-Encoding: gzip" y COMPRIME el envío y DESCOMPRIME la respuesta, que, a su vez, está comprimida, por lo que habrá que descomprimirla.
Los certificados no solo pueden cargarse de pfx, sino también del almacén de Windows o usar uno cargado anteriormente

Gracias nuevamente.

[espinete]

Hola a tod@s.

Después de tanto tiempo y de tener encaminado el desarrollo del TicketBAI (al menos el envío y consulta de facturas), me surge una pregunta un poco tonta pero necesito estar seguro...

Para el envío de información del LROE existen varios métodos: ingresos con software garante, facturas con software garante, anulación...

Pero hay otros que indican "sin software garante", o "ingresos sin factura" y otros más.

Teniendo en cuenta que en mi caso estaría haciendo la integración en un software de facturación, es obvio pensar que solo tendría que implementar aquellos esquemas/envíos "con software garante", no? ¿O estoy obviando algo que no he entendido del todo?

No sé si existe información sobre para qué se usa cada caso exactamente, pero imagino que en mi caso concreto solo tendría que preocuparme por implementar el envío de facturas hechas con mi software, nada más.

¿Es correcto?

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

[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

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

[skymota]

Empezado por 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.

Buenas! una vez firmado el fichero, para obtener el SignatureValue para el encadenamiento has utilizado algún metodo de las ChilKat? o directamente cargando el fichero con un xml con algo tipo getAttribute?
Gracias!