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

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

Empezado por trumbolt

Cuando tenga permisos para publicar urls, también las añadiré para tenerlo todo en el mismo sitio ...

He actualizado en el mensaje 1 del hilo, las que pusimos aquí.
Revisa que sean las mismas que tú tienes y que sean corectas.

[keys]

Hola a todas.

Deciros que hacienda de bizkaia ya ha habilitado el envio de los suplidos/provisiones en el 140 de producción.

Por otra parte ayer me dieron dos tickets con el codigo QR de Bizkaia, uno en una panaderia y otro en una farmacia. Los dos estaban mal, uno solo contenía el TBAI, no la dirección de hacienda y otro un número que no se veía que era. Por si estais por aqui.

[tejano]

No sé si os ha llegado esta noticia https://www.elcorreo.com/economia/bi...212421-nt.html

Al final nos piden a nosotros que hagamos el trabajo pero ellos siempre lo retrasan.

[Nessie]

Empezado por edari

Acabo de hacer una prueba y me la anula correctamente.

Lo raro es que te dé error de dispositivo remitente para la anulación y no para la alta.

Hola,

me han contestado de Gipuzkoa. Lo pongo aquí por si a alguien le sirve de ayuda. En pruebas, al utilizar un certificado de dispositivo, hay que mandarles un mail para registrar el dispositivo. En las operaciones de ANULACION, controlan que el dispositivo este registrado.

Un saludo.


RESPUESTA DE HACIENDA GIPUZKOA:

-----------------------------------------------------------------------------

Egun on, buenos días
Esto ocurre porque el control en la Anulación de facturas es más restrictivo que en el Alta de facturas.

Para solucionar este error en el entorno de pruebas, deben enviar un correo a este mismo buzón indicando que quieren registrar un dispositivo. Anoten los siguientes datos en el mensaje:

• NIF del emisor
• Número de serie del dispositivo

--------------------------------------------------------------------------

[sEngine]

Email nuevo enviado por Alava

Buenos días,

Les informamos de la implantación en PRODUCCIÓN de los servicios rest correspondientes a ZUZENDU.
ZUZENDU-ALTA: https://ticketbai.araba.eus/TicketBA...sanarmodificar
ZUZENDU-ANULACIÓN: https://ticketbai.araba.eus/TicketBA...ulaciones/baja

Tenéis disponible la documentación sobre ZUZENDU en Documentación técnica (araba.eus)/Pruebas Servicios Zuzendu.

Es importante distinguir entre ZUZENDU, factura rectificativa y anulación de factura.
Ver preguntas frecuentes 8.9: FAQ TiCKETBAI ÁLAVA (araba.eus)

8.9 ¿QUÉ HAY QUE HACER SI LA ANOTACIÓN DEL FICHERO TICKETBAI HA SIDO RECHAZADA AL ENVIARSE A HACIENDA?
❖ Si el envío del fichero TicketBAI ha sido RECHAZADO al enviarse a Hacienda por incumplimiento de esquema, ausencia de líneas de detalle, certificado no válido, falta de datos obligatorios, deberá SUBSANAR el error del siguiente modo:

• El fichero TicketBAI original no se puede modificar, por lo que permanecerá inalterado.
• A través del Servicio ZUZENDU, se procederá al envío de un nuevo fichero de SUBSANACIÓN, ya con los datos completos y correctos, que NO será firmado electrónicamente, y en el que se deberá incluir la firma electrónica del fichero original.

❖ Si en el mensaje de respuesta se reciben AVISOS indicando que es preciso modificar el envío (se trata de datos que no figuran en la factura pero que afectan exclusivamente al fichero XML, como por ejemplo: una incongruencia del régimen de IVA, no se han identificado las facturas rectificadas, etc.), a través del mismo Servicio ZUZENDU, deberá enviar un fichero de MODIFICACIÓN, ya con los datos completos y correctos, que NO será firmado electrónicamente, y en el que se deberá incluir la firma electrónica del fichero original.
❖ Si, por el contrario, hay que modificar alguno de los contenidos de la factura a que se refiere el artículo 15 del Reglamento de facturación, no se podrá utilizar el servicio ZUZENDU sino que se deberá expedir una factura rectificativa, generando el fichero TicketBAI correspondiente y remitiendo la información.
❖ Extraordinariamente, cuando se trate de una operación incorrecta (casos excluidos de poder emitir una factura rectificativa), como por ejemplo que se haya expedido una facturar por error cuando no ha habido una auténtica venta, deberá realizarse una anulación de la operación original procediendo a emitir un Fichero TicketBAI de ANULACIÓN.
❖ En el caso de que el envío del fichero de ANULACIÓN sea RECHAZADO, por incumplimiento de esquema, certificado no válido, etc., deberá SUBSANAR el error del siguiente modo:

• El fichero de ANULACIÓN original no se puede modificar, por lo que permanecerá inalterado.
• A través del Servicio ZUZENDU-ANULACIÓN, se procederá al envío de un nuevo fichero de anulación, ya con los datos completos y correctos, que NO será firmado electrónicamente, y en el que se deberá incluir la firma electrónica del fichero original.

Un saludo.

[trumbolt]

Empezado por Sistel

Hola,

Para mí, lo importante es que se pueda seguir facturando en cualquier caso y contra viento y marea.
Se van generando los XML, se van firmando, se van generando los códigos TBAI y QR y se van imprimiendo las facturas.

El tema del envío a la Hacienda Foral correspondiente creo que no es tan vital.
Pero no puedo dejar parado el TPV de una panadería, por ejemplo, porque no funcione el servicio de recepción de facturas de Hacienda Foral o porque haya un problema de Internet.

Los ficheros XML firmados se van poniendo en cola y un cronjob los va enviando a medida que se puede.
Si luego Hacienda Foral sale con cualquier mensaje de error de que no traga con la factura, ya es cuestión de LROE facturas emitidas sin software garante en Bizkaia, Zuzendu en Gipuzkoa o Alavazendu (o como le quieran llamar cuando lo inventen) en Álava.

Saludos

Perdonad que resucite un post de hace 3 meses pero estabais hablando de un tema del que tengo algunas dudas.

Está claro que lo importante para el cliente es seguir facturando independientemente de si tiene o no conexión en ese momento para el envío de las facturas así que nuestro software genera el xml, lo firma, genera el identificador, el QR e imprime. Y luego ya añade el xml a una cola y trata de enviarlo cuando pueda.

La única excepción a este comportamiento es si detectamos que el certificado de firma ha caducado. En ese caso, sabiendo que la factura va a ser rechazada (porque va a ser rechazada por el servicio, ¿verdad? - no tengo medios para probar ésto, la verdad - ), no le dejo facturar e imprimir, es decir, activamos una restricción para que el software continúe emitiendo facturas (y así el cliente puede seguir operando) pero sin la posibilidad de impresión (así no habrá facturas sin identificador TBAI ni QR por el mundo). Luego, cuando actualicen el certificado, podrán generar todos esos xml sobre las facturas no impresas, firmarlas y enviarlas. Creo que es una solución interesante que no me parece que rompa el reglamento y además es lo único que se nos ha ocurrido para evitar posibles errores a la hora de subir la factura. Se admiten otras ideas

Bueno dicho ésto, el tema de la gestión de los errores me trae por la calle de la amargura. ¿Qué pasa si tengo tres facturas en cola (F1, F2, F3) y la primera (F1) es rechazada por cualquier motivo?. ¿Entiendo que el resto no se pueden subir hasta que suba esa primera que actúa como un "tapón", verdad?. Si la subsanación de esa factura para que sea "aceptada" por el servidor tbai implica hacer cambios en la misma, habría que volver a firmarla y se iría a tomar por saco el encadenamiento con el resto de las facturas posteriores (F2 y F3) y cambiaría el identificador TBAI y el QR de esas facturas que ya están impresas y con los clientes finales. Vamos un problemón. ¿Cómo lo estáis enfocando vosotros?. Necesito otras visiones porque me pongo cardíaco.

Otra cosa es que la factura sea aceptada y luego el servicio ya te devuelva advertencias o errores que habrá que subsanar entiendo que con Zuzendu, pero eso ya es otra guerra que irá después de ésta. Las cosas secuencialmente y paso a paso

Muchas gracias.

[trumbolt]

Empezado por sEngine

Email nuevo enviado por Alava

Ostras, precisamente estaba dándole vueltas justo a este tema en mi mensaje anterior

Por lo que entiendo, TODO lo enviado ya no se puede tocar, sea aceptado o rechazado por lo que no se pueden generar "tapones" en el envío de ficheros y el encadenamiento de todas las facturas no tendrá ningún problema porque esas facturas nunca se va a poder modificar. ¿Esto es así en TODAS las diputaciones o sólo en Alava? Lo digo porque parece que cada uno hace la guerra por su cuenta.

