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
La saisie des formules d'épuration se fait sur un onglet.
Bloc numéro 1
| Code (champ COD) |
|
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.
|
| Intitulé (champ ZDES) |
Caractéristiques
| Intitulé court (champ ZDESSHO) |
| Code activité (champ CODACT) |
|
Un code activité vous permet de :
Si le code activité est désactivé :
|
| Module (champ MODULE) |
|
Sélectionnez un module pour le paramétrage. Ce champ vous 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
| Actif (champ ENAFLG) |
|
Sélectionnez cette case à cocher pour activer la fiche courante. Les enregistrements non sélectionnés conservent leur contenu et paramétrage, mais ne pourront pas être utilisés en rappelant leur code dans :
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. Elle est modifiable uniquement par un utilisateur autorisé, ou via un Workflow de signature. |
| Traitement standard (champ CTLTRT) |
|
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é. |
| Traitement spécifique (champ SPETRT) |
Tableau Tables
| Table (champ TBL) |
|
Tables à historiser et épurer |
| Table liée (champ LNKTBL) |
|
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 |
| Société (champ CPYFLD) |
|
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. |
| Site (champ FCYFLD) |
| Date (champ DATFLD) |
| Formule d'historisation (champ FRM) |
|
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. |
Boutons spécifiques
|
Copie |
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).
|
|
Copie |
Barre de menus
Documentation / ParagraphesCette 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 / LiensCette 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érationCe 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 :
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éfinieLa 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 tableOn tente de saisir plus de 20 tables détail pour une table principale.
XXXXXX : Champ inexistant sur la table YYYYYYYOn 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 incorrectOn 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 XXXXXXLes 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 incorrectLe 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.