Draft:Questions certification LNE pour le certificateur (Loi Finance): Difference between revisions

* Périmètre: Nous avons défini le périmètre sur la base d'une liste de fichiers qui ne devront pas être modifié pour rester dans le périmètre de la même version majeure. Notre architecture qui permet d'isoler les fichiers concernés par l'encaissement et le traçage en log inaltérable sera présenté en séance visio. Les questions la dessus viendront peut être lors de la séance.

* Nos documents (utilisateurs, développeur, etc) sont déjà publique et partagé par l'écosystème (principe de coopétition), mais quid des nouveaux document propres à la certification, peut on les rendre publiques, sous quelles conditions ?

* Puisque tout le monde n'a pas besoin de l'inaltérabilité (seul 5 à 20% de nos utilisateurs sont concernés), on envisage de rendre le module de conformité "non" actif par défaut, mais activable par l'intégrateur ou l'utilisateur lui même. La certification ne serait donc valide que "sous réserve d'activation du module de conformité". Est-ce envisageable d'intégrer ce genre de réserve dans la certification ou faut-il faire une version spéciale dans laquelle le module de conformité sera actif quoi qu'il arrive, sans nécessiter de paramétrage initial de l'application ?

* Quel est le planning possible du déroulement de certification (date communication des doc finalisés, date évaluation, ...) sachant que de notre côté on espère le code prêt pour fin novembre ?

* Comment se déroule la certification (lieu ? visio ? étapes ? avec qui ?). Comment sont gérer les retours car j'imagine qu'il y a toujours des points identifiés ou réserves à lever ?

* Notre système de log inaltérable couvre d'autre événement en plus de l'enregistrement des paiements, comme par exemple l'enregistrements de factures, même si aucune paiement n'a encore été reçu, car d'autre pays ont ce besoin. Dans la mesure où l'outil de consultation permet de filtrer par type d’événement pour ne voir que les événements soumis à besoin d'inaltérabilité de la France, pouvez vous confirmer que l'on peut rester ainsi (Sinon, parcourir ensemble la liste des types d’événements qu'il faudrait garder juste pour la France).

* Sur Dolibarr toute saisie de paiement est concomitant à l'émission de facture PDF qui fait office de ticket, dans le cas de l'envoi par email ou de l'impression de cette facture (qui mentionne les paiement reçus), on stock dans la log inaltérable les donnée qui composent ce PDF mais pas le fichier PDF même. Est-ce ok ?

* Questions sur la purge. Les points réglementaires sur la purge sont flous car mélange archivages et purge et ne semblent pas adaptés au cas ou on ne purge jamais les logs inaltérables. Cela veut il dire qu'il faut obligatoirement avoir une fonction de purge ou peut on les considérer comme non applicable ?

* Questions sur l'impression de duplicata. Dolibarr ne permet pas l'impression de duplicata car fonctionne par génération de factures obligatoires. C'est toujours une facture entière ou un ticket facture simplifié qu'on imprime. Il n'y a pas de notion de "duplicata" sur des factures en compta française. C'est un PDF qui peut être imprimé n fois (pour la compta, pour le juriste, pour les impots, ...). Comment concilier les exigences sur les points "duplicata" de ticket de caisse. Cette notion a-t-elle un sens pour un logiciel qui enregistre une facture systématiquement de manière concomitente avec le paiement ?

* Un utilisateur enregistre un paiement de 10 euros en début de mois. A la fin du mois, en faisant son rapprochement bancaire, il se rend compte qu'il a fait une erreur de saisie et qu'il y a 11 euros sur le compte. Le logiciel Dolibarr procède ainsi. Suppression logique des 10 euros puis saisi des 11 euros. Ce qui nous donne dans la Log inaltérable 3 entrées: La saisie intiale de +10 euros à la date de début de mois (qui n'est pas effaçable physiquement), une ligne en fin de mois pour la saisie de -10 euros qui annuelle celle de début de mois suivi d'une autre de +11 euros. Est-ce ok ?