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

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

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

[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")

[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

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

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

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