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

[JoseLeeTo]

Empezado por adolphsys

Acabo de hacer un envío a Araba y a mi me funciona.

Muchas gracias.
Acabo de escribirles a ver qué puede estar pasando.
Hace unos días, funcionaba correctamente. Luego de unos días, me estaba devolviendo siempre que está caído el servicio.

Hoy ya me ha extrañado mucho, y les he escrito.

Aquello es chapuza tras chapuza, de verdad.

Por lo demás, a la hora de consultar facturas a la URL que han habilitado, me devuelve lo mismo que al resto de compañeros: "Parámetros incorrectos"

Lo dicho... chapuza, tras chapuza.

[JoseLeeTo]

Empezado por edari

Mismo caso que tú

Estamos todos igual, parece ser

[JoseLeeTo]

Acabo de acordarme de esto que remitieron:

Nos dirigimos a usted como participante del período de pruebas del sistema TicketBai en Álava para informarle de lo siguiente:

• Por motivos técnicos, el próximo Martes 19 de Octubre desde las 07:30 de la mañana el entorno de pruebas de TicketBai Álava no estará disponible. En el momento en que vuelva a estar disponible le informaremos por este mismo medio.


No obstante, mañana volveré a probar, a ver qué resultado me devuelven.

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

[unomasmas]

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?

Una cosa es la generación de la factura (del XML firmado y con QR generado) y otra el envío. Son procesos independientes. Puedes (debes) firmar el XML y generar su correspondiente código QR antes de imprimir (de hecho, lo necesitas para imprimirlo en la factura). Una vez generada puede enviarse inmediatamente o quedarse ahí y enviarla después junto con otras...

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

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

Empezado por YellowStone

Buenas.
¿Cómo evitar que al subir un código al foro, sustituya donde pone por un smile?
Por ejemplo en xadesigest
?

Hay diferentes etiquetas, prueba con otra.

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

[unomasmas]

Empezado por rci

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!

Yo no lo tengo como servicio y posiblemente eso cambie las cosas pero no necesariamente tienes que coger el certifcado del almacén. Puedes pasarle un certificado concreto, con lo que sería igual qué usuario se conecte.

HttpWebRequest.ClientCertificates = new X509CertificateCollection() { certificado };

[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

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

[HerensugeBeltz]

Empezado por rci

... 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 podéis utilizar un certificado basado en fichero? Si usáis la clase X509Certificate2, con el método Import podéis cargar el certificado y, en teoría, asignárselo al objeto HttpWebRequest.

Por cierto, según la información de Microsoft:
We don't recommend that you use HttpWebRequest for new development. Instead, use the System.Net.Http.HttpClient class.

[rci]

Empezado por unomasmas

Yo no lo tengo como servicio y posiblemente eso cambie las cosas pero no necesariamente tienes que coger el certifcado del almacén. Puedes pasarle un certificado concreto, con lo que sería igual qué usuario se conecte.

HttpWebRequest.ClientCertificates = new X509CertificateCollection() { certificado };

Hola unomasmas, muchas gracias por la respuesta.
Ya le paso el certificado concreto, de la misma forma que se hace con el código que has indicado, añadiendolo a la colección ClientCertificates:

 httpWebRequest.ClientCertificates.Add(this.certificate);

Yo entiendo que esto sirve para decirle cual de los certificados del almacén tiene que utilizar. Pero si no están en el almacén de certificados del usuario (instalados en el navegador) no funciona el post de httpWebRequest para TicketBAI porque no encuentra certificado de cliente.

De hecho en la documentacion de microsoft ya lo indica:
https://docs.microsoft.com/es-es/dot...t?view=net-5.0

hay la frase:

Para la autenticación de cliente con HttpWebRequest , el certificado de cliente debe estar instalado en el almacén de certificados del usuario actual.

Supongo que tu también lo tienes en el almacén y por eso te funciona cuando no es un servicio de windows.


Muchas gracias de todas formas, a ver si hay suerte.

[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

[keys]

Empezado por sEngine

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

Hola me acaban de comunicar de hacienda que ya lo han solucionado.

Hemos tenido un problema técnico a la hora de implantar la consulta del QR en el entorno de Pruebas. En principio ya os debería funcionar.

Pero sigo sin conseguir que me funcione. Has tenido en cuenta a la hora de calcular el crc la / del final. Puedes poner un ejemplo?

Gracias

[sEngine]

Lo hago igual que para las demas haciendas
un QR que va



https://pruebas-ticketbai.araba.eus/...&i=94.5&cr=122

[misteradrian]

Hola muy buenas de nuevo,

para el entorno de pruebas he estado utilizando un certificado de representante legal y tira bien.
Pero estoy interesado en pasarme a uno de sello de empresa.
¿Sabéis de alguno que sean más baratos de los de la FNMT?
He enviado correos a varias compañías para obtener información dentro de este listado (no tengo permitido insertar enlaces) :

ttps://esignature.ec.europa.eu/efda/tl-browser/#/screen/tl/ES

En cuanto sepa algo os digo.

[elcharlie]

Empezado por keys

Hola me acaban de comunicar de hacienda que ya lo han solucionado.



Pero sigo sin conseguir que me funcione. Has tenido en cuenta a la hora de calcular el crc la / del final. Puedes poner un ejemplo?

Gracias

A mi tampoco me funciona, no sé lo que es.
Edito:
Me funcionan algunos y otros no, los que no me funcionan son los que tienen el símbolo +, que reemplazo por %2B

[keys]

Muchas gracias.

¿Puedes generar un factura sin serie?, si lo hago con serie funciona, pero si es sin serie no funciona.

Gracias.