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

[espinete]

Señor@s... PROBLEMA RESUELTO.

O mejor dicho... motivo descubierto.

El problema está en el proceso de envío con NetHTTPClient1. Si utilizo idhttp1, no hay ningún problema y la factura se envía sin problemas, sin cambiar NADA en el proceso de creación del archivo, firma, etc.

¿Cómo puedo saber la diferencia entre lo que envía NetHTTPClient1 y lo que envía idhttp1 para saber dónde está el problema? Estoy más familiarizado con el uso del almacén de certificados en vez de con los archivos directamente y tendría que cambiar la aplicación.


(aparte de que ahora NECESITO saber por qué me falla NetHTTPClient1 para poder dormir)

Gracias iMia por sugerir el envío con idhttp1. La verdad es que estaba (estábamos) enfocados en que el problema no estaba ahí, sino en la generación del XML o en la firma.

[txitxarru]

Empezado por espinete

Señor@s... PROBLEMA RESUELTO.

O mejor dicho... motivo descubierto.

El problema está en el proceso de envío con NetHTTPClient1. Si utilizo idhttp1, no hay ningún problema y la factura se envía sin problemas, sin cambiar NADA en el proceso de creación del archivo, firma, etc.

¿Cómo puedo saber la diferencia entre lo que envía NetHTTPClient1 y lo que envía idhttp1 para saber dónde está el problema? Estoy más familiarizado con el uso del almacén de certificados en vez de con los archivos directamente y tendría que cambiar la aplicación.


(aparte de que ahora NECESITO saber por qué me falla NetHTTPClient1 para poder dormir)

Gracias iMia por sugerir el envío con idhttp1. La verdad es que estaba (estábamos) enfocados en que el problema no estaba ahí, sino en la generación del XML o en la firma.

Me alegro que hayas encontrado el motivo, de todas formas para que la firma te la genere sin BOM le puedes añadir la linea:

Código Delphi [-]
Signer.Config('WriteBOM=FALSE');

[iMia]

Empezado por espinete

Señor@s... PROBLEMA RESUELTO.

O mejor dicho... motivo descubierto.

El problema está en el proceso de envío con NetHTTPClient1. Si utilizo idhttp1, no hay ningún problema y la factura se envía sin problemas, sin cambiar NADA en el proceso de creación del archivo, firma, etc.

¿Cómo puedo saber la diferencia entre lo que envía NetHTTPClient1 y lo que envía idhttp1 para saber dónde está el problema? Estoy más familiarizado con el uso del almacén de certificados en vez de con los archivos directamente y tendría que cambiar la aplicación.


(aparte de que ahora NECESITO saber por qué me falla NetHTTPClient1 para poder dormir)

Gracias iMia por sugerir el envío con idhttp1. La verdad es que estaba (estábamos) enfocados en que el problema no estaba ahí, sino en la generación del XML o en la firma.

[HerensugeBeltz]

Empezado por espinete

Señor@s... PROBLEMA RESUELTO.

O mejor dicho... motivo descubierto.

El problema está en el proceso de envío con NetHTTPClient1. Si utilizo idhttp1, no hay ningún problema y la factura se envía sin problemas, sin cambiar NADA en el proceso de creación del archivo, firma, etc.

Gracias iMia por sugerir el envío con idhttp1. La verdad es que estaba (estábamos) enfocados en que el problema no estaba ahí, sino en la generación del XML o en la firma.

Dado que usas los componentes SecureBlackBox 2020, no sería más sencillo usarlos también para el envío?
Ejemplo en C++ Builder:

  sbxHTTPClient1->ClientCertHandle[0]= sbxCertStore->CertHandle[m_ndxCertificadoSeleccionado];
  // Cargo el fichero como un array de bytes. Con otros métodos se desvirtuaba el
  // contenido y el envío fallaba.
  DynamicArray<byte> cnt;
  std::unique_ptr<TFileStream> fs(new TFileStream(XMLOrigen,	fmOpenRead));
  cnt.Length= fs->Size;
  fs->Read(cnt, 0, cnt.Length);

  bool resul(true);
  try
  {
    sbxHTTPClient1->TLSAutoValidateCertificates= true; //== 02/07/21. Añadido
    sbxHTTPClient1->TLSVersions= TsbxConstants::csbTLS12;
    sbxHTTPClient1->ReqParamsContentType= L"application/xml;charset=UTF-8";
    sbxHTTPClient1->ReqParamsAcceptCharset= L"UTF-8";
    sbxHTTPClient1->ReqParamsAccept= L"*/*";
    sbxHTTPClient1->ReqParamsHTTPVersion= TsbxHTTPClientReqParamsHTTPVersions::chvHTTP11;
    sbxHTTPClient1->TLSRenegotiationAttackPreventionMode= TsbxHTTPClientTLSRenegotiationAttackPreventionModes::crapmAuto;
    sbxHTTPClient1->Config(L"UseSystemCertificates=true"); 

    sbxHTTPClient1->PostBytes(endPoint, cnt);
  }
  catch (Exception &e)
  {
    codigoError= -6;
    err= L"Error en el envío de la factura XML.\r\n"+ e.Message + L"\r\n" +
      sbxHTTPClient1->ReasonPhrase;
    resul= false;
  }

