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

[Galaxian]

Para enviar (es código C++, que es el lenguaje que uso, aunque su traducción a Pascal/Delphi no el muy complicada porque la estructura es la misma, aunque su sintaxis difiera un poco:

Código PHP:

CkRest rest;
CkSocket socket;

success = socket.SetSslClientCertPfx("d:\\xxx.pfx","xxxxxxxxxx");
if (success != true) {std::cout << socket.lastErrorText() << "\r\n"; return;}

bool bTls = true;
int port = 443;
int maxWaitMs = 5000;

success = socket.Connect("pruesarrerak.bizkaia.eus",port,bTls,maxWaitMs);

if (success != true) 
{
    std::cout << "Connect Failure Error Code: " << socket.get_ConnectFailReason() << "\r\n";
    std::cout << socket.lastErrorText() << "\r\n";
    return;
}

bool bAutoReconnect = true;

// Use the connection:
success = rest.UseConnection(socket,bAutoReconnect);
if (success != true) {std::cout << rest.lastErrorText() << "\r\n"; return;}

CString jsn="{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"XXXXXXXXXX\",\"nrs\":\"XXXXXXXXXX\"},\"drs\":{\"mode\":\"140\",\"ejer\":\"2020\"}}";
cTexto dat=cFicheroBase::Leer("D:\\Ejemplo_LROE_140.xml").Texto();

rest.put_Utf8(SI);

rest.AddHeader("Accept-Encoding","gzip");
rest.AddHeader("Content-Encoding","gzip");
rest.AddHeader("Content-Type","application/octet-stream");
rest.AddHeader("eus-bizkaia-n3-version","1.0");
rest.AddHeader("eus-bizkaia-n3-content-type","application/xml");
rest.AddHeader("eus-bizkaia-n3-data",jsn);

int rst=rest.SendReqStringBody("POST","/N3B4000M/aurkezpena",dat);
rst=rest.ReadResponseHeader();
cchar *cr=rest.responseHeader();

CkByteData rb;
rst=rest.ReadRespBodyBinary(rb);
const uchar *dta=rb.getData();
int lng=rb.getSize();

cBinario rb2(dta,lng);
rb2=cCompresion::Descomprimir::Gzip(rb2);

return; 


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

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

[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

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