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

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

Empezado por espinete

Dejo esto por aquí, no sé si alguien lo ha posteado ya:

https://www.autonomosyemprendedor.es...232026177.html

Al parecer a Hacienda le ha gustado el tema TicketBAI y tiene intención de implantar algo parecido para toda España (aunque por el momento solo menciona a los autónomos).
Se requerirá incluir un Código QR en las facturas.

Creo que te refieres a este hilo:
https://www.clubdelphi.com/foros/showthread.php?t=95235

Ya se ha creado uno específico para ello.
Suscríbete allí para recibir las notificaciones cuando haya cambios.

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

Empezado por keys

Alava tambien ha sacado el servicio Zuzendu

Os dejo lo poco que hay de documentación por si alguien quiere "ojearla".
La mayoría son borradores, por eso la pongo aquí, cuado esté la definitiva la añadiremos al inici del hilo.
Valen para ir haciendose una idea de por donde irán los tiros....

Alava_Validaciones y errores Zuzendu 2.pdf
Alava_Validaciones y errores Zuzendu.pdf
Pruebas zuzendu.pdf
Requisitos del servcio Zuzendu.pdf

Si os dan probklemas de descarga, los podéis bajar desde el FTP del club, directamente:
http://terawiki.clubdelphi.com/Otros...Alava_Zuzendu/

[ermendalenda]

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

Planteado así si. Nosotros mismo lo hacemos desde una DLL externa.
Pero en el caso que ha plannteado [ermendalenda] hablaba de una "importación de facturas", y me ha sonado a una importación manual.

Imagina que el usuario debe hacer esa importación manualmente. En ese caso0 ya no me parece tan claro.
(pero todo esto es suponer...)

Va a ser automático, el usuario sólo incluye fechas desde hasta a importar y el sistema comprobará que las numeraciónes importadas no estén ya, que sean correlativas, que cumpla normativas etc. Y a partir del nuevo sistema genero pdfs con el qr, el xml firmado encadenado y la posibilidad de imprimir y enviar por email. La conexión es por odbc al otro sistema.

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

Empezado por ermendalenda

Va a ser automático, el usuario sólo incluye fechas desde hasta a importar y el sistema comprobará que las numeraciónes importadas no estén ya, que sean correlativas, que cumpla normativas etc. Y a partir del nuevo sistema genero pdfs con el qr, el xml firmado encadenado y la posibilidad de imprimir y enviar por email. La conexión es por odbc al otro sistema.

Si es un sistema automático no creo que haya problema.

[ermendalenda]

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

Si es un sistema automático no creo que haya problema.

Gracias Neftali y demás chicos/as.
Vaya lío estoy montando para aprovechar el sistema antiguo por un par de años.

[espinete]

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

Creo que te refieres a este hilo:
https://www.clubdelphi.com/foros/showthread.php?t=95235

Ya se ha creado uno específico para ello.
Suscríbete allí para recibir las notificaciones cuando haya cambios.

No me queda claro que sea exactamente lo mismo, pero sí, está (y estará) relacionado.

La Ley Antifraude es para todas las empresas, y esa noticia solo hablaba de "autónomos", o al menos así lo entendí, así que no sé realmente cómo afectará a unos y otros.
Por lo pronto, por la similitud que tiene con el TicketBAI (usar un código QR), lo veo más relacionado con esto que con la Ley Antifraude, de la que poco se sabe aún a falta de la normativa, pero que va más encaminada a limitar lo que un software puede o no puede hacer.

Lo que está claro es que si lo del TicketBAI sale bien (yo aún tengo dudas cuando entre a producción de forma obligatoria para TODOS), la Hacienda Estatal acabará haciendo lo mismo, o algo similar.
Y entonces cada Comunidad Autónoma hará su TicketBAI propio, o peor, cada provincia, y será una locura, quedaremos todos para llorar en alguna playa mientras bebemos cerveza barata y comemos arena.

[HerensugeBeltz]

Empezado por espinete

...Y entonces cada Comunidad Autónoma hará su TicketBAI propio, o peor, cada provincia, y será una locura...

