A este respecto tengo una duda.

Hasta ahora no he hecho ninguna codificación de este tipo, y hasta donde he visto los QR me leen bien (Gipuzkoa)

De todas formas, me he propuesto hacer un "urlencode()" mediante PHP, por asegurar, y aquí me ha entrado la duda.

Entiendo que el CRC8 de la URL, que luego se agrega mediante "&cr=", se hace con la URL real que va a llevar la imagen QR, con codificación y todo, ¿correcto?

Es decir, que no tengo que generar un CRC8 a partir de la URL que tiene el TBAI original, tal como es en realidad, y luego codificar la URL para el QR...

Gracias!

En Bizkaia y en Gipuzkoa, tienes que calcular el crc con la url ya modificada, en Araba no es necesario

Yo lo estoy enviando de esta forma, en real

curl --insecure --cert-type P12 --cert path_certificado:password -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"NIF_EMPRESA\",\"nrs\":\"NOMBRE_EMPRESA\"} ,\"drs\":{\"mode\":\"240\",\"ejer\":\"2022\"}}" -v "https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena" --data-binary "@path_archivo_gz" --output c:\tmp\respuesta.gz -D c:\tmp\cabecera.txt

Llevamos desde el 1 de enero enviando datos a la BFA y no tenemos problema.

qr cuando hay un + o / en SignatureValue
 

La respuesta que me dieron los de soporte de Bfa era correcta aunque me costó entenderla.

De la firma extraigo los 13 primeros caracteres de ‘SignatureValue’, en mi caso Wx+Royp0h3nOY
cText:=”zzzz batuz.eus/QRTBAI/?id=TBAI-14894343A-081022-Wx+Royp0h3nOY-“
Calculo el crc8 lo los 36 últimos caracteres TBAI-14894343A-081022-Wx+Royp0h3nOY-
Que es: 125, los añado y también la serie, el número de factura y el importe
zzzz batuz.eus/QRTBAI/?id=TBAI-14894343A-081022-Wx+Royp0h3nOY-125&s=FAC&nf=100019&i=1.62
Sustituyo el signo + por %2B
zzzz batuz.eus/QRTBAI/?id=TBAI-14894343A-081022-Wx%2BRoyp0h3nOY-125&s=FAC&nf=100019&i=1.62
y calculo el crc, que es 1, lo añado y ya está
ctext:=zzzz batuz.eus/QRTBAI/?id=TBAI-14894343A-081022-Wx%2BRoyp0h3nOY-125&s=FAC&nf=100019&i=1.62&cr=001

Buenas!,

¿Os funciona el servicio de consultar QR?

https://tbai.prep.gipuzkoa.eus/qr/

A mi me viene dando 503 desde la semana pasada...

A mi me está funcionando correctamente.
Una consultada ahora mismo:
https://tbai.prep.gipuzkoa.eus/qr/?i...&i=3.63&cr=029

Gracias,

Acabo de probar y ahora sí, carga bien.

Hola!


Un cliente que esta con recargo de equivalencia me comenta que las facturas las estoy emitiendo mal.
Me ha pasado un pantallazo donde pone:
Datos IRPF y supuestamente el Importe ingreso IRPF es incorrecto(está poniendo la base imponible y debería ir el total), pero yo no le digo en ningún sitio el importe del IRPF, entonces imagino que los tiros irán por que tengo que indicar que el usuario tiene recargo de equivalencia? Si es así, sabéis donde se marca esto?


Gracias de antemano.

Me contesto:
Termino de ver el aparato Renta > Detalle renta > *Epigrafe *IngresoacomputarirpfdirefentebaseimpoIVA * ImporteIngresoIRPF *CriterioCobrosYPagos
Pero mi duda es, el recargo de equivalencia es para compras, no para ventas, por lo que si mi cliente compra con recargo de equivalencia, al cliente final no puede meterle el recargo de equivalencia... Tengo que Marcar estas casillas?¿?

Modificaciones de Ticket BAI Bizkaia
 

Hola, buenas tardes.

¿Alguno de vosotros está consiguiendo emitir modificaciones de Ticket BAI en Bizkaia al estilo de Zuzendu Gipuzkoa y Araba?

Por más que he leído la documentación de Bizkaia, solo he encontrado incongruencias respecto a la casuística un Ticket BAI con respuesta "Incorrecto" y deber modificar o enviar nuevo.

Detallo:

A) - Si un Ticket BAI enviado, da como resultado "<EstadoRegistro>Incorrecto</EstadoRegistro>", en un apartado de preguntas frecuentes, concretamente la 160 dicta que habría que enviar una modificación a través del subcapitulo 1.2 en vez del 1.1, ya que no hay esquema de modificaciones en el grupo con software garante y hay que hacerlo a través de esquema sin software garante. Pero no recibo más que respuestas de Incorrecto del servidor por "El registro no existe en el sistema.".

