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

Lo veo lioso. Si hay 4 tpvs y 1 hace de servidor y ese firma localmente y tiene el php que firma a los demás esta mezclado, es compatible tener los 2 sistemas en la misma ubicación?

Y aún más, si mañana decido crear una nueva versión que en un centro tengo todo a través de un servidor y otro todos firman en el mismo dispositivo

Se puede?

Hola ermendalenda,

Es firma en servidor si la firma se hace en distinto dispositivo al que está facturando.

No hay problema en hacer las combinaciones que quieras, pero para cada caso tendrás que ver si se está haciendo la firma en el mismo dispositivo o en otro (firma en servidor).
Y debes tener en cuenta que si se hace firma en servidor, no puede utilizarse certificado digital de dispositivo.

Saludos

Hola ermendalenda,

Como te comentaba, creo que puedes hacer los cambios que quieras, pero teniendo en cuenta que si se hace firma en servidor no se puede utilizar certificado digital de dispositivo.

Por cierto, si son varios TPVs, en lugar de hacer que uno de ellos tenga que hacer también de servidor, ¿por qué no pones un Raspberry Pi como servidor en el local y que todos lo lo utilicen como servidor para la firma?
Por poco más de 30 € tienes resuelto el problema y una arquitectura estable.

Saludos

Gracias por la ayuda.
Precisamente ya me viene hoy la raspberry y me la dan con Linux instalado. Ya después compro la raspberry y vlono tarjeta para las demás, hemos tenido la misma idea. Esa la usaré para los centros con tpvs más antiguos. De todas formas poner el firmador en un tpv y que los demás hagan las peticiones con Curl no consume muchos recursos. En las tiendas que tengan tpvs potente tes los pondré todos con el apache (o sea arquitectura cliente) para poder ejecutar el php(no sé si hay otra forma de ejecutarlo a través de alguna api...
Por cierto en el firmador php le he añadido como capturar el xml de la petición curl y devolverlo es fácil., son 2 líneas, si lo necesitáis...

Hola ermendalenda,

Me alegra que hayas elegido esa configuración.
Yo utilizo TPVs que son Raspberry Pi y van como la seda.
Te recomiendo que al servidor-Raspberry que firma los XML le instales el servidor web Nginx (en lugar de Apache) y PHP-FPM. Tendrás una máquina muy potente, estable, diminuta y con un consumo de risa.

Respecto a tu oferta de compartir tu modificación del firmador PHP .... ¡Venga, publica!
Toda la información seguro que es valiosa para más de uno.
Aunque seamos pocos los que escribimos en este foro, hay muchísima gente que lo lee.
Creo que éste es el foro sobre TicketBAI más valioso que hay en Internet (si es que hay otros ... que no conozco)

Saludos

Tal es así que un único hilo casi resulta insuficiente. No estaría mal plantear un foro específico para Ticket BAI y poder crear hilos independientes para cada cuestión que se plantea :-)
Un abrazo agradecido a colaboradores y administradores :-)

Estoy interesado en esto de la raspberry (la de 30 euros no la encuentro)
¿Sería posible montar un servidor web para todo TBAI incluido el almacén de las facturas firmadas.xsig?
Y así apenas tocar las aplicaciones ya existentes poco más que para realizar las llamadas al firmador.php
Agradecería consejos para su implementación
Gracias

Buenos días,

Muchas gracias ermendalenda y Sistel por las aclaraciones, ya tengo montada mas o menos esa parte, dando la opción al usuario de poder ver la llamada y respuesta generada por cada documento sin poder editar ni modificarlas.

Aunque como dice Sistel en Bizkaia y Guipuzkoa no pone nada de eso pero sí en Alava mejor tenerlo unificado para todas.

Un saludo

Hola bilbur,

Por supuesto que es posible montar ese servidor web para todo lo referente a TicketBAI.
Con una Raspberri Pi te irá perfecto.

