Traçabilité des modifications dans la base de données Oracle E-Business Suite.

La traçabilité des modifications dans certaines tables répond à des objectifs de sécurité et de reproductibilité.

Sécurité : Il est indispensable de pouvoir tracer les modifications réalisées sur certaines tables pour éviter la fraude. La donnée originale doit être sauvegardée dans son état avant modification. Ainsi, il est possible de tracer l’ensemble des modifications d’un enregistrement et d’identifier les différentes personnes qui les ont réalisées. C’est typiquement le cas des tables contenant les informations des comptes bancaires ou les tables contenant les données d’habilitation.

Reproductibilité. Le « Principe de la permanence du chemin de révision », développé dans l’article 911-3 du plan comptable général et repris par l’administration fiscale dans le cadre des contrôles des comptabilités informatisées, impose aux entreprises de pouvoir rejouer les traitements informatiques qui ont conduit à la génération d’une écriture comptable. Pour faire cela, il est indispensable de connaitre l’ensemble des valeurs des paramètres existants à la date du traitement. Il est donc nécessaire d’historiser les données des tables contenant des valeurs utilisées comme paramètre par les traitements. C’est typiquement le cas des valeurs des options de profil, des devises, des taux de change, des paramètres spécifiques, des tables de trans-codification, des jeux de valeurs, …

Avec une base de données Oracle, l’exercice est relativement simple.

D’un point de vue fonctionnel, il suffit de mettre sur chaque objet à monitorer un « mouchard » qui va identifier tous les actes de modification ou de suppression de données et sauvegarder la donnée d’origine avant sa modification ou sa suppression. Il ne faut pas plus de quelques heures de travail pour déployer ce mouchard sur l’ensemble des tables identifiés.

D’un point de vue technique, il faut :

1. Créer une table d’historisation contenant les mêmes champs que la table d’origine et cinq champs supplémentaires (HISTORISATION_MODE (U/D), HISTORISATION_DATE, HISTORISED_BY, HISTORISED_LOGIN, HISTORISED_CONTEXT)
2. Positionner sur la table d’origine un trigger (AFTER UPDATE OR DELETE) qui va écrire dans la table d’historisation. Les cinq champs supplémentaires sont alimentés avec les valeurs suivantes  (exemple pour Oracle E-Business Suite) :
   1. ‘U’ for Update, ‘D’ for Delete.
   2. sysdate
   3. nvl(fnd_profile. value (‘USER_ID’), -1)
   4. nvl(fnd_profile.value(‘LOGIN_ID’), -1)
   5. nvl(SYS_CONTEXT(‘USERENV’,’SESSION_USER’)||’ – ‘||SYS_CONTEXT(‘USERENV’,’HOST’)||’ – ‘||SYS_CONTEXT(‘USERENV’,’IP_ADDRESS’)||’ – ‘||SYS_CONTEXT (‘USERENV’,’OS_USER’), ‘UNKNOWN’)

La mise en place de ce « mouchard » a un impact imperceptible (pour ne pas dire aucun) sur les performances du système.

Une fois l’historisation mise en place, il est possible de tracer tous les changements et toutes les suppressions. Il devient alors possible d’exécuter un traitement avec des anciennes données et d’avoir la certitude que le résultat produit sera « Permanent ».

Dans les entreprises de grande taille, avec des supports souvent délocalisés, ce mouchard permet également d’identifier qui est à l’origine de chacune des modifications.

La société ATTRIBUTE se propose de déployer cette fonctionnalité dans votre entreprise en une seule journée.