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

[b4aronDeLaBirr4]

Muchas gracias! Es difícil solicitarlo? (hay que aportar mucha documentación)

Que el lunes os sea leve!

[batuzail]

Empezado por b4aronDeLaBirr4

Muchas gracias! Es difícil solicitarlo? (hay que aportar mucha documentación)

Que el lunes os sea leve!

Hola,
Tienes que explicar como vas a cumplir con la normativa, tienes que meter mucho relleno y copiar cosas de su documentación, si asumes que eso ya lo saben y no lo documentas te dirán que tienes que explicarlo, a mi me paso eso. Al final presenté una memoria de 8 páginas.



Saludos

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

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

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

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

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

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

[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 del negativo e importe total del negativo tb con signo negativo, las líneas positivas como siempre, 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 impositivos, si son distintos ivas o no se lleva nada a cambio en el mismo tiquet, rectificativa con su serie y numeración

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