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

[ermendalenda]

Empezado por b4aronDeLaBirr4

Buenas!

Por curiosidad, ¿qué enfoque le habéis dado al tratamiento del encadenamiento en las facturas? Independientemente del lenguaje de programación utilizado. ¿Un campo en la base de datos que apunte a la anterior? ¿Algún matiz más?

A seguir con el lunes!

Una tablita en la base de datos con un campo numérico (continuo en número y cronologicamente) independiente de la serie y número de factura y que contenga varios campos, entre ellos, la serie, número, fecha y firma de la última factura y otros campos iguales con la anterior. Teniendo en cuenta que no arrastre firmas de anulaciones. Casa nueva factura solo tengo que mirar el registro del último número de la tabla y si tengo varios dispositivos en el mismo equipo( tabletsequipos que graban en Red...) previamente pongo un bloqueo antes de hacer todos los procesos para evitar que se solapen. El resto de dispositivos que se encuentren el bloqueo se quedan en bucle esperando que se levante el bloqueo.

[b4aronDeLaBirr4]

Y en esa tabla contemplas solo aquellas facturas notificadas? O también contemplas los intentos, las fallidas y lo más peculiar, aquellas que no se han mandado pero que ya has firmado y todo (imaginemos el clásico caso del internet caído puntualmente)

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

Empezado por ermendalenda

Una tablita en la base de datos con un campo numérico (continuo en número y cronologicamente) independiente de la serie y número de factura y que contenga varios campos, entre ellos, la serie, número, fecha y firma de la última factura y otros campos iguales con la anterior. Teniendo en cuenta que no arrastre firmas de anulaciones. Casa nueva factura solo tengo que mirar el registro del último número de la tabla y si tengo varios dispositivos en el mismo equipo( tabletsequipos que graban en Red...) previamente pongo un bloqueo antes de hacer todos los procesos para evitar que se solapen. El resto de dispositivos que se encuentren el bloqueo se quedan en bucle esperando que se levante el bloqueo.

Nosotros algo similar.

Empezado por b4aronDeLaBirr4

Y en esa tabla contemplas solo aquellas facturas notificadas?

Nosotros sólo generamos encadenamiento cuando la factura ha sido notificada. Si no se notifica (por lo que sea) se deshace todo mediante transacciones y no queda rastro.

[b4aronDeLaBirr4]

Sí, más o menos lo que estoy planteando es tener una tabla de IntentosNotificacion que apunte a la factura, tenga el contenido de la petición de envío, el contenido de la respuesta de esa petición (esto en formato BLOB quizá), el estado (existiendo Notificado, No notificado, Fallido... previamente definidos) o algo del estilo. Luego en lo que es la tabla factura, apuntar a la anterior en caso de realizar una emisión correctamente y como cada factura tendría un campo BLOB con su XML firmado y eso, podría tener acceso a los 100 primeros caracteres del campo SignatureValue de la factura anterior (que es lo que se pide, básicamente).

Es que estoy planteando la estructura primero, y quiero que sea lo más genérica posible para poder implementar cualquier sistema de notificación, como el SII, por eso ando full documentación jeje gracias!

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

[OFFTOPIC]
Buenas a todos.

Me vais a permitir una licencia con este hilo (será la única, lo prometo ).
Soy consciente de que muchos de los que visitáis este grupo accedéis a él directamente, sin pasar por otras zonas del ClubDelphi.

Os animo a que visitéis el enlace del banner que hay en la parte superior de la página.



Explica todo lo necesario para conocer nuestro grupo de Teaming. Os pediría que le dedicarais un minuto.
A partir de ahí, si alguien se anima será bienvenido.

Gracias.

[/OFFTOPIC]

[ermendalenda]

Empezado por b4aronDeLaBirr4

Y en esa tabla contemplas solo aquellas facturas notificadas? O también contemplas los intentos, las fallidas y lo más peculiar, aquellas que no se han mandado pero que ya has firmado y todo (imaginemos el clásico caso del internet caído puntualmente)

Sí una factura no puede enviarse, las facturas siguientes se quedan en espera y me manda una incidencia por correo, se supone que los envíos KO serán en breve culpas denuestro software y acabarán desapareciendo. Si hay un KO se vuelve a reintentar cada minuto, tengo pendiente de añadir un límite de xmls sin enviar configurable y que se bloquee o de bastante por saco al usuario como para que avise a soporte, esto aun lo estoy pensando, se aceptan ideas.

En la tabla tb guardo registro de envío a un servidor externo nuestro al que envío el xml firmado, sin firmar y un pdf de la factura.
Esa tabla la leo continuamente con un software en segundo plano que no afecta a la facturación, cuando voy a generar la factura hago otras conprobrobaciones, fecha y hora de sistema, que no haya problemas con el firmador... Que son errores más graves que provocarían un bloqueo para no seguir facturando.

[b4aronDeLaBirr4]

Buenos días!

Ya veo... tiene sentido... Yo también tengo que pensar el tema de las facturas que no se han podido mandar, tendré que comentarlo en la oficina a ver si alguien viene con alguna idea fresca. Pero una posibilidad es, si no se trata de un error puntual permitir volver a mandar y si no se ha podido tampoco, a la cola. Porque no se pueden enviar más facturas hasta que se haya mandado aquella que no se ha podido mandar, ¿verdad?

Otra posibilidad, aunque de objeto de estudio es, si la factura F1 no se ha podido mandar y mandamos la F2, consultamos si hay facturas pendientes de mandar primero, si no se puede pues cuando se emita F3, lo mismo, funcionando a lo FIFO, pero no sé si será demasiada consulta. Además, queda contemplar aquel momento en el que el problema del servidor se extienda sobre el tiempo y no sé si proponer un proceso automático al final de la jornada con esa misma cola. Lo que no quiero es dejar al cliente sin servicio. Se agradecen ideas, comentarios...

[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

[b4aronDeLaBirr4]

Pienso lo mismo, facturar no puede dejar de hacerse. Gracias!

[b4aronDeLaBirr4]

Sigo poniéndome al día con todo lo que el cuerpo me permite y veo lo de Zuzendu que en un pasado se habló... Pero ahora: "Este anexo ha sido modificado por el anexo I de la Orden Foral 40/2022, de 25 de enero, por la que se sustituyen los anexos I y III de la Orden Foral 16/2022, de 18 de enero, por la que se regulan los requisitos de los servicios, el procedimiento, y las especificaciones técnicas y funcionales para la subsanación de los ficheros TicketBAI.", es decir, algo bastante reciente. ¿Esto solo afecta a Gipuzkoa? Por los mensajes del foro, no parece que esté en funcionamiento, ¿no? y esto... ¿Afecta de manera directa al actual envío de facturas de Gipuzkoa o es más algo adicional?

También leo Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

¿Qué caso real es este?

Saludos!

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

[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