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

[Ramon88]

Empezado por unomasmas

Aemás de usar el protocolo TLS 1.2 (que veo que ya lo haces), creo que debes asegurarte de que el emisor en el documento (factura) que envías debe ser el mismo que firma la petición y, por otra parte, debe estar registrada en la base de datos de pruebas... Yo también estoy teniendo este problema. Es posible que sea un problema de ellos porque hace tiempo pude enviarlo con los mismos datos y ahora no me deja ?? He abierto una consulta con el servicio técnico pero todavía no tengo respuesta :-(

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

[unomasmas]

Empezado por Ramon88

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:

        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>002</Codigo>
            <Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.b: The content of element 'T:TicketBai' is not complete. One of '{"http://www.w3.org/2000/09/xmldsig#":Signature}' is expected.</Descripcion>
            <Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-complex-type.2.4.b: The content of element 'T:TicketBai' is not complete. One of '{"http://www.w3.org/2000/09/xmldsig#":Signature}' is expected.</Azalpena>
        </ResultadosValidacion>

[Ramon88]

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

[ermendalenda]

Empezado por Ramon88

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=

6NrKAm60o7u62FUQwzZew24ra2ve9PRQYwC21AM6In0
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

[ermendalenda]

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.

[unomasmas]

Empezado por ermendalenda

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.

[unomasmas]

Empezado por ermendalenda

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

Da igual que pongas prefijo o no

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

[unomasmas]

Empezado por Ramon88

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

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

[Edgar7]

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:

Artículo 9.—Funcionalidad de verificación presencial de los softwares garantes

Los softwares garantes deberán disponer de una funcionalidad de verificación presencial, en virtud de la cual deberán mostrar la siguiente información en una única pantalla del dispositivo de facturación:

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.

Con carácter opcional, se podrá mostrar igualmente el número de serie del dispositivo desde el cual se muestra la anterior información.

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

Artículo 8.— Conservación de los ficheros de alta y de anulación de operación con software garante

Los ficheros de alta y de anulación de operación con software garante deberán conservarse durante los plazos a los que se refiere el artículo 66 de la Norma Foral General Tributaria.

Muchas gracias por la ayuda por adelantado.

[ermendalenda]

Empezado por Edgar7

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

[Sistel]

Empezado por ermendalenda

Para que te den el garante tienes que indicar en el formulario donde y como acceder a los ficheros xmls firmados.
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

[Sistel]

Empezado por Edgar7

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.

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