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

[rci]

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.
No me parece factible que el usuario de nuestro programa corrija a mano el XML con errores
Ando un poco perdido en este tema.

Gracias!

[Irreo]

Empezado por rci

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".

Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.

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.

[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

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

Empezado por rci

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

[rci]

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

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

Tienes razón Neftali. Que el usuario edite el XML no es una opción.

Supongo que tendremos que programar una solución para cada posible error.
Muchas gracias

[Irreo]

Empezado por rci

Supongo que tendremos que programar una solución para cada posible error.

No creo que sea cuestión de programar una solución para cada posible error

A ver, las facturas normales en si no tienen mucho misterio (por suerte) ya que es solo remitente, destinatario, y unas líneas de detalle.

Lo importante es tener desarrollada la funcionalidad de Alta con su firma, y por otro la de Zuzendu, que simplemente genera un XML prácticamente igual, pero sin firmar y adjuntando parte de la firma de la factura original.

Por lo demás, "da igual" que errores genere la factura original. ¿CIF incorrecto? Lo corriges, y haces lo que corresponda.... ¿fecha aaaa-mm-dd en lugar de dd-mm-aaaa? Lo mismo.

Con esto quiero decir que lo importante es tener hechos los servicios de envío.

Lógicamente lo que si debes tener documentado en algún sitio es qué tienes que hacer con cada error, porque en unos casos será Zuzendu, y en otros requerirá crear una nueva factura rectificativa.

Por ejemplo, a nosotros nos pasó lo de un CIF con guión, y este fue el error devuelto:

1153 - El NIF del destinatario tiene un formato erróneo

El error "1153" yo lo tengo anotado como "a rectificar". Por lo tanto, la operativa fue corregir el CIF del cliente, y emitir una factura sustitutiva.

Ánimo y suerte.

[rci]

Empezado por Irreo

No creo que sea cuestión de programar una solución para cada posible error

A ver, las facturas normales en si no tienen mucho misterio (por suerte) ya que es solo remitente, destinatario, y unas líneas de detalle.

Lo importante es tener desarrollada la funcionalidad de Alta con su firma, y por otro la de Zuzendu, que simplemente genera un XML prácticamente igual, pero sin firmar y adjuntando parte de la firma de la factura original.

Por lo demás, "da igual" que errores genere la factura original. ¿CIF incorrecto? Lo corriges, y haces lo que corresponda.... ¿fecha aaaa-mm-dd en lugar de dd-mm-aaaa? Lo mismo.

Con esto quiero decir que lo importante es tener hechos los servicios de envío.

Lógicamente lo que si debes tener documentado en algún sitio es qué tienes que hacer con cada error, porque en unos casos será Zuzendu, y en otros requerirá crear una nueva factura rectificativa.

Por ejemplo, a nosotros nos pasó lo de un CIF con guión, y este fue el error devuelto:

1153 - El NIF del destinatario tiene un formato erróneo

El error "1153" yo lo tengo anotado como "a rectificar". Por lo tanto, la operativa fue corregir el CIF del cliente, y emitir una factura sustitutiva.

Ánimo y suerte.

Exacto Irreo, creo que haremos esto, desarrollar la parte de generar el xml para zuzendu y la parte del envío y después ver en cada caso como lo gestionamos.
En nuestro caso se ha rechazado una factura en Gipuzkoa, hemos enviado un guion y se ha rechazado, han contestado:

"Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFEJEMP-R' is not facet-valid with respect to pattern '(([a-zA-Z]{1}\d{7}[a-zA-Z]{1})(\d{8}[a-zA-Z]{1})([a-zA-Z]{1}\d{8}))' for type 'NIFType'."


Por lo tanto tenemos que utilizar Zuzendu subsanar para volver a enviar la factura sin el guión en el nif y con los apartados nuevos de zuzendu


Gracias

[Irreo]

Empezado por rci

Exacto Irreo, creo que haremos esto, desarrollar la parte de generar el xml para zuzendu y la parte del envío y después ver en cada caso como lo gestionamos.
En nuestro caso se ha rechazado una factura en Gipuzkoa, hemos enviado un guion y se ha rechazado, han contestado:

"Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFEJEMP-R' is not facet-valid with respect to pattern '(([a-zA-Z]{1}\d{7}[a-zA-Z]{1})(\d{8}[a-zA-Z]{1})([a-zA-Z]{1}\d{8}))' for type 'NIFType'."


Por lo tanto tenemos que utilizar Zuzendu subsanar para volver a enviar la factura sin el guión en el nif y con los apartados nuevos de zuzendu


Gracias

¿Pero ese error lo has obtenido desde el servicio KONTSULTA, o fue lo que te devolvieron al enviar la factura a Alta?

Yo mirando la respuesta XML que tuvimos, tengo esto:

00 - Recibido - ALTA PREP
1153
El NIF del destinatario tiene un formato erróneo

Es decir, el estado es "00", recibido, pero con errores.

Esto fue en Gipuzkoa.

[rci]

Empezado por Irreo

¿Pero ese error lo has obtenido desde el servicio KONTSULTA, o fue lo que te devolvieron al enviar la factura a Alta?

Yo mirando la respuesta XML que tuvimos, tengo esto:

00 - Recibido - ALTA PREP
1153
El NIF del destinatario tiene un formato erróneo

Es decir, el estado es "00", recibido, pero con errores.

Esto fue en Gipuzkoa.

Fué al enviar una Alta de factura. El nif es correcto pero se nos pasó y venía un un guión. Y la factura se rechaza, código de error 002
Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFOKAQI-R' is not facet-valid with respect to pattern '(([a-z|A-Z]{1}\d{7}[a-z|A-Z]{1})|(\d{8}[a-z|A-Z]{1})|([a-z|A-Z]{1}\d{8}))' for type 'NIFType'.


En nuestro caso el estado es 01 Rechazada


Gracias