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

[YellowStone]

Empezado por Toñico

Hola a todos.

Antes que nada pido disculpas si cometo algún error ya que es mi primer mensaje en este foro.

Necesito vuestra ayuda porque estoy bloqueado.

Estoy intentando enviar a Bizcaia un fichero LROE 240 y para ello estoy utilizando Delphi 10.3 Rio y los componentes Indy HTTP y TIdSSLIOHandlerSocketOpenSSL.

El fichero que estoy enviando es un gzip que contiene el xml según la documentación.

Esta es mi forma de hacerlo con INDY pero en Delphi 2007, tampoco creo que varié mucho.

"cuerpo" es el cuerpo del envío, previamente convertido ya a GZIP.
"data" son los datos de la empresa a pasar en JSON.
"datosCertificado" no es más que un "record" con los datos que necesito del certificado.

Observa que no envío "content-length" en la cabecera, lo quité porque si lo mandaba, daba error.

Espero que te sirva para encontrar el problema.

function IndyPostBatuz(cuerpo: TMemoryStream; data: string; datosCertificado: TDatosCertificado): IXMLDocument;
var IdHTTP: TIdHTTP;
    LHandler: TIdSSLIOHandlerSocketOpenSSL;
    rGetCertificado: TGetCertificado;
    sRespuesta, slXML: TStringList;
    msRespuesta: TMemoryStream;
    sXML, sTipo, sCodigo, sMensaje: string;
begin
  rGetCertificado := TGetCertificado.Create;
  IdHTTP := TIdHTTP.Create(nil);
  result := TXMLDocument.Create(nil);
  try
    // Configuramos la cabecera específica para Bizkaia
    IdHTTP.Request.CustomHeaders.AddValue('Accept-Encoding', 'gzip');
    IdHTTP.Request.CustomHeaders.AddValue('Content-Encoding', 'gzip');
    //IdHTTP.Request.CustomHeaders.AddValue('Content-Length', IntToStr(cuerpo.Size)); // Finalmente, este dato no es necesario mandarlo, aparte de que si lo mandamos, da error
    IdHTTP.Request.CustomHeaders.AddValue('Content-Type', 'application/octet-stream');
    IdHTTP.Request.CustomHeaders.AddValue('eus-bizkaia-n3-version', '1.0');
    IdHTTP.Request.CustomHeaders.AddValue('eus-bizkaia-n3-content-type', 'application/xml');
    IdHTTP.Request.CustomHeaders.AddValue('eus-bizkaia-n3-data', data);
    LHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
    try
      LHandler.sslOptions.Method := sslvTLSv1_2;
      LHandler.sslOptions.SSLVersions := [sslvTLSv1_2];
      LHandler.SSLOptions.CertFile := rDatosCertificado.RutaCertificado; // Certificado de dispositivo a usar
      LHandler.SSLOptions.KeyFile := rDatosCertificado.RutaCertificado;  // Certificado de dispositivo a usar (el mismo que cerfile)
      LHandler.OnGetPassword := rGetCertificado.hServidorGetPassword;    // Cuando se solicite la clave, el evento se encarga de aportarla
      IdHTTP.IOHandler := LHandler;
      sRespuesta := TStringList.Create;    // La respuesta la recogemos en un stringlist;

      msRespuesta := TMemoryStream.Create; // Stream que va a recoger el contenido en gzip. Desgraciadamente, Indy no tiene un Post en el que tanto petición como respuesta puedan ser Stream.

      try
        sRespuesta.Append(IdHTTP.Post(xrTicketbai.URL, cuerpo, IndyTextEncoding_UTF8)); // Enviamos la petición y la recogemos en un StringList;
      except
        on E:Exception do
          begin
            ShowMessage(E.message);
          end;
      end;

      sTipo := idHTTP.Response.RawHeaders.Values['eus-bizkaia-n3-tipo-respuesta']; // Tipo de Respuesta. Si todo ha ido bien, es "Correcto"
      sCodigo := idHTTP.Response.RawHeaders.Values['eus-bizkaia-n3-codigo-respuesta']; // Si sTipo no es "Correcto" entonce viene el código de error
      sMensaje := idHTTP.Response.RawHeaders.Values['eus-bizkaia-n3-mensaje-respuesta']; // y el mensaje de error correspondiente
      sIdentificativoBatuz := idHTTP.Response.RawHeaders.Values['eus-bizkaia-n3-identificativo']; // Aquí recogemos el identificativo, que viene en la cabecera de la respuesta

      if sCodigo <> '' then
        begin
          ShowMessage('Tipo de respuesta: '+sTipo+#13#10+
                      'Codigo de respuesta: '+sCodigo+#13#10+
                      'Mensaje de respuesta: '+sMensaje);
        end;

      sRespuesta.SaveToStream(msRespuesta);  // Grabamos la respuesta en un Stream de memoria.

      if msRespuesta.Size > 0 then
        begin
          msRespuesta.Position := 0;   // Importante posicionarse en 0, para que se pueda descomprimir correctamente
          sXML := gZipToxmlModeloStream(msRespuesta);  // Descomprimimos el stream de la respuesta en un string

          try
            result.Active := False;
            result.XML.Clear;
            result.XML.Text := LimpiaRespuesta(sXML);  // Pasamos el string de la respuesta a un txmldocument
          finally
            FreeAndNil(msRespuesta);
          end;
        end;
    finally
      LHandler.Free;
    end;
  finally
    IdHTTP.Disconnect;
    IdHTTP.Free;
  end;
