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

[[duilioisola]]

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

Código PHP:

<?xml version="1.0" encoding="utf-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision">
    <Cabecera>
        <IDVersionTBAI>1.2</IDVersionTBAI>
    </Cabecera>
...
</T:TicketBai>

Te lo adjunto al mensaje

Gracias Germán,

Lo he comparado con lo que genero yo y son iguales, excepto la parte de la firma, donde la estructura es un poco diferente.
Como parece que lo aceptan, no voy a mirar eso mucho más.

De todos modos, me refería al envío del Libro de Registro.
Esto lo formo con una parte JSON en la cabecera

{
  "con":"LROE",
  "apa":"1.1",
  "inte":{
    "nif":"B95642500",
    "nrs":"ECOTHERM ENERGY SL",
    "ap1":"",
    "ap2":""
  },
  "drs":{
    "mode":"240",
    "ejer":"2022"
  }
}

y luego un XML que contiene el TicketBAI comprimido y convertido a Base64 dentro del tag <FacturasEmitidas><FacturaEmitida><TicketBai>:

<?xml version="1.0"?>
<lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns:lrpjfecsgap="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_2.xsd">
  <Cabecera>
    <Modelo>240</Modelo>
    <Capitulo>1</Capitulo>
    <Subcapitulo>1.1</Subcapitulo>
    <Operacion>A00</Operacion>
    <Version>1.0</Version>
    <Ejercicio>2022</Ejercicio>
    <ObligadoTributario>
      <NIF>B95642500</NIF>
      <ApellidosNombreRazonSocial>ECOTHERM ENERGY SL</ApellidosNombreRazonSocial>
    </ObligadoTributario>
  </Cabecera>
  <FacturasEmitidas>
    <FacturaEmitida>
      <TicketBai>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48VDpUaWNrZXRC
YWkgeG1sbnM6VD0idXJuOnRpY2tldGJhaTplbWlzaW9uIj4KCTxDYWJlY2VyYT4K
...
PjwvZHM6T2JqZWN0PjwvZHM6U2lnbmF0dXJlPjwvVDpUaWNrZXRCYWk+
</TicketBai>
    </FacturaEmitida>
  </FacturasEmitidas>
</lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion>

[Ja Mon]

Saludos a todos y gracias por vuestra ayuda.


La duda que no me ha quedado clara leyendo los post es si, tras enviar el fichero firmado, nos devuelve un mensaje de error.
1. Si el error es de datos, creo que el fichero se acepta y queda registrado. (¿y que hay que hacer en este caso?)

2. Si el error es por otra causa y es rechazado (error en el formato o la firma por ejemplo) ¿queda registrado y su signaturevalue es válida para la siguiente factura? Supongo que no, pero no me ha quedado claro que ocurre en este caso.


El proceso que voy a seguir para realizar los envios es este, por si a alguien le sirve de ayuda y por si veis que hay algo que corregir:
Primero creo el fichero XML desde la factura sin los datos de encadenamiento y luego los recupero con otro programa que hace lo siguiente:

1. Lee el fichero XML
2. Busca la ultima factura procesada
3. Guarda los datos de encadenamiento
4. Firma el fichero

5. Envía el fichero
6. Si el resultado es correcto
a. Actualiza la ultima factura

b. Imprimo o envío la factura
c. Muevo el fichero xml a otro directorio

Si el resultado es incorrecto
a. Borro el fichero XML
b. Notifico el error
7. Inicio el proceso con el siguiente fichero


Gestionar el encadenamiento desde la misma aplicación de facturación, en entornos con múltiples terminales era una pesadilla, por eso la idea de crear una cola y gestionarla con otra aplicación. No se si ya existe algo así


Muchas gracias a todos.

[trumbolt]

Empezado por Ja Mon

Saludos a todos y gracias por vuestra ayuda.


La duda que no me ha quedado clara leyendo los post es si, tras enviar el fichero firmado, nos devuelve un mensaje de error.
1. Si el error es de datos, creo que el fichero se acepta y queda registrado. (¿y que hay que hacer en este caso?)

2. Si el error es por otra causa y es rechazado (error en el formato o la firma por ejemplo) ¿queda registrado y su signaturevalue es válida para la siguiente factura? Supongo que no, pero no me ha quedado claro que ocurre en este caso.


El proceso que voy a seguir para realizar los envios es este, por si a alguien le sirve de ayuda y por si veis que hay algo que corregir:
Primero creo el fichero XML desde la factura sin los datos de encadenamiento y luego los recupero con otro programa que hace lo siguiente:

1. Lee el fichero XML
2. Busca la ultima factura procesada
3. Guarda los datos de encadenamiento
4. Firma el fichero

5. Envía el fichero
6. Si el resultado es correcto
a. Actualiza la ultima factura

