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

[skatologiko]

Empezado por skatologiko

Una pregunta que supongo que ya habrá salido , pero que no encuentro por ningún lado. Cuando envío el XML a Guipúzcoa de una factura con la librería Chilkat, recibo una cadena de texto que contiene el IdentificadorTBAI (con la forma TBAI-XXXXXXXX-XXXXXX-XXXXXXXX), que es con lo que genero la Url y el posterior QR. Pero sin embargo, como a Vizcaya hay que enviar un archivo comprimido,y lo hago utilizando curl, sólo recibo un fichero que no contiene nada similar ¿de dónde sale el IdentificadorTBAI en Vizcaya?

Me contesto a mí mismo:
1. Especificaciones del código identificativo
El código identificativo identifica a la factura o justificante generado mediante la utilización del software
garante y asegura su relación con su correspondiente fichero de alta de operación con software garante al
que se refiere el artículo 3 de la presente Orden Foral.
Tiene una longitud fija de 39 caracteres.
El tipo y el tamaño de la fuente del código identificativo deberán ser similares al del resto de la factura o
justificante, asegurando su legibilidad por parte de su destinatario o destinataria.
El contenido del código identificativo es el siguiente:
─ 4 caracteres de texto fijo en mayúscula: TBAI.
─ 1 carácter “- “como separador. Guion medio.
─ 9 caracteres del NIF de la persona o entidad emisora de la factura o justificante.
Debe corresponder con el NIF, según su formato oficial, incluido en el fichero TBAI.
─ 1 carácter “- “como separador. Guion medio.
─ 6 caracteres de la fecha de expedición de la factura o justificante.
Debe corresponder con la fecha incluida en el fichero de alta de operación con software garante, en el
campo denominado “FechaExpedicionFactura”, en formato DDMMAA, sin separadores internos.
Cada uno de los subcampos será rellenado con ceros a la izquierda en caso de ser necesario, de manera
que el tamaño de la fecha será siempre 6 números en todos los casos (por ejemplo, 010122 sería uno
de enero de 2022).
El formato DDMMAA se compone de: DD: día de la expedición de la factura, MM: mes de la expedición
de la factura y AA: últimos dos dígitos del año de expedición de la factura. Por ejemplo, para 2021,
AA=21.
─ 1 carácter “- “como separador. Guion medio.
─ 13 primeros caracteres de la firma del fichero de alta de operación con software garante, es decir, del
campo “SignatureValue” del fichero correspondiente a la factura o justificante.
─ 1 carácter “- “como separador. Guion medio.
─ 3 caracteres que se corresponden con un código de d

[SuperUKO]

Empezado por keys

Hola a todos.

No se si alguien esta enviando el modelo 140 de Bizkaia, la parte que no es de TicketBAI. Ayer nos encontramos a un cliente que estaba intentando enviar un registro al libro de Provisiones y suplidos, y nos encontramos que le da un error de que el libro no estaba disponible. Hicimos la pregunta a hacienda y nos responden lo siguiente.



Con dos ..... Luego nos piden a nosotros que nos adaptemos a todo lo que dicen y ellos no tienen todo desarrollado.

Buenas, Keys.


Pues no te puedo decir si funciona en postproducción, pero acabo de probar a mandar un Suplido del 2022 en desarrollo y va perfecto.

[keys]

Empezado por SuperUKO

Buenas, Keys.


Pues no te puedo decir si funciona en postproducción, pero acabo de probar a mandar un Suplido del 2022 en desarrollo y va perfecto.

Ese es el problema, lo han añadido en desarrollo, en la pagina web del LROE, pero no en producción para los clientes.

[keys]

Hola a todos.

En Bizkaia a la hora de hacer un envío hay definidos unos "Códigos de respuesta HTTP para errores de cliente" como son el

400 Bad Request - Petición bloqueada por superar el tamaño máximo permitido del fichero (20 MB)
403 Forbidden - Se ha denegado el acceso al obligado tributario por haber detectado incidencias en sus envíos
429 Too Many Requests - El servicio ha alcanzado el número máximo de peticiones concurrentes permitidas, inténtelo más tarde

Cuando estos se producen el servidor no retorna nada dentro de la cabecera de respuesta ni devuelve ningún xml con la respuesta. ¿Alguien sabe en Delphi realizando el envio con TNetHTTPClient, donde se reciben estos resultados?

En HeaderValue[0] retorna solo Keep-Alive

[keys]

Hola a todos me respondo a mi mismo aunque no estoy seguro ya que no lo puedo probar.

