Nos quatre ans (Déjà...) avec Dolibarr.

Bonjour,

Je vais prendre un gros raccourci, mais Dolibarr nous a permis de préserver notre confort de travail.

Dit comme ça, cela semble un peu farfelu. Mais c’est pourtant vrai. Nous sommes une pme de 5 personnes, dans la mode enfantine. Le choix des deux créatrices de la société est de préserver, favoriser au maximum le confort de travail. Ainsi, nous travaillons tous depuis notre domicile, ou depuis le lieu de notre choix (sauf actualité particulière, bien sur).
Dolibarr est un des instruments qui nous permet de travailler efficacement de cette manière. Il nous suffit d’avoir une connexion wifi, et l’on peut travailler depuis le jardin (je vois des jaloux... ;-)) ,  dans la chambre d’hôtel, sur les salons pro (pratique pour vérifier si le clients a des impayés avant de prendre commande...), à l’atelier de production en Inde, etc etc etc...
J’ai pu aussi donner un accès à notre cabinet comptable, pour que la personne qui s’occupe de nous puisse, par exemple, vérifier un paiement ou une facture. 
Nous l’utilisons depuis 2008 et nous n’avons pas rencontré de limite . En 2011, il y a eu 900 factures et 500 commandes (ce qui représente 34000 lignes de commande). Nous avons actuellement 4700 références en vente.
Comme pour tous les logiciels, nous n’utilisons pas toutes les fonctionnalités. Nous nous servons essentiellement des fonctions commandes-factures-paiements et de la gestion de notre base de clients/prospects.
Le fait que Dolibarr soit construit sur une base Mysql et qu’il soit un logiciel open-source m’a permis de greffer autour tout un tas de petits scripts qui  font 'parler’ la base de façon statistique. Je peux produire sur des feuilles de tableur des stats qui montrent comment vit la collection en cours(Qui commande quoi ? Quelles tailles ? Quelle couleur ? Ce qui nous aide pour anticiper les volumes de production des collections suivantes), des états des comptes clients (utiles pour les bilans...), des projections sur nos commandes de réassort, etc etc. En bref :Dolibarr remplit et gère la base et des à-côtés s’occupent des spécificités de notre métier.


Tout ceci étant dit, cela ne nous empêche pas de pester contre ce qui nous apparaît comme des limitations ou des bugs. (Sommes-nous les seuls a parfois devoir enlever un gros nombre de lignes à une facture ? Le suppression une à une des lignes est juste une torture... A quand un système de sélection multiple  ? )
Nous sommes ravi que la chasse aux clics soit ouverte ! Les factures qui s’auto-valident après un paiement complet est une très bonne idée. Mais on pourrait trouver d’autres gain de temps : placer une autre ligne de boutons (émettre un paiement, envoyer par mail, etc etc) en tête de la facture. Quand les factures sont longues, il faut dérouler toute la page avant de pouvoir cliquer sur ‘émettre un paiement’ ou ‘envoyer par mail’. Ce n’est pas grave, c’est juste pénible.

La seule vraie désagréable surprise fut quelques jours après l’installation (facile et rapide, as usual) de la 3.1 :la gestion des acomptes a changer... 
Pour comprendre, je vais en deux mots expliquer notre fonctionnement. Les commandes sont passées très en amont de la livraison. Environ 6 mois. (Nous commençons a prendre les commandes de la collection hiver 2012-2013 qui sera livrée en juillet.) Nous demandons à nos clients de régler un acompte de 30% de la valeur de la commande, cet acompte valide la commande et la place dans la pile des commandes prêtes à partir. Cette facture d’acompte n’est pas une vente et ne rentre pas dans le CA. C’est seulement un mouvement de trésorerie. (Comme nous le demande notre comptable) Puis, quand la collection est dans nos locaux, on expédie et on facture. Les acomptes viennent se déduire au reste à payer de la facture.

Oui, mais voila. Avec la 3.1, les acomptes viennent obligatoirement se glisser ‘dans’ la facture et en réduisent le montant. (Au lieu de n’être considéré QUE comme un versement qui réduit le reste à payer.)
Du coup, nous nous retrouvons avec un ‘stock’ d’acomptes qui, d’un côté n’a jamais fait partie de notre CA (à raison), et de l’autre vient se soustraire au montant de la facture (donc du ca). Ça ne va pas... 
J’ai cherché une éventuelle option dans les menus de configuration, sans succès. J’ai donc du faire marche arrière et revenir sur la 3.0 (Retour des clics en nombre... ). Suite à cette mésaventure, j’ai deux questions :

	Ou était annoncé ce changement entre la 3.0 et la 3.1 ? J’ai lu et relu  le changelog sans réussir a y trouver cette info. J’ai aussi chercher sur le site web... en vain. Si cela avait été annoncé, j’aurais éviter un cycle upgrade-downgrade toujours un peu hasardeux.

	Pourquoi changer de logique en cours de route ? Je suppose que nous sommes loin d’être les seuls a avoir un ‘historique’ conséquent dans Dolibarr. Changer un point crucial, même s’il peut paraître anodin, peut avoir de grosses conséquences. En utilisant Dolibarr, c’est comme si on confiait notre entreprise au logiciel : on y place notre mémoire commerciale et comptable. Il faut pouvoir être en confiance. (Je continuerais a l’être, mais je vais être plus prudent. )


Cette dernière péripétie ne change pas notre avis global sur Dolibarr : c’est un bon outil, qui fait son parfaitement son oeuvre. Il y a seulement cette frustration de devoir rester sur la 3.0 si la gestion des acomptes n’évolue pas ou si elle ne devient pas paramétrable. 
Je continuerais à le promouvoir  (concurrents ‘amis’, clients ... ) et à veiller les futures versions.

Merci à tous les contributeurs de ce projet.
Bien à vous,

Xavier.

En effet, il y a eu un oubli dans le changelog. En fait, il ne s’agit pas vraiment d’un oubli car le problème était que dans certains endroits de l’application on gérait les accomptes en tant que paiement et dans d’autres en tant que réduction du montant total de la facture finale.
Il fallait donc corriger cela. Le choix a été fait d’uniformiser dans le sens accompte = diminution de la facture finale. Comme il s’agissait plutot d’une correctif, cela n’est pas forcément tracé dans le changelog.

Pour ce qui est de votre cas, il est possible d’ajouter une fonction pour gérer les accomptes comme « paiement » et non comme ligne de réduction de la facture finale (histoire d’etre uniforme mais dans l’optique inverse). Ce qui vous permettrait d’upgrader sans perdre le fonctionnement actuel.
Mais dans ce cas, le totaux des rapports n’incluerait pas alors les factures d’accompte qui seraient invisible (pour ne pas etre compté 2x).
Comment gériez vous cela auparavant ? En ignorant les accomptes dans vos rapports je présume ?

Quid des rapport de tva qui n’incluerait alors pas les accomptes ?

Merci de m’avoir répondu.

Dans les rapports généré par la 3.0, les acomptes ne sont pas pris en compte. j’ai regardé le code, et la ligne est mis en commentaire.

Pour le calcul du CA, je me dépatouillait avec une requête mysql qui me crachait mon ca (facture en +, avoirs en - et exclusion des acomptes)

Et oui : ce serait vraiment extra si on pouvait gérer les acomptes comme un paiement. Une option, comme vous l’indiquez, serait idéal.