GED : Dolibarr 17+ suffixe des fichiers pdf ("pseudo-signés" et +)

[erics]

Bonsoir,
dans la version 17 est apparu un suffixe automatique appliqué aux fichiers pseudo-signés dolibarr (vous savez quand votre client dessine un truc qui ressemble de loin à une signature manuscrite) :

• fichier.pdf devient fichier_signed-20230315220214.pdf
• 20230315220214 étant l’année le mois le jour suivi de heure minutes secondes

C’est une idée, pas forcément bonne mais une idée qui peut répondre aux cas de figure que nous avons rencontrés depuis que nous utilisons uptosign. Par exemple pour une facture

• je demande à la sceller pour l’envoyer à mon client et qu’il puisse ainsi être sûr que le RIB présent est bien celui de cap-rel et qu’il a entre les mains un document authentique
• le client paye sa facture
• le client me demande une facture acquitée (ou dolibarr re-génère le PDF par le biais des actions automatiques lorsque le paiement est enregistré)
• le « nouveau » fichier PDF n’est plus scellé

Dans le cas d’un devis signé c’est encore plus problématique de « perdre » la signature sur un simple clic sur le bouton « générer le pdf » (ou une action automatique) … c’est donc plutôt une bonne idée de rajouter un suffixe à chaque version scellée / signée du document.

Mais pas un suffixe aussi long:

• ça occupe toute la place, sur certains écrans ça masque la loupe permettant d’avoir une vue rapide du document pdf
• la date/heure du fichier est disponible dans les métadonnées, pourquoi l’ajouter au nom du fichier ?

Il me semblerait plus pertinent que ça soit un numéro 01,02,03 … ça serait étrange d’avoir plus de 99 versions d’un même document …

Et vous, qu’en pensez vous ?

[nicolas90]

Oui avoir plusieurs version du document mais il va falloir une interface pour montrer X documents (A définir dans les paramètres PDF) et une solution pour avoir les autres documents par une extension de la liste des X documents affichés et ne pas avoir une liste affiché en permanence de toutes les générations de document. En provisoire gérer le fait de n’avoir qu’un seul document

[erics]

Je viens de voir que le module dolibarr historique des devis (Historique Proposition commerciale V2) propose de conserver les différentes versions PDF d’un devis.

Et les noms des devis sont suffixés de -1.pdf puis -2.pdf etc.

L’idée de cet espace sur le forum serait d’arriver à un consensus ou un choix qui serait partagé histoire que chaque module n’invente pas une solution dans son coin …

[pscoffoni]

Hello je vote aussi pour un simple incrément dans le nom du fichier

[isamuse]

Très bien et suffisant à mon sens

[erics]

@erics

Et les noms des devis sont suffixés de -1.pdf puis -2.pdf etc.

Sauf qu’en fait dans le cas particulier de ce module le fichier pdf est nommé à partir de la révision du devis, donc si vous re-générez le pdf de la révision 2 il écrase le fichier -2.pdf … si le fichier .pdf contenait la signature du client vous perdez la signature.

Le problème reste entier

[erics]

Alors d’un point de vue plus général, la question est de savoir quand est-ce qu’il faut « archiver » un pdf et qu’il est « différent » de la fiche dolibarr:

• Lorsque le fichier PDF est signé
• Lorsque le fichier PDF est scellé (horodaté et verrouillé par un certificat électronique)

Y a t il d’autres cas de figure où le fichier PDF pourrait être différent de ce que dolibarr pourrait produire en cliquant sur le bouton générer ?

• Lorsqu’on change de modèle de document (devis pdf généré avec azur, puis re-généré avec cyan)
• … ?

Dans quels cas est-il important de conserver un PDF ?

• Le fichier PDF a été communiqué à un tiers (client)
• Le fichier PDF a été versé en compta
• Le fichier PDF a subit une modification structurelle importante (ajout de pièces jointes, signature, scellement)
• … ?

Avez-vous des idées complémentaires ?

[erics]

Je suis en train de faire un démonstrateur pour creuser l’idée sous la forme d’un module qui sera facile d’intégrer au coeur de dolibarr si l’idée s’avère judicieuse.

Mais pour ça je vais avoir besoin d’un large éventail d’usages donc plus vous serez à tester et mieux ça sera ! Prêt(e)s ? Attention, pour jouer il faut vraiment un dolibarr de test/bricolage n’allez pas faire ça en prod !

1ere étape pour illustrer l’idée : le module suivant archivespdf. Comme son nom l’indique il a pour but d’archiver les PDF. Pour l’instant:

• il fonctionne uniquement sur les DEVIS
• chaque fois que le PDF est généré il archive le PDF précédent
• j’ai fait le choix de créer un sous dossier « archives » dans le dossier de stockage du document de ce fait la liste des archives ne « pollue » pas la liste des documents joints à un objet dolibarr et permet de « contenir » les informations dans une sous arborescence, ça aidera pour la gestion des droits d’accès en particulier

Ensuie, vous remarquerez l’onglet « archivespdf » que ce module « apporte »