[Ramon88]

Bueno, pues esta mañana muy amablemente me han llamado desde Hacienda de gipuzkoa, dudas resueltas, generaré facturas simplificadas y ellos quieren rectificativas, pero yo cuando anulo una venta es por que la operación no se lleva a cabo, por lo que puedo generar anulación.

Alava creo que es igual que gipuzkoa por que he probado a enviar y me funciona todo, lo único que no he probado es el QR pero ya vi que tenia algun cambio.

Ahora voy con Bizkaia, y me están entrando tics nerviosos viendo la documentación, esto no tiene nada que ver a las demás?
Alguien puede resumirme un poco? no entiendo nada...

Tengo que generar facturas xml como siempre, y cada cuanto tengo que subirlas comprimidas? y la compresion va en 7z ? donde puedo ver toda esta info? es que he visto en este enlace mucha información, pero son mas de 1000 hojas en total.
https://www.batuz.eus/es/documentacion-tecnica#LROE


Un saludo,

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

Empezado por Ramon88

Alguien puede resumirme un poco? no entiendo nada...

Tengo que generar facturas xml como siempre, y cada cuanto tengo que subirlas comprimidas? y la compresion va en 7z ? donde puedo ver toda esta info? es que he visto en este enlace mucha información, pero son mas de 1000 hojas en total.
https://www.batuz.eus/es/documentacion-tecnica#LROE


Un saludo,

El documento que más te puede servir es este.
Al final, tal y como dices, tienes que generar el fichero de TicketBAI igual que para Guipuzkoa, ese fichero va dentro de un XML, eso lo comprimes y lo envías utilizando una cabecera con varios campos tipo campo/valor.

En el primer mensaje de este hilo tienes bastante información.
Y en este hilo enlaces con referencias a los pasos más importantes.

[ermendalenda]

TBAI-A22222222-131021-lIk4jJXpKKzEE-041

TBAI-A22222222-131021-lIk4jJXpKKzEE-041


Aqui os dejo un pequeño problema que os puede volver locos y dar algún problema con el identificador TBAI al leerlo y copiarlo manualmente o que alguien lo malinterprete y tengais un lio:

Se ven iguales si usas para imprimir por ejemplo;
Tipo de letra System letra ele minúscula > "l" letra i mayúscula >"I"
Tipo de letra Arial letra ele minúscula > "l" letra i mayúscula >"I"

Ok, por ejemplo:
Tipo de letra Verdana letra ele minúscula > "l" letra i mayúscula >"I"



Saludos


Por ejemplo la web de comprobacion de QR de BIZKAIA tiene ese "problemilla"

[espinete]

¿Alguien puede decirme qué ha pasado con los envíos a Bizkaia últimamente? Tras terminar por fin Gipuzkoa y Araba, he vuelto a probar envíos con Bizkaia (antes funcionaba, tanto enviar como anular y consultar) y ahora ya no puedo enviar:

Error sending data: no se pudo resolver el nombre del servidor o su dirección.

Estoy enviando (obviamente en modo pruebas) a _tps :// pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena

[luismartin]

Empezado por espinete

¿Alguien puede decirme qué ha pasado con los envíos a Bizkaia últimamente? Tras terminar por fin Gipuzkoa y Araba, he vuelto a probar envíos con Bizkaia (antes funcionaba, tanto enviar como anular y consultar) y ahora ya no puedo enviar:

Error sending data: no se pudo resolver el nombre del servidor o su dirección.

Estoy enviando (obviamente en modo pruebas) a _tps :// pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena

Enviaron un email avisando de que ese entorno de pruebas lo deshabilitaban, y que, hasta el 10 de diciembre, se podra utilizar su entorno real en modo de pruebas. Es la misma URL, pero sin el "prue" delante, o sea, sarrerak.bizkaia....

Pego toda la info que enviaron en castellano:

Kaixo,

Os escribimos para informaros de que ya está abierto el entorno real del LROE en modo pruebas, con el doble objetivo de que, por un lado, las personas contribuyentes se familiaricen con el nuevo sistema, y, por otro lado, las empresas desarrolladoras de software puedan realizar pruebas sobre el entorno real del servicio de entradas masivas. En todo caso, las anotaciones que se realicen durante este periodo se registrarán a modo de prueba y no tendrán trascendencia tributaria.

Este entorno se cerrará el 10 de diciembre de 2021.

La información detallada de este entorno está publicada en la web de Batuz (www.batuz.eus).

Agur bat.

Esto otro lo enviaron ya hace tiempo:

Como sabéis, el periodo voluntario incentivado de Batuz se iniciará el 1 de enero de 2022 para las personas y entidades que se adhieran al sistema. En consecuencia, esta fecha supondrá la apertura del entorno real del Libro Registro de Operaciones Económicas (LROE), tanto para la aplicación web de la Hacienda Foral como para el intercambio automático de ficheros informáticos a través del servicio de entradas masivas de la Diputación Foral de Bizkaia.

