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

[Maska10]

Buenas a tod@s,

Ala, pues cuando creía que ya lo tenía todo en marcha y muchos clientes enviando resulta que tenemos un problemón, nos están llegando avisos (y a los usuarios también) que las firmas de los ficheros no se están validadando.

Tras revisarlo todo mil veces y contactar con soporte resulta que los ficheros xml que recibe Guipuzcoa son diferentes a los que enviamos, los saltos de linea son diferentes y claro, la validación de la firma falla ... me dicen desde soporte que es posible que se haya "modificado en transito" .. ¿como carajo se va a modificar en el transito?, ¿es posible que CURL modifique el fichero?

Saludos.

[Irreo]

Empezado por Maska10

Buenas a tod@s,

Ala, pues cuando creía que ya lo tenía todo en marcha y muchos clientes enviando resulta que tenemos un problemón, nos están llegando avisos (y a los usuarios también) que las firmas de los ficheros no se están validadando.

Tras revisarlo todo mil veces y contactar con soporte resulta que los ficheros xml que recibe Guipuzcoa son diferentes a los que enviamos, los saltos de linea son diferentes y claro, la validación de la firma falla ... me dicen desde soporte que es posible que se haya "modificado en transito" .. ¿como carajo se va a modificar en el transito?, ¿es posible que CURL modifique el fichero?

Saludos.

A mi la vez que me pasó eso (en entorno de pruebas) era porque el XML tenía texto antes.

Según tengo entendido, por temas del estándar XML o alguna cosa así, la primera línea, el primer carácter, debe ser la definición del XML.

Yo por hacerlo más visual, estaba haciendo por PHP algo así (resumen cutre):

$xml = '
<xml .....
<TBAI....
/TBA>
';

Quizás en tu caso es otra cosa, pero por si te ayuda.

[Maska10]

Empezado por Irreo

A mi la vez que me pasó eso (en entorno de pruebas) era porque el XML tenía texto antes.

Según tengo entendido, por temas del estándar XML o alguna cosa así, la primera línea, el primer carácter, debe ser la definición del XML.

Yo por hacerlo más visual, estaba haciendo por PHP algo así (resumen cutre):

$xml = '
<xml .....
<TBAI....
/TBA>
';

Quizás en tu caso es otra cosa, pero por si te ayuda.

Gracias por la respuesta, pero parece que no es el caso, el primer contenido del fichero es la definición, pero es que aparte en el fichero que reciben (ya que me lo han enviado) absolutamente todos los saltos de linea desaparecen o tienen otro formato, vamos que aparece todo en una misma línea.

[Irreo]

Empezado por Maska10

Gracias por la respuesta, pero parece que no es el caso, el primer contenido del fichero es la definición, pero es que aparte en el fichero que reciben (ya que me lo han enviado) absolutamente todos los saltos de linea desaparecen o tienen otro formato, vamos que aparece todo en una misma línea.

Lo de que esté todo en una línea o no creo que no afecta.

Yo probaría a:

- Pasar ambos ficheros por un "minify" para dejarlos ambos sin saltos de línea ni tabuladores.
- Pasar ambos ficheros por un "prettify" para ponerlos bien formateados.

Y en cualquiera de los casos, usar un comparador online, o bien usando tu GIT local, ver qué diferencias hay.

[HerensugeBeltz]

Empezado por Irreo

Lo de que esté todo en una línea o no creo que no afecta.

Yo probaría a:

- Pasar ambos ficheros por un "minify" para dejarlos ambos sin saltos de línea ni tabuladores.
- Pasar ambos ficheros por un "prettify" para ponerlos bien formateados.

Y en cualquiera de los casos, usar un comparador online, o bien usando tu GIT local, ver qué diferencias hay.

Yo entiendo que sí puede afectar si el "minify" se realiza sobre un XML ya firmado.
La firma del XML debe ser lo último que se haga antes de grabar el fichero, ya que cualquier cambio posterior la invalidaría.

[Irreo]

Empezado por HerensugeBeltz

Yo entiendo que sí puede afectar si el "minify" se realiza sobre un XML ya firmado.
La firma del XML debe ser lo último que se haga antes de grabar el fichero, ya que cualquier cambio posterior la invalidaría.

Sí, eso sí.

Me refería a la hora de comprobar el XML enviado firmado, y el XML que ha recibido Hacienda e informa que ha sido manipulado.

Es decir, comprobar los dos XML en la misma situación, ya sea minify, o formateado. Según comenta Maska10, Hacienda le ha enviado el XML que han recibido ellos.

[HerensugeBeltz]

Empezado por Irreo

Sí, eso sí.

Me refería a la hora de comprobar el XML enviado firmado, y el XML que ha recibido Hacienda e informa que ha sido manipulado.

Es decir, comprobar los dos XML en la misma situación, ya sea minify, o formateado. Según comenta Maska10, Hacienda le ha enviado el XML que han recibido ellos.

Tienes razón, he leído mal tu respuesta.

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

Empezado por Maska10

Tras revisarlo todo mil veces y contactar con soporte resulta que los ficheros xml que recibe Guipuzcoa son diferentes a los que enviamos, los saltos de linea son diferentes y claro, la validación de la firma falla ... me dicen desde soporte que es posible que se haya "modificado en transito" .. ¿como carajo se va a modificar en el transito?, ¿es posible que CURL modifique el fichero?

Revisa los procedimientos por los que pasa el fichero o el XML después de firmarlo.
Este error de "modificado en transito" suele dar cuando algún character del XML ha cambiado desde que se firma hasta que se recibe.

Otra opción es que simplemente cambie la codificación. Si dentro del XML hay un character acentuado, al cambiar la codificación del fichero ese character cambia y por lo tanto la firma ya no coincide (esto nos pasó a nosotros al grabarlo de determinada forma). La mayoría de los ficheros funcionaban aunque cambiaba la codificación. En los XML que no había caracteres extraños no daba error, mientras que los que incluían acentos nos daba el "...error, modificado en transito".

Que no sea algo de esto.

[skymota]

Empezado por Maska10

Buenas a tod@s,

Ala, pues cuando creía que ya lo tenía todo en marcha y muchos clientes enviando resulta que tenemos un problemón, nos están llegando avisos (y a los usuarios también) que las firmas de los ficheros no se están validadando.

Tras revisarlo todo mil veces y contactar con soporte resulta que los ficheros xml que recibe Guipuzcoa son diferentes a los que enviamos, los saltos de linea son diferentes y claro, la validación de la firma falla ... me dicen desde soporte que es posible que se haya "modificado en transito" .. ¿como carajo se va a modificar en el transito?, ¿es posible que CURL modifique el fichero?

Saludos.

Muy buenas!

Me empezó a pasar esto mismo en Guipuzcoa-pruebas pero con una casuistica que me está volviendo loco. Mismos datos en la factura, DATOS DEL EMISOR CON UN ACENTO. La primera vez que la envío, me devuelve el error "El mensaje ha sido modificado en tránsito o la firma no está bien realizada". La vuelvo a hacer a continuación, y me devuelve ok, esa y todas las siguientes que haga seguidas......

Paro de enviar, y al cabo de un rato (más de un minuto) vuelvo a realizar la misma factura, y me vuelve a dar el error, y todas las siguientes me vuelven a dar ok.

Es un poco sinsentido, pero ya no se si es del servidor de pruebas de Guipuzcoa de mi cabeza o de que!!!
-Comprobado que está todo en utf-8
-Comprobado que no se modifica el fichero desde que se firma hasta que se envía.

Ni que decir tiene que en Alava y en Vizcaya no tuve ni tengo ningún problema de este tipo y me envía todo correctamente.

Alguna pista? Mil gracias!

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

Empezado por skymota

Me empezó a pasar esto mismo en Guipuzcoa-pruebas pero con una casuistica que me está volviendo loco. Mismos datos en la factura, DATOS DEL EMISOR CON UN ACENTO. La primera vez que la envío, me devuelve el error "El mensaje ha sido modificado en tránsito o la firma no está bien realizada". La vuelvo a hacer a continuación, y me devuelve ok, esa y todas las siguientes que haga seguidas......

Paro de enviar, y al cabo de un rato (más de un minuto) vuelvo a realizar la misma factura, y me vuelve a dar el error, y todas las siguientes me vuelven a dar ok.

Es un poco sinsentido, pero ya no se si es del servidor de pruebas de Guipuzcoa de mi cabeza o de que!!!
-Comprobado que está todo en utf-8
-Comprobado que no se modifica el fichero desde que se firma hasta que se envía.

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.

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

[skymota]

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

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.

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

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!

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

Empezado por skymota

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

Seguramente.

[HerensugeBeltz]

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:efault).
A ver si te sirve de ayuda.

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

Empezado por HerensugeBeltz

Yo empezaría por comprobar que todas las funciones de lectura/grabación del fichero XML, antes y después de firmar

Y entre firmar y enviar.

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

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

[edejuan]

Empezado por Maska10

Buenas a tod@s,

Ala, pues cuando creía que ya lo tenía todo en marcha y muchos clientes enviando resulta que tenemos un problemón, nos están llegando avisos (y a los usuarios también) que las firmas de los ficheros no se están validadando.

Tras revisarlo todo mil veces y contactar con soporte resulta que los ficheros xml que recibe Guipuzcoa son diferentes a los que enviamos, los saltos de linea son diferentes y claro, la validación de la firma falla ... me dicen desde soporte que es posible que se haya "modificado en transito" .. ¿como carajo se va a modificar en el transito?, ¿es posible que CURL modifique el fichero?

Saludos.

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.

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

Empezado por edejuan

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

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

[elcharlie]

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.

[thinkows]

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>

[skymota]

Empezado por thinkows

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??