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

[espinete]

¿Alguien ha conseguido importar los esquemas XSD para poder generar el "cuerpo" de la petición con los TicketBAI a enviar?

Estoy intentando importar por ejemplo el "LROE_PF_140_1_1_Ingresos_ConfacturaConSG_AltaPeticion_V1_0_1.xsd" pero Delphi Sydney me devuelve el error:

Archivo Adjunto 3885

Solo para confirmar:
Entiendo que los ficheros TicketBAI generados no se envían directamente, sino que se debe crear un XML que contiene como máximo 1000 TicketBAI, codificarlo en Base64, comprimirlo y añadirlo en el cuerpo de la petición/envío, junto con un json como cabecera de la petición y otros requisitos en el header.

El problema es que no puedo usar el XML Data Binding para generar ese XML que contiene los TicketBAI por culpa de ese error.

Entiendo también que cada tipo de TicketBAI usa un esquema XSD diferente según el caso, y que cada petición/envío solo puede contener TicketBAI del mismo tipo/esquema.

¿Soy el único al que le parece todo esto bastante engorroso, o es que he empezado tarde y fue demasiada información de golpe?

[Emiliopm]

Buenas compañeros, hemos creado un curso relacionado con TicketBAI en nuestra plataforma abatic . net

Así pues, si estáis interesados en TicketBAI, esta es una buena forma de comenzar.

Durante el curso crearemos una anulación de factura, la firmaremos y la enviaremos a TicketBAI. Todo ello durante 12 horas repartidas en 2 semanas en directo.

Un saludo.

[keys]

Empezado por espinete

¿Alguien ha conseguido importar los esquemas XSD para poder generar el "cuerpo" de la petición con los TicketBAI a enviar?

Estoy intentando importar por ejemplo el "LROE_PF_140_1_1_Ingresos_ConfacturaConSG_AltaPeticion_V1_0_1.xsd" pero Delphi Sydney me devuelve el error:

Archivo Adjunto 3885

Solo para confirmar:
Entiendo que los ficheros TicketBAI generados no se envían directamente, sino que se debe crear un XML que contiene como máximo 1000 TicketBAI, codificarlo en Base64, comprimirlo y añadirlo en el cuerpo de la petición/envío, junto con un json como cabecera de la petición y otros requisitos en el header.

El problema es que no puedo usar el XML Data Binding para generar ese XML que contiene los TicketBAI por culpa de ese error.

Entiendo también que cada tipo de TicketBAI usa un esquema XSD diferente según el caso, y que cada petición/envío solo puede contener TicketBAI del mismo tipo/esquema.

¿Soy el único al que le parece todo esto bastante engorroso, o es que he empezado tarde y fue demasiada información de golpe?

Hola.

Yo trabajo con delphi Tokio y no he tenido ningún problema al importar los xsd. ¿Has metido todos los ficheros a descargar dentro de la misma carpeta?. Te adjunto los ficheros importados por si te sirve de algo.

En Bizkaia los ficheros no se envían directamente, sino que van dentro de un modelo de hacienda 140/240. El fichero de ticketbai es el mismo para los dos modelos pero se envían de diferente forma.En Gipuzkoa si se envían directamente y en alava ¿?. La estructura del fichero ticketBAi es la misma para las tres haciendas.

Igual si es un poco engorroso al princio, pero una vez que lo consigues entender es siempre igual.

Animo Compañero.

[espinete]

Muchas gracias, keys.

Fallo mío. No descomprimí *todos* los archivos del ZIP, sino únicamente el .xsd que quería importar. Por eso Delphi daba el error, porque necesitaba el resto de archivos. Disculpa, no tenía experiencia usando el XML Data Binding.

Usé un "XML importer" online y ahí sí obtuve un mensaje de error más descriptivo que hacía referencia a que faltaba un archivo, y eso me dio la pista.

