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

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

Yo creo que si generas una factura errónea y para corregirla generas una rectificativa, aunque el resultado sea 0 debes enviarla al cliente. Eso es lo "raro" frente a anular como comenta keys.

Pensad que habrá un momento en que todas las facturas, tanto de emisor como de receptor, tendrán que ser enviadas (y es de suponer que la hacienda correspondiente las cruzará).

El cliente estará recibiendo una factura errónea, una rectificativa de la factura errónea y además le estará obligando a introducirlas ambas en su sistema (y a enviarlas -en un futuro-) puesto que son facturas que están registradas en la administración por el emisor.

No se si me explico...

De todas formas son casos muy puntuales, a no ser que alguien se equivoque mucho generando facturas. Cosa que a lo mejor es sospechosa por otros temas...

[adolphsys]

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

Yo creo que si generas una factura errónea y para corregirla generas una rectificativa, aunque el resultado sea 0 debes enviarla al cliente. Eso es lo "raro" frente a anular como comenta keys.

Pensad que habrá un momento en que todas las facturas, tanto de emisor como de receptor, tendrán que ser enviadas (y es de suponer que la hacienda correspondiente las cruzará).

El cliente estará recibiendo una factura errónea, una rectificativa de la factura errónea y además le estará obligando a introducirlas ambas en su sistema (y a enviarlas -en un futuro-) puesto que son facturas que están registradas en la administración por el emisor.

No se si me explico...

De todas formas son casos muy puntuales, a no ser que alguien se equivoque mucho generando facturas. Cosa que a lo mejor es sospechosa por otros temas...

Gracias por vuestra respuesta.

Desde mi humilde punto de vista, es más transparente y trazable las facturas de cargo y abono, aunque quede "raro" no enviarlas al cliente. Pero hay que admitir que también es "raro" y sospechoso la existencia de huecos o "facturas marcadas como anuladas" ...

Hoy en día, con la normativa vigente, ante una inspección tributaria, prefiero no tener que justificar huecos en la numeración de facturas de venta...

[ermendalenda]

Empezado por adolphsys

Gracias por vuestra respuesta.

Desde mi humilde punto de vista, es más transparente y trazable las facturas de cargo y abono, aunque quede "raro" no enviarlas al cliente. Pero hay que admitir que también es "raro" y sospechoso la existencia de huecos o "facturas marcadas como anuladas" ...

Hoy en día, con la normativa vigente, ante una inspección tributaria, prefiero no tener que justificar huecos en la numeración de facturas de venta...

Yo por ejemplo emito facturas sustitutivas de las simplificadas, si el vendedor se equivoca(que pasa muy a menudo) ANULO la sustitutiva y libero las simplificadas para hacer una nueva sustitutiva, en este caso la anulación es lo más rápido y transparente, se vé claro que ha habido un error.

[Sistel]

Hola,

Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf
La cosa va a traer cola ... para nosotros.

Saludos

[Casimiro Notevi]

Empezado por Sistel

Hola,
Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf
La cosa va a traer cola ... para nosotros.
Saludos

Es fácil: "Los obligados tributarios que ... utilicen sistemas informáticos para el cumplimiento de la obligación de facturación ".
¡Hala!, aquí está la solución de toda la vida:
Oiga, que yo no sé usar un aparato de esos tan modernos y eso de interné qué es:

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

Empezado por Sistel

Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf

Voy a copiar este mensaje al hilo sobre la ley antifraude para programas informáticos, que creo que es más adecuado.

[keys]

Muchas gracias.

Esto parece que es como el TicketBAI que han sacado en las forales.

No obstante, los obligados tributarios a que se refiere el artículo 3.1 de dicho Reglamento deberán
tener operativos los sistemas informáticos adaptados a las características y requisitos que se
establecen en el citado Reglamento y en su normativa de desarrollo a partir del 1 de enero de
2024

PArece que de momento nos dan tiempo.

Los obligados tributarios que, de acuerdo con el artículo 3 de este Reglamento, utilicen
sistemas informáticos para el cumplimiento de la obligación de facturación podrán remitir
voluntariamente a la Agencia Estatal de Administración Tributaria, de forma automática y segura
por medios electrónicos, todos los registros de facturación generados por los sistemas
informáticos a que se refiere la letra a) del artículo 7 de este Reglamento de acuerdo con las
especificaciones técnicas que se establezcan para la remisión

Parece que el envio de los registros a hacienda será voluntario y no obligatorio como en las forales. Aunque el sistema tiene que poder hacerlo.

