Dolibarr ERP CRM Wiki

Historique des modifications Dolibarr pour la compatibilité avec la loi finance

(Redirected from Loi article 88 finances 2016 et Certification NF525 - Travaux Dolibarr)

Pour un article sur la loi finance 2016, ce que c'est, les obligations pour les logiciels, c'est ici Loi_finances_2016_sur_les_logiciels_de_caisse_et_Certification_NF525_ou_LNE


Cette page trace l'historique des modification faites pour suivre les modification de Dolibarr afin d'etre conforme à la loi finance. Les premières modifications ont été réalisées avec le v6 sortie en septembre 2017. Un lot complémentaire d'évolutions est disponible avec la v7 (sortie début février 2017). Les dernières modifications ont été faite en v9.

Fonction de signature d'une version avec sa configuration

  • Améliorer l'outil de fabrication de signature d'une version de Dolibarr pour permettre l'ajout de la configuration ou une partie de configuration dans la signature.

-> Fait en v6

  • Ajout d'une API pour vérifier la signature à distance

-> Fait en v7

Fonction pour forcer l'activation d'un module selon le pays lors de l'activation d'un modules

  • Améliorer la proriété ->depends afin de pouvoir faire une dépendance selon le pays = array('FR'=> array('modBlockedLog', ...))

Ainsi en activant le module Facture, cela force l'activation du module modBlockedLog si le pays est France.

-> Fait en v6

  • Ajouter un controle si on change le pays après coup dans la page de configuration pour activer les dépendences dépendant du pays.

-> Optionnel. Si en changeant le pays, on se trouve avec des modules requis mais pas encore activé, afficher un warning et proposer l'activation du module. Si accepté, on change pays + on active les modules, si non, on refuse le changement de pays.

Module de tracabilité modBlockedLog

Ce module a été nommé Module Archives - Logs Inaltérables

  • Trigger sur les actions facture et paiement clients pour tracer l'action, avec les informations d'origine, dans une log chainée (donc difficilement modifiable localement sans être repéré).

On parle d'archivage temps réel.

Chaque ligne intégrant dans sa somme de controle SHA256, la somme de controle de la ligne précédente, rendant impossible la modification d'une ligne sans corrompre toute la chaine (la cas de réécriture complete de toute la chaine restera toujours techniquement faisable, mais le système 100% infaillible n'existe pas, et on considère qu'avec ce procédé, le niveau de difficulté devient tel qu'il est jugé suffisant pour être en conformité, une tentative de masquer un encaissement devient alors hors de portée des utilisateurs et même de la plupart des informaticiens, mais restera toujours "techniquement envisageable" à des hackers de haut niveaux).

Les champs à intégrer dans cette log sont:

  • Row id (séquence technique continue obtenue par max + 1). Note: Ce champ ne fait pas partie du checksum d'intégrité.
  • Date et heure action
  • Code trigger action
  • Info sur l'entité vendeuse (Nom, Num tva, Pays, Id prof, ...)
  • Num tva tiers
  • Infos de l'entité acheteuse (Nom, Num tva, Pays, Id prof, ...)
  • Auteur
  • Infos facture si action relative a une facture ou paiement (Date, total ht, total tva, total ttc, ...)
  • Infos paiement si action relative a un paiement (Ref paiement, Date paiement, Montant paiement (total), Montant paiement (part sur la facture), Mode paiement, Montant hors taxe, Montant tva, Montant local tax 1, Montant local tax 2, Montant avec taxes)
  • Commentaire. Note: Ce champ ne fait pas partie du checksum d'intégrité.
  • Timestamp auto
  • Empreinte de line = signature de la ligne = SHA256(join('|',liste des champs précédents hors Rowid et Commentaire et timestamp auto))
  • Hash de chainage = SHA256(Empreinte de ligne + Hash de chainage de la ligne précédente)

-> Fait en v7

  • Ajout de PHP Unit pour valider erreur de suppression de facture validée.

-> Fait en v7

  • Inclure les actions d'impression ou envoi de factures par email, dans cette log

-> Fait en v7

  • Inclure les actions de désactivation/activation du module dans cette log

-> Fait en v7

  • Inclure la possibilité de faire de recherche sur les champs de la log

-> Fait en v7

Module POS

  • Ajout fonction de cloture journalière, mensuelle, annuelle et ajouter une trace de l'export et du total perpétuel et du grand total dans la log