b. Imprimo o envío la factura
c. Muevo el fichero xml a otro directorio

Si el resultado es incorrecto
a. Borro el fichero XML
b. Notifico el error
7. Inicio el proceso con el siguiente fichero


Gestionar el encadenamiento desde la misma aplicación de facturación, en entornos con múltiples terminales era una pesadilla, por eso la idea de crear una cola y gestionarla con otra aplicación. No se si ya existe algo así


Muchas gracias a todos.

El problema que veo es que si tienes un error en el envío, borras el xml y estás "sacando" esa factura digamos del correcto encadenamiento. Si la borras, ¿cómo gestionas luego eso?. Aparte que si tienes que imprimir la factura (y necesitas el QR) cómo lo haces cpon esa factira cuyo envio ha fallado? Lo digo porque necesitas la firma para eso.

Teóricamente según TBAI, el software garante tiene que ser capaz de emitir una factura (firmarla e imprimir su QR) sin necesidad de conectarse con ellos (que era el principal problema que había al principio).

En mi caso, hemos desligado la generación, firmado e impresión de la factura del envío que va por un servicio de cola que únicamente se encarga de enviar las facturas que va generando el software y notifica posibles errores para luego poder solventarlos de manera manual, que es la única manera que hemos encontrado ya que automatizar algo es prácticamente imposible ...

[Ja Mon]

Empezado por trumbolt

El problema que veo es que si tienes un error en el envío, borras el xml y estás "sacando" esa factura digamos del correcto encadenamiento. Si la borras, ¿cómo gestionas luego eso?. Aparte que si tienes que imprimir la factura (y necesitas el QR) cómo lo haces cpon esa factira cuyo envio ha fallado? Lo digo porque necesitas la firma para eso.

Teóricamente según TBAI, el software garante tiene que ser capaz de emitir una factura (firmarla e imprimir su QR) sin necesidad de conectarse con ellos (que era el principal problema que había al principio).

En mi caso, hemos desligado la generación, firmado e impresión de la factura del envío que va por un servicio de cola que únicamente se encarga de enviar las facturas que va generando el software y notifica posibles errores para luego poder solventarlos de manera manual, que es la única manera que hemos encontrado ya que automatizar algo es prácticamente imposible ...

Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado.
La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato.

La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.

[Sistel]

Empezado por Ja Mon

Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado.
La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato.

La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.

Hola,

Creo que el procedimiento, como ya han indicado más de una vez los de TicketBAI, no es esperar a conseguir que el sistema informático de Hacienda Foral dé el visto bueno al XML firmado y enviado.
Se trata de:
- Recopilar los datos para emitir la factura (la factura no está emitida, realmente, hasta que no se ha obtenido el XML firmado)
- Crear el XML
- Firmarlo (ahora es cuando la factura está realmente emitida)
- Recopilar los datos de códigos TBAI y QR a partir de los datos del XML firmado
- Imprimir o enviar la factura al destinatario con los códigos TBAI y QR.
- Y, a continuación, enviar el XML firmado a Hacienda.

Que Hacienda dé por bueno o no el XML es independiente: la factura ya está emitida.
Si Hacienda da por bueno el XML recibido, genial.
Si Hacienda no lo da por bueno, dependiendo del tipo de código que retorne, habrá que hacer una u otra cosa. Pero la factura ya está emitida y va a misa.

Saludos

[Ja Mon]

Empezado por Sistel

Hola,

Creo que el procedimiento, como ya han indicado más de una vez los de TicketBAI, no es esperar a conseguir que el sistema informático de Hacienda Foral dé el visto bueno al XML firmado y enviado.
Se trata de:
- Recopilar los datos para emitir la factura (la factura no está emitida, realmente, hasta que no se ha obtenido el XML firmado)
- Crear el XML
- Firmarlo (ahora es cuando la factura está realmente emitida)
- Recopilar los datos de códigos TBAI y QR a partir de los datos del XML firmado
- Imprimir o enviar la factura al destinatario con los códigos TBAI y QR.
- Y, a continuación, enviar el XML firmado a Hacienda.

Que Hacienda dé por bueno o no el XML es independiente: la factura ya está emitida.
Si Hacienda da por bueno el XML recibido, genial.
Si Hacienda no lo da por bueno, dependiendo del tipo de código que retorne, habrá que hacer una u otra cosa. Pero la factura ya está emitida y va a misa.

Saludos

Ok. Pero la duda que tengo es para este caso:

Tenemos 3 facturas A,B,C.
Se genera el xml de A, obtenemos el qr y el signature value para introducirlo en B e imprimimos

Se genera el xml de B, obtenemos el qr y el signature value para introducirlo en C e imprimimos

Se genera el xml de C, obtenemos el qr y el signature value para introducirlo en ... e imprimimos


