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

[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

[Irreo]

Buenos días a todos,

Ando redactando la memoria para Gipuzkoa, y repasando en mi código el tema del encadenamiento, a la hora de redactar cómo funciona, me han entrado algunas dudas sobre si lo que tengo montado se puede considerar correcto.

En la documentación mencionan que en Gipuzkoa la comunicación debe ser "inmediata". Pero claro, no estoy seguro qué consideran ellos inmediato...

El sistema que tengo montado (todavía en fase de pruebas) funciona así:

Infraestructura:
- Servidor con un API propio, que viene a ser un "proxy" entre las personas que crean las facturas, y Hacienda.
- Tiendas físicas con software Windows para venta y emisión de tickets.

Servidor:
- Se recibe un JSON con una factura.
- Se crea un registro en la BBDD con todos los datos.
- Se firma y se guarda todo.
- Si es nueva factura queda marcada como "pendiente de enviar", y si es una corregida se guarda como "a reenviar"

Cronjob que se está ejecutando constantemente en el servidor:
- Cada 10 segundos, y en orden de creación de factura, se lee una factura de la tabla anterior y se envía.
- Si es una factura sin intento de envío previo, obtengo el XML ya firmado que estaba guardado.
- Si es una factura a corregir, genero de nuevo el XML a partir de los datos de la factura, que no va firmado.

Con esto me aseguro de que el encadenamiento esté siempre bien. Es decir, aunque una factura sea rechazada, ya se considera como "factura anterior" para el encadenamiento.
Y al haber solo un hilo del sistema dedicado al envío de facturas, con los 10 segundos de margen se evitan situaciones donde dos envíos se pisan entre ellos, si el primero por ejemplo tarda varios segundos.

Otro de los motivos de tener esto así, es poder emitir el ticket con el QR incluso aunque todavía no hayamos comunicado con Hacienda.

Es decir:
- Un cliente compra un producto en la tienda.
- El software del ordenador envía los datos a nuestro API, y le entrega el QR y TBAI.
- La factura todavía no sabemos si tiene el XML incorrecto, si va a ser rechazada o aceptada, pero entiendo que me da igual.
- El cliente se va con su ticket.
- En los segundos siguientes a haberse guardado la factura, ya se va a enviar a Hacienda mediante el cronjob.

¿Mi preocupación?
Que por lo que sea, se generen muchas facturas en algún momento, y en lugar de tardar de 1 a 9 segundos en estar funcional el QR, tarde 50 segundos por ejemplo... o más.

¿Debe ser inmediato.... inmediato?

¿Sabéis algo de si el inspector que hace verificaciones presenciales crea una factura e intenta leer el QR en el mismísimo instante?

Gracias!
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.

[Ja Mon]

Empezado por ermendalenda

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.

Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales.

Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador.
Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema.

Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima.


Muchas gracias a los dos, poco a poco voy resolviendo las dudas.

[Ja Mon]

Empezado por ermendalenda

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.

Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales.

Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador.
Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema.

Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima.


Otra duda:
Cuando se imprime la factura se imprimen los vencimientos con su fecha. Una vez firmada, si el cliente desea cambiar la fecha de los vencimientos, dividirlos en varios, etc. Puede hacerlo pero, si sacamos un duplicado de la factura ¿los vencimientos nuevos (fechas e importes) que se imprimen deben ser los originales o pueden ser los nuevos? Si son los originales, habrá que buscar el fichero (pdf, o lo que sea) que se creó en su día e imprimirlo en vez de usar el metodo de impresión habitual...



Muchas gracias a los dos, poco a poco voy resolviendo las dudas.

[trumbolt]

Empezado por ermendalenda

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.

Algo así hacemos nosotros. La primera estación que empieza a emitir una factura digamos que bloquea el contador de facturas y no lo libera hasta que queda finalizada la firma del XML. Si otra fuese a facturar justo en ese momento, queda en espera a que el contador si libere (mirando con las pruebas es cuestión de 1 segundo o así) y toma el control para facturar él. Esto lógicamente en entornos en donde las estaciones de trabajo funcionen con la misma serie. En otros donde cada PC factura con la suya propia y sin interrelación con el resto, no es necesario esperar ya que el encadenamiento sólo afectaría a sus facturas. Ideal para entornos como restaurantes o tiendas con varios TPVs trabajando a destajo ...

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

[Ja Mon]

Empezado por trumbolt

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.

Tienes razón y, como me indicaba Sistel, lo que hago ahora es crear facturas temporales que se pueden eliminar en cualquier momento. Solo cuando el usuario imprime, exporta o envía por correo electrónico se asigna un número, fecha y hora definitivos Luego, otro proceso en el servidor se encarga de gestionar la cola de los xml que le van llegando.
Creo que desde el principio tenía confusión sobre crear, emitir, imprimir, expedir... Ahora todo es lo mismo.

[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