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

[keys]

Empezado por tejano

Estamos con el mismo problema, desde ayer nos da error.

Si alguien se entera de algo, que lo comente por favor, yo haré lo mismo si me entero de algo.

Gracias

Esta mañana me han llamado de hacienda para hacer una prueba hoy. Y siguen con el mismo problema. Me han dicho que lo estan mirando. Con calma

[keys]

Me acaba de responder hacienda con lo siguiente.

"Hemos detectado una incidencia con las validaciones de algunos certificados en la firma de los ficheros TicketBAI. Estamos trabajando en dicha incidencia y os avisaremos cuando esté solucionada."

[tejano]

Empezado por keys

Me acaba de responder hacienda con lo siguiente.

"Hemos detectado una incidencia con las validaciones de algunos certificados en la firma de los ficheros TicketBAI. Estamos trabajando en dicha incidencia y os avisaremos cuando esté solucionada."

Gracias Keys, iba a poner lo mismo, me acaban de responder.

[thinkows]

Hemos consultado los errores de encadenamiento dando el siguiente supuesto :

Pregunta a la hacienda foral :

Buenos días, quisiéramos saber si hemos entendido bien la mecánica de funcionamiento, planteando el siguiente escenario, nuestra aplicación en principio enviará a la hacienda foral el XML on-line, pero vamos a prever un mecanismo para el envío en el caso de caída de internet


HAY CONEXIÓN A INTERNET

SE ENVIA EL TICKET nº 326 referenciando como operación anterior el TICKET nº325
SE ENVIA EL TICKET nº 327 referenciando como operación anterior el TICKET nº326

CAE INTERNET

SE GENERA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 pero no se envía a la hacienda foral

SE RESTABLECE INTRENET

SE ENVIA EL TICKET nº 329 referenciando como operación anterior el TICKET nº328 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 no se ha enviado todavía)


AL FINAL DEL DIA SE ENVIAN MEDIANTE UN PROCESO TODOS LOS FICHEROS QUE NO SE HAN PODIDO ENVIAR


SE ENVIA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 se envía ahora)



Entendemos que errores de encadenamiento son simples avisos sin más consecuencias mientras se acaben enviando todas las operaciones ?

Aprovechando la ocasión quisiéramos saber si ya han salido las especificaciones de ZUZENDU ?



Respuesta de Guipuzkoa :

Egun on, Buenos días

La normativa foral de Gipuzkoa reguladora de la obligación de TicketBAI parte de la premisa que la imposibilidad temporal del cumplimiento de la obligación TicketBAI no suponga la paralización de la facturación y las ventas. Asimismo, parte de la posibilidad de que no se requiere conexión a internet para la generación del fichero XML ni para la plasmación del código identificativo y del QR. Por ello para el supuesto de que por cualquier circunstancia no se puedan generar ficheros o expedir facturas cumpliendo la obligación TicketBAI, establece en el artículo 17 del Decreto Foral 32/2020, de 22 de diciembre, por el que se aprueba el Reglamento por el que se desarrolla la obligación TicketBAI, lo siguiente:

“Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI.

3. En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio telefónico o telemático, avería del sistema de envío u otras circunstancias en las que el contribuyente pueda generar ficheros TicketBAI pero no pueda enviarlos a la Administración tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI generados y procederá a su envío tan pronto se restablezca la conexión.”

Así, una vez que el servicio estuviera activo debería remitir las facturas que han quedado pendientes de envío en su correspondiente orden de encadenamiento.

Un saludo,


Es decir, no podemos enviar el 329 hasta haber enviado el 328.... lo estáis haciendo así ? (nosotros al cerrar la operación hacemos el envío de la misma) , esto nos obligará a cambiar y enviar todo lo pendiente
por orden.

Y sin noticias de ZUZENDU .....

[ermendalenda]

Empezado por thinkows

Hemos consultado los errores de encadenamiento dando el siguiente supuesto :

Pregunta a la hacienda foral :

Buenos días, quisiéramos saber si hemos entendido bien la mecánica de funcionamiento, planteando el siguiente escenario, nuestra aplicación en principio enviará a la hacienda foral el XML on-line, pero vamos a prever un mecanismo para el envío en el caso de caída de internet


HAY CONEXIÓN A INTERNET

SE ENVIA EL TICKET nº 326 referenciando como operación anterior el TICKET nº325
SE ENVIA EL TICKET nº 327 referenciando como operación anterior el TICKET nº326

CAE INTERNET

SE GENERA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 pero no se envía a la hacienda foral

