O firmáis vosotros o firma el servicio de terceros. Hace falta certificado para FIRMAR y certificado para ENVIAR (que puede ser el mismo o no).
Ese "servicio de terceros" si hace la comunicación debe tener uno de ENVÍO, ahora falta saber quien debe tener el de FIRMA (me parece más lógico que lo tengáis vosotros) y les enviéis los ficheros ya firmados.
Pero en todo caso eso debes aclararlo con quien te ofrece ese servicio.

Muchas gracias por la información, me pondré en contacto con el servicio que contratamos sobre este tema.

Problemas Alava
 

¿Alguien esta teniendo problemas con Álava??

Revisa las cabeceras y mira si a la empresa que estas presentando hace el 140 o el 240.

¿Qué hago mal con las cabeceras para el LROE?
 

Yo con variaciones y variaciones, como hacer de $cabecera una variable y no un vector, cambiar los ':' por '=' o variar el 'Content-Type, del siguiente código

he logrado que no responda nada, absolutamente nada como es el caso de arriba, he conseguido que me dé Bad Request por no entender el contenido del mensaje, he logrado que me dé una colección impresionante de sentencias con el error 415 al final, pero nunca un XML con el error como lo dan las otras diputaciones.
¿Alguien puede orientarme un poco de qué hago tan mal?

Gracias!!
 

muchas gracias !! Me ha venido muy bien :)

Certificados de firma de código
 

Hola,
No sé si sabéis que a partir de junio los nuevos certificados de firma de código deben ir en dispositivos USB.
https://knowledge.digicert.com/gener...mber-2022.html

Nosotros tenemos un certificado válido hasta agosto de 2024 pero desde Sectigo nos han enviado una oferta que os traslado por si a alguien le interesa (está en correcto inglés):

Hello, this is Matt French with Sectigo.

We are reaching out to clients with Code Signing certificates to ensure they are aware of the upcoming changes and see if they would like to delay having to use a USB token with their certificate.

I see that your current certificate is valid until August 31st, 2024. The new changes will not affect your current certificate. However, when you go to renew the certificate, you will require a USB token that the certificate is housed in, to be directly plugged into the device that is signing with the Code Signing certificate (same as with the EV Code Signing certificates now).

You will not require a USB token for the duration of your order if you place your order before April 25th. I mention this because a lot of our customers are looking for ways to delay having to use the USB tokens and we have come up with a couple of options to help.

First, we are offering existing Code Signing certificate clients a promotion code equal to the value of the time they have remaining on their current certificate, if they place a new order for a 3 year Code Signing certificate.

Second, we are offering the fourth year free when you order a Code Signing certificate for 3 years, on orders placed before April 24th.

Please let me know if you have any questions or if you would like me to send you a promotion code equivilent to the time remaining on your current certificate, that can be used as a discount off the purchase of a 3 year Code Signing certificate.

Kind regards

Sectigo
 

Gracias por la info.^\||/^\||/

Guipuzcoa - Cambio de politica de firma
 

Hola,

He visto que en el año 2022 se cambio la politica de firma a: vSe1CH7eAFVkGN0X2Y7Nl9XGUoBnziDA5BGUSsyt8mg=

He encontrado un ejemplo de insercion de la politica de firma con la anterior politica de firma donde se incluye entre otros el algoritmo y la version tecnica en pdf.
Mi pregunta es ¿ Ademas de la politica de firma hay que cambiar el resto de cosas relacionadas con la politica de firma ?

Gracias


utoFirmaCommandLine sign -i C:\FacE\FacturaTBAI.XML -o C:\FacE\FacturaTBAI.FIRMADO.XML -store windows -filter subject.contains:<NIF> -format xades -xml -config "format=XAdES Enveloped
\npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf
\npolicyIdentifierHash=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"

Hola. En principio sigue valiendo la enterior, pero si la quieres cambiar solo con cambiar la política es suficiente el resto sigue igual.

En el primer mensaje del hilo tienes las políticas de firma actualizadas a Mayo del 2022.
Nosotros estamos con la "nueva" desde hace tiempo. Si como dice [keys] la vieja todavía funciona, no hay prisa, pero en algún momento deberás actualizar la constante.

Error en autofirmacommandline.exe solo cuando firma con politica
 

Hola,

Intentando firmar, despues de 6 horas de vueltas, con autofirmacommandline.exe con los parametros de mas abajo se cuelga. Si quito todo lo que hay despues de -config va bien.
Observo que autofirma.exe (el que tiene GUI) le pongo los parametros y me da tambien error. El siguiente error:

es.gob.afirma.signers.xml.InvalidXMLException: Las firmas XAdES Enveloped solo pueden realizarse sobre datos XML
at es.gob.afirma.signers.xades.XAdESSigner.sign(XAdESSigner.java:510)
at es.gob.afirma.signers.xades.AOXAdESSigner.sign(AOXAdESSigner.java:407)
at es.gob.afirma.standalone.ui.SignPanelSignTask.signData(SignPanelSignTask.java:554)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doSignature(SignPanelSignTask.java:314)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:133)
at es.gob.afirma.standalone.ui.SignPanelSignTask.doInBackground(SignPanelSignTask.java:73)
at java.desktop/javax.swing.SwingWorker$1.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.desktop/javax.swing.SwingWorker.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)



¿ Alguien tiene un ejemplo de autofirmacommandline.exe con la version 1.8.0 ?
¿ Puede ser el problema la ultima version la 1.8.0 ? ¿ Que puedo hacer para poder seguir integrando el ticket bai ?

Gracias a ambos.

Error en autofirmacommandline.exe solo cuando firma con politica
 

Este es el mensaje de error de autofirmacommandline.exe

Error en autofirmacommandline.exe solo cuando firma con politica
 

Solucionado !!!!!
Me faltaba el tag terminal </T:TicketBai>
En fin. Siento los disturbios

Acabo de darme cuenta de que yo la política de firma la tengo en HEX. ¿Vosotros usáis el valor tal cual, o convertido a HEX?

Lo curioso es que para Araba sí uso el valor normal, pero para Gipuzkoa y Bizkaia lo tengo en HEX.

Hola,

Cada día proceso y envío a TicketBAI cerca de 10.000 facturas de mis clientes (principalmente TPV de bazares, bares y cafeterías)

Compruebo que en las 12 facturas enviadas el domingo 16 de abril de 2023 entre las 16:03h y las 16:38h a TicketBAI de Álava se me devuelve el código 008 y mensaje "AVISO: Error en verificación de firma"

Las anteriores y posteriores han ido bien.
Así que está claro que ELLOS han tenido un problema de verificación de firmas en sus servidores (me imagino que por utilizar los servicios de Izenpe).
Les envío email a TicketBAI de Álava, esperando que me digan que, lógicamente, no tengo que hacer nada porque ha sido un fallo suyo.

Pero no. Me contestan diciéndome que tengo que enviar Zuzendu para la subsanación.
¡¡¡ Chúpate ésa !!!
Así que, una vez más, hay que decirles "Sí, buana"

Para mear y no echar gota :)

Saludos

Es la clave del régimen, porque "Quis custodiet ipsos custodes?" ¿ Quién vigila al vigilante ?
Respuesta: Pues exactamente nadie: Hacen de su sombrero un capirote y de su capa un sayo
Lo mejor es la creencia generalizada de que la sociedad de privilegios desapareció con el advenimiento de la democracia

Por cierto en Alava, ¿En producción esta ya activo zuzendu?

Hola keys

Sí. Yo lo utilizo desde hace mucho tiempo.

Saludos

Perdón me he confundido con Osatu.

Duda abonos
 

Buenas gente, soy nuevo por aquí. En primer lugar felicitaciones por el foro y este hilo de TBAI, es lo mejor que he encontrado por la red.


Os planteo una duda. Me han pedido que haga todo el tema de las generaciones de los ficheros para vizcaya y me surge una duda con los abonos.
Ellos actualmente funcionan realizando los abonos como facturas en negativo pero con una serie diferente que luego vuelcan a un software de contabilidad.

¿Se puede generar simplemente un TBAI en el que los importes sean negativos con la misma estructura que tendría una factura normal sin tan siquiera indicar qué factura abona?



Un saludo y gracias.

Puedes hacer una factura negativa sin problemas. Técnicamente te la aceptarán.

Muchas gracias por tu respuesta. En mi caso no estoy desglosando el coste unitario al no ser obligatorio pero el resto lo tengo tal cual indicas, totales en negativo y tipos impositivos en positivo.



Y me surge otra duda. Ellos tienen varios centros de facturación con distintas series pero mi intención es tener una pasarela común.

¿El encadenamiento debo hacerlo por cada centro o debe ser global? Se lo he preguntado al correo de dudas y básicamente no me han aclarado absolutamente nada y eso que han tardado 3 días en contestar...

Datos factura identificativos erróneos (NIF, dirección, etc.)
 

Buenas tardes.