end;

[Toñico]

Muchísimas gracias YellowStone

Ahora si que me funciona. Me devuelve un error que puedo leer:

eus-bizkaia-n3-identificativo: 113248123
eus-bizkaia-n3-mensaje-respuesta: No se encuentra el certificado del dispositivo dentro del censo de certificados de dispositivo de la DFB. El número de serie del certificado de dispositivo utilizado es: 616ac435f1f8d99862d144d96f27ce32
eus-bizkaia-n3-codigo-respuesta: N3_0000016
eus-bizkaia-n3-numero-registro:
eus-bizkaia-n3-tipo-respuesta: Incorrecto

Estoy usando el certificado suministrado por ellos, así que les preguntaré.

Una vez mas, muchísimas gracias.

[YellowStone]

Empezado por keys

Entonces mándaselo a hacienda. Te dije eso por que a nosotros nos paso que la fecha de factura era del 2023 y la de operación del 2022 y esas hay que enviarlas al libro del 2023.

Buenas, Keys:


Disculpa que suba este mensaje de hace un año.



Como hemos empezado a mediados del 2024 con Batuz, no nos había pasado esto hasta ahora.


Cliente que factura a primeros de 2025, fecha de expedición evidentemente 2025, pero fecha de las operaciones 2024. Hemos mandado 2024 como ejercicio, pero nos da el error B4_2000017 que dice que la fecha de expedición debe corresponder con el ejercicio del libro. ¿Opinas que esto es correcto? Las operaciones deben tenerse en cuenta para el IVA del último trimestre del ejercicio 2024. Aunque ponga 2025 en el ejercicio de la cabecera, supongo que ellos lo tendrán en cuenta para que esas operaciones se contabilicen en 2024, no?

[keys]

Empezado por YellowStone

Buenas, Keys:


Disculpa que suba este mensaje de hace un año.



Como hemos empezado a mediados del 2024 con Batuz, no nos había pasado esto hasta ahora.


Cliente que factura a primeros de 2025, fecha de expedición evidentemente 2025, pero fecha de las operaciones 2024. Hemos mandado 2024 como ejercicio, pero nos da el error B4_2000017 que dice que la fecha de expedición debe corresponder con el ejercicio del libro. ¿Opinas que esto es correcto? Las operaciones deben tenerse en cuenta para el IVA del último trimestre del ejercicio 2024. Aunque ponga 2025 en el ejercicio de la cabecera, supongo que ellos lo tendrán en cuenta para que esas operaciones se contabilicen en 2024, no?

