Yo lo que he visto es que el fichero que has enviado es UTF8 con BOM.
Creo que debería ser UTF8. No se si es el mismo que estás enviando, pero asegurate de eso.

Como te ha dicho Neftali, o está en UTF8 BOM, o lo has editado con un editor que le ha dejado con caracteres extraños, prueba a editarlo con por ejemplo MFC Wordpad y vuelve a grabarlo.
De todas formas te va a dar error el envio por que te falta informar lass lineas de detalle.

Te dejo el fichero sin los caracteres especiales para que lo vuelvas a firmar y pruebes a enviar, pero lo dicho:te faltan las lineas de detalle.
Saludos

Un detalle del xml. Cuidado con las fechas porque la fecha de la factura anterior no puede ser superior a la de la factura que envías.

En este ejemplo:

<FechaExpedicionFacturaAnterior>05-05-2022</FechaExpedicionFacturaAnterior> <--- Esta fecha no puede ser superior a la de FechaExpedicionFactura

<FechaExpedicionFactura>13-09-2021</FechaExpedicionFactura>


De paso, como comentaba Neftali, elguille ten cuidado al guardar el fichero pq lo has hecho en utf8 BOM y debe ser utf8 a secas (desconozco las diferencias entre ambos, pero solo está admitido utf8).


También os pongo como lo firmo yo con el autofirma, por si ayuda a despejar alguna duda:

Código Delphi [-]
signParams := 'sign -format XAdES ' +
                '-config "format=XAdES Enveloped\npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf\npolicyIdent  ifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=\npolicyIdentifierHashAlgorithm=http://www.w3.org/2001/04/xmlenc#sha256\npolicyQualifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf" ' +
                '-xml ' + 
                '-i "' + PathFile + '\' + FileName + '" ' + // Fichero entrada
                '-o "' + PathFile + '\' + FileName + '" ' + // Fichero salida (sobreescribimos)
                '-store pkcs12:"' + PathCertificat + '" ' +
                '-filter "imported" ' + 
                '-password "' + PwCertificat + '" ';

Código Delphi [-]
ShellExecute(
      'open',
      'cmd',
      '/v:1 /c autofirmaCommandLine.exe ' + signParams +                                 
      ' > "' + pathResposta + '" ',  // captura de la respuesta para parsear si hace falta
      '"C:\Program Files\AutoFirma\AutoFirma\"',
      0
    );

Nada, sigo sin encontrar este detalle, ni en la doctrina, ni en la faq ni en preguntas frecuentes...

Parece ser que puede ser el mismo
" a diferencia de las facturas rectificativas completas en las que es necesario que se expidan con una serie específica, las facturas simplificadas rectificativas no tienen que tener una serie diferente del resto de facturas simplificadas, sin perjuicio de que voluntariamente se le quiera dar."
Gracias de todas formas

Como te han comentado más arriba el xml tiene que guardarse en UTF sin BOM

Yo lo hago así.

Código Delphi [-]
        strList := TStringList.Create;
        try
          strList.Assign(xmlTBai_Document.XML);
          strList.WriteBOM := false;
          strList.SaveToFile(strFileNameXML, TEncoding.UTF8);
        finally
          FreeAndNil(strList);
        end;

Saludos.

He conseguido que Guipuzkoa me lo acepte! Gracias a todos, no se que habria hecho sin vosotros!!

Al menos ya me responde con Recibido, aunque con el error:

<Codigo>008</Codigo>
<Descripcion>ERROR - The Reference for URI has no XMLSignatureInput - (org.apache.xml.security.exceptions.XMLSecurityException)</Descripcion>

Alguien sabe que puede ser?

Muchas gracias de nuevo! :)

Cambios?
 

Hola, ¿alguien ha oído algo de que van a haber grandes cambios?

Hola a todos.

¿A alguien más le esta dando error al enviar al 240 de bizkaia una factura?

B4_2000070
FirmaElectronica: La firma no cumple los requisitos de la política de firma TicketBAI.(EPES: S ALGORITMO: rsa-sha256:2048 POLITICA: S CERTIFICADO_ADMITIDO: N )

Hasta ahora funcionaba bien y si envío al 140 funciona tambien.

A mi me está dando lo mismo.

Y no hay documentación actualizada.