Os escribimos ahora para informaros de que, a partir de mediados de octubre y hasta principios de diciembre, se abrirá a modo de pruebas este entorno real del LROE, con el doble objetivo de que, por un lado, las personas contribuyentes se familiaricen con el nuevo sistema, y, por otro lado, las empresas desarrolladoras de software puedan realizar pruebas sobre el entorno real del servicio de entradas masivas. En todo caso, las anotaciones que se realicen durante este periodo se registrarán a modo de prueba y no tendrán trascendencia tributaria.



Por ello, el entorno de pruebas actual del servicio de entradas https://pruesarrerak.bizkaia.eus se cerrará el próximo 30 de septiembre de 2021.



Para la realización de pruebas del sistema de envíos masivos estarán disponibles los siguientes entornos:

Entorno real del LROE a modo de pruebas con certificados reales de producción. La URL será https://sarrerak.bizkaia.eus y, como hemos dicho, estará disponible a partir de mediados de octubre hasta principios de diciembre de 2021.
Nuevo entorno de pruebas que, atendiendo a las sugerencias recibidas, funcionará con certificados de pruebas y estará disponible a partir de mediados de noviembre.

La información detallada de estos entornos se publicará en la web de Batuz (www.batuz.eus) y se notificará tanto a través del apartado de Novedades de dicha web como a través de un correo enviado desde este buzón.

Agur bat.

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

Empezado por espinete

¿Alguien puede decirme qué ha pasado con los envíos a Bizkaia últimamente? Tras terminar por fin Gipuzkoa y Araba, he vuelto a probar envíos con Bizkaia (antes funcionaba, tanto enviar como anular y consultar) y ahora ya no puedo enviar:
Error sending data: no se pudo resolver el nombre del servidor o su dirección.
Estoy enviando (obviamente en modo pruebas) a _tps :// pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena

Pues hace ya tiempo anunciaron cambios y cierre en los servidores:
https://www.clubdelphi.com/foros/sho...postcount=1721


Y esta semana han avisado de que los han vuelto a poner en marcha (a medias y con cambios):
https://www.clubdelphi.com/foros/sho...postcount=1855

[luismartin]

Estoy teniendo problemas para el envío en caso de ser la primera factura. Sé que en este caso no es necesario enviar la huella TBAI, pero aun así, la validación me da error porque me pide los elementos XML propios de la Huella TBAI. Entonces, ¿alguien tiene claro qué elementos no se envían este caso, o si se envían, con qué valores??

<HuellaTBAI>   
    <EncadenamientoFacturaAnterior>
    	<SerieFacturaAnterior></SerieFacturaAnterior>
        <NumFacturaAnterior></NumFacturaAnterior>
        <FechaExpedicionFacturaAnterior></FechaExpedicionFacturaAnterior>
        <SignatureValueFirmaFacturaAnterior></SignatureValueFirmaFacturaAnterior>
    </EncadenamientoFacturaAnterior> 
	<Software>
	    <LicenciaTBAI></LicenciaTBAI>
	    <EntidadDesarrolladora>
        	<NIF></NIF>
	    </EntidadDesarrolladora>
        <Nombre></Nombre>
        <Version></Version>
    </Software>
    <NumSerieDispositivo></NumSerieDispositivo>
</HuellaTBAI>

[ermendalenda]

Empezado por luismartin

Estoy teniendo problemas para el envío en caso de ser la primera factura. Sé que en este caso no es necesario enviar la huella TBAI, pero aun así, la validación me da error porque me pide los elementos XML propios de la Huella TBAI. Entonces, ¿alguien tiene claro qué elementos no se envían este caso, o si se envían, con qué valores??

<HuellaTBAI>   
    <EncadenamientoFacturaAnterior>
        <SerieFacturaAnterior></SerieFacturaAnterior>
        <NumFacturaAnterior></NumFacturaAnterior>
        <FechaExpedicionFacturaAnterior></FechaExpedicionFacturaAnterior>
        <SignatureValueFirmaFacturaAnterior></SignatureValueFirmaFacturaAnterior>
    </EncadenamientoFacturaAnterior> 
    <Software>
        <LicenciaTBAI></LicenciaTBAI>
        <EntidadDesarrolladora>
            <NIF></NIF>
        </EntidadDesarrolladora>
        <Nombre></Nombre>
        <Version></Version>
    </Software>
    <NumSerieDispositivo></NumSerieDispositivo>
</HuellaTBAI>

En ese caso no mandes los campos de encadenamiento
<HuellaTBAI>
<Software>
<LicenciaTBAI>TBAIPRUEBA</LicenciaTBAI>

<EntidadDesarrolladora>
<NIF>Axxxxxxxxxz</NIF>

</EntidadDesarrolladora>


<Nombre>nombprograma</Nombre>

<Version>1.0.2626</Version>

</Software>


<NumSerieDispositivo>GuCF4BB2E79CA</NumSerieDispositivo>

</HuellaTBAI>

Y si no vas a meter numero de serie de dispositivo creo que tampoco hay que mandar el campo vacio, los de licencia y demas si hacen falta