Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[[newtron]]

Sin saber nada de TicketBAI la lógica me dice que el responsable de cumplir con la normativa es el programa que emite la factura originalmente y efectivamente hay muchas cosas de las que no se ha hablado como son facturas emitidas por webs, balanzas, registradoras, terminales móviles y tantos millones de dispositivos que andan por el mundo haciendo facturas simplificadas. No estaría mal ir enterándose de qué pasará con esas cosas.

Saludos.

[keys]

En TicketBAI cualquier dispositivo que emita facturas (BALANZAS, TPV, Etc..) se tiene que adaptar a TicketBAI. Me imagino que en verifactu ocurrirá lo mismo.

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

En el caso de TicketBAI (que por algo lleva el prefijo de Ticket) cuando tú entregas un ticket, ya debe llevar impreso el QR con toda la información necesaria para que el usuario pueda validar esa factura en la web de hacienda. Por lo tanto el terminal que emite ese ticket (o el software asociado) son los que deben realizar la emisión/generación/envío de esa factura.

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

Empezado por afxe

... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP.

No se si mi mensaje anterior te aclara algo, pero en el caso de TicketBAI (que está pensado para tickets principalmente), si el usuario se lleva un "Ticket" (por ejemplo porque consume un café en un restaurante), cuando se ha generado ese ticket, ese software ya debe haber realizado todo el trabajo de generación del XML, firma, QR,... Por lo tanto, cuando tu software importe esas facturas , todo eso ya debe estar hecho.

En realidad es que TicketBAI se ha implementado (y por eso lleva el prefijo Ticket) para los negocios "pequeños" que generan tickets. Que son los que hasta ahora se les "descontrolaban" (en cuando a ventas y fiscalidad). Lo que pretenden es que todos esos negocios (bares, restaurantes, peluquerías, tiendas pequeñas, chinos,....) que hasta ahora te daban un ticket (no una factura) y a final de mes nadie sabía realmente lo que facturaban, ahora estén fiscalizadas igual que las grandes.

[Sistel]

Empezado por afxe

Sin pretender abusar de los que ya os habéis peleado con el TicketBai... ¿Cómo se gestionan las facturas que son emitidas por otros softwares y que son importadas al ERP? Por poner ejemplos:

- Prestashop, wordpress, wooCommerce.... Nuestro ERP recibe las facturas ya hechas y las incorpora al fichero de facturación. ¿Tiene que estar el Presta preparado para Veri*factu?

- Tengo con una distribuidora de pescado y marisco que vende a restaurantes y hoteles... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP. Imagino que esta empresa hará la comunicación con H.P... pero el tratamiento fiscal de dichas facturas lo hace nuestro ERP. ¿Podemos almacenar facturas de otros sistemas sin presentarlas?

- Una cadena de pescaderías tienen balanzas inteligentes. Hacen facturas simplificadas y por la noche transmiten las ventas realizadas que se incorporan como una única factura recapitulativa por cada balanza... por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos?

¿Cómo habéis resuelto estas situaciones con el TicketBai?

Hola afxe,

Te cuento cómo hemos resuelto nosotros los mismos escenarios que tú comentas en caso de nuestros clientes en TicketBAI:

- Prestashop, wordpress, wooCommerce.... Nuestro ERP recibe las facturas ya hechas y las incorpora al fichero de facturación. ¿Tiene que estar el Presta preparado para Veri*factu?

En el caso de tiendas online se puede dar el caso de que emitan facturas directamente (al hacer el pedido y pago por tarjeta o Paypal) o se emitan, posteriormente, desde otra aplicación.
Para el caso de nuestros clientes con tienda online Wordpress-Woocommerce que emiten facturas directamente desde esa aplicación, sólo tienen que instalar nuestro plugin que hará todos los procesos, incluida la generación del PDF de la factura con los códigos TBAI y QR y el envío automático, inmediato, del XML firmado la factura a Hacienda Foral.

- Tengo con una distribuidora de pescado y marisco que vende a restaurantes y hoteles... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP. Imagino que esta empresa hará la comunicación con H.P... pero el tratamiento fiscal de dichas facturas lo hace nuestro ERP. ¿Podemos almacenar facturas de otros sistemas sin presentarlas?

