TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco - Página 42

tejano · #**821** 17-06-2021

Hola!!!! No sé si os ha pasado a alguien, a la hora de generar el link o código QR, si la firma en sus 13 primeros caracteres tiene símbolos como "-", "+", ..... da error el link

Como por ejemplo

https://batuz.eus/QRTBAI/?id=TBAI-A4...3207.07&cr=216

Podéis decirme si os ha pasado al alguno? Ya no sé si es problema del programa o lo es del entorno de pruebas.

Gracias

Sistel · #**822** 17-06-2021

Cita:

Empezado por tejano

Hola!!!! No sé si os ha pasado a alguien, a la hora de generar el link o código QR, si la firma en sus 13 primeros caracteres tiene símbolos como "-", "+", ..... da error el link

Como por ejemplo

https://batuz.eus/QRTBAI/?id=TBAI-A4...3207.07&cr=216

Podéis decirme si os ha pasado al alguno? Ya no sé si es problema del programa o lo es del entorno de pruebas.

Gracias

Hola tejano,

Ese tema ya se trató en este hilo.
Mira en la página 32 y sucesivas

Saludos

tejano · #**823** 18-06-2021

Cita:

Empezado por Sistel

Hola tejano,

Ese tema ya se trató en este hilo.
Mira en la página 32 y sucesivas

Saludos

Muchas gracias Sistel, cambiado, probado y funciona bien como indicas.

Gracias

luismartin · #**824** 18-06-2021

Buenos días. Conseguido funcionamiento en entorno de pruebas de Gipuzkoa.

Ahora estoy peleándome con Batuz y el LROE (Bizkaia). Pero sólo obtengo errores 400 del servidor. No consigo que acepte las peticiones. ¿ Alguien sabría decirme el por qué? Creo seguir las especificaciones.

Para los de PHP (aunque no creo que sea difícil de entender por otros). Este es el código de la petición, a ver si alguien ha pasado por este trance ya:

Código PHP:


			
    // codificamos a gzip la cadena XML del LROE, 

    // la cual contiene a su vezl el XML del TicketBAI codificado en base64, conforme a las especificaciones

    $gzipStr = gzencode($xmlStr);



    $cabeceras = array(

        'Accept-Encoding: gzip',

        'Content-Encoding: gzip',

        'Content-Length: ' . mb_strlen($gzipStr),

        'Content-Type:  application/octet-stream',

        'eus-bizkaia-n3-version: 1.0.',

        'eus-bizkaia-n3-content-type: application/xml',

        'eus-bizkaia-n3-data:  {"con": "LROE", "apa": "1.1", "inte": {"nif": "' .

        $nif . '","nrs":"' .

        $nombre . '"},"drs": {"mode": "240","ejer": "' . $ejercicio . '"}}',

    );

    $ch = curl_init($url);

    curl_setopt($ch, CURLOPT_POST, 1);

    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');

    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');

    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);

    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);

    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);

    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);

    $resp = curl_exec($ch);

Vi un post en la web de Batuz indicando que ayer día 17, el entorno de pruebas no estaba operativo, con lo cual, di por sentado que era eso. Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.

No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

tejano · #**825** 18-06-2021

Cita:

Empezado por luismartin

Buenos días. Conseguido funcionamiento en entorno de pruebas de Gipuzkoa.

Ahora estoy peleándome con Batuz y el LROE (Bizkaia). Pero sólo obtengo errores 400 del servidor. No consigo que acepte las peticiones. ¿ Alguien sabría decirme el por qué? Creo seguir las especificaciones.

Para los de PHP (aunque no creo que sea difícil de entender por otros). Este es el código de la petición, a ver si alguien ha pasado por este trance ya:

Código PHP:


			
    // codificamos a gzip la cadena XML del LROE, 

    // la cual contiene a su vezl el XML del TicketBAI codificado en base64, conforme a las especificaciones

    $gzipStr = gzencode($xmlStr);



    $cabeceras = array(

        'Accept-Encoding: gzip',

        'Content-Encoding: gzip',

        'Content-Length: ' . mb_strlen($gzipStr),

        'Content-Type:  application/octet-stream',

        'eus-bizkaia-n3-version: 1.0.',

        'eus-bizkaia-n3-content-type: application/xml',

        'eus-bizkaia-n3-data:  {"con": "LROE", "apa": "1.1", "inte": {"nif": "' .

        $nif . '","nrs":"' .

        $nombre . '"},"drs": {"mode": "240","ejer": "' . $ejercicio . '"}}',

    );

    $ch = curl_init($url);

    curl_setopt($ch, CURLOPT_POST, 1);

    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');

    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');

    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);

    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);

    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);

    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);

    $resp = curl_exec($ch);

