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

[b4aronDeLaBirr4]

Gracias por la respuesta! ¿Descargo los de desarrollo o los de producción? ¿Y luego, este certificado, en qué momento habría que hacer algo con ello?

Un saludo.

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

[adolphsys]

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>

Factura con fecha anterior o actual, a TicketBAI no le gusta que factures servicios futuros.

Tip para todos: repasar vuestros sistemas de facturación y controlar la fecha para que no os ocurra lo mismo

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

[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

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

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

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

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

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

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