A ver si por fin consigo cumplir todos los requisitos para generar una simple petición de envío. Por cierto, hoy martes el entorno de pruebas no estará operativo, según me dicen de Bizkaia.

[espinete]

Iba a crear un post-resumen de todo el proceso, al menos de lo que ya tengo, pero creo que ahora mismo no soy el que más experiencia tiene con TicketBAI. De hecho empecé a elaborar el post y son tantos pasos que cuesta explicarlo, así que por ahora lo dejo hasta que esté familiarizado con todo esto.

Ya he conseguido crear el XML final (el LROE), que contiene los TicketBAI firmados a enviar, en Base64 y comprimirlo en ZIP, pero al realizar un envío usando NetHTTPClient solo obtengo Bad Request, así que no sé cual de las 1000 cosas que hay que hacer previamente es la que está mal.

Primero genero el xml del LROE, a partir de uno de los esquemas XSD, concretamente el del envío de "ingresos con factura con software garante". Como son datos de prueba no sé si es que falta (o sobra) algún dato.
Obviamente el fichero "firmado.xml" es el TicketBAI firmado con certificado digital.

Código Delphi [-]
    
    f := NewLROEPF140IngresosConFacturaConSGAltaPeticion;

    f.Cabecera.Modelo:='140';
    f.Cabecera.Ejercicio:=2021;
    f.Cabecera.Capitulo:='';
    f.Cabecera.SubCapitulo:='1.1';
    f.Cabecera.Operacion:='A00';  //A00 = Alta / M00 = Modificación
    f.Cabecera.Version:='';

    f.Cabecera.ObligadoTributario.NIF:='XXXXXXX';
    f.Cabecera.ObligadoTributario.ApellidosNombreRazonSocial:='XXXXXXXXXXXX';

    with f.Ingresos.Add do
    begin
        TicketBai := EncodeFileToBase64('firmado.xml');

        with Renta.Add do
        begin
            Epigrafe:='';
            ImporteIngresoIRPF:='121';
            IngresoAComputarIRPFDiferenteBaseImpoIVA:='121';
            CriterioCobros:='';
        end;
    end;

    XMLDocument2.XML.Text:=f.XML;
    xmldocument2.Active:=True;
    xmldocument2.SaveToFile('lroe.xml');

Tengo dudas con la compresión de dicho XML en gzip. He usado System.ZLib para comprimir el lroe.xml con la siguiente función, pero no estoy seguro de que sea la forma correcta.

Código Delphi [-]
procedure comprimir(origen,destino:string);
var LInput, LOutput: TFileStream;
    LZip: TZCompressionStream;
begin
    { Create the Input, Output, and Compressed streams. }
    LInput := TFileStream.Create(origen, fmOpenRead);
    LOutput := TFileStream.Create(destino, fmCreate);
    LZip := TZCompressionStream.Create(clDefault, LOutput);

    { Compress data. }
    LZip.CopyFrom(LInput, LInput.Size);

    { Free the streams. }
    LZip.Free;
    LInput.Free;
    LOutput.Free;
end;

El envío del LROE lo realizo usando código que encontré en este hilo. No tiene mucha complejidad, pero por si acaso lo pongo:

Código Delphi [-]
    
    NetHTTPRequest1.CustomHeaders['Accept-Encoding'] := 'gzip';
    NetHTTPRequest1.CustomHeaders['Content-Encoding'] := 'gzip';
    NetHTTPRequest1.CustomHeaders['Content-Type'] := 'application/octet-stream';
    NetHTTPRequest1.CustomHeaders['eus-bizkaia-n3-version'] := '1.0';
    NetHTTPRequest1.CustomHeaders['eus-bizkaia-n3-content-type'] := 'application/xml';

    json :=  '{"con": "LROE", "apa": "1.1", "inte": {"nif": "XXXXXXX","nrs": "XXXXXXXXXX","ap1": "","ap2": ""},"drs": {"mode": "140","ejer": "2021"}}';

    NetHTTPRequest1.CustomHeaders['eus-bizkaia-n3-data'] := json;

    ss := TStringStream.Create('', TEncoding.UTF8);
    ss.Position := 0;
    ss.LoadFromFile('archivo.gz');

    NetHTTPRequest1.MethodString := 'POST';
    Memo1.Text := NetHTTPClient1.Post('https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena', ss).ContentAsString(tencoding.UTF8);