Y pregunto, si la factura TBAI ha sido rechazada por ejemplo, por un certificado inválido o porque se ha consignado mal el has de la política de firma, por ejemplo, Zuzendu va a "tragar" siempre porque no se firma digitalmente. Otra cosa es que tengamos fallos en el esquema o no se haya consignado algún campo obligatorio ...

En el "Listado de validaciones y errores del fichero de ALTA TicketBAI" de Alava, pone lo siguiente:

3- VALIDACIONES
VALIDACIONES DE RECEPCIÓN:
o Para validar los datos que se informan a nivel de petición al servicio, y que la estructura de etiquetas cumple el esquema en cuanto al orden,
obligatoriedad, formato, longitud y si el valor debe coincidir con una serie de valores preestablecidos, en los casos que aplique.
o La no superación de las validaciones de recepción produce siempre el rechazo del fichero.
o La superación de las validaciones de recepción conlleva que el fichero sea recibido, aunque se pueden producir errores asociados a las validaciones
de consolidación del apartado siguiente.

Entiendo entonces que el rechazo del fichero por un fallo en las validaciones de recepción no es en realidad un rechazo "de mentira" porque la factura queda de alguna manera dentro del sistema (no me imagino la manera si el problema es de fallos en el esquema, por ejemplo), ya no se puede enviar de nuevo y hay que tirar de Zuzendu y la subsanación, ¿correcto?.

Cuando hablan de la firma de la factura original, entiendo que se refieren al nodo <SignatureValueFirmaFactura> que va con los 100 primeros caracteres de la forma, ¿no?

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

Empezado por trumbolt

La única excepción a este comportamiento es si detectamos que el certificado de firma ha caducado. En ese caso, sabiendo que la factura va a ser rechazada (porque va a ser rechazada por el servicio, ¿verdad? - no tengo medios para probar ésto, la verdad - )

En su día se dijo que dejarían un "periodo de gracia" para poder corregir este tipo de errores.
Segun eso, te admitirán las facturas, pero te darán un mensaje de aviso y un tiempo prudencial (unos días) para que instales los nuevos certificados.

Empezado por trumbolt

...que el software continúe emitiendo facturas (y así el cliente puede seguir operando) pero sin la posibilidad de impresión (así no habrá facturas sin identificador TBAI ni QR por el mundo). Luego, cuando actualicen el certificado, podrán generar todos esos xml sobre las facturas no impresas, firmarlas y enviarlas.

Diría que justo eso es lo que no quieren que se haga.
Esa "factura" de la que nos has generado XML, firmado,... es modificable. Justo esa situación es la que no quieren.
Según dicen, las facturas deben enviarse "lo antes posible".
Si te pasas 2 días generando facturas, sin firmar, sin encadenar,... y al cabo de 2 días (cuando tienes los certificados) las envías todas juntas no creo que les haga mucha gracia.

Yo creo que debrías generar las facturas, el XML, firmarlas, enviarlas, generar los "encadenamientos correlativos" (aunque las rechaze) y luego cuando tengas los certificados correctos enviarlas de nuevo corregidas o con los métodos alternativos que proveen las diferentes diputaciones.

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

Empezado por trumbolt

(1) ¿Qué pasa si tengo tres facturas en cola (F1, F2, F3) y la primera (F1) es rechazada por cualquier motivo?. ¿Entiendo que el resto no se pueden subir hasta que suba esa primera que actúa como un "tapón", verdad?.

(2) Si la subsanación de esa factura para que sea "aceptada" por el servidor tbai implica hacer cambios en la misma, habría que volver a firmarla y se iría a tomar por saco el encadenamiento con el resto de las facturas posteriores (F2 y F3) y cambiaría el identificador TBAI y el QR de esas facturas que ya están impresas y con los clientes finales. Vamos un problemón. ¿Cómo lo estáis enfocando vosotros?. Necesito otras visiones porque me pongo cardíaco.

(3) Otra cosa es que la factura sea aceptada y luego el servicio ya te devuelva advertencias o errores que habrá que subsanar entiendo que con Zuzendu, pero eso ya es otra guerra que irá después de ésta. Las cosas secuencialmente y paso a paso

(1) Aunque una factura sea rechazada el encadenamiento sigue valiendo, y debes enviar las siguientes encadenadas con la que te han rechazado.
Son cosas distintas.
Ellos tendrán las tres facturas encadenadas de forma correcta, pero la F1 será rechazada.
Más adelante ya enviarás la F1 de nuevo por los métodos alternativos (ZUZENDU) o otros libros en el caso de BATUZ.

