Jump to content

Rodolphe

Members
  • Posts

    247
  • Joined

  • Last visited

About Rodolphe

  • Birthday 10/31/1972

Rodolphe's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. Bon, je suis un âne. Il manquait la table ps_order_invoice_payment, qui fait justement le lien entre les paiements et la factures, donc forcément ça ne pouvait pas aller... Pfff à force de vouloir être sur plusieurs fronts en même temps, on fait des co.....es ! Rodolphe
  2. Bonjour. À mon tour de rencontrer ce problème. Testé avec différents mode de paiement qui ont tous un point commun, quand la facture est passée elle n'est pas encore payée (virement, chèque ou paiement CB différé). Je passe au statut suivant (paiement accepté), ça créé le paiement. Ok pourquoi pas même si ça ne devrait pas le faire en automatique il me semble, ce sont des paiements qu'il faudriat enregistrer manuellement. Mais passons, pourquoi pas. Ensuite quand je passe en préparation, rebelote, paiement en double ! J'ai déjà installé pas mal de Prestashop dont deux que j'utilise tous les jours, sans jamais rencontrer ce problème. J'avoue que je ne trouve pas... Ce nouveau site est en 1.6.1.20. EDIT : J'ajoute que si je créé d'abord le paiement manuellement, le passage ne paiement validé le double aussi. Alors que sur mon prestahsop habituel, aucun souci. Si je créé manuellement le paiement ou si je laisse Presta le créer au changement de statut, tout va bien. Là c'est Presta qui ne "voit" pas qu'il y a déjà un paiement ! Rodolphe
  3. Ceci a pour seul impact de désactiver la gestion avancée des stocks. Et du coup ça ne décrémente pas le stock sur les articles, donc ça ne va pas non plus. Rodolphe, qui cherche aussi
  4. Je me permets de remonter le sujet, car j'ai le même problème. Ce qui me gêne souvent avec les développeurs - je précise que j'en ai été un aussi - c'est qu'ils donnent l'impression de développer pour eux et eux seulement. Autrement dit, ils ont une idée sur le fonctionnement et c'est forcément la bonne... C'est hélas très souvent - de plus en plus ? - le cas avec Prestashop ! Dans le cas présent, le fonctionnement est imposé, alors qu'il n'aurait sans doute pas été bien compliqué de prévoir le cas du non cumul, de laisser le choix. Mais non, pour les développeurs il n'y a qu'une possibilité, donc c'est comme ça et pas autrement. Et les utilisateurs ? Quels utilisateurs ? Bref, je suis preneur d'une éventuelle rustine, une de plus. Je ne me penche plus sur le code Prestashop depuis la version 1.4 ou 1.5 - en 1.6 n'en parlons pas, ni en 1.7 d'ailleurs - tellement c'est devenu une usine à gaz illisible... Peut-être un développement tiers que nous pourrions mutualiser ? Rodolphe
  5. Bonjour, C'est du bricolage mais ça m'a permis de débloquer un client - enfin deux - qui sont sur une même installation, en multi boutiques donc. Grand merci pour le gain de temps. Rodolphe
  6. Ils sont réactifs, même si au début ça a été compliqué. Sur ma boutique c'est devenu presque fonctionnel, encore quelques petits points qui posent problème. Mais j'ai pu, parfois en bricolant, vendre des articles avec acompte. Rodolphe
  7. Si votre module - que j'ai acheté fort cher - fonctionnait ce serait en effet une excellente solution. S'il fonctionnait ! Rodolphe, très mécontent
  8. Il n'empêche... C'est dans les faits possible d'être remboursé ou de bénéficier d'un bon d'achat si on prouve - avec beaucoup beaucoup d'insistance - que le module n'est pas conforme à la description, pas compatible avec une version de PS contrairement à ce qui est écrit, etc. J'y suis parvenu, mais encore une fois en insistant et en râlant... Il faut dire que ce n'est pas la première fois qu'un module, pourtant développé par l'équipe PS, n'est pas du tout fonctionnel. Pas très sérieux tout ça ! A contrario, achat hier d'un nouveau module via addons mais développé pas un tiers. Encore un problème de non conformité, mais réaction immédiate du développeur, envoi d'une version de test à valider, etc. Très pro. Contrairement à l'équipe PS en général hélas, en tout cas dans mon cas. Je continue à acheter régulièrement des modules, pour moi ou mes clients, mais à chaque fois je me demande dans quelle galère je vais encore me retrouver ! Rodolphe
  9. Bonjour, Décidément, entre mes achats de modules qui ne se passent pas toujours au mieux et ce point important pour moi qui reste sans réponse, je n'ai pas de chance Rodolphe
  10. Manifestement ça ne déchaîne pas les passions ! Rodolphe
  11. Bonjour à tous, Je souhaiterais pouvoir ajouter manuellement le numéro de facture en admin, sur Presta 1.6.1.4. J'utilise en effet mon propre outil de facturation. J'ai pu modifier le back office et le front office pour faire apparaître et pointer le bouton facture vers le bon PDF une fois que le numéro est ajouté manuellement dans la base de données, mais c'est cet ajout que je souhaiterais faire depuis le BO. J'avais modifié ça sans souci sur une 1.2 puis 1.4 mais là je sèche un peu. Et si une solution existe pour l'ensemble des modifications nécessaires y compris celles effectuées pour l'instant directement dans le code par mes soins je suis preneur aussi. Pour simplifier, pouvoir définir un lien type vers les PDF des factures, complété ensuite par le numéro ou la chaîne de caractères saisi(e) en BO. Je ne dois pas être le seul à facturer indépendamment de Presta et à vouloir intégrer ensuite ces factures ??? J'espère être clair Merci d'avance pour vos lumières. Rodolphe
  12. Voici ce qui fonctionne chez moi : Dans classes/Mail.php, j'ai ajouté, juste après /* Send mail */ : $from = Configuration::get('PS_SHOP_EMAIL'); Vu que le replyto est bien géré dorénavant, ce n'est pas gênant si le from est systématiquement l'adresse de contact de la boutique. Et ça permet de contourner le problème, qui est corrigé dans certaines parties de PRestashop mais pas partout. Ce serait plus propre en override, là je l'ai fait en urgence. Rodolphe
  13. Il faut modifier le from et ça peut fonctionner. Je l'avais fait en 1.4, j'espérais que ce soit fixé en 1.6. C'est d'autant plus dommage que le replyto est bien en place, lui. Rodolphe
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More