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

[CMB]

Buenas tardes

¿Saben si existe alguna convención en cuanto al nombre de los ficheros TBAI? En las especificaciones hace referencia en muchas ocasiones a dichos ficheros pero no dice nada sobre qué nombre asignarles.


Supongo que lo más natural sería usar el Identificativo TBAI, tal como está definido en la sección 4.3.2 del documento TicketBAI_Especificaciones_v_1_1.pdf, no obstante al contener un extracto del campo SignatureValue, que está codificado en Base64, este puede contener carácteres especiales por lo que no sería muy adecuado.


¿Se supone que debemos definir nuestro propio esquema para nombrar los ficheros?

[Sistel]

Hola,

Novedades sobre deducciones y bonificaciones, en Gipuzkoa, por la puesta en marcha de TicketBAI.
https://www.camaragipuzkoa.com/index...hive&task=view

Saludos

[Sistel]

Empezado por CMB

Buenas tardes

¿Saben si existe alguna convención en cuanto al nombre de los ficheros TBAI? En las especificaciones hace referencia en muchas ocasiones a dichos ficheros pero no dice nada sobre qué nombre asignarles.


Supongo que lo más natural sería usar el Identificativo TBAI, tal como está definido en la sección 4.3.2 del documento TicketBAI_Especificaciones_v_1_1.pdf, no obstante al contener un extracto del campo SignatureValue, que está codificado en Base64, este puede contener carácteres especiales por lo que no sería muy adecuado.


¿Se supone que debemos definir nuestro propio esquema para nombrar los ficheros?

Hola CMB,

No acabo de entender tu pregunta.
Si te refieres al nombre que debe tener cada fichero XML firmado de TicketBAI al guardarlo en la aplicación de facturación, no he leído que haya ninguna norma obligatoria.
Parece lógico que puedas guardar con el nombre que quieras y dentro de la estructura de directorios que mejor te venga.
Entiendo que es tu tema interno de tu aplicación.

Saludos

[chuski1212]

Hola a todos! Que maravilla de foro!

Estoy intentando implementar el sistema Ticket BAI utilizando node y la libreria xadesjs, pero no consigo que el sistema de pruebas de Guipuzkoa me acepte el fichero de alta.
Siempre me devuelve error Codigo 006 Error al verificar la firma

Alguien ha conseguido hacerlo funcionar utilizando esta tecnologia?

Gracias a todos!

[ermendalenda]

Empezado por chuski1212

Hola a todos! Que maravilla de foro!

Estoy intentando implementar el sistema Ticket BAI utilizando node y la libreria xadesjs, pero no consigo que el sistema de pruebas de Guipuzkoa me acepte el fichero de alta.
Siempre me devuelve error Codigo 006 Error al verificar la firma

Alguien ha conseguido hacerlo funcionar utilizando esta tecnologia?

Gracias a todos!

Hola, para asegurarte que no es otra cosa, primero pasa tus ficheos por estos comprobadores, si te dan ok en los 2, busca otro problema que no sea la firma:
https://web.uanataca.com/pe/servicio...ma-electronica
http://tools.chilkat.io/xmlDsigVerif...#generatedCode

[ermendalenda]

Duda, sobre precios, no he visto ningún indicativo en TBAI que haga referencia a la zona o formato de los articulos vendidos, pongo un ejemplo en un restaurante:

*Llega una familia que pide mesa y se toman un par de cañas en la Barra, y según carta precio de la Caña en Barra: 1,50€, precio en terraza 1,75€.
en la factura el mismo artículo está con 2 precios (No hay descuentos)
Conoceis alguna normativa al respecto?
Puedo usar la misma serie de factura o tengo que cobrar en 2 facturas?

Y hay viene mi paranoia:
Suponiendo que sí, pienso que dado lo novedoso del manejo de estos datos, pueden crear alertas que se está vendiendo a precios distintos y generar falsas alarmas que al principio puede derivar en inspecciones, aunque supongo que si no lo tiene en cuenta al principio iran regulanddo esas alertas y no me extraña que con el tiempo pidan que se hagan en numeros de serie diferentes o añadan algun otro campo-
Aparte de que todo esto tiene pinta de que aquí no se escapa ni el tato con las estrictas normativas respecto a los precios, que si no se puede vender por debajo de costo(por lo de la competencia desleal en los casos no incluidos en la ley por ofertas específicas, fecha próxima de caducidad...) , que si hay descuento los demás clientes tengan las mismas posibilidades para acceder a ese descuento(incluidos descuentos al personal por supuesto).
Etc etc...
Enfín Serafín, a ver quién es capaz de librarse del látigo.