(2) Los servicios de modificación (tipo ZUZENDU) o los envíos en otros libros en BATUZ se suelen hacer sin firma, justo para no tener problemas con los encadenamientos. La factura original ya está firmada, encadenada y almacenada y la "subsanación" será enviar una serie de datos "extra" para corregir la original, pero esos envíos de subsanación no van firmados ni llevan encadenamiento.
(para que te hagas una idea)

(3) Hay advertencias que no necesariamente te obligan a reenviar. Algunos son avisos. Por ejemplo, el comentado anteriormente del certificado. Te pueden avisar de que el certificado está caducado, pero te las aceptan.
El aviso te sirve para corregir el error, pero no debes enviarla de nuevo, porque la factura es si es correcta (sólo falla el certificado).

[trumbolt]

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

(1) Aunque una factura sea rechazada el encadenamiento sigue valiendo, y debes enviar las siguientes encadenadas con la que te han rechazado.
Son cosas distintas.
Ellos tendrán las tres facturas encadenadas de forma correcta, pero la F1 será rechazada.
Más adelante ya enviarás la F1 de nuevo por los métodos alternativos (ZUZENDU) o otros libros en el caso de BATUZ.

(2) Los servicios de modificación (tipo ZUZENDU) o los envíos en otros libros en BATUZ se suelen hacer sin firma, justo para no tener problemas con los encadenamientos. La factura original ya está firmada, encadenada y almacenada y la "subsanación" será enviar una serie de datos "extra" para corregir la original, pero esos envíos de subsanación no van firmados ni llevan encadenamiento.
(para que te hagas una idea)

(3) Hay advertencias que no necesariamente te obligan a reenviar. Algunos son avisos. Por ejemplo, el comentado anteriormente del certificado. Te pueden avisar de que el certificado está caducado, pero te las aceptan.
El aviso te sirve para corregir el error, pero no debes enviarla de nuevo, porque la factura es si es correcta (sólo falla el certificado).

Muchas gracias por la respuesta. Por lo que veo todo se ha retorcido por un fallo de comprensión de concepto. Siempre pensé que rechazado significada justo eso, que no les entraba en el sistema y que había que volver a reenviar una vez modificada. Pero resulta que no. Que todo llega pase lo que pase (bueno, a menos que su server esté "en mantenimiento", claro) y que si tanto hay errores en la recepción (fallo esquema, certificado, campos obligatorios) como en el procesado, luego hay que subsanar con Zuzendu, al menos en Guipúzcoa o Alava porque aún no me he puesto con Bizkaia, que por lo que me ha parecido ver por encima, es oootra historia diferente. Para qué unificarlo todo, ¿verdad?. Menos mal que son sólo tres y no 8 como en Andalucía.

Con ésto claro, lo que tiene más sentido, como bien comentas en el otro post, es generar siempre el xml, firmarlo y enviarlo aunque sepas que puede que haya algo mal (como la caducidad del certificado) porque luego ya lo corregirás con Zuzendu.

[Sistel]

Empezado por trumbolt

...es decir, activamos una restricción para que el software continúe emitiendo facturas (y así el cliente puede seguir operando) pero sin la posibilidad de impresión (así no habrá facturas sin identificador TBAI ni QR por el mundo). Luego, cuando actualicen el certificado, podrán generar todos esos xml sobre las facturas no impresas, firmarlas y enviarlas. Creo que es una solución interesante que no me parece que rompa el reglamento y además es lo único que se nos ha ocurrido para evitar posibles errores a la hora de subir la factura. Se admiten otras ideas

Hola trumbolt,

Como muy bien te indica nuestro colega Neftali, en ningún caso debes hacer eso.
Es lo que TicketBAI intenta evitar: que se puedan emitir facturas sin firmar y encadenar (que podrían ser borradas)

Ten en cuenta que, actualmente, es obligatorio SIEMPRE imprimir ticket de cualquier venta.
Tengo noticias de inspectores de Hacienda Foral de Bizkaia que se han colocado en la puerta de un comercio e iban preguntando a los clientes que salían si les habían dado ticket.
Si no les dan, ya sabes: Entran, se identifican y abren expediente.

Hay que imprimir siempre el ticket de la venta aunque el cliente no lo coja y vaya a la papelera.
Y eso ahora, antes de TicketBAI .... así que figúrate cuando TicketBAI sea obligatorio.

