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

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.

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

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

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.

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

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.

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.

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

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.

A mi en Alava me respodieron lo siguiente :

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

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

Dos digest en SecureBlackBox
 

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.

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?

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

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

¿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?

Anulación de facturas en entorno de pruebas
 

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.

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

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.

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

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.

He actualizado en el mensaje 1 del hilo, las que pusimos aquí.
Revisa que sean las mismas que tú tienes y que sean corectas.

Hola a todas.

Deciros que hacienda de bizkaia ya ha habilitado el envio de los suplidos/provisiones en el 140 de producción.

Por otra parte ayer me dieron dos tickets con el codigo QR de Bizkaia, uno en una panaderia y otro en una farmacia. Los dos estaban mal, uno solo contenía el TBAI, no la dirección de hacienda y otro un número que no se veía que era. Por si estais por aqui.

No sé si os ha llegado esta noticia https://www.elcorreo.com/economia/bi...212421-nt.html

Al final nos piden a nosotros que hagamos el trabajo pero ellos siempre lo retrasan.

Hola,

me han contestado de Gipuzkoa. Lo pongo aquí por si a alguien le sirve de ayuda. En pruebas, al utilizar un certificado de dispositivo, hay que mandarles un mail para registrar el dispositivo. En las operaciones de ANULACION, controlan que el dispositivo este registrado.

Un saludo.


RESPUESTA DE HACIENDA GIPUZKOA:

-----------------------------------------------------------------------------

Egun on, buenos días
Esto ocurre porque el control en la Anulación de facturas es más restrictivo que en el Alta de facturas.

Para solucionar este error en el entorno de pruebas, deben enviar un correo a este mismo buzón indicando que quieren registrar un dispositivo. Anoten los siguientes datos en el mensaje:

• NIF del emisor
• Número de serie del dispositivo

--------------------------------------------------------------------------

Email nuevo enviado por Alava

Perdonad que resucite un post de hace 3 meses pero estabais hablando de un tema del que tengo algunas dudas.

Está claro que lo importante para el cliente es seguir facturando independientemente de si tiene o no conexión en ese momento para el envío de las facturas así que nuestro software genera el xml, lo firma, genera el identificador, el QR e imprime. Y luego ya añade el xml a una cola y trata de enviarlo cuando pueda.

La única excepción a este comportamiento es si detectamos que el certificado de firma ha caducado. En ese caso, sabiendo que la factura va a ser rechazada (porque va a ser rechazada por el servicio, ¿verdad? - no tengo medios para probar ésto, la verdad :confused:- ), no le dejo facturar e imprimir, es decir, activamos una restricción para que el software continúe emitiendo facturas (y así el cliente puede seguir operando) pero sin la posibilidad de impresión (así no habrá facturas sin identificador TBAI ni QR por el mundo). Luego, cuando actualicen el certificado, podrán generar todos esos xml sobre las facturas no impresas, firmarlas y enviarlas. Creo que es una solución interesante que no me parece que rompa el reglamento y además es lo único que se nos ha ocurrido para evitar posibles errores a la hora de subir la factura. Se admiten otras ideas :)

Bueno dicho ésto, el tema de la gestión de los errores me trae por la calle de la amargura. ¿Qué pasa si tengo tres facturas en cola (F1, F2, F3) y la primera (F1) es rechazada por cualquier motivo?. ¿Entiendo que el resto no se pueden subir hasta que suba esa primera que actúa como un "tapón", verdad?. Si la subsanación de esa factura para que sea "aceptada" por el servidor tbai implica hacer cambios en la misma, habría que volver a firmarla y se iría a tomar por saco el encadenamiento con el resto de las facturas posteriores (F2 y F3) y cambiaría el identificador TBAI y el QR de esas facturas que ya están impresas y con los clientes finales. Vamos un problemón. ¿Cómo lo estáis enfocando vosotros?. Necesito otras visiones porque me pongo cardíaco.

Otra cosa es que la factura sea aceptada y luego el servicio ya te devuelva advertencias o errores que habrá que subsanar entiendo que con Zuzendu, pero eso ya es otra guerra que irá después de ésta. Las cosas secuencialmente y paso a paso :)

Muchas gracias.

Ostras, precisamente estaba dándole vueltas justo a este tema en mi mensaje anterior :D

Por lo que entiendo, TODO lo enviado ya no se puede tocar, sea aceptado o rechazado por lo que no se pueden generar "tapones" en el envío de ficheros y el encadenamiento de todas las facturas no tendrá ningún problema porque esas facturas nunca se va a poder modificar. ¿Esto es así en TODAS las diputaciones o sólo en Alava? Lo digo porque parece que cada uno hace la guerra por su cuenta.

Y pregunto, si la factura TBAI ha sido rechazada por ejemplo, por un certificado inválido o porque se ha consignado mal el has de la política de firma, por ejemplo, Zuzendu va a "tragar" siempre porque no se firma digitalmente. Otra cosa es que tengamos fallos en el esquema o no se haya consignado algún campo obligatorio ...

