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

[josevalle]

Hola:

El xml termina con: </T:TicketBai>

Y el programa de firma añade lo de signature, etc...

<Version>1.02</Version>
</Software>
</HuellaTBAI>
</T:TicketBai>

Yo tampoco utilizo Delphi, escribo el xml como fichero de texto, firmo con afirma, genero el Qr con Simplecodegenerator (freeware),
con base64 lo convierto y lo envio a la diputación con curl. Todo lo hago con bats. Lo tengo funcionando en Bizkaia y Alava.

[Doc Corrupto]

Tengo una duda, si envio una factura a ticketbai y por el motivo que sea no obtengo respuesta (problema servidor, etc...) la factura queda entregada, de que manera puedo consultar si una factura se encuentra en ticketbai? Ya que puede ser que le de a enviar y de un error de que esa factura ya existe en el sistema. Hay algún endpoint para verificar el estado de una factura? Si no es asi, como gestionais esta parte?

Saludos

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

Empezado por Doc Corrupto

si envio una factura a ticketbai y por el motivo que sea no obtengo respuesta (problema servidor, etc...) la factura queda entregada, de que manera puedo consultar si una factura se encuentra en ticketbai? Ya que puede ser que le de a enviar y de un error de que esa factura ya existe en el sistema. Hay algún endpoint para verificar el estado de una factura? Si no es asi, como gestionais esta parte?

Manualmente puedes hacerlo por ejemplo escaneando el QR o utilizando la web de consulta (ahora no recuerdo si todas la tienen).
De forma "automática" siempre puedes volver a enviarla y detectar el error de factura duplicada.
No hay que yo recuerde servicio de consulta.

[tejano]

Buenas tardes, no sé si sabéis responderme sobre estos temas de las fechas. Estamos recibiendo facturas de diferentes empresas de las haciendas forales y que creo que están haciendo lo que quieran con la fecha de expedición.

Creo que la fecha de expedición es lo que antiguamente llamábamos Fecha de factura y que esta debe ser siempre la fecha del día en la que hacemos la factura. Hemos recibido una factura con fecha de factura = 31/01/2024 y fecha de expedición = 02/02/2024.

Actualmente creo que solo existen 2 fechas, la fecha de expedición y la fecha del devengo, que es la fecha en la que nos devengamos el IVA. Puede haber otras fechas, pero sin demasiada importancia.

Si me lo podéis aclarar os lo agradezco.

Gracias

[keys]

Empezado por tejano

Buenas tardes, no sé si sabéis responderme sobre estos temas de las fechas. Estamos recibiendo facturas de diferentes empresas de las haciendas forales y que creo que están haciendo lo que quieran con la fecha de expedición.

Creo que la fecha de expedición es lo que antiguamente llamábamos Fecha de factura y que esta debe ser siempre la fecha del día en la que hacemos la factura. Hemos recibido una factura con fecha de factura = 31/01/2024 y fecha de expedición = 02/02/2024.

Actualmente creo que solo existen 2 fechas, la fecha de expedición y la fecha del devengo, que es la fecha en la que nos devengamos el IVA. Puede haber otras fechas, pero sin demasiada importancia.

Si me lo podéis aclarar os lo agradezco.

Gracias

Hola, sólo hay dos fechas. Fecha de expedición (Fecha en la que se emite la factura, día actual) y fecha de operación (Fecha de devengo), La fecha de devengo tiene que ser igual o inferior a la fecha de emisión de la facturas.

Me consta que hay aplicaciones que dejan poner en la fecha de expedición un día que no es el actual (el sistema se lo traga), pero eso no es correcto y no se sé si algún día les darán problema en Hacienda (tienen la fecha de firma). De hecho Alava ha incorporado un aviso (016) que indica si la fecha de expedición es anterior de la fecha del día.

Hacienda dice esto :

¿Qué se debe indicar en los campos “Fecha expedición factura” y “Hora expedición factura”?

Se refiere a la fecha y hora de en la que se ha expedido la factura a través del sistema TicketBAI, independientemente de que en su caso no se haya generado la impresión física de la misma.


Sin cambios

¿Cuándo debe cumplimentarse el campo “Fecha operación”?

Deberá cumplimentarse el campo "Fecha operación" cuando la fecha de realización de la operación sea distinta a la fecha de expedición de la factura.

Ejemplo: la empresa "A" vende mercancías a otra empresa el 3 de julio de 2022, documentando la operación en factura de fecha 1 de agosto de 2022. En este caso, se consignará el campo "Fecha expedición factura" con valor 1 de agosto de 2022 y el campo “Fecha operación” con valor 3 de julio de 2022.

