Eso nos pasó a nosotros y también nos volvimos locos, hasta que al final tuvimos que llamar y hablar con ellos.

LA EXPLICACION: (agarraros que vienen curvas...)

NO VALIDAN TODAS las facturas que emiten un programa. Para que el servidor no se sobrecargue, cuando un mismo programa envía facturas, validan una de cada X. Dicho tal cual.:eek:

Os pongo la captura del correo:


Vamos, que tenemos un servidor de pruebas "para probar", pero resulta que no te puedes fiar de las pruebas porque lo que te contesta es "aleatorio". :(:o:confused:

WTF!!!!!

Madre mía!!!! entonces tengo que SUPONER que todas las que envío con caracteres raros están mal.......

Alguien que trabaje con Chilkat y que me pueda dar algo de luz sobre esto? doy por hecho que en algún momento el fichero firmado cambia de codificación, pero en todo momento y todas las comprobaciones que hago no veo diferencia alguna!

Gracias!

Seguramente.

Yo empezaría por comprobar que todas las funciones de lectura/grabación del fichero XML, antes y después de firmar, tengan asignada la codificación UTF8 (por ejemplo SaveToFile(..., TEncoding::UTF8), ya que de no especificarla el fichero podría grabarse en ANSI (TEncoding::Default).
A ver si te sirve de ayuda.

Y entre firmar y enviar.

El entorno de PREPRODUCCION de Batuz (Vizcaya) me está dando como "caído".
¿Me pasa sólo a mi? ¿A Alguien más?

Más madera !
 

KONTSULTA zerbitzua PREn / Servicio KONTSULTA en PRE
Me acaba de llegar un mail desde Guipuzkoa con un nuevo servicio REST para consutas (pruebas), he rezado para que fuera Spam ..., pero no

En mi caso, cuando empecé las pruebas en Guipuzkoa, en Alava no me pasó, y de manera aletoria ( que es como ya han comentado que aplican los filtros a la llegada), me daba ese error y fue por el componente de envío de las INDY, parece ser que por defecto convertía a UTF8 (de nuevo , porque ya lo había convertido yo previamente) y el fichero xml que tenía guardado no era el mismo que se enviaba, tuve que desactivar el encoding de las INDY igualando la propiedad correspiente al encoding a "".


Para poder comprobrarlo creamos una pagina en php en un servidor web de la red local para que recibiera el fichero XML y poder compararlo que el que creaba la aplicación, y sí, eran diferentes hasta que desactivamos el 'encoding' del componente para envío (INDY).

Si necesitas algo más concreto de alguno de los puntos (configuración INDY o pagina php de recepción) me avisas.

Actualizado en mensaje #1 de resumen con el link.
Añadida la documentación al FTP en la carpeta correspondiente.

Desde hace meses les he pedido un servicio así para ver el estado real de las facturas durante el desarrollo, y ahora a falta de 25 días lo activan.

Más vale tarde.....

Este servicio me hace preguntarme una vez más el por qué de tener que enviar el encadenamiento de factura, si ya saben cuál es la última factura enviada.... ¿más datos para asegurar que un tercero no envía facturas en nuestro nombre?... Ni idea...

En nuestro caso, ya que habéis comentado soluciones, lo que hicimos fue grabar el XML en haxadecimal a disco, después de determinados pasos que íbamos ejecutando (incluyendo en el XML caracteres con acentos).
En un momento dado entre 2 pasos (manipulando Streams concretamente) nos dimos cuenta de que cambiaba la codificación (1 de los caracteres cambiaba su codificación en haxadecimal).

Hola a tod@s, ¿Os esta funcionando el servicio de envío de facturas de Gipuzkoa de Pruebas?,
es que llevo toda la mañana sin poder enviar nada.... y ya no sé si es algo mío, o el problema es de ellos.

Es Su Problema
 

Hola, es su problema, a mi lo único que me funciona es el nuevo servicio de consulta de facturas

Saludos

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>06-10-2022 11:42:01</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado - ZUZENDU PREP</Descripcion>
<Azalpena>Baztertua - ZUZENDU PREP</Azalpena>
<ResultadosValidacion>
<Codigo>006</Codigo>
<Descripcion>El servicio de recepción no está disponible. Repita la operación más tarde</Descripcion>
<Azalpena>Jasotze zerbitzua ez dago erabilgarri. Egin berriro eragiketa geroago</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

A mi me da error también, está caido.... ¿¿entraria en KONTflicto con el nuevo servicio KONTsultas?? :D:D

Seguro
 

:cool::cool::cool: Fijo que sí

Ok, Gracias, ya me estaba volviendo loco

Desde ayer que lo comenté aquí, parece que está caído.
Ya estaba pensando que era algo sólo mio.

Perdona tío, no había leído tu mensaje. Ya puedes perdonar...

No pasa nada. :p
Yo tamboién paso ratos que me "desconecto" del tema, que al final tenemos otras cosas que hacer...

Es su problema
 

Ya funciona el entorno de pruebas.

SI, eso parece. Gracias.

Timeout?
 

A nosotros no nos responde, hasta ayer iba bien, pero hoy no responde :(

He vuelto a probar ahora mismo y sí me contesta.
^\||/

Si te sigue fallando, ¿Qué URL estás utilizando?

estamos usando esta URL
 

Buenas tardes, estamos usando esta URL https ://tbai-z.prep.gipuzkoa.eus/sarrerak/alta (separo pq el foro no me deja poner URLs :(

Código Delphi [-]
[
  URL_ALTA_GIPUZKOA_PRUEBAS = 'https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta';
  URL_ALTA_GIPUZKOA_PRODUCCION = 'https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/alta';
  URL_ANULACION_GIPUZKOA_PRUEBAS = 'https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/anulacion';
  URL_ANULACION_GIPUZKOA_PRODUCCION = 'https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/baja';

  URL_ALTA_ZUZENDU_GIPUZKOA_PRUEBAS = 'https://tbai-z.prep.gipuzkoa.eus/sarrerak/zuzendu-alta';
  URL_ALTA_ZUZENDU_GIPUZKOA_PRODUCCION = 'https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/zuzendu-alta';
  URL_ANULACION_ZUZENDU_GIPUZKOA_PRUEBAS = 'https://tbai-z.prep.gipuzkoa.eus/sarrerak/zuzendu-baja';
  URL_ANULACION_ZUZENDU_GIPUZKOA_PRODUCCION = 'https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/zuzendu-baja';

  URL_OSATU_GIPUZKOA_PRUEBAS = 'https://tbai-z.prep.gipuzkoa.eus/sarrerak/osatu';
  URL_OSATU_GIPUZKOA_PRODUCCION = 'https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/osatu';

  URL_CONSULTAS_FACTURAS_GIPUZKOA_PRUEBAS = 'https://tbai-k.prep.gipuzkoa.eus/kontsulta/fakturak';
  URL_CONSULTAS_FACTURAS_GIPUZKOA_PRODUCCION = 'https://tbai-k.egoitza.gipuzkoa.eus/kontsulta/fakturak';  { TODO : Poner la Url Real de Produccion }
  URL_CONSULTAS_ULTIMA_FACTURA_GIPUZKOA_PRUEBAS = 'https://tbai-k.prep.gipuzkoa.eus/kontsulta/azkena';
  URL_CONSULTAS_ULTIMA_FACTURA_GIPUZKOA_PRODUCCION = 'https://tbai-k.egoitza.gipuzkoa.eus/kontsulta/azkena'; { TODO : Poner la Url Real de Produccion }

Estas son las urls de Gipuzkoa que estoy usando, y a mi me esta funcionando

Tema resuelto, me he cargado todos los saltos de linea antes de firmar el fichero y listo

Joder con Vizcaya
 

Vaya tela con Vizcaya, el que mas me está costando con diferencia .. ahora no me aceptan el fichero gz porque dicen que en la cabecera del envío el parametro "Content-Length" no coincide con el tamaño del fichero ... el caso es que lo envío por CURL y no especifico el parámetro "Content-Length" en la cabecera (entre otras cosas porque no he visto que nadie lo haga revisando los mensajes de los que enviais por CURL en el foro) por lo que debe añadirlo CURL por defecto

Muchas gracias a todos por vuestra ayuda!

Finalmente vimos que no era problema de las URLs, ya que haciendo el envío desde otros servidores funciona correctamente. Hemos escrito a soporte pues parece que se trata de algún tipo de bloqueo a nuestra IP. Os seguiré contando!

:confused: Me tienes sobre ascuas. No nos dejes sin el final.

Hola a todos.

Un chascarrillo. Tenemos un cliente que esta enviando datos a Bizkaia, es un comercio que esta enviando Tickets, envia unos 1000 tickets al día, lleva ya dentro de ticketbai un tiempo.

Al entrar en la página web de la hacienda para ver las facturas presentadas y se le bloquea todo, no hay forma de entrar a consultar nada, etcc. Llama a hacienda y le constestan que es que tiene un gran volumen de datos y por eso no le funciona nada. Y le dicen que el no puede entrar a la web de hacienda.

Me pregunto que me pasaría si le digo y eso a un cliente :rolleyes:

Pues que te despedirían como proveedor .. pero como no puede "despedir" a la administración (ya nos gustaría) pues le toca resignarse jaja.

Imagino que a la larga funcionará bien, pero quizás no dimensionaron correctamente lo que todo esto podría suponer.

Están pensando también hacer algo parecido a nivel nacional, a ver qué pasa entonces!

No se si reir o llorar...

A nivel nacional riete tu de la bomba de Putin .. en fin, ya veremos.

Por cierto, veo que tu cliente envía a Vizcaya sin problemas, yo estoy teniendo problemas al enviarles por CURL, la respuesta es "error al descomprimir el fichero" y soporte me dice que es por que el Content-Length no coincide con el tamaño del fichero, pero leñe, yo no envío el Content-Lenght, lo hace Curl (supongo) al hacer el envío con el fichero ... ahí me he quedao.

Creo que a alguien le pasaba algo así y era porque el XML se enviaba con/sin saltos de línea, o algo de caracteres

Hola todos.

Alava a enviado una comunicación indicando que van a poner en marcha el servicio OSATU. Además de cambiar el sistema de comunicación con ellos.

Consulta Gipuzkoa
 

Buenas, ¿os funciona el servicio de consulta de Gipuzkoa?

Lleva varios días respondiendo un 503 Servicio no disponible.

Problema al generar código QR
 

Hola

Tengo problemas al generar los qr cuando al firmar el xml me aparece un signo + en os primeros caracteres de SignatureValue

...id=TBAI-14894343A-081022-Wx+Royp0h3nOY-210&s=FAC&nf=100019&i=1.62&cr=064...

He consultado con los de soporte de la Bfa, pero no entiendo la respuesta. Si simplemente cambio el + por %2B me sigue dando error. En los demás casos funciona bien y ya tengo la aplicación en producción.



Egun on,
Nos ponemos en contacto con usted porque hemos recibido a través de la aplicación “Comprueba tu factura”, la imagen de una factura emitida por usted cuyo código QR da error de lectura.
En este sentido, le informamos que el código QR debe contener una URL válida para acceder a la aplicación web de comprobación de facturas o justificantes expedidos con software garante con los datos de la factura o justificante incluidos como parámetros. Si la URL o sus parámetros contienen caracteres no válidos, deberán ser codificados (URL encoding) de forma correcta siguiendo los usos normales de las arquitecturas web, como por ejemplo reemplazar el símbolo “+ ” por “%2B” o el símbolo “/” por “%2F”.

En este mismo hilo ya hemos hablado de este problema:
https://www.clubdelphi.com/foros/sho...=94264&page=98
https://www.clubdelphi.com/foros/sho...ument&page=117
https://www.clubdelphi.com/foros/sho...94264&page=100
(si buscas hay alguna más...)


Desde el foro no permite buscar por “%2F” o “%2B” porque la palabra es corta, pero si haces la búsqueda desde Google te lleva a algunos hilos:
https://www.google.com/search?client...hi+%22%252F%22

No hay manera con Vizcaya
 

Joer que dessesperación llevo con Vizcaya,

La respuesta al enviar siempre es "ERROR AL DESCOPRIMIR EL FICHERO", tras comprobar que el fichero es correcto el servicio de soporte me dice que el problema es que el parámetro CONTENT-LENGTH de la cabecera no coincide con el tamaño del fichero, lo he comprobado y efectivamente el tamaño nunca coincide y si le pongo el CONTENT-LENGTH a mano como parámetro no funciona.

Por tanto el problema debe estar en el comando CURL .. lo pongo a ver si alguien ve algún problema en el:



Gracias.