Este foro me ha traído viejos recuerdos, pues hace mas de 20 años trabajé con Delphi en las versiones 2 a 7. Como Borland no creía en su producto y cada vez se usaba menos me tuve que reconvertir a .NET en fin.

Estoy adaptando una aplicación para el TBai (de momento sólo para Álava) y la duda me surge con los errores en los datos identificativos de la factura, sobre todo del receptor, como pueden ser en NIF, la dirección, etc. y los importes correctos.

Para corregir esto se ha de hacer una factura rectificativa que supongo será por sustitución con los datos identificativos corregidos y mi pregunta es si los importes son correctos, hay que ponerlos o no en la nueva factura y como afecta todo esto en la generación del xml. He preguntado a la diputación de Alaba y me han puesto un copiar y pegar de los diferentes casos de facturas rectificativas, que sólo hacen referencia a la corrección de importes.

Gracias por vuestra ayuda.

A ver si esto te aclara algo:
https://www.batuz.eus/es/preguntas-f...egunta_7405232
(segunda pregunta)

"El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:

• Si un mismo dispositivo o centro de facturación emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie dentro de ese dispositivo o centro de facturación (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie).
• Igualmente, si el sistema de facturación es un sistema totalmente centralizado, el encadenamiento se refiere a la última factura expedida por el sistema en orden temporal."

En Gipuzkoa, si la factura es errónea, a priori, debes hacer un Zuzendu (dirección o NIF incorrecto del receptor, etc.). Si la has emitido a un receptor equivocado, por ejemplo, entonces deberás darla de baja y emitir una nueva con un nº de factura diferente.

Gracias por la respuesta. Ya había leído esa parte, pero no me queda del todo claro a qué llaman ellos centro de facturación, en mi caso que es una pasarela ¿se considera sólo un centro porque el servidor cuenta como dispositivo único o como ellos ya lo tienen separado son varios centros que se conectan a la pasarela?


Mi duda surge porque en esa misma segunda pregunta ellos indican:
"Si son necesarios varios procesos de facturación (se podrían asimilar a centros de facturación) para dar respuesta a varios usuarios concurrentes de una misma empresa de forma paralela, se debería encadenar en orden temporal dentro de cada proceso o centro de facturación, con independencia de la serie. En este caso, debe existir un número acotado de procesos o colas de facturación, asociado al número de usuarios concurrentes por empresa emisora de facturas."


Y mi mayor duda es, si el encadenamiento puede ser distinto en base a los centros de facturación y en ningún lugar se indica el centro, ¿cómo comprueban ellos que estás realizando correctamente el encadenamiento?

La clave de firma ha sido revocada o es desconocida
 

Buenos días, como va todo ??? Os ha pasado alguna vez en el envio a Guipuzkoa que :

Avisen de firma revocada o desconocida :

enviando una factura simplificada T1-202022952.XML

00 ADMITIDO CON AVISOS TBAI-XXXXX-250423-C3U+ZoA/w4Idv-217 25-04-2023 10:50:05

Código 008 La clave de firma ha sido revocada o es desconocida

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<IdentificadorTBAI>TBAI-XXXXXXX-250423-C3U+ZoA/w4Idv-217</IdentificadorTBAI>
<FechaRecepcion>25-04-2023 10:50:05</FechaRecepcion>
<Estado>00</Estado>
<Descripcion>Recibido - ALTA</Descripcion>
<Azalpena>Jasota - ALTA</Azalpena>
<ResultadosValidacion>
<Codigo>008</Codigo>
<Descripcion>La clave de firma ha sido revocada o es desconocida</Descripcion>
<Azalpena>La clave de firma ha sido revocada o es desconocida</Azalpena>
</ResultadosValidacion>
<CSV>TBAIba6e5f10-e0c9-440d-a922-fd242e667f10</CSV>
</Salida>
</ns2:TicketBaiResponse>

En el siguiente envio en el mismo equipo se admita sin problemas ....
T1-202022952.XML

Y en el siguiente, lo rechazen directamente ...
T1-202022953.XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>25-04-2023 11:32:11</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado - ALTA</Descripcion>
<Azalpena>Baztertua - ALTA</Azalpena>
<ResultadosValidacion>
<Codigo>001</Codigo>
<Descripcion>Certificado remitente debe estar homologado y no revocado y no caducado (más de un mes) </Descripcion>
<Azalpena>Igorlearen ziurtagiria homologatuta, errebokatu gabea eta (hilabete baino gehiago) iraungi gabea egon behar da</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>


Alguna idea ???
Agradecido de antemano, un saludo a todos.