-> Fait en v9

Fonction pour affichage d'un warning selon pays en cas d'install de module ou module externe

  • Améliorer le descripteur de module par une propriété ->warnings_activation et ->warnings_activation_ext = array('FR'=>'KeyForMessage', ...) pour permettre à un module de déclarer un message de warning qui sera affiché selon le pays lors de l'activation du module ou d'un module externe autre.

La première condition affiche un warning quand on active le module. La deuxième affiche un warning quand on active un module externe. Ceci permettra de mettre en garde l'utilisateur sur le risque encouru à installer des modules externes dans les pays où la législation requiert d'être vigilent sur les fonctionnalités de son logiciel.

-> Fait en v6

Fonction pour affichage d'un warning en cas de désintallation d'un module

  • Améliorer le descripteur de module par une propriété ->warnings_unactivation = array('FR'=>'TranslationKeyMessage', ...). Si défini, Message de confirmation à la désactivation du module si pays de la société correspond au pays dans le descripteur. Ceci permettra d'avertir l'utilisateur si il tente de désactiver un module obligatoire fortement recommandé pour être en conformité avec la loi de son pays.

Avertir que toutes ses transactions précédentes seront invalidées et que même en réactivant le module (action également tracée), seules les traces depuis la dernière activation pourront ere considérée conforme à la loi.

-> Fait en v7

Export archive

  • Dans le module modBlockedLog, possibiliter de générer un fichier CSV depuis la log verrouillée avec signature et infos de chainage, avec colonne action faite (impression, validation...), date, ref facture, ref paiement (si paiement), nature modification, info complémentaires, checksum md5 line (cumul des info)

-> Fait en v7

  • Ajouter le nom et ip de la personne qui a activé un module, en plus de la date.

-> Fait en v6

Ajouter consultation du ChangeLog

  • Rendre lisible/consultable le fichier ChangeLog depuis une page d'administration (accès distant vers page du fichier ChangeLog GitHub via tag de la version).

-> Fait en v7


=> Un intégrateur pourra alors attester de la conformité d'une version de Dolibarr en fournissant la signature de la version et paramétrage pour lequel il s'engage.

Travaux en cours et à venir dans Dolibarr pour permettre la conformité via certification (non obligatoire si l'autre méthode est mise en oeuvre)

Une certification peut etre demandée, par exemple auprès de l'organisme LNE. Elle est payante. Et ne s'obtient que pour une version donnée.

En plus des évolutions déjà évoquées ci-dessus, un gros (très gros) travail documentaire doit etre réalisé pour etre en situation de passer la certification. Voir le document "Référentiel de certification des systèmes de caisse" produits par le LNE (organisme à contacter pour obtenir le document. Si il faut payer pour obtenir le certificat, il faut aussi payer pour avoir les informations sur le périmètre de la certification, mais le document a le mérite d'etre compréhensible).

=> Ce sujet et le processus de demande de certification sera donc peut être fait dans une seconde phase mais n'est pas prioritaire ni nécessaire car la solution par attestation est plus adapté aux logiciels modernes qui évoluent vite.

Planning

Les travaux de mise en conformité suivent la planning suivant:

  • La solution 1 de mise en conformité (conformité via attestation), sera prête avec la version v7 qui sort en janvier 2018. Une mise à jour sera donc possible. Il sera alors possible d'obtenir une attestation auprès d'un partenaire qui délivre ces attestations. Une liste est disponible sur https://partners.dolibarr.org et/ou https://saas.dolibarr.org.
  • La solution 2 de mise en conformité (conformité via certification, non obligatoire du fait que la solution 1 sera disponible), sera aussi mise en oeuvre dès lors que l'application rentrera dans le périmètre (non envisagé à ce jour par le gouvernement). Elle apporterait alors un plus pour permettre de ne pas avoir à demander d'attestation, toutefois les processus de conformité étant long et complexe, une telle orientation vous obligera à utiliser un logiciel figé qui suivra très difficilement le rythme des progrès technologiques. Aussi nous préconisons la solution 1. Pour cette même raison, le calendrier de cette solution 2 n'est par contre pas établi.
Retrieved from "https://wiki.dolibarr.org/index.php?title=Historique_des_modifications_Dolibarr_pour_la_compatibilité_avec_la_loi_finance&oldid=55928"