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

[espinete]

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

He visto que la estructura es casi exactamente igual que la del envío de una Factura, y por lo que he leído, es para "subsanar" envíos que hayan sido rechazados previamente; y que el envío se hace a una URL distinta a la de Alta de Facturas, etc.
En el diagrama que hay en la web de Gipuzkoa indica que cuando el envío de una factura devuelva "avisos de errores" y el error tiene "reflejo en la factura" (vete tu a saber qué quieren decir con eso), hay que subsanarla con un "zuzendu modificar". Pero...
¿A qué errores se refieren exactamente? ¿Por qué no me ha hecho falta hasta ahora hacer un envío de zuzendu, con cientos de clientes enviando facturas desde hace más de un año? ¿Para qué casos concretos habría que hacer esto?

Extraído de la documentación:

Cuando el fichero de alta TicketBAI o el fichero de subsanación del fichero de
alta TicketBAI sea recibido con aviso de errores que no exijan la emisión de una
factura rectificativa, pero sean consecuencia de no superar las validaciones de
consolidación del resto de datos que deban informarse en el fichero, se deberá
generar un fichero de modificación que será enviado a través del servicio
zuzendu.
Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

Y espérate, que después de leer que hay diferencias entre "modificar" y "subsanar" y, por si fuera poco confuso:
- Ficheros de subsanación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de subsanación de los ficheros de alta TicketBAI

No sé si es que estoy realmente cansado de todo este tema, pero la verdad es que ahora mismo no se me ocurre un caso concreto en el que sea necesario enviar una modificación/zuzendu, y mucho menos, una "baja de zuzendu".
Lo que está claro es que dejar que el propio usuario final pueda enviar zuzendus cuando le de la gana, no es buena idea.

[DemonAscun]

Empezado por espinete

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

He visto que la estructura es casi exactamente igual que la del envío de una Factura, y por lo que he leído, es para "subsanar" envíos que hayan sido rechazados previamente; y que el envío se hace a una URL distinta a la de Alta de Facturas, etc.
En el diagrama que hay en la web de Gipuzkoa indica que cuando el envío de una factura devuelva "avisos de errores" y el error tiene "reflejo en la factura" (vete tu a saber qué quieren decir con eso), hay que subsanarla con un "zuzendu modificar". Pero...
¿A qué errores se refieren exactamente? ¿Por qué no me ha hecho falta hasta ahora hacer un envío de zuzendu, con cientos de clientes enviando facturas desde hace más de un año? ¿Para qué casos concretos habría que hacer esto?

Extraído de la documentación:

Cuando el fichero de alta TicketBAI o el fichero de subsanación del fichero de
alta TicketBAI sea recibido con aviso de errores que no exijan la emisión de una
factura rectificativa, pero sean consecuencia de no superar las validaciones de
consolidación del resto de datos que deban informarse en el fichero, se deberá
generar un fichero de modificación que será enviado a través del servicio
zuzendu.
Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

Y espérate, que después de leer que hay diferencias entre "modificar" y "subsanar" y, por si fuera poco confuso:
- Ficheros de subsanación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de subsanación de los ficheros de alta TicketBAI

No sé si es que estoy realmente cansado de todo este tema, pero la verdad es que ahora mismo no se me ocurre un caso concreto en el que sea necesario enviar una modificación/zuzendu, y mucho menos, una "baja de zuzendu".
Lo que está claro es que dejar que el propio usuario final pueda enviar zuzendus cuando le de la gana, no es buena idea.

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

[skatologiko]

Buenos días, ¿alguien está teniendo hoy problemas en Guipúzcoa? Parece que nos está tardando en transmitir los tickets (unos sí y otros no)

[Sistel]

Empezado por skatologiko

Buenos días, ¿alguien está teniendo hoy problemas en Guipúzcoa? Parece que nos está tardando en transmitir los tickets (unos sí y otros no)

Hola,

Sí. Parece que está caído.

Saludos

[iMia]

Si, está dando timeouts

[sEngine]

Si, justo me ha comentado un cliente que le estaba dando error en el envio

[Sistel]

Hola,

Realmente es una lástima como funcionan los sistemas informáticos de las Haciendas Forales que atienden a los servicios TicketBAI.
Cuando no es por una cosa es por otra.