En el ejercicio hay que poner 2025 ya que la fecha de expedición factura es del 2025. Luego hacienda lo tendrá en cuenta en función de la fecha de operación para calcular el iva en las facturas normales, no las rectificativas. Te dejo este enlace donde se especifica como hacienda hace el cálculo de del borrador del iva. https://www.batuz.eus/fitxategiak/ba...6b61aa130ce1dc

[YellowStone]

Muchas gracias. Ya lo hemos puesto así, entendido. Gracias por el enlace.

[Toñico]

Hola a todos. Estoy haciendo pruebas de enviar ficheros tanto de modificación como de anulación al servicio de Zuzendu y también de anulación al servicio ticketbai. Todas las llamadas las hago a las urls de test de Gipuzkoa.

Estoy realizando las llamadas usando un certificado de dispositivo propio. Este mismo certificado lo estoy usando para el envío de ficheros de alta ticketbai y no tengo ningún problema.

Pues bien, tanto Zuzendu como la anulación el error que me devuelve es el mismo: 013 - Falta aceptar el Registro del Dispositivo remitente....

El emisor del mensaje que estoy usando también es el de test: 99999990S CIUDADANO FICTICIO ACTIVO.

¿Podéis indicarme que tipo de certificado tengo que usar? No creo que pueda/deba registrar mi certificado para un emisor de test como es el caso.

Muchas gracias de antemano.

[keys]

Empezado por Toñico

Hola a todos. Estoy haciendo pruebas de enviar ficheros tanto de modificación como de anulación al servicio de Zuzendu y también de anulación al servicio ticketbai. Todas las llamadas las hago a las urls de test de Gipuzkoa.

Estoy realizando las llamadas usando un certificado de dispositivo propio. Este mismo certificado lo estoy usando para el envío de ficheros de alta ticketbai y no tengo ningún problema.

Pues bien, tanto Zuzendu como la anulación el error que me devuelve es el mismo: 013 - Falta aceptar el Registro del Dispositivo remitente....

El emisor del mensaje que estoy usando también es el de test: 99999990S CIUDADANO FICTICIO ACTIVO.

¿Podéis indicarme que tipo de certificado tengo que usar? No creo que pueda/deba registrar mi certificado para un emisor de test como es el caso.

Muchas gracias de antemano.

Ese certificado ahora no vale por que no lo tienen dado de alta para zuzendu para esa empresa. Yo creo que tendrías que hablar con hacienda o usar una empresa que si tenga dado de alta ese certificado.

[Toñico]

Empezado por keys

Ese certificado ahora no vale por que no lo tienen dado de alta para zuzendu para esa empresa. Yo creo que tendrías que hablar con hacienda o usar una empresa que si tenga dado de alta ese certificado.

Muchas gracias keys. Lo voy moviendo.

[Quim Herrera]

Hola a todos,
Tengo un par de clientes a los que les han rechazado algunas facturas en Bizkaia. En Hacienda me dicen que las tengo que volver a enviar por el capítulo 1.2. pero ninguna información ni ejemplo de dónde ni como mandarlo.
He visto algún ejemplo del XML de capitulo 1.2 en el foro, pero no sé si debe ir firmado ni como se manda ni si hay que generar e incluir el ticketBAI nuevo. ¿ Alguien tiene algún ejemplo de como mandarlo o sabe dónde puedo encontrar documentación ?
Utilizo Delphi 10.2 y chilkat para la firma.
Muchas gracias

[rci]

Empezado por Quim Herrera

Hola a todos,
Tengo un par de clientes a los que les han rechazado algunas facturas en Bizkaia. En Hacienda me dicen que las tengo que volver a enviar por el capítulo 1.2. pero ninguna información ni ejemplo de dónde ni como mandarlo.
He visto algún ejemplo del XML de capitulo 1.2 en el foro, pero no sé si debe ir firmado ni como se manda ni si hay que generar e incluir el ticketBAI nuevo. ¿ Alguien tiene algún ejemplo de como mandarlo o sabe dónde puedo encontrar documentación ?
Utilizo Delphi 10.2 y chilkat para la firma.
Muchas gracias