SE RESTABLECE INTRENET

SE ENVIA EL TICKET nº 329 referenciando como operación anterior el TICKET nº328 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 no se ha enviado todavía)


AL FINAL DEL DIA SE ENVIAN MEDIANTE UN PROCESO TODOS LOS FICHEROS QUE NO SE HAN PODIDO ENVIAR


SE ENVIA EL TICKET nº 328 referenciando como operación anterior el TICKET nº327 (ENTIENDO QUE RECIBIREMOS EL ERROR 10 Error de encadenamiento el 328 se envía ahora)



Entendemos que errores de encadenamiento son simples avisos sin más consecuencias mientras se acaben enviando todas las operaciones ?

Aprovechando la ocasión quisiéramos saber si ya han salido las especificaciones de ZUZENDU ?



Respuesta de Guipuzkoa :

Egun on, Buenos días

La normativa foral de Gipuzkoa reguladora de la obligación de TicketBAI parte de la premisa que la imposibilidad temporal del cumplimiento de la obligación TicketBAI no suponga la paralización de la facturación y las ventas. Asimismo, parte de la posibilidad de que no se requiere conexión a internet para la generación del fichero XML ni para la plasmación del código identificativo y del QR. Por ello para el supuesto de que por cualquier circunstancia no se puedan generar ficheros o expedir facturas cumpliendo la obligación TicketBAI, establece en el artículo 17 del Decreto Foral 32/2020, de 22 de diciembre, por el que se aprueba el Reglamento por el que se desarrolla la obligación TicketBAI, lo siguiente:

“Artículo 17. Incidencias de carácter técnico en el cumplimiento de la obligación TicketBAI.

3. En los supuestos excepcionales de falta temporal de cobertura, interrupción del servicio telefónico o telemático, avería del sistema de envío u otras circunstancias en las que el contribuyente pueda generar ficheros TicketBAI pero no pueda enviarlos a la Administración tributaria, el software TicketBAI acumulará sucesivamente todos los ficheros TicketBAI generados y procederá a su envío tan pronto se restablezca la conexión.”

Así, una vez que el servicio estuviera activo debería remitir las facturas que han quedado pendientes de envío en su correspondiente orden de encadenamiento.

Un saludo,


Es decir, no podemos enviar el 329 hasta haber enviado el 328.... lo estáis haciendo así ? (nosotros al cerrar la operación hacemos el envío de la misma) , esto nos obligará a cambiar y enviar todo lo pendiente
por orden.

Y sin noticias de ZUZENDU .....

Efectivamente, tengo marcado los que no se han podido enviar, si alguno no sse puede enviar sigo generando tiquets y reintento enviarlo en el mismo orden(dejaré una opción para saltarlo si el problema del envío es algo justificable aunque se rompa el encadenamiento y pasaré al siguiente aunque se me quede huérfano) ahora lo tengo en la misma Hilera, pero tengo previsto hacerlo en un ejecutable aparte, como quieras llamarlo, en cola asíncrona, en segundo plano y cada vez que vaya a enviar siempre en un orden cronológico al que le he asignado un número de orden FIFO.,

[ermendalenda]

Empezado por chuski1212

Hola!

Tenias razon, era algo relacionado con el URI, muchas gracias, una cosa menos, seguimos remando

Ahora me devuelve el error:

<Codigo>008</Codigo>
<Descripcion>No se pudo seleccionar ninguna política de validación para poder validar - (13517)</Descripcion>

Alguien sabe algo? Saludos!

Hola, sigue revisando la cabecera
presta especial atención a las mayúsculas y minúsculas, ojo con las comillas (") que si lo has copiado de alguna web puede ser unas comillas distintas, en resumen, repasa caracter a caracter.
En la cabecera debes tener algo así:

<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">
o al menos así:
<T:TicketBai xmlns:T="urn:ticketbai:emision">

Nota: y por supuesto el xml firmado no se puede editar y cambiarle nada por que no funcionaria el envio y cambiaria el signaturevalue
Saludos.

[ion]

Hola!
Tengo problemas con el envio del archivo .gz a DFB.
Estoy usando PHP y GuzzleHttp.
Para los headers:

Código PHP:

$data = ['con' => "LROE", 'apa' => "1.1", 'inte' => ["nif" => "99999970B", "nrs" => "PROFESIONAL", "ap1" => "FICTICIO", "ap2" => "ACTIVO"],'drs' => ["mode" => "140", "ejer" => "2021"]];
        $n3Data = json_encode($data);

        $headers = [
            'Accept-Encoding' => 'gzip', 
            'Content-Encoding' => 'gzip',
            'Content-Type' => 'application/octet-stream',
            'us-bizkaia-n3-version' => '1.0',
            'eus-bizkaia-n3-content-type' => 'application/xml',
            'eus-bizkaia-n3-data' => $n3Data,
        ]; 


Y para el envio:

Código PHP:

$gzdata = gzencode($xml);

        $r = $client->request('POST', ''..pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena', [
            'body' => $gzdata

        ]); 


