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

[Ja Mon]

Empezado por trumbolt

Aunque no ingrese en su sistema (caso de que el xml sea rechazado como indicas) ese XML se corresponde con una factura perfectamente válida ya emitida por el software y como dice @sistel, eso va a misa. Para solventar el problema luego se tendría que realizar un Zuzendu de subsanación en el caso de Guipuzcua y Alava con lo que el QR de esa factura ya emitida y que tendría en poder el cliente, empezaría a funcionar correctamente porque la factura ya estaría "dada de alta" por asi decirlo, en su sistema.

Deberías de diseñar el sistema para que fuese autónomo de manera que si hubiese un problema de conexión (los servidores de IZEMPE se caen o están "en mantenimiento", o la conexión a inet se va por avería), el software pueda seguir emitiendo facturas con encadenamiento, QR e identificador tbai. Eso fue una de las cosas que más me costó entender en un principio ...

Intuitivamente, me cuesta aceptar entregarle al cliente información potencialmente erronea que pueda suponer un conflicto para el vendedor pero si hacienda no le va a "buscar las cosquillas" pues lo haré así.
Muchas gracias, sistel y trumbold, por la ayuda.

[xamminf]

Hola a todos,

No sé si esto ha sido respondido, pero pregunto

Cuando generamos el .xml, hay alguna forma de saber si es valido o no antes de mandarlo, a nivel de sintaxis y a nivel de informacion.
Si fuera erroneo intentaría rehacerlo y no generar la cadena de .xml erroneo + envio + error en pantalla + llamada del usuario + .xml de anulacion
Lo digo porque sobre todo al principio puedo generar algunos .xml erroneos y claro eso conllevara problemas y quizas anulaciones


Gracias de antemano

[Sistel]

Empezado por xamminf

...
Cuando generamos el .xml, hay alguna forma de saber si es valido o no antes de mandarlo, a nivel de sintaxis y a nivel de informacion.
Si fuera erroneo intentaría rehacerlo y no generar la cadena de .xml erroneo + envio + error en pantalla + llamada del usuario + .xml de anulacion
...

Hola xamminf,

