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

[YellowStone]

Empezado por espinete

Buenas!

Tengo un problema con los envíos a Araba. Al parecer han detectado que se han hecho envíos de facturas con una fecha de emisión distinta a la de la firma/envío.
Por lo general, nuestro software realiza la firma + envío en el momento de emitir la factura, pero eso no siempre es posible, por muchos motivos:

- Factura que no se pudo enviar porque, yo qué sé, se fue la luz en ese momento, o internet, o se bloqueó el PC...
- Cliente que lleva tiempo enviando las facturas al entorno de PRUEBAS sin darse cuenta y luego quiere reenviarlas al entorno de producción
- Factura creada a partir de varios albaranes y la fecha de la factura es indicada manualmente, que no tiene por qué ser la de hoy.

Hasta ahora, Araba (y cualquier otra diputación) aceptada estas facturas con fecha de emisión distinta a la del envío, siempre y cuando no hubiera problemas de encadenamiento.
Pero ahora han puesto un aviso/error cuando se detecta una fecha de emisión distinta a la del envío.

Y me parece bien. Si no se puede, no se puede. Ese aviso/error debería haber estado activado desde el día 1, pero bueno.

La duda es... ¿Cómo hacéis vosotros en estos casos? ¿Permitís a los clientes enviar manualmente facturas "antiguas"?

Lo digo porque, según ellos:



¿Soy yo el único que cree que esto es un poco locura?

Nuestro programa también lo permitía, y recibimos carta de la diputación para que dejara de permitirlo. Lo permitiamos en la facturación de albaranes, por si por error se había hecho la facturación mal, que se pudiera echar para atrás sin tener que crear 200 facturas rectificativas o 200 anulaciones. Sólo las enviábamos a la hora de imprimirlas. Claro, que el cliente, lo mismo no las imprimía y enviaba hasta días después, lo que antes era permitido, y ahora no. La solución que hemos puesto es que según se factura se envía, y si se equivoca, que ande con cuidado o tendrá que repetir la facturación entera. Y enviamos como fecha de expedición, la fecha del momento en que se crea, y fecha de operación, la fecha que el cliente le quiera poner a la factura.

[espinete]

Empezado por YellowStone

Nuestro programa también lo permitía, y recibimos carta de la diputación para que dejara de permitirlo. Lo permitiamos en la facturación de albaranes, por si por error se había hecho la facturación mal, que se pudiera echar para atrás sin tener que crear 200 facturas rectificativas o 200 anulaciones. Sólo las enviábamos a la hora de imprimirlas. Claro, que el cliente, lo mismo no las imprimía y enviaba hasta días después, lo que antes era permitido, y ahora no. La solución que hemos puesto es que según se factura se envía, y si se equivoca, que ande con cuidado o tendrá que repetir la facturación entera. Y enviamos como fecha de expedición, la fecha del momento en que se crea, y fecha de operación, la fecha que el cliente le quiera poner a la factura.

Creo que nuestro error es que tanto en "fecha de expedición" como en "fecha de operación" ponemos la misma fecha, ya que en el 99% de los casos, ambas coinciden.
Pero es verdad que al facturar albaranes, convertir presupuestos en factura, etc. damos la opción al usuario de elegir la fecha de la factura resultante, y quizás ese sea el problema.

En cualquier caso, nosotros por ahora sí permitíamos a los usuarios enviar las facturas más adelante. Hay muchísimos casos en los que debería ser permitido, o necesario, para evitar problemas mayores.
Pero vamos, que si Araba no lo permite, les remitiré a ellos cuando los clientes se quejen (que lo harán).

Mucho va a tener que cambiar España para que se adapte todo el mundo a Veri*Factu cuando entre en vigor, me temo.

[diegorgm]

Hola a todos,

Llevo dos días pegándome con esto para Bizkaia y no consigo librarme de un error. He buscado en todo el hilo y no he encontrado nada.

Estoy envíando un XML de ejemplo sacado de la web de Batuz para la emisión de una factura, que empieza con

<?xml version="1.0" encoding="UTF-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision">
	<Cabecera>
		<IDVersionTBAI>1.2</IDVersionTBAI>
	</Cabecera>
...