[ermendalenda]

Más paranoias,
Debe haber algún tipo de regulación que de alguna forma nos proteja a los desarrolladores y vendedores de software garante. Digo yo vamos. Si no vaya tela el contrato que habrá que redactar para alquilar o vender el programa, por que se me plantean un montón de escenarios (si nadie puede continuar con la venta/mantenimiento del software) :
1.me quiero jubilar
2.me toca la loteria
3.me quedo manco o me quedotonto de un golpe en la cabeza
4quiero cambiar de profesion
5. La empresa entra en quiebra y tengo que cerrar
Mmmm
No sé si alguien va a querer un software con cláusulas de rescision tan evidentes y además de algún modo debo hacer que deje de funcionar (al menos que no se puedan emitir más facturas)
Para las pequeñas empresas de venta de software, lo veo negro. O se le echa mucho estómago y se tapa uno la nariz sin mirar el futuro.

[YellowStone]

Empezado por ermendalenda

Duda, sobre precios, no he visto ningún indicativo en TBAI que haga referencia a la zona o formato de los articulos vendidos, pongo un ejemplo en un restaurante:

*Llega una familia que pide mesa y se toman un par de cañas en la Barra, y según carta precio de la Caña en Barra: 1,50€, precio en terraza 1,75€.
en la factura el mismo artículo está con 2 precios (No hay descuentos)
Conoceis alguna normativa al respecto?
Puedo usar la misma serie de factura o tengo que cobrar en 2 facturas?

Y hay viene mi paranoia:
Suponiendo que sí, pienso que dado lo novedoso del manejo de estos datos, pueden crear alertas que se está vendiendo a precios distintos y generar falsas alarmas que al principio puede derivar en inspecciones, aunque supongo que si no lo tiene en cuenta al principio iran regulanddo esas alertas y no me extraña que con el tiempo pidan que se hagan en numeros de serie diferentes o añadan algun otro campo-
Aparte de que todo esto tiene pinta de que aquí no se escapa ni el tato con las estrictas normativas respecto a los precios, que si no se puede vender por debajo de costo(por lo de la competencia desleal en los casos no incluidos en la ley por ofertas específicas, fecha próxima de caducidad...) , que si hay descuento los demás clientes tengan las mismas posibilidades para acceder a ese descuento(incluidos descuentos al personal por supuesto).
Etc etc...
Enfín Serafín, a ver quién es capaz de librarse del látigo.

¿Y por qué tiene que ser el mismo artículo? No creo que la solución sea enviar dos facturas. Creo yo que lo lógico es que tengas en este caso dos artículos: "Caña en barra" un artículo; "Caña en terraza", otro. Más o menos es lo mismo que si unos amigos te piden tres "tercios" uno de Mahou, otro de Heineken y otro de Cruzcampo. ¿vas a hacer tres facturas separando los "tercios" porque cada uno tiene un precio?

[Band]

Empezado por YellowStone

¿Y por qué tiene que ser el mismo artículo? No creo que la solución sea enviar dos facturas. Creo yo que lo lógico es que tengas en este caso dos artículos: "Caña en barra" un artículo; "Caña en terraza", otro. Más o menos es lo mismo que si unos amigos te piden tres "tercios" uno de Mahou, otro de Heineken y otro de Cruzcampo. ¿vas a hacer tres facturas separando los "tercios" porque cada uno tiene un precio?

Yo no estoy muy puesto en temas de restauración, pero conozco un caso cercano que el lo trata por familia. Es decir, tiene una familia = terraza y otra familia = local. En la familia terraza le aplica un aumento fijo de 0,1 o 0,2€ por lo que el lo arregla sin poner más artículos en el sistema, simplemente con una familia la cual incrementa a los artículos un pequeño importe para el suplemento de terraza. Lo que también te sirve para la factura o ticket, puesto que puedes detallarlo fácilmente al saber la familia a la que pertenece

