Bonjour,
toujours pour décrire l'ensemble des évolutions apportées à Dolibarr 2.6.1 depuis quelques mois pour ma société qui a pu gérer l'afflux de demande grâce à cet outil CRM/ERP équilibré et vivant par ses échanges communautaires :
Comme je l'ai indiqué dans les préliminaires j'avais décidé de ne pas modifier le modèle de données pour ne pas rendre les migrations futures ingérables. Je le regrette peut-être un peu maintenant mais voici comment j'ai contourné le pb pour ajouter de nouveaux champs, en particulier la gestion des modes de réglement par chèque et en location financière.
--> utilisation de la "note publique" comme d'un 'super champ" pour stocker entre des "balises" (Ex : Nb de cheques / Fin Nb de cheques) les différents éléments nécessaires entre autres à la génération des propositions et des factures.
--> Indications 'plus fines' de conditions de règlement pour les chèques (nombre de chèques et encaissement à intervalle de 1 mois d'un montant au prorata, ou de façon plus complexe si date/montant non 'standard'). Il faut noter qu'il s'agit simplement d'un paragraphe dans la proposition et qu'il n'y a pas de gestion de ces dates/montants au niveau facture avec rappel automatisé.
--> Addition d'un nouveau mode de réglement, la location financière, qui fait intervenir un 'leaser' (organisme financier) qui va récupérer des loyers mensuels (24/36/48 mois avec des modalités spécifiques) auprès du client final et nous régler à nous la totalité en 1 fois (avec un petit bonus). Le nom du leaser est aussi dans ce super champ de "note publique".
--> à part les modes de règlement, ce super champ contient aussi le nom de 'facturation' (plus rarement une adresse différente) qui n'est pas toujours celui du client de départ (l'enseigne d'enregistrement d'un prospect/client n'étant pas toujours le nom devant figurer sur la facture)
--> jusqu'à récemment il fallait remplir 'à la main' ces données en allant dans l'onglet 'note publique' mais j'ai créé une interface pour lire/écrire (de pair avec l'interface de choix des produits-services que je vais détailler dans le prochain post).
Je suis conscient que cette façon de faire (super champ au lieu de base de données) n'est pas académique mais, au départ, j'ai considéré que migrer des données, en plus de la migration de code, me semblait trop 'risqué'. Je l'ai payé cependant très cher car j'ai découvert que la notion 'd'espace' (" ", "\xc2\xa0"... avec trim()) ou de 'balisage' d'un texte (style html) n'était pas toujours triviale...
Au prochain post...
Romain