https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf

Éléments de réponse: Un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-TVA DECLA-30-20-10. Autrement dit, un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les opérations effectuées avec ses clients non assujettis.

Ainsi, les logiciels ou systèmes de caisse dans lesquels sont enregistrées les opérations effectuées avec des clients assujettis à la TVA (clients professionnels) ne relèvent pas du champ d’application du dispositif.

En revanche, ceux dans lesquels sont enregistrées les opérations effectuées avec des clients qui ne sont pas assujettis à la TVA (clients particuliers) relèvent du champ d’application du dispositif.

De la même façon, ceux dans lesquels sont enregistrées à la fois les opérations effectuées avec des clients assujettis à la TVA (clients professionnels) et des non assujettis (clients particuliers) relèvent du champ d’application du dispositif.

Il convient de ne pas tenir compte de la qualification du logiciel (de caisse, comptable ou de gestion) en question, mais de retenir sa fonctionnalité de caisse. Ainsi, un logiciel de gestion qui permet l’enregistrement des opérations de ventes ou de prestations de services qui concernent les non assujettis à la TVA (clients particuliers) doit être considéré comme un logiciel ou un système de caisse visé par le dispositif.

Éléments de réponse:

Depuis le 15 juin 2017, seuls les logiciels et systèmes de caisse sont concernés par la mesure, principaux vecteurs des fraudes constatées à la TVA.

Concernant les logiciels multi fonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées.

Éléments de réponse: La loi instaure une obligation de résultat concernant la conformité des logiciels (respect des quatre conditions de la loi : inaltérabilité, sécurisation, conservation, archivage) et non de moyen: elle ne définit pas de cahier des charges, ni de solution technique, contrairement à d’autres dispositifs fiscaux.

L’élaboration de référentiels est donc du ressort des seuls acteurs privés.

Éléments de réponse:

L’administration fiscale n’impose aucune solution technique (empreinte électronique, chaînage des opérations...), dès lors qu’aucune norme fiscale a été prévue par le législateur.

Concernant les systèmes de caisse, la garantie d’inaltérabilité peut être obtenue par plusieurs techniques permettant d’une part d’empêcher l’accès de l’utilisateur à des fonctionnalités de modification des données validées et d’autre part de détecter tout accès/modification des données de règlement. Toute modification ou correction doit être détectable.

Le certificat est associé à la capacité de pouvoir démontrer que les données de règlement n’ont pas été modifiées depuis leur enregistrement initial et doit fournir un système de preuve en ce sens.

Éléments de réponse:

Le logiciel de caisse doit enregistrer toutes les données d’origine relatives à la transaction de règlements (notes et tickets de caisse).

Les données initialement validées devant rester inaltérables, si des corrections sont ultérieurement apportées à des opérations de règlements, ces corrections (modifications ou annulations) s’effectuent par l’enregistrement de nouvelles opérations de «plus» et de «moins» et non par modification directe des données d’origine enregistrées.

Ces opérations de correction donnent également lieu à enregistrement et leur inaltérabilité doit également être garantie.

Techniquement, la solution doit garantir l’inaltérabilité de toutes les données élémentaires (enregistrement initial et correction(s)) et fournir une fonctionnalité de suivi des modifications.

Éléments de réponse:

Pour les systèmes de caisse, la condition d’inaltérabilité des enregistrements de règlement (quantité, montant, TVA, mode de règlement...) s’obtient par plusieurs moyens techniques garantissant:

• Une inaltérabilité logique de haut niveau, en privant l’utilisateur de toute fonctionnalité du logiciel lui permettant de modifier les données élémentaires de règlement. Ce moyen s’assortit d’une solution technique permettant de détecter et démontrer que l’utilisateur n’a pas contourné cette impossibilité fonctionnelle intégrée au logiciel de l’éditeur.

• Une inaltérabilité de bas niveau qui garantit l’intégrité des données enregistrées sur le disque sous forme de fichier ou de base de données. L’accès à une donnée élémentaire par un homme de l’art ne pouvant jamais être empêché, cette inaltérabilité est garantie par la preuve que la donnée élémentaire n’a pas été modifiée depuis son enregistrement (empreinte numérique à clé privée, chaînage...).