[HerensugeBeltz]

Empezado por tejano

Buenas tardes, no sé si sabéis responderme sobre estos temas de las fechas. Estamos recibiendo facturas de diferentes empresas de las haciendas forales y que creo que están haciendo lo que quieran con la fecha de expedición.

Creo que la fecha de expedición es lo que antiguamente llamábamos Fecha de factura y que esta debe ser siempre la fecha del día en la que hacemos la factura. Hemos recibido una factura con fecha de factura = 31/01/2024 y fecha de expedición = 02/02/2024.

Actualmente creo que solo existen 2 fechas, la fecha de expedición y la fecha del devengo, que es la fecha en la que nos devengamos el IVA. Puede haber otras fechas, pero sin demasiada importancia.

Si me lo podéis aclarar os lo agradezco.

Gracias

Debéis indicar como fecha de operación 31/01/2024 y como fecha de expedición 02/02/2024. En caso de existir una única fecha, esta sería la fecha de expedición y se asume misma fecha de operación.

[Doc Corrupto]

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

Manualmente puedes hacerlo por ejemplo escaneando el QR o utilizando la web de consulta (ahora no recuerdo si todas la tienen).
De forma "automática" siempre puedes volver a enviarla y detectar el error de factura duplicada.
No hay que yo recuerde servicio de consulta.

de forma automática no existe ningún endpoint no?

gracias por la respuesta

[tejano]

Empezado por Doc Corrupto

de forma automática no existe ningún endpoint no?

gracias por la respuesta

Yo cuando envío la factura, viene un fichero de respuesta y verifico ese fichero.

Si quieres ir un nivel por encima, en Vizcaya que es con la que trabajo, puedes hacer una consulta en la hacienda y verificar que existe ya ese documento.

Existe el capítulo de consulta de facturas. Nosotros lo utilizamos para "cuadrar" nuestro IVA, contabilidad y emisión de facturas entre la DFB y nuestros datos.

Saludos

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

Empezado por tejano

en Vizcaya que es con la que trabajo, puedes hacer una consulta en la hacienda y verificar que existe ya ese documento.
Existe el capítulo de consulta de facturas.

El problema es que en los otros no.
Aquí como cada uno va por libre...

[Doc Corrupto]

Empezado por tejano

Yo cuando envío la factura, viene un fichero de respuesta y verifico ese fichero.

Si quieres ir un nivel por encima, en Vizcaya que es con la que trabajo, puedes hacer una consulta en la hacienda y verificar que existe ya ese documento.

Existe el capítulo de consulta de facturas. Nosotros lo utilizamos para "cuadrar" nuestro IVA, contabilidad y emisión de facturas entre la DFB y nuestros datos.

Saludos

claro, me refiero a los casos en los que no se recibe la respuesta, nos ha pasado en algún caso aislado entre miles de facturas entregadas, el problema es que enviamos la petición, no recibimos la respuesta por el motivo que sea, fallo en servidores, o lo que sea, y claro al no recibir la respuesta nosotros en nuestro sistema no creamos la factura final para que se entienda, si la queremos volver a enviar, nos dice que esa factura ya existe.

No me entra en la cabeza que no tengan un endpoint para verificar el estado de una factura

[edari]

Buenos días,


Conocéis alguna página que valide un código QR y te diga el nivel de corrección del error?


Gracias

[softtron]

Empezado por josevalle

Hola:

El xml termina con: </T:TicketBai>

Y el programa de firma añade lo de signature, etc...

<Version>1.02</Version>
</Software>
</HuellaTBAI>
</T:TicketBai>

Yo tampoco utilizo Delphi, escribo el xml como fichero de texto, firmo con afirma, genero el Qr con Simplecodegenerator (freeware),
con base64 lo convierto y lo envio a la diputación con curl. Todo lo hago con bats. Lo tengo funcionando en Bizkaia y Alava.

Muchas gracias josevalle, me has ayudado mucho. Se me abren otros caminos de desarrollo. He resuelto la firma con afirma, pero el curl para el envío parece que no lo genero bien. Puedes darnos un ejemplo de un curl montado para ver que puedo estar haciendo mal? No se si en el curl deben aparecer comillas " o comilla ' o no se usan.

[softtron]

Empezado por softtron

Muchas gracias josevalle, me has ayudado mucho. Se me abren otros caminos de desarrollo. He resuelto la firma con afirma, pero el curl para el envío parece que no lo genero bien. Puedes darnos un ejemplo de un curl montado para ver que puedo estar haciendo mal? No se si en el curl deben aparecer comillas " o comilla ' o no se usan.

