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

[HerensugeBeltz]

Empezado por
<ResultadosValidacion>
<Codigo>004</Codigo>
<Descripcion>Error: Falta dato obligatorio o [B

el dato es erróneo[/b] [CabeceraFactura:FechaExpedicionFactura].</Descripcion>
<Azalpena>Errorea: Derrigorrezko datua falta da edo datua ez da zuzena [CabeceraFactura:FechaExpedicionFactura].</Azalpena>
</ResultadosValidacion>

Esta es la fecha:

<CabeceraFactura>
<SerieFactura>B2022</SerieFactura>
<NumFactura>0100</NumFactura>
<FechaExpedicionFactura>01-01-2022</FechaExpedicionFactura>
<HoraExpedicionFactura>18:00:17</HoraExpedicionFactura>
</CabeceraFactura>

No puedes enviar una factura futura

[HerensugeBeltz]

Empezado por HerensugeBeltz

No puedes enviar una factura futura

Ya te habían respondido. Perdón.

[HerensugeBeltz]

Empezado por Eric Mtz

Ya por curiosidad, ¿Lograste que te funcionara con el DNI electrónico?

Éstos son los que indican:
o Certificado de persona física.
...

El DNI electrónico no deja de ser un certificado de persona física emitido por la FNMT. Lo único que hice diferente, por facilitar las pruebas, fue instalarlo en el almacén de certificados de Windows.
En el XML de la factura ponía como ID del emisor mi propio DNI y la factura era aceptada.

[sEngine]

Buenas soy nueva por aqui, buscando como pelearme con ticketbai llegué a este foro.

Estaba teniendo problemas con el envío desde delphi, ya que en mi version no tengo "TNetHTTPClient" por lo que he estado investigando con el Idhttp (que habia leido que no se podia) y he conseguido que se envie con su certificado.
Os dejo el codigo que me ha funcionado por si a alguien más le puede ser útil.

De primeras hay que crear un componente TIdSSLIOHandlerSocketOpenSSL y otro TIdhttp en el formulario.

En el TIdSSLIOHandlerSocketOpenSSL hay que añadirle al evento OnGetPassword lo siguiente

procedure TFMain.LHandlerGetPassword(var Password: string);
begin
  Password := 'IZProd2021';
 end;

Y luego ya el codigo del envio

  RequestBody := TFileStream.Create('tempBAi_firmado.xml', fmOpenRead);

  LHandler.SSLOptions.SSLVersions := [sslvTLSv1_2];
  LHandler.SSLOptions.CertFile := 'sello_entidad_act.p12';
  LHandler.SSLOptions.KeyFile := 'sello_entidad_act.p12';
  LHandler.ongetpassword := LHandlerGetPassword;
  idhttp_fac := TIdhttp.Create();
  idhttp_fac.IOHandler:=LHandler;
  idhttp_fac.Request.ContentType := 'application/xml';

   Respuesta := idhttp_fac.Post('h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta',RequestBody);

Espero que os sea util

[JVelezGarcia]

Empezado por tejano

Estoy haciendo pruebas de facturas emitidas LROE 240 y me da el error B4_1000025 - Operación errónea

Creo que en el apartado hay que poner el 2 y después la llamada es similar al de enviadas y a la misma dirección, pero como no hay mucha información no puedo asegurarlo.

c:\curl\1\bin\curl --insecure --cert-type P12 --cert Path_certificadoassword -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"2\",\"inte\":{\"nif\":\"A48190839\",\"nrs\":\"TECNICAS DE REFRACTARIOS S.A.U\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v ...

Gracias de antemano.

Yo he estado enviando facturas emitidas 240 y el valor en apa es 1.1

[JVelezGarcia]

Hola, al realizar el envío usando curl por línea de comandos obtengo el fichero respuesta comprimido.
Cuando lo descomprimo obtengo un fichero con el mismo nombre y sin extensión. Si descomprimo ese segundo fichero ya obtengo el fichero xml de respuesta. Es como si tuviera que descomprimirlo dos veces.

El envío lo hago así :

curl -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" -H "Content-Type: application/octet-stream" -H "eus-bizkaia-n3-version: 1.0" -H "eus-bizkaia-n3-content-type: application/xml" -H "eus-bizkaia-n3-data: {\"con\": \"LROE\",\"apa\": \"1.1\",\"inte\": {\"nif\": \"CIF\",\"nrs\": \"EMPRESA\"},\"drs\": {\"mode\": \"240\",\"ejer\": \"2021\"}}" --data-binary @LROE240.XML.gz --cert CERTIFICADO.pem --key CERTIFICADO_KEY.pem -v URL_SERVIDOR_PRUEBAS --output RESP_240.gz -D cabecera.txt

No sé si estoy haciendo algo mal en el envío (parámetro --output) o es que tengo que hacer algo más.

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

Empezado por edari

¿Os suben bien las facturas a Gipuzkoa pruebas?

A mi me están subiendo bien.

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

Empezado por sEngine

Estaba teniendo problemas con el envío desde delphi, ya que en mi version no tengo "TNetHTTPClient" por lo que he estado investigando con el Idhttp (que habia leido que no se podia) y he conseguido que se envie con su certificado.
Os dejo el codigo que me ha funcionado por si a alguien más le puede ser útil.

De primeras hay que crear un componente TIdSSLIOHandlerSocketOpenSSL y otro TIdhttp en el formulario.

Espero que os sea util

Gracias por compartirlo.
Actualizado el mensaje que recopila códigos y ejemplos.

[b4aronDeLaBirr4]

Empezado por b4aronDeLaBirr4

Bueno, ya parece que tengo contacto con el servicio (aunque sin ser aceptada la factura todavía, ahora pongo el problema) pero por si a alguien le sirve, mientras estoy esperando el certificado de persona física a la FNMT, he usado "sello_entidad_act.p12:IZProd2021" en POSTMAN y al menos me da respuesta. Aunque no entiendo este error cuando estoy usando un ejemplo de la hacienda foral:

<ResultadosValidacion>
<Codigo>004</Codigo>
<Descripcion>Error: Falta dato obligatorio o el dato es erróneo [CabeceraFactura:FechaExpedicionFactura].</Descripcion>
<Azalpena>Errorea: Derrigorrezko datua falta da edo datua ez da zuzena [CabeceraFactura:FechaExpedicionFactura].</Azalpena>
</ResultadosValidacion>

Esta es la fecha:

<CabeceraFactura>
<SerieFactura>B2022</SerieFactura>
<NumFactura>0100</NumFactura>
<FechaExpedicionFactura>01-01-2022</FechaExpedicionFactura>
<HoraExpedicionFactura>18:00:17</HoraExpedicionFactura>
</CabeceraFactura>

He puesto la fecha de hoy y el error ha cambiado (no me imaginaba que tuviera que ser la misma fecha que el envío). Ahora tengo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>07-07-2021 13:38:45</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado</Descripcion>
<Azalpena>Baztertua</Azalpena>
<ResultadosValidacion>
<Codigo>003</Codigo>
<Descripcion>Error: La factura no incluye líneas de detalle.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du xehetasun lerrorik.</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

Es que no entiendo que un fichero de ejemplo dado por ellos no sea suficiente para el sistema de validación. O que esté dejándome algo... Ideas?

[b4aronDeLaBirr4]

Ahora estoy intentando formar un documento con el que poder probar un envío correcto a la hacienda de Gipuzkua. Si alguien dispone de un ejemplo que cumpla con todos los requerimientos por ahí, se lo agradecería (estoy trabajando con los subidos por las haciendas forales).

-- UPDATE --

En el documento de FAQ para desarrolladores he encontrado esto: "El esquema XSD de TicketBAI indica las líneas de detalle como opcionales, pero en Gipuzkoa es obligatorio indicar este dato." por lo que el error está claro (madre mía con las estructuras no comunes...).

[HerensugeBeltz]

Empezado por b4aronDeLaBirr4

Es que no entiendo que un fichero de ejemplo dado por ellos no sea suficiente para el sistema de validación. O que esté dejándome algo... Ideas?

Aunque en el esquema no sea obligatorio, en Gipuzkoa te obligan a especificar los detalles de todas las líneas.

<DescripcionFactura>Servicios Hotel</DescripcionFactura>
    <DetallesFactura>
		<IDDetalleFactura>
		    <DescripcionDetalle>Línea factura 1</DescripcionDetalle>
				<Cantidad>1</Cantidad>
				<ImporteUnitario>110.00</ImporteUnitario>
				<Descuento>0.00</Descuento>  <==== este sí es opcional
				<ImporteTotal>121.00</ImporteTotal>
		</IDDetalleFactura>
    </DetallesFactura>

[tejano]

Empezado por JVelezGarcia

Hola, al realizar el envío usando curl por línea de comandos obtengo el fichero respuesta comprimido.
Cuando lo descomprimo obtengo un fichero con el mismo nombre y sin extensión. Si descomprimo ese segundo fichero ya obtengo el fichero xml de respuesta. Es como si tuviera que descomprimirlo dos veces.

El envío lo hago así :

curl -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" -H "Content-Type: application/octet-stream" -H "eus-bizkaia-n3-version: 1.0" -H "eus-bizkaia-n3-content-type: application/xml" -H "eus-bizkaia-n3-data: {\"con\": \"LROE\",\"apa\": \"1.1\",\"inte\": {\"nif\": \"CIF\",\"nrs\": \"EMPRESA\"},\"drs\": {\"mode\": \"240\",\"ejer\": \"2021\"}}" --data-binary @LROE240.XML.gz --cert CERTIFICADO.pem --key CERTIFICADO_KEY.pem -v URL_SERVIDOR_PRUEBAS --output RESP_240.gz -D cabecera.txt

No sé si estoy haciendo algo mal en el envío (parámetro --output) o es que tengo que hacer algo más.

Hola, sí hay que descomprimirlo 2 veces

[b4aronDeLaBirr4]

Gracias por la respuesta!
Lo que me fastidia es que, aún poniendo dicho detalle y aquellos campos obligatorios en Gipuzkua, me dice lo siguiente:

<ResultadosValidacion>
<Codigo>002</Codigo>
<Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Azalpena>
</ResultadosValidacion>

[bilbur]

Empezado por mounteide

Hola Bilbur.

Ahora me ha firmado correctamente. Muchísimas gracias.

Ahora me funciona todo perfectamente, en entorno en windows. Sin embargo cuando lo subo a un servidor centos me da error al enviarlo por curl

curl command - Unable to load client cert -8018

Esto es debido a el servidor tiene una versión de curl que no es openssl es nss.

A ti por casualidad te ha dado este problema? Sabes como pasar con curl los parámetros para que la firma sea con nss?

Muchísimas gracias y saludos.

Lo uso en windows y opensuse linux ambos con ssl
De todas forma pregunta en el foro por formas de envío con o sin curl


Suerte

[b4aronDeLaBirr4]

Empezado por b4aronDeLaBirr4

Gracias por la respuesta!
Lo que me fastidia es que, aún poniendo dicho detalle y aquellos campos obligatorios en Gipuzkua, me dice lo siguiente:

<ResultadosValidacion>
<Codigo>002</Codigo>
<Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Azalpena>
</ResultadosValidacion>

Vale, al parecer el orden de los campos en el XML es muy estricto con el XSD y al estar mirando entre Gipuzkoa y Bizkaia había confundido un par. Ahora no entiendo por qué, tras mostrarme todos estos errores, me vuelve al problema del certificado con el siguiente error ya conocido:

<Codigo>007</Codigo>
<Descripcion>Error: Certificado remitente no válido para emisor factura.</Descripcion>

Recuerdo que he utilizado el certificado sello_entidad_act.p12:IZProd2021 obtenido de Izenpe (certificados de producción) así que no sé si se podrá usar otro certificado de esos o tener que recurrir por fuerza al de persona física solicitado (aún sin recibir) por la FNMT.

[b4aronDeLaBirr4]

Buenas!

¿Qué certificado estás utilizando? Ya que veo que te funciona!

Un saludo.

[JoseLeeTo]

Empezado por b4aronDeLaBirr4

He puesto la fecha de hoy y el error ha cambiado (no me imaginaba que tuviera que ser la misma fecha que el envío). Ahora tengo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>07-07-2021 13:38:45</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado</Descripcion>
<Azalpena>Baztertua</Azalpena>
<ResultadosValidacion>
<Codigo>003</Codigo>
<Descripcion>Error: La factura no incluye líneas de detalle.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du xehetasun lerrorik.</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

Es que no entiendo que un fichero de ejemplo dado por ellos no sea suficiente para el sistema de validación. O que esté dejándome algo... Ideas?

Hola. En su momento, cuando consulté a los de Batuz, me comentaron que las facturas que admiten pueden tener fecha del ejercicio 2021 e incluso del 2020 (para entorno de pruebas se entiende).
Ya a partir del 2022, es cuando se podrán emitir dichas facturas de su mismo ejercicio.

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

Empezado por tejano

Hola, sí hay que descomprimirlo 2 veces

Segun ellos no.
A nosotros nos contestaron que lo estamos haciendo todos mal (menos ellos).

[edari]

Empezado por edari

¿Os suben bien las facturas a Gipuzkoa pruebas?


Subo la factura y de repente me ha empezado a salir

<Codigo>002</Codigo><Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-datatype-valid.1.2.1: 'codigo_HASH' is not a valid value for 'base64Binary'.</Descripcion>



Hasta hace un rato me subían bien (bueno miento me daba otro error de esquema porque me había comido las líneas de detalle...que ya lo sabía y me iba a poner con ello hoy) pero ahora siempre me devuelve este error...

Sigo con este error y me estoy volviendo loco para que suba una factura


Estoy comparando mi xml con un zip de ejemplos que hay en el hilo y veo una diferencia,



No estoy grabando "NumSerieDispositvo" porque en la documentación de su web lo siguen poniendo en "negro" (opcional)


¿Es opcional o no?


No tengo ni idea si es por esto pero es el camino que se me ocurre de momento

[Galaxian]

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

Segun ellos no.
A nosotros nos contestaron que lo estamos haciendo todos mal (menos ellos).

Seguro que no se han dado cuenta de que el software que usan comprime automáticamente los datos si descubre el encabezado Content-Encoding: gzip, y lo digo porque las librerías que uso (Chilkat) hacen exactamente eso: comprimen y descomprimen automáticamente los datos si encuentra dicho encabezado. De hecho, al objeto html le envío datos xml y él los comprime y envía un gz, pero al recibir la respuesta, en vez de un XML recibo un GZ.

Como no podía ser de otra manera, lo primero que hice fue acceder a los datos realmente recibidos, descomprimí el gz y el resultado fue otro gz.

He optado por no decírselo a los de batuz porque hay ciertos "dioses de la programación" (entre los que se encuentran ellos según he comprobado en otras preguntas) que no reconocen un error ni ante el mismísimo Tomás de Torquemada.