AResponse.StatusCode Creo que es donde retorna esos códigos de error.

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

Revisa el Headers del Response. Si ahí no hay nada, sólo queda (como tú has dicho) el StatusCode y StatusText.

[ermendalenda]

Buenas tardes, una cosilla sin importancia. Para el 2024 comienza un cambio (similar al del efecto 2000) lo conocerán mejor los que eran informáticos en esa fecha.
El cambio es a nivel de criptografía y va a afectar hasta los routers.
No será de un día para otro, pero tened previsto que los actuales certificados electrónicos tendrán otros tipos de clave pública y privada, los dni electrónicos etc etc etc.
Pero no os asustéis no será de un día para otro
Solo lo digo para que no os relajeis.

[popemonica]

Hola de nuevo a tod@s
Una duda que me ha surgido y ante la cual no encuentro información.

Imaginaros que he hecho una factura Modelo 240 y la he enviado a Hacienda.
Ahora resulta que me he dado cuenta de que he cobrado de más y que tengo que hacerle una abono al cliente.

hablando con la empresa para la cual estoy adecuando la app, me dice que ellos hacen una factura de abono, es decir con importe negativo.
Hasta ahí no hay ningún problema.

la duda que me entra es si esto es correcto de cara a seguir con los protocolos de TicketBAI.
Es decir, yo puedo emitir esa factura (con importe negativo) a hacienda, igual que hago con una factura normal?

Es que a la hora de generar el xml no encuentro nada que me diga si los valores que van en ese xml cambian o no con respecto a una normal.
Para anulacion de facturas si que hay ejemplos de xml pero para este caso yo no he encontrado nada.

Lo mismo me ocurre con el xml que se genera para el LROE (es decir el envio)

Alguien me podría echar un cable?

Gracias

[keys]

Empezado por popemonica

Hola de nuevo a tod@s
Una duda que me ha surgido y ante la cual no encuentro información.

Imaginaros que he hecho una factura Modelo 240 y la he enviado a Hacienda.
Ahora resulta que me he dado cuenta de que he cobrado de más y que tengo que hacerle una abono al cliente.

hablando con la empresa para la cual estoy adecuando la app, me dice que ellos hacen una factura de abono, es decir con importe negativo.
Hasta ahí no hay ningún problema.

la duda que me entra es si esto es correcto de cara a seguir con los protocolos de TicketBAI.
Es decir, yo puedo emitir esa factura (con importe negativo) a hacienda, igual que hago con una factura normal?

Es que a la hora de generar el xml no encuentro nada que me diga si los valores que van en ese xml cambian o no con respecto a una normal.
Para anulacion de facturas si que hay ejemplos de xml pero para este caso yo no he encontrado nada.

Lo mismo me ocurre con el xml que se genera para el LROE (es decir el envio)

Alguien me podría echar un cable?

Gracias

Puedes hacer eso, pero no es de todo correcto. Ya que en este caso lo que hay que hacer una rectificativa. Puedes miar la FAQ 48 de TicketBai de Bizkaia.

[adolphsys]

Empezado por keys

Hola a todos.

Perdonar pero sigo con mi lucha con los suplidos. He realizado la consulta a cada hacienda y en Gipuzkoa me han contestado una cosa y en Bizkaia otra.

Bizkaia

Gipuzkoa


Alguien se aclara?

Hola keys, como en tu estudio solo te falta Álava, te informo que el 19/10/2021 me respondieron esto:

Hemos seguido pensando sobre la duda que nos planteó y creemos que no es necesario que introduzca una línea de detalle con el importe suplido (no sujeto).

Perdone las molestias

Quedamos a su disposición

Primero me dijeron que los suplidos debían ser incluidos en el cuerpo como base no sujeta, pero entonces daba un error de validación de negocio, así que finalmente no hay que incluir los importes suplidos.

[keys]

A mi en Alava me respodieron lo siguiente :

En el supuesto de que únicamente se quisiera documentar un suplido, se trataría de una operación en la que no se documenta ninguna entrega de bienes ni prestación de servicios realizada por el profesional en el desarrollo de su actividad, ya que en estos casos el empresario actuaría como mero intermediario, satisfaciendo sumas de dinero del cliente a un tercero por mandato expreso.

En este caso, no habría obligación de expedir factura de acuerdo con lo dispuesto en el Reglamento de facturación, pudiéndose documentar la operación en un recibo u otro justificante.
Por tanto, un documento en el que solo se informe de un suplido quedaría fuera del ámbito de aplicación de TicketBAI.