He encontrado un ejemplo, pero aun no estoy totalmente seguro. ¿Una línea de comando Curl quedaría así para el envío a Álava?:

curl.exe --tlsv1.2 --data-binary "@c:\Efactura\Factura-Alava\factura1-signed.xml" --cert-type P12 --cert c:\Efactura\Certificado\softtron.pfx:123456789 -H "Content-Type: application/xml;charset=UTF8" -X POST htt ps ://pruebas-ticketbai.araba. eus/TicketBAI/v1/facturas/ -o c:\Efactura\respuesta.xml

Entre comillas " el archivo xml que se envía y el header. Pero en otros ejemplos Curl para otras haciendas forales las comillas se usan de forma diferente.

Si alguien me puede corroborar lo que es correcto, o confirmar lo que es erróneo, se lo agradezco.

[edari]

Empezado por softtron

He encontrado un ejemplo, pero aun no estoy totalmente seguro. ¿Una línea de comando Curl quedaría así para el envío a Álava?:

curl.exe --tlsv1.2 --data-binary "@c:\Efactura\Factura-Alava\factura1-signed.xml" --cert-type P12 --cert c:\Efactura\Certificado\softtron.pfx:123456789 -H "Content-Type: application/xml;charset=UTF8" -X POST htt ps ://pruebas-ticketbai.araba. eus/TicketBAI/v1/facturas/ -o c:\Efactura\respuesta.xml

Entre comillas " el archivo xml que se envía y el header. Pero en otros ejemplos Curl para otras haciendas forales las comillas se usan de forma diferente.

Si alguien me puede corroborar lo que es correcto, o confirmar lo que es erróneo, se lo agradezco.

Yo lo subo siempre con curl

curl.exe --tlsv1.2 --data-binary @\FICHERO.XML --cert-type P12 --cert CERTIFICADO:PASSWORD -H "Content-Type: application/xml;charset=UTF8" -X POST https://pruebas-ticketbai.araba.eus/...I/v1/facturas/ -o FICHERORESPUESTA.XML

[josevalle]

Empezado por softtron

He encontrado un ejemplo, pero aun no estoy totalmente seguro. ¿Una línea de comando Curl quedaría así para el envío a Álava?:

curl.exe --tlsv1.2 --data-binary "@c:\Efactura\Factura-Alava\factura1-signed.xml" --cert-type P12 --cert c:\Efactura\Certificado\softtron.pfx:123456789 -H "Content-Type: application/xml;charset=UTF8" -X POST htt ps ://pruebas-ticketbai.araba. eus/TicketBAI/v1/facturas/ -o c:\Efactura\respuesta.xml

Entre comillas " el archivo xml que se envía y el header. Pero en otros ejemplos Curl para otras haciendas forales las comillas se usan de forma diferente.

Si alguien me puede corroborar lo que es correcto, o confirmar lo que es erróneo, se lo agradezco.

Hola: Yo fui probando con los ejemplos de este foro y cuando la respuesta fue correcta di por terminada la búsqueda.

j:\TbaiAlava\curl -X POST --connect-timeout 30 --data-binary "@j:\TbaiAlava\XML\Factura230014Fir.xml" -o "j:\TbaiAlava\XML\RespTbaiFactura230014.xml" --cert-type P12 --cert SOLDISP_2CE25029TG_CERT.p12:999999 -H "Content-Type: application/xml;charset=UTF-8" https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

Es muy parecido a lo que tu dices.

[espinete]

Tengo un problema que me ha surgido hoy con un cliente, y no sé qué decirle para arreglar el lío que ha provocado...

Resulta que, por despiste, entró en el año/ejercicio 2023 en vez de en el 2024 (nuestro software separa los ejercicios en bases de datos diferentes), y se puso a hacer ventas.
Es decir, hizo facturas en la empresa de 2023 con fecha de 2024 y las envió a TicketBAI.

Lo peor de todo es que TicketBAI se las tragó sin rechistar. No le importó el encadenamiento, ni la fecha del ejercicio, ni el número de factura no correlativo... Nada. Enviadas y aceptadas.

Claro, al darse cuenta, ha ido a la empresa de 2024, y al hacer una venta, casualmente el número de factura ya se había enviado, y ahora TicketBAI responde con "factura duplicada".

En fin, un disparate que no sé muy bien cómo arreglar...

¿Puedo hacer en 2024 una rectificativa de una factura de 2023? ¿Debe el cliente anular las facturas que envió y volver a hacerlas bien? ¿Al anular una factura, eso me permite volver a enviar una nueva factura con el mismo número?

Y la más importante...