Vi un post en la web de Batuz indicando que ayer día 17, el entorno de pruebas no estaba operativo, con lo cual, di por sentado que era eso. Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.

No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

A ver si te sirve como lo envío yo

curl --insecure --cert-type P12 --cert nombre_certificado:contraseña_certificado -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"CIF\",\"nrs\":\"NOMBRE_EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary "@c:\tmp\consulta.gz" --output c:\tmp\respuesta.gz -D c:\tmp\cabecera.txt

y me funciona bien, comprimo con el 7z

Saludos

HerensugeBeltz · #**826** 18-06-2021

Cita:

Empezado por Sistel

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

El cliente debe guardar los ficheros XML firmados de las facturas INTACTOS.
Es de vital importancia que no se alteren en ningún caso.
Para que no me salpique, en caso de que el cliente haga alguna de las suyas, yo prefiero que esos ficheros XML firmados estén bajo mi custodia en mis propios servidores.
Al cliente le doy sólo acceso remoto de sólo lectura a esos ficheros.

Son bienvenidos los comentarios sobre estos temas.

Hola,

Yo todavía tengo el tema muy verde, pero en cuanto al almacenamiento de los ficheros XML mi idea era grabarlos en la propia base de datos, en un campo BLOB del registro de la factura asociada.
¿Alguien ve algún problema en ello? (aparte del tamaño que pueda alcanzar la base de datos aunque, según mi experiencia, esto sólo afecta a las copias de seguridad, no a la velocidad de acceso a datos [Firebird])

Gracias.

luismartin · #**827** 18-06-2021

Cita:

Empezado por tejano

A ver si te sirve como lo envío yo

curl --insecure --cert-type P12 --cert nombre_certificado:contraseña_certificado -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"CIF\",\"nrs\":\"NOMBRE_EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary "@c:\tmp\consulta.gz" --output c:\tmp\respuesta.gz -D c:\tmp\cabecera.txt

y me funciona bien, comprimo con el 7z

Saludos

Hola tejano. He intentado la prueba por línea de comandos, teniendo ya generado el gzip, en un fichero llamado lroe_1624012540.gz, pero me da problemas

. Por lo visto, algo del certificado, pero parece más cosa del certificado del servidor (lógicamente, he ocultado datos sensibles):

Código:

$ curl --insecure --cert-type P12 --cacert cert_certFNMTEmpresa.pfx --pass contraseña -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"BXXXXXXXX\",\"nrs\":\"NOMBRE EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary lroe_1624012540.gz --output respuesta.gz -D cabeceras_respuesta.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 80.245.2.232...
* TCP_NODELAY set
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to pruesarrerak.bizkaia.eus (80.245.2.232) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* error setting certificate verify locations, continuing anyway:
*   CAfile: cert_certFNMTEmpresa.pfx
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4450 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [527 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [134 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: jurisdictionC=ES; jurisdictionST=BIZKAIA; jurisdictionL=BILBAO; businessCategory=Government Entity; postalCode=48009; C=ES; ST=BIZKAIA; L=BILBAO; street=GRAN V�A 25; O=BIZKAIKO FORU ALDUNDIA - DIPUTACION FORAL DE BIZKAIA; OU=IT; serialNumber=P4800000D; CN=pruesarrerak.bizkaia.eus
*  start date: Jul  3 12:41:06 2020 GMT
*  expire date: Jul  3 12:41:06 2022 GMT
*  issuer: C=ES; O=IZENPE S.A.; OU=BZ Ziurtagiri publikoa - Certificado publico EV; CN=CA de Certificados SSL EV
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
} [5 bytes data]
> POST /N3B4001M/kontsulta HTTP/1.1
> Host: pruesarrerak.bizkaia.eus
> User-Agent: curl/7.64.0
> Accept: */*
> Accept-Encoding:gzip
> Content-Encoding:gzip
> Content-Type:application/octet-stream
> eus-bizkaia-n3-version:1.0
> eus-bizkaia-n3-content-type:application/xml
> eus-bizkaia-n3-data:{"con":"LROE","apa":"1.1","inte":{"nif":"BXXXXXXXX","nrs":"NOMBRE EMPRESA"},"drs" :{"mode":"240","ejer":"2021"}}
> Content-Length: 18
> 
} [18 bytes data]
* upload completely sent off: 18 out of 18 bytes
* OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104
100    18    0     0  100    18      0     68 --:--:-- --:--:-- --:--:--    68
* Closing connection 0
curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104

Como decía, lroe_1624012540.gz es donde tengo el gzip conteniendo el XML del LROE (que a su vez contiene la factura TBAI)

Neftali [Germán.Estévez] · #**828** 18-06-2021

Cita:

Empezado por luismartin

...Pero hoy me encuentro con el mismo error. Y ya me estoy planteando si es que hay algún problema en mi petición.
No sé si el problema puede estar en la compresión a GZIP. Uso gzencode, pero también he probado con gzcompress y gzdeflate, con igual resultado.

Igual que envías datos en la cabecera de la petición, en la respuesta también llega información en los datos de cabecera.
¿Puedes poner esa cabecera?

Puede ser algo como esto, por ejemplo:

Código:

eus-bizkaia-n3-numero-registro=
eus-bizkaia-n3-tipo-respuesta=Incorrecto
Keep-Alive=timeout=5, max=100
X-Powered-By=Undertow/1
eus-bizkaia-n3-mensaje-respuesta=Todos los registros incluidos en la petición son incorrectos.
eus-bizkaia-n3-codigo-respuesta=B4_1000002
Connection=Keep-Alive
Content-Encoding=gzip
Content-Length=8332
Date=Tue, 25 May 2021 08:17:36 GMT
Content-Type=application/xml;charset=UTF-8
eus-bizkaia-n3-identificativo=94716

Eric Mtz · #**829** 18-06-2021

Buenos días y/o tardes señores, tengo otro problema. (Como podéis ver estoy en racha)

El de hoy tiene tela, veréis, estoy realizando el envío de facturas a Bizkaia, y con el modelo 240 no tengo problemas, sin embargo al realizar el envío del 140 no logro que tan siquiera me devuelvan una respuesta, el servidor directamente rechaza la solicitud y no entiendo la razón, utilizo las clases del modelo 140 e incluso la cabecera del envío tiene la estructura que ellos exigen.

El certificado que empleo para el envío es el del DNI electrónico, ¿Utilizáis vosotros también el DNI? ¿Os ha funcionado? ¿Hicisteis algo especial?, bueno, como digo siempre cualquier ayuda será bien recibida.

Un saludo y que paséis un buen fin de semana, a no ser que trabajes para hacienda... nah es broma, todo el mundo a descansar que el lunes hay que seguir.

Sistel · #**830** 18-06-2021

Cita:

Empezado por luismartin

...

Código PHP:


			
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_POST, 1);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_SSLCERT, PATH_TEMP . '/client.pem');
    curl_setopt($ch, CURLOPT_SSLKEY, PATH_TEMP . '/key.pem');
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($ch, CURLOPT_POSTFIELDS, $gzipStr);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $cabeceras);
    $resp = curl_exec($ch);

Hola luismartin,

Yo también lo hago con PHP, siguiendo, prácticamente, el mismo modelo que presentó en este hilo el colega Bilbur.

Las únicas diferencias que encuentro es que yo no utilizo ninguna de estas dos líneas:

Código PHP:


			
    curl_setopt($ch, CURLOPT_SSLKEYPASSWD, $claveCert);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);

CURLOPT_SSLKEYPASSWD - Si tienes el certificado convertido a PEM, no necesitas password alguna.
CURLOPT_SSL_VERIFYPEER - Ya está, por defecto en TRUE desde la versión 7.10 de Curl

Saludos

Sistel · #**831** 18-06-2021

Cita:

Empezado por Eric Mtz

Buenos días y/o tardes señores, tengo otro problema. (Como podéis ver estoy en racha)

El de hoy tiene tela, veréis, estoy realizando el envío de facturas a Bizkaia, y con el modelo 240 no tengo problemas, sin embargo al realizar el envío del 140 no logro que tan siquiera me devuelvan una respuesta, el servidor directamente rechaza la solicitud y no entiendo la razón, utilizo las clases del modelo 140 e incluso la cabecera del envío tiene la estructura que ellos exigen.

El certificado que empleo para el envío es el del DNI electrónico, ¿Utilizáis vosotros también el DNI? ¿Os ha funcionado? ¿Hicisteis algo especial?, bueno, como digo siempre cualquier ayuda será bien recibida.

Un saludo y que paséis un buen fin de semana, a no ser que trabajes para hacienda... nah es broma, todo el mundo a descansar que el lunes hay que seguir.

Hola Eric Mtz,

En las Especificaciones del Envío Masivo del LROE 1.0.7, en la página 14 dice:
Los tipos de certificados admitidos para los envíos de los LROE son los siguientes:
o Certificado de persona física.
o Certificado de representante de entidad.
o Sello de empresa.
o Sello de autónomo.
o Certificado de dispositivo (debe estar censado para el obligado tributario en DFB/BFA).

No habla nada de que se admita el DNI electrónico.

Saludos

tejano · #**832** 18-06-2021

Cita:

Empezado por luismartin

Hola tejano. He intentado la prueba por línea de comandos, teniendo ya generado el gzip, en un fichero llamado lroe_1624012540.gz, pero me da problemas

. Por lo visto, algo del certificado, pero parece más cosa del certificado del servidor (lógicamente, he ocultado datos sensibles):

Código:

$ curl --insecure --cert-type P12 --cacert cert_certFNMTEmpresa.pfx --pass contraseña -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"BXXXXXXXX\",\"nrs\":\"NOMBRE EMPRESA\"},\"drs\" :{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta" --data-binary lroe_1624012540.gz --output respuesta.gz -D cabeceras_respuesta.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 80.245.2.232...
* TCP_NODELAY set
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to pruesarrerak.bizkaia.eus (80.245.2.232) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* error setting certificate verify locations, continuing anyway:
*   CAfile: cert_certFNMTEmpresa.pfx
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4450 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [527 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [7 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [134 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: jurisdictionC=ES; jurisdictionST=BIZKAIA; jurisdictionL=BILBAO; businessCategory=Government Entity; postalCode=48009; C=ES; ST=BIZKAIA; L=BILBAO; street=GRAN V�A 25; O=BIZKAIKO FORU ALDUNDIA - DIPUTACION FORAL DE BIZKAIA; OU=IT; serialNumber=P4800000D; CN=pruesarrerak.bizkaia.eus
*  start date: Jul  3 12:41:06 2020 GMT
*  expire date: Jul  3 12:41:06 2022 GMT
*  issuer: C=ES; O=IZENPE S.A.; OU=BZ Ziurtagiri publikoa - Certificado publico EV; CN=CA de Certificados SSL EV
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
} [5 bytes data]
> POST /N3B4001M/kontsulta HTTP/1.1
> Host: pruesarrerak.bizkaia.eus
> User-Agent: curl/7.64.0
> Accept: */*
> Accept-Encoding:gzip
> Content-Encoding:gzip
> Content-Type:application/octet-stream
> eus-bizkaia-n3-version:1.0
> eus-bizkaia-n3-content-type:application/xml
> eus-bizkaia-n3-data:{"con":"LROE","apa":"1.1","inte":{"nif":"BXXXXXXXX","nrs":"NOMBRE EMPRESA"},"drs" :{"mode":"240","ejer":"2021"}}
> Content-Length: 18
> 
} [18 bytes data]
* upload completely sent off: 18 out of 18 bytes
* OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104
100    18    0     0  100    18      0     68 --:--:-- --:--:-- --:--:--    68
* Closing connection 0
curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104