Creo que es algo de ellos. Tambien estan teniendo problemas con los certificados del SII de representación. LEs he mandado la consulta.

Gracias.

¿Puede que tengas algun caracter aún de sobra?

Parece que hay fallos en la firma
<ds:Reference ...... Type="http://www.w3.org/2000/09/xmldsig#Object" URI="">

URI esta vacio y deberia contener algo así:

<ds:Reference..... URI="#xmldsig-c9ec071f-dd3f-f1b1-2f2c-ae7d6266c800-signedprops"

Repasa cabecera del xml enviado que no haya caracteres extraños.
Saludos

Jejeje, PVP creo que significa Precio Venta Público; o sea, que por definición incluye impuestos ;-)
Es sólo por tocar las narices; se entiende perfectamente que el que hay que usar no incluye ni descuentos ni impuestos ;-)
Pero yo lo llamaría Precio Neto ¿eh?

;)
Correcto...

Bizkaia LROE 140 y 240
 

Egunon!
Gracias a vuestras aportaciones hemos conseguido mandar y obtener respuesta desde Gipuzkoa, Pero con Bizkaia estamos perdidos. Alguien podría decirme como podemos crear el xml para mandarlo?? Donde puedo conseguir ejemplos?
Gracias.

Empieza por aquí: https://www.batuz.eus/es/documentacion-tecnica
Ahí tienes documentación, los esquemas y ejemplos.

el xml es el mismo... solo tiene la diferencia que los destalles de la factura son opcionales en Bizkaia i obligatorios en Gipuzkoa...

El proceso de comunicación es diferente... Resumen muy resumido : a Gipuzkoa se envía directamente un xml i a Bizkaia se envia a través de un registro llamado LROE, donde puedes enviar más de 1...

Mírate el enlace que te ha puesto Neftalí más arriba y la primera página de este hilo, donde están tooodos los enlaces...

Hola!

Tenias razon, era algo relacionado con el URI, muchas gracias, una cosa menos, seguimos remando :)

Ahora me devuelve el error:

<Codigo>008</Codigo>
<Descripcion>No se pudo seleccionar ninguna política de validación para poder validar - (13517)</Descripcion>

Alguien sabe algo? Saludos!

Estamos con el mismo problema, desde ayer nos da error.

Si alguien se entera de algo, que lo comente por favor, yo haré lo mismo si me entero de algo.

Gracias

@Tejano, en Gipuzkoa va bien.

Ahora (y desde hace días) tengo el aviso 012: Error en verificación alta-Inscripción sofware TicketBAI. El software no está registrado.
Hasta la semana pasada tenía que ser normal, dado que no estaba registrado...pero el lunes me registré, me enviaron la documentación y ya aparezco en la lista el la web de TBAI y he puesto la licencia TBAI que me dieron y la estoy utilizando...
¿a alguien le ha pasado?

Esta mañana me han llamado de hacienda para hacer una prueba hoy. Y siguen con el mismo problema. Me han dicho que lo estan mirando. Con calma:D

Me acaba de responder hacienda con lo siguiente.

"Hemos detectado una incidencia con las validaciones de algunos certificados en la firma de los ficheros TicketBAI. Estamos trabajando en dicha incidencia y os avisaremos cuando esté solucionada."

:eek:

Gracias Keys, iba a poner lo mismo, me acaban de responder.

He realizado la siguiente consulta por si es de vuestro interés
 

Hemos consultado los errores de encadenamiento dando el siguiente supuesto :

Pregunta a la hacienda foral :

Buenos días, quisiéramos saber si hemos entendido bien la mecánica de funcionamiento, planteando el siguiente escenario, nuestra aplicación en principio enviará a la hacienda foral el XML on-line, pero vamos a prever un mecanismo para el envío en el caso de caída de internet


HAY CONEXIÓN A INTERNET

SE ENVIA EL TICKET nº 326 referenciando como operación anterior el TICKET nº325
SE ENVIA EL TICKET nº 327 referenciando como operación anterior el TICKET nº326

CAE INTERNET

SE GENERA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 pero no se envía a la hacienda foral

SE RESTABLECE INTRENET

SE ENVIA EL TICKET nº 329 referenciando como operación anterior el TICKET nº328 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 no se ha enviado todavía)


