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

[tejano]

Buenos días,
Sabe alguien responderme a estas preguntas?

Cabecera HTTP de la petición del LROE

• Cuando enviamos los fichero a la DFB, en la cabera de HTTP, el contenido del json pide la Razón social de la empresa campo “nrs”, en nuestro caso es TECNICAS DE REFRACTARIOS S.A.U, debo poner algún carácter en los espacios, si lo dejo en blanco da problemas y si pongo un guion bajo parece que va bien.
• El certificado que tenemos es de representante, es necesario rellenar los datos de PRIMER APELLIDO “ap1” y SEGUNDO APELLIDO “ap2” con los apellidos del representante que hay en el certificado.
• Por último en “Content-Length” que tamaño hay que poner el del fichero gz??, y en que unidad Bytes, KBytes, …..

Gracias

[sline]

Hola
El formato json tiene que ser sin saltos de línea:

{"con": "LROE", "apa": "1.1", "inte": {"nif": "B00000034","nrs": "HOTEL ADIBIDEZ"},"drs": {"mode": "240","ejer": "2022"}}

en vez de

{
   "con": "LROE",
   "apa": "1.1",
   "inte": {
     "nif": "B00000034",
     "nrs": "HOTEL ADIBIDEZ",
   },
   "drs": {
     "mode": "240",
     "ejer": "2022"
   }
}

Prueba a quitar los "." y dejarlo "TECNICAS DE REFRACTARIOS SAU"

Empezado por tejano

Buenos días,
Sabe alguien responderme a estas preguntas?

Cabecera HTTP de la petición del LROE

• Cuando enviamos los fichero a la DFB, en la cabera de HTTP, el contenido del json pide la Razón social de la empresa campo “nrs”, en nuestro caso es TECNICAS DE REFRACTARIOS S.A.U, debo poner algún carácter en los espacios, si lo dejo en blanco da problemas y si pongo un guion bajo parece que va bien.
• El certificado que tenemos es de representante, es necesario rellenar los datos de PRIMER APELLIDO “ap1” y SEGUNDO APELLIDO “ap2” con los apellidos del representante que hay en el certificado.
• Por último en “Content-Length” que tamaño hay que poner el del fichero gz??, y en que unidad Bytes, KBytes, …..

Gracias

[sline]

Estoy realizando consultas a lroe a batuz pero siempre tengo el mismo resultado:

eus-bizkaia-n3-mensaje-respuesta: Operación errónea.
eus-bizkaia-n3-codigo-respuesta: B4_1000025
eus-bizkaia-n3-numero-registro: 
eus-bizkaia-n3-tipo-respuesta: Incorrecto

El xml que uso para enviar es el mismo que el del ejemplo (cambiando lo necesario) Ejemplo_Consulta_1_LROE_PJ_240_FacturasEmitidasConSG_B00000034.xml



¿A alguien mas le pasa?

[Band]

Yo me estoy encontrando con que me devuelve esta respuesta al hacer un envío con uno de los ejemplos de prueba (concretamente este fichero, aunque me pasa con todos "Ejemplo_TicketBAI_79732487C_A2022_0399.xml"):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>28-05-2021 17:28:52</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. No se ha podido procesar el mensaje. Detalle del error: Content is not allowed in prolog.</Descripcion>
            <Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Mezua ezin da prozesatu. Errorearen xehetasuna: Content is not allowed in prolog.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

A alguien le ha pasado o sabe a qué puede ser debido? Obviamente ya veo que el error dice eso de que no cumple el esquema XSD, pero es un fichero generado por ellos que en teoría está bien y no veo ningún caràcter especial, ni ninguna pista como para ver que el fichero no es válido.

[landaga]

Empezado por Band

Yo me estoy encontrando con que me devuelve esta respuesta al hacer un envío con uno de los ejemplos de prueba (concretamente este fichero, aunque me pasa con todos "Ejemplo_TicketBAI_79732487C_A2022_0399.xml"):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>28-05-2021 17:28:52</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. No se ha podido procesar el mensaje. Detalle del error: Content is not allowed in prolog.</Descripcion>
            <Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Mezua ezin da prozesatu. Errorearen xehetasuna: Content is not allowed in prolog.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