Como decía, lroe_1624012540.gz es donde tengo el gzip conteniendo el XML del LROE (que a su vez contiene la factura TBAI)

En tu caso creo que el certificado no es P12, es pfx. Puede ser que vaya por ahí la cosa.

Saludos

yaedev · #**833** 21-06-2021

Cita:

Empezado por tejano

Buenos días,

Me surge una duda, y no sé si os ha pasado a vosotros. En el caso de las autofacturas por parte de nuestros clientes, en el código QR que debemos poner como Serie, lo digo porque el cliente únicamente da un número de factura y no se sabe cual es la serie y dentro del código QR va la serie "&s=&nf=B1159766001"

Gracias

La serie de facturación es opcional. Por lo que si no hay serie, no hay que ponerla y te tendría que aceptarlo. ¿Cuándo te devuelve error: si concatenas el campo sin ningn valor o si no incluyes el campo?

11.2 ¿Los ficheros XML-TicketBAI tienen que informar siempre de la serie de la factura?
No. De acuerdo con el artículo 6 del Reglamento de facturación, una factura deberá contener su número, y en su caso, su serie. Por lo que, en principio, la serie no es un dato obligatorio de una factura. Así, el citado artículo 6 del reglamento de facturación establece que "se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza"

https://www.gipuzkoa.eus/documents/2456431/13761128/1-FAQ-TEXTO+UNIFICADO+19-05-2021.pdf/029ebb00-0fb1-aefe-cfde-2bae0eef4dd6

