Merci erics pour ce développement, le module fonctionne bien chez moi - je suis impatient de pouvoir le passer en prod
J’aimerais néanmoins soulever un détail pratique : selon les usages qui ont cours dans notre métier et nos préférences perso, nous avons je pense besoin de solliciter le paiement auprès des clients à un moment différent.
En ce qui me concerne :
les nouveaux clients règlent 100% à la signature de la proposition pour la première affaire ;
les clients fidélisés règlent un acompte de 50% à la signature de la proposition, et le solde à réception de facture ;
les gros comptes règlent en LCR à 30 jours
j’utilise les propositions mais pas les bons de commande que je trouve redondants avec les propales ;
j’édite les factures au départ de la marchandise ;
Il me serait donc fort utile de pouvoir déclencher les paiements par Stancer à partir des propositions, j’imagine que pour d’autres il serait pratique de les déclencher au moment du bon de commande ou de la facture d’acompte…
Serait-il possible de faire en sorte qu’on puisse déclencher les paiements à toutes les étapes ?
Je ne suis pas comptable mais il me semble que si tu prend de l’argent à la signature du devis ça s’appelle un acompte et tu dois donc faire une facture d’acompte qui sera déduite de la facture finale.
Excellente idée et « oui bien entendu » ! Pour mes différents services « automatiques » je transforme le devis en commande client laquelle est payée et provoque la création automatique de la facture donc je rejoint tout à fait ce besoin.
Dans la situation actuelle du dev j’avance pas à pas pour débusquer le moins de bugs possibles à chaque itération sinon vous allez me tomber dessus avec 200 bugs et ça risque d’être ingérable
Donc dès que le tunnel de paiement sera tout à fait validé sur les factures je ferais le nécessaire pour les devis, commandes …
En fait,
ce qu’il faut c’est avoir sur la page de paiement une phrase du genre « le paiement (intégral ou partiel) vaut acceptation du devis référence xxxxx (ou de la commande zzzzz) » et ensuite lancer les actions automatiques de dolibarr comme indiqué dans la capture d’écran:
Créer automatiquement une commande client à la signature d’un proposition commerciale (la commande sera du même montant que la proposition commerciale) → ça sera transparent / invisible pour le client mais ça permettra d’avoir le 2.
Créer automatiquement une facture client à la clôture d’une commande (la facture sera du même montant que la commande)
Avec le cas particulier du paiement de x % à la commande qui ne pourra donc pas créer de facture automatique à la cloture de la commande vu que la commande ne sera pas intégralement payée dans ce cas précis … à la réflexion je me demande si ça ne serait pas un « manque » de dolibarr de ne pas pouvoir automatiquement éditer une facture d’acompte dans ce cas … on s’éloigne un peu du sujet « Stancer » du fil mais c’est une réflexion qu’il faudrait peut-être mener ?
Dans le cas de @Mauresque ça implique de réactiver les commandes clients qui donnent souvent l’impression d’ajouter des étapes « administratives » … mais qui apportent aussi des choses en plus
1 / actuellement le module remonte à Stancer les infos suivantes :
dans le champ « Numéro de commande » ; un numéro de transaction de type « INVxxx.CUSxxx » - on pourait croire que INV se réfère au numéro de facture et CUS au numéro de client, mais chez moi ça ne correspond pas., Donc peu explicite ou utile comme information…
dans le champ « Description » ; le n° de document interne qui a servi à la génération du paiement (facture seulement aujourd’hui, proposition ou commande également je l’espère bientôt ) de type « Payment for FACxxxx » dans la description.
Hors dans l’interface « Paiments » de Stancer la première colonne est « Numéro de commande » et le champ « Description » n’apparait pas et on se retrouve avec comme réf. de paiement une info peu explicite (les deux premières lignes ici, celles d’en dessous ont été saisies à la main directement via l’interface de Stancer.
Serait-il possible de recopier la référence du document interne dans le champ « Numéro de commande » plutot que « Description » ?
2/ également, le lien de paiement envoyé au client reste actif même quand il l’a déjà utilisé et que le paiement est passé. Pour éviter les double paiements, serait-il possible d’invalider le lien quand il a été utilisé ?
3/ enfin, si le statut du paiement remonte bien dans Dolibarr au niveau du compte Stancer, mais la facture reste au statut « Impayée » même quand un paiement a été passé avec succès. Serait-il possible de passer automatiquement la facture au statut « Payé » ?
Je pense que si on combine 2/ et 3/ ; on peut afficher l’info « Facture payée » sur l’écran qui arrive quand on suit le lien de paiement.
Salut @erics, la création automatique de la facture d’acompte existe dans Dolibarr et fonctionne plutot bien, fonctionnalité acompte automatique Tu pourrais peut être l’utiliser mais il faut que cela soit définit comme condition de paiement du devis.
L’automatisme de l’acompte créé la facture d’acompte avec le bon montant de X% et le workflow crée automatiquement la commande tu as tout ce qu’il faut je pense
INV et CUS sont en effet les numéros de factures et de clients (les index, que tu peux voir dans l’uri dolibarr .php?id=xxx … j’ai « gardé » ces codes qui sont communs avec les autres modules de paiements mais je te rejoins sur le côté très bof car c’est ce qui apparait sur le relevé de banque du client … ou il vaudrait largement mieux avoir FA2201-01253 par exemple donc je vais modifier ça
2/ oui bien sûr
3/ c’est un indispensable pour pouvoir accéder à la version 1.0 du plugin donc oui
je vais creuser cette piste mais oui c’est évident qu’il faut l’utiliser ! merci 1000 fois de l’avoir pointé ! c’est toute la force du forum: je serais totalement passé à côté !!!
Eric, j’avais pensé à réutiliser le stripe_card_ref et le stripe_acount de llx_societe_rib en v18 pour permettre son usage avec d’autres systeme comme stancer. Mais cela signifierais que si on met stancer, on ne peut plus mettre Stripe ou un autre. Bref, finallement pas le choix, il faudra de nouvelle colonnes. Soit en dur comme actuellement, soit en extrafields, soit en table complementaire…
Tu es parti sur quoi ?
Hello Laurent,
au début j’ai réutilisé les champs « stripe* » en faisant abstraction du nom pour y stocker les données ad-hoc pour stancer … mais d’un côté c’est moche et de l’autre j’étais pas super serein par rapport aux collisions à venir.
Et puis sur mes dolibarr j’ai déjà du stripe et j’ai vu les collisions
Alors j’ai interprété à ma manière la réponse d’Alex et je me suis dis que même si nativement on ne propose pas d’ajouter des extrafields sur cet objet rien ne m’interdit de faire
ALTER TABLE llx_societe_rib ADD stancer_object_ref VARCHAR(32) NULL DEFAULT NULL AFTER stripe_account;
ALTER TABLE llx_societe_rib ADD stancer_account VARCHAR(32) NULL DEFAULT NULL AFTER stancer_object_ref;
Note: la v1.0 du plugin n’est pas encore sortie tu peux encore me dire de faire autrement
Par contre, tant que t’es la il faudrait voir si t’es ok pour ajouter des hook/triggers sur les pages ou on a « en dur » du stripe/paypal pour permettre l’intégration propre de modules complémentaires … je pense en particulier aux pages
compta/facture/prelevement.php
societe/paymentmodes.php
ne pouvant pas interagir avec ces pages la seule solution que j’ai trouvé est de proposer un onglet supplémentaire « Stancer » dans lequel je fais mon boulot:
Idéalement, il aurait fallu les extrafields sur cette table, mais y a pas alors pourquoi pas l’ajout des colonnes par le module. Le nom avec stancer_ est suffisant pour éviter les collisions.
Bien sur tu peux ajouter des hooks.
Pour les triggers, ajout possible uniquement si cela respecte bien une action CRUD d’un objet métier Dolibarr. Si autres, c’est hook.
@Mauresque j’ai besoin d’éléments complémentaires par rapport à ça:
est-ce que ton dolibarr est en accès public ? car normalement après le paiement stancer le client devrait « revenir » sur dolibarr (page « paiement effectué avec succès ») et c’est là qu’on stocke dans dolibarr que la facture est payée etc.
j’arrive à reproduire ton cas avec un dolibarr hébergé dans mon réseau local donc à la fin du paiement stancer ne peut pas me faire revenir sur mon dolibarr et donc pas de création automatique des paiements …
pour répondre à ce problème je vois deux solutions possibles:
une tâche planifiée « stancer » dans dolibarr qui irait périoquement demander à stancer où en sont les paiements (de toute façon il faudra le faire pour « suivre » les transferts entre stancer et la banque principale où sera versé l’argent au bout de ~7jours)
lorsqu’on se place sur la page « Encaissements par Stancer » de vérifier ligne par ligne si le document dolibarr lié est à jour où pas …
Le 2) va provoquer un ralentissement de l’affichage de la page surtout si vous avez des listes longues par défaut (chez moi 500 par exemple) … ça veut dire 500 chargements de factures pour vérifier les paiements liés … hum mais aurait l’avantage du « direct » alors que 1) impliquera une impression de « ça ne marche pas » …
Ou 3) un bouton sur la fiche facture « actualisation stancer » …
dans tous les cas il faut faire qqchose pour gérer par exemple les « disputes », ou rejets de paiements qui interviendraient dans la période légale …
Oulla @Mauresque c’est du sérieux la …
le champ ext_payment_id est arrivé dans la table llx_prelevement_facture_demande avec dolibarr 10 … en tout cas c’est ce que je « vois » dans la migration SQL de dolibarr 9 à 10:
ALTER TABLE llx_prelevement_facture_demande ADD COLUMN ext_payment_id varchar(128) NULL;
Ton dolibarr est ancien et une mise à jour s’est mal passée ? peux tu faire un export uniquement de la structure de la table llx_prelevement_facture_demande stp ?
Et tu peux la comparer à la structure que tu devrais avoir avec la 16.0 ?