A alguien le ha pasado o sabe a qué puede ser debido? Obviamente ya veo que el error dice eso de que no cumple el esquema XSD, pero es un fichero generado por ellos que en teoría está bien y no veo ningún caràcter especial, ni ninguna pista como para ver que el fichero no es válido.

Si no lo has hecho ya prueba a poner al principio, antes de la cabecera del xml, los siguientes tags y atributos:


<?xml version="1.0" encoding="UTF-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="htxp://ww.w3.org/2000/09/xmldsig#" xmlns:xsi="htxp://ww.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="htxp://ww.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">


(las url llevan una x donde debería ir una t y falta una w para que me permita enviar el mensaje)

[sline]

Hola Band


Tuve ese mismo problema y era porque generaba el xml con una etiqueta en diferente orden al que aparecía en el xsd.



Saludos.

Empezado por Band

Yo me estoy encontrando con que me devuelve esta respuesta al hacer un envío con uno de los ejemplos de prueba (concretamente este fichero, aunque me pasa con todos "Ejemplo_TicketBAI_79732487C_A2022_0399.xml"):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>28-05-2021 17:28:52</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. No se ha podido procesar el mensaje. Detalle del error: Content is not allowed in prolog.</Descripcion>
            <Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Mezua ezin da prozesatu. Errorearen xehetasuna: Content is not allowed in prolog.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

A alguien le ha pasado o sabe a qué puede ser debido? Obviamente ya veo que el error dice eso de que no cumple el esquema XSD, pero es un fichero generado por ellos que en teoría está bien y no veo ningún caràcter especial, ni ninguna pista como para ver que el fichero no es válido.

[HerensugeBeltz]

Empezado por Band

Yo me estoy encontrando con que me devuelve esta respuesta al hacer un envío con uno de los ejemplos de prueba (concretamente este fichero, aunque me pasa con todos "Ejemplo_TicketBAI_79732487C_A2022_0399.xml"):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>28-05-2021 17:28:52</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. No se ha podido procesar el mensaje. Detalle del error: Content is not allowed in prolog.</Descripcion>
            <Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Mezua ezin da prozesatu. Errorearen xehetasuna: Content is not allowed in prolog.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

A alguien le ha pasado o sabe a qué puede ser debido? Obviamente ya veo que el error dice eso de que no cumple el esquema XSD, pero es un fichero generado por ellos que en teoría está bien y no veo ningún caràcter especial, ni ninguna pista como para ver que el fichero no es válido.

A mí me pasaba haciendo pruebas con los componentes Chilkat.
El error te dice que hay algún carácter antes de la etiqueta inicial del xml (<?xml version="1.0"...)
El problema puede estar relacionado con el BOM del fichero UTF-8 (si lo tiene prueba a quitárselo). Comprueba que el juego de caracteres del XML sea UTF-8 y no ISO8859-1, por ejemplo. Yo sinceramente no encontré la solución ya que finalmente opté por los componentes de SecureBlackBox.

[Band]

Empezado por HerensugeBeltz

A mí me pasaba haciendo pruebas con los componentes Chilkat.
El error te dice que hay algún carácter antes de la etiqueta inicial del xml (<?xml version="1.0"...)
El problema puede estar relacionado con el BOM del fichero UTF-8 (si lo tiene prueba a quitárselo). Comprueba que el juego de caracteres del XML sea UTF-8 y no ISO8859-1, por ejemplo. Yo sinceramente no encontré la solución ya que finalmente opté por los componentes de SecureBlackBox.

Gracias a landaga, sline, HerensugeBeltz por las respuestas. Al final y después de asegurarme del tema del BOM del fichero, temas de encoding, caracteres extraños que pudieran haber delante de la declaración xml, etc... di con el problema que para mi caso es particular. Os pongo mi solución por si a alguien más le pasa y usa curl para enviar.

Yo usaba para enviar el fichero este parámetro (repito, con curl):

Código Delphi [-]
-F "data=@' + nombreArchivo + '" '