yaedev · #**834** 21-06-2021

Gracias por vuestras respuestas!

Cita:

Empezado por Neftali

Creo que el envío debe ser "lo antes posible", por lo tanto no se a qué te refieres con "que quede almacenado en el PC" cuando no es inminente.
De todas formas, la idea es que cuando generas el ticket debes firmarlo, porque necesitas el TBAI (incluye la firma) y a su vez ese debe ir impreso en el ticket que se lleva el cliente. Quieren asegurar que cuando el cliente sale con el ticket/factura ya la has firmado.
Por lo tanto no puedes volver a generar el TicketBAI, porque no sería el mismo que el original.
Si los has perdido, debeás justificarlo por los cauces adecuados para ello.

En el caso de Gipuzkoa y Araba el envío sí sería inmediato. En Bizkaia es trimestral, mensual o según el SII, vamos que no es inmediato. No obstante, aunque los 2 primeros sea inmediato. Imagina que en ese momento tienes un fallo de red o de comunicación o cualquier otra causa que te imposibilite remitir el fichero, se tendría que poder enviar después.

Cita:

Empezado por Sistel

En el caso de los software de escritorio, o aplicaciones alojadas en los propios servidores de los clientes, por lo que tienen acceso a las bases de datos: por mucho que les restringas a nivel de software, si el usuario entra en la base de datos, puede eliminar y modificar datos como le plazca… ¿Cómo controláis eso?

El cliente debe guardar los ficheros XML firmados de las facturas INTACTOS.
Es de vital importancia que no se alteren en ningún caso.
Para que no me salpique, en caso de que el cliente haga alguna de las suyas, yo prefiero que esos ficheros XML firmados estén bajo mi custodia en mis propios servidores.
Al cliente le doy sólo acceso remoto de sólo lectura a esos ficheros.

Son bienvenidos los comentarios sobre estos temas.

Saludos
PD: Veo que el colega Neftali [Germán.Estévez] acababa de contestar también a esas cuestiones

Claro, en mi caso es software de escritorio con bases de datos locales. Por ahora inviable montar sistema para almacenar en servidores propios los ficheros. En el caso de FacturaE, los ficheros también los almaceno en el ordenador. LA idea es hacerlo igual....

Pero entiendo que si un usuario coge un bloc de notas y edita el XML firmado. ¿La firma ya no sería válida, no? porque la firma se basa también en el contenido del fichero, por lo que si algo cambia, la firma sería inválida. Es que aún no he llegado a esa parte, si no lo hubiera probado.

Cita:

Creo que son buenas consultas para que les hagas, por email, a los chicos de TicketBAI (y que nos cuentes después la respuesta)

Sí, voy recopilando dudas para enviarlas...

Un saludo!

tejano · #**835** 21-06-2021

Cita:

Empezado por yaedev

La serie de facturación es opcional. Por lo que si no hay serie, no hay que ponerla y te tendría que aceptarlo. ¿Cuándo te devuelve error: si concatenas el campo sin ningn valor o si no incluyes el campo?

11.2 ¿Los ficheros XML-TicketBAI tienen que informar siempre de la serie de la factura?
No. De acuerdo con el artículo 6 del Reglamento de facturación, una factura deberá contener su número, y en su caso, su serie. Por lo que, en principio, la serie no es un dato obligatorio de una factura. Así, el citado artículo 6 del reglamento de facturación establece que "se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza"

https://www.gipuzkoa.eus/documents/2456431/13761128/1-FAQ-TEXTO+UNIFICADO+19-05-2021.pdf/029ebb00-0fb1-aefe-cfde-2bae0eef4dd6

El error me lo da al concatenar el fichero QR, al no tener serie he probado a poner el el QR "https://batuz.eus/QRTBAI/?id=TBAI-CIF_EMPRESA-280221-FIRMA_XML-CRC8&s=&nf=NRO_AUTOFACTURA&i=IMPORTE&cr=CRC8" o incluso a no poner el campo Serie "https://batuz.eus/QRTBAI/?id=TBAI-CIF_EMPRESA-280221-FIRMA_XML-CRC8&nf=NRO_AUTOFACTURA&i=IMPORTE&cr=CRC8" y con ninguna de las 2 me deja.

Gracias