AL FINAL DEL DIA SE ENVIAN MEDIANTE UN PROCESO TODOS LOS FICHEROS QUE NO SE HAN PODIDO ENVIAR


SE ENVIA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 se envía ahora)



Entendemos que errores de encadenamiento son simples avisos sin más consecuencias mientras se acaben enviando todas las operaciones ?

Aprovechando la ocasión quisiéramos saber si ya han salido las especificaciones de ZUZENDU ?



Respuesta de Guipuzkoa :

Egun on, Buenos días

La normativa foral de Gipuzkoa reguladora de la obligación de TicketBAI parte de la premisa que la imposibilidad temporal del cumplimiento de la obligación TicketBAI no suponga la paralización de la facturación y las ventas. Asimismo, parte de la posibilidad de que no se requiere conexión a internet para la generación del fichero XML ni para la plasmación del código identificativo y del QR. Por ello para el supuesto de que por cualquier circunstancia no se puedan generar ficheros o expedir facturas cumpliendo la obligación TicketBAI, establece en el artículo 17 del Decreto Foral 32/2020, de 22 de diciembre, por el que se aprueba el Reglamento por el que se desarrolla la obligación TicketBAI, lo siguiente:

“Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI.

3. En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio telefónico o telemático, avería del sistema de envío u otras circunstancias en las que el contribuyente pueda generar ficheros TicketBAI pero no pueda enviarlos a la Administración tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI generados y procederá a su envío tan pronto se restablezca la conexión.”

Así, una vez que el servicio estuviera activo debería remitir las facturas que han quedado pendientes de envío en su correspondiente orden de encadenamiento.

Un saludo,


Es decir, no podemos enviar el 329 hasta haber enviado el 328.... lo estáis haciendo así ? (nosotros al cerrar la operación hacemos el envío de la misma) , esto nos obligará a cambiar y enviar todo lo pendiente
por orden.

Y sin noticias de ZUZENDU .....

Efectivamente, tengo marcado los que no se han podido enviar, si alguno no sse puede enviar sigo generando tiquets y reintento enviarlo en el mismo orden(dejaré una opción para saltarlo si el problema del envío es algo justificable aunque se rompa el encadenamiento y pasaré al siguiente aunque se me quede huérfano) ahora lo tengo en la misma Hilera, pero tengo previsto hacerlo en un ejecutable aparte, como quieras llamarlo, en cola asíncrona, en segundo plano y cada vez que vaya a enviar siempre en un orden cronológico al que le he asignado un número de orden FIFO.,

