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

[trumbolt]

Empezado por Sistel

Hola,

Para mí, lo importante es que se pueda seguir facturando en cualquier caso y contra viento y marea.
Se van generando los XML, se van firmando, se van generando los códigos TBAI y QR y se van imprimiendo las facturas.

El tema del envío a la Hacienda Foral correspondiente creo que no es tan vital.
Pero no puedo dejar parado el TPV de una panadería, por ejemplo, porque no funcione el servicio de recepción de facturas de Hacienda Foral o porque haya un problema de Internet.

Los ficheros XML firmados se van poniendo en cola y un cronjob los va enviando a medida que se puede.
Si luego Hacienda Foral sale con cualquier mensaje de error de que no traga con la factura, ya es cuestión de LROE facturas emitidas sin software garante en Bizkaia, Zuzendu en Gipuzkoa o Alavazendu (o como le quieran llamar cuando lo inventen) en Álava.

Saludos

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

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

Empezado por trumbolt

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

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.

Empezado por trumbolt

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

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.

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

Empezado por trumbolt

(1) ¿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?.

(2) 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.

(3) 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

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

[trumbolt]

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

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

[Sistel]

Empezado por trumbolt

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

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

[trumbolt]

Empezado por Sistel

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.

[Sistel]

Empezado por trumbolt

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

[Ramon88]

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


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

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

Empezado por Ramon88

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)

[ikosoft]

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