Me salta una error que dice El XML no cumple el esquema. La cabecera no tiene informada correctamente el nodo Modelo.. Sin embargo, si valido el XML contra el XSD ticketbaiv1-2-2.xsd parece que es válido. De hecho, según ese esquema, la cabecera no debe llevar un nodo Modelo.

Si añado el nodo Modelo a la cabecera, el error cambia y me sigue pidiendo otros nodos hasta que llego a un punto en que me dice que no reconoce el elemento TicketBai.

Todo parece indicar que, por algún motivo, se está haciendo la validación del XML contra otro esquema diferente.

Si alguien me puede echar una mano, se lo agradezco.

[keys]

Esto es lo que tengo yo en el fichero xml.

Código Delphi [-]


1.2

[keys]

Perdón. Me lo ha quitado

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ticketbai:emision ticketBaiV12.xsd ">
<Cabecera>
<IDVersionTBAI>1.2</IDVersionTBAI>
</Cabecera>

[diegorgm]

Muchas gracias por tu respuesta! Estaba enviando el primero y no el segundo...

[thinkows]

Empezado por diegorgm

Hola a todos,

Llevo dos días pegándome con esto para Bizkaia y no consigo librarme de un error. He buscado en todo el hilo y no he encontrado nada.

Estoy envíando un XML de ejemplo sacado de la web de Batuz para la emisión de una factura, que empieza con

<?xml version="1.0" encoding="UTF-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision">
	<Cabecera>
		<IDVersionTBAI>1.2</IDVersionTBAI>
	</Cabecera>
...

Me salta una error que dice El XML no cumple el esquema. La cabecera no tiene informada correctamente el nodo Modelo.. Sin embargo, si valido el XML contra el XSD ticketbaiv1-2-2.xsd parece que es válido. De hecho, según ese esquema, la cabecera no debe llevar un nodo Modelo.

Si añado el nodo Modelo a la cabecera, el error cambia y me sigue pidiendo otros nodos hasta que llego a un punto en que me dice que no reconoce el elemento TicketBai.

Todo parece indicar que, por algún motivo, se está haciendo la validación del XML contra otro esquema diferente.

Si alguien me puede echar una mano, se lo agradezco.

Buenos días, adjunto un ejemplo de pruebas, en el XML sin agrupar (sin empaquetar) :


<?xml version="1.0" encoding="utf-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision">
<Cabecera>
<IDVersionTBAI>1.2</IDVersionTBAI>
</Cabecera>
<Sujetos>
<Emisor>
<NIF>A99805228</NIF>
<ApellidosNombreRazonSocial>wAxkrkQQMPtTaBvEZzVH4QuwTRam9A</ApellidosNombreRazonSocial>
</Emisor>


En el XML agrupado (empaquetado)

<?xml version="1.0" encoding="utf-8"?>
<lrpficfcsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns:lrpficfcsgap="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_2.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2024</Ejercicio>
<ObligadoTributario>
<NIF>A99805228</NIF>
<ApellidosNombreRazonSocial>wAxkrkQQMPtTaBvEZzVH4QuwTRam9A</ApellidosNombreRazonSocial>
</ObligadoTributario>

[edari]

Empezado por YellowStone

Nuestro programa también lo permitía, y recibimos carta de la diputación para que dejara de permitirlo. Lo permitiamos en la facturación de albaranes, por si por error se había hecho la facturación mal, que se pudiera echar para atrás sin tener que crear 200 facturas rectificativas o 200 anulaciones. Sólo las enviábamos a la hora de imprimirlas. Claro, que el cliente, lo mismo no las imprimía y enviaba hasta días después, lo que antes era permitido, y ahora no. La solución que hemos puesto es que según se factura se envía, y si se equivoca, que ande con cuidado o tendrá que repetir la facturación entera. Y enviamos como fecha de expedición, la fecha del momento en que se crea, y fecha de operación, la fecha que el cliente le quiera poner a la factura.

A mí también me está saltando este error y hasta ahora teníamos siempre una sola fecha. A raíz de tener que añadir la fecha operación al xml me salta alguna duda:


Esa fecha de operación hay que guardarla también por separado en contabilidad? Tengo que tener en cuenta en los libros de iva esa fecha de alguna forma?


Hay que imprimirla en la factura?


Gracias

[ermendalenda]

