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

[ermendalenda]

Una cosa que acabo de pensar, si el usuario final fuerza un cambio de hora/fecha en el equipo, por ejemplo para marcar alguna factura que se le habia quedado atras,etc...
LA LIA PARDA
Me pongo a buscar pero si alguien tiene un webservice para agregar al programa de sincronizador de hora/fecha, ya que la de windows todos los cuñados saben desactivarla.

Esto se hace eterno.

[unomasmas]

Empezado por edari

Entiendo que el proceso que tengo que hacer es (en Vizcaya, modelo 240)

1) Al imprimir las facturas, genero el XML
2) Firmo el XML y dejo el fichero ahí
No subo nada de manera "automática" y luego desde un proceso en el que el usuario selecciona las facturas que quiere/tiene que subir
1) Seleccionas las facturas que tiene pendientes para subir
2) busco cada XML firmado que generé en su día (que esperemos que siga estando en su sitio y que nadie lo haya borrado ) que ha elegido el usuairo
3) Paso todas las facturas en ese momento a Base64
4) genero el fichero que le he puesto a mi compi Ramon88
5) Y lo subo

Sería así el proceso lógico??

Alava y Guipuzcoa tienen menos "riesgo" porque en medio miunuto tienes cada factura impresa, generada en xml, firmada y subida y ya no hay más que hacer...ya no puede meter la mano el usuario pero en Vizcaya me da mucho más miedo que puede pasar con esos ficheros.

Me dan ganas, fíjate, de hacer todo el proceso de subida a la vez de imprimir todas las facturas como en Alava y Guipuzcoa pero no tengo claro que es mejor...

Creo que no hay nada que te impida hacerlo así; es decir, tal y como se hace en Gipuzkoa: Generar XML, firmarlo, generar QR y subir la factura. Lo único que cambia es que en vez de subir únciamente el fichero, has de empaquetarlo dentro de otro xml tal y como dices.

Pero también se puede subir un bloque de ellos; el plazo para ello depende del tipo de empresa, creo que hasta tres meses... pero no tienes que esperar, con independencia del tipo de empresa puedes ir subiendo uno a uno cada vez que se genere; eso creo, al menos.

[rci]

Empezado por rci

Hola

Supongamos el caso que nuestro programa en algún momento tiene un problema para generar el fichero XML TicketBAI, por lo que sea, que el certificado está mal o que hay un error interno del programa que impide generar el fichero XML.
Tal como tenemos desarrollado el programa, si no se puede generar el fichero TicketBAI, no se puede salvar la factura ni imprimirla. Por lo tanto la tienda que utiliza nuestro programa, si ocurre algún problema de este tipo, tiene que dejar de vender porque no puede hacer facturas.
En una tienda grande con muchos TPVs y mucha clientela esto no es aceptable, no pueden dejar de trabajar.
Mientras no podamos solucionar el problema, ya sea del certificado o arreglando el programa... pueden pasar horas.

¿Cómo podemos gestionar en este caso?



Si desactivamos temporalmente TicketBAI para que puedan vender y facturar, las facturas que hagan en ése período no estarán firmadas y no tendran el QR y no se enviarán. Esto no es posible tampoco...



Es un tema que nos preocupa mucho. A ver como lo haceis vosotros.


Muchas gracias

Buenas, os envío la respuesta de Gipuzkoa, que es la única que ha contestado de momento. Viene a decir lo mismo que ya me habéis contestado vosotros.

Egun on, buenos días