Pero en el Memo no obtengo nada. Tengo que irme al evento RequestCompleted, y con AResponse.StatusCode y AResponse.StatusText solo obtengo 400 - Bad Request.

Sé que hoy el entorno de pruebas no estará operativo, pero me gustaría saber si lo anterior es correcto o no, porque dudo mucho que las respuestas a las peticiones sean lo suficientemente detalladas como para saber cual es el error exacto en los envíos.

Gracias de antemano. Espero que este post pueda servir también como pequeño resumen del proceso para los que empiecen desde cero, aunque hay muchísimos detalles que faltan.

[Dadaista]

Hola buenos dias

Este es mi primer post desde que me di de alta. Despues de leer y releer este Hilo, por fin me atrevo a escribir. Soy un programador independiente con una solucion informatica la cual utilizan en un par de tiendas en vizcaya, entre otras. Es un simple programa de ventas que emite tickets de caja. Realmente yo programo en Java pero me avisaron del tema de ticketbai y despues de dar muchas vueltas por internet, encontré éste foro en el que he podido encontrar bastante información al respecto... para mi, el mejor sitio... despues de lo que he visto que hay por la red.

Lo que os digo anteriormente. Me llamaron desde vizcaya y me dijeron oye!!! ticketbai!!! y encontré este foro. Tengo algunas dudas que no se si alguno de vosotros podria contestarme ya que veo que en el hilo hay personas que saben bastante.

Mi programa es una simulacion de una caja resgistradora que emite tickets de caja desde una computadora con windows 10. Los propietarios de las tiendas pasan la informacion de las ventas a sus asesores/contables y son estos últimos los que se encargan de todo el papeleo con hacienda.

Mi pregunta es, si vosotros veis necesario/obligatorio que yo implemente Ticketbai en mi pequeña aplicación para las personas dueñas de las tiendas donde se utiliza mi aplicacion que se encuentran en Euskadi.

En caso que considereis que es necesario.. los ficheros XML quien los firmaria?... la persona dueña de la tienda o yo?

Perdonad por ser tan extenso y por desviarme un poco del tema central de este hilo pero es que no se me ocurre un sitio mejor donde preguntar. Muchas gracias por leer.

Salu2

[keys]

Empezado por Dadaista

Hola buenos dias

Este es mi primer post desde que me di de alta. Despues de leer y releer este Hilo, por fin me atrevo a escribir. Soy un programador independiente con una solucion informatica la cual utilizan en un par de tiendas en vizcaya, entre otras. Es un simple programa de ventas que emite tickets de caja. Realmente yo programo en Java pero me avisaron del tema de ticketbai y despues de dar muchas vueltas por internet, encontré éste foro en el que he podido encontrar bastante información al respecto... para mi, el mejor sitio... despues de lo que he visto que hay por la red.

Lo que os digo anteriormente. Me llamaron desde vizcaya y me dijeron oye!!! ticketbai!!! y encontré este foro. Tengo algunas dudas que no se si alguno de vosotros podria contestarme ya que veo que en el hilo hay personas que saben bastante.

Mi programa es una simulacion de una caja resgistradora que emite tickets de caja desde una computadora con windows 10. Los propietarios de las tiendas pasan la informacion de las ventas a sus asesores/contables y son estos últimos los que se encargan de todo el papeleo con hacienda.

Mi pregunta es, si vosotros veis necesario/obligatorio que yo implemente Ticketbai en mi pequeña aplicación para las personas dueñas de las tiendas donde se utiliza mi aplicacion que se encuentran en Euskadi.