Este es el error que recivo:

GuzzleHttp\Exception\ClientException
Client error: `POST ..://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena` resulted in a `400 Bad Request` response

[ermendalenda]

Empezado por ion

Hola!
Tengo problemas con el envio del archivo .gz a DFB.
Estoy usando PHP y GuzzleHttp.
Para los headers:

Código PHP:

$data = ['con' => "LROE", 'apa' => "1.1", 'inte' => ["nif" => "99999970B", "nrs" => "PROFESIONAL", "ap1" => "FICTICIO", "ap2" => "ACTIVO"],'drs' => ["mode" => "140", "ejer" => "2021"]];
        $n3Data = json_encode($data);

        $headers = [
            'Accept-Encoding' => 'gzip', 
            'Content-Encoding' => 'gzip',
            'Content-Type' => 'application/octet-stream',
            'us-bizkaia-n3-version' => '1.0',
            'eus-bizkaia-n3-content-type' => 'application/xml',
            'eus-bizkaia-n3-data' => $n3Data,
        ]; 


Y para el envio:

Código PHP:

$gzdata = gzencode($xml);

        $r = $client->request('POST', ''..pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena', [
            'body' => $gzdata

        ]); 


Este es el error que recivo:

GuzzleHttp\Exception\ClientException
Client error: `POST ..://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena` resulted in a `400 Bad Request` response

Hola no sé como funciona Guzzle, si te puede servir veo un par de cosas:
No se si has definido la variable $client:
$client = new \GuzzleHttp\Client();

Despues veo extraño ésto, (que no sé si ha sido al cortar el http... y pegar):
''..pruesarrera
^^ dos comillas simples .. mmmm no sé, lo veo raro, aunque ya te digo no me hagas mucho caso.

[ermendalenda]

Empezado por ermendalenda