<En mi caso no estoy desglosando el coste unitario al no ser obligatorio>

Tengo entendido que en Bfa si es obligatorio informar de cada línea de detalle, salvo que sean facturas simplificadas.

Error en el envio al entorno de pruebas
 

Hola,

Usando Curl, despues de haber firmado con Autofirma con certificado personal, me da error el envio a Gipuzkoa
¿ Alguna idea por favor ?

Con esta llamada a Curl:
Obtengo este error:

Puede ser que estés mezclando el envío a Vizcaya en el CURL? Lo del gzip si no lo entiendo mal es solo en Vizcaya


Yo acabo de comprobar a subir a Guipuzcoa pruebas y me sube bien con este curl

Efectivamente, ese era el problema. A Guipuzcoa no se manda en formato gzip.
Lo he mandado como .xsig y se lo ha tragado. ¿ Tu tambien lo mandas firmado ? He probado a mandarlo sin firmar y no ha funcionado

Muchas gracias

Varias facturas
 

Buenos días,

Me imagino que en un mismo fichero .xml de alta o anulacion se pueden mandar varias facturas
Pero ¿ Qué es más conveniente ? ¿ Mandar una factura por .xml o varias en un .xml ?

Si se manda una a una puede ser lento
Si se manda varias en un .xml, algunos tipos de problemas relacionados con la estructura .xml o la codificacion pueden afectar a todas las facturas contenidas

¿ Qué opinais al respecto ?

******


Me autorespondo: En Gipuzkoa hay que mandar las facturas justo despues de imprimirlas asi que no cabe la posibilidad de agruparlas, al menos en el modo inmediato, que debe ser el habitual

En Álava y Guipuzcoa se envía 1 fichero de TicketBAI por factura.
En Vizcaya se pueden enviar N ticketBAI dentro de un fichero.

=> Ya que ellos no se han puesto de acuerdo, nosotros para estandarizar enviamos siempre 1 factura por fichero. De esa forma el proceso es siempre el mismo, simplemente cambiamos el constructor del fichero (y la pieza de envío). Pero la lógica es la misma para todas las facturas independientemente de la tributación.

Yo diría que eso es en el SII. Aquí las cosas van diferente.

En la documentación de Álava pone esto:
"b) Enviar a la Administración tributaria cada fichero informático generado según lo dispuesto en la letra a) anterior de forma inmediata (por lo que requiere conexión a Internet)."

O en la de Guipouzcoa que pone esto:
En el caso de Gipuzkoa, el envío de los ficheros TicketBAI debe llevarse a cabo de modo simultáneo a la expedición de la factura o justificante y online.

Nosotros lo hacemos al generar la factura (inmediato)

Muchas gracias estimado Neftalí.
Me viene mejor una a una porque el proceso es más sencillo
Lo veo peor porque requiere más conexiones.

En todo caso cuando sea facturacion a final de mes, no deberia/puedo hacer eso de enviar en modo inmediato. Habrá que mandar al finalizar la facturacion ¿ No crees ? Se trataria de aislar el proceso de facturacion (masivo) del envio

Correcto.
Eso ya es cuestión de evaluar cada caso concreto. Si ese tema es muy problemático, siempre puedes "mejorar" la implementación empaquetando N facturas, aunque recuerda que sólo sirve para Vizcaya.

Puedes realizar ambas cosas en paralelo.
Por ejemplo, creo recordar que hay por aquí alguien que ha implementado algo similar a una cola.
Al generar una factura, la encola y es otro proceso quien se encarga del envío. De esa forma, al generar una factura se encola y se envía "automáticamente" y si estás en un proceso batch tipo "Facturación automática de albaranes" (a final de mes), pues el proceso va generando facturas y encolando y es otro proceso quien las va enviando.

Hola,

Yo también lo hago así.
Un proceso va emitiendo las facturas y marcándolas para su envío.
Y un cronjob autónomo, que se arranca cada minuto, va enviando una a una todas las facturas pendientes de envío.

Saludos

Hola,

En Álava y Gipuzkoa es obligatorio informar cada línea de detalle (igual si son facturas completas como si son simplificadas)
En Bizkaia no es obligatorio informar las líneas de detalle de la factura.

Saludos

Duda Codigo de Pais
 

Buenas a todos.
Una nueva duda que me acaba de surgir. En el caso de clientes intracomunitarios, ¿en el código de país debe ir el ISO o el VATCode? En general son iguales pero hay algunas excepciones (Monaco, Irlanda del Norte o Grecia)