¿No debería TicketBAI evitar que ocurra esto, o cosas similares? Yo creo que dejar toda la responsabilidad a los desarrolladores no es buena idea. Nosotros no podemos contemplar, ni siquiera imaginar, todos los disparates que puede cometer un cliente. Si el requisito, exigencia, prohibición, etc. lo pone TicketBAI, que sean ellos quienes devuelvan un error, y no nosotros tener que prever todo lo que pueda pasar y evitar el envío.

Vamos, digo yo.

Araba por ejemplo desde hace poco empezó a dar los errores con las fechas de expedición, fecha de operación y fecha actual precisamente para evitar estos problemas.

[YellowStone]

Empezado por espinete

Tengo un problema que me ha surgido hoy con un cliente, y no sé qué decirle para arreglar el lío que ha provocado...

Resulta que, por despiste, entró en el año/ejercicio 2023 en vez de en el 2024 (nuestro software separa los ejercicios en bases de datos diferentes), y se puso a hacer ventas.
Es decir, hizo facturas en la empresa de 2023 con fecha de 2024 y las envió a TicketBAI.

Lo peor de todo es que TicketBAI se las tragó sin rechistar. No le importó el encadenamiento, ni la fecha del ejercicio, ni el número de factura no correlativo... Nada. Enviadas y aceptadas.

Claro, al darse cuenta, ha ido a la empresa de 2024, y al hacer una venta, casualmente el número de factura ya se había enviado, y ahora TicketBAI responde con "factura duplicada".

En fin, un disparate que no sé muy bien cómo arreglar...

¿Puedo hacer en 2024 una rectificativa de una factura de 2023? ¿Debe el cliente anular las facturas que envió y volver a hacerlas bien? ¿Al anular una factura, eso me permite volver a enviar una nueva factura con el mismo número?

Y la más importante...

¿No debería TicketBAI evitar que ocurra esto, o cosas similares? Yo creo que dejar toda la responsabilidad a los desarrolladores no es buena idea. Nosotros no podemos contemplar, ni siquiera imaginar, todos los disparates que puede cometer un cliente. Si el requisito, exigencia, prohibición, etc. lo pone TicketBAI, que sean ellos quienes devuelvan un error, y no nosotros tener que prever todo lo que pueda pasar y evitar el envío.

Vamos, digo yo.

Araba por ejemplo desde hace poco empezó a dar los errores con las fechas de expedición, fecha de operación y fecha actual precisamente para evitar estos problemas.

En mi opinión debería de anular todas las facturas enviadas erróneamente. Eso si, misma combinación de serie y número no te la van a aceptar, pues la factura va a seguir constando en Hacienda, como anuladas, pero con el número original, se puede comprobar en la web. Así que tendrá que utilizar una nueva numeración para ellas. A principios de año anulamos unas 300 facturas por el tema de la fecha de expedición, y esos números han quedado ahí. Y si, se pueden hacer rectificativas en 2024 de facturas de 2023, sin problema, identificándolas correctamente en numeración y fecha de expedición, que es lo que comprueban para localizar la factura rectificada.

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

Empezado por espinete

¿Puedo hacer en 2024 una rectificativa de una factura de 2023? ¿Debe el cliente anular las facturas que envió y volver a hacerlas bien? ¿Al anular una factura, eso me permite volver a enviar una nueva factura con el mismo número?

Si optas por la opción de anular (que no se si es la correcta) siempre puedes volver a generarlas con una SERIE diferente.
Si haces rectificativas creo que no hay problema porque sea de otro ejercicio; Si haces una el 31 de Diciembre, deberías poder rectificarla una semana después (que ya es el año siguiente).

[espinete]

Por lo pronto la clienta va a contactar con su delegación a ver qué le dicen.

Opciones siempre hay, pero en estos casos sería mucho más fácil que la propia delegación respondiera al envío con un "ojo, que hemos detectado algo que no cuadra" en vez de dejar que seamos nosotros quienes prevean cualquier circunstancia que pueda darse.
Ahora habrá que estar haciendo anulaciones, o rectificativas, rehaciendo las facturas, envíos... Y encima el cliente ya habrá hecho y enviado facturas nuevas después del desastre, así que más se complica.

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

Empezado por softtron

...pero el curl para el envío parece que no lo genero bien. Puedes darnos un ejemplo de un curl montado para ver que puedo estar haciendo mal? No se si en el curl deben aparecer comillas " o comilla ' o no se usan.

Recordar que en el segundo mensaje de este hilo, hay una recopilación de enlaces con con diferentes códigos, en diferentes lenguajes, para las diferentes operaciones.
Ahí hay varias referencias a códigos de envío con CURL.