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

[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

[Ja Mon]

Empezado por Sistel

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

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

[Sistel]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

Hola Ja Mon,

Las facturas deben ser consecutivas en número, fecha y hora.
Yo considero 2 estados:
- Recopilación de datos para la factura (no considero aún emitida la factura)
- Emisión de la factura: asignación de nº de factura (siguiente a la última emitida), fecha y hora y creación y firma del XML

Si la asignación de nº de factura, fecha y hora y creación del XML y firma lo haces en servidor, te olvidas del problema de que haya varios puestos diferentes creando facturas y no sean consecutivas.

Saludos

[ermendalenda]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

No.puedes asignat el número por adelantado.
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda.

[trumbolt]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

El problema que veo con tu acercamiento es que parece un parche añadido a tu sistema en vez de una solución integrada sobretodo pensando que esto no va a ser sólo para el Pais Vasco sino que vamos camino de tenerlo en todo el territorio nacional.

Por lo que veo, diferencias entre emitir la factura (supongo que en tu programa) y firmar el xml. En realidad, tu programa no debería considerar que se ha emitido una factura si no se ha generado el XML y firmado. En mi software, tras grabar la factura físicamente en la bbdd, por así decirlo, se genera el XML y se firma y si no se puede por alguna razón (fallo de certificado, ...), se cancela la transacción y la factura deja de existir internamente. Es la manera de asegurar un encadenamiento correcto. Luego ya esos XML firmados tienes que hacerlos llegar a Hacienda, en mi caso con un servicio de cola de envío independiente al software principal.

[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?

[Sistel]

Empezado por Ja Mon

...
¿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?

Hola Ja Mon,

Yo así lo entiendo.
Para mí la emisión de la factura es el momento en que creo el XML y lo firmo (en el mismo equipo) con la fecha y hora de ese momento.
Después ya extraigo el código TBAI y código QR para meterlos en el documento-factura y envío a Hacienda Foral.

Saludos