Entiendo que la capacidad recaudatoria es competencia de las Haciendas (las tres Vascas, la Navarra y la Estatal) y no de las CCAA, por lo que pienso que no se dará el caso.

[Sanduzelai]

Hola a todos,
en mi empresa vamos a pasar del entorno de test a producción en los próximos días para emitir facturas en Gipuzkoa pero tenemos alguna duda.

Hemos hecho el registro como empresa desarrolladora de una solución de ticketbai pero no nos ha llegado confirmación por su parte de que podemos empezar. Entiendo que nos pasaran un número de licencia nuevo para el entorno de PRO ¿no?


Muchas gracias por adelantado

[tejano]

Empezado por Sanduzelai

Hola a todos,
en mi empresa vamos a pasar del entorno de test a producción en los próximos días para emitir facturas en Gipuzkoa pero tenemos alguna duda.

Hemos hecho el registro como empresa desarrolladora de una solución de ticketbai pero no nos ha llegado confirmación por su parte de que podemos empezar. Entiendo que nos pasaran un número de licencia nuevo para el entorno de PRO ¿no?


Muchas gracias por adelantado

En mi caso con Vizcaya así es.....te dan un Numero de licencia TBAI que debe ir en el fichero que envías. En el caso de Gipuzkoa no lo tengo claro si será así.

Saludos

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

Empezado por espinete

Por lo pronto, por la similitud que tiene con el TicketBAI (usar un código QR), lo veo más relacionado con esto que con la Ley Antifraude, de la que poco se sabe aún a falta de la normativa, pero que va más encaminada a limitar lo que un software puede o no puede hacer.

Aquí (mensaje que pertenece al hilo que he comentado) ya vimos que hay bastantes similitudes. No sólo lo del código QR, sino el encadenamiento, la remisión inmediata,...

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

Empezado por Sanduzelai

Hemos hecho el registro como empresa desarrolladora de una solución de ticketbai pero no nos ha llegado confirmación por su parte de que podemos empezar. Entiendo que nos pasaran un número de licencia nuevo para el entorno de PRO ¿no?

Si, son diferentes (al menos nosotros tenemos uno para PRE y otro para PRO).

[jreverendo]

Llevo un par de dias intentando enviar a pruebas de Zuzendu de Guipuzcoa y me responde el error "006 El servicio no esta disponible" les he enviado una consulta preguntandoles si era cosa mia o de ellos, me han pedido los datos a que url estoy enviando y el mensaje de respuesta, se lo he enviado y desde entonces no se nada, yo supongo que será problema de ellos...

Pero alguien me puede confirmar si esta caido el servicio???



Un Saludo.

[thinkows]

Empezado por jreverendo

Llevo un par de dias intentando enviar a pruebas de Zuzendu de Guipuzcoa y me responde el error "006 El servicio no esta disponible" les he enviado una consulta preguntandoles si era cosa mia o de ellos, me han pedido los datos a que url estoy enviando y el mensaje de respuesta, se lo he enviado y desde entonces no se nada, yo supongo que será problema de ellos...

Pero alguien me puede confirmar si esta caido el servicio???



Un Saludo.

Ahora mismo acabo de probar :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<IdentificadorTBAI>TBAI-B58292129-100322-afVgb4yGpL1rM-235</IdentificadorTBAI>
<FechaRecepcion>10-03-2022 15:55:48</FechaRecepcion>
<Estado>00</Estado>
<Descripcion>Recibido - ZUZENDU PREP</Descripcion>
<Azalpena>Jasota - ZUZENDU PREP</Azalpena>
<CSV>TBAI19fc51a3-a896-48ff-a223-b79f2478cb06</CSV>
</Salida>
</ns2:TicketBaiResponse>

Y funciona, me ocurrio algo parecido hace unas semanas y parece que era algo de su servidor .... aparentemente utilizan mas de un servidor ...

Saludos,

[joselugrk]

Hola,

Os quería preguntar como se debe enviar a Bizkaia las facturas SIN SOFTWARE GARANTE y las CONSULTAS de ingresos.