Hola, sigue revisando la cabecera
presta especial atención a las mayúsculas y minúsculas, ojo con las comillas (") que si lo has copiado de alguna web puede ser unas comillas distintas, en resumen, repasa caracter a caracter.
En la cabecera debes tener algo así:

<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">
o al menos así:
<T:TicketBai xmlns:T="urn:ticketbai:emision">

Nota: y por supuesto el xml firmado no se puede editar y cambiarle nada por que no funcionaria el envio y cambiaria el signaturevalue
Saludos.

Aunque pensandolo bieen tiene pinta mas bien que no se esta firmando adecuadamente y faltan parametros en la firma.

[ion]

Si, la variable $client la tengo creada y las comillas son porque no puedo poner enlaces.
He descubierto que el error que recibo de la DFB es:
Parámetro clientcert no indicado en la cabecera de la petición

Los certificados me funcionan para Gipuzkoa y los envio igual.
Gracias.

[elguille]

Empezado por iMia

Como te han comentado más arriba el xml tiene que guardarse en UTF sin BOM

Yo lo hago así.

Código Delphi [-]
        strList := TStringList.Create;
        try
          strList.Assign(xmlTBai_Document.XML);
          strList.WriteBOM := false;
          strList.SaveToFile(strFileNameXML, TEncoding.UTF8);
        finally
          FreeAndNil(strList);
        end;

Saludos.

Efectivamente era que el fichero llevaba BOM, no he conseguido grabar sin el directamente con las chilkat, pero con la función descrita y añadiendo las lineas de detalle, ha ido perfecto. Muchas gracias a todos.

[David M]

Hola, ¿puede alguien confirmar si al enviar una nueva factura a Gipuzkoa y visitar el enlace del QR le aparecen directamente los datos de la factura enviada?
Desde hace un par de días, en lugar de aparecer los datos de la factura me muestra un captcha para poner un código y después de ponerlo me dice que el QR es ilegible (que yo sepa no he tocado nada) y tengo que poner el identificador TBAI y otro captcha para poder ver los datos de dicha factura.
Con los QR anteriores al día 16 me aparecen los datos directamente.

Saludos,
David M.

[juramisa]

Buenos días

Estoy intentando enviar el TicketBai para Gipuzkoa. Para Bizkaia lo tengo superado, pero en Gipuzkoa me encuentro un poco perdido.
Utilizo sbxHTTPClient de SecureBlackbox y al realizar el envío la cabecera va cargada así:

Código Delphi [-]
 sbxHTTPClient1.Post(la_url_GI_alta_pruebas, Cuerpo_mensaje_text);

Cabecera preparada: 
POST /WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta HTTP/1.1: 
Content-Type: application/xml;charset=UTF-8
Host: tbai-prep.egoitza.gipuzkoa.eus
User-Agent: SecureBlackbox
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 9371

Pero me da un error 10058 y luego 10054.
En la cabecera solo hay que indicar entiendo Content-Type: application/xml;charset=UTF-8
Si hay alguien que trabaje igual que yo, y puede indicarme como lo hace, agradecido.

Entre las dudas que tengo, es el fichero TicketBai hay que enviarlo también en gzip, como en Bizkaia , o en texto XML sin comprimir.

Gracias

[ermendalenda]

Empezado por David M

Hola, ¿puede alguien confirmar si al enviar una nueva factura a Gipuzkoa y visitar el enlace del QR le aparecen directamente los datos de la factura enviada?
Desde hace un par de días, en lugar de aparecer los datos de la factura me muestra un captcha para poner un código y después de ponerlo me dice que el QR es ilegible (que yo sepa no he tocado nada) y tengo que poner el identificador TBAI y otro captcha para poder ver los datos de dicha factura.
Con los QR anteriores al día 16 me aparecen los datos directamente.

Saludos,
David M.

A mi me sigue funcionando.
Puede pasarte varias cosas (si las sabes pues nada):
1. Que efectivamente el servicio este mal en ese momento(lo acabo de probar y va bien pero es cierto que alguna vez mme ha pasado lo que comentas y a los pocos segundos ya funcionaba)
2. Que no estes convirtiendo el QR (Ojo no el código que escribes) a URI (código URL), esto es por si los caracteres de la firma tienen algun caracter especial "/" """, "'" "."...
3. Que aunque estes generando el Qr con URi no es tes calculando el nuevo CR, que es diferente al escrito.

[ermendalenda]

Empezado por ermendalenda

A mi me sigue funcionando.
Puede pasarte varias cosas (si las sabes pues nada):
1. Que efectivamente el servicio este mal en ese momento(lo acabo de probar y va bien pero es cierto que alguna vez mme ha pasado lo que comentas y a los pocos segundos ya funcionaba)
2. Que no estes convirtiendo el QR (Ojo no el código que escribes) a URI (código URL), esto es por si los caracteres de la firma tienen algun caracter especial "/" """, "'" "."...
3. Que aunque estes generando el Qr con URi no es tes calculando el nuevo CR, que es diferente al escrito.

Por cierto no hace fallta enviarlo para que funcione, los datos que ves están en el mismo QR, que si lo generas correctamente se deberia ver.

[David M]

Empezado por ermendalenda

A mi me sigue funcionando.
Puede pasarte varias cosas (si las sabes pues nada):
1. Que efectivamente el servicio este mal en ese momento(lo acabo de probar y va bien pero es cierto que alguna vez mme ha pasado lo que comentas y a los pocos segundos ya funcionaba)
2. Que no estes convirtiendo el QR (Ojo no el código que escribes) a URI (código URL), esto es por si los caracteres de la firma tienen algun caracter especial "/" """, "'" "."...
3. Que aunque estes generando el Qr con URi no es tes calculando el nuevo CR, que es diferente al escrito.

Gracias por tu tiempo ermendalenda, lo tengo solucionado.
Resulta que sí que había cambiado una parte del código y a la hora de construir la url en lugar de pasar nf como parámetro de número de factura me comí la f, por eso no cuadraba. Estragos provocados por el copy/paste

Saludos,
David M

[ermendalenda]

Empezado por David M

Gracias por tu tiempo ermendalenda, lo tengo solucionado.
Resulta que sí que había cambiado una parte del código y a la hora de construir la url en lugar de pasar nf como parámetro de número de factura me comí la f, por eso no cuadraba. Estragos provocados por el copy/paste

Saludos,
David M

Nada.
Me alegro, que lo hayas solucionado.

[ermendalenda]

Empezado por bilbur

Hasta ahora, en desarrollo, guardo las contraseñas de los certificados .pfx en texto claro.
Evidente que esto no puede ser en producción.


Estoy haciendo lo siguiente:


Mediante formulario solicito al cliente su certificado.pfx y su contraseña de importación (la cual no "veo")


Guardo en el directorio que corresponde su certificado.pfx

lo paso y guardo a certificado.pem

y guardo la contraseña encriptada en certificado.pass


De este modo No guardo las contraseñas de importación del certificado y firma en texto claro.


A la hora de la firma desencripto la contraseña guardada en certificado.pass, firmo y destruyo la contraseña desencriptada. (mini modificación firmador.php probado y funcionando)



Cierto es que al final todo depende de la contraseña de encriptar desencriptar, la cual puede ser autogenerada por combinaciones de cif cliente, cif desarrollador, fechas, etc.


Seguro que se me pasa algo y mi pregunta es, ¿Vosotros cómo lo habéis planteado?


Un saludo y gracias


Si alguien necesita el script en PHP para pasar y guardar los certificados.pfx a .pem y .pass que lo diga y lo subo.

Hola bilbur, ante todo muchas gracias por ese script maravillos del firmador.php, agradecería que subieras el nuevo script para convertir los certificados.
Te debemos ya unas cuantas rondas de pinchos y bebidas.
Un saludo.

[Sistel]

Empezado por ermendalenda

Hola, tengo claro que la serie de las facturas rectificativas tiene que ser diferentes.
Sabeis si se sigue conservando la posibilidad de que la SERIE de la [FACTURA SIMPLIFICADA RECTIFICATIVA], sea la MISMA SERIE que la [FACTURA SIMPLIFICADA NORMAL]?
Buff me ahorraria bastante cambio de código.
Gracias

Hola ermedalenda,

El tema de que se utilice distinta serie para facturas rectificativas que para facturas normales (independientemente de que sean simplificadas o no) es parte de la normativa del Reglamento de Facturación.
No tiene nada que ver con TicketBAI y a los de TicketBAI ese tema se la suda.

Es parte de las normativas del Reglamento de Facturación que suelen ser un poco "laxas" (Los inspectores de Hacienda no le dan mucha importancia, al igual que al tema de que se sellen las facturas recibidas al dorso y otra larga serie de chuminadas similares)
Sé que hay muchas empresas que no siguen esa regla de separar en distinta serie las facturas normales de las rectificativas (aunque no sea "totalmente" legal ... pero no es una cosa grave)

El mismo tema con emitir facturas simplificadas con importes negativos en lugar de facturas simplificadas rectificativas en el caso de devoluciones en TPVs.
Hay softwares muy sencillos de TPV que no tienen posibilidad de seguir toda la normativa de crear facturas simplificadas rectificativas identificando los datos de la factura a la que rectifican, los datos que rectifican, el tipo de rectificación (total o parcial) y el motivo de la rectificación.
En esos casos lo habitual es generar una factura simplificada con importe negativo y santas pascuas.
Consulté ese caso con TicketBAI y se lavaron las manos (es tema del reglamento de facturación ... y a ellos se la reflanflinfa) .

Saludos

[ermendalenda]

Empezado por Sistel

Hola ermedalenda,

El tema de que se utilice distinta serie para facturas rectificativas que para facturas normales (independientemente de que sean simplificadas o no) es parte de la normativa del Reglamento de Facturación.
No tiene nada que ver con TicketBAI y a los de TicketBAI ese tema se la suda.

Es parte de las normativas del Reglamento de Facturación que suelen ser un poco "laxas" (Los inspectores de Hacienda no le dan mucha importancia, al igual que al tema de que se sellen las facturas recibidas al dorso y otra larga serie de chuminadas similares)
Sé que hay muchas empresas que no siguen esa regla de separar en distinta serie las facturas normales de las rectificativas (aunque no sea "totalmente" legal ... pero no es una cosa grave)

El mismo tema con emitir facturas simplificadas con importes negativos en lugar de facturas simplificadas rectificativas en el caso de devoluciones en TPVs.
Hay softwares muy sencillos de TPV que no tienen posibilidad de seguir toda la normativa de crear facturas simplificadas rectificativas identificando los datos de la factura a la que rectifican, los datos que rectifican, el tipo de rectificación (total o parcial) y el motivo de la rectificación.
En esos casos lo habitual es generar una factura simplificada con importe negativo y santas pascuas.
Consulté ese caso con TicketBAI y se lavaron las manos (es tema del reglamento de facturación ... y a ellos se la reflanflinfa) .

Saludos

Gracias Sistel.
Yo soy de los que no lo tengo preparado para otra serie,
Me preocupa de que mañana las rechace el servidor.