pubntrash

Salut, J'ai mis en place ce module sans problème (base Presta 1.4). As-tu plus d'info sur le soucis (message d'erreur...) ? Pour info, je l'ai modifié pour éviter le problème du paiement refusé (ou abandonné) qui ne peut être relancé car le no de panier ne change pas. Ce n'est pas grand chose comme modif, mais ça marche du tonnerre ! Dès que le temps me le permettra, je vais encore l'améliorer pour : éviter les refus car Presta n'a pas répondu favorablement dans le temps imparti (Presta valide la commande puis seulement retourne l'accusé réception à CIC, d'où un timeout et dès fois c'est quand même validé par CIC, des fois pas). Dans un 1er temps, j'ai mis une règle dans Thunderbird (client mail) pour mettre ces mails d'anomalie dans un dossier spécial et c'est traité au cas par cas mettre un statut de commande différent selon la qualité de la transaction (exploitation de la valeur status3ds) S'il y en a qui sont intéressés par ces modif, me le dire. 2 conditions : avoir acheté le module Presta (condition sine qua non et c'est bien normal, même si le module n'est pas un modèle du genre) avoir de la patience car je suis toujours charrette :-(

Une simple question de bon sens... Mémoriser le dernier statut de commande dans le header de la commande (ps_orders). C'est peut-être déjà fait dans la 1.5.x (ouais, je mets mes aussi mes souliers dans la cheminée le 24 décembre, mais j'me soigne) Gain : éviter de rechercher le dernier statut dans toutes les requêtes (des fois sur son id, des fois sur la date de création, on est imaginatifs, chez Presta). Coût : minime en terme de charge serveur et en codage. Vous en pensez quoi ?

Salut, A ma connaissance, la seule solution, c'est le PRMP (Prix de Revient Moyen Pondéré), recherche dans les topics sur ce thème. Et le seul moyen de le gérer (Presta 1.4), c'est à la mimine (calculette autorisée). Bon courage.

Je vois que Paypal est très réactif. Merci à François !

Bonsoir, Confronté au problème du remboursement automatique (c'est vraiment du n'importe quoi !), et dans l'urgence, j'ai modifié le fichier Modules/paypal.php pour le désactiver et ça semble bien fonctionner (testé sur site en production 1.4). dans private function _doTotalRefund($id_order) Mettre return false; juste après global $cookie; dans hookCancelProduct($params) Mettre return false; juste après { C'est du brutal mais efficace. Pour la team Presta : suggestion de désactiver cette fonctionnalité en standard, la "gestion" des retours et des avoirs est déjà assez aléatoire comme cela.

La question semble donc être Presta est-il actuellement correctement interfacé avec une gestion commerciale quelconque ? Actuellement = fonctionnalité immédiatement disponible (et pérenne) Correctement = pas de la bidouille, mais un système automatisé supportant les déclinaisons et certaines "originalités" de Presta Je n'ai pas la réponse à cette question. En attendant, on a des "notions" de CA, une "idée" de statistiques, pourquoi ne pas mettre une "approche" de marge brute ? On a tout pour faire, même si c'est avec le dernier prix d'achat ou un PRMP calculé à la main Un PRMP, même approché, comme évoqué plus haut ne semble pas insurmontable vu ce que fait déjà Presta (puisque l'on calcule déjà le CA d'une commande ou sur une période. A voir dès que le temps libre me le permettra Nota : PRMP = Prix de Revient Moyen Pondéré (voir post de Pascal7)

Salut, Pas d'autre solution dans l'immédiat que désactiver cette option.

Merci, c'est sympa, je vais évaluer.

Bonsoir, Si l'option "Rediriger automatiquement vers l'url canonique" ( Préférences -> SEO & URLs), la page fautive apparaît systématiquement sous le nom "/erreur-404" dans le module "Pages introuvables". Une idée SVP (à part désactiver l'option ) ?

Salut, Dans Stats -> Pages introuvables, tu as quoi dans la colonne "Page" ?

Bonjour, Je veux dupliquer l'onglet Commandes du backoffice. Objectif : dériver l'onglet tel qu'il est et l'adapter en affichage et comportement pour en faire une fonction "Préparation de commandes". L'onglet "Commandes" subsiste dans sa forme actuelle. Quelqu'un a déjà réalisé cela ? Merci par avance.

Bonjour, Même problème. Dans les logs serveur, avez-vous des erreurs "suexec policy violation" ? Les problèmes semblent survenir depuis l'incident du 12/10 sur les mutu. Je suis en train de travailler sur le sujet et toute info est la bienvenue !

Salut, Il faut modifier product.tpl et aussi product.js Principe : tant que les attributs (affichés "Choisir") ne sont pas sélectionnés, le bouton "Ajouter au panier" ne s'affiche pas et un message (à la place de "En stock") indique qu'il faut choisir tel et tel attribut. Ca a l'air de marcher et je le post sur ce fil dès que mon serveur dev n'est plus HS. Testé 1.4.4 A+

Bonjour, $product.quantity_all_versions sortait des valeurs étranges d'où des articles "Epuisés" alors qu'ils étaient en stock. dans classes/Product.php, j'ai modifié $row['quantity_all_versions'] = $row['quantity']; $row['quantity'] = Product::getQuantity((int)$row['id_product'], $row['id_product_attribute'], isset($row['cache_is_pack']) ? $row['cache_is_pack'] : NULL); en $row['quantity_all_versions'] = Product::getQuantity((int)$row['id_product']); $row['quantity'] = Product::getQuantity((int)$row['id_product'], $row['id_product_attribute'], isset($row['cache_is_pack']) ? $row['cache_is_pack'] : NULL); Le problème est résolu. Est-ce un problème connu ? Pour info, j'ai migré d'une 1.2.4 à une 1.4.4

www.amballage68.com ne semble plus fonctionner et Raja est très cher !