Hola,

Lo que antes se llamaban "tickets", actualmente se llaman "facturas simplificadas".
Tienen el mismo valor que las facturas completas, y deben llevar número de factura y fecha.
Y si se emiten otras facturas completas, deben llevar serie separada.

Pueden no incluir datos del destinatario.
Si se incluyen los datos del destinatario (nombre, NIF, domicilio, localidad, código postal, etc) se denominan "facturas simplificadas cualificadas" y, en este caso, el destinatario puede anotarlas como facturas recibidas normales en su contabilidad y tenerlas en cuenta en sus declaraciones de IVA.

Como norma general no pueden ser de un importe mayor de 400€, aunque si es por ventas al por menor, transporte, hostelería o algunas otras, el límite es de 3.000€

Saludos

¿ Y cual es la diferencia entre una factura completa y una simplificada cualificada ?

El importe máximo y la diferente serie.

Saludos

Gracias Sistel.


A lo que me referia es que hay facturas simplificadas que pueden ser perfectamente facturas completas y ademas de importe elevado, por debajo de 3.000 eur, porque son facturas simplificadas con detalle del cliente. En esos casos son indestinguibles de las completas salvo por la serie

A nivel contable no lo sé, pero hasta donde recuerdo, en "idioma TicketBAI", factura simplificada es toda aquella que NO lleva datos de cliente, y con un importe menor a 3000€.

Si en el XML envías datos de cliente, la consideran factura completa, aunque sea de 25€. De hecho en cuanto envías cliente, al escanear el QR para ver la situación online, requiere entrar como contribuyente, etc...

Gracias, Sistel.

Hola,

Efectivamente, para facturas de menos de 3.000€ no hay diferencia alguna entre factura simplificada cualificada (con datos de destinatario) y factura completa, salvo que deben ser de series diferentes.

De hecho, nosotros recomendamos a nuestros clientes que utilizan una sola serie y que no emiten facturas mayores de 3.000€ utilizar sólo facturas simplificadas: en el caso de que metan los datos del destinatario serán "facturas simplificadas cualificadas" y en el caso de que no, serán "facturas simplificadas" a secas.
Así se evitan tener que llevar 2 series diferentes de facturas.

Saludos

Hola,

Que sea factura simplificada o completa viene definido en la estructura del fichero XML en el nodo <FacturaSimplificada>
Y si no aparece ese nodo, se considera factura completa.

Eso es independiente de que tenga datos o no del destinatario.

Otra cosa diferente es que Hacienda Foral no permita ver los datos del destinatario de una factura, a partir del QR, si no te identificas como emisor o destinatario.

Saludos

Buenos días,
estoy dando los primeros pasos en el entorno de pruebas con TicketBAI Bizkaia (ya tengo desarrollado TicketBAI Gipuzkoa y TicketBAI Araba)

Estoy generando y enviando este modelo 240:
y estoy recibiendo el siguiente error:
He revisado mi código y no veo claro dónde esta mi error.
¿Alguno de los que tenéis desarrollado TicketBAI Bizkaia me puede dar algo de luz?
Entiendo que este error de cabecera es relativo al modelo 240 ¿no? (la factura TicketBAI se crea de la misma forma que en las otras 2 haciendas que están funcionando)


Gracias de antemano!

Te copio una cabecera de una factura que acabo de generar y que es prácticamente igual. compáralas y veo que alguna diferencia en la primera línea y poco más...
Veo que en tu cabecera hay esto:
Y nosotros enviamos esto:
El resto (la estructura de los datos) son iguales.

Buenas a todos.
Una duda, sólo para confirmar.

Hasta ahora en el fichero ticketBAI para Vizcaya enviábamos la descripción de la línea vacía:


Nunca nos había dado problemas hasta ahora que nos aparece el siguiente error:


Si rellenamos ese valor deja de salir, por lo tanto asumimos que es ese.
¿Alguien más ha detectado este cambio de comportamiento en la descripción de las líneas?