Dans cet onglet - pour l’instant - vous ne pourrez que « voir » la liste des archives, bien entendu à terme il faudra pouvoir interagir avec mais avançons pas à pas voulez vous

La GED standard de dolibarr nous offre quelques champs actuellement inutilisés que nous pouvons mettre à contribution (et donc ce boulot aura un impact sur la GED globale de dolibarr, en vérité ça a déjà commencé avec un 1er PR en cours dans le coeur).

Ci dessous vous trouverez entre parenthèses les commentaires issus du fichier SQL de description de la création de la table en base de données:

• description (champ texte libre)
• keywords (list of keywords, separated with comma. Must be limited to most important keywords)
• cover (is this file a file to use for a cover)
• extraparams (for stocking other parameters with json format)
• note_public : classiques notes publiques qu’on retrouve dans tout objet dolibarr
• note_private : idem pour les notes privées
• acl : (for future permission ‹ per file ›)

En résumé tout ceci n’est qu’un démonstrateur (POC dans notre langage de développeurs) histoire de matérialiser l’idée / le concept / le fonctionnement pour qu’on puisse tous parler sur un « truc » palpable.

Bien entendu l’idée n’est pas de faire une archive à chaque fois que le pdf est modifié, l’idée est qu’au final un développeur puisse faire ce qu’il veut et propose lors des étapes importantes d’archiver le pdf, par exemple lorsqu’on envoie un mail avec le PDF en pièce jointe, par exemple lorsqu’on récupère un PDF après la signature, etc.

Je souhaite proposer des améliorations dans le coeur de la GED de dolibarr pour avoir par exemple une fonction toute simple $fichier->archiver() qui ferait le boulot d’archivage. Ensuite il faudra probablement d’autres fonctions pour interagir avec les archives et c’est pour ça qu’il vaut mieux y réfléchir ensemble …

Téléchargement du module : CAP-REL
Si besoin, les sources sont ici: CAP-REL / dolibarr / Plugin ArchivesPdf · GitLab

[erics]

Suite de la réflexion pour un cycle assez « simple » devis → facture (sans passer par commande pour ne pas trop vous complexifier le process):

• 1. création du pdf, fichier PR2301-2001.pdf
• 2. scellement du pdf, fichier PR2301-2001_sealed-1.pdf
• 3. envoi du pdf au client, le client demande une remise,
• 4. modification du pdf, fichier PR2301-2001-2.pdf
• 5. scellement du pdf, fichier PR2301-2001_sealed-3.pdf
• 6. envoi du pdf au client, le client demande une modification de la quantité
• 7. modification du pdf, fichier PR2301-2001-4.pdf
• 8. scellement du pdf, fichier PR2301-2001_sealed-5.pdf
• 9. envoi du pdf au client, le client accepte
• 10. envoi du pdf à la signature électronique, c’est donc le fichier PR2301-2001_sealed-5.pdf qui est envoyé
• 11. retour du fichier signé, fichier PR2301-2001_signed-6.pdf
• 12. création d’une facture, FA2301-125.pdf
• 13. scellement du pdf, fichier FA2301-125_sealed-1.pdf
• 14. envoi du pdf, le client paye
• 15. le client demande une facture « acquittée » / « payée »
• 16. saisie des informations de paiement dans dolibarr, clic sur générer le pdf, fichier FA2301-125-2.pdf
• 17. scellement du document, fichier FA2301-125_sealed-3.pdf
• 18. envoi du document au client

État final dans l’arborescence:

Résultat dans dolibarr:

Voyez vous l’idée ? ça c’est une vue très technique / développeur, mais je pense que pour l’utilisateur normal c’est l’échec assuré « trop compliqué » à comprendre du 1er coup.

Question: dans son dossier principal au lieu de garder la dernière version du fichier normal + fichier scellé + fichier signé ne vaudrait il mieux pas garder uniquement la dernière version tout court ?

Résultat dans dolibarr seul la dernière version du fichier est visible:

L’objectif au bout du bout serait d’avoir un truc avec une représentation visuelle de ce genre:

Mon Devis → a été scellé (1.pdf) → a été modifié (2.pdf) → a été scellé (3.pdf) → a été modifié (4.pdf) → a été scellé (5.pdf) → a été signé (6.pdf) → est devenu une facture → a été scellée (1.pdf) → a été payée (2.pdf) → a été scellée (3.pdf)

Pour les utilisateurs d’outils de type TimeMachine l’idée serait d’avoir dans la partie « archives » un visualiseur de PDF avec des flèches « précédent » / « suivant » pour éventuellement pouvoir dérouler l’historique d’un document … d’ou l’importance de pouvoir « chaîner » les fichiers les uns après les autres.

[erics]

Bonjour,
si vous voulez tester, le module de test (gratuit bien sûr) est ici :

dolibarr-archivespdf

version 0.0.2 suite aux dernières réflexions … je vous laisse tester, il faut prendre ce projet comme un prototype qui permet de réfléchir à des évolutions possibles plus globale de la GED de dolibarr