B) - Sin embargo, en la documentación "ESPECIFICACIONES FUNCIONALES Y TÉCNICAS DEL ENVÍO MASIVO DEL LROE A LA DFB/BFA" dicta que ante una presentación con respuesta "Incorrecto", las anotaciones no se graban en la DFB/BFA, y por lo que es necesario volver a enviar el Ticket BAI. (Pero si se consulta con enlace o QR, si que está registrado :confused:)

¿Qué debemos interpretar entonces al enviar un Ticket BAI por 1.1 y que se reciba "Incorrecto"?

¿Volver a enviarlo nuevo con los datos bien por la misma vía 1.1 dando resultado como Correcto y sin problemas como en pruebas que he efectuado como si lo anterior no hubiera sucedido?

¿Emitir una modificación de Ticket BAI subcapítulo 1.1 a través de 1.2? Esto no consigo hacerlo de ninguna forma y no hay documentación sobre modificaciones a través de vía subcapítulo 1.2 :confused::confused:


Un saludo

Quizás sea por la clave de operación, que estas poniendo la 01 y existe una para el recargo de equivalencia no se si la 52 o 51

De todas maneras si el cliente esta en RERE le tienes que aplicar recargo de equivalencia

Lo de la clave de la operacion no lo sabía, voy a ver si me informo.


Gracias Noe!

Ahora que al fin nos hemos registrado en guipuzkoa y tenemos el codigo, hay que hacerlo tambien en el resto? o con uno ya sirve para todos?

si te refieres a la licenciaTBAI que te dan como desarrollador, tienes que solicitar una distinta a cada diputación. De hecho, tienes que solicitar una para pruebas y otra para el entorno real

Las de pruebas son diferentes por diputación. Cuando se haya certificado, será la misma licencia de producción para las 3 diputaciones

A esto me referia, a la de produccion. Gracias

Hola a todos!
Una duda, en el caso de las facturas completas, ¿se tiene que informar del campo hora? En la documentación no veo claro que la hora sea obligatoria.
Gracias.

Hola de nuevo!

Más dudas que me surgen respecto a las fechas. En mi caso, tenemos diferentes series de facturas (por ejemplo la serie A y la serie B), y en el proceso de facturación se puede dar el caso que se generen las facturas de la serie A con una fecha 30/10/2022 de factura. Y luego se generen las facturas de la serie B con otra fecha 25/10/2022 de factura. En este caso, ¿cuál sería el orden correcto para encadenar las facturas? ¿La fecha de generación de las facturas, independientemente de la serie? O ¿Cómo lo gestionáis vosotros?

Muchas gracias.

Hola, yo tengo dos series, enviaba el encadenamiento de la última de su serie, y me daba error de encadenamiento, hice la consulta y me dijeron que la última enviada independiente de la serie, ahora ya no me da error de encadenamiento. Pero la primera consulta me dijeron lo contrario, según con quien hables allí te dice una cosa u otra.
Un saludo.

Estupendo, gracias! Y otra duda, ¿envías la hora de la factura? ¿O se puede enviar sin hora?

Hola,

El nodo <HoraExpedicionFactura> es obligatorio.
Está en rojo en https://web.araba.eus/documents/1050...00/Anexo+I.pdf

Saludos

Por un lado esto que se extrae de la documentación (preguntas frecuentes); a ver si te aclara algo:

Dependerá de cómo sea tu sistema, en el caso del nuestro, es independiente de la serie.

El tema de las fechas es complejo, ya que nosotros no dejemos (a partir de la implantación de TBAI) generar una factura anterior a una ya generada.

Añado las referencias:
https://www.gipuzkoa.eus/es/web/ogas...rreko-faktura-
https://web.araba.eus/es/hacienda/ti...ecuentes#faq14

El encadenamiento de facturas se realiza en base a la fecha de expedición de la factura, que no tiene porqué coincidir con la fecha de operación (fecha de factura). En mi opinión es perfectamente válido expedir el 30/10/22 una factura sin fecha de operación (se asume como tal la fecha de expedición) e, inmediatamente después, expedir una factura con fecha de operación de 25/10/22, que irá encadenada a la anterior, sean ambas de la misma serie o de series distintas.

Buenas,

Hay una cosa aquí que no me queda del todo clara, y no sé si es un problema de conceptos.

Tenemos por un lado lo que sería la "fecha de expedición" de una factura, que hasta donde yo entiendo, es la fecha en la que se ha "creado" una factura. Es decir, la fecha en la que una factura "cobra existencia" (con ticketbai o sin él)