En Bizkaia (Batuz), cuando una factura expedida mediante el sistema TicketBAI es rechazada en el subcapítulo "1.1 - Facturas emitidas con software garante", la información de la operación se tendrá que enviar por el subcapítulo "1.2 - Facturas emitidas sin software garante", superando las validaciones.
Es decir, en el subcapítulo 1.2 se tendrán que corregir los errores que han provocado que la factura no se pueda anotar en el subcapítulo 1.1 (por ejemplo, si el NIF del destinatario no cumple el algoritmo del NIF).
De este modo la operación que no se ha podido registrar mediante el subcapítulo 1.1 quedaría anotada en el LROE y presentada en Hacienda.
La anotación en el subcapítulo 1.2 se puede hacer manualmente mediante la aplicación del LROE https://www.batuz.eus/es/lroe

Nuestro programa solo está preparado para enviar de forma normal, al subcapítulo 1.1 con software garante.
Cuando ocurre algún caso como el que comentas, el cliente introduce manualmente la factura por la web al subcapítulo 1.2
Desconozco si se puede enviar al 1.2 desde programa de forma similar a como enviamos las facturas habitualmente (al 1.1), es posible pero no estoy seguro y tampoco se como hacerlo.
No se si alguien lo hace en su programa.

Saludos

[Quim Herrera]

Empezado por rci

Nuestro programa solo está preparado para enviar de forma normal, al subcapítulo 1.1 con software garante.
Cuando ocurre algún caso como el que comentas, el cliente introduce manualmente la factura por la web al subcapítulo 1.2
Desconozco si se puede enviar al 1.2 desde programa de forma similar a como enviamos las facturas habitualmente (al 1.1), es posible pero no estoy seguro y tampoco se como hacerlo.
No se si alguien lo hace en su programa.

Saludos

Muchas gracias rci !! me has salvado la vida.
Aún no me había encontrado con tener que reenviar rechazadas .
Yo estaba convencido que podria hacerse manualmente pero en Hacienda no han querido confirmarme que se podia enviar manualmente ni donde (tampoco lo han desmentido). Se dedican a cortar y pegar la FAQ 160 de Batuz que no explica nada de como enviarlo.
Saludos,

[rci]

Empezado por Quim Herrera

Muchas gracias rci !! me has salvado la vida.
Aún no me había encontrado con tener que reenviar rechazadas .
Yo estaba convencido que podria hacerse manualmente pero en Hacienda no han querido confirmarme que se podia enviar manualmente ni donde (tampoco lo han desmentido). Se dedican a cortar y pegar la FAQ 160 de Batuz que no explica nada de como enviarlo.
Saludos,

De nada!

Mira he encontrado este post con un ejemplo, por lo que veo si que se puede enviar por programa también.
https://www.clubdelphi.com/foros/sho...postcount=3832

Si quieres hacerlo desde tu programa puede que te ayude este post. Sino que lo entren a mano por la web de batuz

Saludos

[Quim Herrera]

Empezado por rci

De nada!

Mira he encontrado este post con un ejemplo, por lo que veo si que se puede enviar por programa también.
https://www.clubdelphi.com/foros/sho...postcount=3832

Si quieres hacerlo desde tu programa puede que te ayude este post. Sino que lo entren a mano por la web de batuz

Saludos

Lo había visto y he contruido un xml como el del ejemplo con una factura rechazada en pruebas pero no he sido capaz de enviarlo a la web de pruebas. Dejaré que lo resuelvan manualmente ya que es muy difícil saber en cada caso que es lo que hay que cambiar para que vuelva a cargar. Que se mojen un poco los asesores fiscales que nosotros ya tenemos suficiente carga!
Saludos,

[Noe277]

Una pregunta. Haber si alguien me puede decir donde esta la información para corregir una facturara enviada a Batuz.
Solo tengo mal la clave de operación pero no se como reenviarla para corregirla.

[keys]

Empezado por Noe277

Una pregunta. Haber si alguien me puede decir donde esta la información para corregir una facturara enviada a Batuz.
Solo tengo mal la clave de operación pero no se como reenviarla para corregirla.

Creo que la tienes que enviar por software no garante. Bizkaia no tiene el servicio zuzendu como el resto de las haciendas.

[infoser101]

