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

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

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

Empezado por Galaxian

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.

Correcto.
A esa misma conclusión llegamos nosotros y se lo explicamos con detalle.

No es que ellos compriman 2 veces (que imaginábamos que no) sino que es su servidor o alguna pieza que tienen funcionando vuelve a comprimir lo que envían, de forma que se recibe un doble comprimido.

Les explicamos que no era tema de las librerías que usamos (porque otros usuarios usan otras), ni siquiera de Delphi (porque otros usuarios de otros lenguajes también se encuentran con esto). Todo ello, con los links correspondientes para consultar.
¿Crees que se lo han mirado?
La respuesta fue algo equivalente a "nosotros lo hacemos bien, el resto lo hacéis mal, revisad vuestro código".

Incluso les dijimos que con PostMan se puede comprobar esto. Pues nada, debe ser que la gente de Postman también hacen algo mal...


Otro con algo de seriedad al menos se lo miraría o pediría más datos. Ellos ni eso.