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

[Galaxian]

Empezado por bilbur

Se encadena con la última generada sea de la serie que sea

Muchas gracias bilbur.

Aprovecho la ocasión para lanzar otra pregunta -de nota- al que ni las haciendas de Guipúzcoa y Vizcaya han respondido: ¿como se declaran las operaciones hechas a comisión por terminales externos pero que se cobran con el programa (por ejemplo las recargas de móviles)? En estos casos, el programa genera una factura simplificada por importe cero, pues las ventas a comisión no son ventas propias del negocio:

• ¿Hay declarar estas facturas? En su caso ¿debe llevar el QR?
• ¿Qué pasa con la comisión? ¿no habría que declararla en el 140 de batuz?
• Y el más difícil todavía: ¿y si la comisión es variable dependiendo de las ventas (ONCE y loterías) y no se conoce hasta que se recibe la factura?

¿Nadie más se ha encontrado con este caso o alguno similar?

Un saludo

[keys]

Hola.

Yo entiendo que hablas de un suplido.

En el caso en el que, en una factura, por ejemplo, además de los honorarios de un profesional se documentase un suplido, el importe del suplido no formaría parte de la base imponible del IVA pero estas facturas deben cumplir igualmente los requisitos TicketBAI.

En cambio, si únicamente se quisiera documentar un suplido, se trataría de una operación en la que no se documenta ninguna entrega de bienes ni prestación de servicios realizada por el profesional en el desarrollo de su actividad, ya que en estos casos el empresario actuaría como mero intermediario, satisfaciendo sumas de dinero del cliente a un tercero por mandato expreso. En este caso, no habría obligación de expedir factura de acuerdo con lo dispuesto en el Reglamento de facturación, pudiéndose documentar la operación en un recibo u otro justificante. Por tanto, un documento en el que solo se informe de un suplido quedaría fuera del ámbito de aplicación de TicketBAI.

Luego en el 140 tiene que ir como un ingreso sin factura.

[Galaxian]

Empezado por keys

Hola.

Yo entiendo que hablas de un suplido.

En el caso en el que, en una factura, por ejemplo, además de los honorarios de un profesional se documentase un suplido, el importe del suplido no formaría parte de la base imponible del IVA pero estas facturas deben cumplir igualmente los requisitos TicketBAI.

En cambio, si únicamente se quisiera documentar un suplido, se trataría de una operación en la que no se documenta ninguna entrega de bienes ni prestación de servicios realizada por el profesional en el desarrollo de su actividad, ya que en estos casos el empresario actuaría como mero intermediario, satisfaciendo sumas de dinero del cliente a un tercero por mandato expreso. En este caso, no habría obligación de expedir factura de acuerdo con lo dispuesto en el Reglamento de facturación, pudiéndose documentar la operación en un recibo u otro justificante. Por tanto, un documento en el que solo se informe de un suplido quedaría fuera del ámbito de aplicación de TicketBAI.

Luego en el 140 tiene que ir como un ingreso sin factura.

No es un suplido ya que no es el vendedor el que pone el dinero sino el cliente. En todo caso sería un cobro por adelantado.

Me da que esto va a ser trabajo del gestor, que es el que lo declarará en 140 1.2.

[keys]

Segun dice en la pregunta

En estos casos, el programa genera una factura simplificada por importe cero, pues las ventas a comisión no son ventas propias del negocio:

Por lo tanto es un servicio que realiza otra empresa pero lo paga a través de ti. Si no estoy equivovado es un suplido.

Un gasto suplido es un gasto que un profesional tiene a cuenta de un tercero. Es decir, se trata de un gasto que el profesional paga en nombre del cliente, quien posteriormente asumirá este importe

[Galaxian]

Empezado por keys

Un gasto suplido es un gasto que un profesional tiene a cuenta de un tercero. Es decir, se trata de un gasto que el profesional paga en nombre del cliente, quien posteriormente asumirá este importe

Yo no lo veo así: no es el profesional quien adelanta el dinero sino el que lo cobra del cliente, por lo que sería un cobro por adelantado del que detraerá una parte por su servicio. Es decir, un cobro por adelantado por partida doble: una parte por cuenta del vendedor y otra por cuenta propia al haber cobrado por adelantado su comisión, de la que deberá soportar el IVA y la retención.

