Archivage

L'archivage consiste à créer une base SQLite contenant les 3 fichiers DGITCK, DGICLO, DGIARC, nommés respectivement TICKET, CLOTURE, ARCHIVE, plus un fichier de contrôle selftest.

Comme les clôtures, l'archivage se fait toujours par société et magasin, pour une période donnée qui est soit un exercice comptable complet, soit la période faisant suite à la dernière clôture d'exercice.

Pour les 3 fichiers :

• On archive toutes les colonnes des fichiers d'origine, mais ces colonnes ont un nom « en clair », celui-là même qui est utilisé dans l'image JSON de chaque ticket ou clôture permettant de calculer le hashcode correspondant.
• On archive toutes les lignes pour la société et le magasin demandés, et pour la période demandée pour ce qui est des tickets et clôtures.
  En revanche, pour le fichiers des archives, on enregistre toutes les lignes sans limitation de date. On a donc une trace de tous les traitements d'archivage et épurations qui précèdent.

Remarque : dans le fichier des archives qui est placé dans la base SQLite, on n'a pas le hashcode sur le dernier enregistrement, celui correspondant à l'archive en cours de création.
On ne peut en effet connaitre ce hashcode qu'une fois la base SQLite entièrement constituée, et une fois celle-ci constituée, on ne peut plus rien modifier dans son contenu sous peine de fausser ce hashcode.

Si on souhaite contrôler à posteriori que la base n'a pas été altérée, on peut exécuter la commande .selftest qui ne doit signaler aucune erreur (cette commande effectue un contrôle par recalcul de l'empreinte de chaque fichier contenu dans la base et comparaison avec celle enregistrée dans le fichier selftest lors de la création de la base.

Pour plus d'information sur la manipulation de la base SQLite ainsi obtenue, voir la note  SQLite - Utilisation pour archivage, chapitre Mode d'emploi d'une base d'archive SQLite à la fin de la note.