y la solución ha sido cambiarlo por:

Código Delphi [-]
-d "@' + nombreArchivo + '" '

No me lo he mirado con detalle pero imagino que en el primer caso le debe estar colando algo en el envío, cosa que no hace en el segundo caso.

[Noe277]

Buenos días,

Se me plantea una duda existencial.
En Gipuzkoa yo genero el xml lo firmo, lo envió y me devuelve el Qr. Entonces imprimo la factura con el Qr.

Pero en BIZKAIA:
Genero el xml, lo firmo y a los 3 meses o cuando sea lo envió en el modelo 140/240.
¿Las facturas al imprimir no van a llevar el Qr?
No se si estoy entendiendo el proceso en Bizkaia.

[tejano]

Empezado por Band

Gracias a landaga, sline, HerensugeBeltz por las respuestas. Al final y después de asegurarme del tema del BOM del fichero, temas de encoding, caracteres extraños que pudieran haber delante de la declaración xml, etc... di con el problema que para mi caso es particular. Os pongo mi solución por si a alguien más le pasa y usa curl para enviar.

Yo usaba para enviar el fichero este parámetro (repito, con curl):

Código Delphi [-]
-F "data=@' + nombreArchivo + '" '

y la solución ha sido cambiarlo por:

Código Delphi [-]
-d "@' + nombreArchivo + '" '

No me lo he mirado con detalle pero imagino que en el primer caso le debe estar colando algo en el envío, cosa que no hace en el segundo caso.

Buenos días Band, puedes enviar como te quedaría el curl?, yo también estoy intentando utilizarlo y más ahora que ese comando viene que el mismo Windows.
Cuando lo envío me da el error 400 de Bad Request.
Graciasssssss!!!!

[landaga]

Empezado por sline

Estoy realizando consultas a lroe a batuz pero siempre tengo el mismo resultado:

eus-bizkaia-n3-mensaje-respuesta: Operación errónea.
eus-bizkaia-n3-codigo-respuesta: B4_1000025
eus-bizkaia-n3-numero-registro: 
eus-bizkaia-n3-tipo-respuesta: Incorrecto

El xml que uso para enviar es el mismo que el del ejemplo (cambiando lo necesario) Ejemplo_Consulta_1_LROE_PJ_240_FacturasEmitidasConSG_B00000034.xml



¿A alguien mas le pasa?

A Bizkaia no puedes enviar el XML directamente, tienes que mandarlo comprimido en formato gzip.

[sline]

Lo mando en formato gzip.

Empezado por landaga

A Bizkaia no puedes enviar el XML directamente, tienes que mandarlo comprimido en formato gzip.

[jaiser]

Estoy intentando enviar un xml-tbai a la url de pruebas de guipuzkoa "h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta" y al obtener la respuesta me da error 503 servidor no disponible. Llevo varios días intentadolo y me da error todo el rato, a alguien le pasa o le ha pasado lo mismo?. Probe a mandar al real y hay si que me respondía, luego me indicaron que no mandará pruebas al real, pero al de pruebas me da error todo el rato.

[HerensugeBeltz]

Empezado por jaiser

Estoy intentando enviar un xml-tbai a la url de pruebas de guipuzkoa "h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta" y al obtener la respuesta me da error 503 servidor no disponible. Llevo varios días intentadolo y me da error todo el rato, a alguien le pasa o le ha pasado lo mismo?. Probe a mandar al real y hay si que me respondía, luego me indicaron que no mandará pruebas al real, pero al de pruebas me da error todo el rato.

Yo acabo de mandar varios ficheros de prueba sin problema a la Hacienda de Gipuzkoa.

[landaga]

Empezado por sline

Estoy realizando consultas a lroe a batuz pero siempre tengo el mismo resultado:

eus-bizkaia-n3-mensaje-respuesta: Operación errónea.
eus-bizkaia-n3-codigo-respuesta: B4_1000025
eus-bizkaia-n3-numero-registro: 
eus-bizkaia-n3-tipo-respuesta: Incorrecto