- Ahora que si no funcionan los envíos a Gipuzkoa.
- Ayer que si tenían caducado (y sin darse cuenta) su certificado.
- Otros días que si el sistema que emplean de verificación de certificados (el desastroso Izenpe) no verifica bien.
...

No entiendo que a nosotros se nos exijan sistemas estables, fiables y seguros y las Administraciones se tomen a chufla el estado de sus servicios.
¡¡¡ Un poco de seriedad, por favor !!!

(Es sólo por desahogarme)

Saludos

[espinete]

Empezado por Sistel

Hola,

Realmente es una lástima como funcionan los sistemas informáticos de las Haciendas Forales que atienden a los servicios TicketBAI.
Cuando no es por una cosa es por otra.

- Ahora que si no funcionan los envíos a Gipuzkoa.
- Ayer que si tenían caducado (y sin darse cuenta) su certificado.
- Otros días que si el sistema que emplean de verificación de certificados (el desastroso Izenpe) no verifica bien.
...

No entiendo que a nosotros se nos exijan sistemas estables, fiables y seguros y las Administraciones se tomen a chufla el estado de sus servicios.
¡¡¡ Un poco de seriedad, por favor !!!

(Es sólo por desahogarme)

Saludos

Ya verás qué divertido va a ser cuando implanten VeriFactu a nivel nacional

[espinete]

Empezado por DemonAscun

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

Si, ese es el protocolo, pero lo que no entiendo es en qué casos concretamente se debe hacer una "subsanación".
Si no entra un Alta normal, no basta con volver a intentarlo? Hacienda aún no tiene la factura, no? Otra cosa es que se haya enviado PERO con avisos/errores y Hacienda se la haya tragado (que debería ser problema de ellos por habérsela comido, pero bueno).

Es decir, si se envía una factura, pero con error/aviso, ahí entiendo que sí haya que hacer una "subsanación", después de haber corregido la causa del error. Imagino que dependerá de qué tipo de error sea exactamente.

Luego está lo de "modificar una factura". Lo siento, pero sigo sin entender la diferencia. En ambos casos (subsanar y modificar) lo que tenemos que hacer es modificar algo en la factura. ¿En qué casos concretos se requiere subsanación y en qué casos modificación?

Subsanación si Hacienda se traga una factura incorrecta y modificación si nosotros voluntariamente queremos reenviarla? ¿Para esto último no sería más correcto una rectificativa? Al menos eso es lo que nos ha reiterado Hacienda últimamente: "Modificar mal. Rectificativa bien"...

Y siguiendo con las exigencias de tener que hacer rectificativas... ¿por qué entonces se permiten las "bajas"?

[Sistel]

Empezado por espinete

Si, ese es el protocolo, pero lo que no entiendo es en qué casos concretamente se debe hacer una "subsanación".
Si no entra un Alta normal, no basta con volver a intentarlo? Hacienda aún no tiene la factura, no? Otra cosa es que se haya enviado PERO con avisos/errores y Hacienda se la haya tragado (que debería ser problema de ellos por habérsela comido, pero bueno).

Es decir, si se envía una factura, pero con error/aviso, ahí entiendo que sí haya que hacer una "subsanación", después de haber corregido la causa del error. Imagino que dependerá de qué tipo de error sea exactamente.

Luego está lo de "modificar una factura". Lo siento, pero sigo sin entender la diferencia. En ambos casos (subsanar y modificar) lo que tenemos que hacer es modificar algo en la factura. ¿En qué casos concretos se requiere subsanación y en qué casos modificación?

Subsanación si Hacienda se traga una factura incorrecta y modificación si nosotros voluntariamente queremos reenviarla? ¿Para esto último no sería más correcto una rectificativa? Al menos eso es lo que nos ha reiterado Hacienda últimamente: "Modificar mal. Rectificativa bien"...

Y siguiendo con las exigencias de tener que hacer rectificativas... ¿por qué entonces se permiten las "bajas"?

Hola,

Para aclarar cuando hacer una rectificativa, un Zuzendu de modificación o un Zuzendu de subsanación, viene muy bien este gráfico que anexo.

Saludos

[Sistel]

Empezado por espinete

¿por qué entonces se permiten las "bajas"?

Hola,

Hay veces que no tiene mucho sentido hacer rectificativas sino anular la factura y hacerla de nuevo.
Ejemplos:

