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

[rci]

Empezado por Irreo

Por un lado, el XML que se envía no es sin más el original sin firmar. Aunque mantiene la estructura original, la definición del fichero y el bloque de "Cabecera" cambian.

Por otro lado, si hay un error en el XML, significa que hay un problema en el software que lo ha generado, o bien en la propia factura.

Es decir, corregir un XML a mano y enviarlo puede ser algo factible cuando tienes que enviar YA algo, y no tienes otra cosa preparada.

Lo correcto es corregir el problema que ha motivado un XML erróneo.

Por ejemplo, si le faltan las líneas de detalle, hay que enviarlo a Zuzendu-Subsanar. De nada sirve que abras el XML y las agregues a mano, porque te va a volver a pasar.

O abres la factura desde tu aplicación y agregas las líneas de detalle, y vuelves a enviarla, o bien corriges la programación que ha impedido la generación de unas líneas de detalle que sí existían.

En conclusión, ahora mismo no se me ocurre un motivo o razón justificada para editar un XML a mano.

Por ejemplo, en el sistema que tengo montado si hay un problema con el envío, me guardo el código de error, y además marco esa factura como a rectificar, o enviar a Zuzendu (según el error original), para saber qué hacer con ella. Además, dejo un registro de todos y cada uno de los envíos, con el XML original y el firmado para cada caso, con la respuesta obtenida. Pero cada intento de envío genera un XML y un registro nuevo, es decir, jamás reutilizo un XML ya generado.

Tienes razón Irreo, el usuario no puede editar el XML.

El caso es este, todavía no hemos desarrollado zuzendu y se ha rechazado una factura por un cif enviado con un guion, por un bug del programa. Ya hemos corregido el programa para no permitirlo pero claro, tenemos que enviar esa factura de alguna forma.
La idea es que no se rechacen facturas pero siempre puede ocurrir algo..


Vamos a ver como lo hacemos.



Muchas gracias

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

Empezado por rci

Ya hemos corregido el programa para no permitirlo pero claro, tenemos que enviar esa factura de alguna forma.

A estas alturas ya tengo un lío en la cabeza importante y además ahora hace semanas que hemos apartado este tema, pero ¿esas facturas erróneas, una vez corregido el programa, no puedes enviarlas con el libro 240 sin software garante?

UPDATE:
Efectívamente me he echo un lío. 240SinSG sólo es para BATUZ y asumo que tú estás en una de la otras dos tributaciones.
En ese caso y según la documentación:

Artículo 1. Procedimiento para el envío de la información correspondiente
al fichero TicketBAI que ha sido rechazado.
1. La información correspondiente al fichero TicketBAI que ha sido objeto de rechazo
por no cumplir las validaciones mínimas establecidas en la Orden Foral 521/2020, de
23 de diciembre, por la que se regulan las especificaciones técnicas y funcionales del
software TicketBAI y la declaración de alta en el Registro de Software TicketBAI,
deberá ser objeto de subsanación a través del envío del fichero de subsanación, de
acuerdo con los requisitos de los servicios Zuzendu, el procedimiento y las
especificaciones técnicas y funcionales que se regulan como anexo I a la presente
orden foral.
2. El fichero TicketBAI rechazado no podrá sufrir alteración alguna, y deberá
conservarse en su estado original dentro del sistema informático para garantizar la
integridad, conservación, trazabilidad e inviolabilidad del fichero TicketBAI generado
por el software TicketBAI.

[rci]

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

A estas alturas ya tengo un lío en la cabeza importante y además ahora hace semanas que hemos apartado este tema, pero ¿esas facturas erróneas, una vez corregido el programa, no puedes enviarlas con el libro 240 sin software garante?

UPDATE:
Efectívamente me he echo un lío. 240SinSG sólo es para BATUZ y asumo que tú estás en una de la otras dos tributaciones.
En ese caso y según la documentación:

Artículo 1. Procedimiento para el envío de la información correspondiente
al fichero TicketBAI que ha sido rechazado.
1. La información correspondiente al fichero TicketBAI que ha sido objeto de rechazo
por no cumplir las validaciones mínimas establecidas en la Orden Foral 521/2020, de
23 de diciembre, por la que se regulan las especificaciones técnicas y funcionales del
software TicketBAI y la declaración de alta en el Registro de Software TicketBAI,
deberá ser objeto de subsanación a través del envío del fichero de subsanación, de
acuerdo con los requisitos de los servicios Zuzendu, el procedimiento y las
especificaciones técnicas y funcionales que se regulan como anexo I a la presente
orden foral.
2. El fichero TicketBAI rechazado no podrá sufrir alteración alguna, y deberá
conservarse en su estado original dentro del sistema informático para garantizar la
integridad, conservación, trazabilidad e inviolabilidad del fichero TicketBAI generado
por el software TicketBAI.

Disculpa Neftali, no habia especificado que es para Gipuzkoa, que tienen Zuzendu y creo que es igual o muy similar que el Zuzendu de Araba. En cambio en Bizkaia no lo tienen pero hay este capítulo de "Sin software garante".

Ahora estamos con el Zuzendu y mas adelante ya entraremos con el Batuz apartado "sin software garante"

Muchas Gracias