Foros Club Delphi
Página 49 de 114 « Primero < 39464748 49 5051525999 > Último »
Mostrar 40 mensajes desde este tema en una página

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)
-   -   TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco (https://www.clubdelphi.com/foros/showthread.php?t=94264)

JoseLeeTo 19-10-2021 16:25:50
Cita:
Empezado por adolphsys (Mensaje 543593)
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. :mad:

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 19-10-2021 16:26:27
Cita:
Empezado por edari (Mensaje 543577)
Mismo caso que tú v\||/
Estamos todos igual, parece ser

JoseLeeTo 19-10-2021 16:29:11
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 19-10-2021 16:58:50
Cita:
Empezado por espinete (Mensaje 543589)
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 19-10-2021 17:07:48
Cita:
Empezado por espinete (Mensaje 543586)
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 19-10-2021 17:37:11
Cita:
Empezado por rci (Mensaje 543595)
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:

Código:
    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?:confused:


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] 19-10-2021 17:49:37
Cita:
Empezado por YellowStone (Mensaje 543564)
Buenas.
¿Cómo evitar que al subir un código al foro, sustituya donde pone :D por un smile?
Por ejemplo en xades:Digest
?
Hay diferentes etiquetas, prueba con otra.

rci 19-10-2021 18:15:24
Cita:
Empezado por adolphsys (Mensaje 543601)
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 19-10-2021 18:54:38
Cita:
Empezado por rci (Mensaje 543603)
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.

Código:
HttpWebRequest.ClientCertificates = new X509CertificateCollection() { certificado };

hago_preguntas 19-10-2021 20:10:48
Cita:
Empezado por keys (Mensaje 543590)
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 20-10-2021 08:34:47
Cita:
Empezado por YellowStone (Mensaje 543594)
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 20-10-2021 08:54:21
Cita:
Empezado por keys (Mensaje 543607)
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 20-10-2021 08:54:43
Cita:
Empezado por rci (Mensaje 543603)
... 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 20-10-2021 08:58:12
Cita:
Empezado por unomasmas (Mensaje 543604)
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.

Código:
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:
Código:
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:
Cita:
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 20-10-2021 09:52:08
Cita:
Empezado por keys (Mensaje 543607)
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 20-10-2021 10:32:40
Cita:
Empezado por sEngine (Mensaje 543612)
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.

Cita:
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 20-10-2021 10:38:03
Lo hago igual que para las demas haciendas
un QR que va



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

misteradrian 20-10-2021 10:54:52
Certificados Sello de empresa
 
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 20-10-2021 10:55:54
Cita:
Empezado por keys (Mensaje 543613)
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 20-10-2021 10:59:09
Muchas gracias.

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

Gracias.

rci 20-10-2021 11:04:28
Cita:
Empezado por HerensugeBeltz (Mensaje 543609)
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.

Hola HerensugeBeltz, disculpa no habia visto tu respuesta. Muchas gracias también.


Ya utilizamos la clase X509Certificate2 y tenemos el certificado y lo asignamos al objeto HttpWebRequest. Por lo que se al asignarle el certificado le indicas cual tiene que utilizar y luego se va al almacén de certificados del usuario y busca si allí encuentra el certificado que le has indicado.