Por otro lado tenemos lo que los textos sobre el encadenamiento de facturas denominan "factura expedida por el sistema", que una vez más hasta donde yo entiendo, se refiere a facturas que un dispositivo ha enviado a Hacienda, pero aquí no entramos a hablar de fechas de factura.

En la teoría puedo suponer que la fecha y hora para ambos eventos serán iguales, ya que según la normativa, "una factura debe ser enviada a Hacienda inmediatamente después de ser emitida/expedida".

Pero aquí es donde no me quedan claros estos conceptos.

A mi en su momento me dijeron que aunque "no es obligatorio" enviar las facturas en orden (me refiero a la numeración), sí es recomendable.

Es decir, que puedes enviar las facturas 30, 31, 33, 34 y 35, y después enviar la 32. Pero ojo, con el encadenamiento bien. Es decir, la 33 notificará que la 31 es la anterior, y la 32 dirá que la anterior es la 35.

Lo que no me termina de quedar claro es si la "fecha de expedición de la factura" debe corresponder en efecto a la "fecha en la que el sistema ha expedido (emitido) la factura a Hacienda"

Nosotros por ejemplo generamos las facturas en un sistema centralizado que tenemos para gestionar pedidos, cobros, etc... y una vez la factura ya tiene su número, fecha de expedición, etc. se envían a un API intermedio, que es el que envía las facturas a Hacienda. Yo el encadenamiento lo estoy calculando en este dispositivo, y los datos de la factura los ignoro (fecha, número...). Simplemente cojo la última factura que ha entrado en esa cola, ya que luego se envían en orden una por una.

Teniendo en cuenta que hay varios puntos de venta en diferentes sitios, si dos ventas se ejecutan al mismo tiempo, si hubiese retardos en el proceso de asignar fecha, enviar al API, etc... podría darse el caso que la factura 150 tenga la hora 12:35, la 151 tenga la hora 12:36, pero que sea la 151 la primera que envía la solicitud al API, por lo que el resultado de cara a Hacienda sería que envío la factura 151, y después la 150 encadenando a la 151 con la factura anterior.

Hasta ahora he entendido que esto es correcto, según lo que he leído y lo que he hablado con ellos. Pero ahora después de leer la frase de "El encadenamiento de facturas se realiza en base a la fecha de expedición de la factura", me dejas con ciertas dudas.

Porque insisto, hasta donde yo entiendo no es lo mismo la "fecha de expedición" de una factura, en lo que a contabilidad se refiere, que el momento en el que el dispositivo "expide una factura", (que a su vez dentro lleva su propia fecha de expedición).

Saludos.

Cuando hablo de fecha de expedición me refiero al instante en que genero el XML y lo firmo. Ese XML ya es intocable y esa factura figura como expedida en ese instante, con su código QR y todo. Si por un problema técnico no se puede enviar en ese momento a TicketBAI se encolará, así como las facturas sucesivas y más adelante las enviamos ordenadas por fecha de expedición (que para nosotros, repito, es la fecha de generación y firma del XML).

En vuestro caso no me queda claro si vuestro API intermedio es el que genera y firma el XML (asigna el QR) o simplemente envía los XML encolados según le llegan.

En nuestro caso el API recibe un JSON con los datos para la factura (incluyendo fecha expedición), calcula el encadenamiento, genera el XML, lo firma, y deja la factura "en espera".

Un tercer proceso va enviando estas facturas cada varios segundos.

La forma en la que lo hacéis me gusta más, y de hecho es como lo empecé a hacer hace unos meses (todo centralizado en el API), pero una cosa llevó a la otra y al final todo lo gordo del sistema de facturación se hace desde la plataforma que ya había montada en la red local de la oficina.

Buenas.. el proceso de notas de crédito aun me queda un poco nebuloso... para aclarar, nosotros (sin TBAI) teníamos un proceso simple:


1. Emitir factura normal
2. El cliente hace una devolución por X motivo.

3. Se emitía una nota de crédito y ese crédito podía ser crédito de tienda(caso mas común) o simplemente devolver efectivo.
4. Se emitía una factura nueva con el item cambiado/reemplazado.


Ahora con TBAI, si entiendo bien, el punto (2) seria emitir una factura rectificativa, en donde solo indico los items que estoy devolviendo.

y luego emitir una factura normal y corriente en caso de que se cambie o venda otra cosa? Si entiendo bien en este caso no aplica hacer una anulación?



No me queda claro la linea "Hacer la factura nueva, donde quede claro que es una “nota de crédito”." ¿Como se deja claro que es una "nota de crédito"? ¿Al ser rectificativa se implica eso?