Sistel · #**836** 21-06-2021

Cita:

Empezado por Eric Mtz

Gracias por la ayuda Sistel, ya lo he enviado, a ver si los dos tenemos suerte y nos lo aceptan.

Hola Eric Mtz,

Presenté la petición de registro de mi primer software garante TicketBAI el pasado miércoles 16 de junio.
He entrado hoy en la sede electrónica de la Diputación Foral y veo que el pasado sábado 19 de junio estaba aprobada su inscripción.
Y ya está en el registro de softwares garantes de TicketBAI.
¡¡¡ Qué rapidez !!!
Eso sí, no me han enviado ni email ni aviso de ninguna forma.

Saludos

Neftali [Germán.Estévez] · #**837** 21-06-2021

Cita:

Empezado por yaedev

En el caso de Gipuzkoa y Araba el envío sí sería inmediato. En Bizkaia es trimestral, mensual o según el SII, vamos que no es inmediato. No obstante, aunque los 2 primeros sea inmediato. Imagina que en ese momento tienes un fallo de red o de comunicación o cualquier otra causa que te imposibilite remitir el fichero, se tendría que poder enviar después.

Como estabas hablando de fichero de TicketBAI pensaba que hablabas de Guipuzkoa/Araba. Bizkaia es batuz (que incluye ticketBAI).

En el primer caso, como he dicho, debes enviar el fichero "lo antes posible". Si en un momento dado, los servidores están caídos, pues deberás enviarlo en cuanto puedas (lo antes posible).

Neftali [Germán.Estévez] · #**838** 21-06-2021

Cita:

Empezado por yaedev

Pero entiendo que si un usuario coge un bloc de notas y edita el XML firmado. ¿La firma ya no sería válida, no? porque la firma se basa también en el contenido del fichero, por lo que si algo cambia, la firma sería inválida. Es que aún no he llegado a esa parte, si no lo hubiera probado.

Si editas un fichero firmado y lo intentas enviar fallará porque la firma no coincide y fallará la validación.

Eric Mtz · #**839** 22-06-2021

Buenos días a todos, quería compartir con vosotros una pregunta/respuesta que les he hecho a Batuz:

PREGUNTA:
"Buenos días, verán, estamos implementado TBAI en nuestra aplicación y con el modelo 240 no hemos tenido ningún problema, empleábamos nuestro certificado de empresa a la hora del envío y listo, sin embargo, con el modelo 140 no disponemos de ningún certificado de persona física, hemos intentado emplear varios falsos pero todos son rechazados por el servidor, me preguntaba si ustedes ponen a disposición pública algún certificado para realizar las pruebas."

RESPUESTA:
"Kaixo,
Tal y como se indica en el documento del “Entorno de pruebas del LROE” de la web de Batuz, los certificados a utilizar en el entorno de pruebas deben ser los de Producción.
Agur bat."

Dicho esto, me he quedado un poco en las mismas, creo entender que "certificado de producción" se refiere a certificados reales y en vigencia... ¿En serio?, ¿Para el entorno de pruebas?... No dispongo de ninguno.

Ruegos y preguntas:
¿Tenéis alguno de pruebas que os haya colado?, ¿Alguien mas está como yo?, ¿Podéis pasar algún enlace con certificados que funcionen?, ¿Es que nadie piensa en los desarrolladores?, ¿¡¡Cómo pueden tardar ocho horas en responder una frase tan vaga!!?... No, en serio, en este foro hay gente mucho mas útil que en el correo oficial.

Bueno, que me enervo y aun son las 9 de la mañana. Espero vuestras respuestas y gracias por haber leído hasta aquí, un saludo y ánimo a todos.

keys · #**840** 22-06-2021

Creo que no te queda mas remedio de obtener un certicado que sirva para el del 140, persona fisica u otro. Al menos es lo que hemos que tenído que hacer nosotros.

Un Saludo y tranquilidad

Temas Similares
Tema	Autor	Foro	Respuestas	Último mensaje
SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice	newtron	Internet	3557	Hace 1 Día 17:42:47
Como utilizar la ayuda del nuevo Sistema Operativo	gluglu	Humor	3	24-09-2007 09:39:05
Aplicacion Agencia De Viajes	ArdiIIa	Varios	9	20-01-2007 16:49:53
El Vasco Aguirre	Al González	La Taberna	5	26-05-2006 09:22:28
Microsoft ha lanzado su nuevo sistema operativo	DarkByte	Humor	0	25-01-2004 09:21:14