Éléments de réponse:

Les données de l’opération doivent être inaltérables de la prise de commande jusqu’à l’enregistrement du règlement.

Cette inaltérabilité est garantie par:

• L’absence de fonctionnalité logicielle permettant une modification/suppression de la transaction et la preuve que ce système n’a pas été contourné.

• Une preuve numérique permettant de détecter si la donnée élémentaire a été modifiée depuis son enregistrement.

Éléments de réponse:

La condition de sécurisation des données a fait l’objet de précisions dans la doctrine administrative à laquelle il convient de se reporter : BOI-TVA-DECLA-30-10-30 § 130 à 150. La condition de sécurisation ne vise pas à limiter les droits d’accès au logiciel ou système de caisse mais à assurer que les enregistrements des encaissements réalisés par toute personne qui accède au logiciel ou système soient tracés, de même que les éventuelles modifications apportées à ces enregistrements initiaux.

En cas d’emploi d’une fonction «école» ou «test», le § 150 de la doctrine administrative précitée prévoit par ailleurs l’identification de l’opérateur sous la responsabilité duquel le personnel en formation enregistre les données.

La sécurisation des données vise à s’assurer que les données enregistrées ne peuvent plus être modifiables, sans traces. Il ne s’agit pas seulement de protéger les données contre les modifications par des tiers, ce qui constitue un délit en application des articles 323-1 à 323-3 du code pénal, mais aussi contre des modifications non tracées effectuées par le propriétaire et détenteur des données lui-même.

Éléments de réponse: Il convient de distinguer la condition de conservation des données de la condition d’archivage des données.

La conservation des données détaillées de transaction doivent être conservées «en ligne» dans le système de caisse. Ces données peuvent faire l’objet de purge, ce qui consiste à les sortir du système de caisse et à les stocker dans un support externe d’archivage (clé USB, disque optique ou disque dur externe).

