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

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

Empezado por Edgar7

1.- En el TicketBAI, el nodo Emisor en el que se indica el campo NIF y el campo ApellidosNombreRazonSocial, entiendo que estos campos han de ser los del usuario que usa el software, ¿el usuario se tiene que dar de alta en algún sitio para poder enviar los ticketBAI o no es necesario que ello hagan nada?

2.- En el caso de Bizkaia, ¿esos datos deben ser los mismos que se envían en el json de la cabecera, en los campos NIF y NRS?
{"con":"LROE","apa":"1.1","inte":{"nif": " ","nrs": " "},"drs":{"mode":" ","ejer":" "}}

3.- ¿Es necesario dar de alta el programa en todas las haciendas, o con darle de alta en una vale para todas?

4.- ¿Qué pasos se han de seguir para dar de alta un programa adaptado para TicketBAI en las haciendas?

1. Los del usuario. Creo que los usuarios no. Esos datos ya los tienen la hacienda Vasca.
2. Si, los mismos datos de arriba (pag. 18 del documento Batuz_LROE_Especificaciones_Envío_Masivo_V1_0_7.pdf).
3. Como empresa desarrolladora de software, debes gestionarlo en ambas.

[Eric Mtz]

Hola a todos, ¿Cómo lo lleváis?, parece que poco a poco vamos avanzando entre todos, ¡Ánimo ostia!
Bueno... me habéis pillado, hasta aquí la parte positiva del mensaje, como ya imaginaréis tengo un problema, aunque ésta vez para variar es de ámbito teórico, en fin, allá va:

Estoy redactando la memoria descriptiva del software para solicitar el certificado y el caso es que exigen una descripción detallada del proceso de firma... Mmm... Entiendo... ¿¡Qué!?

Es decir "tipos de certificados admitidos" es algo que puedo medio concretar, pero ¿Arquitectura de la firma?... ¡No tengo ni idea!.
Sé que utilizo algo llamado Xades, que los certificados se almacenan en variables de tipo X509Certificate2, y que al realizar la firma se ejecutan doscientas funciones distintas pero ya está, no sabría concretar nada más, pero piden y cito textualmente "Una descripción del proceso de firma en función del tipo de certificado utilizado".

Bueno señores, recuperando la cordura, me da la sensación de que es mas sencillo de lo que lo estoy planteando, aunque realmente no estoy seguro ya que todo este tema de los certificados me pilla un poco verde.

Como siempre cualquier ayuda es bien recibida, gracias de antemano a todos los que andáis por aquí resolviendo dudas, esta comunidad es esencial para cualquiera que quiera implementar el TicketBAI y salir con vida del intento.

Un saludo.

[Sistel]

Empezado por Eric Mtz

...
Estoy redactando la memoria descriptiva del software para solicitar el certificado y el caso es que exigen una descripción detallada del proceso de firma... Mmm... Entiendo... ¿¡Qué!?
Es decir "tipos de certificados admitidos" es algo que puedo medio concretar, pero ¿Arquitectura de la firma?... ¡No tengo ni idea!.
Sé que utilizo algo llamado Xades, que los certificados se almacenan en variables de tipo X509Certificate2, y que al realizar la firma se ejecutan doscientas funciones distintas pero ya está, no sabría concretar nada más, pero piden y cito textualmente "Una descripción del proceso de firma en función del tipo de certificado utilizado".
...

Hola Eric Mtz,

Lo tienes todo en el documento de Especificaciones funcionales y técnicas del sistema TicketBAI en la página 8, punto 5, donde dice:
A la declaración de alta deberá adjuntarse la memoria descriptiva a la que se refiere el número 5.º del apartado anterior, en la que deberán describirse los siguientes extremos:

Fíjate en los puntos:
1) Tipo de software (según las categorías descritas en el artículo 2 de la presente Orden Foral): aplicación de escritorio y/o aplicación con arquitectura distribuida
Debes indicar si tu aplicación es de escritorio (local) o es aplicación con arquitectura distribuida (servidor)

