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

[rci]

Hola, alguien tiene claro que ocurre con el IVA del 5% en 2024 en Euskadi?

He intentado enviar una factura con el 5% a Gipuzkoa y su respuesta ha sido:

El valor del campo TipoImpositivo es incorrecto, el valor informado solo es permitido para fecha de operación posterior o igual a 1 de Julio de 2022 e inferior o igual a 31 de diciembre de 2023

En cambio he enviado otra factura con el 5% a Araba y ha sido aceptada sin problemas.

Según AEAT el 5% es válido hasta el 30/06/2024 pero no tengo claro que ocurre en Euskadi.

También podría ser que Gipuzkoa no haya actualizado sus validaciones...

Gracias por todo.
Saludos

[keys]

Empezado por rci

Hola, alguien tiene claro que ocurre con el IVA del 5% en 2024 en Euskadi?

He intentado enviar una factura con el 5% a Gipuzkoa y su respuesta ha sido:


En cambio he enviado otra factura con el 5% a Araba y ha sido aceptada sin problemas.

Según AEAT el 5% es válido hasta el 30/06/2024 pero no tengo claro que ocurre en Euskadi.

También podría ser que Gipuzkoa no haya actualizado sus validaciones...

Gracias por todo.
Saludos

Lo acabo de probar y me ocurre lo mismo. Yo mandaría la incidencia a hacienda por que parece que no lo han actualizado. El % es normativa estatal. La nueva versión deberían haberla puesto el día 1 y la pusieron el 3.

[MaeseKvothe]

Estos últimos días estoy detectando cosas raras en las peticiones a la url de pruebas en Vizcaya.



He estado haciendo pruebas de consultas y envíos y a veces una petición básica a su servidor, consulta por numero de factura por ejemplo, me está tardando minuto y medio, y otras veces 400-500 milisegundos.
De hecho he tenido que cambiar el tiempo para timeout porque con el valor por defecto (100 segundos) me ha fallado varias veces estos últimos días el envío del modelo 240 y al no recibir su respuesta no podía saber si lo habían llegado a registrar o no.

¿Alguien sabe a qué se debe o ha detectado algo similar?

[espinete]

Estoy obteniendo un "Error 500 - Internal Server Error" al hacer envíos a Gipuzkoa. ¿A alguien más le pasa?

A Araba puedo enviar sin problema.

[keys]

Empezado por espinete

Estoy obteniendo un "Error 500 - Internal Server Error" al hacer envíos a Gipuzkoa. ¿A alguien más le pasa?

A Araba puedo enviar sin problema.

Parece que Gipuzkoa esta OFF

[thinkows]

Empezado por MaeseKvothe

Estos últimos días estoy detectando cosas raras en las peticiones a la url de pruebas en Vizcaya.



He estado haciendo pruebas de consultas y envíos y a veces una petición básica a su servidor, consulta por numero de factura por ejemplo, me está tardando minuto y medio, y otras veces 400-500 milisegundos.
De hecho he tenido que cambiar el tiempo para timeout porque con el valor por defecto (100 segundos) me ha fallado varias veces estos últimos días el envío del modelo 240 y al no recibir su respuesta no podía saber si lo habían llegado a registrar o no.

¿Alguien sabe a qué se debe o ha detectado algo similar?

Buenos días, a nosotros nos ha ocurrido lo mismo con un cliente en prueba, el los de producción sin problema.

Todo por Timeouts excedidos
12 operaciones el jueves 04/01
1 operacion el viernes 05/01
1 operacion el sabado 08/01

Para verificar hemos hecho el reenvio para ver si lo han recibido y todos nos da duplicado.

Un saludo.

[edejuan]

Hola !

Ando ofuscado en un par de puntos, a ver si me podéis confirmar:


LROE 240

A Bizkaia no se puede 'reenviar' una factura, como se hace en las otras provincias (zuzendu), para por ejemplo modificar los datos fiscales, no ?

Tengo una factura enviada a Bizkaia y que fue aceptada sin errores (con software garante), si envío el esquema 'sin software garante' para esa factura con '<Operacion>M00</Operacion>', me dice que el registro no existe en el sistema,
y si el esquema lleva '<Operacion>A00</Operacion>', me indica que no se puede duplicar el registro.

Entonces las opciones son anulación o rectificación, con posterior envío con 'software garante' es así ?

He preguntado a ellos y me responden con lo típico, un enlace:

"En el caso de que se quiera realizar alguna modificación de una factura TicketBAI que ha sido aceptada y registrada correctamente en el sistema, se tendrá que actuar de acuerdo con lo indicado en la pregunta frecuente 19 ¿Se pueden modificar los datos de una factura ya expedida mediante el sistema TicketBAI?
https://www.batuz.eus/es/preguntas-frecuentes"

Siguiendo el enlace:

19 - ¿Se pueden modificar los datos de una factura ya expedida mediante el sistema TicketBAI?

TicketBAI

No puede modificarse la factura sin generar previamente un nuevo fichero TicketBAI.

En cualquier caso en el que sea necesario expedir una factura nueva para corregir un error de una factura anterior, debe generarse previamente un fichero TicketBAI.

