Développement > Dictionnaire données > Ouverture au paramétrage > Historisation / Epuration
Historisation / Epuration
Cette fonction permet de définir les modalités d'historisation et d'épuration d'une table et éventuellement des tables détail associées, ainsi que toutes les tables qui lui sont liées dans le dictionnaire et dont le code annulation est positionné à suppression. Prenons par exemple, la formule d'historisation SOH de la table des commandes client SORDER, les tables SORDERP, SORDERQ etc sont historisées également.
Ces formules d'historisation sont utilisées lors de la fonction d'historisation / épuration.
C'est un traitement superviseur, qui à partir des formules d'historisation et du paramétrage, va effectuer cette historisation et épuration. Il est cependant possible d'ajouter des particularités dans un traitement dont le nom sera identifié dans la formule d'épuration.
Le détail des modalités d'historisation/épuration des tables de certains modules est donné dans un document annexe.
Remarque importante
Il est important de noter que l'historisation qui est faite ici n'a rien à voir avec un quelconque archivage, notamment fiscal. Il s'agit en effet d'une historisation technique destinée à répondre à des problèmes de performances liés à des volumétries importantes sur les tables actives.
Ainsi, par exemple, l'historisation des écritures ne se fait pas forcément pour un exercice complet, car en cas de lettrage à cheval sur deux exercices, la pièce de l'exercice antérieur n'est pas historisée, même si on a demandé à historiser cet exercice.
Cette historisation ne dédouane donc en RIEN de réaliser l’archivage fiscal à chaque arrêté. Afin de répondre aux exigences de l’administration fiscale, nous préconisons de réaliser, à chaque arrêté, l’édition en pdf des états légaux (Journaux, Grand-Livre, Balances) et d’exporter sous excel (ou autre format neutre) les écritures comptables de la période, ainsi que l’ensemble des paramétrages/données ayant concouru à leur constitution.
Si on utilise par ailleurs le connecteur GED, associé à un logiciel de gestion électronique de document, on peut par ailleurs assurer un stockage sécurisé et intangible des données dès leur extraction.
Gestion de l'écran
Ecran de saisie
Présentation
La saisie des formules d'épuration se fait sur un onglet.
Fermer
Champs
Les champs suivants sont présents dans cet onglet :
Bloc numéro 1
| Ce code identifie la formule d'épuration. Le code épuration AUDITASD (table Audit SData) permet d'épurer les enregistrements de la table d'audit ayant été traités par le traitement de synchronisation utilisé pour l'interface CRM. Les enregistrement épurés sont ceux dont le numéro de séquence est strictement inférieur au numéro de la dernière mise à jour de la table de synchronisation.
|
| Destiné notamment à figurer sur les états et les écrans dans lesquels le code de la fiche peut être saisi ou sélectionné, ce texte permet de donner une description en clair de la fiche concernée. Un intitulé court peut aussi être utilisé à cet usage lorsqu'il n'y a pas assez de place. |
Caractéristiques
| Destiné notamment à figurer sur les états et les écrans dans lesquels le code de la fiche peut être saisi ou sélectionné, ce texte permet de donner une description en clair de la fiche concernée. Un intitulé court peut aussi être utilisé à cet usage lorsqu'il n'y a pas assez de place. |
| Un code activité permet :
Ainsi, si le code activité est non actif, l'élément marqué ne sera pas utilisable, et le code associé (s'il y en a) ne sera pas généré ni activable. |
| Module d'appartenance du paramétrage. Ce champ permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier. |
Traitements
| Cette case à cocher permet d'activer ou de désactiver la fiche courante sans pour autant perdre son contenu. Une fiche désactivée ne peut pas être utilisée (par appel de son code) dans d'autres fiches (documents, paramétrages...), ou lors de traitements de masse. Les habilitations sur une fonction donnée peuvent interdire la création d'une fiche active. Dans ce cas, la case est désactivée par défaut, et est modifiable uniquement par un utilisateur autorisé, ou via un circuit de signature défini par Workflow. |
| Traitements facultatifs pouvant comprendre divers sous-programmes qui seront appelés lors de l'exécution de l'historisation. Voir les caractéristiques de ces sous-programmes. Les développements verticaux devront commencer par X; les développements spécifiques devront commencer par Y ou Z. La mise à jour du traitement spécifique ne nécessite pas de protection par code activité. |
|
|
Tableau Tables
| Tables à historiser et épurer |
| Il est possible de renseigner une table principale ainsi que ces tables de détail. Par conséquent, pour une table détail, on précisera, dans ce champ, la table principale à laquelle elle est associée. Pour une table détail, aucun autre paramètre ne sera saisissable. Une table peut être considérée comme table de détail, si sa clé primaire est constituée par la clé primaire de la table principale + un identifiant. On peut saisir jusqu’à 20 tables détail par table principale |
| Les champs "Société" , "Site" et "Date" permettent d’identifier les champs de la table principale contenant respectivement, la société, le site, la date. Ce sont des critères standards pour filtrer les enregistrements de la table principale à historiser. |
|
|
|
| Ce champ permet de définir des filtres supplémentaires par une formule pour l’historisation des enregistrements. L’épuration, utilise cette formule, lorsque l’historisation n’est pas activée par le paramétrage. |
Fermer
Boutons spécifiques
Remarque importanteIl est important de noter que des traitements standards sont livrés lorsque la condition d'historisation ou d'épuration n'est pas suffisante, et que ces traitements standard ne doivent pas être changés. Leur modification inconsidérée peut provoquer des historisations et épurations mettant en danger la pérennité des données de la base. Il est recommandé, si on désire modifier les règles d'historisation / épuration, de compléter la formule d'historisation en définissant par exemple des critères plus restrictifs et d'écrire si nécessaire l'effacement de données complémentaires créées dans des tables spécifiques dans le traitement spécifique. (voir la méthodologie).
|
Barre de menu
Options / Paramètres épurations
Options / Paramètres épurations
Documentation / Paragraphes
Cette fonction permet d'accéder à la gestion de la documentation, sur le premier paragraphe de la documentation (si elle existe) associé à la fiche courante.
Documentation / Liens
Cette fonction permet d'accéder à la gestion des liens. Elle permet de définir des liens entre la fiche courante et d'autres fiches (par exemple des liens entre fonctions et paramètres). Ces liens, purement documentaires, permettent d'alimenter la mécanique de génération des squelettes de documentation.
Documentation / Génération
Ce menu permet de lancer une génération de documentation. La génération peut se lancer également à partir du bouton [Génération] dans le bas de la fenêtre.
Trois types de génération peuvent être lancées, séparément ou simultanément :
- la génération du squelette de documentation à partir du dictionnaire (tables ADOCUMENT, ADOCBLB, ADOCCLB).
- la génération de la documentation à partir des tables précédentes.
- la génération de la documentation sur champ.
Les bornes proposées par défaut tiennent compte de la fiche en cours, mais elles peuvent être modifiées au lancement.
Messages d'erreur
Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :
Table non définie
La table saisie dans le champ « table lié » doit avoir été saisie en tant que table à traiter dans le champ « table ».
XXXXXX : Trop de liens sur cette table
On tente de saisir plus de 20 tables détail pour une table principale.
XXXXXX : Champ inexistant sur la table YYYYYYY
On a lié la table YYYYYYY à une table principale. Au moins un champ de la clé primaire de la table principale n'est pas trouvé dans cette table détail YYYYYYY.
XXXXXX : Type de données incorrect
On a lié la table YYYYYYY à une table principale. Le champ XXXXX de la clé primaire de la table principale est bien présent dans la table détail mais il est d'un type de donnée différent.
Champ inexistant sur la table XXXXXX
Les champs d'identification de zone (société, site, date) doivent référencer une zone qui existe dans la table principale.
Type de donnée incorrect
Le champ Zone société doit référencer une zone de type CPY ou FCY.
Le champ Zone site doit référencer une zone de type CPY ou FCY.
Le champ Zone date doit référencer une zone de type date.