En caso que considereis que es necesario.. los ficheros XML quien los firmaria?... la persona dueña de la tienda o yo?

Perdonad por ser tan extenso y por desviarme un poco del tema central de este hilo pero es que no se me ocurre un sitio mejor donde preguntar. Muchas gracias por leer.

Salu2

Hola.

El envío del fichero va dentro de un modelo de hacienda(140/240) y por lo tanto será tu cliente quien determine si el envío lo va a hacer el o la asesoria. Si tu aplicación emite tickets/facturas tiene que ser tu aplicación el que genere el ficheo TBai si o si, ya que en el ticket tienes que imprimir el código qr y para eso necesitas generar el fichero, y este es el que se tiene que enviar.

Luego el envío lo tendrá que hacer tu aplicación o tendrás que pasar los ficheros xml al asesor para que el realice el envío, siempre y cuando su aplicacion (la del asesor) permita realizar el envio de esos ficheros generados por otra aplicación.

Todo esto sólo en Bizkaia, ya que en Gipuzkoa el envío hay que realizarlo según se genere la factura.

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

Empezado por Dadaista

Los propietarios de las tiendas pasan la informacion de las ventas a sus asesores/contables y son estos últimos los que se encargan de todo el papeleo con hacienda.

No comentas "cómo pasan los propietarios esa información". Si es de forma telemática o más manual. De todas formas, sólo evitarías el paso del envío, pero creo que eso es lo de menos, porque es lo más sencillo, todo el trabajo anterior debe hacerlo tu aplicación.

Empezado por Dadaista

Mi pregunta es, si vosotros veis necesario/obligatorio que yo implemente Ticketbai en mi pequeña aplicación para las personas dueñas de las tiendas donde se utiliza mi aplicacion que se encuentran en Euskadi.

Como han comentado, tu aplicación es la que genera tickets, por lo tanto es tu aplicación es la que al generar el ticket, debe crear el archivo XML y firmarlo. Esa información la necesitas para el siguiente ticket.

También tienes que generar el código QR y añadirlo al ticket que se lleva el cliente.

Supongo que si has revisado el hilo, ya la habrás visto, pero esta imagen es bastante explicativa del proceso.
Pasos al facturar en TicketBAI

Empezado por Dadaista

En caso que considereis que es necesario.. los ficheros XML quien los firmaria?... la persona dueña de la tienda o yo?

Como te hemos comentado los ficheros los debe firmar tu aplicación utilizando un certificado, que lo lógico es que vaya a nombre de la dueña, que es la que está tributando.

[espinete]

Buenas...

(Parece ser que ) por fin he conseguido hacer un envío. Al menos ya no obtengo Bad Request. He usado el siguiente código facilitado por keys un par de páginas atrás. La única diferencia que había con el mío era la forma de adjuntar el archivo comprimido en la petición:

Código Delphi [-]
var json : string;
    RequestBody: TFileStream;
    AResponse: IHTTPResponse;
begin
    RequestBody := TFileStream.Create('archivo.gz', fmOpenRead);

    NetHTTPClient1.SecureProtocols := [THTTPSecureProtocol.TLS12];
    NetHTTPClient1.CustomHeaders['Accept-Encoding'] := 'gzip';
    NetHTTPClient1.CustomHeaders['Content-Encoding'] := 'gzip';
    NetHTTPClient1.CustomHeaders['Content-Type'] := 'application/octet-stream';
    NetHTTPClient1.CustomHeaders['eus-bizkaia-n3-version'] := '1.0';
    NetHTTPClient1.CustomHeaders['eus-bizkaia-n3-content-type'] := 'application/xml';

    //Formamos los parametros json de entrada
    json :=  f_cabecera_LROE('LROE', //concepto
             '1.1',  //subcapitulo
             'XXXXXXXXX',  //NIF
             'XXXXXXXXXXXXXXXXX',   //Nombre o Razón Social
             '',   //Primer Apellido
             '',   //Segundo Apellido
             '140',   //140 o 240
             '2021'); //Ejercicio

    NetHTTPClient1.CustomHeaders['eus-bizkaia-n3-data'] := json;
    AResponse := NetHTTPClient1.Post('https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena',RequestBody);

    memo2.Lines.Append(inttostr(AResponse.StatusCode)+' '+AResponse.StatusText);

    memo2.Lines.Append(AResponse.ContentAsString());