3) Proceso de firma de los ficheros de alta y de anulación de operación con software garante, indicando en particular, los tipos de certificados electrónicos que pueden ser utilizados por el software garante para el proceso de firma
Debes indicar cómo será el proceso de firma y el tipo de certificados que usará la aplicación (de representante, de persona física, de autónomo, de dispositivo o sello de empresa)

Hoy he presentado yo la solicitud de la primera de mis aplicaciones de software garante.
Con un par de folios para la memoria descriptiva (indicando cada uno de los puntos de esa página 8, punto 5) me ha sobrado espacio.
A ver si no me ponen ninguna pega.

Saludos

[tejano]

Buenos días,

Me surge una duda, y no sé si os ha pasado a vosotros. En el caso de las autofacturas por parte de nuestros clientes, en el código QR que debemos poner como Serie, lo digo porque el cliente únicamente da un número de factura y no se sabe cual es la serie y dentro del código QR va la serie "&s=&nf=B1159766001"

Gracias

[yaedev]

Empezado por tejano

Buenos días,

Me surge una duda, y no sé si os ha pasado a vosotros. En el caso de las autofacturas por parte de nuestros clientes, en el código QR que debemos poner como Serie, lo digo porque el cliente únicamente da un número de factura y no se sabe cual es la serie y dentro del código QR va la serie "&s=&nf=B1159766001"

Gracias

La serie de facturación es opcional. Por lo que si no hay serie, no hay que ponerla y te tendría que aceptarlo. ¿Cuándo te devuelve error: si concatenas el campo sin ningn valor o si no incluyes el campo?

11.2 ¿Los ficheros XML-TicketBAI tienen que informar siempre de la serie de la factura?
No. De acuerdo con el artículo 6 del Reglamento de facturación, una factura deberá contener su número, y en su caso, su serie. Por lo que, en principio, la serie no es un dato obligatorio de una factura. Así, el citado artículo 6 del reglamento de facturación establece que "se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza"

https://www.gipuzkoa.eus/documents/2456431/13761128/1-FAQ-TEXTO+UNIFICADO+19-05-2021.pdf/029ebb00-0fb1-aefe-cfde-2bae0eef4dd6

[tejano]

Empezado por yaedev

La serie de facturación es opcional. Por lo que si no hay serie, no hay que ponerla y te tendría que aceptarlo. ¿Cuándo te devuelve error: si concatenas el campo sin ningn valor o si no incluyes el campo?

11.2 ¿Los ficheros XML-TicketBAI tienen que informar siempre de la serie de la factura?
No. De acuerdo con el artículo 6 del Reglamento de facturación, una factura deberá contener su número, y en su caso, su serie. Por lo que, en principio, la serie no es un dato obligatorio de una factura. Así, el citado artículo 6 del reglamento de facturación establece que "se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza"

https://www.gipuzkoa.eus/documents/2456431/13761128/1-FAQ-TEXTO+UNIFICADO+19-05-2021.pdf/029ebb00-0fb1-aefe-cfde-2bae0eef4dd6

El error me lo da al concatenar el fichero QR, al no tener serie he probado a poner el el QR "https://batuz.eus/QRTBAI/?id=TBAI-CIF_EMPRESA-280221-FIRMA_XML-CRC8&s=&nf=NRO_AUTOFACTURA&i=IMPORTE&cr=CRC8" o incluso a no poner el campo Serie "https://batuz.eus/QRTBAI/?id=TBAI-CIF_EMPRESA-280221-FIRMA_XML-CRC8&nf=NRO_AUTOFACTURA&i=IMPORTE&cr=CRC8" y con ninguna de las 2 me deja.

Gracias

[yaedev]

Echando un vistazo también a la parte burocrática y legal sobre los requisitos y obligaciones del software garante, quería hacer un checklist de acciones permitidas o no, que se me pueden colar. Hay que restringir muchas las acciones que hasta ahora se podía "hacer" en un software.... Bueno, en parte a algun@s ya nos va a servir para la futura ley nacional, el que no se pueda mangonear las facturaciones, aunque no sea por un fin ilícito, sino por la costumbre de editar o borrar en vez de anular o rectificar.