Gracias por la respuesta.
Al final he descubierto que el error era porque enviaba el archivo TicketBAI directamente y no el modelo 240 que es el que pensaba que estaba enviando (cosas del copy-paste)

Hola Neftali,

¿Seguro que está bien esa estructura XML?
Veo el cierre </DescripcionDetalle> sin haber abierto antes ese nodo <DescripcionDetalle>

Creo que si quieres abrirlo y cerrarlo a la vez, deberia ser <DescripcionDetalle />

Saludos

La etiqueta de cierre sola en XML equivale a ambas con contenido vacío.

Hola Neftali.

Gracias.
Desconocía que podía hacerse así.
Conocía sólo la sintaxis de nodo sin contenido poniendo la barra al final: <DescripcionDetalle />

Saludos

Me ha llegado esta información de Bizkaia, por si tenéis que apuntarla.
Igualmente actualizao el mensaje #1 del hilo, donde están el resto de buzones de dudas.

Estaba editando el código cuando me he dado cuenta de que esto plantea un problema.
De momento estoy adaptando el código para la Administración Foral de Vizcaya (Bizkaia).


En el documento "especificaciones funcionales y técnicas del sistema TicketBAI 1.1" (que entiendo que son de carácter general) se habla de que el documento de factura debe incluir un identificativo TBAI, el cual contiene elNIF del contribuyente.


Concretamente, su estructura es: TBAI-NNNNNNNNN-DDMMAA-FFFFFFFFFFFFF-CRC
Donde NNNNNNNNN es el NIF.


Por ejemplo: TBAI-00000006Y-251019-btFpwP8dcLGAF-237

La longitud total debe ser de 39 caracteres, incluyendo los guiones.


Si no me equivoco, el contribuyente es el destinatario de la factura (el cliente).



Si no hay un contribuyente identificable, ¿cómo vamos a generar el identificativo TBAI?
A no ser que yo esté equivocado en algo.

El contribuyente es el emisor de la factura, no el receptor.

Vaya error de bulto!!

Yo entendía que quien paga el impuesto es el cliente.
Y que, por tanto, éste es el contribuyente.

Buenas,

Gracias por la aclaración.

Acabo de mirar la documentación y en efecto veo que una factura marcada como "Simplificada" puede llevar datos de destinatario.

De todas formas, ¿esto es relativamente nuevo? No tengo recuerdo de haber leído nada sobre facturas "cualificadas" cuando estuve desarrollando esto en su momento...

Lo cierto que ahora mismo no me preocupa porque el desarrollo lo hice personalizado para la empresa para la que trabajo y con nuestras necesidades. El planteamiento que tengo es que en el momento que se rellenan datos de cliente, pasa a ser factura completa y listo, y el resto son "tickets".

Saludos.

Hola,

Creo que lo de "facturas simplificadas cualificadas" fue una denominación que empezó a utilizar la Agencia Tributaria a raiz del SII (no recuerdo haberlo leído antes). No es nada específico de TicketBAI.
Puedes verlo en los puntos 2.49 y 3.23 de las Preguntas Frecuentes sobre el SII

Ten en cuenta que si todas las facturas que emites son de un importe inferior a 3.000€ puedes emitirlas todas como facturas simplificadas (lo que tú aún llamas con su antigua denominación de "tickets") independientemente de que tengan o no datos del destinatario. Y así te ahorras tener 2 tipos y series diferentes de facturas.

Saludos

¿A alguien le está dando problemas Bizkaia hoy?
De pronto lo que estaba funcionando ahora me da el error "The remote certificate is invalid because of errors in the certificate chain: PartialChain"

Error envío
 

En el entorno de pruebas de Bizcaya me sale esto, el día 13/06/23 se envío correctamente sin ningún cambio.

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

A entorno de pruebas, que es lo único que puedo probar me sube correctamente.


Si subes tú a pruebas ahora y te sube también mal revisa a ver si ves algo del certificado de marras

