Il ne s’appelerait pas « Travaux planifiés » plutot ledit module ?
Edit : bah oui, c’est écrit dans ton screen en plus…
J’ai lancé la tache 3 fois, 3 fois la même erreur : refreshall error on date=null or amount=
ok
pour le coup je veux bien le fichier dolibarr.log (mais s’il pèse des centaines de Mo un découpage des lignes de ces dernières heures sera suffisant)…
Bon sinon dans le registre des choses sans importance mais qui titillent… chez moi la page qui est au bout de l’url de paiement ne suit pas les couleurs du thème par défaut.
J’ai notamment le bouton d’action « Paiement par CB » qui arbore cette affreuse livrée mauve / violette historique du thème par défaut de Dolibarr, et que j’aimerais bien changer.
Une idée ? Merci par avance
1 « J'aime »
Hello, nouvelle version du module 1.2.20, dis moi si ça ‹ corrige › le pb de couleur du bouton ? perso je ne suis pas super fan … mais c’est assez étrange que le style « personnalisé » ne s’applique pas sur ces boutons, c’est presque un « bug » du coeur de dolibarr.
Merci encore erics pour ta grande disponibilité !
J’ai installé la 1.2.22, et j’ai une erreur 500 dès que je cherche à aller sur une page qui fait appel au module : si j’essaye de rentrer dans la config du module ( ! ), si j’ouvre une facture…
oulla sérieux ? peux tu regarder error.log car erreur 500 c’est fatal ! et super urgent je vais supprimer cette version du serveur de mise à jour direct !
Je n’ai pas accès au error/log dans l’immédiat, faut queje demande à l’hébergeur.
J’ai installé 1.2.20 pour voir et même soucis…
1.2.16 fonctionne nickel par contre
waw … je vais faire de ce pas un diff entre 1.2.16 et 1.2.22 … merci !
→ seule chose que je vois qui pourrait causer une erreur 500 c’est l’utilisation de variables statiques et l’utilisation du mot clé self:: … mais tout ceci me semble compatible php 5.3 donc j’ai du mal à capter ce qui pourrait provoquer une 500 
Tout fonctionne avec la 1.2.26 : le module fonctionne parfaitement et le bouton d’action est de la couleur du thème - bravo @erics 
1 « J'aime »
Bonjour,
Ce module m’a l’air top mais j’ai commencé avec Dolibarr en version 18, cependant le support de la version de ce module semble s’arrêter en v17, est-ce vraiment le cas ?
Merci d’avance 
Bonjour,
j’ai du oublier de mettre à jour cette partie de la fiche du module (et je vais y remédier sans tarder).
Par contre je vous invite à lire le journal des modifications (changelog) présente en « bas » de la page de présentation du module pour vous rassurer sur la compatibilité dolibarr-18 qui y est expressément nommé !
Éric
Bonjour,
Merci beaucoup d’avoir prit le temps de me répondre :), en effet j’avoue ne pas avoir lu le changelog et d’avoir « bêtement » juste regardé la compatibilité
En tout cas je viens de vous le commander et je vais tester ça de suite
Florian
1 « J'aime »
J’utilise le module Stancer depuis quelques temps et j’ai encore trop d’échecs de paiements.
Il m’a fallu un peu de temps pour comprendre que le simple fait de cliquer sur « payer avec Stancer » fait que Stancer récupère les données clients et acte le statut « en attente de paiement ». Donc au départ je pensais que c’était des échecs mais non c’est juste des paiements qui ne sont pas allés au bout (même si je trouve assez moyen que Stancer récupère déjà les données avant même une tentative de paiement). Mais au delà de ces cas, il y a quand même des échecs de paiements, provenant de clients pour qui ça fonctionnait très bien via le module de paiement stripe.
Autre chose me gêne: le statut « paiement commencé » quand un client a payé. J’utilise le système de relance de factures impayées donc pour moi une facture est payée, impayée ou payée partiellement. Mais ce statut « paiement commencé » implique que les clients sont relancés (car la facture n’est pas en statut « payée » alors qu’ils sont effectué leur paiement. Surtout que le statut ne change pas quand Stancer effectue le reversement (ou alors j’ai mal paramétré quelques chose). Je ne vois pas l’intérêt de ce statut. Si un client paie par chèque et que je n’encaisse pas le chèque, c’est en statut « Payé » et non « Paiement commencé ». J’aimerai que le module ait le même comportement. Ce statut est un statut de paiement, pas un statut de crédit sur le compte. Donc peu importe que l’argent soit sur le compte ou pas, quand le client a payé sur Stancer et que le paiement a été accepté, le statut doit être « payé » pour éviter toute relance injustifiée
Du coup je garde le module sous le coude, mais j’ai réactivé Stripe, qui, hormis le taux de commission, me donne davantage satisfaction.
Hello @cdeboudt
les choses évoluent plutôt dans le bon sens, chez Stancer ils simplifient les états mais pas encore de manière complète, ainsi vous pouvez avoir sur la liste des transactions « payé » mais lorsqu’on demande via l’api c’est « paiement en cours » …
Ensuite côté dolibarr « paiement commencé » correspond à la fenêtre de tir pendant laquelle vous pouvez avoir une pré-acceptation du paiement CB mais finalement un rejet de la banque … je ne sais pas comment « mieux » gérer cette fenêtre de tir, si je passe l’état à « payé » ça va vous faire bizarre si 3 jours plus tard le paiement est finalement rejeté …
Par contre une mise à jour préparée hier apporte un correctif sur ce bug de « paiement commencé » qui dans certains cas particuliers reste alors que le paiement a finalement bien été confirmé. J’ai maintenant un « ramasse miette » sous la forme d’une tâche planifiée qui rattrape les quelques factures qui restent un peu trop longtemps dans cet état (quand le reversement arrive).
J’ai aussi amélioré la situation des factures dont on marque le paiement par chèque et qui finalement sont payées par cb stancer …
Il me reste le serpent de mer que vous indiquez au début du message à savoir je clique sur payer par stancer finalement je ne paye pas et quelques minutes plus tard je re-clique sur le lien, pour l’instant je refuse côté dolibarr de relancer un nouveau paiement pour éviter les doubles paiements et je n’arrive pas non plus à reprendre la session précédente (le jeton de sécurité est cramé) … alors comment gérer la situation vu que même dans le cas où le paiement est déjà fait stancer retourne par l’api « paiement en attente » … vu que les frais liés aux remboursements en cas de double paiement sont à la charge du commerçant c’est une situation délicate.
Pour le coup vous gérez comment si c’est un chèque en bois ? ou si vous « perdez » le chèque ? perso je préfère avoir paiement en cours/commencé pour pouvoir « suivre » ces paiements …
… Le dev continue, pas à pas, ça s’améliore et vos retours sont précieux, n’hésitez pas à en faire part à Stancer également ils sont à l’écoute de toutes les remarques des utilisateurs !
Merci pour cette réponse complète. Effectivement sans doute plus complexe qu’il n’y parait.
Les chèques en bois étant quand même ultra minoritaires, quand je reçoit un chèque je le saisis et la facture est donc payée (le chèque étant présumé provisionné). Si je met du temps à l’encaisser et la banque met également du temps à m’indiquer que le chèque est sans provision, je supprimerai le paiement à ce moment là et la facture retrouvera le statut « impayée ».
Car relancer trop tard un client qui a eu un pb de paiement me parait moins gênant que relancer à tord un client qui est à jour de ses paiements.
Ok je vais repasser à Stripe quelques mois, et je retenterai Stancer ensuite, d’ici là ça se sera peut être amélioré de leur côté.
1 « J'aime »
@cdeboudt très intéressant ce retour, c’est vraiment le genre d’échanges que j’apprécie, la vie réelle, le use-case concret.
Sans tomber dans l’usine à gaz, peut-être qu’une option « considérer le paiement fait dès le retour positif de stancer » serait à votre avis une bonne piste ? quitte à gérer ensuite les cas particuliers de paiements refusés ?
Pour les relances automatiques pour impayés, vous utilisez quel module ? à ma connaissance il n’y a que inovea qui propose ça mais je préfère demander car parfois on découvre des modules inconnus
C’est pour que je vois avec le développeur de ce module s’il peut me le « prêter » (avec @Inovea ça sera facile) le temps que j’analyse la situation et éventuellement fasse le nécessaire (par exemple trouver une astuce pour exclure de sa liste de relance les factures « en cours de paiement » ou « dont le paiement n’est pas tout à fait certifié »), enfin vous voyez l’idée !
Oui pour moi il faut que ce soit en statut payé dès que la procédure de paiement effectuée et correctement déroulée; et effectivement ensuite on gère les cas particuliers.
Je n’utilise aucun module de relance en particulier, c’est une fonction incluse dans les travaux planifiés: sendEmailsRemindersOnInvoiceDueDate
c’est pas parfait mais ça fait le job.
1 « J'aime »
ok merci pour l’info … et effectivement « pas de bol » dans la fonction en question il est indiqué :
donc ça relance même s’il y a des paiements en cours ou déjà effectués