Saludos

[trumbolt]

Empezado por Sistel

Hola trumbolt,

Como muy bien te indica nuestro colega Neftali, en ningún caso debes hacer eso.
Es lo que TicketBAI intenta evitar: que se puedan emitir facturas sin firmar y encadenar (que podrían ser borradas)

Ten en cuenta que, actualmente, es obligatorio SIEMPRE imprimir ticket de cualquier venta.
Tengo noticias de inspectores de Hacienda Foral de Bizkaia que se han colocado en la puerta de un comercio e iban preguntando a los clientes que salían si les habían dado ticket.
Si no les dan, ya sabes: Entran, se identifican y abren expediente.

Hay que imprimir siempre el ticket de la venta aunque el cliente no lo coja y vaya a la papelera.
Y eso ahora, antes de TicketBAI .... así que figúrate cuando TicketBAI sea obligatorio.

Saludos

Todo claro entonces. Factura generada, firmada y encadenada siempre, haya o no errores que detectemos y no podamos evitar (como un certificado caducado).

Y un tema ya por curiosidad. Imaginemos que el certificado está caducado. Aún así se firma con él la factura y luego se envío. En la fase de recepción será rechazada (es una de las cosas que se comprueban) aunque como ya he aprendido, queda registrada en su sistema a la espera de una subsanación a través de Zuzendu en Gipuzkoa y Araba (y de LROE en Bizkaia aunque ya tendré que mirar cómo se hace eso). El problema es que, si es tema del certificado de firma y con Zuzendu no hay que firmar nada, ese error no se podría subsanar de ninguna manera, o al menos no se me ocurre cómo.

[Sistel]

Empezado por trumbolt

...El problema es que, si es tema del certificado de firma y con Zuzendu no hay que firmar nada, ese error no se podría subsanar de ninguna manera, o al menos no se me ocurre cómo.

Hola trumbolt,

Los servicios Zuzendu son para corregir los datos de las facturas, no los ficheros XML TicketBAI firmados.
Si el fichero está mal, pues lo está y punto. No se puede corregir.
Mediante Zuzendu, lo que haces es corregir los datos de esa factura (NIFs, bases imponibles, cuotas de IVA, ...) para que Hacienda Foral se quede tranquila y la considere como si hubiese llegado bien el XML firmado.

Saludos

[Ramon88]

Hola a todos!


Ya tenía todos los servicios funcionando, aun que ningun cliente quería estar en la fase de pruebas, y ahora les entran los nervios...
Lo dejé todo tal cual a fecha Diciembre de 2021


El único cambio ha sido la subsanación de fallos(zuzendu)?

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

Empezado por Ramon88

El único cambio ha sido la subsanación de fallos(zuzendu)?

Revisa se tengas actualizadas las políticas de firma:
https://www.clubdelphi.com/foros/sho...97&postcount=1 (a mitad del mensaje)

Los HASH de las políticas de firma (que si han cambiado):
https://www.clubdelphi.com/foros/sho...97&postcount=1 (debajo de las URL's)

[ikosoft]

Hola a toda la gente que colabora en este mágnífico foro.
Estamos en fase de pruebas enviando XML de alta y anulación en Álava y Guipuzkoa.



Necesitamos que alguien nos aclare de qué forma podemos usar un certificado "genérico" para integrarlo en nuestro software y que sirva para todas nuestros clientes.
Soporte de TBAI nunca nos dejan nada claro, hablan de certificado de usuario, de autónomo, de dispositivo....y siempre nos remiten a los certificados de test IZENPE.



Lo cierto que es agradeceríamos si alguien nos arroja algo de luz en este sentido, he leído algunos post comentando sobre certificados de software que se compran como los de ksoftware.net
* ¿serían la solución que andamos buscando?
* ¿es posible integrar nuestro certificado de empresa usando el parámetro<Factura emitida por tercero o destinatario> = T (Tercero) y sería correcto? en ese caso, ¿deben firmar nuestros clientes un consentimiento por enviar sus tickets firmados con nuestro certificado?



¡muchas gracias a todos!

[Sistel]

Empezado por ikosoft

Hola a toda la gente que colabora en este mágnífico foro.
Estamos en fase de pruebas enviando XML de alta y anulación en Álava y Guipuzkoa.