En el caso que nos comenta, no se podrían generar ficheros TicketBAI. Estas situaciones se regulan en el artículo 17 del Decreto Foral 32/2020 del 22 de diciembre:

Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI.
1. En los supuestos excepcionales de interrupción del servicio eléctrico, de destrucción, fallo, avería, rotura u otras circunstancias en las que el contribuyente no pueda generar ficheros TicketBAI ni expedir factura o justificante empleando el software TicketBAI, y éstas deban ser expedidas en el momento de realizarse la operación, dicha circunstancia se notificará a la Administración tributaria y el contribuyente expedirá y entregará factura o justificante en papel a la persona o entidad destinataria, conservando copia del mismo.
La factura o justificante se consignará en una serie específica que se destinará únicamente a las facturas o justificantes expedidos en virtud de lo dispuesto en este artículo, y contendrá la expresión «factura o justificante expedido según lo dispuesto en el artículo 17 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre.»
2. El contribuyente, tan pronto desaparezca el motivo que imposibilite la generación de ficheros TicketBAI y la expedición de factura o justificante empleando el software TicketBAI, deberá introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas o justificantes expedidos, generando los ficheros TicketBAI y enviándolos a la Administración tributaria.
La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado.
En cualquier caso, la persona o entidad destinataria de la operación podrá solicitar un duplicado de la factura o justificante emitido, que contemple el código TicketBAI y el código QR.
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.

En estos casos o cuando por otras circunstancias el contribuyente no pueda generar ficheros TicketBAI ni expedir factura o justificante empleando el software TicketBAI, se notificará dicha circunstancia a la Administración tributaria mediante remisión de correo electrónico a la dirección ticketbai@gipuzkoa.eus y el contribuyente expedirá y entregará factura o justificante en papel a la persona o entidad destinataria, conservando copia del mismo. En dicho correo electrónico el contribuyente deberá indicar lo siguiente:
• Su identificación: Indicando su nombre o razón social y NIF/CIF.
• Causa que motiva la incidencia.
• En el asunto del correo electrónico se deberá indicar que se trata de una incidencia enumerada en el artículo 17.

La factura o justificante se consignará en una serie específica, y contendrá la expresión “factura o justificante expedida según lo dispuesto en el artículo 17”.

Tan pronto desaparezca el motivo que imposibilite la generación de ficheros TicketBAI y la expedición de factura o justificante empleando el software TicketBAI, deberá introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas generando los ficheros TicketBAI y enviándolos a la Administración tributaria.

La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado.

Un saludo,

Gracias por las respuestas

[JoseLeeTo]

[quote=edari;543543]En Vizcaya,creo por lo que entiendo, tienes que subir no un fichero xml con cada factura si no un fichero "resumen" con las facturas que quieras subir, pasadas a base64 y cada factura "incluida" dentro del campo <TicketBai> de este ejemplo

Buenos días,

Por lo que a mí me dieron a entender, en Vizcaya se puede enviar perfectamente un XML por factura o en bloque.
En Guipuzcoa y Alava hay que hacerlo obligatoriamente de forma inmediata y una por una.
Pero no creo que en Vizcaya haya limitación a enviar en bloques, sino que admite también una por una.

Pero ya tengo un follón en la cabeza que no sé de qué va cada cosa, y puedo estar equivocado.

¿Alguien me puede sacar de dudas?

Muchas gracias de antemano.
Un saludo

[Eric Mtz]

Hola señores, buenos días, tengo una duda que probablemente ya haya sido resuelta pero que no he sabido localizar en el foro, así que si me estoy repitiendo pido disculpas.

Veréis, estoy a tiro piedra del lanzamiento y por ello ando verificando que todas las URLs reales sean correctas, mi duda surge con las direcciones QR, concretamente con:

Araba/Álava: https://ticketbai.araba.eus/TBAI/QRTBAI (sin “/” para el cálculo del CRC).

Durante el desarrollo siempre utilicé la dirección de pruebas de Gipuzkoa, así que doy por hecho que los procesos están bien, pero lo de sin "/" me confunde un poco, ¿Se supone que se van a concatenar todos los datos sin la "/" inicial?, en plan:

"https://ticketbai.araba.eus/TBAI/QRTBAI?id=XXXXXXXXXXXXXXX&s=SSSSSS&nf=NNNNNNNNN..."

Queda un poco raro, pero si lo especifican supongo que será así, ¿Cómo lo hacéis vosotros?, gracias de antemano

[Ramon88]

Empezado por edari

En Vizcaya,creo por lo que entiendo, tienes que subir no un fichero xml con cada factura si no un fichero "resumen" con las facturas que quieras subir, pasadas a base64 y cada factura "incluida" dentro del campo <TicketBai> de este ejemplo



https://www.batuz.eus/fitxategiak/ba..._B00000034.xml


Este es el fichero que creo que hay que subir y comprimir...pero ya te digo que con Vizcaya soy igual de profano que tú...


Y aprovecho para preguntar mi duda


Tengo claro que Alava y Guipuzcoa se suben factura a factura cada xml por separado en el momento de generar la factura. Y no hay que discutir.



Por contra Vizcaya funciona un poco como el SII, es decir, es al final de día, o mejor dicho hay un plazo de tiempo (¿3-4 días?) en el que debes subir todas las facturas generadas días atras.


Entiendo que el proceso que tengo que hacer es (en Vizcaya, modelo 240)



1) Al imprimir las facturas, genero el XML
2) Firmo el XML y dejo el fichero ahí


No subo nada de manera "automática" y luego desde un proceso en el que el usuario selecciona las facturas que quiere/tiene que subir


1) Seleccionas las facturas que tiene pendientes para subir
2) busco cada XML firmado que generé en su día (que esperemos que siga estando en su sitio y que nadie lo haya borrado ) que ha elegido el usuairo
3) Paso todas las facturas en ese momento a Base64

4) genero el fichero que le he puesto a mi compi Ramon88
5) Y lo subo


Sería así el proceso lógico??


Alava y Guipuzcoa tienen menos "riesgo" porque en medio miunuto tienes cada factura impresa, generada en xml, firmada y subida y ya no hay más que hacer...ya no puede meter la mano el usuario pero en Vizcaya me da mucho más miedo que puede pasar con esos ficheros.


Me dan ganas, fíjate, de hacer todo el proceso de subida a la vez de imprimir todas las facturas como en Alava y Guipuzcoa pero no tengo claro que es mejor...


p.d.
Odio a los vizcaínos


Firmado
Un vizcaíno

Buenos días... Por decir algo!
Por que tienen que complicarnos tanto?

Entonces de que sirve el QR?? si no lo van a poder comprobar no funcionará hasta que subas el fichero? y pueden pasar 3 meses como comentais...

[misteradrian]

Hola de nuevo señoras y señores,
lo primero de todo muchas gracias por toda la información subida a este foro, con mención especial a bilbur por todo el tema del firmador en php, que me ha venido genial.

Y precisamente al utilizar este firmador me da una serie de fallos a la hora de dar de altas facturas que quisiera corregir.

A la hora de enviar las facturas me da el siguiente aviso.
008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#xmldsig-ea406c2f-bf64-e988-ed62-0b8afb482297-signedprops" failed to verify. [src/xml2signatureobj.cpp(315)]

y comprobando el xml con la herramienta de chillkat, me dice lo siguiente:

Signature Verified
Number of Reference Digests = 3
Reference 1 digest is invalid because the computed digest differs from the digest in the XML.
Reference 2 digest is valid.
Reference 3 digest is valid.

Qué casualmente coincide con el mismo campo de la respuesta de Gipuzkoa.
Supongo que viene dado por el valor de la variable,

Código PHP:

$this->SignedProperties 


que a su vez llama al generateGUID de el XMLTools de bilbur.

Código PHP:

$this->signatureID             = $tools->generateGUID('xmldsig-'); 


Pero revisando el foro no he sacado nada en claro sobre qué probar para modificar este error.
Supongo que tendré que modificar este XMLTools y generar un valor de digest válido, la cosa es que no sé cual.

Un saludo y gracias de antemano.

[edari]

Empezado por Ramon88

Buenos días... Por decir algo!
Por que tienen que complicarnos tanto?

Entonces de que sirve el QR?? si no lo van a poder comprobar no funcionará hasta que subas el fichero? y pueden pasar 3 meses como comentais...

Eso ya se ha hablado por aquí y efectivamente...mientras no subas esos ficheros no se pueden comprobar el QR


El chiste se cuenta solo

[rci]

Empezado por rci

Buenas, os envío la respuesta de Gipuzkoa, que es la única que ha contestado de momento. Viene a decir lo mismo que ya me habéis contestado vosotros.

Gracias por las respuestas

Hola, he recibido la respuesta de Bizkaia, en este caso entiendo que dan la opción de seguir facturando y imprimiendo sin el QR ni identificativo TBAI:

Kaixo,

El hecho de que se rompa el dispositivo mediante el cual se expiden los tickets o facturas TicketBAI, o haya otro problema que impida su emisión, no implica que el empresario no pueda seguir vendiendo o facturando. Las implicaciones de este caso son las siguientes:

• Se deberá seguir cumpliendo con la obligación de entregarle al cliente una factura o justificante de la operación. Las facturas o tickets deberán expedirse en papel o electrónicamente sin código QR y sin identificativo TicketBAI.

La información de esas facturas emitidas sin software garante tendrá que remitirse a la Diputación Foral de Bizkaia mediante los siguientes esquemas:

o Para el LROE de las personas físicas (modelo 140): 1.2 - Ingresos con factura sin Software garante.
o Para el LROE de las personas jurídicas (modelo 240): 1.2 - Facturas emitidas sin Software garante.

Al tratarse de una situación de incumplimiento de las obligaciones TicketBAI, la Administración tributaria podrá requerir al contribuyente que justifique esta situación y el contribuyente deberá conservar y aportar la oportuna documentación probatoria.


Si el caso fuera una avería en el dispositivo, dicho dispositivo averiado ha podido generar ficheros TicketBAI antes de estropearse y no haber hecho el envío de dichos ficheros a la Administración antes de que ocurra la avería. En el caso de Bizkaia, si los ficheros TicketBAI de facturas expedidas pueden recuperarse, se tendrán que enviar a Hacienda, dentro de anotaciones de los siguientes esquemas del LROE:

o 1.1 - Ingresos con factura con Software garante (modelo 140).
o 1.1 - Facturas emitidas con Software garante (modelo 240).

Sin embargo, si no pudieran recuperarse los ficheros TicketBAI, la información correspondiente a esas operaciones debe remitirse igualmente. Esta remisión deberá realizarse con el mensaje web correspondiente a los subcapítulos 1.2 -Ingresos con factura sin Software garante (modelo 140) y 1.2 - Facturas emitidas sin Software garante (modelo 240) de los LROE.

Agur bat.

Saludos

[misteradrian]

Empezado por misteradrian

Hola de nuevo señoras y señores,
lo primero de todo muchas gracias por toda la información subida a este foro, con mención especial a bilbur por todo el tema del firmador en php, que me ha venido genial.

Y precisamente al utilizar este firmador me da una serie de fallos a la hora de dar de altas facturas que quisiera corregir.

A la hora de enviar las facturas me da el siguiente aviso.
008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#xmldsig-ea406c2f-bf64-e988-ed62-0b8afb482297-signedprops" failed to verify. [src/xml2signatureobj.cpp(315)]

y comprobando el xml con la herramienta de chillkat, me dice lo siguiente:

Signature Verified
Number of Reference Digests = 3
Reference 1 digest is invalid because the computed digest differs from the digest in the XML.
Reference 2 digest is valid.
Reference 3 digest is valid.

Qué casualmente coincide con el mismo campo de la respuesta de Gipuzkoa.
Supongo que viene dado por el valor de la variable,

Código PHP:

$this->SignedProperties 


que a su vez llama al generateGUID de el XMLTools de bilbur.

Código PHP:

$this->signatureID             = $tools->generateGUID('xmldsig-'); 


Pero revisando el foro no he sacado nada en claro sobre qué probar para modificar este error.
Supongo que tendré que modificar este XMLTools y generar un valor de digest válido, la cosa es que no sé cual.

Un saludo y gracias de antemano.

Vale señor@s, me respondo a mí mismo por si a alguien le sirve.

He revisado de nuevo de arriba a abajo el foro y he encontrado el error. (Otra cosa es solucionarlo)

El error viene en concreto de un campo dentro de la firma

<ds:X509IssuerName>CN=AC Representación,  OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El certificado es un certificado de la FNMT y en el campo CN, la palabra Representación es la que me da errores a la hora de verificar el xml por chillkat, por la tilde en la ó.

Supongo que tendré que encontrar la manera de codificarlo de manera correcta en php, ya que tengo puesto el visual studio code a ISO 8859-1 y ticketbai lo requiere en utf-8.

Si corregís esta tílde a la hora de pasarlo a chillkat no os da ningún error y los 3 digest son válidos.

Un saludo y espero que sirva a los nuevos que venís con esto.

[rci]

Empezado por rci

Hola, he recibido la respuesta de Bizkaia, en este caso entiendo que dan la opción de seguir facturando y imprimiendo sin el QR ni identificativo TBAI:


Saludos

Buenas tardes, me han contestado de Araba, la respuesta es muy parecida a la de Gipuzkoa.

“Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI
1. En los supuestos excepcionales de interrupción del servicio eléctrico, de destrucción, fallo, avería, rotura u otras circunstancias en las que la o el contribuyente no pueda generar ficheros
TicketBAI ni expedir factura o justificante empleando el software TicketBAI, y éstas deban ser expedidas en el momento de realizarse la operación, dicha circunstancia se notificará a la Administración
Tributaria y la o el contribuyente expedirá y entregará factura o justificante por otros medios a la persona o entidad destinataria, conservando copia del mismo.
La factura o justificante se consignará a una serie específica que se destinará únicamente a las facturas o justificantes expedidos en virtud de lo dispuesto en este artículo, y contendrá
la expresión “factura o justificante expedido según lo dispuesto en el artículo 17 del Decreto Foral por el que se desarrolla la obligación TicketBAI”.
2. La o el contribuyente, tan pronto como desaparezca el motivo que imposibilite la generación de ficheros TicketBAI y la expedición de factura o justificante empleando el software
TicketBAI, deberá introducir correlativa y sucesivamente en su software TicketBAI los datos de todas las facturas y justificantes expedidos, generando los ficheros TicketBAI y enviándolos a
la Administración Tributaria.
La factura o justificante expedido por el software TicketBAI tendrá la consideración de duplicado. En cualquier caso, la persona o entidad destinataria de la operación podrá solicitar un duplicado
de la factura o justificante emitido, que contemple el código TicketBAI y el código QR.”

Es decir: si no se puede generar el fichero XML se deberá generar la factura por cualquier otro medio: papel o electrónico, expidiendo una factura o justificante en una serie especial con el contenido antes indicado. Cuando se solucione la avería se deberá introducir todas esas facturas o justificantes, de forma correlativa, en el sistema para que se generen los ficheros XML, se encadenen, se firmen y remitan a la Hacienda Foral.
De este modo no se compromete la facturación de la empresa.


Un saludo

Saludos y gracias

[ermendalenda]

Bueno ya tengo mi propia función para leer la hora y fecha actual y actualizar el equipo antes de cada factura de un webservice.
La única cosa que me falta en temas de verificación es un script php para saber la fecha de caducidad del certificado y ya redondeamos.
Decidme por favor que sabéis como sacar la fecha.
Gracias y saludos

[YellowStone]

Buenas.
¿Cómo evitar que al subir un código al foro, sustituya donde pone por un smile?
Por ejemplo en xadesigest
?

[ermendalenda]

Empezado por misteradrian

Vale señor@s, me respondo a mí mismo por si a alguien le sirve.

He revisado de nuevo de arriba a abajo el foro y he encontrado el error. (Otra cosa es solucionarlo)

El error viene en concreto de un campo dentro de la firma

<ds:X509IssuerName>CN=AC Representación,  OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El certificado es un certificado de la FNMT y en el campo CN, la palabra Representación es la que me da errores a la hora de verificar el xml por chillkat, por la tilde en la ó.

Supongo que tendré que encontrar la manera de codificarlo de manera correcta en php, ya que tengo puesto el visual studio code a ISO 8859-1 y ticketbai lo requiere en utf-8.

Si corregís esta tílde a la hora de pasarlo a chillkat no os da ningún error y los 3 digest son válidos.

Un saludo y espero que sirva a los nuevos que venís con esto.

Buenas, yo uso firmador.php y tengo ese acento y no me da problemas
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Chilkat valid en los 3 digest y sin errores al enviar.
Es extraño lo que dices, ya somos muchos los que lo usamos y hubiera dado más problemas.
Lo único que veo diferente es que entre la "," y "OU" (", OU=CERES") tienes 2 espacios, no creo que sea problema.
Tienes el XML con esta cabecera?
<?xml version="1.0" encoding="UTF-8"?>