[bilbur]

Empezado por Galaxian

Muchas gracias bilbur.

Aprovecho la ocasión para lanzar otra pregunta -de nota- al que ni las haciendas de Guipúzcoa y Vizcaya han respondido: ¿como se declaran las operaciones hechas a comisión por terminales externos pero que se cobran con el programa (por ejemplo las recargas de móviles)? En estos casos, el programa genera una factura simplificada por importe cero, pues las ventas a comisión no son ventas propias del negocio:

• ¿Hay declarar estas facturas? En su caso ¿debe llevar el QR?
• ¿Qué pasa con la comisión? ¿no habría que declararla en el 140 de batuz?
• Y el más difícil todavía: ¿y si la comisión es variable dependiendo de las ventas (ONCE y loterías) y no se conoce hasta que se recibe la factura?

¿Nadie más se ha encontrado con este caso o alguno similar?

Un saludo

Entiendo que si se emite factura, aunque importe sea cero, hay que declararla en TBAI y estar a lo que ponga en la factura emitida.
Yo si que las declaro en SII.
A mi se me da, a veces, el caso de factura emitida total cero por venta de mercancía p.e. 10 y devolución de envases tb de -10, total 0,00.

Así no "pierdo" número de factura ni encadenamientos

Lo mejor, probar ahora en pruebas (BIZ y GIP) y ver el resultado
Si da error, enviar correo a los dos y a esperar

[batuzail]

Hola,Voy a empezar a desarrollar el acceso a ticketBai, tengo una pregunta de concepto, por si alguno que ya tenga la solución puede contestarme.
En mi caso generamos la facturas una vez a la semana, generamos cientos de facturas.


¿Hay que realizar una petición por factura y asignar a ese documento el código y el QR en el momento de la generación?


¿Se pueden generar las facturas y posteriormente acceder a ticketbai cuando se imprimen?


Voy implementar sobre VB6 y .NET, usando Chilkat y SecureBlackBlox.


Gracias

[Sistel]

Empezado por batuzail

...
En mi caso generamos la facturas una vez a la semana, generamos cientos de facturas.
¿Hay que realizar una petición por factura y asignar a ese documento el código y el QR en el momento de la generación?
¿Se pueden generar las facturas y posteriormente acceder a ticketbai cuando se imprimen?
...

Hola,

La factura está completa cuando obtienes su XML firmado.
Para obtener el XML firmado de la factura no necesitas acceder a ningún sitio externo.
Es un proceso local.

Otra cosa diferente es su envío a Hacienda Foral.
Si es de Gipuzkoa, debe hacerse el envío inmediatamente después de haber generado el XML firmado (salvo que obtengas de Hacienda una autorización para el envío posterior por no tener conexión ni fija ni móvil a Internet).
Si es de Bizkaia, tienes el plazo normal que había para las declaraciones de IVA (trimestrales o mensuales según la empresa o en un plazo de 4 días si es una empresa obligada al SII), pero se envían dentro del capítulo 1.1 del LROE.

Pero para imprimirla (o enviarla por email como PDF) tienes que añadir en la parte de abajo del documento el código TBAI y el código QR.
Esos códigos TBAI y QR puedes obtenerlos cuando vayas a imprimirla. No los necesitas antes.

Es lo que yo he entendido, pero se admiten correcciones.

Saludos

[batuzail]

Empezado por Sistel

Hola,

La factura está completa cuando obtienes su XML firmado.
Para obtener el XML firmado de la factura no necesitas acceder a ningún sitio externo.
Es un proceso local.

Otra cosa diferente es su envío a Hacienda Foral.
Si es de Gipuzkoa, debe hacerse el envío inmediatamente después de haber generado el XML firmado (salvo que obtengas de Hacienda una autorización para el envío posterior por no tener conexión ni fija ni móvil a Internet).
Si es de Bizkaia, tienes el plazo normal que había para las declaraciones de IVA (trimestrales o mensuales según la empresa o en un plazo de 4 días si es una empresa obligada al SII), pero se envían dentro del capítulo 1.1 del LROE.