Leyendo del boletín oficial, el software garante de cumplir con ciertas condiciones:

"Que el software cumple de forma incondicionada sin salvedad ni reserva alguna, todas las condiciones y requisitos establecidos en los artículos 122 bis y 113 bis de las Normas Forales del Impuesto sobre Sociedades y del Impuesto sobre la Renta de las Personas Físicas, respectivamente, relativos al sistema informático garante de la trazabilidad e inviolabilidad de los registros que documenten las entregas de bienes y prestaciones de servicios, y en la presente Orden Foral."

link: https://www.batuz.eus/fitxategiak/ba...fff1ab3ce3c5e5

Art. 122 bis. Obligación de utilizar un sistema informático que garantice la integridad, conservación, trazabilidad, inviolabilidad y remisión de los ficheros que documenten las entregas de bienes y prestaciones de servicios.(...)

Link: https://www.iberley.es/legislacion/n...gicas-26852041



Que está permitido y qué no:

• No se pueden modificar ni eliminar facturas / tickets emitidos. Si la ha fastidiado, obligar al usuario a crear una factura de anulación o de rectificación según proceda el caso.
• Cuando el envío del fichero TicketBAI no es inminente: por ejemplo, la tienda ha generado un ticket de ventas y por consiguiente el fichero ticket BAI, el cual ha quedado almacenado en el PC. Si el usuario pierde el fichero TicketBAI (fallos disco, virus, etc.) ¿Se puede permitir que vuelva a generar el fichero TicketBAI de un ticket / factura emitida pero que aún no ha sido enviado a Hacienda?
• Cuando creas una nueva factura o ticket ¿permites que se pueda editar la fecha-hora de expedición?
• No sé si vuestro programa genera cobros y pagos (o vencimientos), pero en caso de que sí, una vez generados ¿entiendo que tampoco se pueden modificar ni eliminar? Salvo el poder actualizar su estado (cobrado / pagado), la fecha en que se ha pagado / cobrado y la forma de pago....
• En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

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

Empezado por yaedev

Cuando el envío del fichero TicketBAI no es inminente: por ejemplo, la tienda ha generado un ticket de ventas y por consiguiente el fichero ticket BAI, el cual ha quedado almacenado en el PC. Si el usuario pierde el fichero TicketBAI (fallos disco, virus, etc.) ¿Se puede permitir que vuelva a generar el fichero TicketBAI de un ticket / factura emitida pero que aún no ha sido enviado a Hacienda?

Creo que el envío debe ser "lo antes posible", por lo tanto no se a qué te refieres con "que quede almacenado en el PC" cuando no es inminente.
De todas formas, la idea es que cuando generas el ticket debes firmarlo, porque necesitas el TBAI (incluye la firma) y a su vez ese debe ir impreso en el ticket que se lleva el cliente. Quieren asegurar que cuando el cliente sale con el ticket/factura ya la has firmado.
Por lo tanto no puedes volver a generar el TicketBAI, porque no sería el mismo que el original.
Si los has perdido, debeás justificarlo por los cauces adecuados para ello.

Empezado por yaedev

Cuando creas una nueva factura o ticket ¿permites que se pueda editar la fecha-hora de expedición?

En teoría debes poder modificar cualquier cosa de la factura/ticket, que no afecte a los campos del TicketBAI. Por poner un ejemplo, si tienes un campo descripción, puedes modificar y guardar, siempre que no sean datos del TBAI.

Empezado por yaedev

No sé si vuestro programa genera cobros y pagos (o vencimientos), pero en caso de que sí, una vez generados ¿entiendo que tampoco se pueden modificar ni eliminar? Salvo el poder actualizar su estado (cobrado / pagado), la fecha en que se ha pagado / cobrado y la forma de pago....

Los cobros/Pagos/vencimientos de la factura son independientes de la propia factura.
Que cobres el total o parte de ella no debería afectar a la factura.
(tal vez no te he entendido)

Empezado por yaedev

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