El proceso de validación en TBai nos rechaza el fichero de B y no se registra en TBai (no porque no le gusten los datos si no porque hay un error en la estructura, por ejemplo) cuando ya hemos impreso C y encadenado con signature value de B.
En este caso C estaría encadenando con un fichero que nunca se ha registrado en TBai y el impreso de B tendría un qr que no apuntaría a una url válida.

No se si esto es correcto así y hay una forma de corregirlo posteriormente pero pienso que habría que evitarlo, también para evitar posibles explotaciones maliciosas de este error.

[Sistel]

Empezado por Ja Mon

Ok. Pero la duda que tengo es para este caso:
...
En este caso C estaría encadenando con un fichero que nunca se ha registrado en TBai y el impreso de B tendría un qr que no apuntaría a una url válida.
...

Hola Ja Mon,

El encadenamiento de los XML de facturas es algo que tienes que hacer tú a medida que las vas emitiendo.
Es independiente de que Hacienda después, cuando se las envíes, considere que alguna de ellas no está correcta.
Tú las tienes encadenadas y eso es lo importante.

Puede ser que se te caiga la conexión a Internet, que los servicios de Hacienda Foral no funcionen o que la emisión sea en Bizkaia (normativa Batuz que puede admitir que las facturas se envíen varios meses después de su emisión).
Da igual: tú las tienes numeradas consecutivamente, firmadas y encadenadas.
Si después, cuando consigas enviarlas a Hacienda, te dice que alguna (o todas) tienen errores tienes diversas vías para corregir esos errores sin necesidad de volver a enviar.
(Por ejemplo, en Bizkaia, en el capítulo 1.2 del LROE. O en Gipuzkoa o Alava mediante el servicio Zuzendu).

Pero, en cualquier caso, la emisión de la factura (y su encadenamiento) y la obtención de los códigos TBAI y QR son temas de tu aplicación de facturación e independientes del posterior envío y aceptación (o no) por parte de Hacienda.

Para corregir los errores, después, ya hay otras vías, pero la factura emitida firmada y encadenada es cosa tuya y no se debe poder borrar ni alterar en ningún caso (Nueva Ley General Tributaria Antifraude)

Saludos

[trumbolt]

Empezado por Ja Mon

Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado.
La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato.

La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.

Aunque no ingrese en su sistema (caso de que el xml sea rechazado como indicas) ese XML se corresponde con una factura perfectamente válida ya emitida por el software y como dice @sistel, eso va a misa. Para solventar el problema luego se tendría que realizar un Zuzendu de subsanación en el caso de Guipuzcua y Alava con lo que el QR de esa factura ya emitida y que tendría en poder el cliente, empezaría a funcionar correctamente porque la factura ya estaría "dada de alta" por asi decirlo, en su sistema.

Deberías de diseñar el sistema para que fuese autónomo de manera que si hubiese un problema de conexión (los servidores de IZEMPE se caen o están "en mantenimiento", o la conexión a inet se va por avería), el software pueda seguir emitiendo facturas con encadenamiento, QR e identificador tbai. Eso fue una de las cosas que más me costó entender en un principio ...

[Ja Mon]

Empezado por trumbolt

Aunque no ingrese en su sistema (caso de que el xml sea rechazado como indicas) ese XML se corresponde con una factura perfectamente válida ya emitida por el software y como dice @sistel, eso va a misa. Para solventar el problema luego se tendría que realizar un Zuzendu de subsanación en el caso de Guipuzcua y Alava con lo que el QR de esa factura ya emitida y que tendría en poder el cliente, empezaría a funcionar correctamente porque la factura ya estaría "dada de alta" por asi decirlo, en su sistema.

Deberías de diseñar el sistema para que fuese autónomo de manera que si hubiese un problema de conexión (los servidores de IZEMPE se caen o están "en mantenimiento", o la conexión a inet se va por avería), el software pueda seguir emitiendo facturas con encadenamiento, QR e identificador tbai. Eso fue una de las cosas que más me costó entender en un principio ...

Intuitivamente, me cuesta aceptar entregarle al cliente información potencialmente erronea que pueda suponer un conflicto para el vendedor pero si hacienda no le va a "buscar las cosquillas" pues lo haré así.
Muchas gracias, sistel y trumbold, por la ayuda.

[xamminf]

Hola a todos,

No sé si esto ha sido respondido, pero pregunto

Cuando generamos el .xml, hay alguna forma de saber si es valido o no antes de mandarlo, a nivel de sintaxis y a nivel de informacion.
Si fuera erroneo intentaría rehacerlo y no generar la cadena de .xml erroneo + envio + error en pantalla + llamada del usuario + .xml de anulacion
Lo digo porque sobre todo al principio puedo generar algunos .xml erroneos y claro eso conllevara problemas y quizas anulaciones


Gracias de antemano