- Vendes un pantalón y en el momento de entregar la factura al cliente, te das cuenta de que has puesto jersey.
Anulas la factura, la rompes antes de entregarla al cliente y vuelves a hacerla bien.

- Haces una factura de 100€ y a continuación te das cuenta de que se te había quedado trabada la tecla del cero y te aparece 1.000.000€ como importe.
Anulas la factura, desencajas la tecla bloqueada y vuelves a hacer la factura.

- Después de hacer una factura te das cuenta de que has puesto como destinatario a un ex-cliente de hace muchos años (con el que quedaste a mal).
Ni se te ocurriría enviarle la factura emitida y una rectificativa.
Anulas la factura y eliges bien el destinatario al hacer la nueva.

- Estás cobrándole a un cliente en la tienda y, en el último momento, cuando vas a darle la factura, el cliente te dice que se arrepiente y no quiere el producto.
Anulación al canto.

Hay infinidad de casos en los que no es lógico hacer una rectificativa sino una anulación.

Saludos

[espinete]

Entiendo los casos, y de hecho sería lo lógico. Pero... ¿no se supone que esto implicaría ir en contra de lo que precisamente Hacienda no quiere que hagamos?

Cómo demuestra el empresario que esa factura realmente no se llegó a entregar al cliente final? ¿No estaríamos permitiendo defraudar/esconder esa factura?

Al anular/baja una factura... ¿su número queda libre de nuevo para hacer otra factura usando ese mismo número?

[Sistel]

Empezado por espinete

Entiendo los casos, y de hecho sería lo lógico. Pero... ¿no se supone que esto implicaría ir en contra de lo que precisamente Hacienda no quiere que hagamos?

Creo que es lógico que Hacienda permita anular facturas que no deberían haberse emitido.
Otra cosa es si después Hacienda ve que hay muchas facturas sospechosas de ese tipo y le da por hacer una inspección.

Empezado por espinete

Cómo demuestra el empresario que esa factura realmente no se llegó a entregar al cliente final? ¿No estaríamos permitiendo defraudar/esconder esa factura?

Es que puede incluso anularse después de habérsele entregado al cliente.
Por supuesto, en ese caso, debe informar al cliente que se ha anulado esa factura por tal motivo.

Hacienda puede pedir explicaciones del por qué de una anulación.
Pero si hay una razón suficiente, no debe haber ningún problema.

Empezado por espinete

Al anular/baja una factura... ¿su número queda libre de nuevo para hacer otra factura usando ese mismo número?

No. El número no se recupera.
Y si se comprueba con el código QR, se verá que está anulada.

Saludos

[edari]

Buenos días,


Una pregunta os quiero hacer sobre el tema del encadenamiento de facturas


Si en un paquete de 40 facturas hay una rechazada por datos mal grabados, nif incorrecto etc...


Qué hacéis?


Parar el resto del envío hasta que se corrija la incidencia o enviar el resto y provocar un error de encadenamiento cuando la factura rechazada ya esté correcta y pueda subir


Gracias de antemano

[yasmNote]

Empezado por espinete

Ya verás qué divertido va a ser cuando implanten VeriFactu a nivel nacional

Hablando del verifactu, sabéis si en bizkaia, gipuzkoa o alava el verifactu es obligatorio? porque entiendo que con ticketbai ya estas cumpliendo no? porque he estado mirando y el verifactu es otra cosa como ticketbai o parecido...
¿Sabéis algo?

[edari]

Empezado por yasmNote

Hablando del verifactu, sabéis si en bizkaia, gipuzkoa o alava el verifactu es obligatorio? porque entiendo que con ticketbai ya estas cumpliendo no? porque he estado mirando y el verifactu es otra cosa como ticketbai o parecido...
¿Sabéis algo?

Verifactu no se aplica en el PV

[keys]

Hola a todos.

Como todos sabréis a partir del 1 de enero ha entrado una nueva versión de TicketBAI. Pues tenemos un cliente que esta dentro de unos de esos cambios, en concreto con una de las nuevas causas de no sujeción. Al intentar enviar la primera factura del año de este tipo hacienda de Gipuzkoa nos devuelve un error de que no se cumple el XSD.

Hablamos con hacienda y nos responden lo siguiente.

Por problemas técnicos no ha sido posible poner en marcha la nueva versión en PRODUCCION, en los siguientes días el nuevo esquema estará operativo.

