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

[keys]

Empezado por Sistel

Hola keys

Sí. Yo lo utilizo desde hace mucho tiempo.

Saludos

Perdón me he confundido con Osatu.

[MaeseKvothe]

Buenas gente, soy nuevo por aquí. En primer lugar felicitaciones por el foro y este hilo de TBAI, es lo mejor que he encontrado por la red.


Os planteo una duda. Me han pedido que haga todo el tema de las generaciones de los ficheros para vizcaya y me surge una duda con los abonos.
Ellos actualmente funcionan realizando los abonos como facturas en negativo pero con una serie diferente que luego vuelcan a un software de contabilidad.

¿Se puede generar simplemente un TBAI en el que los importes sean negativos con la misma estructura que tendría una factura normal sin tan siquiera indicar qué factura abona?



Un saludo y gracias.

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

Empezado por MaeseKvothe

¿Se puede generar simplemente un TBAI en el que los importes sean negativos con la misma estructura que tendría una factura normal sin tan siquiera indicar qué factura abona?

Puedes hacer una factura negativa sin problemas. Técnicamente te la aceptarán.

[MaeseKvothe]

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

Puedes hacer una factura negativa sin problemas. Técnicamente te la aceptarán.

Muchas gracias por tu respuesta. En mi caso no estoy desglosando el coste unitario al no ser obligatorio pero el resto lo tengo tal cual indicas, totales en negativo y tipos impositivos en positivo.



Y me surge otra duda. Ellos tienen varios centros de facturación con distintas series pero mi intención es tener una pasarela común.

¿El encadenamiento debo hacerlo por cada centro o debe ser global? Se lo he preguntado al correo de dudas y básicamente no me han aclarado absolutamente nada y eso que han tardado 3 días en contestar...

[fmblas]

Buenas tardes.

Este foro me ha traído viejos recuerdos, pues hace mas de 20 años trabajé con Delphi en las versiones 2 a 7. Como Borland no creía en su producto y cada vez se usaba menos me tuve que reconvertir a .NET en fin.

Estoy adaptando una aplicación para el TBai (de momento sólo para Álava) y la duda me surge con los errores en los datos identificativos de la factura, sobre todo del receptor, como pueden ser en NIF, la dirección, etc. y los importes correctos.

Para corregir esto se ha de hacer una factura rectificativa que supongo será por sustitución con los datos identificativos corregidos y mi pregunta es si los importes son correctos, hay que ponerlos o no en la nueva factura y como afecta todo esto en la generación del xml. He preguntado a la diputación de Alaba y me han puesto un copiar y pegar de los diferentes casos de facturas rectificativas, que sólo hacen referencia a la corrección de importes.

Gracias por vuestra ayuda.

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

Empezado por MaeseKvothe

Y me surge otra duda. Ellos tienen varios centros de facturación con distintas series pero mi intención es tener una pasarela común.

¿El encadenamiento debo hacerlo por cada centro o debe ser global? Se lo he preguntado al correo de dudas y básicamente no me han aclarado absolutamente nada y eso que han tardado 3 días en contestar...

A ver si esto te aclara algo:
https://www.batuz.eus/es/preguntas-f...egunta_7405232
(segunda pregunta)

"El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:

• Si un mismo dispositivo o centro de facturación emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie dentro de ese dispositivo o centro de facturación (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie).
• Igualmente, si el sistema de facturación es un sistema totalmente centralizado, el encadenamiento se refiere a la última factura expedida por el sistema en orden temporal."

[HerensugeBeltz]

Empezado por fmblas

Buenas tardes.

Estoy adaptando una aplicación para el TBai (de momento sólo para Álava) y la duda me surge con los errores en los datos identificativos de la factura, sobre todo del receptor, como pueden ser en NIF, la dirección, etc. y los importes correctos.

Para corregir esto se ha de hacer una factura rectificativa que supongo será por sustitución con los datos identificativos corregidos y mi pregunta es si los importes son correctos, hay que ponerlos o no en la nueva factura y como afecta todo esto en la generación del xml.
Gracias por vuestra ayuda.

En Gipuzkoa, si la factura es errónea, a priori, debes hacer un Zuzendu (dirección o NIF incorrecto del receptor, etc.). Si la has emitido a un receptor equivocado, por ejemplo, entonces deberás darla de baja y emitir una nueva con un nº de factura diferente.

[MaeseKvothe]

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