[chuski1212]

Empezado por ermendalenda

Hola, para asegurarte que no es otra cosa, primero pasa tus ficheos por estos comprobadores, si te dan ok en los 2, busca otro problema que no sea la firma:

Gracias por el consejo!

Chilkat me devuelve lo siguiente:

Signature is Invalid
Number of Reference Digests = 2
Reference 1 digest is valid.
Reference 2 digest is valid.

Lo cual me da a entender que efectivamente no estoy firmando bien. No se ya por donde tirar porque mi fichero es practicamente igual que los ficheros de ejemplo

[defcon1_es]

Buenas tardes.

El ERP de la empresa tiene una numeración de más de 7 dígitos y en el XSD el dato <NumFactura> admite hasta 20 dígitos;
todo el proceso se realiza correctamente en el entorno de pruebas excepto la comprobación del QR, que muestra el mensaje:

  
  Faktura zenbakia - Número de factura 
  FB - 0020021001000001 ≠ FB - 1000001 
  Faktura jaso da, baino balioak ez datoz bat
  Factura recibida pero los valores no coinciden

Ya he enviado un email a ticketbaikontsultak@gipuzkoa.eus pero aun no me han respondido.

¿Os pasa esto a alguno de vosotros?

[ermendalenda]

Empezado por defcon1_es

Buenas tardes.

El ERP de la empresa tiene una numeración de más de 7 dígitos y en el XSD el dato <NumFactura> admite hasta 20 dígitos;
todo el proceso se realiza correctamente en el entorno de pruebas excepto la comprobación del QR, que muestra el mensaje:

  
  Faktura zenbakia - Número de factura 
  FB - 0020021001000001 ≠ FB - 1000001 
  Faktura jaso da, baino balioak ez datoz bat
  Factura recibida pero los valores no coinciden

Ya he enviado un email a ticketbaikontsultak@gipuzkoa.eus pero aun no me han respondido.

¿Os pasa esto a alguno de vosotros?

Estas usando caracteres en el nunero de factura?
No se pueden enviar caracteres en número de factura. La parte fija( que no sea numeración correlativa) pertenece a la serie.

[ermendalenda]

Empezado por chuski1212

Gracias por el consejo!

Chilkat me devuelve lo siguiente:

Signature is Invalid
Number of Reference Digests = 2
Reference 1 digest is valid.
Reference 2 digest is valid.

Lo cual me da a entender que efectivamente no estoy firmando bien. No se ya por donde tirar porque mi fichero es practicamente igual que los ficheros de ejemplo

Correcto algo no está bien. Parece que puede tener que ver con el canonizador.
En el xml usas uno y el firmador espera otro. Comprueba el encabezado del XML.
Comprueba también que no hayas insertado caracteres especiales sin convertirlos a utf8
Como son las vocales con tildes etc..

[ermendalenda]

Empezado por CMB

Buenas tardes

¿Saben si existe alguna convención en cuanto al nombre de los ficheros TBAI? En las especificaciones hace referencia en muchas ocasiones a dichos ficheros pero no dice nada sobre qué nombre asignarles.


Supongo que lo más natural sería usar el Identificativo TBAI, tal como está definido en la sección 4.3.2 del documento TicketBAI_Especificaciones_v_1_1.pdf, no obstante al contener un extracto del campo SignatureValue, que está codificado en Base64, este puede contener carácteres especiales por lo que no sería muy adecuado.


¿Se supone que debemos definir nuestro propio esquema para nombrar los ficheros?

Buenas, no hay especificaciones sobre la estructura del nombre de fichero.
Si te sirve yo he usado esta estructura:
C:\TBAIFILES\[AÑO] \[YYYY-MM-DD] \FACT_[YYYYMMDD] _[HHMMSS]_[Serie]-[Número]. XML

Que hace fácil identificarlos y ordenarlos cronológicamente por el nombre del fichero, a la par de que no creas carpetas con demasiados ficheros que pueden dar lugar a ciertos problemas.
Lo que sí hay que indicar en el formulario de alta es:
Sistema de almacenamiento de los ficheros de alta y de anulación de operación
con software garante.
Con lo cual no estaria de más(si es posible) indicar de alguna forma donde están ubicados.