Caso Curioso
 

Hola a todos, hoy por error hemos enviado un ticket de prueba a las url's de producción de en Guipuzkoa.... :p:p , o sorpresa admitida sin un solo error ????

El NIF del emisor es de la provincia de Barcelona, le mando un correo pidiendo disculpas y con todos los datos de la operación, xml incluido.

Les pregunto por la ausencia de ERROR, respuesta :

Buenos días,
Con anular la factura sería suficiente. :confused::confused::confused::confused:

Un saludo

[email protected] https://gipuzkoa.eus/ticketbai

Soy obediente y procedo .... respuesta a la anulación

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<IdentificadorTBAI>TBAI-Bxxxxxxxx-300922-Sn9juIYhDs4dO-107</IdentificadorTBAI>
<FechaRecepcion>30-09-2022 11:29:02</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado - BAJA</Descripcion>
<Azalpena>Baztertua - BAJA</Azalpena>
<ResultadosValidacion>
<Codigo>012</Codigo>
<Descripcion>Error en verificación alta-inscripción software TicketBAI</Descripcion>
<Azalpena>Errorea TicketBAI softwarearen alta inskripzioa egiaztatzean</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

He vuelto a enviar un correo... estoy a la espera.....

Le ha pasado a alguien mas???

Un saludo

estás enviando a la url de baja de pruebas? da la sensación que estás enviando a la plataforma de producción, y te dicen que no estás inscrito

A mí me pasó lo mismo: el primer envío en producción de un cliente le dio error de servidor y probé a mandar una factura en real con mi propio DNI (soy asalariado, no estoy dado de alta como declarante en Gipuzkoa y pensé que la rechazarían). Cuando me la aceptó me quedé igual que tú.

Mandé un correo a Hacienda y la respuesta fue que, en este caso (no retengo IVA), esa factura no tenía ningún efecto pero que tuviese más cuidado la próxima vez :).

Se me ha olvidado decir que, por si acaso, anulé la factura en producción.

Curioso
 

El tema está en que la factura de alta la he enviado por error y la han admitido sin problemas y en cambio la anulación (todo con url's de producción) la han rechazado, todavía no me han contestado, les he
comentado que si he podido enviar un alta, porqué me rechazan la devolución (que es lo que me han dicho que haga) ????

Ya os contaré, gacias.

Modificado en transito por Curl?
 

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.

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.

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.

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

Consulta por código QR identificación necesaria
 

Hola buenas tardes compañeros.

¿A alguno más os pasa que las consultas de Ticket BAI en Gipuzkoa mediante código QR ahora al acceder aparece una página de que para consultarlo se debe entrar identificado?



Archivo Adjunto 4027

En mi caso (PREPRODUCCION) no.
Sigue como siempre.

Exacto Neftali. En ambiente desarrollo de pruebas lo tienen igual de siempre. Sucede en ambiente de producción

Hola,

Sí, ocurre, en el entorno en real, con las facturas completas (las que incluyen datos del destinatario), pero no ocurre con las facturas simplificadas (sin datos del destinatario.

Les consulté a los chicos de TicketBAI de Gipuzkoa y me dijeron que era por tema de protección de datos.
Sólo puede consultarse del QR (o el TBAI) con certificado digital del emisor o del destinatario de la factura.

Les argumenté que es absurdo limitar de esa forma la consulta del QR o del TBAI, ya que sólo el emisor y el destinatario tienen el código TBAI y el código QR de la factura (que incluye parte de la firma) y nadie más puede consultarla.
Después de varios emails de ida y vuelta, al final me dijeron que tomaban nota de mi sugerencia y la pasaban al departamento correspondiente.

Saludos

Gracias Sistel. Estoy contigo.

No consigo comprender entonces la lógica del argumento que dan. No tiene razón de ser. En cuanto a que la información que se consulta cuando se lee el código QR y te deriva a la web de comprobación del registro de la factura, los únicos datos que aparecen son el NIF emisor, número de factura e importe de la factura. Nada sobre el destinatario. :confused:

Un saludo

Los designios de Hacienda son inescrutables.
Nosotros, débiles mortales, sólo debemos creer y obedecer ciegamente.
:D:D:D

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.

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!