A ver si esto te aclara algo:
(segunda pregunta)

"El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:

• Si un mismo dispositivo o centro de facturación emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie dentro de ese dispositivo o centro de facturación (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie).
• Igualmente, si el sistema de facturación es un sistema totalmente centralizado, el encadenamiento se refiere a la última factura expedida por el sistema en orden temporal."

Gracias por la respuesta. Ya había leído esa parte, pero no me queda del todo claro a qué llaman ellos centro de facturación, en mi caso que es una pasarela ¿se considera sólo un centro porque el servidor cuenta como dispositivo único o como ellos ya lo tienen separado son varios centros que se conectan a la pasarela?


Mi duda surge porque en esa misma segunda pregunta ellos indican:
"Si son necesarios varios procesos de facturación (se podrían asimilar a centros de facturación) para dar respuesta a varios usuarios concurrentes de una misma empresa de forma paralela, se debería encadenar en orden temporal dentro de cada proceso o centro de facturación, con independencia de la serie. En este caso, debe existir un número acotado de procesos o colas de facturación, asociado al número de usuarios concurrentes por empresa emisora de facturas."


Y mi mayor duda es, si el encadenamiento puede ser distinto en base a los centros de facturación y en ningún lugar se indica el centro, ¿cómo comprueban ellos que estás realizando correctamente el encadenamiento?

[thinkows]

Buenos días, como va todo ??? Os ha pasado alguna vez en el envio a Guipuzkoa que :

Avisen de firma revocada o desconocida :

enviando una factura simplificada T1-202022952.XML

00 ADMITIDO CON AVISOS TBAI-XXXXX-250423-C3U+ZoA/w4Idv-217 25-04-2023 10:50:05

Código 008 La clave de firma ha sido revocada o es desconocida

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<IdentificadorTBAI>TBAI-XXXXXXX-250423-C3U+ZoA/w4Idv-217</IdentificadorTBAI>
<FechaRecepcion>25-04-2023 10:50:05</FechaRecepcion>
<Estado>00</Estado>
<Descripcion>Recibido - ALTA</Descripcion>
<Azalpena>Jasota - ALTA</Azalpena>
<ResultadosValidacion>
<Codigo>008</Codigo>
<Descripcion>La clave de firma ha sido revocada o es desconocida</Descripcion>
<Azalpena>La clave de firma ha sido revocada o es desconocida</Azalpena>
</ResultadosValidacion>
<CSV>TBAIba6e5f10-e0c9-440d-a922-fd242e667f10</CSV>
</Salida>
</ns2:TicketBaiResponse>

En el siguiente envio en el mismo equipo se admita sin problemas ....
T1-202022952.XML

Y en el siguiente, lo rechazen directamente ...
T1-202022953.XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>25-04-2023 11:32:11</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado - ALTA</Descripcion>
<Azalpena>Baztertua - ALTA</Azalpena>
<ResultadosValidacion>
<Codigo>001</Codigo>
<Descripcion>Certificado remitente debe estar homologado y no revocado y no caducado (más de un mes) </Descripcion>
<Azalpena>Igorlearen ziurtagiria homologatuta, errebokatu gabea eta (hilabete baino gehiago) iraungi gabea egon behar da</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>


Alguna idea ???
Agradecido de antemano, un saludo a todos.

[josevalle]

<En mi caso no estoy desglosando el coste unitario al no ser obligatorio>

Tengo entendido que en Bfa si es obligatorio informar de cada línea de detalle, salvo que sean facturas simplificadas.

[xamminf]

Hola,

Usando Curl, despues de haber firmado con Autofirma con certificado personal, me da error el envio a Gipuzkoa
¿ Alguna idea por favor ?

Con esta llamada a Curl:

Código PHP:

Curl.Exe  -k --data-binary @XXX_YYYEnvio_5076677.gz https://tbairep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta --cert-type PEM --key "Certificado_key.Pem"  --header "Content-Type: application/xml;charset=UTF-8" -v --output axyz.xml  -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" 


Obtengo este error:

Código PHP:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>30-04-2023 18:27:13</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado - ALTA PREP</Descripcion>
        <Azalpena>Baztertua - ALTA PREP</Azalpena>
        <ResultadosValidacion>
            <Codigo>017</Codigo>
            <Descripcion>El tamaño del mensaje no es válido: ha superado el tamaño permitido. Le recomendamos que eliminen espacios, tabulaciones u otro tipo de caracteres innecesarios.</Descripcion>
            <Azalpena>Mezuaren tamaina ez da zuzena: baimendutako tamaina gainditu du. Espazioak, tabulazioak edo beharrezkoak ez diren bestelako karaktereak ezabatzea gomendatzen dizugu.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