[ermendalenda]

Empezado por ermendalenda

Bueno ya tengo mi propia función para leer la hora y fecha actual y actualizar el equipo antes de cada factura de un webservice.
La única cosa que me falta en temas de verificación es un script php para saber la fecha de caducidad del certificado y ya redondeamos.
Decidme por favor que sabéis como sacar la fecha.
Gracias y saludos

Listo, gracias.

[hago_preguntas]

Empezado por Eric Mtz

Hola señores, buenos días, tengo una duda que probablemente ya haya sido resuelta pero que no he sabido localizar en el foro, así que si me estoy repitiendo pido disculpas.

Veréis, estoy a tiro piedra del lanzamiento y por ello ando verificando que todas las URLs reales sean correctas, mi duda surge con las direcciones QR, concretamente con:



Durante el desarrollo siempre utilicé la dirección de pruebas de Gipuzkoa, así que doy por hecho que los procesos están bien, pero lo de sin "/" me confunde un poco, ¿Se supone que se van a concatenar todos los datos sin la "/" inicial?, en plan:



Queda un poco raro, pero si lo especifican supongo que será así, ¿Cómo lo hacéis vosotros?, gracias de antemano

Hasta donde yo entiendo la especificación, si es así como indicas, y además eso afecta al cálculo del código QR.

[thinkows]

Buenos días estimados contribuyentes, estoy en proceso de adquirir el certificado de firma de código tanto del ejecutable como para el del instalable (.msi) y tengo cierto lio de cual y donde adquirirlo, podéis compartir vuestra experiencia.

En otro orden de cosas ayer recibí un email de Guipuzkoa con recomendaciones y errores habituales, el la última línea indicaban que pronto publicaran la especificaciones de ZUZENDU a dos meses
vista de la puesta en marcha me parece una tomadura de pelo ....

[HerensugeBeltz]

Empezado por thinkows

Buenos días estimados contribuyentes, estoy en proceso de adquirir el certificado de firma de código tanto del ejecutable como para el del instalable (.msi) y tengo cierto lio de cual y donde adquirirlo, podéis compartir vuestra experiencia.

Nosotros compramos el de Sectigo (antiguo COMODO). Acabo de consultarlo y ahora lo tienes por 79$ (supongo que anuales).
https://sectigostore.com/page/cheap-...af6705f30498c5

[thinkows]

Muchas gracias compañero

[misteradrian]

Empezado por ermendalenda

Buenas, yo uso firmador.php y tengo ese acento y no me da problemas
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Chilkat valid en los 3 digest y sin errores al enviar.
Es extraño lo que dices, ya somos muchos los que lo usamos y hubiera dado más problemas.
Lo único que veo diferente es que entre la "," y "OU" (", OU=CERES") tienes 2 espacios, no creo que sea problema.
Tienes el XML con esta cabecera?
<?xml version="1.0" encoding="UTF-8"?>

Hola de nuevo lo primero de todo gracias por tu contestación.
Quizás no me expresé del todo bien. Efectivamente el firmador es una maravilla y funciona correctamente.
El caso es que yo tengo puesto mi editor de textos y los datos que obtengo en la base de datos en ISO8859-1 y el envío los requiere siempre en UTF-8.
Entonces cuando hay tildes se me transforman a caracteres extraños (Pasa lo mismo si en cualquier campo como el nombre lleva alguna tilde).
Y pues cuando lo visualizo y lo paso a chillkat o lo envío para ticketbai Gipuzkoa , los errores de la firma venían derivados de esos caracteres extraños por la codificación derivadas de las tildes.
Resumiendo, problemas de derivados de codifcación.

Lo único me ha surgido una duda nueva a ver si alguien me la puede responder.
¿La variable digest dentro del nuevo array POLITICA_FIRMA_ALAVA como lo puedo calcular?

Un saludo y mil gracias de nuevo de verdad,
sin este foro no podría estar tirando este proyecto hacia delante.