Si, ya leí que Microsoft no recomienda usar HttpWebRequest sino HttpClient :( pero me suena que al principio lo intentamos con HttpClient y no pudimos hacerlo y al final utilizamos HttpWebRequest.



Ahora estoy intentando algo y creo que me va a funcionar. cuando lo confirme lo comparto.


Saludos y muchas gracias

elcharlie 20-10-2021 11:05:56
Cita:
Empezado por keys (Mensaje 543617)
Muchas gracias.

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

Gracias.
Siempre hay que usar serie de factura. Eso creo yo
Ahora mismo el único error que me dá es al reemplazar el símbolo + de la url por %2B, que me supongo que todavía no lo tendrán controlado.

hago_preguntas 20-10-2021 11:10:11
Cita:
Empezado por keys (Mensaje 543613)
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
Lo de la barra / al final, debe ser simplemente si la url que lleva a la factura la tiene o no, pero el cálculo es el mismo para todos (respetando el orden de los parámetros y haciendo codificación url de los mismos) en la url de pruebas si la tiene y debería de ir en el cálculo del crc y en la de producción aparentemente no la tiene y no debería de ir, es lo que yo entiendo.

HerensugeBeltz 20-10-2021 11:11:28
Cita:
Empezado por elcharlie (Mensaje 543619)
Siempre hay que usar serie de factura. Eso creo yo.
Según la documentación, la serie es opcional. Entiendo que sólo es obligatoria en determinados casos (por ejemplo lo comentado recientemente en este foro: se te cae el sistema y emites las facturas a mano. Una vez solucionado el problema das de alta esas facturas con una serie especial).

Corregidme si me equivoco.

hago_preguntas 20-10-2021 11:23:09
Según el fichero xsd, es opcional:

Cita:
<complexType name="CabeceraFacturaType">
<sequence>
<element name="SerieFactura" type="T:TextMax20Type" minOccurs="0"/>
<element name="NumFactura" type="T:TextMax20Type"/>
<element name="FechaExpedicionFactura" type="T:FechaType"/>
<element name="HoraExpedicionFactura" type="T:HoraType"/>
<element name="FacturaSimplificada" type="T:SiNoType" minOccurs="0"/>
<element name="FacturaEmitidaSustitucionSimplificada" type="T:SiNoType" minOccurs="0"/>
<element name="FacturaRectificativa" type="T:FacturaRectificativaType" minOccurs="0"/>
<element name="FacturasRectificadasSustituidas" type="T:FacturasRectificadasSustituidasType" minOccurs="0" />
</sequence>
</complexType>
y la documenentación de las especificaciones funcionales indica:
Cita:
Serie de la factura.
 Clave: s
 Valor: serie de la factura según la normativa de facturación. Debe corresponder con
la serie incluida en el fichero TBAI (campo “SerieFactura”).
Quizás haya que poner el valor en blanco algo como:
Cita:
&s

keys 20-10-2021 11:31:40
Cita:
Empezado por elcharlie (Mensaje 543619)
Siempre hay que usar serie de factura. Eso creo yo
Ahora mismo el único error que me dá es al reemplazar el símbolo + de la url por %2B, que me supongo que todavía no lo tendrán controlado.
Como dicen los compañeros lo normal es no tener serie de factura y por eso es opcional. Sólo en determinados casos hay que usar serie en las facturas.

keys 20-10-2021 11:34:53
Cita:
Empezado por hago_preguntas (Mensaje 543622)
Según el fichero xsd, es opcional:



y la documenentación de las especificaciones funcionales indica:


Quizás haya que poner el valor en blanco algo como:
Estoy haciendo lo mismo que en resto de las haciendas cuando no hay serie. Es decir dejarlo en blanco &s=&nf=

espinete 20-10-2021 11:44:01
Cita:
Empezado por unomasmas (Mensaje 543600)
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...
Gracias por la aclaración. Estaba acostumbrado a la factura electrónica de algunos países de Latinoamérica y, como ellos no requieren el "encadenamiento" me estaba liando intentando hacerlo igual con Ticketbai.

No obstante, me surge entonces otra duda... Si la generación y firma del XML hay que hacerla en el momento de hacer la venta (ya que se necesita el QR para imprimirlo en la factura o tícket), PERO el envío puede ser ahora o dentro de unos días... ¿debo entonces guardar en algún sitio el XML firmado, ya que me hará falta para adjuntarlo al XML del envío de facturas, no?

Me refiero a Bizkaia, pero supongo que se aplica también a Gipuzkoa y Araba, ya que pueden ocurrir errores de conexión, etc. y necesitemos hacer los envíos más adelante.

En el envío, sea de la provincia que sea, se necesita el XML firmado de la factura. Si el envío se puede hacer en cualquier otro momento, independientemente de la firma, necesitaré ese XML a posteriori, por lo que en algún sitio habrá que guardarlo, no?

No es un poco locura almacenar los XML de (presumiblemente) miles de facturas, ya sea en archivos sueltos o en la propia base de datos?

elcharlie 20-10-2021 11:54:59
Cita:
Empezado por keys (Mensaje 543624)
Estoy haciendo lo mismo que en resto de las haciendas cuando no hay serie. Es decir dejarlo en blanco &s=&nf=
Desconocía el dato, gracias por la aclaración, siempre se aprende algo. La verdad es que me hubiera ido bien saberlo antes, pero bueno, ya lo tenemos puesto para que siempre envíe serie. Aun así, alguien ha probado a generar el QR con los caracteres %2B? porque a mi esos son los que me da error. Error que no me dá en las otras diputaciones.

adolphsys 20-10-2021 13:15:04
La comprobación QR en Araba ya funciona
 
Ya pueden comprobarse las facturas subidas a Araba en el entorno de pruebas, y no es necesario suprimir el slash final de la URL para el cálculo del CRC, o sea funciona como Vizcaya y Guipúzcoa.

keys 20-10-2021 13:51:40
Cita:
Empezado por adolphsys (Mensaje 543628)
Ya pueden comprobarse las facturas subidas a Araba en el entorno de pruebas, y no es necesario suprimir el slash final de la URL para el cálculo del CRC, o sea funciona como Vizcaya y Guipúzcoa.
Pruebalo con un factura sin serie.

edari 20-10-2021 14:03:03
Pues efectivamente ya funciona



Cita:
Empezado por keys (Mensaje 543629)
Pruebalo con un factura sin serie.

https://pruebas-ticketbai.araba.eus/...=280.74&cr=189

keys 20-10-2021 14:03:43
Me contestan esto de hacienda de alava.

Cita:
Os confirmamos que teníamos problemas en la consulta de facturas sin informar la serie. Por favor, probarlo de nuevo porque ya debería estar solucionado.
Ahora ya funciona bien tanto con serie como sin serie.

edari 20-10-2021 14:15:00
Cita:
Empezado por keys (Mensaje 543629)
Pruebalo con un factura sin serie.



Funciona unos sí y otros no :eek::eek:


Be patient

Creo que el problema, el mío, me salen mal los QR que añado yo el %2B

David M 20-10-2021 15:44:39
Cita:
Empezado por edari (Mensaje 543632)
Funciona unos sí y otros no :eek::eek:


Be patient

Creo que el problema, el mío, me salen mal los QR que añado yo el %2B
A mí tampoco me funciona si contiene %2F ("/")

elcharlie 20-10-2021 16:13:17
Cita:
Empezado por David M (Mensaje 543633)
A mí tampoco me funciona si contiene %2F ("/")
Yo en la url el único carácter que reemplazo es el símbolo + por %2B, con el símbolo / no he tenido ningún problema en las demás diputaciones.

edari 20-10-2021 16:43:16
Cita:
Empezado por David M (Mensaje 543633)
A mí tampoco me funciona si contiene %2F ("/")



Contestado



Buenas tardes edari,


El CRC lo habéis calculado sobre https://pruebas-ticketbai.araba.eus/...00988&i=189.35 y https://pruebas-ticketbai.araba.eus/...00989&i=176.16
Debéis de generarlo sobre https://pruebas-ticketbai.araba.eus/...00988&i=189.35 y https://pruebas-ticketbai.araba.eus/...00989&i=176.16
Si los generáis como os indico, manteniendo los caracteres del Identificativo TicketBAI sin codificarlos, os funciona correctamente:​Un saludo.





Y efectivamente funciona.


p.d.
Tanto costaba ir de la mano con Guipuzcoa con esto? Vizcaya no sé como va porque todavía no he podido subir nada

David M 20-10-2021 16:47:40
Cita:
Empezado por elcharlie (Mensaje 543634)
Yo en la url el único carácter que reemplazo es el símbolo + por %2B, con el símbolo / no he tenido ningún problema en las demás diputaciones.
Anda! Pues tienes razón!
En Álava si no reemplazo el símbolo / por %2F me muestra la consulta del QR perfectamente.
He probado de las dos formas en Gipuzkoa y me acepta tanto con la / como con %2F.
Yo creo que al principio no aceptaba la / y por eso lo tengo programado así.
Esperaré a ver si al final admiten las dos formas en Álava también.

Gracias elcharlie!

David M 20-10-2021 16:50:58
Cita:
Empezado por edari (Mensaje 543635)
Contestado


Y efectivamente funciona.


p.d.
Tanto costaba ir de la mano con Guipuzcoa con esto? Vizcaya no sé como va porque todavía no he podido subir nada
Vaya tela...
Gracias por compartir la explicación.

APO 20-10-2021 17:21:14
Hola a todos, soy otra "víctima" :confused: del TicketBAI que estoy empezando a encontrarme con los primeros problemas. Ante todo, agradeceros a todos por las aportaciones en este foro ya que son de muchísima ayuda ^\||/qP:-)

El primer problema que me encuentro es cómo cargar los certificados en la constante ACertificateList de la función NetHTTPClient1NeedClientCertificate. He leído en algún post anterior que lo hace el procedimiento DoGetClientCertificates, pero ¿cómo lo hago para llamar a este procedimiento? Perdonar mi ignorancia, pero es que estoy muy verde en todo este asunto. El error que me da al enviar el XML es "Empty certificate list", supongo porque tengo que cargar el certificado primero.
Código Delphi [-]
procedure TfrmEnvelm.NetHTTPClient1NeedClientCertificate(const Sender: TObject; const ARequest: TURLRequest; const ACertificateList: TCertificateList; var AnIndex: Integer);
var
  i: Integer;
begin
  for i := 0 to ACertificateList.Count - 1 do
  begin

    if SameText(ACertificateList[i].Subject, mi_certificado.Caption) then
    begin
      AnIndex := i;
      break;
    end;
  end;
end;
Muchas gracias!!!:)


La franja horaria es GMT +2. Ahora son las 12:14:48.
Página 49 de 114 « Primero < 39464748 49 5051525999 > Último »
Mostrar 40 mensajes desde este tema en una página

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi