Error Tbai
 

Buenos días,

Estamos notando que a nuestros clientes de Álava les esta empezando a dar el error: 008 error de verificación de la firma. No hemos tocado nada y han estado funcionado sin problema hasta ahora.
No se si la dipu a cambiado algo o es un problema del servidor.

¿A alguien mas le ocurre?

Hola,

A nosotros, ahora mismo, nos está funcionando bien.
Pero ese mismo mensaje nos lo dió hace unos días durante unas horas.
Nos pusimos en contacto con TicketBAI de Álava y nos dijeron que utilizan los servicios de Izenpe para verificar las firmas.
Y parece que en algunas ocasiones falla.
Nos dijeron que como era un fallo por su parte, que no teníamos que hacer nada.
(Odiamos tener que usar Zuzendu si no es culpa nuestra)

Saludos.

Hola buenas.

Ya lo tengo solucionado, era el código de caracteres, hay que tratarlo en ANSI, y la respuesta hay que hacer lo mismo.

Me jode que la diputaciones forales no se pongan de acuerdo de como hacer un standard de presentación, en Bizkaia este problema no existe, lo puedes mandar en UNICODE y sin problemas, ni siquiera documenten estos pequeños detalles.

De momento en modo pruebas ya se recoge los XML enviados sin problemas, ahora ver el modo real, a ver que me encuentro.

Gracias a todos por la ayuda y saludos.

Error CURL Araba
 

Hasta ahora nos ha funcionado perfectamente, pero desde hoy tenemos el siguiente error al enviar el xml a la diputacion de Araba: GuzzleHttp\Exception\RequestException: cURL error 56: OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104.
A alguien mas le ha pasando? el erro nos lo da en producion y en el entorno de pruebas

Yo, de momento, estoy enviando sin problemas

Ya han actualizado las fechas de incorporación obligatoria de Bizkaia
Las fechas dependerán del tamaño de la empresa y de a que se dedica



https://www.batuz.eus/es/incorporacion-obligatoria

Como saber si un certificado está revocado
 

Buenas,

A ver si alguien me podría echar una mano....
Tengo el software de ticketbai enviando facturas a bizkaia y cada vez que envía comprueba que el certificado NO esté caducado. Pero claro, el problema viene , cuando antes de caducar la asesoría lo renueva pero desde que lo renueva hasta que se lo envía al cliente pasan 2 horas.

¿Qué ocurre? que todo los tickets que emitan en esas dos horas, mi software lo pasa por válido porque el certificado no está caducado (no ha llegado su fecha de caducidad) pero, sin embargo, está revocado porque cuando renuevas un certificado el antiguo automaticamente deja de ser válido.
Entonces diputación me responde con un error de que el certificado está revocado.

¿Sabéis cómo se puede implementar esa comprobación en PHP? Porque no encuentro ninguna función que me compruebe si un certificado está revocado.

Muchas gracias de antemano!!

Yo en su día había entendido que darían unos días "de gracias" para estos temas y que aceptarían mientras unos se caducaban y se renovaban.

Pues lo unico que ocurre es que el ticket no se registra en diputacion, y como no se puede volver a firmar porque un ticket ya emitido no se puede tocar pues he tenido que enviarlo por el capitulo 1.2 pero claro, quiero poder detectar el error antes de enviarlo a diputación...

Borrador modelo 303 Bizkaia
 

Hola, hace ya tiempo que no participo en el foro.

Parece que por fin han puesto el borrador del modelo 303 en Vizcaya, después de varios años promentiéndolo.

Adjunto link dónde indican como hacerlo https://streaming.bizkaia.eus/Lantik...lectronica.mp4

¿Si es de interés general, tal vez deberías publicarlo en noticias, pero no se si aplica al hilo de TicketBAI? ¿O si?

Buenos días a todos,

Estoy usando un TIdHttp de las Indy 10.6.2 para la comunicación con TicketBai, y tengo un problema de codificación cuando recupero el mensaje de respuesta que me dan desde Batuz en los headers.
Después de revisar el hilo, no he visto o no he sabido ver si alguien más tenía esta problemática y si la ha solucionado de algún modo. He probado forzando la codificación de la respuesta a UTF-8, guardar la lista de RawHeaders de la respuesta a un TStream y nada.

Ejemplo de las cabeceras que obtengo:
¿Alguien más se ha encontrado con esto?
Muchas gracias.

Un saludo

Buenas Neftali, si aplica a TicketBai, Batuz en Vizcaya puesto que el borrador del 303 sale en base a los datos que anteriormente se han enviado al Batuz.

Yo creo que el sistema te esta respondiendo bien. El error es que el interesado que estas intentando enviar facturas no esta dado de alta en bizkaia.

Correcto, el error lo estoy forzando para que me devuelva ese texto con la tilde. El problema lo tengo a la hora de recuperar ese texto de error para añadir al log.

Utilizo el siguiente código para obtener el resultado de la respuesta:
En vez de recuperar "El interesado no está identificado.", recupero "El interesado no est? identificado.".

Perfecto!
Gracias por la aclaración.

¿Has probado a cargar la respuesta en un TStringStream? En esta clase tienes algunas propiedades para "definir" la codificación que se usa.
Me refiero en lugar de cargarla directamente a una cadena.

Si, la respuesta la cargo en un TStingStream forzando la codificación a UTF8 y se lo paso al Post. Pero por lo visto esa codificación a Batuz no le gusta mucho.

Nosotros lo hacemos con TNetHTTPClient y responde bien las tildes.

He probado a utilizar IndyTextEncoding_8Bit sólo para Batuz y parece que ahora lo pinta bien, me parece curioso.

A nosotros nos está pasando en Guipúzcoa, en algún ticket suelto (todos se generan igual),aunque en la consulta de tickets emitidos sí que aparecen. Desde la hacienda foral me han dicho que son los aleatorios que comprueban, y que al parecer no se ha respetado la codificación UTF-8 en el proceso de envío, y que nos tenemos que asegurar de incluir “Content-Type: application/xml; charset=UTF-8” en la cabecera del HTTP del envío.

Las dos primeras líneas de nuestro fichero son:
<?xml version="1.0" encoding="utf-8"?>
<T:TicketBai xmlns:T="urn:ticketbai:emision">

Y no sé cómo deben ser para incluir lo que piden.

Hola,

Hacienda Foral de Álava acaba de publicar algunas modificaciones en el esquema de los ficheros TicketBAI.
https://web.araba.eus/documents/1050...en+PRUEBAS.pdf

Sería de agradecer que se suban a la documentación de este hilo.

Saludos

Estoy teniendo problemas con las anulaciones en gipuzcoa,
Me devuelve este error, pero yo lo veo todo bien:
Fichero no cumple el esquema XSD. Detalle del error: cvc-elt.1: Cannot find the declaration of element 'T:AnulaTicketBai'.

Prueba a poner esto en la segunda linea

Estaba cambiándolo pero termino de ver que me dicen que es por que estoy enviándolo al servicio de altas... La verdad que no tiene sentido por que lo tengo todo separado...

¿Qué certificado SSL estais usando para firmar vuestros softwares?
Nos acaba de caducar el que cogimos el año pasado:

Comodo Code Signing-certificate (1 year)
Price: €76.00 (excl. VAT).

Y ahora piden 314€ por un año

Hola, yo creo que la subida es generalizada, nosotros lo cogimos aquí https://www.ksoftware.net/code-signing-certificates/ y por el precio de un año de ahora cogimos tres. :eek:

Certificado de firma de código
 

Nosotros lo tenemos con Sectigo (pertenece a Comodo).
Acabo de consultar y hay certificados por 429$ para tres años.

https://www.sectigo.com/ssl-certific...s/code-signing

No es el precio por los tres años. Es para un año, dale a Add to cart y verás.

Han subido el precio por esto.

As of June 1, 2023, all Code Signing Certificates must comply with the new CA/B Forum regulations to ensure that the subscriber’s private key is generated, stored, and used in a suitable FIPS-compliant hardware. ​

Ahora recuerdo que ya se habló de esto en el foro.

Lo encontré https://www.clubdelphi.com/foros/sho...ificado+codigo

Correcto. Me ha confundido la frase que dice Free token with 3-year certificate

Bizkaia también lo tiene previsto modificar para comenzar a partir del 1 de enero. Lo más significativo son

Devengo facturas emitidas-recibidas
 

Buenos días, este es el primer mes que se hace automáticamente el modelo 303 del IVA en BFA con Batuz,

Los datos que tenemos en nuestra Base de Datos y los que ellos ponen nos descuadran totalmente.

Como consideráis vosotros el devengo del IVA, el el SII tenía en cuenta la fecha de operación en emitidas y la fecha de recepción en recibidas para la fecha de devengo

• Facturas emitidas, Devengo = fecha de operación o si esta no existe la fecha de factura
• Facturas recibidas, Devengo = fecha de Recepción de la factura en la empresa.

Podéis decirme si vosotros la consideráis de igual forma?

Hola, lo que consideramos nosotros no sirve de mucho. Hacienda hace lo siguiente https://www.batuz.eus/fitxategiak/sa...b24a83e2abf5c8, que es lo que tu pones.

Gracias Keys :)

Por si le puede interesar a alguien, me han respondido de la BFA y es como pensaba, por teléfono nos habían respondido diferente :mad: y generado la duda

Kaixo,

A efectos del devengo del IVA, se sigue este criterio:

- En las facturas expedidas, el devengo del IVA repercutido se produce en el periodo que corresponde a la fecha de operación. Si no hay fecha de operación, el devengo se produce en la fecha de expedición.
- En las facturas recibidas, el IVA soportado será deducible a partir del periodo al que corresponde la fecha de recepción, no antes. En las facturas recibidas se valida que la fecha de recepción no sea anterior a la fecha de expedición de la factura por el proveedor.
Agur bat.

error 008 el mensaje ha sido modificado en transito
 

Buenos días a todos:

Tengo problemas al enviar el fichero xml a Guipúzcoa pues me cambia los acentos y caracteres como la ñ, y me devuelve el error '008 El mensaje ha sido modificado en transito'.
Utilizo Delphi 11 y componentes RESTClient, RESTRequest y RESTResponse. el fichero firmado tiene codificación utf-8.
pero al enviarlo parece que no se respeta.
El código que utilizo es este:

Código Delphi [-]
procedure TForm1.Button15Click(Sender: TObject);
var
  Texto:String;
  S,ArchivoString: TStrings;
  f1:TextFile;
 FicheroAEnviar,ArchivoRespuesta : String;
begin

 RESTRequest1.Method :=TRESTRequestMethod.rmPOST;
 RESTRequest1.Accept:='utf-8';
 RESTRequest1.AcceptCharset:='utf-8;q=0.8';

 RESTClient1.SecureProtocols :=[THTTPSecureProtocol.TLS11,THTTPSecureProtocol.TLS12];
 RESTClient1.ContentType:= 'application/xml;charset=UTF-8';
 RESTClient1.AcceptEncoding:='utf-8;q=0.8';
 RESTClient1.OnNeedClientCertificate:=RESTClient1NeedClientCertificate;

 Opendialog1.Execute();
 FicheroAEnviar:=OpenDialog1.FileName;
 ArchivoRespuesta:=Copy(FicheroAEnviar,1,Length(FicheroAEnviar)-4)+'resp';

 ArchivoString := TStringList.Create();
 try
  ArchivoString.LoadFromFile(FicheroAEnviar,Tencoding.UTF8);
  RESTRequest1.addbody(ArchivoString.Text,ctAPPLICATION_XML);
 finally
  ArchivoString.Free;
 end;

 RESTRequest1.Execute;

 var CodigoRespuesta := RESTRespuesta.StatusCode;
 var Respuesta           := RESTRespuesta.Content;
 var Cabeceras           := RESTRespuesta.Headers;

 s := TStringList.Create();
 S.Add(RESTRespuesta.Content);
 S.SaveToFile(ArchivoRespuesta, TEncoding.UTF8);

end;

Si alguien puede ayudar estaré agradecido, pues ando desesperado, llevo casi dos semanas atascado con este problema, y ya estoy pensando en dejar al cliente.

Muchas gracias.

Hola.

¿Sólo te pasa con los envíos que tienen Ñ y acentos? Yo creo que el loadfromfile o el ArchivoString.Text te está cambiando algo en el fichero por la codificación. Yo los envíos los hago con TNetHTTPClient y no tengo ningún problema.

Un Saludo

Yo te diría que cambies el código para no coger el body de un fichero. La mayoría de los problemas de cambio de codificación son al pasar por diferentes pasos.
Intenta generarlo en memoria (Stream) y asignarlo al componente directamente sin pasar por fichero.

Gracias Keys,
¿tendrías algún ejemplo de como se hace con estos componentes?