En el "Listado de validaciones y errores del fichero de ALTA TicketBAI" de Alava, pone lo siguiente:

Entiendo entonces que el rechazo del fichero por un fallo en las validaciones de recepción no es en realidad un rechazo "de mentira" porque la factura queda de alguna manera dentro del sistema (no me imagino la manera si el problema es de fallos en el esquema, por ejemplo), ya no se puede enviar de nuevo y hay que tirar de Zuzendu y la subsanación, ¿correcto?.

Cuando hablan de la firma de la factura original, entiendo que se refieren al nodo <SignatureValueFirmaFactura> que va con los 100 primeros caracteres de la forma, ¿no?

En su día se dijo que dejarían un "periodo de gracia" para poder corregir este tipo de errores.
Segun eso, te admitirán las facturas, pero te darán un mensaje de aviso y un tiempo prudencial (unos días) para que instales los nuevos certificados.


Diría que justo eso es lo que no quieren que se haga.
Esa "factura" de la que nos has generado XML, firmado,... es modificable. Justo esa situación es la que no quieren.
Según dicen, las facturas deben enviarse "lo antes posible".
Si te pasas 2 días generando facturas, sin firmar, sin encadenar,... y al cabo de 2 días (cuando tienes los certificados) las envías todas juntas no creo que les haga mucha gracia.

Yo creo que debrías generar las facturas, el XML, firmarlas, enviarlas, generar los "encadenamientos correlativos" (aunque las rechaze) y luego cuando tengas los certificados correctos enviarlas de nuevo corregidas o con los métodos alternativos que proveen las diferentes diputaciones.

(1) Aunque una factura sea rechazada el encadenamiento sigue valiendo, y debes enviar las siguientes encadenadas con la que te han rechazado.
Son cosas distintas.
Ellos tendrán las tres facturas encadenadas de forma correcta, pero la F1 será rechazada.
Más adelante ya enviarás la F1 de nuevo por los métodos alternativos (ZUZENDU) o otros libros en el caso de BATUZ.

(2) Los servicios de modificación (tipo ZUZENDU) o los envíos en otros libros en BATUZ se suelen hacer sin firma, justo para no tener problemas con los encadenamientos. La factura original ya está firmada, encadenada y almacenada y la "subsanación" será enviar una serie de datos "extra" para corregir la original, pero esos envíos de subsanación no van firmados ni llevan encadenamiento.
(para que te hagas una idea)

(3) Hay advertencias que no necesariamente te obligan a reenviar. Algunos son avisos. Por ejemplo, el comentado anteriormente del certificado. Te pueden avisar de que el certificado está caducado, pero te las aceptan.
El aviso te sirve para corregir el error, pero no debes enviarla de nuevo, porque la factura es si es correcta (sólo falla el certificado).

Muchas gracias por la respuesta. Por lo que veo todo se ha retorcido por un fallo de comprensión de concepto. Siempre pensé que rechazado significada justo eso, que no les entraba en el sistema y que había que volver a reenviar una vez modificada. Pero resulta que no. Que todo llega pase lo que pase (bueno, a menos que su server esté "en mantenimiento", claro) y que si tanto hay errores en la recepción (fallo esquema, certificado, campos obligatorios) como en el procesado, luego hay que subsanar con Zuzendu, al menos en Guipúzcoa o Alava porque aún no me he puesto con Bizkaia, que por lo que me ha parecido ver por encima, es oootra historia diferente. Para qué unificarlo todo, ¿verdad?. Menos mal que son sólo tres y no 8 como en Andalucía.

Con ésto claro, lo que tiene más sentido, como bien comentas en el otro post, es generar siempre el xml, firmarlo y enviarlo aunque sepas que puede que haya algo mal (como la caducidad del certificado) porque luego ya lo corregirás con Zuzendu.

Hola trumbolt,

Como muy bien te indica nuestro colega Neftali, en ningún caso debes hacer eso.
Es lo que TicketBAI intenta evitar: que se puedan emitir facturas sin firmar y encadenar (que podrían ser borradas)

Ten en cuenta que, actualmente, es obligatorio SIEMPRE imprimir ticket de cualquier venta.
Tengo noticias de inspectores de Hacienda Foral de Bizkaia que se han colocado en la puerta de un comercio e iban preguntando a los clientes que salían si les habían dado ticket.
Si no les dan, ya sabes: Entran, se identifican y abren expediente.

Hay que imprimir siempre el ticket de la venta aunque el cliente no lo coja y vaya a la papelera.
Y eso ahora, antes de TicketBAI .... así que figúrate cuando TicketBAI sea obligatorio.

Saludos

Todo claro entonces. Factura generada, firmada y encadenada siempre, haya o no errores que detectemos y no podamos evitar (como un certificado caducado).

Y un tema ya por curiosidad. Imaginemos que el certificado está caducado. Aún así se firma con él la factura y luego se envío. En la fase de recepción será rechazada (es una de las cosas que se comprueban) aunque como ya he aprendido, queda registrada en su sistema a la espera de una subsanación a través de Zuzendu en Gipuzkoa y Araba (y de LROE en Bizkaia aunque ya tendré que mirar cómo se hace eso). El problema es que, si es tema del certificado de firma y con Zuzendu no hay que firmar nada, ese error no se podría subsanar de ninguna manera, o al menos no se me ocurre cómo.

