Traçabilité des actions sur formulaire
Une nouvelle option est disponible pour les formulaires : « Avec traçabilité des modifications ».
Quand cette option est active, toutes les modifications (création, modification, suppression) sur les enregistrements du formulaire sont tracées dans une table à part.
Le changement d'état de cette option (cocher et décocher) sont aussi tracés dans cette table.
Cette option est introduite avec le langage v12.
Un SMX de patch est disponible pour les langages inférieur à 12 (#Patch - Tracabilite Formulaire.smx).
Attention !
Quand elle est active, cette option fait 2 requêtes dans la base de données à chaque création/modification/suppression ; cela signifie que les traitements peuvent être plus lents.
Choisissez avec attention les formulaires sur lesquels vous activez cette option pour ne pas réduire les performances tout en restant conforme à la législation.
L'historique est conservé dans une table dont le nom est dans le format N_LOG_F_XXXXXX.
Le format de la table est identique quel que soit le formulaire :
- IDLOG : un entier consécutif (qui commence à 1)
- DATEHEURE : instant de l'archivage
- IDUTILISATEUR : identifiant de l'utilisateur SIMAX qui a fait la modification
- UTILISATEUR : pseudo de l'utilisateur SIMAX qui a fait la modification
- TYPEACTION : entier qui représente le type d'action effectué sur l'enregistrement ( 2386 => création, 2387 => modification, 2391 => suppression)
- IDENREG : identifiant de l'enregistrement sur lequel à eu lieu l'action
- ENREG : libellé (minidesc) de l'enregistrement sur lequel à eu lieu l'action (tronqué à 254 caractères)
- DETAILS : en création, valeur des colonnes, en modification, valeur old et new des colonnes modifiées (les colonnes recalculées n'apparaissent pas)
- HASHSCORE : clé de hash (SHA-1) qui permet de vérifier l'intégrité de la ligne après génération (ie permet de vérifier si les lignes n'ont pas été modifiées manuellement directement dans la bdd)
Les requêtes SQL à lancer pour vérifier l'intégrité de l'historique sont documentées ailleurs que dans cette nouveauté.
Sauf cas particulier, ne pas transférer ces tables (N_LOG_XXX) dans les backups pour éviter de les faire grossir inutilement (même gestion que les OLD_ et les M_).
Pour plus d'informations :
https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
Cette nouveauté couvre le chapitre : II Condition d'inaltérabilité
Mis à jour

