Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[nincillo]

Empezado por oscarperez-1980

Alguien más interesado?
Yo ya lo tengo analizado y no lo veo complejo, el registro es de lo más curioso, lo quieren detallado para exportar a Excel y que no tengan que hacer nada.

Yo también estaría interesado. Pero de blockchain etc soy novato total...

[oscarperez-1980]

Exacto, como pone el compi lo llama registro de eventos


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

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

Empezado por oscarperez-1980

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

Quiero entender que eso sólo afecta todo lo que se refiera a "facturación" (es decir, lo que concierne a la AEAT).
En el caso de TBAI (que parece lógico), esto afecta sóo estrictamente a los campos que "le interesan a la hacienda vasca" (los que se envían).
Lo digo por aclarar, es que ese "TODAS" creo que no queda claro y puede llevar a confusión.

NOTA: O al menos eso "quiero" entender yo. Habrá que esperar a que lo aclaren.

[oscarperez-1980]

Yo entiendo que todo es de todo, no solo de facturación y tiene lógica, para ver si hay algo raro oculto...
Además ya que se pone un log.. Pues mejor de todo, es mi opinión.

Saludos.

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

Quiero entender que eso sólo afecta todo lo que se refiera a "facturación" (es decir, lo que concierne a la AEAT).
En el caso de TBAI (que parece lógico), esto afecta sóo estrictamente a los campos que "le interesan a la hacienda vasca" (los que se envían).
Lo digo por aclarar, es que ese "TODAS" creo que no queda claro y puede llevar a confusión.

NOTA: O al menos eso "quiero" entender yo. Habrá que esperar a que lo aclaren.

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

Empezado por oscarperez-1980

Yo entiendo que todo es de todo, no solo de facturación y tiene lógica, para ver si hay algo raro oculto...

Pero estamos dentro de un contexto de ley antifraude, que se refiere a "facturación".
¿Crees que esto me debe obligar a almacenar eventos de todos mis cambios en todas mis tablas?
Pienso en tablas como (por poner alguna): REPRESENTANTES, LOGOS, POBLACIONES, PAISES, CODIGOS_ISO, OFERTAS, CONTACTOS, DIRECCIONES_ENVIO, EMBALAJES, FASES, PIEZAS, INMUEBLES,...

Yo no le veo sentido ni justificación a que la ley antifraude me obligue a guardar "logs" de las operaciones realizadas en la tabla FASES (por poner un ejemplo).

Empezado por oscarperez-1980

...para ver si hay algo raro oculto...

¿Algo "oculto" en mi mantenimiento de provincias? (por decir algo)

Empezado por oscarperez-1980

Además ya que se pone un log.. Pues mejor de todo, es mi opinión.

Si tienes una Base Bases de Datos de cliente con 6GB/400 tablas y X operaciones diarias, la decisión no es tan sencilla como "ya que lo ponemos, lo ponemos a todo".
Piensa que eso implica no sólo cambios en la aplicación, sino seguramente en otros muchos aspectos.
Lo primero que se me ocurre es ¿Cómo puede crecer esa Base de Datos si a las 400 tablas les debo añadir "eventos" para todas las operaciones?

¿Porqué pienso esto? (lo dicho anteriomente)
Me baso en la experiencia de TicketBAI (y en la idea final que se ha implementado), en donde ellos quieren asegurar al final, que una factura no pueda ser modificada de ninguna forma, una vez emitida.

Esto dicho así, parece que significa que una vez generada una factura la debes poner en "sólo-lectura".
La respuesta de ellos fue que no.
Se puede modificar una factura emitida/enviada/Aceptada siempre y cuando no alteres los campos que afectan a TBAI. Si en tu factura incluyes NOTAS, REPRESENTANTES, CENTROSDECOSTE, LOGO, DIR_ENVIO, ALARMAS, RIESGO, DOMICILIACIONESBANCARIAS,... (por decir algo), puedes modificarlos sin problemas. A ellos esos campos NO LES INTERESAN (sólo los que afectan a la generación del XML de la factura).

Por eso creo que la "idea" en este caso irá por el mismo camino. Creo que cuando hablan de TODO, se refieren a temas de facturación (además de otros temas genéricos que tienen sentido, como login de usuarios, inicio y fin,...); Lo que pueda afectar a un fraude a la AEAT. Pero que yo modifique un CODIGO_ISO o una PROVINCIA no puede afectar a eso.

De todas formas, como ya hemos dicho, creo que nos estamos adelantando. Lo único que hay es un decreto ley (o documentación legal), no hay documentación técnica y por lo tanto técnicamente creo que no se debería empezar a desarrollar nada.

[keys]

Hola.

Yo pienso lo mismo que neftali, esta ley antifraude es referente a la facturación. Si tienes un programa de diseño grafico, pero que además genera facturas (ejemplo tonto) no es lógico que tengas que guardar en un log todos los eventos de tu aplicación.

De todas formas como el dice, habrá que esperar a que saquen más información.

[afxe]

También de acuerdo con Neftali. Frecuentemente los usuarios me preguntan ¿quién ha borrado este descuento? ¿quién ha cambiado el nombre de este producto?... y se nos ocurrió meter un trigger en todas las tablas que registraran en un log las sentencias SQL que se generan desde la sesión de cada usuario.... lo probamos en un cliente que tenía una base de datos de 3 gb, 340 tablas, algunas con más de 100 campos. A la semana tenía 55 gb. cientos de registros diarios de gran peso. Desechamos la idea. Sólo guardamos las inserciones, borrados, y la última vez que se modificó cada registro, así como el último usuario que operó con ese registro.