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

[adolphsys]

Empezado por espinete

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

[espinete]

Empezado por adolphsys

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".

[keys]

Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

Yo no consigo que me de 017. No se sobre que lo estan aplicando.

[keys]

Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

URL de acceso a la aplicación web de lectura del QR, específica para cada Administración tributaria:
o Araba/Álava: https://ticketbai.araba.eus/TBAI/QRTBAI (sin “/” para el cálculo del CRC).
o Bizkaia: https://batuz.eus/QRTBAI/ (con “/” al final para el cálculo del CRC).
o Gipuzkoa: https://tbai.egoitza.gipuzkoa.eus/qr/ (con “/” al final para el cálculo del CRC).

[YellowStone]

Empezado por keys

Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas:


https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

Pero también falla.

[keys]

Empezado por YellowStone

La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas:


https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

Pero también falla.

Ya la direccion ya se que es la que ponéis, pero me refiero por tener en cuenta o no la / para calcular el crc. Que parece que se calcula distinto que en las otras haciendas. Por cierto hoy el propio enlace del ejemplo de la hacienda de ALAVA da error.

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

[elcharlie]

Empezado por keys

Ya la direccion ya se que es la que ponéis, pero me refiero por tener en cuenta o no la / para calcular el crc. Que parece que se calcula distinto que en las otras haciendas. Por cierto hoy el propio enlace del ejemplo de la hacienda de ALAVA da error.

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

Yo me supongo que estarán arreglándolo, me dá a mí la sensación de que algo mal tenian.

[sEngine]

Empezado por keys

Ya la direccion ya se que es la que ponéis, pero me refiero por tener en cuenta o no la / para calcular el crc. Que parece que se calcula distinto que en las otras haciendas. Por cierto hoy el propio enlace del ejemplo de la hacienda de ALAVA da error.

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

esa no me va pero el QR que generé yo ayer, hoy si que me funciona

[rci]

Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest


Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor.
Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente.

El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System).

En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío.

Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo:

    var httpWebRequest = HttpWebRequest.CreateHttp(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(this.certificate);
    httpWebRequest.Method = "POST";
    …

Pues bien, parece que cuando ejecutamos como servicio de windows, como arranca con el usuario system, el HttpWebRequest no tiene acceso al almacén de certificados de los otros usuarios, por ejemplo el usuario con que se inicia sesión en el servidor y donde instalamos el certificado en el navegador.

Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?


Muchas gracias!!

[adolphsys]

Empezado por rci

Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest


Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor.
Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente.

El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System).

En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío.

Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo:

    var httpWebRequest = HttpWebRequest.CreateHttp(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(this.certificate);
    httpWebRequest.Method = "POST";
    …

Pues bien, parece que cuando ejecutamos como servicio de windows, como arranca con el usuario system, el HttpWebRequest no tiene acceso al almacén de certificados de los otros usuarios, por ejemplo el usuario con que se inicia sesión en el servidor y donde instalamos el certificado en el navegador.

Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?


Muchas gracias!!

Hola, si nos detallas un poco más el problema tal vez alguien pueda ayudarte:

• Te refieres a un servicio de Windows puro y duro, o se consume mediante Internet Information Services (IIS)?
• Se trata de un entorno Terminal Services?
• Cómo se conectan los usuarios?
• Cada uno tendrá su propio certificado o utilizan todos el mismo?

Aunque no trabajo en .Net, si el certificado está instalado para el usuario XXX lógicamente no será accesible por el usuario YYY.

[rci]

Empezado por adolphsys

Hola, si nos detallas un poco más el problema tal vez alguien pueda ayudarte:

• Te refieres a un servicio de Windows puro y duro, o se consume mediante Internet Information Services (IIS)?
• Se trata de un entorno Terminal Services?
• Cómo se conectan los usuarios?
• Cada uno tendrá su propio certificado o utilizan todos el mismo?

Aunque no trabajo en .Net, si el certificado está instalado para el usuario XXX lógicamente no será accesible por el usuario YYY.

Hola adolphsys, muchas gracias por la respuesta.


Si, me refiero a un servicio de windows puro y duro. Tenemos una aplicación de consola que hace el envio. Si lo ejecutamos como aplicación funciona correctamente, porque lo estamos ejecutando con el usuario X que tiene el certificado instalado en su almacén de certificados.


Si arrancamos la aplicación desde un servicio de windows, hacemos que arranque con el usuario del sistema local (System) y luego no tiene acceso al almacén de certificados del usuario X.

Si configuramos el servicio para que arranque con el usuario X, luego funciona pero pensamos que no es buena idea, porque por ejemplo, si el usuario cambia el password, el servicio deja de funcionar, por eso queremos que arranque con el usuario del sistema local, como viene por defecto.




A parte tenemos la aplicación TPV en cada ordenador, esa aplicación genera el xml, lo firma, lo guarda e imprime la factura.

La aplicación de envio solo está en el servidor y va cogiendo las facturas firmadas en el orden correcto y las va enviando.


El certificado es el mismo para todos. Cada ordenador con TPV tiene el certificado instalado para firmar.

En el servidor también hay el certificado instalado para poder enviar.


Creo que el problema es del componente que utilizamos System.Net.HttpWebRequest que por lo que parece siempre busca en el almacén de certificados del usuario y claro...

No se si alguién que utilice C# .Net usa otro componente para enviar TicketBAI



Muchas gracias!

[hago_preguntas]

Empezado por keys

Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo


Yo no consigo que me de 017. No se sobre que lo estan aplicando.

¿De donde has sacado el ejemplo?

A mí me sale crc=036, calculado sobre el enlace que has puesto quitando &crc=017

[adolphsys]

Empezado por espinete

Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".

Eso es, ya sabes que al cliente final hay que permitirle seguir facturando haya enviado o no la factura a Hacienda.

A Vizcaya puedes enviar un bloque por ejemplo de 10 facturas, e igual aceptan seis, y cuatro se rechazan, así que tienes que examinar el XML de respuesta y leer el estado de cada factura de forma individualizada.