Hola, sigue revisando la cabecera
presta especial atención a las mayúsculas y minúsculas, ojo con las comillas (") que si lo has copiado de alguna web puede ser unas comillas distintas, en resumen, repasa caracter a caracter.
En la cabecera debes tener algo así:

<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">
o al menos así:
<T:TicketBai xmlns:T="urn:ticketbai:emision">

Nota: y por supuesto el xml firmado no se puede editar y cambiarle nada por que no funcionaria el envio y cambiaria el signaturevalue
Saludos.

Bizkaia CURL
 

Hola!
Tengo problemas con el envio del archivo .gz a DFB.
Estoy usando PHP y GuzzleHttp.
Para los headers:
Y para el envio:


Este es el error que recivo:

GuzzleHttp\Exception\ClientException
Client error: `POST ..://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena` resulted in a `400 Bad Request` response

Hola no sé como funciona Guzzle, si te puede servir veo un par de cosas:
No se si has definido la variable $client:
$client = new \GuzzleHttp\Client();

Despues veo extraño ésto, (que no sé si ha sido al cortar el http... y pegar):
''..pruesarrera
^^ dos comillas simples .. mmmm no sé, lo veo raro, aunque ya te digo no me hagas mucho caso.

Aunque pensandolo bieen tiene pinta mas bien que no se esta firmando adecuadamente y faltan parametros en la firma.

Si, la variable $client la tengo creada y las comillas son porque no puedo poner enlaces.
He descubierto que el error que recibo de la DFB es:
Parámetro clientcert no indicado en la cabecera de la petición

Los certificados me funcionan para Gipuzkoa y los envio igual.
Gracias.

Efectivamente era que el fichero llevaba BOM, no he conseguido grabar sin el directamente con las chilkat, pero con la función descrita y añadiendo las lineas de detalle, ha ido perfecto. Muchas gracias a todos.

Validación QR Gipuzkoa
 

Hola, ¿puede alguien confirmar si al enviar una nueva factura a Gipuzkoa y visitar el enlace del QR le aparecen directamente los datos de la factura enviada?
Desde hace un par de días, en lugar de aparecer los datos de la factura me muestra un captcha para poner un código y después de ponerlo me dice que el QR es ilegible (que yo sepa no he tocado nada) y tengo que poner el identificador TBAI y otro captcha para poder ver los datos de dicha factura.
Con los QR anteriores al día 16 me aparecen los datos directamente.

Saludos,
David M.

Entorno de pruebas Gipuzkoa
 

Buenos días

Estoy intentando enviar el TicketBai para Gipuzkoa. Para Bizkaia lo tengo superado, pero en Gipuzkoa me encuentro un poco perdido.
Utilizo sbxHTTPClient de SecureBlackbox y al realizar el envío la cabecera va cargada así:

Código Delphi [-]
 sbxHTTPClient1.Post(la_url_GI_alta_pruebas, Cuerpo_mensaje_text);

Pero me da un error 10058 y luego 10054.
En la cabecera solo hay que indicar entiendo Content-Type: application/xml;charset=UTF-8
Si hay alguien que trabaje igual que yo, y puede indicarme como lo hace, agradecido.

Entre las dudas que tengo, es el fichero TicketBai hay que enviarlo también en gzip, como en Bizkaia , o en texto XML sin comprimir.

Gracias

A mi me sigue funcionando.
Puede pasarte varias cosas (si las sabes pues nada):
1. Que efectivamente el servicio este mal en ese momento(lo acabo de probar y va bien pero es cierto que alguna vez mme ha pasado lo que comentas y a los pocos segundos ya funcionaba)
2. Que no estes convirtiendo el QR (Ojo no el código que escribes) a URI (código URL), esto es por si los caracteres de la firma tienen algun caracter especial "/" """, "'" "."...
3. Que aunque estes generando el Qr con URi no es tes calculando el nuevo CR, que es diferente al escrito.

Por cierto no hace fallta enviarlo para que funcione, los datos que ves están en el mismo QR, que si lo generas correctamente se deberia ver.

Gracias por tu tiempo ermendalenda, lo tengo solucionado.
Resulta que sí que había cambiado una parte del código y a la hora de construir la url en lugar de pasar nf como parámetro de número de factura me comí la f, por eso no cuadraba. Estragos provocados por el copy/paste :D

Saludos,
David M

Nada.
Me alegro, que lo hayas solucionado.

Hola bilbur, ante todo muchas gracias por ese script maravillos del firmador.php, agradecería que subieras el nuevo script para convertir los certificados.
Te debemos ya unas cuantas rondas de pinchos y bebidas.
Un saludo.

Hola ermedalenda,

El tema de que se utilice distinta serie para facturas rectificativas que para facturas normales (independientemente de que sean simplificadas o no) es parte de la normativa del Reglamento de Facturación.
No tiene nada que ver con TicketBAI y a los de TicketBAI ese tema se la suda.

Es parte de las normativas del Reglamento de Facturación que suelen ser un poco "laxas" (Los inspectores de Hacienda no le dan mucha importancia, al igual que al tema de que se sellen las facturas recibidas al dorso y otra larga serie de chuminadas similares)
Sé que hay muchas empresas que no siguen esa regla de separar en distinta serie las facturas normales de las rectificativas (aunque no sea "totalmente" legal ... pero no es una cosa grave)

El mismo tema con emitir facturas simplificadas con importes negativos en lugar de facturas simplificadas rectificativas en el caso de devoluciones en TPVs.
Hay softwares muy sencillos de TPV que no tienen posibilidad de seguir toda la normativa de crear facturas simplificadas rectificativas identificando los datos de la factura a la que rectifican, los datos que rectifican, el tipo de rectificación (total o parcial) y el motivo de la rectificación.
En esos casos lo habitual es generar una factura simplificada con importe negativo y santas pascuas.
Consulté ese caso con TicketBAI y se lavaron las manos (es tema del reglamento de facturación ... y a ellos se la reflanflinfa) .

Saludos

Gracias Sistel.
Yo soy de los que no lo tengo preparado para otra serie,
Me preocupa de que mañana las rechace el servidor.