end;

Ahora obtengo 200 - OK, pero nada más. No sé cómo obtener la respuesta al envío, que por lo que he leído, es un archivo comprimido que contiene un XML.

AResponse.ContentAsString() no contiene nada. Está en blanco.

¿Alguien sabe qué hacer a continuación?

[tejano]

Buenos días,

Que programa estáis utilizando para generar el archivo gz comprimido.

Saludos

[espinete]

5 mensajes más arriba tienes un código para comprimir un archivo en .gz usando la librería ZLib que trae Delphi

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

Yo las primeras pruebas las hice directamente con Postman y/o con Imsomnia (similar). En ambos casos se permite instalar un certificado cliente y para probar los envíos y obtener las respuestas son suficientes.

Lo digo porque es una forma de comprobar el fichero, la sintaxis, la codificación,... y dejar de lado la codificación en Delphi.
Una vez que sabemos que el fichero es correcto (o que nos tiene que dar determinado error), podemos empezar a codificar.

De esta forma compartimentamos problemas. Si probamos todo a la vez, no sabemos si es del fichero, del certificado, del firnado, del comprimido, del los parámetros, de la forma de envío,...

[espinete]

Acabo de probar con Postman y el envío se realiza. Comparé los headers, etc. de Postman con los míos y una de las diferencias era el UserAgent.

Fui a mi código y añadí UserAgent := 'PostmanRuntime/7.26.10'; y ahora sí obtengo una respuesta (bastante larga).

Así que el UserAgent por defecto (Embarcadero URI Client/1.0) parece ser que no sirve, aunque no entiendo el motivo exacto.

Tanto en Postman como con mi proyecto, obtengo un JSON con developerMessage enorme e inservible y Status 500.

El certificado en Postman parece estar correcto, porque en pruebas anteriores sí obtenía un error que hacía referencia a "password invalid" y en otras pruebas sí recibía errores como "el formato del NIF no es válido", por lo que esta respuesta de error 500 cuando todo parece estar bien no sé a qué puede ser debido.

[Dadaista]

Muy agradecido keys y Neftali

[elcharlie]

Se ha abierto la posibilidad de realizar envíos al entorno de pruebas mediante certificados de dispositivo.

Con carácter previo a la remisión de las anotaciones, se deberán comunicar los datos identificativos de el/los certificados de dispositivo mediante la cumplimentación del formulario electrónico al que se puede acceder en el siguiente enlace: https://www.ebizkaia.eus/es/catalogo...os?procID=1740.



En https://www.batuz.eus/es/documentacion-tecnica dispone de un manual para obtener el número de serie asociado al certificado de dispositivo.



Por otro lado, se ha habilitado igualmente en el entorno de pruebas la anulación de los siguientes subcapítulos:



1.1 - Ingresos con factura con Software garante del LROE de personas físicas y entidades sin personalidad jurídica (modelo 140).
1.1 - Facturas emitidas con Software garante del LROE de personas jurídicas y de contribuyentes no residentes con establecimiento permanente (modelo 240).



Las consultas o incidencias relacionadas con el entorno de pruebas se deben dirigir por escrito a batuz@bizkaia.eus.

Esto han enviado desde Batuz, por si alguien le interesa hacer las pruebas con los certificados de dispositivos.

[espinete]

Me respondo a mí mismo...

Las respuestas al envío de la petición REST vienen en el Header de la respuesta. Concretamente en estos valores:

Código Delphi [-]
    if AResponse.ContainsHeader('eus-bizkaia-n3-mensaje-respuesta') then
        memo2.Lines.Append(AResponse.HeaderValue['eus-bizkaia-n3-mensaje-respuesta']);

    if AResponse.ContainsHeader('eus-bizkaia-n3-codigo-respuesta') then
        memo2.Lines.Append(AResponse.HeaderValue['eus-bizkaia-n3-codigo-respuesta']);

    if AResponse.ContainsHeader('eus-bizkaia-n3-tipo-respuesta') then
        memo2.Lines.Append(AResponse.HeaderValue['eus-bizkaia-n3-tipo-respuesta']);

Ahora ya consigo ver los distintos motivos de error en los envíos.

[espinete]

Me devuelve "Error al descomprimir el fichero.Not in GZIP format", así que me temo que el algoritmo para comprimir en GZIP no es válido.

Buscando en StackOverflow encontré esta variante que parece que sí funciona:

Código Delphi [-]
procedure comprimir(origen,destino:string);
var LInput, LOutput: TFileStream;
    LZip: TZCompressionStream;
begin
    { Create the Input, Output, and Compressed streams. }
    LInput := TFileStream.Create(origen, fmOpenRead);
    LOutput := TFileStream.Create(destino, fmCreate);
    LZip := TZCompressionStream.Create(LOutput, zcDefault, 15 + 16);

    { Compress data. }
    LZip.CopyFrom(LInput, LInput.Size);

    { Free the streams. }
    LZip.Free;
    LInput.Free;
    LOutput.Free;
end;

[espinete]

Después de corregir otros errores en el envío (certificado, modelo, etc.) y de adaptar el envío tanto para el 140 como para el 240, etc. ahora obtengo el siguiente error

El XML no cumple el esquema.[Linea:1 Columna:180] Error:cvc-complex-type.2.4.a: Invalid content was found starting with element '{"https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_1.xsd":Cabecera}'. One of '{Cabecera}' is expected.

Si comparo los XML generados por mi aplicación, con los XML de ejemplo que proporciona Bizkaia, la única diferencia que veo es que los de Bizkaia empiezan así:

<lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns:lrpjfecsgap="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
...

...y el mío empieza así...

<LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
...

¿Alguien más ha tenido este problema? Si la causa es esa... ¿hay forma de forzar a añadir ese prefijo en los XML o hay que hacerlo manualmente modificando directamente los strings antes de guardar el xml?

[elcharlie]

Empezado por espinete

Me devuelve "Error al descomprimir el fichero.Not in GZIP format", así que me temo que el algoritmo para comprimir en GZIP no es válido.

Buscando en StackOverflow encontré esta variante que parece que sí funciona:

Código Delphi [-]
procedure comprimir(origen,destino:string);
var LInput, LOutput: TFileStream;
    LZip: TZCompressionStream;
begin
    { Create the Input, Output, and Compressed streams. }
    LInput := TFileStream.Create(origen, fmOpenRead);
    LOutput := TFileStream.Create(destino, fmCreate);
    LZip := TZCompressionStream.Create(LOutput, zcDefault, 15 + 16);

    { Compress data. }
    LZip.CopyFrom(LInput, LInput.Size);

    { Free the streams. }
    LZip.Free;
    LInput.Free;
    LOutput.Free;
end;

Yo creo que lo estas haciendo bien, asi lo hago yo.

[espinete]

Hola, sí, eso ya estaba resuelto. El problema que tengo ahora es el del mensaje posterior:

El XML no cumple el esquema.[Linea:1 Columna:180] Error:cvc-complex-type.2.4.a: Invalid content was found starting with element '{"https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_1.xsd":Cabecera}'. One of '{Cabecera}' is expected.

No entiendo por qué dice que no tiene Cabecera si el XML es idéntico, salvo que el XML "original" incluye el prefijo "lrpjfecsgap"