Sabéis si también detecta si he hecho la factura a las 23.59 y las envío 2 minutos después? O lo tienen controlado por nunero de horas?

[Sistel]

Empezado por ermendalenda

Sabéis si también detecta si he hecho la factura a las 23.59 y las envío 2 minutos después? O lo tienen controlado por nunero de horas?

Sería el colmo que te dijeran algo por enviarlas con 2 minutos de retraso.
(Aunque con la Administración cualquier tontería es posible)

Yo las envío mediante un cronjob que se lanza cada minuto.
Y nunca se me han quejado.

[ermendalenda]

Esto es un lío y van a tener que abrir un poco la mano. Al menos 2 o 4 días,
Pilla puentes,fines de semana...con averias de fibra y todos locos

[Sistel]

Empezado por ermendalenda

Esto es un lío y van a tener que abrir un poco la mano. Al menos 2 o 4 días,
Pilla puentes,fines de semana...con averias de fibra y todos locos

Sí, que se emitan y envíen las facturas desde un equipo local del cliente con conexión a Internet es chungo.
En esos casos, tal vez sería buena idea equipar a los clientes con un router-backup 3G/4G con una SIM con datos baratos.
Si se le cae la fibra, el tráfico seguirá saliendo por 3G/4G.

[keys]

Hola a todos.

Pregunte ha hacienda de ALAVA por el error 016 (Fecha de recepción muy posterior a la fecha de expedición), en nuestro caso es por que el cliente ha estado sin internet mucho tiempo pero a seguido generando facturas. Me han contestado lo siguiente :

El aviso 016, Fecha de recepción muy posterior a la fecha de expedición, es una advertencia, para dar a conocer que no ha existido simultaneidad.

Si, como indica, la diferencia entre las fechas debido a problemas de conexión puntuales que puedan acreditarse, en cuyo caso no debe realizar ninguna actuación, dado que ya está previsto en el art. 17 del Decreto Foral 48/2021, que aprueba el reglamento de la obligación TicketBAI, que establece los pasos a seguir en cado de incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI, indicando que:

Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI

1. En los supuestos excepcionales de interrupción del servicio eléctrico, de destrucción, fallo, avería, rotura u otras circunstancias en las que la o el contribuyente no pueda generar ficheros TicketBAI ni expedir factura o justificante empleando el software TicketBAI, y éstas deban ser expedidas en el momento de realizarse la operación, dicha circunstancia se notificará a la Administración Tributaria y la o el contribuyente expedirá y entregará factura o justificante por otros medios a la persona o entidad destinataria, conservando copia del mismo.
La factura o justificante se consignará a una serie específica que se destinará únicamente a las facturas o justificantes expedidos en virtud de lo dispuesto en este artículo, y contendrá la expresión “factura o justificante expedido según lo dispuesto en el artículo 17 del Decreto Foral por el que se desarrolla la obligación TicketBAI”

2. La o el contribuyente, tan pronto como desaparezca el motivo que imposibilite la generación de ficheros TicketBAI y la expedición de factura o justificante empleando el software TicketBAI, deberá introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas y justificantes expedidos, generando los ficheros TicketBAI y enviándolos a la Administración Tributaria.
La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado.
En cualquier caso, la persona o entidad destinataria de la operación podrá solicitar un duplicado
de la factura o justificante emitido, que contemple el código TicketBAI y el código QR.

3. En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio telefónico o telemático, avería del sistema de envío u otras circunstancias en las que la o el contribuyente pueda generar ficheros TicketBAI pero no pueda enviarlos a la Administración Tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI generados y procederá a su envío tan pronto se restablezca la conexión.”

Es decir que en este caso, de falta temporal de cobertura, no tendría que hacer nada.

Es decir muy parecido a lo que le contestaron al compañero. En nuestro caso no hay que hacer nada.

[HerensugeBeltz]

Empezado por edari

A mí también me está saltando este error y hasta ahora teníamos siempre una sola fecha. A raíz de tener que añadir la fecha operación al xml me salta alguna duda:

Esa fecha de operación hay que guardarla también por separado en contabilidad? Tengo que tener en cuenta en los libros de iva esa fecha de alguna forma?

Hay que imprimirla en la factura?


Gracias

