Gracias Glaxian, el error era por el nombre del cliente que contenia un acento :-(, limpiando acentos y otros carácteres me ha funcionado con Chilckat

Precisamente para eso sirve la conversión a UTF8. Si algo con acentos lo conviertes a UTF8 antes de firmar no hay problemas.

Revisa mensajes anteriores del hilo. Hay varios códigos en varios lenguajes.
Si no también tienes una DLL que puedes llamarla para calcularlo.
Es este mensaje concretamente: http://clubdelphi.com/foros/showpost...&postcount=606

Socorro
 

AYUDA: Necesito a alguien que haya logrado cruzar el corredor de Kessel en menos de 12 parsecs.
Estoy seriamente desesperado así que intentaré documentar mi situación lo mejor que pueda.

Estoy pausado con el envío del 140 de BATUZ desde hace una maldita eternidad, he visto lunas pasar sin lograr avances, así que recurro a vosotros para mendigar un poco de sensatez.

Os pongo en situación, hace ya un tiempo que he logrado realizar envíos exitosos a BATUZ con el modelo 240, así que todo el tema pre-envío de construir, almacenar, encadenar, comprimir, parsear y todas las gilipolleces que se les han podido ocurrido a batuz están correctamente implementadas.

El tema es que adapté las clases relacionadas con el 240 al 140, eso incluye la clase donde van insertadas las facturas, la cabecera del propio envío y hasta la clase a la que parseo la respuesta. Pues aún así y tras decenas de comprobaciones me devuelve un “Error 505” vamos que el servidor me manda a freír puñetas sin mirar tan siquiera el contenido del envío.

Supongo que detecta algo mal dentro de la propia solicitud pero de verdad que ya no sé que hacer, a mi juicio solo hay dos cosas que juegan un papel importante a la hora de ser rechazados por el servidor (¡Ojo! rechazados, ni siquiera devuelto con errores) una es el certificado y la otra es la información de la cabecera del envío.

CABECERA:
Lo único que cambié en la cabecera frente al 240 es el campo de "eus-bizkaia-n3-data" que tal y como indican en la documentación les he añadido el nombre y los apellidos.
(Creo que sobra decirlo pero en las pruebas uso datos reales)

CERTIFICADO:
Preparaos que vienen curvas, probé con varios DNIs electrónicos, de autónomos y todo por si acaso fuera ese el error, solicité mi propio certificado de persona física y hasta con los certificados de pruebas que me han recomendado en éste foro, TODOS ME HAN DEVUELTO "Error 505"!!

Ando perdidísimo, no se si el error está en el certificado o he insertado en algún momento el correcto y hay algún otro dato mal, o si BATUZ me tiene manía... Ya no sé nada, al menos con el 240 el servidor me decía cosas como "El modelo está mal introducido" o "Faltan datos en tal sitio" pero ahora me rechazan cual leproso sin mirarme ni a la cara, ayuda, estoy a un par de envíos incorrectos de enviar un mensaje a batuz... pero de esos con la cara encapuchada y la voz distorsionada.

La función ....


Function TicketSI_CRC8(Huella As String)

Dim crc As Byte
Dim CRCtable1() As Variant
Dim i As Integer
Dim Data() As Byte
Dim Longitud As Integer

Data = StrConv(Huella, vbFromUnicode)
Longitud = UBound(Data()) + 1


crc = 0
CRCtable1 = Array( _
&H0, &H7, &HE, &H9, &H1C, &H1B, &H12, &H15, &H38, &H3F, &H36, &H31, &H24, &H23, &H2A, &H2D, &H70, &H77, &H7E, &H79, &H6C, &H6B, &H62, &H65, &H48, &H4F, &H46, &H41, &H54, &H53, &H5A, &H5D, _
&HE0, &HE7, &HEE, &HE9, &HFC, &HFB, &HF2, &HF5, &HD8, &HDF, &HD6, &HD1, &HC4, &HC3, &HCA, &HCD, &H90, &H97, &H9E, &H99, &H8C, &H8B, &H82, &H85, &HA8, &HAF, &HA6, &HA1, &HB4, &HB3, &HBA, &HBD, _
&HC7, &HC0, &HC9, &HCE, &HDB, &HDC, &HD5, &HD2, &HFF, &HF8, &HF1, &HF6, &HE3, &HE4, &HED, &HEA, &HB7, &HB0, &HB9, &HBE, &HAB, &HAC, &HA5, &HA2, &H8F, &H88, &H81, &H86, &H93, &H94, &H9D, &H9A, _
&H27, &H20, &H29, &H2E, &H3B, &H3C, &H35, &H32, &H1F, &H18, &H11, &H16, &H3, &H4, &HD, &HA, &H57, &H50, &H59, &H5E, &H4B, &H4C, &H45, &H42, &H6F, &H68, &H61, &H66, &H73, &H74, &H7D, &H7A, _
&H89, &H8E, &H87, &H80, &H95, &H92, &H9B, &H9C, &HB1, &HB6, &HBF, &HB8, &HAD, &HAA, &HA3, &HA4, &HF9, &HFE, &HF7, &HF0, &HE5, &HE2, &HEB, &HEC, &HC1, &HC6, &HCF, &HC8, &HDD, &HDA, &HD3, &HD4, _
&H69, &H6E, &H67, &H60, &H75, &H72, &H7B, &H7C, &H51, &H56, &H5F, &H58, &H4D, &H4A, &H43, &H44, &H19, &H1E, &H17, &H10, &H5, &H2, &HB, &HC, &H21, &H26, &H2F, &H28, &H3D, &H3A, &H33, &H34, _
&H4E, &H49, &H40, &H47, &H52, &H55, &H5C, &H5B, &H76, &H71, &H78, &H7F, &H6A, &H6D, &H64, &H63, &H3E, &H39, &H30, &H37, &H22, &H25, &H2C, &H2B, &H6, &H1, &H8, &HF, &H1A, &H1D, &H14, &H13, _
&HAE, &HA9, &HA0, &HA7, &HB2, &HB5, &HBC, &HBB, &H96, &H91, &H98, &H9F, &H8A, &H8D, &H84, &H83, &HDE, &HD9, &HD0, &HD7, &HC2, &HC5, &HCC, &HCB, &HE6, &HE1, &HE8, &HEF, &HFA, &HFD, &HF4, &HF3 _
)

For i = 0 To Longitud - 1
crc = CRCtable1((crc Xor Data(i)) And &HFF)
Next

TicketSI_CRC8 = Format(crc And &HFF, "000")

End Function

D E L U J O
 

Muy agradecido compañero!!!!

Gracias ^\||/, ya latenía casi hecha, estaba teniendo algún problema al intentar usar &HFFF,

Nuevo servicio SUBSANAR en julio
 

Buenas, antes de irme de vacaciones e intentar olvidarme de ticketBAI hasta la vuelta, os comunico que desde Gipuzkoa me han contestado esto:


Saludos y muchas gracias a todos.


Que os vayan bien las vacaciones cuando las hagáis!:D

Hola, estamos intentando enviar el fichero a Guipúzcoa y no hay manera. La factura la graba en el sistema, ya que si volvemos a enviar el mismo fichero nos devuelve que ya está registrada. Pero la primera vez nos retorna error con el siguiente mensaje: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)"
Toda la pinta tiene que es por lo que indicas arriba ya que si enviamos el mismo fichero con la aplicación SOAPUI todo es correcto. Usamos los componentes INDY (versión 10.6) que trae delphi (versión 10.2) para hacer el envío. Al final ¿con qué componentes o de qué manera haces el envío para que no modifique el fichero en el proceso?

Gracias de antemano

Aunque el mensaje diga eso, no te fies, no es que los componentes modifiquen el fichero en el envío.
Lo normal es que en algún punto del proceso, desde que generamos el fichero y lo firmamos, hasta que lo enviamos, sin querer estamos modficando la codificación.
A veces simplemente es al usar TStreams o grabar en disco y recuperar.

Revisad los pasos que estáis haciendo desde la firma hasta el envío y si en algún punto la codificación cambia, no porque lo hagáis expresamente, sino porque se esté haciendo sin daros cuenta.

En cuanto a los envíos en los mensajes del foro puedes ver que hay varios componentes que se están utilizando. En este mensaje tienes (en la parte inferior) un resumen de los diferentes componenetes que se usa para enviar:
https://www.clubdelphi.com/foros/sho...&postcount=436

* Opcion1: TNetHTTPClient
* Opción2: TRESTClient + TRESTRequest + TRESTResponse
* Opcion3: TsbxHTTPClient (SecureBlackBox)
* Opción4: Utilizando commandos CURL
* Opción5: Utilizando las Indy + OpenSSL
* ...

¿Alguien puede poner un ejemplo de algún archivo XML de anulación?

¡Qué rapidez! Gracias.

Hemos probado a enviar el fichero firmado generado directamente con funciones como:

Código Delphi [-]
IdHTTP1.Post(URL, SourceFile, ResponseStream);

o esta

Código Delphi [-]
sbxHTTPClient1.PostFile(URL, FileName);

En teoría así evitamos lo que comentas de cambio de codificaciones al cargar el fichero con Streams y compañía. El resultado es el mismo. Lo sorprendente es que si ese fichero lo enviamos con el programa SoapUI lo acepta sin problemas. Hemos "intentado" crear un LOG con los datos que se envían y comparado byte a byte con el nuestro y son idénticos.

Hemos probado todas las opciones y no hay manera, cada una nos falla en un punto diferente. Con la que más hemos conseguido es con las INDY del propio Delphi.

Gracias de nuevo de antemano.

Al no haber empezado con Batuz pues lo único que pruebes con el "sello_entidad_act.p12" de desarrollo de Izenpe (link) porque no te puedo ayudar con mucho más sorry...

Es un proceso algo similar a la emisión, crear la cabecera, codificar el xml del archivo ticketbai de la emisión en base 64, comprimirlo en gz y enviar la anulación.

Asegurate de enviarlo asi

Código Delphi [-]
idhttp1.Request.ContentType := 'application/xml; charset=utf-8"';

Perdona, se me olvidaba el fichero de anulación, esta firmado, hay que firmarlo al igual que el de la emisión.

En los ejemplos de Batuz creo que tienes varios XML de anulación. Los ficheros enviados y las diferentes respuestas, tanto para TicketBAI como para Batuz.
https://www.batuz.eus/fitxategiak/Ba...os/Ejemplos.7z

Sí, así lo tenemos pero no hay manera.

Código Delphi [-]
   ... 
    wXML := 'prueba.xsig';
    wURL := 'https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta';
    idhttp1.Request.ContentType := 'application/xml; charset=utf-8';
    IdHTTP1.Request.BasicAuthentication := False;
    wCer := 'CERT_TEST.pfx';
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.CertFile := wCer;
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.KeyFile  := wCer;

    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Mode   := sslmClient;
    IdSSLIOHandlerSocketOpenSSL1.SSLOptions.Method := sslvTLSv1_2; // sslvSSLv23; //sslvTLSv1_1;
    wML.Position := 0;
    Try
      IdHTTP1.Post(wURL, wXML, wMR);
      wMR.Position := 0;
      memo1.Lines.LoadFromStream(wMR, TEncoding.UTF8);
      label1.Caption := IntToStr(IdHTTP1.Response.ResponseCode) + ': ' + IdHTTP1.Response.ResponseText;
    Except
      On E:Exception do
        memo1.Lines.Add(E.Message);
    End;

Gracias por la respuesta.

Hola, a mi me pasaba lo mismo me volví loco con la codificación utf-8, al final el problema era que el nombre del cliente tenía un acento, limpia de carácteres un poco raros todos los strings y prueba, yo tras hacer eso puedo enviar sin problema.


Suerte

Hola, ya hemos revisado eso también y efectivamente el acento lo tiene la propia firma ("CN=AC Representación") y no somos capaces de quitarlo ya que si lo hacemos entonces salta que el certificado ha sido modificado. Lo hemos intentado limpiar en el evento OnFormatText del componente TElXMLSigner de SecureBlackBox, sin resultado. De hecho por eso empezamos esta pregunta citando el caso de Neftali ya que no solo lo resolvió si no que está probando con una empresa llamada "áéíóúÁÉÍÓÚÜçÇñÑ€~#@". ¡Tela! :)

Un saludo y gracias por las respuestas.

Los dos casos se resuelven codificando el XML de ANSI a UTF8 ANTES de firmarlo. He hecho multitud de pruebas y todas han sido aceptadas. Es más, varios de mis clientes que ya están haciendo las "pruebas de campo" tienen, a su vez, clientes cuyo nombre contiene acentos y/o eñes y ningún problema.

Hola y muchas gracias por la respuesta. He llegado a un momento en el que dudo de todo, así que creo que eso también lo he probado. Entre otras formas de esta, ya no sé si será correcta o no:

Código Delphi [-]
  slXML := TStringList.Create;
  Try
    slXML.LoadFromFile('test_TBAI.xml');
    slXML.SaveToFile('test_TBAI_utf8.xml', TEncoding.UTF8);
  Finally
    slXML.Free;
  end;

Haciendo ese paso previo (también probado con la clase "TUTF8NoBOMEncoding" que indicaba un delphiano de este mismo foro) la respuesta es:

Un saludo

Da igual que lo intentes codificar si tiene caracteres inválidos para la codificación te va a poner otra.
Es mejor que conviertas previamente los caracteres raros. Yo tenia problemas con esto porque lo genero lo guardo y luego lo vuelvo a leer y en ese me momento me cambia la codificación como tenga cosas raras.

QR en CR8.5
 

Hola,

Yo también uso CR8.5 para los formatos de facturas, ¿¿¿me podrias decir cómo haces para meter el QR???

Muchas gracias!

Mi profecia se hace realidad. :D

https://web.bizkaia.eus/es/web/area-...%2Fes%2Finicio

Con permiso del moderador me cago en toooo

Aplazamiento de Batuz (Bizkaia)
 

Acabo de recibir este correo:

Kaixo,

Aplazamiento en la obligatoriedad de Batuz y nuevos incentivos para su implantación voluntaria.

Tras recabar las aportaciones de colegios profesionales y asociaciones empresariales y de la asesoría fiscal, la Hacienda Foral considera conveniente flexibilizar el plazo establecido para la adopción obligatoria de Batuz, trasladándolo hasta el 1 de enero de 2024, y estableciendo una compensación de hasta el 15% en IRPF o Sociedades para los autónomos, microempresas y pymes que implanten Batuz en 2022 o 2023. Para más información pulse aquí.

Agur bat.

Permiso concedido.

Nuevo correo (Gipuzkoa)
 

También tenemos noticias de Gipuzkoa:

Estimado/as Señores/as

La Ley 10/1982 de Normalización del Uso del Euskera establece que todos los ciudadanos y ciudadanas vascas tienen derecho a expresarse en euskera en todos los ámbitos de la vida social. En desarrollo de este derecho que la ley reconoce a la ciudadanía, el Decreto 123/2008 reguló los derechos lingüísticos de las personas consumidoras y usuarias, entre otros, en su artículo 5, establece que determinadas entidades (como, por ejemplo, prestadoras de servicios universales de interés general o análogos, grandes establecimientos, financieras o de crédito y promotoras de edificación) deben garantizar que los escritos o comunicaciones dirigidas a las personas consumidoras y usuarias se realicen en euskera, así como las facturas o justificantes de las operaciones realizadas.

Dado que el sistema de facturación TicketBAI será obligatorio a partir del 1 de enero de 2022 (según el calendario de implantación), las instituciones promotoras del proyecto (las Diputaciones Forales y el Gobierno Vasco) consideramos muy importante impulsar que los programas que se inscriban en el Registro de software TicketBAI sean adaptados, para que el ticket o factura que recibirá el cliente esté en euskera. Así, además de respetar el derecho lingüístico reconocido a los clientes, prestaremos un mejor servicio a través del sistema TicketBAI.

La Diputación Foral de Gipuzkoa ofrece el apoyo necesario a los desarrolladores de software TicketBAI, así como a las entidades que están realizando la labor de difusión, aportando en los dos idiomas oficiales los contenidos de la plantilla de la factura que genera el sistema.

También tienen a su disposición el buzón de correo electrónico [email protected] donde pueden dirigirse para solicitar nuestra ayuda, en caso de cualquier duda o dificultad.

Hay una gran demanda en nuestra sociedad de herramientas que permitan vivir y trabajar en euskera, por lo que animamos a todos los desarrolladores de software a que contemplen esta posibilidad en sus herramientas informáticas, para lo cual contarán con todo el apoyo de esta administración.

Reciban un cordial saludo

Aplazamiento BATUZ
 

Tocate la seta y baila !!!!! alguien sabe algo de GUIPUZKOA y ARABA ???? :cool::cool::cool:

No puedo ayudarte mucho con SBB porque yo uso Chilkat, pero haz lo siguiente:
Comprueba si la función slXML.LoadFromFile tiene un parámetro para establecer la codificación.
Vuelve a leerlo tras codificarlo y comprueba que está bien codificado.

¡¡¡Los disgustos de uno en uno!!!, si alguien tiene mas boletines que publicar que primero lo suavice dando el pronóstico del tiempo, gracias.

Entonces de momento solo hay que preocuparse por Guipuzkoa no? Genial!

Depende de tus clientes. Ya que es opcional hasta el 2024

Guipuzkoa sin novedad, Álava, como hemos comentado anteriormente, habrá noticias a partir de Septiembre.
Pero tiene pinta de que Álava será bastante similar a Guipuzkoa (y si son listos "aprenderán" de lo que está pasando con BATUZ) .

Problema comprobación Factura
 

Buenas!

Estoy trabajando con Gipuzkoa en la generación del QR de la factura y, previamente, construyo la URL que es la siguiente:

Genero el QR y ya sea por url o código, me lleva a la pantalla de verificación de TBAI , introduzco el captcha pero me dice lo siguiente:

"Ezin izan da fakturaren egoera zehaztu - No se ha podido determinar el estado de la factura."

Alguna sugerencia?

Pruebas Guipuzkoa
 

Tienes que cambiar la URL,la que tienes es la de producción cambia a esta y te funcionará

"//tbai.prep.gipuzkoa.eus/qr/"

Funciona! Muchas gracias!

Hola a todos. Descubrí el fin de semana este foro y me ha costado un montón de horas pasar por todas las páginas, pero ha valido la pena.
Estoy acabando el desarrollo del TBAI y ya sudaba tinta negra pensando en el LROE y entonces veo esta noticia de hoy respecto del aplazamiento de BATUZ y, perdonad mi ignorancia en la lectura entre líneas del comunicado, pero, alguien tiene claro si el aplazamiento hasta 2024 se refiere solo a LROE o también a TBAI? Gracias y un saludo!

Os ha llegado un email de BATUZ ?
 

Aplazamiento en la obligatoriedad de Batuz y nuevos incentivos para su implantación voluntaria.

Tras recabar las aportaciones de colegios profesionales y asociaciones empresariales y de la asesoría fiscal, la Hacienda Foral considera conveniente flexibilizar el plazo establecido para la adopción obligatoria de Batuz, trasladándolo hasta el 1 de enero de 2024, y estableciendo una compensación de hasta el 15% en IRPF o Sociedades para los autónomos, microempresas y pymes que implanten Batuz en 2022 o 2023. Para más información pulse

Esto es extensivo a las otras provincias o solo es para Bizcaia ?

El Mail es de Vizcaya y se refiere sólo a Batuz (LROE).
Los plazos para TicketBAI (Guipuzcoa y Álava) siguen como estaban.