Nombre común (CN) pruesarrerak.bizkaia.eus
Organización (O) BIZKAIKO FORU ALDUNDIA / DIPUTACION FORAL DE BIZKAIA
Unidad organizativa (OU) <No incluido en el certificado>
Nombre común (CN) EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
Organización (O) IZENPE S.A.
Unidad organizativa (OU) AZZ Ziurtagiri publikoa - Certificado publico SCA

Emitido el miércoles, 14 de junio de 2023, 13:32:54
Vencimiento el sábado, 13 de julio de 2024, 13:32:54

Desde el navegador veo esto, desde el 14/06/2023 hicieron un cambio de certificado. Que coincide con el envío correcto del 13 y hoy da el error.

Yo estoy con el entorno de pruebas y no hay manera. Me da error todo, consultas, envíos, etc.
No sé ni por donde tirar, porque con ese mensaje entiendo que el error en certificado es de ellos, no mío.

Hola,

El pasado sábado 24 de junio, todos los XML de TicketBAI enviados a Hacienda Foral de Álava entre las 12:31 y las 16:21h me dieron errores.
Me afectó a 105 facturas con código de respuesta 008 (AVISO: Error en verificación de firma) y a 94 facturas con código 998 (Certificado válido únicamente en caché caducada)

Hoy he hablado con TicketBAI de Álava.
Parece que el culpable, una vez más, ha sido el sistema de verificación de certificados y firmas que usan de IZENPE.
(Peor servicio que el de IZENPE es difícil de encontrar)

De las 94 facturas con código 998 me han dicho que sin problemas, las dan como buenas.
Las 105 facturas con código 008 he tenido que enviarlas, de nuevo, a través del servicio ZUZENDU.

¡¡ Gracias IZENPE por evitar que nos aburramos !!

Saludos.

Facturas incorrectas
 

Buenos días,
voy a meterme a desarrollar el tema del envío a la hacienda de Bizkaia para los casos en los que "no todo haya ido bien".
Estoy leyendo la documentación de la web de Batuz y en Preguntas frecuentes pone:
¿Cuáles son esos supuestos en los que hay que mandar una rectificativa o una de anulación?

Anulación es para cuando se ha emitido la factura por error. Es decir, nunca ha llegado a ser una factura válida. La mayoría de sistemas ni contemplan esta posibilidad.
La rectificativa es para modificar o cancelar una factura. Por ejemplo porque no le habías aplicado un descuento y recibes la queja/aviso o porque te quiere cancelar parte o toda la factura (te devuelve elementos o desestima servicios).
Ninguno de esos temas viene impuesto por la validación del TBAI ni el LROE, son procedimientos financieros estándar.

Gracias por la aclaración :)

Encadenamiento en factura corregida Batuz
 

Hola,
me surge otra cuestión.
Me comentan desde Batuz lo siguiente respecto a la corrección de errores:
En este caso, ¿esta factura corregida tendría encadenamiento?

Las facturas enviadas SinSG (capítulo 1.2) son co un formato diferente y no llevan encadenamiento.
Te adjunto un fichero enviado de esta forma:

Genial! Gracias por la ayuda :)

Epígrafe LROE 140
 

Buenos días,


Para la creación del LROE 140 (Bizkaia), como habéis enfocado el tema de la recuperación del epígrafe ?, sobre todo por si 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 ?


Gracias.

Yo lo veo de otra forma:
Si haces una factura y resulta que recien hecha, Y SIN ENVIAR AUN, te das cuenta que está mal porque metiste un articulo de más, lo que haces es anularla así al cliente sólo le llegará una factura y no dos (factura más rectificativa), porque realmente queda muy mal que al cliente le lleguen dos facturas porque las tendrá que mecanizar y subir al SII, cuando él simplemente pidió una mercancía que debería dar lugar a un unico documento

https://www.gipuzkoa.eus/es/web/ogas...ema-ticketbai-


Ya mi duda, y que expuse en hilos anteriores es saber cómo tratar las anuladas en el programa. Entiendo que habria que afectar a todos los query porque se deberian excluir y ademas posibilitar con parametros consultus donde SI poder incluirlas. Hay quien propuso otras formas

