Buenas,
¿Os sale error en la comprobación del QR en https://batuz.eus?

https://batuz.eus/QRTBAI/?id=....

Ya está ha sido un momento, ya vuelve a funcionar

Si, creo que todo lo que comentas lo cumplo.
Creo que gipuzkoa suele contestar bastante rápido a los emails, voy a probar yo también...


Si quitas el certificado, lo envia todo, pero la respuesta es de que falta el certificado.

Ya lo tengo! Tenía el certificado caducado...que fallo!
Para probarlo estaba cogiendo el certificado a saco, en producción la idea es tenerlo instalado, asi comprobamos primero la fecha.


En fin creo que deberían devolverte como respuesta certificado caducado o algo por el estilo.


PD: Espero que te sirva...

Qué va. Gracias por tu info pero en mi caso el problema debía ser otro: yo no tengo el certificado caducado. Digo debía ser otro porque ahora este problema "se ha solucionado" pero me lanza otro que no es cierto: dice que no se ajusta al esquema XSD; sin embargo, en mi validación no da ningún problema y el validador está funcionando correctamente porque si cambio alguna etiqueta o si pongo un dni con un formato erróneo o una fecha mal o lo dejo sin firmar, etc. me salta el error. Sin embargo, cuando lo envío ahora me da este resultado:

A mi también me está saltando el mismo error y el validador me devuelve OK
Lo que me mosquea es que en el ejemplo que tienen la firma sale así:
<dsig:Signature xmlns:dsig=


y yo la firmo así:
<ds:Signature xmlns:ds=


y digo que no entiendo, por que estoy usando FirmaXadesNet para firmarlo...

La diferencia está solo en el nombre usado, son prefijos difierentes. Si durante todo el Xml está el mismo prefijo sin problemas. Incluso hay firmas que omiten el prefijo ds: dsig:....


La estructura es:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
<Reference /> etc.
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Da igual que pongas prefijo o no

os dejo una ayuda por si quereis revisar vuestro xml antes de firmarlo, yo antes de grabar cualquier dato (descripciones, nombres de clientes...) lo envio a una funcion y reviso los caracteres que sean caracteres imprimibles, etc, y me ahorro todas las conversiones a UTF8,ISO..etc..
https://sede.micinn.gob.es/stfls/eSe...G_20170315.pdf

Hay que tener en cuenta de que si hay caracteres extraños, la firma será incorrecta yte va a tirar errores.

Gracias menda, pero creo que ese no es el caso; en primer lugar porque en el xml no tengo ningún carácter extraño (ni tildes, ni eñes, ni comillas ni ná, excepto [A-Z,a-z,0-9] y por otra parte porque el fichero tanto sin firmar como firmado se genera en utf8, que tendría que ser suficiente también incluyendo caracteres con tildes, etc.

Gracias por la confirmación :-). La verdad es que yo también tenía dudas de si pudiera estar ahí el problema

Será por lo de mal de muchos... pero casi que me has alegrado el día :-) porque ya pensaba que yo era el único. Prepárate para cuando se solucione esto. El próximo error que arrojará en el resultado será: "Error: Certificado remitente incorrecto (revocado o no homologado).".

Espero confundirme...

Buenos días,

¿Alguno podría indicarme que datos mostráis en caso de inspección presencial? He estado revisando la documentación y lo único que he encontrado alguna referencia es en Bizkaia, que indica lo siguiente:

¿Habría que mostrar también los XML enviados con su respuesta? Según el articulo 8, habría que almacenarlos pero no indica en ningún momento que tenga que existir ninguna herramienta para la recuperación de los mismos por parte del usuario (aunque a mi entender seria algo de lo que debería disponer)

Muchas gracias por la ayuda por adelantado.

Para que te den el garante tienes que indicar en el formulario donde y como acceder a los ficheros xmls firmados.
Saludos

Hola Edgar7,

Como se indica en el artículo 9 de https://www.batuz.eus/fitxategiak/ba...septiembre.pdf , los unicos datos obligatorios en el caso de "Verificación Presencial" son:
a) Número de identificación fiscal y apellidos y nombre o razón social o denominación de la persona o entidad desarrolladora del software garante utilizado desde el dispositivo.
b) Nombre del software garante utilizado desde el dispositivo.
c) Versión del software garante utilizado desde el dispositivo.

Por supuesto, como dice el artículo 8 de la misma Orden Foral, hay que conservar los ficheros de alta y anulación de facturas el tiempo que marca la Norma Foral General Tributaria.
(Creo que son 3 años)
Pero si en las contabilidades hay compensaciones o devoluciones correspondientes a ejercicios anteriores, habrá que alargar el período de conservación para englobar también esos ejercicios.

Saludos

Hola ermendalenda,

Yo sólo indiqué que quedaban almacenados y custodiados en nuestros servidores, sin especificar dónde ni cómo acceder a ellos.
Y nos lo aceptaron.

Eso sí, especifiqué, también, que el obligado tributario podría acceder a leerlos, pero no a editarlos o borrarlos.

Saludos

Ya la interpretación que le quiera dar cada uno y lo que quieran que los moleste en caso de inspección, yo lo voy a poner en la memoria descriptiva además de un botón bien gordote en la pantalla de verificación, además por supuesto de guardarlo en un servidor.

7) Sistema de almacenamiento de los ficheros de alta y de anulación de oper...

Después de la experiencia en estos temas, al menos mis clientes directos, no van a saber indicar donde estan los archivos.

Especificaciones Tickebai:

"5 ESPECIFICACIONES TÉCNICAS DE LA FASE DE VERIFICACIÓN PRESENCIAL

En la verificación presencial, el personal inspector podrá verificar el correcto funcionamiento del software de facturación y podrá requerir la aportación de los ficheros TBAI generados tanto en el proceso de verificación como aquellos que el contribuyente tiene la obligación de conservar, de acuerdo con la normativa general tributaria."

Pregunta importante para dar de alta en software garante sobre firmador.php
Si tengo alojado el php en un servidor en la red local:
Ya es considerado como arquitectura con firma en servidor?

Hola ermendalenda,

Pues veo que en Álava sí lo exigen así.
En Gipuzkoa y Bizkaia no he encontrado esa exigencia.

Saludos

Hola ermendalenda,

Si la firma se hace en un servidor (local o en Internet, da lo mismo), en lugar de en la máquina cliente, se considera arquitectura con firma en servidor.

Saludos