Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[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

[afxe]

Ermendalenda dijo:

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.

Me sirve... tenía planeado algo así... recibir las facturas en un servidor propio y encargarnos nosotros de realizar el envío a Hacienda. Pero me preocupa que el usuario use mi programa en dos puestos con series diferentes y a uno de ellos le borre las DNS o bloquee su salida a internet, por ejemplo, provocando que sólo me llegue una de las series. No sé si Hacienda clasificaría como software de doble uso un sistema así. Realmente sería sencillo seguir trabajando con "B", ya que lo normal en ventas del día a día (bares y tiendecitas) es que nadie solicite el ticket impreso, o te presenten un "ticket proforma" sin QR...

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

Empezado por afxe

Realmente sería sencillo seguir trabajando con "B", ya que lo normal en ventas del día a día (bares y tiendecitas) es que nadie solicite el ticket impreso, o te presenten un "ticket proforma" sin QR...

Y en cuanto un usuario te pida un ticket "correcto" ya la tienes liada...
Si le das un ticket sin QR (cuando esté estandarizado) te va a decir que "eso que es". ¿Tendrás opción de generar con QR y sin QR?
¿Le dirás que con QR no puedes?
Si es un ticket que presenta a una empresa (gastos de empresa) te dirá que ese ticket no es válido, que quiere el "bueno".

No se, yo no lo veo nada fácil.
Que habrá o se inventarán formas, seguro, pero fácil no lo veo y menos sin la complicidad del software informático. Por eso el incapié en las multas a las empresas desarrolladoras que facilitene sas trampas.

[[newtron]]

Empezado por keys

La ley dice lo siguiente no solo un log de entrada/salida de usuarios.

Tiquismiquis....

[/quote]

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

Y en cuanto un usuario te pida un ticket "correcto" ya la tienes liada...
Si le das un ticket sin QR (cuando esté estandarizado) te va a decir que "eso que es". ¿Tendrás opción de generar con QR y sin QR?
¿Le dirás que con QR no puedes?
Si es un ticket que presenta a una empresa (gastos de empresa) te dirá que ese ticket no es válido, que quiere el "bueno".

No se, yo no lo veo nada fácil.
Que habrá o se inventarán formas, seguro, pero fácil no lo veo y menos sin la complicidad del software informático. Por eso el incapié en las multas a las empresas desarrolladoras que facilitene sas trampas.

En los restaurantes sobre todo cuando pides la cuenta te dan un papel que pone "Proforma" o "Preventa" o cualquier tontería de esas. Imagino que la mayoría de la gente (yo por ejemplo) pagan y se van pero imagino también que si pides el ticket te lo harán con su numeración correcta y tan felices. Lo que no entiendo es cómo la AEAT con lo que son no se meten en ese comportamiento y empiezan a dar estacazos.

Saludos.

[ermendalenda]

Empezado por newtron

Tiquismiquis....

En los restaurantes sobre todo cuando pides la cuenta te dan un papel que pone "Proforma" o "Preventa" o cualquier tontería de esas. Imagino que la mayoría de la gente (yo por ejemplo) pagan y se van pero imagino también que si pides el ticket te lo harán con su numeración correcta y tan felices. Lo que no entiendo es cómo la AEAT con lo que son no se meten en ese comportamiento y empiezan a dar estacazos.

Saludos.[/quote]


A ver, ya sabemos que hay de todo, pero también te digo que yo creo que con la caña de inspecciones que estan haciendo,cada vez menos.
Son varias las razones por las que se hace así, créeme que ya les gustaría a la mayoría de los restauradores ahorrar en papel y no dar 2 viajes a las mesas.
1. Dar la posibilidad al cliente de repasar el tiquet sin tener después que nadar haciendo rectificativas, tanto de productos servidos como de precio. Ya que el camarero se ha podido equivocar. Y a gi te gustará repasarlo pero el camarero no puede estar a tu lado hasta que esté todo correcto por eso se deja el Preventa o previo tiquet o comanda o como quieran llamarlo cada uno

2.dar la posibilidad al cliente de pedir algo más y poner en la misma cta por que en el último instante ha llegado alguien
3. Dar la posibilidad al cliente de poder dividir la cta entre varios comensales y darle a cada uno su ticket, que eso lo pueden decidir después de ver el total.
4.que al grabar el tiquet quede reflejado correctamente la forma de pago, tanto como para imprimir como para la gestión interna.
5. Que al restaurador le permita solucionar un "sinpa" sin cerrar el tiquet y pagando más impuestos de la cuenta

[Casimiro Noteví]

Empezado por ermendalenda

A ver, ya sabemos que hay de todo, pero también te digo que yo creo que con la caña de inspecciones que estan haciendo,cada vez menos.
Son varias las razones por las que se hace así, créeme que ya les gustaría a la mayoría de los restauradores ahorrar en papel y no dar 2 viajes a las mesas.
1. Dar la posibilidad al cliente de repasar el tiquet sin tener después que nadar haciendo rectificativas, tanto de productos servidos como de precio. Ya que el camarero se ha podido equivocar. Y a gi te gustará repasarlo pero el camarero no puede estar a tu lado hasta que esté todo correcto por eso se deja el Preventa o previo tiquet o comanda o como quieran llamarlo cada uno
2.dar la posibilidad al cliente de pedir algo más y poner en la misma cta por que en el último instante ha llegado alguien
3. Dar la posibilidad al cliente de poder dividir la cta entre varios comensales y darle a cada uno su ticket, que eso lo pueden decidir después de ver el total.
4.que al grabar el tiquet quede reflejado correctamente la forma de pago, tanto como para imprimir como para la gestión interna.
5. Que al restaurador le permita solucionar un "sinpa" sin cerrar el tiquet y pagando más impuestos de la cuenta

Creo que no conoces Andalucía
Edito: ¡¡¡Pero si somos casi vecinos!!!

[ermendalenda]

Empezado por Casimiro Notevi

Creo que no conoces Andalucía
Edito: ¡¡¡Pero si somos casi vecinos!!!

Jefe supongo que sí eres moderador podrás ver mi ubicación aproximada. Jeje.
Bueno ya sabes que conozco Andalucía, pero aún conozco más grandes empresas que Dan servicios informáticos a los restauradores y sé como están actuando y aquí no se la juegan

[ermendalenda]

Empezado por afxe

Ermendalenda dijo:



Me sirve... tenía planeado algo así... recibir las facturas en un servidor propio y encargarnos nosotros de realizar el envío a Hacienda. Pero me preocupa que el usuario use mi programa en dos puestos con series diferentes y a uno de ellos le borre las DNS o bloquee su salida a internet, por ejemplo, provocando que sólo me llegue una de las series. No sé si Hacienda clasificaría como software de doble uso un sistema así. Realmente sería sencillo seguir trabajando con "B", ya que lo normal en ventas del día a día (bares y tiendecitas) es que nadie solicite el ticket impreso, o te presenten un "ticket proforma" sin QR...

Yo en en el servidor tengo varias comprobaciones:
Compruebo de nuevo la estructura contra el xsd, compruebo encadenamiento compruebo que ko haya saltos de numerador de cada serie, compruebo que en esa caja/comercio se hayan enviado ventas después de las últimas 30 horas anteriores(si voy mandando un correo todos los días durante 1 semana).

[ermendalenda]

Empezado por afxe

Ermendalenda dijo:



Me sirve... tenía planeado algo así... recibir las facturas en un servidor propio y encargarnos nosotros de realizar el envío a Hacienda. Pero me preocupa que el usuario use mi programa en dos puestos con series diferentes y a uno de ellos le borre las DNS o bloquee su salida a internet, por ejemplo, provocando que sólo me llegue una de las series. No sé si Hacienda clasificaría como software de doble uso un sistema así. Realmente sería sencillo seguir trabajando con "B", ya que lo normal en ventas del día a día (bares y tiendecitas) es que nadie solicite el ticket impreso, o te presenten un "ticket proforma" sin QR...

Yo en en el servidor tengo varias comprobaciones:
Compruebo de nuevo la estructura contra el xsd, compruebo encadenamiento compruebo que ko haya saltos de numerador de cada serie, compruebo que en esa caja/comercio se hayan enviado ventas después de las últimas 30 horas anteriores(si no voy mandando un correo todos los días durante 1 semana).

[ermendalenda]

Empezado por ermendalenda

Yo en en el servidor tengo varias comprobaciones:
Compruebo de nuevo la estructura contra el xsd, compruebo encadenamiento compruebo que ko haya saltos de numerador de cada serie, compruebo que en esa caja/comercio se hayan enviado ventas después de las últimas 30 horas anteriores(si no voy mandando un correo todos los días durante 1 semana).

Si ves que pueden clonar equipos y quitarlos se la red puedes poner un límite de registros de facturas sin enviar y bloquear con clave

[[newtron]]

Gracias.

Entiendo entonces que todavía no se puede hacer ninguna prueba. Lo que también hay que tener en cuenta y se me olvidaba es activar un log de entrada/salida por usuarios, creo, ¿no?.

Saludos.

[keys]

Empezado por newtron

Gracias.
Entiendo entonces que todavía no se puede hacer ninguna prueba. Lo que también hay que tener en cuenta y se me olvidaba es activar un log de entrada/salida por usuarios, creo, ¿no?.

Saludos.

La ley dice lo siguiente no solo un log de entrada/salida de usuarios.

4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente
todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los
sucesos producidos durante su uso, como el arranque y parada del sistema informático, la entrada
y salida de usuarios, los errores producidos, la instalación inicial y las actualizaciones realizadas.
Además, deberá guardar los datos correspondientes a cada uno de ellos, como el tipo, nombre y
descripción del evento; el usuario que lo ha realizado o bajo el cual se ha producido; el momento
en el que se ha dado y los datos propios representativos de cada evento.
Este registro de eventos podrá ser consultado desde el propio sistema informático y los datos
grabados automáticamente en él por dicho sistema informático no podrán ser alterados de
ninguna forma con posterioridad, ni desde el propio sistema informático ni desde fuera del mismo,
lo que deberá garantizarse mediante el empleo de cualquier proceso técnico fiable. Cualquier
intento de alteración de este registro de eventos, o inconsistencia o irregularidad en él que sea
detectado por el sistema informático, deberá registrarlo también automáticamente en el propio
registro de eventos.
El registro de eventos deberá conservarse hasta el periodo de prescripción de las obligaciones
tributarias que se produzcan durante el funcionamiento del sistema informático y, mediante el
empleo de cualquier proceso técnico fiable, podrá ser exportado a un almacenamiento externo de
forma segura que garantice la integridad e inalterabilidad de sus datos, que tendrán una estructura
y formato estándares legibles.

[edari]

Empezado por keys

La ley dice lo siguiente no solo un log de entrada/salida de usuarios.

Supongo que todos los que tenéis preparado este log de operaciones es a través de las prestaciones que os ofrezca la base de datos que uséis cada uno, verdad?

[[newtron]]

Me temo que las bases de datos que solemos usar no tienen esa opción, la mía por lo menos no la tiene (ElevateDB) así que habrá que montar toda esa movida "a pelo".

Por si a alguien le sirve aquí hay unos componentes que dicen que hacen precisamente eso aunque yo no los he probado.

Saludos.

[keys]

Lógimente cada uno tendrá que hacerlo de la mejor manera y que se lo permita su motor de base datos para no afectar mucho al rendimiento de la aplicación.

Para los que tengais firebird os paso este enlace que puede ser un buen punto de partida https://firebird21.wordpress.com/202...a-informatica/

[keys]

De todas formas la ley dice los siguiente

Cualquier intento de alteración de este registro de eventos, o inconsistencia o irregularidad en él que sea
detectado por el sistema informático, deberá registrarlo también automáticamente en el propio
registro de eventos.

Si la base de datos no permite registrar estas cosas, y intentan entrar en el registro de eventos. Esto no se podrá hacer ya que nuestras aplicaciones no se enteraran.

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

Empezado por edari

Supongo que todos los que tenéis preparado este log de operaciones es a través de las prestaciones que os ofrezca la base de datos que uséis cada uno, verdad?

Nosotros vamos a almacenar esos eventos desde la aplicación.
Para determinadas operaciones que realiza el usuario (entrada/salida/activación/desactivación/...).