Pero habrá que seguir esperando a que desarrollen la ley.

[ermendalenda]

Por lo que he leído es replica de ticketbai y le añaden más movidas sobre todo el Registro de instalación, actualizaciones y eventos con garantía de inalterabilidad y trazabilidad así que a currar un poco más no nos vayamos a quedar dormidos.

[FranAza]

Buenas,

No sé si vuestros sistemas tienen procesos de traspasos (enlaces) contables de facturas a otros softwares de contabilidad.
En estos procesos de traspasos contables de las facturas de ventas nos surgen varias dudas con respecto a las facturas anuladas con el sistema TBAI.


*Cuando se hace el traspaso contable desde la gestión de aquellas facturas pendientes de traspasar, si nos encontramos con una FACTURA ANULADA TBAI:

- ¿Hay que meterla en el enlace? un sólo asiento? dos asientos (uno contrario del otro) para evitar "huecos"?
- ¿No se debe considerar? Entonces existiría un número de factura en contab. que se "salta": --> "hueco"
- ¿Simplemente considerar en la gestión las fac.anuladas como "no traspasables" a contab.?

*Otro caso que nos genera dudas es el siguiente:

Una factura normal previamente contabilizada (ya traspasada a contab.) y que posteriormente se ANULA en la gestión con el sistema TBAI.
¿Cómo actuar?
- Impedir en la gestión que el usuario pueda "anular" facturas ya contabilizadas?
- Permitir hacerlo, y que se resuelva de forma manual en la contabilidad?
- No hacer nada?

Bueno, no se si alguno se ha planteado estas cosas, pero si quereis compartir soluciones....

Saludos

[yasmNote]

Buenas,
Estoy mandando con un cliente con un certificado .p12 a gipuzkoa y en ocasiones (no siempre...según le da) me sale este error:

ERROR - JasnError_Asn1_SettingValue CAUSE = UnknownStringType STRING = UNDEF file = ./include/jasn/infframe.h:171

¿Será un problema del certificado? porque me dicen en gipuzkoa lo siguiente:

Buenas tardes,

De momento, por razones de rendimiento, el certificado de las facturas emitidas se analizan aleatoriamente, es por ello que algunas veces le salte error y otras no. En consecuencia, le recomiendo trasladarle el problema a IZENPE porque entiendo que el problema puede estar en el certificado o al generar la firma.

Un saludo

¿A alguien le ha pasado esto?
Gracias,

[unomasmas]

Empezado por yasmNote

Buenas,
Estoy mandando con un cliente con un certificado .p12 a gipuzkoa y en ocasiones (no siempre...según le da) me sale este error:

ERROR - JasnError_Asn1_SettingValue CAUSE = UnknownStringType STRING = UNDEF file = ./include/jasn/infframe.h:171

¿Será un problema del certificado? porque me dicen en gipuzkoa lo siguiente:

Buenas tardes,

De momento, por razones de rendimiento, el certificado de las facturas emitidas se analizan aleatoriamente, es por ello que algunas veces le salte error y otras no. En consecuencia, le recomiendo trasladarle el problema a IZENPE porque entiendo que el problema puede estar en el certificado o al generar la firma.

Un saludo

¿A alguien le ha pasado esto?
Gracias,

Yo no he tenido ningún problema similar en mis pruebas. ¿El problema es en el servidor de pruebas o de producción? No entiendo que en pruebas hagan comprobaciones aleatorias porque eso resulta en respuestas incoherentes...

[yasmNote]

Empezado por unomasmas

Yo no he tenido ningún problema similar en mis pruebas. ¿El problema es en el servidor de pruebas o de producción? No entiendo que en pruebas hagan comprobaciones aleatorias porque eso resulta en respuestas incoherentes...

Así les luce el pelo... me ha ocurrido en pruebas pero debe ser algún problema con el certificado de la empresa, lo están mirando los desarrolladores, a ver si me dan alguna solución...

[keys]

Empezado por FranAza

Buenas,

No sé si vuestros sistemas tienen procesos de traspasos (enlaces) contables de facturas a otros softwares de contabilidad.
En estos procesos de traspasos contables de las facturas de ventas nos surgen varias dudas con respecto a las facturas anuladas con el sistema TBAI.


*Cuando se hace el traspaso contable desde la gestión de aquellas facturas pendientes de traspasar, si nos encontramos con una FACTURA ANULADA TBAI:

- ¿Hay que meterla en el enlace? un sólo asiento? dos asientos (uno contrario del otro) para evitar "huecos"?
- ¿No se debe considerar? Entonces existiría un número de factura en contab. que se "salta": --> "hueco"
- ¿Simplemente considerar en la gestión las fac.anuladas como "no traspasables" a contab.?

*Otro caso que nos genera dudas es el siguiente:

Una factura normal previamente contabilizada (ya traspasada a contab.) y que posteriormente se ANULA en la gestión con el sistema TBAI.
¿Cómo actuar?
- Impedir en la gestión que el usuario pueda "anular" facturas ya contabilizadas?
- Permitir hacerlo, y que se resuelva de forma manual en la contabilidad?
- No hacer nada?

Bueno, no se si alguno se ha planteado estas cosas, pero si quereis compartir soluciones....

Saludos

Hola en nuestro caso lo que hacemos es contabilizarla dos veces, uno en positivo (Factura original) y otra en negativo (Anulación), ya que como tu dices sino dejas un hueco.

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

Empezado por FranAza

No sé si vuestros sistemas tienen procesos de traspasos (enlaces) contables de facturas a otros softwares de contabilidad.
En estos procesos de traspasos contables de las facturas de ventas nos surgen varias dudas con respecto a las facturas anuladas con el sistema TBAI.

Para nosotros una factura ANULADA es como si borraras la factura del sistema.
No se tierne en cuenta para nada (ni contablemente).

Sí que guardamos la información necesaria para justificar ese borrado/anulación (si fuera necesario), pero no queda constancia en ningún sitio más.

[ermendalenda]

Una pregunta, solo por confirmar. Estoy desarrollando la importación de facturas de otro sistema antiguo para poder generar ticketbai. Supongo que es legal totalmente si solo las emito, imprimo y envío desde el sistema nuevo.
Que pensáis?

[ermendalenda]

Otra pregunta, los que trabajáis con albaranes, si alguno tenéis devoluciones de mercancía en el que se entremezclan varios días de productos y por tanto es imposible saber de qué factura es, se supone que no podéis hacer rectificativa. Como lo hacéis. Se me ha ocurrido dividir las facturas en tantos impositivos que tengan y así la ley parece que permite poner las devoluciones junto con las ventas, tenéis alguna idea distinta?

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

Empezado por ermendalenda

Una pregunta, solo por confirmar. Estoy desarrollando la importación de facturas de otro sistema antiguo para poder generar ticketbai. Supongo que es legal totalmente si solo las emito, imprimo y envío desde el sistema nuevo.
Que pensáis?

Tal vez tendrías que realizar la consulta a los de TicketBAI.
Al final el sistema debe asegurar que ese proceso no se puede alterar y que no se pueden generar facturas sin que suban a TicketBAI.

Si ese proceso de "importación" de un sistema a otro es seguro no debería haber problema, pero si eso depende del usuario tal vez no sirva.

Al final no creo que sea importante si se hare con 1 EXE, con 2 EXEs o con 1 EXE y 1 DLL. Lo que tienes que asegurar es que sea fiable para evitar el fraude.
(pero esto es opiniñon, quien meor te lo puede decir son los de TBAI).

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

[OFFTOPIC]
Buenos días/tardes/noches.

Sólo como aviso a los que entráis habitualmente a este foro, comentaros que durante los últimos días hemos tenido problemas en los foros relacionados con el correo.
Es posible que debido a eso no hayáis recibido notificaciones de los cambios en este hilo (ni en otros).
Parece que nuestro proveedor los ha solucionado, así que sirva este mensaje para informaros, para activar las notificaciones de nuevo a los que estáis suscitos y para pedir disculpas por los inconvenientes.

Un saludo del staff.
[/OFFTOPIC]

[thinkows]

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

Tal vez tendrías que realizar la consulta a los de TicketBAI.
Al final el sistema debe asegurar que ese proceso no se puede alterar y que no se pueden generar facturas sin que suban a TicketBAI.

Si ese proceso de "importación" de un sistema a otro es seguro no debería haber problema, pero si eso depende del usuario tal vez no sirva.

Al final no creo que sea importante si se hare con 1 EXE, con 2 EXEs o con 1 EXE y 1 DLL. Lo que tienes que asegurar es que sea fiable para evitar el fraude.
(pero esto es opiniñon, quien meor te lo puede decir son los de TBAI).

En mi opinión es legal. ya que existen en el mercado API'S y softwares (p.ej BINOVO) que justamente realizan esa función y están dados de alta en software garante.
Saludos