[edari]

Empezado por xamminf

Hola,

Usando Curl, despues de haber firmado con Autofirma con certificado personal, me da error el envio a Gipuzkoa
¿ Alguna idea por favor ?

Con esta llamada a Curl:

Código PHP:

Curl.Exe  -k --data-binary @XXX_YYYEnvio_5076677.gz https://tbairep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta --cert-type PEM --key "Certificado_key.Pem"  --header "Content-Type: application/xml;charset=UTF-8" -v --output axyz.xml  -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" 


Obtengo este error:

Código PHP:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>30-04-2023 18:27:13</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado - ALTA PREP</Descripcion>
        <Azalpena>Baztertua - ALTA PREP</Azalpena>
        <ResultadosValidacion>
            <Codigo>017</Codigo>
            <Descripcion>El tamaño del mensaje no es válido: ha superado el tamaño permitido. Le recomendamos que eliminen espacios, tabulaciones u otro tipo de caracteres innecesarios.</Descripcion>
            <Azalpena>Mezuaren tamaina ez da zuzena: baimendutako tamaina gainditu du. Espazioak, tabulazioak edo beharrezkoak ez diren bestelako karaktereak ezabatzea gomendatzen dizugu.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

Puede ser que estés mezclando el envío a Vizcaya en el CURL? Lo del gzip si no lo entiendo mal es solo en Vizcaya


Yo acabo de comprobar a subir a Guipuzcoa pruebas y me sube bien con este curl

curl.exe --tlsv1.2 --data-binary @FICHERO.XML --cert-type P12 --cert CERTIFCADO.p12:CONTRASEÑA -H "Content-Type: application/xml;charset=UTF8" -X POST https://tbai-prep.egoitza.gipuzkoa.e...nFacturas/alta -o RESPUESTA.XML

[xamminf]

Empezado por edari

Puede ser que estés mezclando el envío a Vizcaya en el CURL? Lo del gzip si no lo entiendo mal es solo en Vizcaya


Yo acabo de comprobar a subir a Guipuzcoa pruebas y me sube bien con este curl

Efectivamente, ese era el problema. A Guipuzcoa no se manda en formato gzip.
Lo he mandado como .xsig y se lo ha tragado. ¿ Tu tambien lo mandas firmado ? He probado a mandarlo sin firmar y no ha funcionado

Muchas gracias

[xamminf]

Buenos días,

Me imagino que en un mismo fichero .xml de alta o anulacion se pueden mandar varias facturas
Pero ¿ Qué es más conveniente ? ¿ Mandar una factura por .xml o varias en un .xml ?

Si se manda una a una puede ser lento
Si se manda varias en un .xml, algunos tipos de problemas relacionados con la estructura .xml o la codificacion pueden afectar a todas las facturas contenidas

¿ Qué opinais al respecto ?

******


Me autorespondo: En Gipuzkoa hay que mandar las facturas justo despues de imprimirlas asi que no cabe la posibilidad de agruparlas, al menos en el modo inmediato, que debe ser el habitual

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

Empezado por xamminf

Me imagino que en un mismo fichero .xml de alta o anulacion se pueden mandar varias facturas
Pero ¿ Qué es más conveniente ? ¿ Mandar una factura por .xml o varias en un .xml ?
¿ Qué opinais al respecto ?

En Álava y Guipuzcoa se envía 1 fichero de TicketBAI por factura.
En Vizcaya se pueden enviar N ticketBAI dentro de un fichero.

=> Ya que ellos no se han puesto de acuerdo, nosotros para estandarizar enviamos siempre 1 factura por fichero. De esa forma el proceso es siempre el mismo, simplemente cambiamos el constructor del fichero (y la pieza de envío). Pero la lógica es la misma para todas las facturas independientemente de la tributación.

Empezado por xamminf

Otro asunto. La subida de facturas. Creo que hay cuatro dias. Asi pues ...

Yo diría que eso es en el SII. Aquí las cosas van diferente.

En la documentación de Álava pone esto:
"b) Enviar a la Administración tributaria cada fichero informático generado según lo dispuesto en la letra a) anterior de forma inmediata (por lo que requiere conexión a Internet)."