L’ensemble des données doivent être conservées (dans le système de caisse) et archivées (sur support externe et leur inaltérabilité et leur traçabilité doivent être garanties pendant six ans. Elles doivent être archivées au moins une fois à la fin de chaque exercice comptable au moyen d’un processus obligatoirement prévu par le logiciel. Elles sont toujours archivées avant un processus de
purge.

Comme précisé par le BOI-TVA-DECLA-30-10-30 (§ 160 et suivants), pour chaque clôture (selon le cas journalière, mensuelle et/ou annuelle ou par exercice), toutes les données doivent être conservées: «cette obligation de conservation porte sur toutes les données enregistrées ligne par ligne, ainsi que pour les systèmes de caisse, sur les données cumulatives et récapitulatives calculées par le système» (cumul du grand total de la période et total perpétuel).

La condition d’archivage a, quant à elle, pour «objet de figer les données et de donner date certaine aux documents archivés». Pour plus de précisions, se reporter au BOI-TVA-DECLA-30-10-30-20160803 § 220 et suivants.

S’agissant du cas de changement de matériel ou de logiciel, il est rappelé que le délai général de conservation de six ans, mentionné au premier alinéa de l’article L. 102B du livre des procédures fiscales, s’applique aux livres, registres, documents ou pièces auxquels l’administration a accès pour procéder au contrôle des déclarations et des comptabilités des contribuables astreints à tenir et à
présenter des documents comptables.

Éléments de réponse:

Toutes les données élémentaires doivent être conservées par le logiciel ou le système de caisse et non pas seulement le Z. Un assujetti qui ne conserve que les Z ne respecte pas les obligations de conservation prévues à l’article L. 102-B du livre des procédures fiscales. Cette définition répond à la nécessité légale de justifier les résultats produits par un système informatisé avec les données élémentaires ayant servi à leur élaboration, prises en compte dès leur origine, et non par des données agrégées résultant de traitements automatisés. Les données de détail d’une transaction de règlement comprennent le numéro du ticket, la date (heure-minute-seconde), le numéro de la caisse, le total TTC, les totaux HT par taux de TVA, le détail des articles ou prestations (libellé, quantité, prix unitaire, total HT de la ligne, taux de TVA associé) et les traces de modifications et corrections apportées.

Ainsi, avant la purge des données élémentaires conservées dans le système de caisse, l’ensemble des données précitées et enregistrées depuis la dernière opération d’archivage doivent être conservées. Après la purge, opération d’archivage qui a pour objet de transférer les données conservées vers un support externe, seuls les totaux de contrôles produits par les procédures de clôtures (soit les grands totaux journaliers, mensuels, annuels et de l’exercice et le total perpétuel) doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. Les données de traçabilité de la procédure de purge/archivage doivent être conservées.

Éléments de réponse:

L’inaltérabilité des données permet de garantir que les enregistrements de règlement ne sont plus modifiés ou n’ont pas été modifiés après leur validation.

Les garanties de conservation et d’archivage permettent de garantir que ces données inaltérables restent durablement accessibles dans le cadre d’un contrôle pendant le délai légal de contrôle.

Pour les logiciels de caisse, on distingue la conservation des données « en ligne » dans le système de caisse, de l’archivage des données sur un support externe.

Les données conservées (en ligne dans le logiciel de caisse) doivent faire l’objet de clôtures journalières, mensuelles et annuelles (ou par exercice). Les données sont archivées au moins une fois à la fin de chaque exercice comptable au moyen d’un processus obligatoirement prévu par le logiciel. Elles sont toujours archivées avant un processus de purge. Les données de détail de règlement sont enregistrées sur un support externe et effacées de la sauvegarde « en ligne » présente dans le logiciel de caisse. En revanche, les totaux de contrôles produits par les procédures de clôtures doivent être conservés dans le logiciel de caisse et continuer d’être protégés par la garantie d’inaltérabilité. La solution logicielle doit permettre de maintenir la traçabilité des procédures d’archivage et de garantir l’inaltérabilité des données archivées.

Éléments de réponse: Il est possible de citer comme support physique externe: une clé USB, un disque optique ou un disque dur externe. Ce support physique externe doit être sécurisé. Aucune solution technique n’est imposée pour assurer cette sécurisation.

Le support physique externe sécurisé n’est exigé qu’en présence de purges, tel que l’indique le § 250 du BOI-TVA-DECLA-30-10-30: Au-delà de la périodicité choisie et au maximum annuelle ou par exercice, le logiciel ou le système peut prévoir une procédure de purge des données de règlement.

Avant la mise en œuvre de cette procédure de purge, le logiciel ou le système doit garantir la production d’une archive complète des données de règlement (données d’origine et éventuelles modifications), avec la date de l’opération de règlement (année – mois – jour), sur un support physique externe sécurisé.

La décision de purger les données est liée à la nécessité de libérer de l’espace sur le disque dur.

L’archivage des données est donc dans ce cas logiquement réalisé en dehors du système de caisse. La sécurisation du support d’archivage doit permettre de garantir l’intégrité des données archivées et leur disponibilité en cas de contrôle.

La disponibilité des données doit être effective en cas de contrôle. Les éditeurs doivent prévoir des procédures d’archivage obligatoires pour les utilisateurs. Pour plus de sécurité plusieurs supports de stockage différents pour une même archive peuvent être proposés comme le prévoit la norme Z 42 013. Les utilisateurs ont en effet l’obligation de conserver les données archivées pendant six ans.

L’obligation d’archivage prévue par le certificat ne doit pas être confondue avec une solution de sauvegarde des données présentes dans le système de caisse. Ces sauvegardes sont entendues comme une copie des données toujours présentes sur la caisse. Les sauvegardes permettent la reprise technique des données en cas de panne de la caisse et constituent une solution, parmi d’autres, de sécurisation des données justificatives de règlement.

Éléments de réponse:

Le § 170 du BOI-TVA-DECLA-30-10-30 précise que: «Pour chaque clôture -journalière, mensuelle et annuelle (ou par exercice)- des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse».

On entend par «cumul du grand total de la période» le cumul de chiffre d’affaires décompté depuis l’ouverture de la période comptable en cours.

On entend par «total perpétuel» le cumul de chiffre d’affaires décompté depuis le début de l’utilisation du système.

Le Total perpétuel est en effet un compteur qui cumule le chiffre d’affaires total enregistré depuis le début de l’utilisation du système et ne se remettant jamais à zéro. Il n’est pas lié à une période contrairement au Grand Total qui lui est le compteur qui cumule le chiffre d’affaires total pour la période comptable.

En cas de changement de matériel ou de logiciel, tous les compteurs repartent de zéro. Les compteurs de l’ancien matériel ou logiciel doivent être archivés et sécurisés.

Dans le cas d’un simple changement de version d’un logiciel tous les compteurs doivent continuer à être incrémentés sans être remis à zéro.

Éléments de réponse:

Des précisions ont été apportées sur ce point aux § n° 160 et suivants du BOI-TVA-DECLA-30-10-30.

Pour les systèmes de caisse, l’obligation de clôture est: journalière, mensuelle et annuelle (ou par exercice).

La doctrine administrative précise par ailleurs que: «Pour chaque clôture -journalière, mensuelle et annuelle (ou par exercice)- des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse».

Parmi ces données figurent le grand total pour la période comptable, le total période et le total perpétuel.

Toutes les données enregistrées doivent être conservées. «Cette obligation de conservation porte sur toutes les données enregistrées ligne par ligne, ainsi que pour les systèmes de caisse, sur les données cumulatives et récapitulatives calculées par le système».

La clôture mensuelle permet aussi la totalisation du chiffre d’affaires ventilé par taux de TVA.

Éléments de réponse: La doctrine administrative prévoit que la clôture doit intervenir à l’issue d’une période au minimum annuelle (ou par exercice si celui-ci n’est pas calé sur l’année civile). Pour les systèmes de caisse, il faut en plus une clôture journalière et mensuelle. Ensuite, le § 220 du BOI-TVA-DECLA-30-10-30 prévoit la possibilité d’archiver les données selon une périodicité choisie qui est au maximum annuelle
ou par exercice.

S’agissant de la condition de conservation des données, il est précisé pour les systèmes de caisse, aux §160 et 170 de la doctrine précitée, que ces systèmes doivent prévoir obligatoirement une clôture journalière, une clôture mensuelle et une clôture annuelle (ou par exercice lorsque l’exercice n’est pas calé sur l’année civile). Pour les systèmes de caisse, ces trois échéances de clôtures sont cumulatives et impératives.

S’agissant du respect de la condition d’archivage, il est prévu que les systèmes de caisse comme les logiciels de comptabilité ou de gestion doivent permettre d’archiver les données enregistrées selon une périodicité au maximum annuelle ou par exercice. Cette périodicité est donc la même que la périodicité annuelle ou par exercice prévue pour le respect de la condition de conservation.

Éléments de réponse: On entend par « éditeur » du logiciel ou du système de caisse la personne qui détient le code source du logiciel ou système et qui a la maîtrise de la modification des paramètres de ce produit.

Une attestation délivrée par un éditeur engage sa responsabilité sous réserve que les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage ne sont pas modifiés.

Logiciel standard d’un éditeur fourni sous forme d’un exécutable et de ses bibliothèques logicielles non modifiables et dont un éventuel paramétrage ne concerne pas les fonctions assurant la sécurisation, l’inaltérabilité, la conservation et l’archivage. L’éditeur de ce logiciel est soumis à une obligation de sécurisation justifiée par un certificat délivré par un organisme accrédité ou une attestation établie par l’éditeur lui-même.

Éléments de réponse:

Les archives doivent pouvoir être lues aisément par l’administration. Aucun format d’archive n’est toutefois imposé. De la même manière, en cas de cryptage de l’archive, aucun format de cryptage n’est imposé. Les archives seront dans ce cas considérées comme pouvant être aisément lues par l’administration (les données numériques par exemple apparaissant en clair et non sous forme codée), dès lors qu’en cas de contrôle, l’assujetti à la TVA concerné présentera à l’administration des archives décryptées.

A titre d’exemple, les formats de fichiers de type TXT ou CSV peuvent être utilisés pour l’archivage (cf. BOI-BIC-DECLA-30-10-20-40 § 550).

Éléments de réponse:

L’attestation doit être individuelle, c’est-à-dire délivrée nominativement à l’assujetti à la TVA qui la produit.

L’attestation doit être établie par l’éditeur du logiciel ou du système de caisse ou par son représentant légal lorsqu’il s’agit d’une société.

Elle doit explicitement mentionner que le logiciel ou le système de caisse respecte les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Elle doit indiquer précisément:

1. le nom et les références de ce logiciel (y compris la version du logiciel concernée et le numéro de licence quand il existe une licence) ou de ce système;
2. la date d’acquisition du logiciel ou système par l’assujetti à la TVA.

L’attestation peut être délivrée sur un support physique ou de manière dématérialisée (par exemple, par téléchargement en ligne d’une attestation à compléter par l’assujetti pour y mentionner notamment son identité complète). Pour plus de précision, il convient de se reporter à la doctrine administrative.

L’attestation doit être conforme au modèle fourni en BOI-LETTRE-000242.

Éléments de réponse:

La loi n’impose pas aux éditeurs cette délivrance spontanée.

Si l’éditeur n’adresse pas d’attestation à l’utilisateur, il appartient à ce dernier de la lui réclamer.

Des consignes seront données aux agents de l’administration fiscale pour prendre en compte les circonstances particulières si l’assujetti apporte la preuve des diligences qu’il a faites pour obtenir cette attestation.

Éléments de réponse:

Le renouvellement de l’attestation est fondé sur les notions d’évolutions mineures ou majeures du logiciel, et non sur une durée calendaire. Dans les faits, l’attestation n’a pas à être renouvelée annuellement, mais elle le sera en fonction des changements mineurs ou majeurs apportées au logiciel.

Il est admis que l’attestation demeure valable pour attester du respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données par les versions mineures ultérieures du logiciel ou système (cf. I-C-1 § 340 du BOI-TVA-DECLA-30-10-30 pour la définition d’une version majeure et d’une version mineure) :

Dans le cas où les fonctionnalités techniques du certificat ne sont pas modifiées par une nouvelle version du logiciel, on parlera d’une version mineure ne faisant pas naître une nouvelle obligation de certification.

Dans le cas où la modification du logiciel est telle que les fonctionnalités techniques assurant la sécurisation, l’inaltérabilité, la sauvegarde et l’archivage des données sont altérées, on parlera d’une version majeure qui doit faire l’objet d’une nouvelle certification.
Toute nouvelle version majeure du logiciel ou système doit donner lieu à l’établissement d’une nouvelle attestation visant expressément cette version

Suite au communiqué de presse du cabinet du ministère du 15 juin 2017 (http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf), seuls les logiciels de caisse seraient à présent concernés.

Etant donné que BeDesk fait partie des logiciels de gestion et non de caisse, l’obligation de mise en conformité dont il est question dans ce ticket ne serait donc plus avérée.

Cependant, tant que la loi n’est pas effectivement révisée, nous continuerons de mettre en application les points ci-dessous à toutes fins utiles.

Un gros travail a déjà été effectué et, considérant que cela améliore également d’une certaine manière la qualité du logiciel, nous le finirons.

https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf?hash=1505292811

Qu’est-ce qu’un logiciel ou système de caisse ?

Un logiciel ou un système de caisse est un système informatisé dans lequel un assujetti enregistre les livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-TVA DECLA-30-20-10.

Ceci exclut de-facto le logiciel BeDesk car il s’agit d’un logiciel de facturation et non de caisse.

Tous les logiciels de gestion commerciale incluant une fonctionnalité de caisse enregistreuse/d’encaissement sont-ils toujours à certifier par leurs éditeurs pour le 1er janvier 2018 ?

Depuis le 15 juin 2017, seuls les logiciels et systèmes de caisse sont concernés par la mesure, principaux vecteurs des fraudes constatées à la TVA.
Concernant les logiciels multi fonctions (comptabilité/gestion/caisse), seules les fonctions caisse enregistreuse/encaissement, et non l’ensemble du logiciel, devront être certifiées.

La note “fonctions caisse enregistreuse/encaissement” est quelque peu ambigüe.

En effet, le suivi de l’apurement des factures pourrait-il être considéré comme une “fonction d’encaissement” ?

• BeDesk-Express n’est pas un logiciel de caisse :
  • On ne réalise pas de ticket de caisse avec BeDesk-Express.
  • BeDesk-Express ne peut pas être connecté à un dispositif de caisse, à un terminal de paiement ou à un quelconque autre système de paiement, pour le piloter ou en extraire les informations.
    • Si l’activité de l’utilisateur nécessite l’usage d’un tel dispositif, celui-ci doit en acquérir un indépendamment de BeDesk-Express.
      • Un avertissement clair doit être placé bien en vue à ce sujet dans le contrat de licence.
        

• BeDesk-Express n’est pas un logiciel de comptabilité :
  • On ne réalise pas la comptabilité de l’entreprise avec BeDesk-Express.
    • Un avertissement clair doit être placé bien en vue à ce sujet dans le contrat de licence.
      
  • BeDesk peut cependant fournir une partie des informations sources (de pré-comptabilité) qui permettent de réaliser la comptabilité proprement dite, par un expert-comptable ou éventuellement à l’aide d’un logiciel tiers conçu à cet effet par un autre éditeur.
    

• BeDesk-Express ne gère ni les moyens de paiements ni l’apurement des comptes :
  • L’apurement des comptes est du ressort de la comptabilité et/ou du logiciel de comptabilité. Ce que BeDesk-Express n’est pas et ne fait pas.
  • La gestion des moyens de paiements peut être réalisée via un système de caisse, un logiciel de comptabilité ou un système de liaison bancaire. BeDesk-Express ne dispose pas d’un système de liaison bancaire permettant par exemple de faire le rapprochement entre une opération bancaire et un encaissement.
    • Il est toutefois possible d’indiquer dans BeDesk-Express des montants d’acomptes reçus à titre “indicatif” dans l’unique but d’assurer un suivi plus facile et de relancer éventuellement les mauvais payeurs. Cette fonctionnalité n’est pas conçue pour remplacer la gestion comptable des apurements ni un système de caisse certifié.
      • Un avertissement clair doit être placé bien en vue à ce sujet, y compris dans le contrat de licence.
        

• BeDesk-Express permet de créer et de gérer des factures (de vente et d’avoir) :
  • Celles-ci doivent être (et sont déjà) conservées indéfiniment dans la base de données.
    • Une clôture est cependant nécessaire pour figer définitivement et irrévocablement les documents (c-à-d, «archiver») à la fin de l’exercice ou à une durée maximum d’un an.
  • On ne peut supprimer aucun document dans BeDesk-Express (ceci n’a jamais été possible via l’interface du logiciel).
    • Cependant, la loi stipule que les fichiers (et donc leur contenu) doivent être inaltérables. Il faut donc mettre ne place un ou plusieurs dispositifs techniques qui détectent et signalent toute modification des fichiers en dehors du logiciel BeDesk-Express lui-même.
  • Toutes les opérations réalisées avec le logiciel doivent être tracées :
    • La notion de traçabilité est très importante car elle permet de fournir un justificatif des opérations réalisées.
      • Dans le cas de BeDesk-Express, elles comprennent l’ensemble des données qui concourent à la réalisation d’une vente et d’un encaissement:
        • Il faut donc établir un historique chronologique inaltérable, sécurisé et par ajouts uniquement des évènements suivants:
          1. Création d’un document avec l’enregistrement d’un horodatage, des états (payé, imprimé, etc..) et des montants totaux HT, TTC et acomptes reçus.
          2. Modification d’un document avec l’enregistrement d’un horodatage et autres informations de traçage ci-dessus.
          3. Impression du document (idem).
          4. Envoi du document par e-mail (idem).
          5. Impression d’une lettre de relance (idem).
          6. Clôture du document (idem).
        • De plus, l’enregistrement à titre “indicatif” des
        • Certains évènements pouvant nécessiter une explication ou un justificatif, l’utilisateur devrait pouvoir commenter les évènements sans toutefois pouvoir en modifier la nature, le contenu et l’ordre chronologique. Bien entendu, aucune suppression ne devrait en outre être possible (seulement ajouter de nouveaux évènements supplémentaires à la fin de l’historique).
        • Bien que l’enregistrement des paiements reçus dans BeDesk-Express soit exclusivement «indicatif» de manière à assurer le suivi plus facile des documents en souffrance et de relancer éventuellement les clients, il convient de modifier la méthode de saisie des acomptes. Il devient nécessaire de remplacer le tableau des versions précédentes par un journal chronologique où on ne peut qu’ajouter de nouvelles entrées par «PLUS» et «MOINS». L’enregistrement des évènements de ce journal doit respecter les mêmes règles d’inaltérabilité, de sécurité, de conservation et d’archivage que les points précédents.

Nous constatons que malheureusement certains utilisateurs font un mauvais usage du système de sauvegarde/restauration.

Un des cas de figure de mauvaise utilisation consiste par exemple à essayer de créer une nouvelle base de données “indépendante” en utilisant le système de sauvegarde/restauration local.

Or, on ne peut pas obtenir une nouvelle base de données “indépendante” avec le système de sauvegarde/restauration.

La signature de la base de données d’origine est conservée à l’identique. De cette manière, quelque soit le poste sur lequel la base de données est restaurée, on peut s’assurer d’utiliser toujours la version la plus récente et comportant l’intégralité des données.

Si on essaye de restaurer une version antérieure de la base de données, celle-ci ne pourra pas être activée et on ne pourra pas ajouter des données à la suite d’une chronologie tronquée ou ramenée à un état antérieur 1).