Los clientes no deberían tener acceso a la Base de Datos y si lo hacen debe quedar claro que es su responsabilidad (por ejemplo, vía un contrato).

[Eric Mtz]

Buenos días y/o tardes señores, tengo otro problema. (Como podéis ver estoy en racha)

El de hoy tiene tela, veréis, estoy realizando el envío de facturas a Bizkaia, y con el modelo 240 no tengo problemas, sin embargo al realizar el envío del 140 no logro que tan siquiera me devuelvan una respuesta, el servidor directamente rechaza la solicitud y no entiendo la razón, utilizo las clases del modelo 140 e incluso la cabecera del envío tiene la estructura que ellos exigen.

El certificado que empleo para el envío es el del DNI electrónico, ¿Utilizáis vosotros también el DNI? ¿Os ha funcionado? ¿Hicisteis algo especial?, bueno, como digo siempre cualquier ayuda será bien recibida.

Un saludo y que paséis un buen fin de semana, a no ser que trabajes para hacienda... nah es broma, todo el mundo a descansar que el lunes hay que seguir.

[Sistel]

Empezado por Eric Mtz

Buenos días y/o tardes señores, tengo otro problema. (Como podéis ver estoy en racha)

El de hoy tiene tela, veréis, estoy realizando el envío de facturas a Bizkaia, y con el modelo 240 no tengo problemas, sin embargo al realizar el envío del 140 no logro que tan siquiera me devuelvan una respuesta, el servidor directamente rechaza la solicitud y no entiendo la razón, utilizo las clases del modelo 140 e incluso la cabecera del envío tiene la estructura que ellos exigen.

El certificado que empleo para el envío es el del DNI electrónico, ¿Utilizáis vosotros también el DNI? ¿Os ha funcionado? ¿Hicisteis algo especial?, bueno, como digo siempre cualquier ayuda será bien recibida.

Un saludo y que paséis un buen fin de semana, a no ser que trabajes para hacienda... nah es broma, todo el mundo a descansar que el lunes hay que seguir.

Hola Eric Mtz,

En las Especificaciones del Envío Masivo del LROE 1.0.7, en la página 14 dice:
Los tipos de certificados admitidos para los envíos de los LROE son los siguientes:
o Certificado de persona física.
o Certificado de representante de entidad.
o Sello de empresa.
o Sello de autónomo.
o Certificado de dispositivo (debe estar censado para el obligado tributario en DFB/BFA).

No habla nada de que se admita el DNI electrónico.

Saludos

[Sistel]

Empezado por yaedev

...
Que está permitido y qué no:

• No se pueden modificar ni eliminar facturas / tickets emitidos. Si la ha fastidiado, obligar al usuario a crear una factura de anulación o de rectificación según proceda el caso.
• Cuando el envío del fichero TicketBAI no es inminente: por ejemplo, la tienda ha generado un ticket de ventas y por consiguiente el fichero ticket BAI, el cual ha quedado almacenado en el PC. Si el usuario pierde el fichero TicketBAI (fallos disco, virus, etc.) ¿Se puede permitir que vuelva a generar el fichero TicketBAI de un ticket / factura emitida pero que aún no ha sido enviado a Hacienda?
• Cuando creas una nueva factura o ticket ¿permites que se pueda editar la fecha-hora de expedición?
• No sé si vuestro programa genera cobros y pagos (o vencimientos), pero en caso de que sí, una vez generados ¿entiendo que tampoco se pueden modificar ni eliminar? Salvo el poder actualizar su estado (cobrado / pagado), la fecha en que se ha pagado / cobrado y la forma de pago....
• En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

Hola yaedev,

Creo que son buenas consultas para que les hagas, por email, a los chicos de TicketBAI (y que nos cuentes después la respuesta)

Te doy mis opiniones de algunas de las cuestiones:

Cuando creas una nueva factura o ticket ¿permites que se pueda editar la fecha-hora de expedición?

Como la firma de la factura debe ser en el mismo momento de creación de la factura, la fecha y hora de la factura debería ser la misma que la de la firma.
No se debe modificar una vez firmada.