Pero para imprimirla (o enviarla por email como PDF) tienes que añadir en la parte de abajo del documento el código TBAI y el código QR.
Esos códigos TBAI y QR puedes obtenerlos cuando vayas a imprimirla. No los necesitas antes.

Es lo que yo he entendido, pero se admiten correcciones.

Saludos

Genial, entonces el proceso consta en generar y firmar xml cuando en mi sistsema se genera la factura y en el momento de imprimir/enviar la factura envio a TBAI y recupero codigo y QR para insertar en el documento.


Gracias

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

Hola batuzail.
Te recomiendo que te leas todo el hilo porque te aclarará bastantes dudas. Hay bastantes mensajes, pero creo que vale la pena el tiempo.

Aquí también tienes un documento con preguntas y respuestas que han publicado desde TicketBAI/Batuz. Ahí también aclaran muchos conceptos.
Por lo demás en cuanto a las preguntas, este gráfico aclara bastante bien los pasos del proceso.

Empezado por batuzail

En mi caso generamos la facturas una vez a la semana, generamos cientos de facturas.
¿Hay que realizar una petición por factura y asignar a ese documento el código y el QR en el momento de la generación?

Alava y Guipuzcoa exigen que el envío sea inmediato tras generar la factura. Cuando generes la factura debes crear el XML, firmarlo y enviarlo (para ello has generado el IDTBAI). Revisa los pasos del gráfico anterior.

Empezado por batuzail

¿Se pueden generar las facturas y posteriormente acceder a ticketbai cuando se imprimen?

Si te refieres a enviarlas a la administración, tal y como te he dicho, el envío debe ser en el momento de realizar la factura.
La impresión en papel/EMail/PDF/... (con el QR y el Id de TBAI incluídos) puede ser posterior.

[keys]

Empezado por bilbur

Entiendo que si se emite factura, aunque importe sea cero, hay que declararla en TBAI y estar a lo que ponga en la factura emitida.
Yo si que las declaro en SII.
A mi se me da, a veces, el caso de factura emitida total cero por venta de mercancía p.e. 10 y devolución de envases tb de -10, total 0,00.

Así no "pierdo" número de factura ni encadenamientos

Lo mejor, probar ahora en pruebas (BIZ y GIP) y ver el resultado
Si da error, enviar correo a los dos y a esperar

El problema es que ese tipo de iva es un iva no sujeto y como envies una factura con importe cero y con iva no sujeto TBAI da error. A nosotros ya se nos planteo el caso y nos contestaron con lo que he puesto antes. Si el importe es cero y no hay base imponible hay que generar un recibo y no una factura.

Sólo se puede incluir en una factura que tenga otros conceptos con base imponible a iva.

[Galaxian]

Empezado por keys

El problema es que ese tipo de iva es un iva no sujeto y como envies una factura con importe cero y con iva no sujeto TBAI da error. A nosotros ya se nos planteo el caso y nos contestaron con lo que he puesto antes. Si el importe es cero y no hay base imponible hay que generar un recibo y no una factura.

Sólo se puede incluir en una factura que tenga otros conceptos con base imponible a iva.

Esa es otra, porque las ventas en agencia (que así es como se llaman oficialmente), además de a retención por IRPF al ser una actividad profesional, están sujetas a IVA, aunque sobre la comisión, por lo que es un IVA soportado, no repercutido.

Cágate lorito.

[bilbur]

Empezado por keys

El problema es que ese tipo de iva es un iva no sujeto y como envies una factura con importe cero y con iva no sujeto TBAI da error. A nosotros ya se nos planteo el caso y nos contestaron con lo que he puesto antes. Si el importe es cero y no hay base imponible hay que generar un recibo y no una factura.

Sólo se puede incluir en una factura que tenga otros conceptos con base imponible a iva.

Para complicarlo más:
Factura emitida base imponible cero