TicketBAI obliga a que se envíen las facturas emitidas, ya sean facturas simplificadas (llamadas habitualmente tickets) o facturas completas en el mismo momento de emitirse.
Por lo cual cualquier equipo emisor de facturas (incluidos TPVs, balanzas electrónicas o cualquier otro) debe tener conexión a Internet.
No pueden almacenarse las facturas para enviarse posteriormente.

- Una cadena de pescaderías tienen balanzas inteligentes. Hacen facturas simplificadas y por la noche transmiten las ventas realizadas que se incorporan como una única factura recapitulativa por cada balanza... por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos?

Con TicketBAI se deben enviar todas las facturas simplificadas en el mismo momento de su emisión.
Aparte, pueden emitirse, posteriormente, facturas completas sustitutivas de facturas simplificadas (llamadas habitualmente facturas de canje de tickets) que agrupen a varias. Pero es una nueva factura y no exime del envío de las primeras.

Hay responsabilidad por parte del obligado tributario (la persona física o jurídica que debe emitir las facturas) así como por parte de la empresa desarrolladora del software garante TicketBAI (que debe haber obtenido licencia para ello).
El software no debe tener posibilidad de contabilidad "B", ni de borrado de facturas o de manipulación de facturas.
Una factura emitida es algo casi sagrado e intocable porque va encadenada mediante firma con la anterior y posterior.

Las sanciones son suficientemente fuertes como para que a nadie se le ocurra infringir las normas.

Saludos

[keys]

Hola a todos.

Se supone que hay que evitar que los datos se alteren, pero si el usuario si es un poco listo podrá entrar en el fichero físico de la base de datos por su cuenta y borrar un registro.

Nuestra base da datos esta en firebird 2.5 y podemos cambiar la clave el usuario e incluso borrar el usuario SYSDBA. Pero si el usuario se lleva el fichero de la base de datos a otro ordenador con el mismo motor podrá acceder con el Usuario maestro (SYSDBA).

La pregunta es si hay alguna forma de evitar esto en firebird o si en alguna versión más reciente ha cambiado esto.

[Casimiro Notevi]

Un usuario no puede tener acceso a la BD para llevársela, copiarla ni nada por el estilo.
Por algo es un sistema cliente/servidor, los clientes no tienen que saber ni dónde está la BD.
Los clientes/terminales/usuarios no deben tener acceso al servidor. El servidor no puede tener compartida carpetas ni nada que permita a cualquiera entrar y copiar la BD.
Firebird solamente necesita tener abierto el puerto 3050 en el servidor, nada más.
Aparte de eso, es un tema que se ha tratado otras veces, a ver si lo encuentro... para no repetir lo mismo en este hilo que no trata sobre eso.

[Sistel]

Empezado por Casimiro Notevi

Un usuario no puede tener acceso a la BD para llevársela, copiarla ni nada por el estilo.
Por algo es un sistema cliente/servidor, los clientes no tienen que saber ni dónde está la BD.
Los clientes/terminales/usuarios no deben tener acceso al servidor. El servidor no puede tener compartida carpetas ni nada que permita a cualquiera entrar y copiar la BD.
Firebird solamente necesita tener abierto el puerto 3050 en el servidor, nada más.
Aparte de eso, es un tema que se ha tratado otras veces, a ver si lo encuentro... para no repetir lo mismo en este hilo que no trata sobre eso.

Hola,

Opino como tú.
Lo mejor es utilizar una arquitectura cliente/servidor donde el usuario no tenga acceso alguno al servidor donde se guardan las facturas.
La aplicación le muestra los datos que deba ver, cuando los pida, y punto pelota.

Saludos

[keys]

Empezado por Sistel

Hola,

Opino como tú.
Lo mejor es utilizar una arquitectura cliente/servidor donde el usuario no tenga acceso alguno al servidor donde se guardan las facturas.
La aplicación le muestra los datos que deba ver, cuando los pida, y punto pelota.

Saludos

Gracias a los dos.