No sé si vuestro programa genera cobros y pagos (o vencimientos), pero en caso de que sí, una vez generados ¿entiendo que tampoco se pueden modificar ni eliminar? Salvo el poder actualizar su estado (cobrado / pagado), la fecha en que se ha pagado / cobrado y la forma de pago....

Los temas de cobros, pagos y vencimientos son temas contables que no deben afectar en nada al fichero XML firmado de la factura.
Además esos temas contables a Hacienda no le interesan en absoluto (le da igual que puedas cobrar o no una factura, por ejemplo).

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

El cliente debe guardar los ficheros XML firmados de las facturas INTACTOS.
Es de vital importancia que no se alteren en ningún caso.
Para que no me salpique, en caso de que el cliente haga alguna de las suyas, yo prefiero que esos ficheros XML firmados estén bajo mi custodia en mis propios servidores.
Al cliente le doy sólo acceso remoto de sólo lectura a esos ficheros.

Son bienvenidos los comentarios sobre estos temas.

Saludos
PD: Veo que el colega Neftali [Germán.Estévez] acababa de contestar también a esas cuestiones

[HerensugeBeltz]

Empezado por Sistel

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

El cliente debe guardar los ficheros XML firmados de las facturas INTACTOS.
Es de vital importancia que no se alteren en ningún caso.
Para que no me salpique, en caso de que el cliente haga alguna de las suyas, yo prefiero que esos ficheros XML firmados estén bajo mi custodia en mis propios servidores.
Al cliente le doy sólo acceso remoto de sólo lectura a esos ficheros.

Son bienvenidos los comentarios sobre estos temas.

Hola,

Yo todavía tengo el tema muy verde, pero en cuanto al almacenamiento de los ficheros XML mi idea era grabarlos en la propia base de datos, en un campo BLOB del registro de la factura asociada.
¿Alguien ve algún problema en ello? (aparte del tamaño que pueda alcanzar la base de datos aunque, según mi experiencia, esto sólo afecta a las copias de seguridad, no a la velocidad de acceso a datos [Firebird])

Gracias.

[yaedev]

Gracias por vuestras respuestas!

Empezado por Neftali

Creo que el envío debe ser "lo antes posible", por lo tanto no se a qué te refieres con "que quede almacenado en el PC" cuando no es inminente.
De todas formas, la idea es que cuando generas el ticket debes firmarlo, porque necesitas el TBAI (incluye la firma) y a su vez ese debe ir impreso en el ticket que se lleva el cliente. Quieren asegurar que cuando el cliente sale con el ticket/factura ya la has firmado.
Por lo tanto no puedes volver a generar el TicketBAI, porque no sería el mismo que el original.
Si los has perdido, debeás justificarlo por los cauces adecuados para ello.

En el caso de Gipuzkoa y Araba el envío sí sería inmediato. En Bizkaia es trimestral, mensual o según el SII, vamos que no es inmediato. No obstante, aunque los 2 primeros sea inmediato. Imagina que en ese momento tienes un fallo de red o de comunicación o cualquier otra causa que te imposibilite remitir el fichero, se tendría que poder enviar después.

Empezado por Sistel

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

El cliente debe guardar los ficheros XML firmados de las facturas INTACTOS.
Es de vital importancia que no se alteren en ningún caso.
Para que no me salpique, en caso de que el cliente haga alguna de las suyas, yo prefiero que esos ficheros XML firmados estén bajo mi custodia en mis propios servidores.
Al cliente le doy sólo acceso remoto de sólo lectura a esos ficheros.

Son bienvenidos los comentarios sobre estos temas.

Saludos
PD: Veo que el colega Neftali [Germán.Estévez] acababa de contestar también a esas cuestiones

Claro, en mi caso es software de escritorio con bases de datos locales. Por ahora inviable montar sistema para almacenar en servidores propios los ficheros. En el caso de FacturaE, los ficheros también los almaceno en el ordenador. LA idea es hacerlo igual....


