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

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

[Sistel]

Empezado por 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.

Hola,

Mi consejo es ponerse en contacto con la Hacienda Foral correspondiente, explicarles el problema y pedirles cual es la solución más conveniente.
En general, siempre que me he puesto en contacto con la sección de TicketBAI de alguna de las Haciendas Forales me han dado soluciones efectivas (y sobre todo dentro de normativa)

Saludos

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