Estoy de acuerdo con lo que decís, el sistema ya esta configurado de esa manera. Pero al tratarse de una aplicación comercial, es el usuario el que instala la aplicación en su servidor y lógicamente tiene acceso a todos los ficheros de su sistema.

Un Saludo.

[Casimiro Notevi]

A ver si encuentro esos enlaces...

[ermendalenda]

Empezado por afxe

Sin pretender abusar de los que ya os habéis peleado con el TicketBai... ¿Cómo se gestionan las facturas que son emitidas por otros softwares y que son importadas al ERP? Por poner ejemplos:

- Prestashop, wordpress, wooCommerce.... Nuestro ERP recibe las facturas ya hechas y las incorpora al fichero de facturación. ¿Tiene que estar el Presta preparado para Veri*factu?

- Tengo con una distribuidora de pescado y marisco que vende a restaurantes y hoteles... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP. Imagino que esta empresa hará la comunicación con H.P... pero el tratamiento fiscal de dichas facturas lo hace nuestro ERP. ¿Podemos almacenar facturas de otros sistemas sin presentarlas?

- Una cadena de pescaderías tienen balanzas inteligentes. Hacen facturas simplificadas y por la noche transmiten las ventas realizadas que se incorporan como una única factura recapitulativa por cada balanza... por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos?

¿Cómo habéis resuelto estas situaciones con el TicketBai?

Hola, te hago u pequeño resumen, el software que emita la factura, da igual que sea una balanza o un software de terceros , tiene que gestionar la generación del xml con sus respectivas las huellas , esos xmls o se podrán alterar ya que si envías uno alterado a hacienda se van a dar cuenta por el encadenamiento otra cosa es el envío, si se ha seleccionado la opción envio, esos xmls se pueden enviar desde ese software o desde otro pero el que genera el xml es el que principalmente debe estar dado de alta y referencia do que se envia con otra api, software, servicio...
Puedes importar posteriormente las facturas a otro ERP para gestionar la contabilidad y ese ERP puede estar separado del que emite las facturas. Si un empleado, empresa o autónomo, separa ese dispositivo de facturación de la generación de tiquets o facturas verificadas con su qr y no emite el xnl ni lo envía ni lo guarda con intención de no declararla, lógicamente, el distribuidor del software y/o empresa i staladora/mantenimiento no tienen responsabilidad siempre que no se haya participado en facilitarlo, que el software no tenga alguna trampa demostrable. Aún así entiendo que habrá situaciones dudosas, pero se entiende que so hay duda razonable cualquier acusación se quedará en nada.
Saludos

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

Empezado por afxe

por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos?

Con este sistema eso es lo que se intenta evitar y es lo que van a conseguir.
De todas formas no hace falta algo tan complejo. Simplemente en una tienda que emitía tickets, bastaba con "tirar a la basura" 1 de cada tres tickets que te han pagado en efectivo.

Ahora eso ya no será posible, porque el ticket debe lllevar el QR y eso significa que ha entrado en el sistema, se ha generado y se ha enviado a hacienda (y el usuario podrá escanearlo y comprobarlo). A no ser que no entregarás nada al cliente y a posteriori lo hicieras "desaparecer" (pero eso no es nada habitual).

Yo creo que en ese caso, si el cliente ha "tocado" la balanza y el sistema informático no ha facilitado las trampas, no es responsabilidad del software, sí del cliente.

[afxe]

si el cliente ha "tocado" la balanza y el sistema informático no ha facilitado las trampas, no es responsabilidad del software, sí del cliente

Realmente, en el caso que he comentado, ni siquiera administración sabía que se estaba inicializando la balanza antes de comunicar... la trampa la estaba haciendo un empleado que consideraba que su sueldo no era justo.

Pero centrando en tema y sentar bases de trabajo (corríjanme si me equivoco):

1º El software que emite la factura tiene que generar inmediatamente el XML y un QR que identifique la factura. Se supone que el XML ya tiene que tener la huella generada y el encadenamiento.

2º Esas facturas emitidas pueden ser recogidas por otro software, como un ERP o una Contabilidad. Lo único obligatorio para estos receptores de facturas es que tenga registrado el XML generado por el SIF, el XML no debe ser generado (o recarlculado) a posteriori por ningún otro software.

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