Necesitamos que alguien nos aclare de qué forma podemos usar un certificado "genérico" para integrarlo en nuestro software y que sirva para todas nuestros clientes.
Soporte de TBAI nunca nos dejan nada claro, hablan de certificado de usuario, de autónomo, de dispositivo....y siempre nos remiten a los certificados de test IZENPE.



Lo cierto que es agradeceríamos si alguien nos arroja algo de luz en este sentido, he leído algunos post comentando sobre certificados de software que se compran como los de ksoftware.net
* ¿serían la solución que andamos buscando?
* ¿es posible integrar nuestro certificado de empresa usando el parámetro<Factura emitida por tercero o destinatario> = T (Tercero) y sería correcto? en ese caso, ¿deben firmar nuestros clientes un consentimiento por enviar sus tickets firmados con nuestro certificado?



¡muchas gracias a todos!

Hola ikosoft,

Si quieres usar un mismo certificado digital para todos tus clientes, el método más adecuado es el que comentas: marcar el nodo <EmitidaPorTercerosODestinatario> con el valor T

Eso te permitirá usar, por ejemplo, tu certificado para firmar los ficheros XML.
Aunque para enviarlos (recuerda que se precisa certificado para ese envío) debes seguir el procedimiento de autorización que exige cada Hacienda Foral.
Entra en cada una de ellas y sigue el procedimiento que indiquen en su web.

Y lo lógico es que pidas a todos tus clientes que firmen un documento de autorización de que tú emitirás, firmarás y enviarás sus facturas en su nombre.

También es recomendable que tengas, al menos, 2 certificados (por ejemplo, uno de FNMT y otro de IZENPE) con distintas fechas de caducidad.
Cuando solicitas renovar un certificado, queda revocado el anterior, por lo que ya no podrás utilizarlo hasta que no tengas instalado el nuevo.
Cambiando de certificado, antes de solicitar la renovación del que venías utilizando, puedes seguir trabajando con el otro hasta que consigas el nuevo.

Saludos.

[ermendalenda]

Buenas tardes,
tengo una duda sobre la hora de grabación, ejemplo;
Emito una factura (numero 1) con hora de expedicion 14:00:00
Se actualiza la hora del sistema unos segundos por algún problema con la pila a las 13:59:45
Emito Factura numero 2 a las 13:59:55.

Sabeis si en los casos de no tener el orden cronologico de fecha expedicion exacto da alguna incidencia el sistema de recepcion de tiquetbai?

[joselugrk]

Hola,

Estoy haciendo pruebas de envíos de facturas a Bizkaia y todo iba bien hasta el miércoles que decidí enviar un paquete con 270 facturas. Al intentar el envío me dio el siguiente mensaje de Chilkat (parecido, este es del envío de prueba de hoy para ver si funcionaba).

ChilkatLog:
ReadResponseHeader:
DllDate: May 28 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 30000
Failed to receive more TLS application data.
tlsApp: Socket operation timeout.
elapsedMs: Elapsed time: 31281 millisec
Failed.
--ReadResponseHeader
--ChilkatLog

También he probado con paquetes mas pequeños y ha realizar consultas. Todo el rato lo mismo Socket operation timeout.

¿Sabe alguien si está pasando algo en el servidor de pruebas de Bizkaia? Les he enviado a los de Soporte de TicketBAI (Bizkaia) y todavía no me han contestado.
¿Alguna idea de que puede estar pasando?

Saludos y muchas gracias,
Joselu

[joselugrk]

Empezado por joselugrk

Hola,

Estoy haciendo pruebas de envíos de facturas a Bizkaia y todo iba bien hasta el miércoles que decidí enviar un paquete con 270 facturas. Al intentar el envío me dio el siguiente mensaje de Chilkat (parecido, este es del envío de prueba de hoy para ver si funcionaba).

ChilkatLog:
ReadResponseHeader:
DllDate: May 28 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 30000
Failed to receive more TLS application data.
tlsApp: Socket operation timeout.
elapsedMs: Elapsed time: 31281 millisec
Failed.
--ReadResponseHeader
--ChilkatLog

También he probado con paquetes mas pequeños y ha realizar consultas. Todo el rato lo mismo Socket operation timeout.

¿Sabe alguien si está pasando algo en el servidor de pruebas de Bizkaia? Les he enviado a los de Soporte de TicketBAI (Bizkaia) y todavía no me han contestado.
¿Alguna idea de que puede estar pasando?

Saludos y muchas gracias,
Joselu

Parece que ya lo han solucionado en Bizkaia.

Muchas gracias,
Joselu