Veo en kubii.es (no llevo comisión ni tengo nada que ver con ellos):
Raspberry Pi Cero WH (con WiFi y Bluetooth) a 14,73 €
Raspberry Pi modelo A+ (con WiFi y Bluetooth) a 26,72 €
Raspberry Pi modelo 3B (con WiFi, Bluetooth, Ethernet y 1GB de memoria) a 40,23 €

Para el tema de crear XML, firmarlo, enviarlo a Hacienda Foral y almacenarlo, cualquiera de esos modelos te será más que suficiente.

Saludos

Aquí lo dejo, le tengo puesto un timeout que si quereis lo podeis quitar pero, si el servidor sta caido no se queda tanto tiempo esperando.Es inmediato y funciona de p.m.

La llamada al firmador.php:
curl --connect-timeout 3 http://.../firmador.php --data-binary @C:\....\...\factura_sin_firmar.xml -o C:\firmada.xml.xsig -D C:\...cabecera_respuesta.txt



Añadir al firmador.php:
//Capturar fichero en una variable
$xml=file_get_contents("php://input");

//Datos certificado
$cal_cert="369258";
$dir_cert = ($_SERVER['DOCUMENT_ROOT'].'/certs/Ciudadano.pfx' );
/Declaracion firmador
$fac = new Firmador();
//Firma según Comunidad
$xmlF = $fac -> firmar($dir_cert,$cal_cert, $xml,"BIZ");
// Devuelve Fichero firmado a la llamada curl o como lo querais capturar
echo $xmlF;


Saludos

Hola ermendalenda,

Muchas gracias por compartirlo.
Muy pero que muy interesante.

También podrías hacer que el servidor cree el XML, lo firme a continuación, cree el código TBAI, cree el código QR y envíe el XML firmado a Hacienda Foral.
Así la máquina que factura se desentiende de todo lo relativo a TicketBAI.
Sólo envía los datos de la factura al servidor y recibe los códigos TBAI y QR para añadirlos en el documento de la factura.

Saludos

Zuzendu para cuando?
 

No se ha publicado documentación todavía no?
Me pareció entender que el vídeo de la presentación también lo publicarán (me perdí los primeros 15 minutos :()


Muchas gracias

De hecho venden apis con lo que comentas y ya hacen el control de envíos etc..
Por ejemplo https://www.kubibai.com/es

Hola ermendalenda,

No los conocía.
Parece que estos colegas hacen algo parecido a lo mío (servicio online TicketBAI).
Gracias por la información.

Saludos

La empresa BINOVO te montan una api en un equipo Windows 10 o Linux en la Red local tb.
Esas 2 son las que conozco.

El fichero de alta TicketBAI no cumple el esquema XSD
 

Hola,



No puedo avanzar, tengo este error y no consigo ver donde esta el fallo... El validador que utilizo me dice que esta todo correcto...
Alguien podría decirme algun validador de xml o como puedo saber donde esta el fallo?

He contactado con ellos pero no contestan.


Un saludo.

Certificado
 

Por cierto, estoy utilizando un certificado digital de la persona que representa la empresa con la que nos hemos dado de alta para hacer las pruebas.
dentro de viendo el certificado dice:
EMITIDO PARA: DNI Nombre de la persona (CIF EMPRESA)
EMITIDO POR: AC Representación
PROPOSITOS PLANTEADOS: Autenticación del cliente, Correo seguro

Hola ramon88, no conozco ningún validador que te diga exactamente donde está el fallo en todos los caso, te paso los 2 que tengo del foro a ver si tienes suerte
Http://tools.chilkat.io/xmlDsigVerif...#generatedCode
Https://web.uanataca.com/pe/servicio...ma-electronica

Gracias por la info!

La de Chilkat no funciona el enlace y la de uanataca es para validar que la firma esté correcta?
No le veo mucho sentido a validar que la firma sea correcta, una vez este todo correctamente realizado la firma siempre debe de ser correcta...


Es que hay algo que se me escapa, he leido en este tema, que hay que poner datos de la factura anterior, pero en el XML de ejemplo no veo ningu sitio donde indiquen esto!
Estoy muy perdido!!