O en la de Guipouzcoa que pone esto:
En el caso de Gipuzkoa, el envío de los ficheros TicketBAI debe llevarse a cabo de modo simultáneo a la expedición de la factura o justificante y online.

Empezado por xamminf

¿ Como lo haceis vosotros ?

Nosotros lo hacemos al generar la factura (inmediato)

[xamminf]

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

En Álava y Guipuzcoa se envía 1 fichero de TicketBAI por factura.
En Vizcaya se pueden enviar N ticketBAI dentro de un fichero.

=> Ya que ellos no se han puesto de acuerdo, nosotros para estandarizar enviamos siempre 1 factura por fichero. De esa forma el proceso es siempre el mismo, simplemente cambiamos el constructor del fichero (y la pieza de envío). Pero la lógica es la misma para todas las facturas independientemente de la tributación.



Yo diría que eso es en el SII. Aquí las cosas van diferente.

En la documentación de Álava pone esto:
"b) Enviar a la Administración tributaria cada fichero informático generado según lo dispuesto en la letra a) anterior de forma inmediata (por lo que requiere conexión a Internet)."

O en la de Guipouzcoa que pone esto:
En el caso de Gipuzkoa, el envío de los ficheros TicketBAI debe llevarse a cabo de modo simultáneo a la expedición de la factura o justificante y online.


Nosotros lo hacemos al generar la factura (inmediato)

Muchas gracias estimado Neftalí.
Me viene mejor una a una porque el proceso es más sencillo
Lo veo peor porque requiere más conexiones.

En todo caso cuando sea facturacion a final de mes, no deberia/puedo hacer eso de enviar en modo inmediato. Habrá que mandar al finalizar la facturacion ¿ No crees ? Se trataria de aislar el proceso de facturacion (masivo) del envio

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

Empezado por xamminf

Lo veo peor porque requiere más conexiones.

Correcto.
Eso ya es cuestión de evaluar cada caso concreto. Si ese tema es muy problemático, siempre puedes "mejorar" la implementación empaquetando N facturas, aunque recuerda que sólo sirve para Vizcaya.

Empezado por xamminf

En todo caso cuando sea facturacion a final de mes, no deberia/puedo hacer eso de enviar en modo inmediato. Habrá que mandar al finalizar la facturacion ¿ No crees ? Se trataria de aislar el proceso de facturacion (masivo) del envio

Puedes realizar ambas cosas en paralelo.
Por ejemplo, creo recordar que hay por aquí alguien que ha implementado algo similar a una cola.
Al generar una factura, la encola y es otro proceso quien se encarga del envío. De esa forma, al generar una factura se encola y se envía "automáticamente" y si estás en un proceso batch tipo "Facturación automática de albaranes" (a final de mes), pues el proceso va generando facturas y encolando y es otro proceso quien las va enviando.

[Sistel]

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

Correcto.
Puedes realizar ambas cosas en paralelo.
Por ejemplo, creo recordar que hay por aquí alguien que ha implementado algo similar a una cola.
Al generar una factura, la encola y es otro proceso quien se encarga del envío. De esa forma, al generar una factura se encola y se envía "automáticamente" y si estás en un proceso batch tipo "Facturación automática de albaranes" (a final de mes), pues el proceso va generando facturas y encolando y es otro proceso quien las va enviando.

Hola,

Yo también lo hago así.
Un proceso va emitiendo las facturas y marcándolas para su envío.
Y un cronjob autónomo, que se arranca cada minuto, va enviando una a una todas las facturas pendientes de envío.

Saludos

[Sistel]

Empezado por josevalle

<En mi caso no estoy desglosando el coste unitario al no ser obligatorio>

Tengo entendido que en Bfa si es obligatorio informar de cada línea de detalle, salvo que sean facturas simplificadas.

Hola,

En Álava y Gipuzkoa es obligatorio informar cada línea de detalle (igual si son facturas completas como si son simplificadas)
En Bizkaia no es obligatorio informar las líneas de detalle de la factura.

Saludos

[MaeseKvothe]

Buenas a todos.
Una nueva duda que me acaba de surgir. En el caso de clientes intracomunitarios, ¿en el código de país debe ir el ISO o el VATCode? En general son iguales pero hay algunas excepciones (Monaco, Irlanda del Norte o Grecia)