PASOS recogidos del documento "ESPECIFICACIONES FUNCIONALES Y TÉCNICAS DEL ENVÍO MASIVO DEL LROE A LA DFB/BFA V1.0.8"
1.- Crear la "Cabecera de la petición HTTP: contiene la información general de la petición y los datos del obligado tributario".
2.- Crear el Cuerpo de la petición HTTP: en el cuerpo de la petición es donde se incluye la información de las anotaciones de las estructuras del LROE que se quiera enviar a DFB/BFA. La aplicación cliente debe crear un fichero (formato comprimido) e incluirlo en el cuerpo de la petición. En concreto, debe realizar los siguientes pasos:

• Construir el fichero XML con las anotaciones de la estructura a enviar.
• Comprimir el fichero anterior en formato GZIP.
• Incorporar el fichero comprimido en el cuerpo de la petición.

¿El fichero XML generado (Factura Sin software Garante o Consulta) debe ir comprimido en base64 como los XML's firmados de facturas o no? Existe algún ejemplo del envío ya preparado para estos casos? Veo que en los ejemplos hay un caso por modelo 140 y 240 de consultas pero ninguno de Facturas Sin Software Garante.

Si podrías explicármelo os lo agradecería, estoy un poco espeso.

Saludos y muchas gracias,
Joselu

[joselugrk]

Empezado por joselugrk

Hola,

Os quería preguntar como se debe enviar a Bizkaia las facturas SIN SOFTWARE GARANTE y las CONSULTAS de ingresos.

PASOS recogidos del documento "ESPECIFICACIONES FUNCIONALES Y TÉCNICAS DEL ENVÍO MASIVO DEL LROE A LA DFB/BFA V1.0.8"
1.- Crear la "Cabecera de la petición HTTP: contiene la información general de la petición y los datos del obligado tributario".
2.- Crear el Cuerpo de la petición HTTP: en el cuerpo de la petición es donde se incluye la información de las anotaciones de las estructuras del LROE que se quiera enviar a DFB/BFA. La aplicación cliente debe crear un fichero (formato comprimido) e incluirlo en el cuerpo de la petición. En concreto, debe realizar los siguientes pasos:

• Construir el fichero XML con las anotaciones de la estructura a enviar.
• Comprimir el fichero anterior en formato GZIP.
• Incorporar el fichero comprimido en el cuerpo de la petición.

¿El fichero XML generado (Factura Sin software Garante o Consulta) debe ir comprimido en base64 como los XML's firmados de facturas o no? Existe algún ejemplo del envío ya preparado para estos casos? Veo que en los ejemplos hay un caso por modelo 140 y 240 de consultas pero ninguno de Facturas Sin Software Garante.

Si podrías explicármelo os lo agradecería, estoy un poco espeso.

Saludos y muchas gracias,
Joselu

Perdonar, se me olvidaba preguntaros como es la Cabecera HTTP de la petición para las facturas SIN SOFTWARE GARANTE.

Gracias.
Joselu

[unomasmas]

Empezado por jreverendo

Llevo un par de dias intentando enviar a pruebas de Zuzendu de Guipuzcoa y me responde el error "006 El servicio no esta disponible" les he enviado una consulta preguntandoles si era cosa mia o de ellos, me han pedido los datos a que url estoy enviando y el mensaje de respuesta, se lo he enviado y desde entonces no se nada, yo supongo que será problema de ellos...

Pero alguien me puede confirmar si esta caido el servicio???

Un Saludo.

A mi me funciona bien...

[jreverendo]

Empezado por thinkows

Ahora mismo acabo de probar :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<IdentificadorTBAI>TBAI-B58292129-100322-afVgb4yGpL1rM-235</IdentificadorTBAI>
<FechaRecepcion>10-03-2022 15:55:48</FechaRecepcion>
<Estado>00</Estado>
<Descripcion>Recibido - ZUZENDU PREP</Descripcion>
<Azalpena>Jasota - ZUZENDU PREP</Azalpena>
<CSV>TBAI19fc51a3-a896-48ff-a223-b79f2478cb06</CSV>
</Salida>
</ns2:TicketBaiResponse>

