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