Dependiendo de los casos, la nueva factura puede ser una factura rectificativa o tratarse de una factura nueva tras la anulación de la factura anterior, caso en el cual deberá generarse previamente un fichero TicketBAI de anulación.

Interpreto que el envío con el esquema 'sin software garante' y con '<Operacion>A00</Operacion>' es para facturas que son rechazadas (que devuelven 'Incorrecto'), no ?

Y entonces para que se utilizaría el envío del esquema 'sin software garante' con '<Operacion>M00</Operacion>' ? Cuando fue 'aceptada con errores' en primer envío con 'software garante' ?


LROE 140

Creo que sólo tengo un cliente en régimen de autónomo, pero:

Para la creación del LROE 140, como habéis enfocado el tema de la recuperación del epígrafe ?, sobre todo por si se tiene más de uno.

- Un campo en el registro de la serie de facturación ? y que facture escogiendo la serie según el epígrafe que necesite asociar a esa factura.
- En la pantalla de facturación, que pueda elegir a que epígrafe se asocia la factura ?
- Otras opciones ?




Gracias y saludos.

[keys]

Empezado por edejuan

Hola !

Ando ofuscado en un par de puntos, a ver si me podéis confirmar:


LROE 240

A Bizkaia no se puede 'reenviar' una factura, como se hace en las otras provincias (zuzendu), para por ejemplo modificar los datos fiscales, no ?

Tengo una factura enviada a Bizkaia y que fue aceptada sin errores (con software garante), si envío el esquema 'sin software garante' para esa factura con '<Operacion>M00</Operacion>', me dice que el registro no existe en el sistema,
y si el esquema lleva '<Operacion>A00</Operacion>', me indica que no se puede duplicar el registro.

Entonces las opciones son anulación o rectificación, con posterior envío con 'software garante' es así ?

He preguntado a ellos y me responden con lo típico, un enlace:



Siguiendo el enlace:




Interpreto que el envío con el esquema 'sin software garante' y con '<Operacion>A00</Operacion>' es para facturas que son rechazadas (que devuelven 'Incorrecto'), no ?

Y entonces para que se utilizaría el envío del esquema 'sin software garante' con '<Operacion>M00</Operacion>' ? Cuando fue 'aceptada con errores' en primer envío con 'software garante' ?


LROE 140

Creo que sólo tengo un cliente en régimen de autónomo, pero:

Para la creación del LROE 140, como habéis enfocado el tema de la recuperación del epígrafe ?, sobre todo por si se tiene más de uno.

- Un campo en el registro de la serie de facturación ? y que facture escogiendo la serie según el epígrafe que necesite asociar a esa factura.
- En la pantalla de facturación, que pueda elegir a que epígrafe se asocia la factura ?
- Otras opciones ?




Gracias y saludos.

Esa factura ya esta en el sistema, solo se puede rectificar o anular. El capitulo de sin software garante en principio es para enviar facturas que han dado error o que no hay que enviarlas por TicketBAI, no para enviar modificaciones de una factura. En principio en Bizkaia como en el resto de las haciendas una factura enviada no se puede modificar.

En cuanto a lo del 140 nosotros hemos optado por el segundo caso, es decir tienen que seleccionar el epígrafe con el que se hace la factura, pueden indicar uno por defecto. Ya que no hay porque cambiar de serie cuando son de actividades distintas.

[edejuan]

Empezado por keys

Esa factura ya esta en el sistema, solo se puede rectificar o anular. El capitulo de sin software garante en principio es para enviar facturas que han dado error o que no hay que enviarlas por TicketBAI, no para enviar modificaciones de una factura. En principio en Bizkaia como en el resto de las haciendas una factura enviada no se puede modificar.

En cuanto a lo del 140 nosotros hemos optado por el segundo caso, es decir tienen que seleccionar el epígrafe con el que se hace la factura, pueden indicar uno por defecto. Ya que no hay porque cambiar de serie cuando son de actividades distintas.

Muchas gracias keys, uuf

- En Araba y Gipuzkoa permito a los clientes modificar sólo los datos fiscales y las reenvío en modo zuzendu, vigilaré si debo quitarlo.

- Creo que haré igual que vosotros, algo más engorroso porque nuestro programa tiene más de 10 pantallas distintas desde las que facturar, pero ideal para comodidad de los usuarios.


Lo dicho, muchas gracias por tu tiempo.

[elcharlie]

Bueno días a todos:
Tengo un problemilla pendiente desde ya tiempo. el problema en cuestión es con el Id de la máquina, con el proceso que tengo en muchos terminales no me devuelve valor.
Soy consciente que es una tontería, ya que ahora mismo no es un dato obligatorio, y de hecho cuando me ocurre eso, pongo la clave de windows o cualquier dato inventado....
El caso es que me gustaría arreglarlo y despreocuparme de esa chorrada.
¿Alguien sabe como hacer para que siempre me devuelva la maquina/placa base un Id?

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

Empezado por elcharlie