Solo era por desahogarme.

[Irreo]

Empezado por espinete

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

Resumiendo y sin entrar en mucho detalle:
- BAJA es un servicio independiente igual que ALTA, pero anula la factura, y no se debe usar alegremente, es solo para casos concretos (facturas rechazadas por el cliente, servicios que no se han llegado a prestar...).
- La solicitud de baja puede fallar, y hay un servicio exclusivo de ZUZENDU-BAJA, donde reenvías la solicitud, corregida.
- ZUZENDU se usa para corregir facturas, pero tiene las variantes SUBSANAR y MODIFICAR.

Después comento esto un poco más.

Empezado por DemonAscun

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

Cuidado con ZUZENDU. Te cito lo que me dijeron desde Hacienda a raíz de unas incidencias:

El ZUZENDU-SUBSANAR es para corregir los XML que se han RECHAZADO.
El ZUZENDU-MODIFICAR es para corregir los XML que se han ACEPTADO pero tienen AVISOS DE ERROR.

Pero incluso esto tiene sus matices, porque una factura aunque haya sido aceptada con avisos, puede requerir una NUEVA factura rectificativa, sin ZUZENDU que valga.

Dicho esto, yo en su día tenía montado un sistema donde dependiendo del tipo de error, enviaba a ZUZENDU, o bien generaba una nueva factura rectificativa.

Iba bien hasta que un día empezó el primer problema con una factura que se intentaba corregir pero no se podía.

Después de hablar con Hacienda por teléfono, un técnico me dijo que una forma de ir a lo seguro es: si una factura se acepta con errores, se envía una nueva sustitutiva y listo. Con esto te evitas toda la problemática de si los datos que estás modificando son "visibles" o no, etc.

En mi caso el software que desarrollé es para uso de la empresa donde trabajo, así que el funcionamiento que decidamos solo nos afecta a nosotros.

Lógicamente dependiendo de lo que tengas montado, si es para revender terceros, etc. quizás sea matar moscas a cañonazos y saltarte ZUZENDU-MODIFICAR pueda dar problemas a la larga.

En resumen, yo lo que hago eso:
- Rechazada?: Zuzendu-Subsanar.
- Aceptada con errores?: Nueva factura sustitutiva.
- Queremos editar una factura (importes, líneas..)?: Nueva factura sustitutiva.

Un saludo.

[edejuan]

Empezado por keys

Hola a todos.

Como todos sabréis a partir del 1 de enero ha entrado una nueva versión de TicketBAI. Pues tenemos un cliente que esta dentro de unos de esos cambios, en concreto con una de las nuevas causas de no sujeción. Al intentar enviar la primera factura del año de este tipo hacienda de Gipuzkoa nos devuelve un error de que no se cumple el XSD.

Hablamos con hacienda y nos responden lo siguiente.

Solo era por desahogarme.

Impresionante, no dejan de sorprender ..., al Ticketbai y más allá.

Buenos días y feliz año a tod@s

[HerensugeBeltz]

Hola a todos,

Sé que este mensaje no tiene relación con TicketBAI, pero entiendo que todos somos desarrolladores de diferentes aplicaciones que contemplan el Régimen Foral del País Vasco, y mi propuesta puede ser de interés.

Debido a una próxima reestructuración en mi empresa estamos planteando dejar de dar soporte de nuestra aplicación de Contabilidad-Fiscal, y quisiera saber si alguno de vosotros desarrolláis una aplicación de contabilidad que soporte la Hacienda de Gipuzkoa (imprescindible) y del resto del País Vasco (muy deseable). Si además soporta la Hacienda Estatal e incluso la Navarra, tanto mejor.

Esta aplicación debería contemplar lo siguiente:
- Retenciones: 110, 216, 190, 296
- Arrendamientos: 115 y 180.
- Iva: 300/330; 390
- Pago fraccionado: 130
- Legalización de libros
- Trasvase cuentas contables para el impuesto de sociedades.

Nos consta que la aplicación DiamaCon de Comeralia cubriría nuestras necesidades, pero queremos conocer más alternativas.
La idea es analizar las aplicaciones sugeridas y la que consideremos más apropiada recomendarla a nuestros clientes para su progresiva implantación.

Por favor, las sugerencias enviadlas a bgngdatos@gmail.com para no cargar este foro.
Gracias a todos.