Y funciona, me ocurrio algo parecido hace unas semanas y parece que era algo de su servidor .... aparentemente utilizan mas de un servidor ...

Saludos,

Empezado por unomasmas

A mi me funciona bien...

Gracias a los 2 no tengo ni idea sigo igual el servidor de TicketBai Pruebas me va sin problemas pero el de Zuzendu Pruebas me responde siempre con esa respuesta, que el servicio no esta disponible, da igual que le envie un Zuzendu con errores o sin errores.

Un Saludo.

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

Empezado por joselugrk

En concreto, debe realizar los siguientes pasos:

• Construir el fichero XML con las anotaciones de la estructura a enviar.
• Comprimir el fichero anterior en formato GZIP.
• Incorporar el fichero comprimido en el cuerpo de la petición.

¿El fichero XML generado (Factura Sin software Garante o Consulta) debe ir comprimido en base64 como los XML's firmados de facturas o no?
Existe algún ejemplo del envío ya preparado para estos casos?

Los pasos son los que comentas.
Aquí no hay que codificar base64 porque no hay fichero TBAI. Los datos de las facturas van directamente en el XML.
Te adjunto un fichero con el XML (que luego se comprime) y las cabeceras de petición y respuesta (con algun datos enmascadaro).

Empezado por joselugrk

Perdonar, se me olvidaba preguntaros como es la Cabecera HTTP de la petición para las facturas SIN SOFTWARE GARANTE.

Te las pongo en el fichero adjunto.
Son iguales (cambiando un parámetro) a las de "con software garante"

[jreverendo]

Empezado por jreverendo

Gracias a los 2 no tengo ni idea sigo igual el servidor de TicketBai Pruebas me va sin problemas pero el de Zuzendu Pruebas me responde siempre con esa respuesta, que el servicio no esta disponible, da igual que le envie un Zuzendu con errores o sin errores.

Un Saludo.

Por si le sirve a alguien ya esta solucionado no rellenaba el campo de la firma de xml, y el servidor me estaba dando este mensaje de respuesta, por lo que si a alguien le da ese error que sepa por que puede ser.

Un Saludo.

[ermendalenda]

Empezado por espinete

No me queda claro que sea exactamente lo mismo, pero sí, está (y estará) relacionado.

La Ley Antifraude es para todas las empresas, y esa noticia solo hablaba de "autónomos", o al menos así lo entendí, así que no sé realmente cómo afectará a unos y otros.
Por lo pronto, por la similitud que tiene con el TicketBAI (usar un código QR), lo veo más relacionado con esto que con la Ley Antifraude, de la que poco se sabe aún a falta de la normativa, pero que va más encaminada a limitar lo que un software puede o no puede hacer.

Lo que está claro es que si lo del TicketBAI sale bien (yo aún tengo dudas cuando entre a producción de forma obligatoria para TODOS), la Hacienda Estatal acabará haciendo lo mismo, o algo similar.
Y entonces cada Comunidad Autónoma hará su TicketBAI propio, o peor, cada provincia, y será una locura, quedaremos todos para llorar en alguna playa mientras bebemos cerveza barata y comemos arena.

Solo autónomo?
Ni hablar. El gobierno va a, practicamente, replicar ticketbai, es decir un blockchain casi igual, y además añade control de eventos de todo el sistema que lleve asociada La facturación y obligación de acompañar al certificado de programa y a los usairkos dr un manual.
Lo único que veo un pelín más diferente es que va a. Permitir usar al empresario 2 modos, envío inmediato con hash o blockchain y no envías.
Saludos

PROYECTO DE REAL DECRETO XX/2022, DE XX DE XXXX POR EL QUE SE APRUEBA EL
REGLAMENTO QUE ESTABLECE LOS REQUISITOS QUE DEBEN ADOPTAR LOS
SISTEMAS Y PROGRAMAS INFORMÁTICOS O ELECTRÓNICOS QUE SOPORTEN LOS
PROCESOS DE FACTURACIÓN DE EMPRESARIOS Y PROFESIONALES, Y LA
ESTANDARIZACIÓN DE FORMATOS DE LOS REGISTROS DE FACTURACIÓN.