Tengo un problemilla pendiente desde ya tiempo. el problema en cuestión es con el Id de la máquina, con el proceso que tengo en muchos terminales no me devuelve valor.
Soy consciente que es una tontería, ya que ahora mismo no es un dato obligatorio, y de hecho cuando me ocurre eso, pongo la clave de windows o cualquier dato inventado....
El caso es que me gustaría arreglarlo y despreocuparme de esa chorrada.
¿Alguien sabe como hacer para que siempre me devuelva la maquina/placa base un Id?

Nosotros hemos tenido el mismo problema y al final en algunos casos no hemos podido arreglarlo, porque muchos de estos IDs (placa base, BIOS,...) en según qué máquinas se devuelven vacíos. No en las máquinas físicas, pero cuando empiezas a incluir máquinas virtuales, máquinas azure, Terminal Server,... no siempre se obtiene el ID esperado.

Para estos casos hemos habilitado un "ID manual" (único, tipo GUID) que se genera una vez y se añade a un campo de la Base de Datos. Si el generado da vacío, cogemos ese y de ahí en adelante se usa ese.

[elcharlie]

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

Nosotros hemos tenido el mismo problema y al final en algunos casos no hemos podido arreglarlo, porque muchos de estos IDs (placa base, BIOS,...) en según qué máquinas se devuelven vacíos. No en las máquinas físicas, pero cuando empiezas a incluir máquinas virtuales, máquinas azure, Terminal Server,... no siempre se obtiene el ID esperado.

Para estos casos hemos habilitado un "ID manual" (único, tipo GUID) que se genera una vez y se añade a un campo de la Base de Datos. Si el generado da vacío, cogemos ese y de ahí en adelante se usa ese.

Pues me vale la idea, muchas gracias por contestar.

[Ramon88]

Sabéis algo de gipuzkoa?

Tengo un cliente con factruras pendientes de subir desde el 15/12/23....

[keys]

Empezado por Ramon88

Sabéis algo de gipuzkoa?

Tengo un cliente con factruras pendientes de subir desde el 15/12/23....

En principio esta funcionando sin problema.

[Noe277]

Buenas,

Hacienda foral de Álava tiene lo siguiente publicado
https://web.araba.eus/documents/1050...=1644833076809


Cambios en Certificado de dispositivo
En breve se va a publicar la nueva política de firma. Que incluye el cambio de certificado de dispositivo.
Cambios en el certificado de dispositivo:
• Se podrá solicitar identificando un punto de facturación en lugar del número de serie del dispositivo.
• Es posible la solicitud de certificados en bloque (hasta 100 certificados). Si desea solicitar certificados
de dispositivo en bloque puede recurrir al buzón de contacto TicketBAI de IZENPE.
• Se podrá solicitar antes de disponer del dispositivo concreto donde irá instalado.
• Se podrá usar en arquitecturas en servidor (excepto Tercero/Destinatario)

➢ El código que identifique un punto de facturación (a indicar en el campo “Número de serie (CN)”)
deberá ser único y no haber sido utilizado con anterioridad por ningún otro dispositivo.
➢ Indicar en Fabricante y modelo información significativa que permita al contribuyente reconocer el
“origen” del dispositivo que se le propone aceptar.


En izenpe no saben nada . Entiendo que van a cambiar la manera de solicitarlos y no tengo claro si habrá solicitar otra vez los que ya tenemos.

[Ramon88]

Perdonar mi ignorancia... Estoy teniendo algunos problemas y no sé por donde van los tiros.

Estoy revisando el tema de las rectificativas, vendo 3 productos y al final me devuelve uno.
Envío una rectificativa añadiendo algunos campos:

           <FacturaRectificativa>
              <Codigo>R5</Codigo>
              <Tipo>I</Tipo>
           </FacturaRectificativa>
           <FacturasRectificadasSustituidas>
              <IDFacturaRectificadaSustituida>
                  <SerieFactura>002024</SerieFactura>
                  <NumFactura>57463</NumFactura>
                  <FechaExpedicionFactura>23-01-2024</FechaExpedicionFactura>
              </IDFacturaRectificadaSustituida>
           </FacturasRectificadasSustituidas>

La URL utilizo la misma que para las facturas, es correcto?

[keys]

Empezado por Ramon88

Perdonar mi ignorancia... Estoy teniendo algunos problemas y no sé por donde van los tiros.

Estoy revisando el tema de las rectificativas, vendo 3 productos y al final me devuelve uno.
Envío una rectificativa añadiendo algunos campos:

           <FacturaRectificativa>
              <Codigo>R5</Codigo>
              <Tipo>I</Tipo>
           </FacturaRectificativa>
           <FacturasRectificadasSustituidas>
              <IDFacturaRectificadaSustituida>
                  <SerieFactura>002024</SerieFactura>
                  <NumFactura>57463</NumFactura>
                  <FechaExpedicionFactura>23-01-2024</FechaExpedicionFactura>
              </IDFacturaRectificadaSustituida>
           </FacturasRectificadasSustituidas>

La URL utilizo la misma que para las facturas, es correcto?

En principio si. Siempre que lo que quieras hacer es una rectificativa por diferencias de una factura simplificada. Que es lo que estas indicando.

[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:

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.

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

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