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

[b4aronDeLaBirr4]

Perfecto, así que esta es la famosa memoria completamente de relleno que había leído por mensajes anteriores jeje Gracias!

Un saludo

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

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

[musinho]

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!

Yo estoy haciendo un plugin de WordPress el cual guarda los siguientes campos por cada factura generada:

tbai_invoice_number: 220041
tbai_previous_invoice_number: 220040
tbai_status: emitido
tbai_invoice_date: 2022-02-03

Al recibir un nuevo pedido hago una consulta a la tabla de facturas para devolver la última factura generada. De ahí obtengo el tbai_previous_invoice_number. Hay que decir que en otra tabla tengo el número plano autoincremental ya que una factura puede componerse por letras y números y la suma no la podría asegurar al 100%.

Sumo uno al autoincremental y guardo el tbai_invoice_number ya formateado y la fecha actual en tbai_invoice_date.

Seguidamente emito el xml firmado a la diputación y según la respuesta asigno el estado en tbai_status.

Con estos datos guardados en bbdd es verdad que necesito abrir el anterior xml para el tema del encadenamiento, y para evitar esto seguramente pueda guardar estos datos en bbdd. Pero bueno doy por hecho que no se van a eliminar los xmls y que los archivos existen en el sistema.

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

[pablog2k]

Buenos días, estoy implementado el desarrollo de ticketbai con batuz, y me surgen unas dudas, a ver si he entendido bien todo:
-se envía el modelo 140 (o 240), y en la cabecera se monta un json tal que asi:

eus-bizkaia-n3-data = {
"con": "LROE",
"apa": "1.1",
"inte": {
"nif": "número de identificación fiscal",
"nrs": "nombre o Razón social",
"ap1": "primer apellido",
"ap2": "segundo apellido"
},
"drs": {
"mode": "140/240",
"ejer": "ejercicio"
}
}

luego en el cuerpo del mensaje,se envía un zip con el propio ticketbai,pero convertido a base64, y se utiliza esta estructura:
https://www.batuz.eus/fitxategiak/ba...ion_V1_0_2.xsd

-Es correcto lo que digo??
-Puedo enviar mas de una factura a la vez en el cuerpo del mensaje? varios registros metidos en el zip
-Puedo ir haciendo anotaciones en el modelo 140/240 siempre que quiera?o se hace todo a la vez? (yo creo debe de ser que puedes ir haciendo anotaciones conforme haces las facturas de ticketbai)

Muchas gracias por la ayuda (que por cierto,vaya lío,ya podría ser como las otras dos diputaciones... envías el xml y listo)

[b4aronDeLaBirr4]

-Puedo enviar mas de una factura a la vez en el cuerpo del mensaje? varios registros metidos en el zip

En principio, ese es el principal objetivo del sistema Batuz, cada factura firmada y demás irá codificada en base64 dentro de cada nodo correspondiente, citando a la documentación:

Generar un fichero XML, que cumple el formato del XSD del alta con facturas software garante, el cual, permite incluir un máximo de 1.000 ficheros TBAI en cada envío. Por cada factura el proceso es el siguiente:
o Codificar el fichero TicketBAI en Base64 e incorporarlo en el nodo “TicketBai” del
subcapítulo correspondiente.
o Completar el resto de datos de cada factura cuando proceda.
▪ Comprimir dicho fichero en formato GZIP.
▪ Incorporar el fichero comprimido en el cuerpo de la petición.