<Factura>
<CabeceraFactura>
<SerieFactura>FV</SerieFactura>
<NumFactura>005864</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
<HoraExpedicionFactura>18:48:34</HoraExpedicionFactura>
<FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
</CabeceraFactura>
<DatosFactura>
<FechaOperacion>04-05-2021</FechaOperacion>
<DescripcionFactura>FACTURA DE VENTA</DescripcionFactura>
<ImporteTotalFactura>0.00</ImporteTotalFactura>
<Claves>
<IDClave>
<ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
</IDClave>
</Claves>
</DatosFactura>
<TipoDesglose>
<DesgloseFactura>
<Sujeta>
<NoExenta>
<DetalleNoExenta>
<TipoNoExenta>S1</TipoNoExenta>
<DesgloseIVA>
<DetalleIVA>
<BaseImponible>0.00</BaseImponible>
<TipoImpositivo>4.00</TipoImpositivo>
<CuotaImpuesto>0.00</CuotaImpuesto>
</DetalleIVA>
</DesgloseIVA>
</DetalleNoExenta>
</NoExenta>
</Sujeta>
</DesgloseFactura>
</TipoDesglose>
</Factura>

Respuesta TBAI BIZ

<Registro>
<Identificador>
<IDFactura>
<SerieFactura>FV</SerieFactura>
<NumFactura>005864</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Correcto</EstadoRegistro>
</SituacionRegistro>
 </Registro>

Parece ser que SI se pueden enviar facturas con base imponible, cuotas y total cero
He probado con facturas simplificadas total cero

<Registro>
<Identificador>
<IDFactura>
<SerieFactura>SV</SerieFactura>
<NumFactura>000444</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Correcto</EstadoRegistro>
</SituacionRegistro>
</Registro>

También correcto en TBAi BIZ


Es posible que no tenga que ver con vuestra casuística, las pruebas son venta de bienes, no prestaciones de servicios.


Un saludo

[keys]

Hola.

Una factura con base 0 si puedes mandar. Lo que no puedes mandar es una factura con solo una línea de no sujeta. Que es como se envía un suplido.

[Elyas]

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

[tejano]

Empezado por Elyas

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

Os adjunto respuesta de Batuz con respuesta a las encadenadas. Nosotros tenemos varias delegaciones y cada delegación una serie de factura y no tienen las facturas del resto de delegaciones, por lo que el encadenamiento lo vamos a realizar en base a la serie.

Contestación de Batuz:

El sistema TicketBAI implica que cada factura debe identificar la factura anterior (serie, número, fecha y 100 primeros caracteres de la firma). Aunque en el esquema del fichero TicketBAI estos campos no son obligatorios, esta circunstancia se debe a que existen varias situaciones en los que este requisito no es exigible (p. ej. la primera factura, o en caso de rotura del dispositivo).

El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:
- Si un mismo dispositivo emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie (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 centralizado que genera las series y los números de facturación, con independencia del dispositivo que se esté utilizando, el encadenamiento se refiere a la última factura expedida por el sistema.
En concreto, “Haz tu factura” funcionaría como un sistema de facturación “centralizado”, por lo que encadena las facturas independientemente de la serie.
- No obstante, si existen diferentes dispositivos o centros de facturación, los cuales sólo expiden facturas dentro de una serie específica para cada dispositivo o centro, el encadenamiento se produce dentro de cada serie.
Este último parece ser el caso al que se refiere la pregunta planteada.

[Sistel]

Empezado por Elyas

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

Hola Elyas,

Creo que el encadenamiento de las facturas no tiene nada que ver con su envío.
El encadenamiento es algo secuencial (factura emitida a factura emitida) y que se hace en local.
Que luego al enviarlas a Ticketbai (en Gipuzkoa) o por LROE (en Bizkaia) alguna te la dan como incorrecta, es otro tema.

Si sabes cual ha sido el error, siempre podrás generar una anulación de la factura (también encadenada a la última generada) y enviarla.
Y emitir otra nueva (con número siguiente y encadenada a la anterior, como es normal) que sea correcta.

Si, más adelante, habilitan un mecanismo de corrección de facturas enviadas y que han considerado incorrectas, perfecto.
Pero con el mecanismo actual de anulación creo que tienes el tema resuelto.

Saludos