Cuando en una factura además de los honorarios de un profesional se documentase un suplido, el importe del suplido no formaría parte de la base imponible del IVA pero estas facturas deben cumplir igualmente los requisitos TicketBAI.
En este supuesto caben dos posibilidades:
a) Incluir el suplido en una nueva línea de detalle, indicándolo como NO SUJETA", causa "OT No sujeto por el artículo 7 de la Norma Foral de IVA Otros supuestos de no sujeción"

b) Incluir el suplido en la factura a entregar al cliente pero no trasladarlo al fichero XML, puesto que no hay un campo específico para este concepto ni es obligatorio informarlo. En esta opción el “Total Factura” del dichero XML no va a coincidir con el importe total a pagar que aparezca en la factura que se entrega al cliente, por lo que para evitar problemas a la hora de comprobar el código QR por parte de ese cliente se recomendaría que, en la factura que se le entrega, se indicara como “Total Factura” el importe sin el suplido, en una línea posterior se consignara el importe del suplido, y en una última línea se indicara “importe total a pagar” con la suma de: Total Factura + Importe del Suplido.

Es decir una mezcla de bizkaia y Gipuzkoa. Por cierto me respodieron el 4 de abril de 2022

[popemonica]

Empezado por keys

Puedes hacer eso, pero no es de todo correcto. Ya que en este caso lo que hay que hacer una rectificativa. Puedes miar la FAQ 48 de TicketBai de Bizkaia.

Muchas gracias por la respuesta.

No tendrá alguien un xml generado de una factura rectificativa por sustitución, para ver como es la estructura de dicho xml verdad?

es que me sería de grana ayuda.

Muchas gracias

[trumbolt]

Buenas compañeros,

Aquí otro de los visitantes ocultos recurrentes que ha tenido que registrarse gracias al cachondeo padre que parece ser el sistema de TicketBAI, con especificidades para cada una de las provincias, como si no fuera bastante trabajo el adaptar un software para que cumpla sus requisitos de firma y envío. Veo que no estoy sólo en ello y si bien no arregla nada, las penas compartidas son menos penas, o eso dicen

Ya que estoy por aquí, intentaré ser lo más productivo que pueda a la comunidad e intentar aportar tb mi conocimiento a fin de ayudar a quien lo necesite.

Y ya de paso, quería agradecer tanto a @keys como a @espinete todo lo que han escrito sobre las SecureBlackBox, la punta de lanza en la que me he apoyado para montar mi desarrollo en C++. Muchas gracias . La verdad es que es una jodienda que no haya apenas ejemplos para la nueva versión 20 y casi todo lo que se encuentra es para la 16.

Por cierto, con la SecureBlackBox, únicamente se generan dos digest en el xml pero por lo que me ha parecido entender tras las ¡¡¡ 153 !!! páginas es que tira bien con eso aunque el ejemplo que se puede descargar de Batuz tenga 3, ¿verdad?. Yo de todas formas he escrito a nsoftware para que me orienten sobre cómo se podría agregar uno nuevo (quizás con AddReference() ) si fuera posible.

[skatologiko]

Una pregunta, estoy intentando enviar tickets de caja a Batuz, y lo hago igual que las facturas normales pero marcando
"<FacturaSimplificada>S</FacturaSimplificada>" y aún sí me pide establecer el Nif del destinatario. ¿cómo hacéis para enviar un ticket del cual no sabemos el nif?

[trumbolt]

Empezado por trumbolt

Buenas compañeros,

Aquí otro de los visitantes ocultos recurrentes que ha tenido que registrarse gracias al cachondeo padre que parece ser el sistema de TicketBAI, con especificidades para cada una de las provincias, como si no fuera bastante trabajo el adaptar un software para que cumpla sus requisitos de firma y envío. Veo que no estoy sólo en ello y si bien no arregla nada, las penas compartidas son menos penas, o eso dicen

Ya que estoy por aquí, intentaré ser lo más productivo que pueda a la comunidad e intentar aportar tb mi conocimiento a fin de ayudar a quien lo necesite.

Y ya de paso, quería agradecer tanto a @keys como a @espinete todo lo que han escrito sobre las SecureBlackBox, la punta de lanza en la que me he apoyado para montar mi desarrollo en C++. Muchas gracias . La verdad es que es una jodienda que no haya apenas ejemplos para la nueva versión 20 y casi todo lo que se encuentra es para la 16.