Sí. Puedes usar un verificador para comprobar que el XML cumple el esquema XSD de TicketBAI.
Yo programo en PHP y para verificar los XML creados utilizo la función DOMDocument::schemaValidate (https://www.php.net/manual/es/domdoc...schemavalidate)
Supongo que todos los lenguajes tendrán alguna función similar.

Pero ojo, la verificación deberías hacerla no sólo antes de enviar el XML a Hacienda, sino antes de emitir realmente la factura.
Los pasos que yo hago son:
- Recabar y comprobar todos los datos que compondrán la factura.
- Recabar los datos necesarios de la factura anterior para el encadenamiento.
- Creación del XML
- Firma del XML
- Verificación del XML frente al esquema XSD de TicketBAI

Si pasa la verificación, obtengo los códigos TBAI y QR y doy por emitida la factura.

Si no pasa la verificación, no puedo emitir esa factura (ni me molesto, en ese caso, en obtener los códigos TBAI yQR).

Hasta que no pasa la verificación no doy como utilizado el número de factura que le había asignado provisionalmente: la factura no está aún emitida.

El tema del envío a Hacienda es algo posterior (y sólo una vez emitida la factura)

Saludos

[xamminf]

Empezado por Sistel

Hola xamminf,

Sí. Puedes usar un verificador para comprobar que el XML cumple el esquema XSD de TicketBAI.
Yo programo en PHP y para verificar los XML creados utilizo la función DOMDocument::schemaValidate (https://www.php.net/manual/es/domdoc...schemavalidate)
Supongo que todos los lenguajes tendrán alguna función similar.

Pero ojo, la verificación deberías hacerla no sólo antes de enviar el XML a Hacienda, sino antes de emitir realmente la factura.
Los pasos que yo hago son:
- Recabar y comprobar todos los datos que compondrán la factura.
- Recabar los datos necesarios de la factura anterior para el encadenamiento.
- Creación del XML
- Firma del XML
- Verificación del XML frente al esquema XSD de TicketBAI

Si pasa la verificación, obtengo los códigos TBAI y QR y doy por emitida la factura.

Si no pasa la verificación, no puedo emitir esa factura (ni me molesto, en ese caso, en obtener los códigos TBAI yQR).

Hasta que no pasa la verificación no doy como utilizado el número de factura que le había asignado provisionalmente: la factura no está aún emitida.

El tema del envío a Hacienda es algo posterior (y sólo una vez emitida la factura)

Saludos

Sistel muchas gracias por tu detallada informacion

[Ja Mon]

Hola, de nuevo.

Expongo la problemática y una solución, a ver si estoy en lo correcto y si alguien más se ha encontrado con esto y le sirve de ayuda.



En entornos multipuesto, varios usuarios var a querer obtener la última factura emitida al mismo tiempo:

a.Ultima factura firmada es 1
b.Equipo PC1 crea factura 2 y su xml, busca ultima factura (1) y firma
c.Mientras tiene lugar el proceso b. los equipos PC2, PC3, PC4 crean sus facturas (3,4,5) y sus xml y buscan la ultima factura.
d.Si b. no ha acabado (por el motivo que sea) todos encontrarán que la ultima factura sigue siendo 1 y todos querran incluirla en el encadenamiento.


Si se pudiesen firmar los xml en el servidor, no sería problema: se crea un cola y ya se procesará allí. Pero en las faq (8.10) indica que es el equipo emisor de la factura el que tiene que realizar la firma.

Para solucionarlo estoy creando este flujo de trabajo, a ver que os parece.


a.Equipo PC1 crea XML en una carpeta del servidor
b.El servidor busca la última factura firmada.
c.El servidor agrega el encadenamiento al fichero XML
d.El servidor comunica a Equipo PC1 que ya puede firmar
e.Equipo PC1 firma y lo comunica al servidor

f.El servidor envia el fichero y continua con el siguiente XML de su lista.
g.Equipo PC1 ya puede imprimir, exportar o enviar por correo electrónico.



Creo que también podría "obligar" al usuario a tener una serie en cada equipo (faq 14.1) pero los clientes, habitualmente, quieren poder imprimir facturas correlativas desde cualquier puesto de trabajo.

[Ja Mon]

Otra duda sobre algo que, supongo, estará permitido. He enviado la consulta a hacienda pero la respuesta me ha dejado dudas.



En multipuesto y con una misma serie el fichero xml, su firma y envio de la factura 1000 puede ser posterior al envio de la factura 1001 debido a que la 1000 es una factura que está siendo revisada, o se ha dejado a medias en el almuerzo o la comida, etc. y la 1001 es una operación rápida de un cliente que está en el mostrador.


¿Supone algún problema?
Gracias.

[Sistel]

Empezado por Ja Mon

Otra duda sobre algo que, supongo, estará permitido. He enviado la consulta a hacienda pero la respuesta me ha dejado dudas.



En multipuesto y con una misma serie el fichero xml, su firma y envio de la factura 1000 puede ser posterior al envio de la factura 1001 debido a que la 1000 es una factura que está siendo revisada, o se ha dejado a medias en el almuerzo o la comida, etc. y la 1001 es una operación rápida de un cliente que está en el mostrador.


¿Supone algún problema?
Gracias.

Hola Ja Mon,

No debe retrasarse la firma y envío en ningún caso.
(El envío sólo podría retrasarse en Bizkaia que se envía mediante LROE)

Yo considero que la emisión de la factura tiene lugar en el momento que se firma crea y firma el XML y debe llevar esa fecha y hora.
No se puede crear un XML y firmar más adelante.
Se trata de que todas las facturas sean consecutivas, con fecha y hora de la emisión y con envío inmediato.

Saludos

[Sistel]

Empezado por Ja Mon

Hola, de nuevo.

Expongo la problemática y una solución, a ver si estoy en lo correcto y si alguien más se ha encontrado con esto y le sirve de ayuda.



En entornos multipuesto, varios usuarios var a querer obtener la última factura emitida al mismo tiempo:

a.Ultima factura firmada es 1
b.Equipo PC1 crea factura 2 y su xml, busca ultima factura (1) y firma
c.Mientras tiene lugar el proceso b. los equipos PC2, PC3, PC4 crean sus facturas (3,4,5) y sus xml y buscan la ultima factura.
d.Si b. no ha acabado (por el motivo que sea) todos encontrarán que la ultima factura sigue siendo 1 y todos querran incluirla en el encadenamiento.


Si se pudiesen firmar los xml en el servidor, no sería problema: se crea un cola y ya se procesará allí. Pero en las faq (8.10) indica que es el equipo emisor de la factura el que tiene que realizar la firma.

Para solucionarlo estoy creando este flujo de trabajo, a ver que os parece.


a.Equipo PC1 crea XML en una carpeta del servidor
b.El servidor busca la última factura firmada.
c.El servidor agrega el encadenamiento al fichero XML
d.El servidor comunica a Equipo PC1 que ya puede firmar
e.Equipo PC1 firma y lo comunica al servidor

f.El servidor envia el fichero y continua con el siguiente XML de su lista.
g.Equipo PC1 ya puede imprimir, exportar o enviar por correo electrónico.



Creo que también podría "obligar" al usuario a tener una serie en cada equipo (faq 14.1) pero los clientes, habitualmente, quieren poder imprimir facturas correlativas desde cualquier puesto de trabajo.

Hola Ja Mon,

El procedimiento que propones puede crear un cuello de botella si el PC tarda mucho en firmar.

Y sí que está admitida la firma en servidor.
Lee las especificaciones de firma de TicketBAI. Hay tres modalidades admitidas:
- Arquitecturas con firma en cliente
- Arquitecturas con firma en servidor
- Arquitecturas con posibilidad de firma en cliente y en servidor

Firmar en servidor te permite tener un único certificado digital y aislar el tema de la firma de los problemas que pueda tener un PC.

Saludos

[Ja Mon]

Empezado por Sistel

Hola Ja Mon,

El procedimiento que propones puede crear un cuello de botella si el PC tarda mucho en firmar.

Y sí que está admitida la firma en servidor.
Lee las especificaciones de firma de TicketBAI. Hay tres modalidades admitidas:
- Arquitecturas con firma en cliente
- Arquitecturas con firma en servidor
- Arquitecturas con posibilidad de firma en cliente y en servidor

Firmar en servidor te permite tener un único certificado digital y aislar el tema de la firma de los problemas que pueda tener un PC.

Saludos

Ok. Creo que es una confusión con los términos. En 8.10 dice


Sí, si bien la firma del fichero XML TicketBAI se deberá realizar en el dispositivo en elque se genere la factura, el envío a la Administración podrá hacerlo tanto el propio
dispositivo de facturación como otro dispositivo diferente,por ejemplo, un servidor
centralqueenvíe losficheros devariosdispositivos defacturación


¿debo entender que el dispositivo en elque se genere la factura es el equipo donde se genera el xml, no el equipo donde está abierta la factura e inicia todo el proceso?