gracias por el apoyo

Hola a todos.

¿Alguién esta teniendo problemas con el entorno de producción de Gipuzkoa?. Hemos tenido varias llamadas de clientes de Gipuzkoa diciendo que va un poco lento el envío de facturas a hacienda y hay momentos que ni contesta el servidor, se supera el tiempo de espera.

Guipouzcoa no, a nosotros nos ha llegado esto desde Álava:

Buenas,

Esta pregunta no sé si será aceptada aquí, porque se sale de tema técnico...

Los compañeros que están haciendo pruebas, han hecho lo siguiente:

Factura 10 (Aceptada)
Factura R-1, rectificando la 10, por diferencias (Aceptada)
Factura R-2, rectificando la 10, por diferencias (Aceptada)
Factura R-3, rectificando la 10, por diferencias (Aceptada

¿Esto está bien?

Hasta donde entiendo, si es una corrección de la corrección, debería haber sido R-3 rectificando R-2, R-2 rectificando R-1, etc...

O bien si se hace como lo han hecho, una vez R-3 deja la factura bien, anular R-1 y R-2

A ver si alguien puede iluminarme, porque en el FAQ si veo menciones a rectificar facturas rectificativas, etc. pero esto que han hecho, a nivel contabilidad, no sé cómo quedaría.

Cuando envías una factura rectificativa, hacienda no esta validando nada de la factura que esta rectificando, podrías poner incluso facturas que estas rectificando y no existen. Eso lo debería controlar la aplicación si es que puede.

Gipuzkoa no funciona?
 

Hola hoy no podemos enviar al entorno de pruebas de Gipuzkoa, tarda mucho y al final devuelve un error: "Se excedió el tiempo de espera de la operación"
Ayer funcionaba sin problema.



Alguien mas tiene este problema?


El entorno real de producción ya funciona bien?

Nuestro cliente empieza en real de forma obligatiroa el 01/11/2022 pero supongo que si lo ponemos en real hoy tampoco habrá problema. De momento hasta ayer enviaba en entorno de pruebas.




Muchas gracias

El de pruebas Gipuzkoa lleva un rato caído, sí.

El de producción aparentemente en principio va bien ahora.

EDITO:
Amplío la información de lo que veo:
Deben estar haciendo alguna prueba o cambio en la plataforma. Al intentar abrir la URL de Alta desde el navegador, en lugar de aparecer el clásico mensaje de "Método GET no soportado", está diciendo que "IZENPE solicita que te identifiques con un certificado", que hasta donde yo recuerde no había visto nunca.

Muchas gracias, hablaré con nuestro cliente para ver si ya quiere pasar al entorno real, así probamos si funciona antes del dia 1/11
:p

Eso mismo nos esta pasando en producción en gipuzkoa. Da ese mismo error, es como si el servidor de ellos no responde, luego lo haces otra vez y ya funciona. Va dando de forma aleatoria. Por supesto si llamas a hacienda te dicen que ellos no tienen ningun problema y que el error es de los programas.

Yo creo que es el servidor de ellos que hay momento en que no puede procesar las peticiones y te deja colgado, pero a ver quien les dice algo.:mad:

No lleva pasando desde hace tres días. HAsta ahora no había ningun problema.

Hola,

Acabo de hablar con TicketBAI de Gipuzkoa y me confirman que sí tienen caído el servicio del entorno de pruebas.
Están en ello y no saben para cuando conseguirán resolverlo.
Concretamente, en nuestro caso, no "tragan" facturas de alta desde ayer sobre las 22:30 de la noche.

Saludos

Muchas gracias a todos por las respuestas.


Supongo que al acercarse la fecha de obligatoriedad de TicketBAI para una gran parte de empresas (01/11/2022) cada vez hay mas peticiones a los servidores y podria ser que no se hayan dimensionado bien...:rolleyes:


Imagino que ya lo solucionaran.



Saludos

Dalo por seguro :D

Cosa que debrían haber pensado y previsto antes de montar un circo como este y pedir a todo el mundo que empiece a enviar datos.
Así vamos...

Me parece que aquí hemos sido los conejillos de indias para cuando se ponga a nivel nacional.

Pánico le tengo al 2 de noviembre, a ver qué nos encontramos...

Por "suerte" en nuestro caso las únicas facturas que emitimos son las nuestras propias así que nadie depende de nosotros. Así que en caso de servidores de Hacienda caídos, excepto algún cliente que nos pueda venir con que "el QR no me funciona, mimimimi", sólo quedará esperar ...

Hola,


Desde que enviaste el formulario de registro cuanto han tardado en remitirte la licencia de producción ?

Yo aún estoy a la espera y hoy es 31 ya ...