(Página 19 de este doc h_t_t_p_s://www.batuz.eus/fitxategiak/batuz/lroe/Batuz_LROE_Especificaciones_Env%C3%ADo_Masivo_V1_0_8.pdf?hash=35f5f37000e8873a209d53f4d18cc843)

[ermendalenda]

Si el problema es sin Internet o problema del servidor es fácil saberlo, en ese caso se deja en cola y listo, se va usando y punto.
Si se recibe un error hay que tratarlo y ver q se hace. Ejemplo certificado caducado o revocado. En ese caso se corta por lo sano. Si es caducado solo tener en cta el período de gracia. Lo que sí hay que tener una forma de reactivar todo rápido y saltarse todos los bloqueos por cualquier imprevisto

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

Empezado por pablog2k

...luego en el cuerpo del mensaje,se envía un zip con el propio ticketbai,pero convertido a base64, y se utiliza esta estructura:
-Es correcto lo que digo??

Un XML del libro 140/240, en su interior hay 1..N nodos donde añades el XML del TicketBAI (correspondiente a una factura) codificado en formato base64.
Ese XML resultante (libro 140/240) lo comprimes como gzip y es lo que envías en la petición junto con la cabecera que has puesto.

Resumiendo: Un gzip, que dentro tiene un XML, con 1..N nodos en base64, que corresponden a un XML del TicketBAI (sencillito vamos...).

Empezado por pablog2k

-Puedo enviar mas de una factura a la vez en el cuerpo del mensaje? varios registros metidos en el zip

Si.
Los 1..N nodos que van en base64, dentro del XML del Libro que luego comprimes.

Empezado por pablog2k

-Puedo ir haciendo anotaciones en el modelo 140/240 siempre que quiera?o se hace todo a la vez? (yo creo debe de ser que puedes ir haciendo anotaciones conforme haces las facturas de ticketbai)

Si, es lo que hacemos algunos de nosotros para intentar "unificar" todo esto.
Porque cada administración se puede permitir hacer lo que quiera (que para eso son funcionarios y lo hacen con nuestro dinero), pero nosotros tenemos que intentar deasarrollar de una manera "óptima" y "estandard".
En nuestro caso intentamos "igualar" dentro de lo posible los tres procesos de envío (las tres administraciones), así que por ahora trabajamos de la misma forma en las tres: Factura que se genera, factura que se envía. Cambiando la mecánica (los builders) del fichero y del envío, pero de esa forma el proceso es compartido para las tres.

[MODO DESAHOGO]
Supongo que pedir que antes de lanzar un proyecto como este, se reunan y se pongan de acuerdo es demasiado pedir...
Para simplificar, para ahorrar trabajo (a ellos y a nosotros), ahorrar dinero (nuestro y de los contribuyentes), simplificar procesos, pruebas, minimizar instalaciones y servicios, minimizar problemas, ahorrar en burocracia, papeleo, organización,.... y tantas y tantas otras cosas.

¿Pa qué? Es mejor hacer cada uno lo que le sale del moño, y que el resto lo sufran...
Funcionarios y Administraciones públicas...
¿Os imagináis que dentro de un año las otras 47 provincias decidieran hacer lo mismo que ellos?
(lo siento por la "chapa", pero estoy muy quemado...)
[/MODO DESAHOGO]

[MikusMikae]

Hola,


Hemos adaptado nuestro software para poder enviar tiquets a TIcketBai y la ayuda del foro a sido impagable para ello.
Pero nos surge una duda en los tiquets con importe cero. Por ejemplo una tienda de ropa, compras una prenda, se genera el correspondiente tiquet, se envia a TicketBai, etc.
Dias mas tarde se realiza un cambio de talla de la prenda, en nuestro sistema se genera un tiquet nuevo pero al tener una linea de tiquet en positivo y otra en negativo, se compensan y el total del tiquet es cero.


Como se enviaria esto en el XML? hay que indicar los totales, ivas, etc. a cero?



Saludos y gracias.

[pablog2k]

gracias por la ayuda Nefta!! y muy de acuerdo contigo, es un verdadero caos todo esto... con lo simple que sería que las 3 diputaciones se pongan de acuerdo...ni que fueran 40 provincias!!! son 3!!! pues cada una con sus cosas distintas... tócate los....

[ermendalenda]

Empezado por MikusMikae

Hola,


Hemos adaptado nuestro software para poder enviar tiquets a TIcketBai y la ayuda del foro a sido impagable para ello.
Pero nos surge una duda en los tiquets con importe cero. Por ejemplo una tienda de ropa, compras una prenda, se genera el correspondiente tiquet, se envia a TicketBai, etc.
Dias mas tarde se realiza un cambio de talla de la prenda, en nuestro sistema se genera un tiquet nuevo pero al tener una linea de tiquet en positivo y otra en negativo, se compensan y el total del tiquet es cero.


Como se enviaria esto en el XML? hay que indicar los totales, ivas, etc. a cero?



Saludos y gracias.

Correcto así de simple, negativo en la cantidad e importe total, el importe unitario siempre en positivo y el total da igual que sea cero o negativo, según reglamento de facturación se admite por cambio si son del mismo tipo impositivo.