¿Este planteamiento es correcto? ¿Un sistema calificado como VERI*FACTU puede NO enviar las facturas en tiempo real?

[[newtron]]

Quiero recordar que en una charla que dieron los de hacienda sobre este tema aclararon que, aunque el software siempre debe de estar preparado para enviar los datos, es decisión del usuario final enviarlos o no. Por supuesto aclararon que los que enviaran datos estarían menos controlados que los que no.

[Sistel]

Empezado por afxe

Realmente, en el caso que he comentado, ni siquiera administración sabía que se estaba inicializando la balanza antes de comunicar... la trampa la estaba haciendo un empleado que consideraba que su sueldo no era justo.

Pero centrando en tema y sentar bases de trabajo (corríjanme si me equivoco):

1º El software que emite la factura tiene que generar inmediatamente el XML y un QR que identifique la factura. Se supone que el XML ya tiene que tener la huella generada y el encadenamiento.

2º Esas facturas emitidas pueden ser recogidas por otro software, como un ERP o una Contabilidad. Lo único obligatorio para estos receptores de facturas es que tenga registrado el XML generado por el SIF, el XML no debe ser generado (o recarlculado) a posteriori por ningún otro software.

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

¿Este planteamiento es correcto? ¿Un sistema calificado como VERI*FACTU puede NO enviar las facturas en tiempo real?

Hola afxe,

Contesto a tus preguntas (suponiendo que el reglamento de Verifactu sea, al final, similar al de TicketBAI)

1º Sí
2º Sí
3º En TicketBAI de Álava y Gipuzkoa el envío debe ser inmediato (en el mismo momento de generar la factura).
En Batuz-TicketBAI de Bizkaia en los mismos plazos de las declaraciones de IVA (trimestral en la mayoría de los casos, mensual en algunos otros y en 4 días para los anteriormente obligados al SII, al que también sustituye)
4º Parece poco aconsejable dejar la base de datos de facturas emitidas al alcance del cliente (que seguro que tiene un cuñado que sabe manipularlas).
Me parece que lo razonable es que se transfieran a un sistema más seguro y que se considere que las facturas "legales" son las almacenadas en dicho sistema seguro.

¿Un sistema calificado como VERI*FACTU puede NO enviar las facturas en tiempo real?

Creo que se comentó que habría posibilidad de no enviarlas, pero dejándolas, en ese caso, encadenadas y a merced de la inspección de cualquier inspector de Hacienda.
Por lo que .... mejor enviar que estar recibiendo visitas frecuentes inoportunas.

Saludos

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

Empezado por afxe

1º El software que emite la factura tiene que generar inmediatamente el XML y un QR que identifique la factura. Se supone que el XML ya tiene que tener la huella generada y el encadenamiento.

Correcto.
En realidad el QR se puede generar en cualquier momento, hasta en el momento justo de imprimir, porque no cambia, es independiente del momento en el que se genere. Lo que sí debe ser inmediato es el XML.

Empezado por afxe

2º ... el XML no debe ser generado (o recarlculado) a posteriori por ningún otro software.

En realidad no se puede. Porque al volver a generarlo cambiaría y eso afectaría al encadenamiento.
El encadenamiento justo es para asegurar que una vez generada la factura N, la (N-1) ya no se va a modificar (y así recursivamente hacia atrás).

Empezado por afxe

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)

No se si se especifica por ahora, pero la lógica es que el programa que realiza la factura, genera el XML y lo firma sea el que permite comunicar.
Por ahora para la LeyAntifraude parece que se podrá optar por enviar automáticamente (VERI*FACTU) o bajo petición cuando hacienda lo solicite.

Empezado por afxe

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

La mayoría de Gestores de Base de Datos actuales disponen de seguridad, así que aplicada correctamente no veo porqué no se puede dejar una Base de Datos en un equipo de un cliente. Si está protegida correctamete sólo el programa(ERP) puede/debe tener acceso a ella. Estoy pensando no sólo en controlar el acceso sino en temas de encriptación (anti-cuñaos-sabiondos ;-D ).
Otro tema es como gestionar la seguridad en cuanto a copias de seguridad.