No se si esta pregunta esta ya mas que superada en el foro, pero soy incapaz de encontrar un sitio con todos los XSD para enviar facturas a Verifactu.

La dirección de la AEAT que pone todo el mundo es:
https://www.agenciatributaria.es/AEA...racion_y_Siste[/i]mas_VERI_FACTU.html
[/i]
El unico esquema de envio que hay es:
https://prewww2.aeat.es/static_files...ministroLR.xsd

Este esquema detalla solo los tipos de alto nivel:

.......
<element name="RegFactuSistemaFacturacion">
<complexType>
<sequence>
<element name="Cabecera" type="sf:CabeceraType"/>
<element name="RegistroFactura" type="sfLR:RegistroFacturaType" maxOccurs="1000"/>
</sequence>
</complexType>
</element>
<complexType name="RegistroFacturaType">
<annotation>
<documentation xml:lang="es">Datos correspondientes a los registros de facturacion</documentation>
</annotation>
<sequence>
<choice>
<element ref="sf:RegistroAlta"/>
<element ref="sf:RegistroAnulacion"/>
</choice>
</sequence>
</complexType>

Cuando se abre este esquema, por ejemplo con XMLNotepad, no se abren los tipo tales como "RegistroAlta", cosa que si ocurría en Ticketbai y Batuz
¿Sabéis como se abren estos esquemas completos, sin ir mirando tipo a tipo?

[Neftali [Germán.Estévez]]

Empezado por Noe277

Una pregunta. Haber si alguien me puede decir donde esta la información para corregir una facturara enviada a Batuz.
Solo tengo mal la clave de operación pero no se como reenviarla para corregirla.

Debes convertirla al Libro 240 sin software garante y volver a enviarla.
El formato de este libro es diferente al habitual (240 con software garante).

En esta página, en la parte de abajo, tienes documentación técnica.
Esto apunta a los esquemas. Y si navegas por esa página, llegas a este fichero zip, que contiene todos los esquemas. Entre ellos los correspondientes al envío "sin SG".

[Noe277]

Empezado por Neftali [Germán.Estévez]

Debes convertirla al Libro 240 sin software garante y volver a enviarla.
El formato de este libro es diferente al habitual (240 con software garante).

En esta página, en la parte de abajo, tienes documentación técnica.
Esto apunta a los esquemas. Y si navegas por esa página, llegas a este fichero zip, que contiene todos los esquemas. Entre ellos los correspondientes al envío "sin SG".

Gracias, Estaba buscando sofware Garante, sabiendo que así lo hare por ai

[infoser101]

Empezado por Neftali [Germán.Estévez]

Debes convertirla al Libro 240 sin software garante y volver a enviarla.
El formato de este libro es diferente al habitual (240 con software garante).

En esta página, en la parte de abajo, tienes documentación técnica.
Esto apunta a los esquemas. Y si navegas por esa página, llegas a este fichero zip, que contiene todos los esquemas. Entre ellos los correspondientes al envío "sin SG".

Pero como se convierte?
Mi experiencia es que Batuz solo admite el envío sin software Garante si es de otra fecha (la clave es nif+factura+fecha)
Por tanto, el único camino que he encontrado es enviar la factura, sin SGarante con fecha del dia siguiente, lo cual es un poco chapuza

[YellowStone]

Empezado por Neftali [Germán.Estévez]

Debes convertirla al Libro 240 sin software garante y volver a enviarla.
El formato de este libro es diferente al habitual (240 con software garante).

En esta página, en la parte de abajo, tienes documentación técnica.
Esto apunta a los esquemas. Y si navegas por esa página, llegas a este fichero zip, que contiene todos los esquemas. Entre ellos los correspondientes al envío "sin SG".

La gran p.t.d. de esto, es que no tiene ni ejemplos en XML, ni una descripción en pdf que haya podido encontrar, nada de nada aparte de estos XSD, y mi Delphi 2007 no me incorpora correctamente estos XSD, me he tenido que apañar con el ejemplo que pusiste en XML hace tiempo. De todos modos, si una vez corregida la factura, la vuelves a enviar como envío normal CON software garante, al menos en pruebas te la coge como válida si ya es correcta.