Perdón me he confundido con Osatu.

Duda abonos
 

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.

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...

Datos factura identificativos erróneos (NIF, dirección, etc.)
 

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.

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."

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.

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?

La clave de firma ha sido revocada o es desconocida
 

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.

<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.

Error en el envio al entorno de pruebas
 

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:
Obtengo este error:

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

Varias facturas
 

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

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

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.

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

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

Duda Codigo de Pais
 

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)