El xml que uso para enviar es el mismo que el del ejemplo (cambiando lo necesario) Ejemplo_Consulta_1_LROE_PJ_240_FacturasEmitidasConSG_B00000034.xml



¿A alguien mas le pasa?

Puede ser que estes intentando hacer una Consulta de algo de lo que no has enviado el Alta?

[tejano]

Empezado por landaga

Puede ser que estes intentando hacer una Consulta de algo de lo que no has enviado el Alta?

Gracias landaga, creo que ya estoy más cerca.

Ahora me da el error N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.

Sabéis a que puede ser debido?

[Sistel]

Empezado por tejano

Gracias landaga, creo que ya estoy más cerca.

Ahora me da el error N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.

Sabéis a que puede ser debido?

Hola,

Creo que puede ser porque el que envía (con su certificado) el LROE no es el mismo que emite la factura.

En ese caso, se precisa que el emisor de la factura haya autorizado al que la envía en el LROE.

Hay un registro de apoderamientos para poder realizar esos envíos en representación del emisor de la factura:
https://www.euskadi.eus/registro-ele...web01-sede/es/
(Aunque no sé si ese registro sirve para apoderar en el caso de Batuz)

Saludos

[Sistel]

Empezado por Sistel

Hola,

Creo que puede ser porque el que envía (con su certificado) el LROE no es el mismo que emite la factura.

En ese caso, se precisa que el emisor de la factura haya autorizado al que la envía en el LROE.

Hay un registro de apoderamientos para poder realizar esos envíos en representación del emisor de la factura:
https://www.euskadi.eus/registro-ele...web01-sede/es/

Saludos

Ampliando un poco más el tema.

Hace tiempo hicimos una consulta a BATUZ:
¿Podríamos emplear, también, para el envío de los LROE, correspondientes a nuestros clientes, nuestro certificado digital en lugar del de cada contribuyente?

La respuesta es Sí.

Aun no se han publicado las órdenes forales que regulan el envío de las anotaciones al LROE. No obstante, en el texto de las mismas se recogerán dos situaciones distintas, ya previstas en la actualidad en relación con el SII, y que se trasladarán igualmente a Batuz:

- El suministro electrónico de las anotaciones al LROE podrá ser efectuado por un tercero o tercera que actúe en representación del contribuyente, de acuerdo con lo establecido en la normativa tributaria.
- Asimismo, al igual que en el SII, el Departamento de Hacienda y Finanzas habilitará el suministro electrónico de las anotaciones al LROE en representación de terceras personas a las entidades que lo soliciten a través del formulario electrónico que se apruebe al efecto. En particular, si se utiliza esta figura, los estatutos de las sociedad solicitante deberán completar, dentro de las actividad que conforman su objeto social, la realización de actividades de representación.
- En estos dos casos de representación, la entidad representante podrá utilizar su propio certificado para realizar los envíos.

Saludos

[landaga]

Empezado por tejano

Buenos días,
Sabe alguien responderme a estas preguntas?

Cabecera HTTP de la petición del LROE

• Cuando enviamos los fichero a la DFB, en la cabera de HTTP, el contenido del json pide la Razón social de la empresa campo “nrs”, en nuestro caso es TECNICAS DE REFRACTARIOS S.A.U, debo poner algún carácter en los espacios, si lo dejo en blanco da problemas y si pongo un guion bajo parece que va bien.
• El certificado que tenemos es de representante, es necesario rellenar los datos de PRIMER APELLIDO “ap1” y SEGUNDO APELLIDO “ap2” con los apellidos del representante que hay en el certificado.
• Por último en “Content-Length” que tamaño hay que poner el del fichero gz??, y en que unidad Bytes, KBytes, …..

Gracias

- Tienes que poner comillas en la razon social y puedes dejar los espacios y los puntos: "TECNICAS DE REFRACTARIOS S.A.U"
- "ap1" y "ap2" sólo si corresponden a la razón social, no tienen relación con el certificado.

- El Content-Lenght es el del fichero gz en Bytes pero por una razón que no llego a comprender no hace falta que lo pongas tu porque se asigna en el envío (al menos es lo que me sucede a mi y es donde estoy fallando....)