Pero entiendo que si un usuario coge un bloc de notas y edita el XML firmado. ¿La firma ya no sería válida, no? porque la firma se basa también en el contenido del fichero, por lo que si algo cambia, la firma sería inválida. Es que aún no he llegado a esa parte, si no lo hubiera probado.

Creo que son buenas consultas para que les hagas, por email, a los chicos de TicketBAI (y que nos cuentes después la respuesta)

Sí, voy recopilando dudas para enviarlas...



Un saludo!

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

Empezado por yaedev

En el caso de Gipuzkoa y Araba el envío sí sería inmediato. En Bizkaia es trimestral, mensual o según el SII, vamos que no es inmediato. No obstante, aunque los 2 primeros sea inmediato. Imagina que en ese momento tienes un fallo de red o de comunicación o cualquier otra causa que te imposibilite remitir el fichero, se tendría que poder enviar después.

Como estabas hablando de fichero de TicketBAI pensaba que hablabas de Guipuzkoa/Araba. Bizkaia es batuz (que incluye ticketBAI).

En el primer caso, como he dicho, debes enviar el fichero "lo antes posible". Si en un momento dado, los servidores están caídos, pues deberás enviarlo en cuanto puedas (lo antes posible).

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

Empezado por yaedev

Pero entiendo que si un usuario coge un bloc de notas y edita el XML firmado. ¿La firma ya no sería válida, no? porque la firma se basa también en el contenido del fichero, por lo que si algo cambia, la firma sería inválida. Es que aún no he llegado a esa parte, si no lo hubiera probado.

Si editas un fichero firmado y lo intentas enviar fallará porque la firma no coincide y fallará la validación.

[Eric Mtz]

Empezado por Sistel

Hola Eric Mtz,

Lo tienes todo en el documento de Especificaciones funcionales y técnicas del sistema TicketBAI en la página 8, punto 5, donde dice:
A la declaración de alta deberá adjuntarse la memoria descriptiva a la que se refiere el número 5.º del apartado anterior, en la que deberán describirse los siguientes extremos:

Fíjate en los puntos:
1) Tipo de software (según las categorías descritas en el artículo 2 de la presente Orden Foral): aplicación de escritorio y/o aplicación con arquitectura distribuida
Debes indicar si tu aplicación es de escritorio (local) o es aplicación con arquitectura distribuida (servidor)

3) Proceso de firma de los ficheros de alta y de anulación de operación con software garante, indicando en particular, los tipos de certificados electrónicos que pueden ser utilizados por el software garante para el proceso de firma
Debes indicar cómo será el proceso de firma y el tipo de certificados que usará la aplicación (de representante, de persona física, de autónomo, de dispositivo o sello de empresa)

Hoy he presentado yo la solicitud de la primera de mis aplicaciones de software garante.
Con un par de folios para la memoria descriptiva (indicando cada uno de los puntos de esa página 8, punto 5) me ha sobrado espacio.
A ver si no me ponen ninguna pega.

Saludos

Gracias por la ayuda Sistel, ya lo he enviado, a ver si los dos tenemos suerte y nos lo aceptan.

[Sistel]

Empezado por Eric Mtz

Gracias por la ayuda Sistel, ya lo he enviado, a ver si los dos tenemos suerte y nos lo aceptan.

Hola Eric Mtz,

Presenté la petición de registro de mi primer software garante TicketBAI el pasado miércoles 16 de junio.
He entrado hoy en la sede electrónica de la Diputación Foral y veo que el pasado sábado 19 de junio estaba aprobada su inscripción.
Y ya está en el registro de softwares garantes de TicketBAI.
¡¡¡ Qué rapidez !!!
Eso sí, no me han enviado ni email ni aviso de ninguna forma.

Saludos

[Edgar7]

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

1. Los del usuario. Creo que los usuarios no. Esos datos ya los tienen la hacienda Vasca.
2. Si, los mismos datos de arriba (pag. 18 del documento Batuz_LROE_Especificaciones_Envío_Masivo_V1_0_7.pdf).
3. Como empresa desarrolladora de software, debes gestionarlo en ambas.

Muchas gracias Neftali! A ver si vamos saliendo del túnel poco a poco entre todos.