—

Pour créer une nouvelle base de données indépendante, il faut cliquer sur le bouton “créer une nouvelle base de données” et non sur “sauvegarder” puis “restaurer”. Cette dernière procédure restitue la base de données d’origine et ne crée pas une nouvelle base de données distincte.

—

En outre, lors de la restauration d’un fichier de sauvegarde, le nom de la base de données est également conservé. Si on effectue la sauvegarde de sécurité de la base de données appelée “Tests”, le nom de la base de données est également enregistré dans le fichier de sauvegarde. Ainsi, lorsqu’on restitue ce fichier, quelque soit le nom qu’on lui aurait donné, ce sera toujours la base de données “Tests” qui sera restaurée.

Cela pose donc un autre problème, si l’utilisateur a essayé de créer une nouvelle base de données “indépendante” par sauvegarde/restauration. En effet, si on restaure par erreur une sauvegarde secondaire sur le poste d’origine, il y aura conflit non seulement d’identité mais de nom également.

—

Pour résoudre ces multiples problèmes, il faut modifier l’implémentation de sécurisation des bases de données en s’assurant qu’une identité correspondent bien au nom de la base de données. Les 2 éléments constituant en soit une clé composée.

Tout changement de nom de la base de données devrait donc dès lors altérer l’identité de la base de données. Cela aura notamment pour conséquence une invalidation immédiate de la licence. Mais, dans le même temps, cela interdira :

1. l’utilisation de copies invalides ou conflictuelles d’une base de données originale,
2. et la réutilisation des codes d’activation sur plus d’une seule et unique identité.

Il faut aussi permettre au support technique de créer des nouvelles identités pour éviter la perte des données des utilisateurs qui auraient utiliser le système de sauvegarde/restauration dans l’espoir de créer une nouvelle base de données “indépendante” par inadvertance.

Nous constatons également que quelques utilisateurs ont créés plusieurs comptes à partir desquels ils ont acquis plusieurs licences. Ce n’est pas un problème en soit. Cependant, ils utilisent aussi ces codes émanant de plusieurs comptes distincts pour activer une même base de données.

Parfois même les coordonnées associées à ces comptes distincts ne sont pas les mêmes (changement de statuts).

Le service des licences doit être attentifs à cet aspect et organiser le regroupement des codes d’activation sur un seul et même compte pour une même base de données.