Creo que no le estáis dando a la fecha de operación la importancia que tiene: esta fecha es la que determina el periodo fiscal, es decir, cuándo aplicar el IVA. Te pongo un ejemplo: el 29 de diciembre realizo un trabajo para una empresa (fecha de operación) y el cinco de enero emito la factura (fecha de expedición), dado que tengo de plazo hasta el día 15 del mes siguiente para emitirla. Supongamos que ese ejercicio cambia el tipo de IVA del 21% al 23%. Yo debo aplicar el 21%, el IVA de la fecha de operación, y no el de la fecha de expedición. Evidentemente, esa factura se liquidará en el ejercicio de la fecha de operación.

En resumen, de cara al IVA, la fecha de operación es la determinante en una factura.

[edari]

Empezado por HerensugeBeltz

Creo que no le estáis dando a la fecha de operación la importancia que tiene: esta fecha es la que determina el periodo fiscal, es decir, cuándo aplicar el IVA. Te pongo un ejemplo: el 29 de diciembre realizo un trabajo para una empresa (fecha de operación) y el cinco de enero emito la factura (fecha de expedición), dado que tengo de plazo hasta el día 15 del mes siguiente para emitirla. Supongamos que ese ejercicio cambia el tipo de IVA del 21% al 23%. Yo debo aplicar el 21%, el IVA de la fecha de operación, y no el de la fecha de expedición. Evidentemente, esa factura se liquidará en el ejercicio de la fecha de operación.

En resumen, de cara al IVA, la fecha de operación es la determinante en una factura.

Gracias. Lo voy a mirar.

[espinete]

Empezado por HerensugeBeltz

Creo que no le estáis dando a la fecha de operación la importancia que tiene: esta fecha es la que determina el periodo fiscal, es decir, cuándo aplicar el IVA. Te pongo un ejemplo: el 29 de diciembre realizo un trabajo para una empresa (fecha de operación) y el cinco de enero emito la factura (fecha de expedición), dado que tengo de plazo hasta el día 15 del mes siguiente para emitirla. Supongamos que ese ejercicio cambia el tipo de IVA del 21% al 23%. Yo debo aplicar el 21%, el IVA de la fecha de operación, y no el de la fecha de expedición. Evidentemente, esa factura se liquidará en el ejercicio de la fecha de operación.

En resumen, de cara al IVA, la fecha de operación es la determinante en una factura.

Todo depende de si la empresa utiliza esa fecha o no. La mayoría del software de facturación y punto de venta no distinguen entre Operación y Expedición porque no hace falta en la mayoría de los casos.
De hecho, en muy pocas aplicaciones, de escritorio y en la nube, he visto que haya campo Fecha de Operación y Fecha de Expedición diferenciados.

Solo en determinados casos es necesario diferenciar ambas fechas. Ya te digo yo que en 20 años a nosotros no nos ha hecho falta nunca.

Lo que está claro es que para evitar algunos casos concretos, hay que tenerla en cuenta a partir de ahora. Aunque solo sea para el envío de TicketBAI a Araba.

[keys]

Empezado por espinete

Todo depende de si la empresa utiliza esa fecha o no. La mayoría del software de facturación y punto de venta no distinguen entre Operación y Expedición porque no hace falta en la mayoría de los casos.
De hecho, en muy pocas aplicaciones, de escritorio y en la nube, he visto que haya campo Fecha de Operación y Fecha de Expedición diferenciados.

Solo en determinados casos es necesario diferenciar ambas fechas. Ya te digo yo que en 20 años a nosotros no nos ha hecho falta nunca.

Lo que está claro es que para evitar algunos casos concretos, hay que tenerla en cuenta a partir de ahora. Aunque solo sea para el envío de TicketBAI a Araba.

Hasta ahora casi nadie tenía en cuenta la fecha de operación, cada uno hacía lo que quería ya que hacías la factura con la fecha que querías ya fuera anterior o posterior al día actual, pero desde que existe TicketBAI eso no se puede hacer y la fecha de operación a pasado a tener mucha importancia. Todo esto ya existía antes de TicketBAI en la normativa de facturación.

A la hora de imprimir la factura si esta no es igual a la de factura es importante ponerla, ya que si la empresa destino hace el 140/240 de bizkaia o el SII tiene que informar de ese dato.