Dés que Laurent aura donné sont feu vert pour l’implémentation.
Je ne vais pas commencer un développement Core Dolibarr pour qu’il reste en demande d’intégration (PR github) sans suite.
C’est que je voulais dire en disant mode de paiement. Je parlais bien de condition de paiement. Mais du coup ma question reste entière.
Y a-t-il vraiment beaucoup de condition en n fois différente ?
30% acompte, 70% à livraison
30% acompte, 40% livraison, 30% après période de garantie
Cela en fait 2 à saisir dans le dictionnaires des conditions de réglements. On peut imaginer en avoir une dizaine soit. Mais y a-t-il beaucoup d’utilisateurs qui auront 1 condition de paiement différente par client, soit des centaines ou milliers différentes du genre ?
Client 1=31% acompte, client 2=32%, client 3=33% ?
J’en doute. Donc pour moi, c’est bien la condition de paiement qui porte, EN GENERAL, le ratio des acomptes à faire. Donc ce paramétrage doit se faire à ce niveau la. Pour une généralisation dans le core, il faut donc partir la dessus.
Pour les cas qui ont besoin d’une condition de paiement différente pour chaque client, il reste possible de mettre un mode plus avancé. Ainsi la condition de paiement au lieu d’etre
30% acompte
pourra être
**% acompte (on peut imaginer * ou un mot réservé pour définir que ce pourcentage d’acompte doit etre défini sur chaque client), mais ceci me semble être un cas avancé du cas plus générale/fréquent.
Il faut dans un premier temps implémenter le cas général, le cas sophistiqué pouvant être dans en option cachée dans un premier temps avant de voir si il a vraiment un publique suffisamment large pour justifier une activation par défaut.
Donc plutôt qu’une case à cocher, je privilégierais un champ de saisi où on saisirait le ratio (donc 30 pour 30% par exemple) ou éventuellement un mot réservé « VARIABLE » ou « BYTHIRDPARTY » ou * (pour un mode ratio propre à chaque client) ou encore « 30 * » ( * signifiant variable par client, et si pas défini on propose 30% par défaut).
Bonjour Eldy, Ok merci pour ton retour, nous partons donc sur ce développement avec tes remarques
je ne comprends plus rien : si ça reste dans les conditions de règlements:
- il faudra en dupliquer autant que de cas particulier non ?
- il ne serai possible que d’indiquer un % et non 1 ou n montants
- la proposition de gains d’ergonomie est perdue ?
On parle ici que du pourcentage qui sera proposé par défaut lors de la création de l’acompte. Dans ce cas cette info sera le pourcentage défini sur la condition de règlement.
Si il y a besoin d’un pourcentage différent pour chaque client, il n’y aura alors qu’une seule condition plutôt que 3 ou 4 et ce sera au niveau du client que le pourcentage sera défini.
Dans tous les cas, ce n’est que le pourcentage prérempli proposé par défaut. Il restera toujours possible de définir ce pourcentage à la valeur de son choix, comme actuellement au cas par cas.
tout à fait d’acord avec toi Laurent, mais…
je pense que c’est justement sur ce point que les avis divergent en partie : pas de % prévus, pas de montant(s) prévu(s), mais chacun l’envisageable « à la volée » (ce qui se pratique trèsssssssssssssss souvent dans du btb et peut être dans du btc (là je n’ai pas d’expérice à part certain secteur dur BTP) )
Oui, initialement je l’avais imaginer comme Eldy, c’est a dire un % directement dans le dictionnaire, mais les divers retours (avant de soumettre ici la spécifications) m’ont amenés à proposer l’alternative décrite.
L’objectif c’est que cela reste paramétrable sur la fiche client mais qu’il y a un taux par défaut dans le dictionnaire.
Salut Floriant,
oui qu’il y ai un « par défaut » en fonction du client c’est bien, mais vraiment l’idéal à mes yeux c’est que ça puisse être modifié en % ou en montant à la volée: c’est là qu’on gagne toute l’érgonomie pour ceux qui font ça au quotidien. (un peu le principe d’un « prix de vente conseillé » vu grand public… mais qui n’empêche pas la négociation)
Oui, pour moi cela soit rester un choix à tous les niveaux
1 « J'aime »
Bonjour a tous,
Voila le résultat
Video Demo
il n’y a plus qu’a attendre la validation : NEW: payment conditions enabling semi-automatic deposit creation (Issue #18439) by marc-dll · Pull Request #18853 · Dolibarr/dolibarr · GitHub
3 « J'aime »
Merci pour cette proposition de fonctionnalité. J’arrive après la bataille mais j’apprécie que pour une fois un développeur demande l’avis des utilisateurs.
Personnellement ce développement me sera très utile car j’adresse presque systématiquement une facture d’acompte après validation d’une proposition.
Bonjour,
Je ne peux m’empêcher d’évoquer un problème majeur de la gestion des acomptes une ligne : ils migrent d’office en première ligne de facture, ce qui est peu commun dans une facture de situation de travaux ou pour le BTP en général. La possibilité de les envoyer en un click en bas de tableau n’existe pas sous Dolibarr et le déplacement manuel pour des documents longs est …une véritable gageure.
1 « J'aime »
Vous avez dit le mot magique, Situration, les acomptes ne sont pas des facture de situations.
Pour gérer les factures de situations (come ce qui se fait dans le BTP), il faut activer les options cachées de INVOICE_USE_SITUATION et INVOICE_USE_SITUATION_CREDIT_NOTE
Merci @FHenry, mais je ne faisais pas la confusion. Les deux se combinent tout à fait. Je citais la redivision de la facture en tranches de situations (activée grâce au réglage que vous évoquez très justement) uniquement pour bien faire comprendre la longueur de certains devis et pour illustrer la difficulté de mettre à posteriori les informations sur les remises et acomptes en fin de document.
Dans ce cas des situations, les acomptes sont en effet eux-mêmes redivisés et peuvent être déduits au prorata de l’avancement du cycle : Il est de pratique courante que leurs lignes se superposent et ils s’ajoutent les unes aux autres pour totaliser le montant d’acompte dans la facture de clôture du cycle, comme convenu au devis. Dolibarr gère bien ce calcul au fur et à mesure de l’avancement.
Mais de toute manière, dans n’importe quel type de facture Dolibarr, situation ou standard, la ligne d’acompte (ajoutée dans la facture après usage de la fonction de « conversion en remise fixe ») est placée en 1ere ligne… alors qu’il serait très sensé pour une bonne part des utilisateurs, d’en faire la déduction APRES l’énuméré des prestations facturées, vu qu’il ne s’agit pas d’un produit à proprement parlé mais plutôt d’une modalité de règlement…
Pour ceux que cette réflexion intéresse, le renvoi des acomptes en fin de tableau des produits peut se réaliser avec une intervention minimale dans le code du fichier facture.class (du moins sur la v11).
Dans le passage :
/**
* Add a discount line into an invoice (as an invoice line) using an existing absolute discount (Consume the discount)
*
remplacer la ligne
$facligne->rang = -1;
par
$facligne->rang = count($this->lines)+1;
1 « J'aime »
Merci pour cette solution. Je suis moi aussi agacée par ce comportement et comme vous systématiquement, je déplace cette ligne en fin de facture d’acompte.
1 « J'aime »
Hello.
Je suis super intéressé par cette fonctionnalité car je demande toujours un acompte de 50 % à la commande.
On peut espérer voir ça intégré dans le core avec quelle version ?
Merci aux devs.
Bonjour,
Ba écoute la demande d’intégration est toujours en attente…
Si tu vous pouvez mettre un +1 un commentaire sur la PR peut-être que cela va facilité son intégration.
En tout cas se ne sera pas avant la version 16 car la 15 est « gelé » et devrait arrivé dans pas trop longtemps
1 « J'aime »
C’est où qu’on peut faire un +1 comme tu dis ? Je suis identifié à mon compte Github, mais je ne suis pas un familier.
Merci.
Bonjour, merci pour le développement de ce module désormais présent dans la V16.
Dans mon cas je souhaiterais afficher en fin de devis différentes échéances pour le règlement d’une prestation de travaux électrique, du style :
Conditions de règlements
- 30 % d’acompte à la signature = X€
- 30 % au démarrage des travaux = X€
- 40 % à la réception du chantier = X€
Je dois ajouter de nouvelles lignes dans le dictionnaire ?
Je vous remercie pour votre retour, je prends tout juste en mains ce super outil,
Bonne journée,