[ermendalenda]

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)


Hay que esperar al reglamento definitivo con todas las pautas bien definidas en su Doctrinas. Lo que pienso que van a decir es que debes enviarlo loables posible teniendo en cuenta las reglas de mínimos de facturas y tiempos, que esas reglas te las podrán ir cambiando después de cada enviom

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

Está claro que existen unas normas de seguridad mínima de acceso a datos y la nueva ley te dice que hay que intentar evitar la modificación de los mismos, pero
Si seleccionas la modalidad de envío te vas a evitar muchos quebraderos de cabeza. Si te sirve, mi software t4abaja en local pero lo que hago es enviar cada venta en un XML a un servidor externo con in servicio REST que guarda todas las ventas y el se encargará de enviarlas a verifactu. Con lo cual tengo garantizada la inviolabilidad.

[[newtron]]

Hola a tod@s.

Entonces... para ir aclarándome que me he despistado un poco de este tema. El asunto está en que a todas las facturas/facturas simplificadas de venta hay que ponerle una marca determinada, firmarlas y a partir de ahí no se podrán modificar. Por otro lado el programa tiene que tener la capacidad de enviarlas a un webservice y es el cliente el que decide si las envía o no.

¿Es correcto este resumen?

Gracias y un saludo.

[Sistel]

Empezado por newtron

Hola a tod@s.

Entonces... para ir aclarándome que me he despistado un poco de este tema. El asunto está en que a todas las facturas/facturas simplificadas de venta hay que ponerle una marca determinada, firmarlas y a partir de ahí no se podrán modificar. Por otro lado el programa tiene que tener la capacidad de enviarlas a un webservice y es el cliente el que decide si las envía o no.

¿Es correcto este resumen?

Gracias y un saludo.

Hola newtron,

En Verifactu está aún por definir hasta que se publique el reglamento.

Te puedo contar cómo se hace en TicketBAI (supongo de Verifactu al final será algo similar):
- Recopilas todos los datos de la factura (emisor, destinatario, líneas de detalle, régimen de IVA del emisor, serie, número, fecha, hora, etc)
- Creas un XML que contiene esa información junto con parte de la firma de la factura anterior + los datos de la licencia de software garante TicketBAI
- Firmas ese XML con un certificado digital
- Obtienes un código TBAI y un código QR, a partir de la firma del XML y los imprimes en la factura
- Envías el XML firmado de forma inmediata (salvo en Bizkaia, que con Batuz tienes un tiempo algo mayor)

En Verifactu parece ser que van a dejar la opción de que no envíes, pero que a cambio de que tengas la puerta abierta para que te visite el inspector de Hacienda, un día sí y otro también, para comprobar el correcto encadenamiento de las facturas.

Saludos

[ermendalenda]

Empezado por newtron

Hola a tod@s.

Entonces... para ir aclarándome que me he despistado un poco de este tema. El asunto está en que a todas las facturas/facturas simplificadas de venta hay que ponerle una marca determinada, firmarlas y a partir de ahí no se podrán modificar. Por otro lado el programa tiene que tener la capacidad de enviarlas a un webservice y es el cliente el que decide si las envía o no.

¿Es correcto este resumen?

Gracias y un saludo.

Hola, no exactamente, si el cliente decide no enviar, tiene que buscar un software que lo permita, ya que no todos los programas van a tener esa opción. La única opción obligatoria a incluir en el programa es la de envío y SE PERMITE, que tenga la opción de no enviar.
Yo por ejemplo, que como la mayoría de vosotros, soy desarrollador, no voy a incluir la opción de no enviar por 3 motivos evidentes: 1.no quiero problemas, 2.no quiero problemas, 3.no quiero problemas.
Por otro lado los tipos de facturas hay algunos mas:
Factura Simplificada
Factura Normal
Factura Simplificada Rectificativa
Factura Rectificativa de Factura normal
Factura recapitulativa
Factura de canje/sustituiva

Te lo digo por que cada tipo debe tener su numero de serie