Llamalo mejor "eventos"

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

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

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.

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.

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).

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

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.

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.

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.

Hemos intentado hablar con la AEAT y las personas que nos han atendido coinciden en que es un proyecto y hay que esperar que se haga el reglamento etc.
Voy coincidiendo con vosotros que las logs deben ser de los datos vinculados con facturación , que no son pocos. Ya que el proyecto hace demasiadas referencias genéricas. Por que habla de eventos de los 'sistemas informáticos' que se usen para la facturacion y eso puede ser muchisimo o algo lógico.

Ya lo hemos comentado varias veces: paciencia, paciencia, paciencia, no hay prisa, no vale la pena hacer nada, es todavía un borrador del gobierno, en hacienda no saben todavía nada hasta que esté aprobado, y tal y como van las cosas creo que tardará.

Hola oscarperez-1980, cuenta también conmigo, me parece buena idea.

En cuanto al registro de eventos, coincido con vosotros en que tiene que ser orientado a facturación (creación de la factura en la bb.dd, creación del xml, firma, envío...). Pero es cierto que despista lo de registrar también el login del usuario, que todos lo relacionamos con la conexión al ERP. Así que si lo orientamos al "programa de facturación", el login del usuario puede referirse a la apertura del formulario de facturación, y el logout cuando cierra ese formulario.

Voy con la mayoría, me parece poco creíble considerar que el «sistema informático» siga la integralidad del sistema de información y por tanto lo de registrar «todo».
Sin embargo, no creo que la interpretación arriba siga la correcta, al menos en la idea de quién ha escrito el borrador: pone en el 9.4 (pág. 12), la énfasis es mía:
Si enumera los dos eventos, será que no deben ser la misma cosa; pero sería lo que resulta de interpretar la entrada en el formulario de facturación como log in.
Por tanto creo que tu interpretación es demasiado restrictiva.

Pero era bien intentarlo. ||-||

Por cierto alguno ha visto por ahí en algún foro a Óscar Pérez?
Le he enviado un documento a tipo para ir empezando con el proyecto este de compartir el documento y no veo señales de vida.
En fin espero que sea algo leve.
Los que sigan interesados en participar que me dejen su email y comparto y ya vamos dando forma a un documento

No obligados los que hacen SII
 

Parece que no había leído bien y los programas que tengan los obligados al SII, tiene pinta de que se van a librar de los QR, VERIFACTU, envío inmediato, XMLS, etc.

Re: No obligados los que hacen SII
 

No lo sé; puedo entenderse de dos maneras:

1. cómo lo dices, con los registros del SII en la AEAT no hay que hacer nada más, estos registros cumplen ya la opción «subir los datos a Hacienda»
2. solo dice qué por uno que esté en el SII, la parte del sistema de facturación que se sube en la web y está hospedada por AEAT cumple todos los requisitos del artículo 8; solo le queda todo el resto del sistema de facturación, la parte que está en los servidores de la empresa antes de subir los registros al SII

La verdad es qué con las especificaciones saldremos probablemente de dudas, ya que si hay cualquier cosa encima del SII, por ejemplo en la definición de registro, no creo que se pudiera sostener la opción 1. ¡Paciencia!

Efectivamente, hasta que no esté redactado y re-re-recorregido no saldremos de dudas, pero es lo que dices, parece que solo se refiere a una parte, o quizás no..
A mi me parecería extraño que el SII estuviera por encima, ya que al final el nuevo reglamento es una presentación más detallada y permite que posteriormente se haga automáticamente algunas de las declaraciones.

Evento ley Antifraude
 

Por si a alguien le interesa para saber algo más sobre este tema. Sage ha sacado un Webinar de una hora para el día 05/04/2022.

https://www.sage-conference.com/even...c6Mzg5ODIwNjM=

Saludos

Gracias por el aviso. Estos de Sage siempre con un marketing muy agresivo y algo estupidos (lo digo por el punto 3 del temario: "Ticket Babi" :eek:)

Gracias tejano, lo veremos a ver si saben más que nosotros del tema...

Una pregunta, sabéis si en el proyecto de las 19 páginas hacen referencia a que el software va a tener que estar certificado Con un certificado de software? Por no rellerlo de nuevo
Gracias