Hola trumbolt,

Los servicios Zuzendu son para corregir los datos de las facturas, no los ficheros XML TicketBAI firmados.
Si el fichero está mal, pues lo está y punto. No se puede corregir.
Mediante Zuzendu, lo que haces es corregir los datos de esa factura (NIFs, bases imponibles, cuotas de IVA, ...) para que Hacienda Foral se quede tranquila y la considere como si hubiese llegado bien el XML firmado.

Saludos

Hola a todos!


Ya tenía todos los servicios funcionando, aun que ningun cliente quería estar en la fase de pruebas, y ahora les entran los nervios...
Lo dejé todo tal cual a fecha Diciembre de 2021 :D


El único cambio ha sido la subsanación de fallos(zuzendu)?

Revisa se tengas actualizadas las políticas de firma:
https://www.clubdelphi.com/foros/sho...97&postcount=1 (a mitad del mensaje)

Los HASH de las políticas de firma (que si han cambiado):
https://www.clubdelphi.com/foros/sho...97&postcount=1 (debajo de las URL's)

Sobre Certificados...help!
 

Hola a toda la gente que colabora en este mágnífico foro.
Estamos en fase de pruebas enviando XML de alta y anulación en Álava y Guipuzkoa.



Necesitamos que alguien nos aclare de qué forma podemos usar un certificado "genérico" para integrarlo en nuestro software y que sirva para todas nuestros clientes.
Soporte de TBAI nunca nos dejan nada claro, hablan de certificado de usuario, de autónomo, de dispositivo....y siempre nos remiten a los certificados de test IZENPE.



Lo cierto que es agradeceríamos si alguien nos arroja algo de luz qP:-)qP:-) en este sentido, he leído algunos post comentando sobre certificados de software que se compran como los de ksoftware.net
* ¿serían la solución que andamos buscando?
* ¿es posible integrar nuestro certificado de empresa usando el parámetro<Factura emitida por tercero o destinatario> = T (Tercero) y sería correcto? en ese caso, ¿deben firmar nuestros clientes un consentimiento por enviar sus tickets firmados con nuestro certificado?



¡muchas gracias a todos!

Hola ikosoft,

Si quieres usar un mismo certificado digital para todos tus clientes, el método más adecuado es el que comentas: marcar el nodo <EmitidaPorTercerosODestinatario> con el valor T

Eso te permitirá usar, por ejemplo, tu certificado para firmar los ficheros XML.
Aunque para enviarlos (recuerda que se precisa certificado para ese envío) debes seguir el procedimiento de autorización que exige cada Hacienda Foral.
Entra en cada una de ellas y sigue el procedimiento que indiquen en su web.

Y lo lógico es que pidas a todos tus clientes que firmen un documento de autorización de que tú emitirás, firmarás y enviarás sus facturas en su nombre.

También es recomendable que tengas, al menos, 2 certificados (por ejemplo, uno de FNMT y otro de IZENPE) con distintas fechas de caducidad.
Cuando solicitas renovar un certificado, queda revocado el anterior, por lo que ya no podrás utilizarlo hasta que no tengas instalado el nuevo.
Cambiando de certificado, antes de solicitar la renovación del que venías utilizando, puedes seguir trabajando con el otro hasta que consigas el nuevo.

Saludos.

Hora última factura
 

Buenas tardes,
tengo una duda sobre la hora de grabación, ejemplo;
Emito una factura (numero 1) con hora de expedicion 14:00:00
Se actualiza la hora del sistema unos segundos por algún problema con la pila a las 13:59:45
Emito Factura numero 2 a las 13:59:55.

Sabeis si en los casos de no tener el orden cronologico de fecha expedicion exacto da alguna incidencia el sistema de recepcion de tiquetbai?

Error Envio Bizkaia
 

Hola,

Estoy haciendo pruebas de envíos de facturas a Bizkaia y todo iba bien hasta el miércoles que decidí enviar un paquete con 270 facturas. Al intentar el envío me dio el siguiente mensaje de Chilkat (parecido, este es del envío de prueba de hoy para ver si funcionaba).

ChilkatLog:
ReadResponseHeader:
DllDate: May 28 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 30000
Failed to receive more TLS application data.
tlsApp: Socket operation timeout.
elapsedMs: Elapsed time: 31281 millisec
Failed.
--ReadResponseHeader
--ChilkatLog

También he probado con paquetes mas pequeños y ha realizar consultas. Todo el rato lo mismo Socket operation timeout.

¿Sabe alguien si está pasando algo en el servidor de pruebas de Bizkaia? Les he enviado a los de Soporte de TicketBAI (Bizkaia) y todavía no me han contestado.
¿Alguna idea de que puede estar pasando?

Saludos y muchas gracias,
Joselu

Solucionado
 

Parece que ya lo han solucionado en Bizkaia.

Muchas gracias,
Joselu