Por cierto, con la SecureBlackBox, únicamente se generan dos digest en el xml pero por lo que me ha parecido entender tras las ¡¡¡ 153 !!! páginas es que tira bien con eso aunque el ejemplo que se puede descargar de Batuz tenga 3, ¿verdad?. Yo de todas formas he escrito a nsoftware para que me orienten sobre cómo se podría agregar uno nuevo (quizás con AddReference() ) si fuera posible.

Se me olvidó incluir al compi @juramisa

Aprovecho para incluir los hashes actualizados porque veo que algunos errores de validación (sobretodo en Batuz) vienen de usar un hash antiguo en la política de firma. Es el problema de usar código de hace unos meses, que uno se confía y resulta que lo han cambiado.

Cuando tenga permisos para publicar urls, también las añadiré para tenerlo todo en el mismo sitio ...

Araba
Hash: d69VEBc4ED4QbwnDtCA2JESgJiw+rwzfutcaSl5gYvM=
Hash en Hex: 77AF55101738103E106F09C3B420362444A0262C3EAF0CDFBAD71A4A5E6062F3

Gipuzkoa
Hash: vSe1CH7eAFVkGN0X2Y7Nl9XGUoBnziDA5BGUSsyt8mg=
Hash en Hex: BD27B5087EDE00556418DD17D98ECD97D5C6528067CE20C0E411944ACCADF268

Bizkaia
Hash: Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=
Hash en Hex: 42ECE7F7CC773CC6D21F06D4CDA8F97F928EA621F4BBC6EF9B06DB6CD90EF44B

Otro error es usar el hash pero en minúsculas. Al parecer es case sensitive la validación.

[trumbolt]

Empezado por rci

Hola, pregunté a la agencia sobre el tema y acabo de recibir respuesta:
Como podeis comprobar, no me han dado ninguna información del caso que nos reportaron y realmente su respuesta tampoco sirve para nada.

¿Descubriste al final qué cliente estaba firmando mal?. ¿No te proporcionaron ni el CIF del emisor para que pudieras al menos poder contactar con el cliente y solucionar el problema?

Y sobre el tema de la comprobación del CIF, yo el problema que le veo es que si el certificado es de algún tipo de representante registrado en TBAI su CIF no va a coincidir de ninguna manera y será imposible detectar este tipo de problemas.

Y ya por curiosidad mía. Siendo un "software garante" que emite facturas rechazadas, ¿puede acarrear algún tipo de sanción sobre el fabricante del programa?

[Nessie]

Hola,
al anular facturas en el entorno de pruebas, Gipuzkoa me devuelve siempre el error 13 (Falta aceptar el Registro del Dispositivo remitente. Acceda a la sede electrónica y gestione el dispositivo.).


Al estar en el entorno de pruebas, no puedo verificar ningún dispositivo.


¿Habéis tenido algún problema al anular facturas en el entorno de pruebas en Gipuzkoa? ¿Os funciona bien?


Un saludo.
Gracias.

[Sistel]

Empezado por skatologiko

Una pregunta, estoy intentando enviar tickets de caja a Batuz, y lo hago igual que las facturas normales pero marcando
"<FacturaSimplificada>S</FacturaSimplificada>" y aún sí me pide establecer el Nif del destinatario. ¿cómo hacéis para enviar un ticket del cual no sabemos el nif?

Hola skatologiko,

No añadas en el XML el nodo <Destinatarios>
Fíjate en https://www.gipuzkoa.eus/documents/2...28/Anexo+I.pdf que está en negro (no es obligatorio en el caso de facturas simplificadas)
Eso es todo.

Saludos

[edari]

Empezado por Nessie

Hola,
al anular facturas en el entorno de pruebas, Gipuzkoa me devuelve siempre el error 13 (Falta aceptar el Registro del Dispositivo remitente. Acceda a la sede electrónica y gestione el dispositivo.).


Al estar en el entorno de pruebas, no puedo verificar ningún dispositivo.


¿Habéis tenido algún problema al anular facturas en el entorno de pruebas en Gipuzkoa? ¿Os funciona bien?


Un saludo.
Gracias.

Acabo de hacer una prueba y me la anula correctamente.



Lo raro es que te dé error de dispositivo remitente para la anulación y no para la alta.

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

Empezado por trumbolt

Aprovecho para incluir los hashes actualizados...

Los he añadido a la página inicial (mensaje 1) con el resto de datos.

Empezado por trumbolt

Cuando tenga permisos para publicar urls, también las añadiré ...

Gracias.
Si debes añadir alguna URL, puedes ponerla cambiando (por ejemplo) la parte inicial por h_t_t_p:/_/ (o algo similar)
Luego algunos de los moderadores la editamos y la ponemos correctamente.