Regimen de equivalencia
 

Hola,
un cliente me ha comentado que está en regimen por recargo de equivalencia en lugar de regimen general que es el que tengo desarrollado.
He visto la documentación y veo que tengo que cambiar algunos tags y añadir otros para este caso.
No me queda claro como hay que calcular el tag CuotaRecargoDeEquivalencia.
En este ejemplo de factura, ¿como habría que hacer?

Entiendo que TipoRecargoEquivalencia será 1.4 por lo que he visto en la web de la agencia tributaria española (pero tampoco estoy seguro que sean los mismos % para las forales)
Gracias!

Hola,

Sí, los tipos de IVA y de recargo de equivalencia son los mismos en todas las administraciones tributarias de España, incluídas las forales.
Te falta un tipo de IVA con su recargo de equivalencia:
Aceites de oliva y de semillas y pastas alimenticias: 5% de IVA con recargo de equivalencia del 0,62%

Saludos

En mi caso, si genero esa factura (con diferencia de decimales) me da lo siguiente; Puedes compararlo con el tuyo, pero tiene buena pinta. Te falta rellenar la cuota de recargo.

Buenos días tod@s,
tengo que un problemón, que con suerte, quizás alguien sepa solucionarlo o por donde van los tiros.
Desde siempre, desde que empezamos con el SII, en el xml de envío, en vez de enviar todos los registros en un solo xml, generábamos un xml por cada uno, para que nos fuera mas fácil tratarlos. No es una manera mala de hacer, es diferente...
Cuando empezamos con el TicketBAI y el Batuz, lo afrontamos de la misma manera, un registro, un xml, y un envio. Hasta aquí la introducción, todo funciona correctamente y sin problemas enviamos y recibimos.
El problema nos viene con la Diputación de Gipuzkoa. Desde hace un tiempo, vemos que si enviamos a la vez muchos registros (con 20 seguidos ya vale), nos cortan la conexión. Hay que esperar unos minutos y volver a enviar, es como si tuvieran un limite de conexiones por tiempo. Nos hemos puesto en contacto con los informáticos de la diputa, y nos han dicho que ellos no bloquean nada, pero a nosotros nos pasa. Solución, enviamos de 10 en 10 esperando unos minutos entre envíos, y así funciona, pero es una chapuza, y me gustaría solucionarlo y poder enviar todo a la vez.
¿A alguien mas le está pasando esto?, ya os digo que en las demás diputaciones 0 problemas, es solo con la de Gipuzkoa, y no podemos modificarlos todo de nuevo para enviarlo en solo xml, seria empezar de nuevo.
¿Alguien sabe algo?
Perdón por el tostón... y gracias de antemano.

Hola a todos. Decirte que a nosotros nos pasa lo mismo, estamos enviando muchas facturas seguidas y de repente nos devuelve un error de conexión (Unas veces cada 20 facturas, otras cada 10, otras nunca, aleatorio). Nos lleva pasando desde que entraron los comercios a TicketBAI de Gipuzkoa, es decir, cuando entro el grueso de contribuyentes. En su momento hablamos con hacienda y nos dijeron lo mismo que a ti. Bueno también nos dijeron que enviáramos las facturas por la noche, los cachondos de ellos. En el entorno de pruebas hemos hecho miles de pruebas y no pasa.

Como tu dices 0 problemas en las otras dos diputaciones y en Gipuzkoa tampoco hasta que paso lo que he dicho.

La solución no es enviar todas a la vez, ya que en Gipuzkoa solo se puede de una en una. Solo es Bizkaia la que lo permite. Nosotros la solución que hicimos cuando detectamos ese error fue, le damos 30 segundos al programa de descanso, y la volvemos intentar enviar, así un número de intentos que hasta ahora le hemos puesto 6 intentos, y parece que hemos solucionado el problema, aunque hay veces que ni con esas.

Estoy convencido que es un problema de hacienda, y ahora al ver que a alguien más le pasa :o