foulon Posted March 1, 2012 Share Posted March 1, 2012 Bonsoir à tous, voici le problème: je suis sous prestashop 1.4.1.0 Lorsqu'un client passe une commande le paiement est bien effectué mais visible unique par le biais du back office de ma banque, mais dans presta rien n'apparait pas de commande dans le BO et meme dans le compte du client, seul l'inscription du client et le panier qu'il a rempli sont visible. De plus je ne sais pas si c'est lié mais il y a plusieurs bugs du meme genre sur d'autre module, exemple: -Une sous catégorie ne s'affiche pas sur la boutique dans le menu mais et present en partie central - j'ai voulu rentrer de nouveaux attributs de produits, une fois l'attribut enregistré il n'apparait pas ou pas immédiatement mais plusieurs heure après. - Dans les stats, cela ce bloc souvent a un jour antèrieur et cela revient un ou 2 jours après. Je vous remercie d'avance pour vos réponses. Link to comment Share on other sites More sharing options...
GioVanille Posted March 2, 2012 Share Posted March 2, 2012 Bonjour, Avez-vous trouvé une solution à votre problème ? Moi, ça fait des mois que je dois traiter mes ventes payées avec Moneybookers manuellement. En effet, après paiement validé, le client ne reçoit que la confirmation de Moneybookers comme quoi il a bien était débuté mais rien n’apparaît dans son compte client ni sur le BackOffice, comme vous, je ne vois que son panier et son inscription. Et de mon côté je ne reçois qu'un mail de Moneybookers m'indiquant l'arrivée d'argent. Je ne sais pas comment régler ce problème alors qi vous avez une solution, je suis preneur ! Merci à tous ceux qui voudront bien donner un coup de main. Gio Link to comment Share on other sites More sharing options...
hulk Posted March 2, 2012 Share Posted March 2, 2012 Bonjour, J'ai eu des problèmes similaires avec le module CM-CIC P@iement, et après avoir analysé mes tables j'ai remarqué qu'il manque l'historique de la commande dans la table ps_order_history, donc je l'ai ajouté manuellement et elle devient visible en BO. Link to comment Share on other sites More sharing options...
parfimp Posted March 2, 2012 Share Posted March 2, 2012 Nous sommes nombreux à être confrontés à ce problème et de trop nombreux fils ont été (malheureusement) ouverts à ce sujet. La solution que vous proposez Hulk est un moyen curatif non forcément accessible aux non initiés et si je ne m'abuse elle consiste à forcer la validation du panier (en mettant la main dans le cambouis ). Perso cela me rebute par inexpérience et par crainte de faire une bêtise. Je viens de recontacter Paypal qui a passé beaucoup de temps sur le problème et qui affirme que leurs données sont envoyées correctement, que donc c'est au niveau de la réception qu'il doit y avoir un problème, ce que vous semblez confirmer. Néamoins Paypal me propose de vérifier si tous les encodages sont identiques: "le codage charset doit être le même sur 3 point : - sur votre site internet - dans le code de bouton paypal - configuré sur le compte paypal" Et là également, comment vérifier tout cela et je suppose que le pb ne vient pas de là en fait car tout fonctionne correctement par virement bancaire. Cdmnt Parfimp http://www.letivoli.fr/prestashop/ Link to comment Share on other sites More sharing options...
hulk Posted March 2, 2012 Share Posted March 2, 2012 je suis complètement d'accord avec vous parfimp, mais ce que j'ai proposé c'est une solution pour régler le problème de la commande déjà passée en premier puis vérifier la source d'erreur et la rectifié pour être sur de ne pas e reproduire dorénavant. Et en ce qui concerne mon problème avec CM-CIC P@iement, cet erreur ce reproduit une fois sur 10 et je crois que c'est dû aux échange entre la banque et la boutique pour certain transaction vu que la commande passée avec ce module de paiement intervient directement sur le statu de la commande si le paiement et accepté. Link to comment Share on other sites More sharing options...
Jean Francois G Posted March 2, 2012 Share Posted March 2, 2012 Effectivement beaucoup de topics ont été ouverts et souvent ont été abandonnés sans avoir de vrais solutions. Je fais parti des gens qui pensent que cela ne vient pas forcement d'un probleme aléatoire, mais d'un probleme de délai de validation de l'accord du payeur au site prestashop. En gros, si le site tourne à un horaire de petite charge réseau, alors les validations sont la et le BO aussi. MAIS si le site prend la commande en horaire surchargé, alors le client paye, le prestataire envoi l'accord au site sous prestashop, ca mouline, ca mouline, encore, et comme le délai est trop long, PAF ! Le module n'ayant pas reçu l'accord a temps, il arrete d'attendre la réponse et envoi au site l'info que le paiement n'est pas reçu. La commande n'est donc pas validée. Quelqu'un avait résolu ce probleme de temps de réponse entre l'envoi de l'accord et la réception par le module, et n'vait plus eu de problème.. Par contre solution incompréhensible pour un utilisateur lambda.. Il faudrait que les programmeurs de prestashop se penche sur le probleme, de manière a ce que les sites plus lents, ou surchargés, ou en hebergement mutualisés (donc surchargés par défaut) ne rencontre pas ce probleme d'abandon apres une latence. Appel lancé ? ? 2 Link to comment Share on other sites More sharing options...
parfimp Posted March 2, 2012 Share Posted March 2, 2012 C'est une piste Jean François, mais je reste à penser que le problème serait identique avec un virement bancaire or il ne l'est pas Et ce qui m'intrigue au regard de votre hypothèse c'est que 100% des commandes transitant par Paypal sont impactées, c'est quant même étonnant à ce titre. En revanche 100% d'accord pour dire que la charge en revient aux programmateurs mais nous sommes en open source, ce qui peut se révéler être un handicap au niveau des délais J'aimerais assez explorer votre méthode, Hulk, car il doit être possible en l'appliquant (dites moi si je me trompe) de valider la commande et ainsi d'assurer le bon fonctionnement en aval ( édition et numérotation des factures, commandes enregistrée, etc ...). Il faudrait nous écrire un tutoriel, Hulk Au risque de me répéter, le service Prestashop m'a demandé d'ouvrir un ticket à 149,-€HT pour se pencher sur le problème...largement au dessus de mes moyens d'une part et j'ai, d'autre part, un peu de mal à comprendre pourquoi un défaut lié à la conception du produit et auquel de nombreux utilisateur sont confrontés, devrait m'être facturé . Link to comment Share on other sites More sharing options...
hulk Posted March 2, 2012 Share Posted March 2, 2012 J'ai fait une petite analyse pour ce module et j'ai remarqué qu'il y a un fichier log contenant les numéros des commandes avec les détails. Ce fichier txt est généré par le module Fia-net Fraud qui contrôle les paiements par ce module. je voulais savoir si le module Fia-net bloque l'accusé de réception du module CM-CIC p@iement qui retourne l'état du paiement (accepté ou erreur paiment) et par suit de créer l'historique de la commande ou non? Link to comment Share on other sites More sharing options...
parfimp Posted March 2, 2012 Share Posted March 2, 2012 J'ai fait un tour dans mas BDD ... voici ce que j'ai trouvé, une liste d'erreurs, cela peut aider peut-être (pour moi c'est du chinois): $cfg['Servers'][$i]['pmadb'] ... en erreur [ Documentation ] $cfg['Servers'][$i]['relation'] ... en erreur [ Documentation ] Fonctions relationnelles: désactivé $cfg['Servers'][$i]['table_info'] ... en erreur [ Documentation ] Affichage infobulle: désactivé $cfg['Servers'][$i]['table_coords'] ... en erreur [ Documentation ] $cfg['Servers'][$i]['pdf_pages'] ... en erreur [ Documentation ] Génération de schémas en PDF: désactivé $cfg['Servers'][$i]['column_info'] ... en erreur [ Documentation ] Commentaires de colonnes: désactivé Transformation: désactivé $cfg['Servers'][$i]['bookmarktable'] ... en erreur [ Documentation ] Requêtes en signets: désactivé $cfg['Servers'][$i]['history'] ... en erreur [ Documentation ] Historique SQL: désactivé $cfg['Servers'][$i]['designer_coords'] ... en erreur [ Documentation ] Concepteur: désactivé $cfg['Servers'][$i]['tracking'] ... en erreur [ Documentation ] Suivi: désactivé Link to comment Share on other sites More sharing options...
foulon Posted March 3, 2012 Author Share Posted March 3, 2012 J'ai de plus en plus de bug, ce matin on a voulu rentrer de nouveau produit, ils n’apparaissent pas sur la boutique ou alors que dans certaine catégorie??????? Je suis hébergé chez ovh en mutualisé. Un ami avait regardé dans les tables et il n'avait rien trouvé sur les commandes non validé par prestashop, elles sont inexistante. Link to comment Share on other sites More sharing options...
parfimp Posted March 3, 2012 Share Posted March 3, 2012 J'ai de plus en plus de bug, ce matin on a voulu rentrer de nouveau produit, ils n’apparaissent pas sur la boutique ou alors que dans certaine catégorie??????? Je suis hébergé chez ovh en mutualisé. Un ami avait regardé dans les tables et il n'avait rien trouvé sur les commandes non validé par prestashop, elles sont inexistante. Nous restons, hélas, sans réponse satisfaisante pour le moment. Parfimp version 1.4.7.0 - module Paypal 2.85 - Newthème 1.5 - hébergeur: Online.net Link to comment Share on other sites More sharing options...
hulk Posted March 7, 2012 Share Posted March 7, 2012 En gros, si le site tourne à un horaire de petite charge réseau, alors les validations sont la et le BO aussi. MAIS si le site prend la commande en horaire surchargé, alors le client paye, le prestataire envoi l'accord au site sous prestashop, ca mouline, ca mouline, encore, et comme le délai est trop long, PAF ! Le module n'ayant pas reçu l'accord a temps, il arrete d'attendre la réponse et envoi au site l'info que le paiement n'est pas reçu. La commande n'est donc pas validée. Quelqu'un avait résolu ce probleme de temps de réponse entre l'envoi de l'accord et la réception par le module, et n'vait plus eu de problème.. Par contre solution incompréhensible pour un utilisateur lambda.. J'ai contacter le responsable des modules de paiement CIC-P@iement et il m'ont dit aussi de cette hypothèse. Est ce qu'il y a un moyen d'augmenter le délai ? cordialement 2 Link to comment Share on other sites More sharing options...
daftfunk Posted May 15, 2012 Share Posted May 15, 2012 Je viens un peu aux nouvelles... pour ce delai ... aucune solution ? Link to comment Share on other sites More sharing options...
xabe20 Posted June 6, 2012 Share Posted June 6, 2012 Bonjour, je vois que le sujet préoccupe beaucoup d'usager. Je connais le meme problème que Hulk. J'utilise PS en version 1.4.6.2 avec le module de paiment CM CIC avec aucun autre moyen de paiement. Tous les paiements fonctionnent très bien mais il se passe strictement rien en BO. Le client paye, recoit la validation de la banque et c'est tout. Aucun mouvement en BO, le panier du client reste bloqué et aucune commande est créée. Et ceci dans 100% des cas !! Je voudrais donc savoir si depuis mars quelqu'un avait une solution à ce probleme ? Et si ce n'est pas le cas, si il y avait un module (gratuit) pour convertir manuellement les paniers des clients en commande meme si c'est solution me semble du bricolage ? Merci d'avance Link to comment Share on other sites More sharing options...
Le-cathare Posted June 6, 2012 Share Posted June 6, 2012 Bonjour J'ai eu le meme pb avec Buyster. comme personne ma trouver une solution j'ai pour le moment désactivé Buyster faute de solutions . Mais avec Buyster j'ai pas le nom du client donc impossible de savoir qui à payer Deplus j'ai aucun panier qui correspondais à ce paiement. Cela fais 4mois et aucun client c'est manifestait . Bizzare Link to comment Share on other sites More sharing options...
xabe20 Posted June 6, 2012 Share Posted June 6, 2012 (edited) Je pense avoir trouvé une ébauche de solution. Dans la doc du module CM CIC P@iement j'ai trouvé ceci : Que faire lorsque je rencontre une erreur "CGI2 not OK" ? Vous devez tout d'abord effectuer les vérifications de base suivantes : L'adresse de "Retour" au site commerçant a-t-elle été fournie à notre équipe technique ? Cette adresse est-elle accessible depuis l'extérieur ? L'adresse de retour est-elle accessible sur le port 80 (http) ou 443 (https) ? Le traitement de l'appel entre votre serveur et notre serveur est-il supérieur à 30 secondes ? N'avez-vous pas fait une redirection à la réception du code retour paiement ? Edited June 6, 2012 by xabe20 (see edit history) Link to comment Share on other sites More sharing options...
LeGastronome Posted November 20, 2012 Share Posted November 20, 2012 Moi j'ai le même souci, avec moneybookers, quelques transactions ne passent pas par le BO je dois valider de manière manuelle ! Presta 1.5.2 et dernière version du Moneybookers Link to comment Share on other sites More sharing options...
Grouik Posted January 10, 2013 Share Posted January 10, 2013 Bonjour, Moi aussi je suis impacté par ce problème. De façon aléatoire une ou 2 commandes sur 20 ne sont pas visibles dans le BO. Je suspecte également les temps de transmission. J'aimerai savoir si tous les gens impactés sont sur un serveur mutualisé ? Je pense que vu le nombre de candidats et le peu de réponses apportées nous pouvons écrire un rapport de bug. Merci à vous, ++ Link to comment Share on other sites More sharing options...
Thierry Création Posted January 31, 2013 Share Posted January 31, 2013 (edited) Bonjour, Nous rencontrons le même problemes sur 2 boutiques , l'une en 1.3.1 et l'autre en 1.4.7 ... Le probleme se pose avec le module systempay ET le module cheque Aléatoirement certaines commandes sont enregistrées sur la BDD mais aucune trace dans l'admin du site. L'hébergement est un VPS chez OVH ... (on ne note pas de surcharge serveur au moment ou une commande saute) Si quelqu'un à la moindre idée pour solutionner le problème , je suis prenneur. Bonne journée, Thierry PS : les problèmes sont apparus 3 semaines après une migration des boutiques sur un nouvel hébergement Edited January 31, 2013 by Thierry Création (see edit history) Link to comment Share on other sites More sharing options...
Missy Posted February 14, 2013 Share Posted February 14, 2013 Bonjour, j'ai le même souci depuis plusieurs jours, une solution a t-elle été trouvé ? Parce que je crise, comme pas mal de personne apparemment. je suis hébergée en mutualisé chez online.net et c'est avec paypal v.2.8.6 ( Prestashop 1.4.7) que j'ai des problèmes. Les commandes n'apparaissent pas dans le BO Après tout ce que j'ai pu lire sur le net, j'ai l'impression que la seule solution serait de fuir online.net et de se tourner vers un hébergement dédié. Qu'en pensez-vous ? Link to comment Share on other sites More sharing options...
ohoho Posted February 25, 2013 Share Posted February 25, 2013 Salut, Même problème, quasiment 1 sur 20 passe au travers, ce phénomène est de plus en plus récurrent, que ce soit sur les paiements chèques, CB avec ATOS ou Paypal, c'est très emmerd.... !!! Boutique : 1.4.7 Hébergement : serveur dédié ovh Link to comment Share on other sites More sharing options...
Thierry Création Posted February 25, 2013 Share Posted February 25, 2013 Bonjour, Après une multitude de test j'ai de plus en plus l'impression que le problème est lié à l'hébergement ? on parle de ovh (mutualisé ou vps dans mon cas) , online.net ... Link to comment Share on other sites More sharing options...
Missy Posted February 25, 2013 Share Posted February 25, 2013 Bonjour, J'ai réglé ce problème aujourd'hui en changeant d'hébergeur g choisi phpnet.org offre premium standart : ici Je suis trop contente. Prestashop 1.4.7 / Paypal v.2.8.6 et j'étais chez online.net Link to comment Share on other sites More sharing options...
ohoho Posted February 27, 2013 Share Posted February 27, 2013 ça ne vient pas de l'hébergeur je pense mais plutôt d'un module tiers qui génère une erreur, j'utilise OVH depuis des années en serveurs dédiés, je n'ai jamais eu ce problème Link to comment Share on other sites More sharing options...
Missy Posted February 27, 2013 Share Posted February 27, 2013 Bonjour, Vous pensez que cela ne vient pas de l'hébergeur, mais dans mon cas si (je dis bien dans mon cas) J'ai déjà suivi la piste d'un module qui ferai planter paypal mais ça n'a rien donné pour moi, j'ai tout essayé jusqu'à ce que je change d'hébergeur. J'était chez online.net. (Le temps de latence empêchait paypal d'envoyer la confirmation de paiement à temps sur mon BO ) Link to comment Share on other sites More sharing options...
webbax Posted February 27, 2013 Share Posted February 27, 2013 Bonjour, Quand le symptôme suivant est observé "paiement effectué sur l'institut financier, mais commande absente dans le back-office" cela signifie en principe que le script de validation de votre module de paiement n'a pas pu être appelé corrrectement. Pour trouver la cause il faut s'assurer des 2 points suivants : 1) que le client est bien redirigé vers la boutique lorsque la transaction est terminée 2) que le le script de validation de la commande ne plante pas Il faut noter aussi que certaines configurations mail, peuvent faire planter l'envoi de la confirmation de commande et du coup stopper le traitement de la validation. Exemple avec Infomaniak (voir point N° 5 http://www.webbax.ch/2011/11/16/installer-prestashop-chez-infomaniak/) Link to comment Share on other sites More sharing options...
Thierry Création Posted February 27, 2013 Share Posted February 27, 2013 Bonsoir Webbax, Dans mon cas, le problème est constaté sur un vps ovh et avec des solutions de paiements qui ne font pas d'appels d'urls exterieur ... comme par exemple le module chèque ou celui de virement bancaire de prestashop. J'y ai pensé aussi un problème lié aux emails Link to comment Share on other sites More sharing options...
BIG PRINT Posted June 4, 2013 Share Posted June 4, 2013 Bonjour, pour moi le pb venait du module de commentaires YOTPO!!!! après l'avoir désinstallé ça marche de nouveau très bien!! Presta 1.4.8.3 Link to comment Share on other sites More sharing options...
alain56 Posted June 6, 2013 Share Posted June 6, 2013 (edited) Bonjour, Pour ma part, cela vient de se produire sur ma boutique PS v1.4.9, OVH mutu. Seul les paiements par CB via le module Atos OFFICIEL (acheté sur Prestashop Addons + Installation par leur soin) sont acceptés sur ma boutique, donc ce n'est pas lié au moyen de paiement. Par contre, à priori le client, après être revenu sur la boutique après la validation de sa commande, n'avait pas son panier vidé ?! L'article commandé était encore dedans ?! Comme s'il n'était jamais passé par la case "serveur de la banque" (Mercanet de chez BNP Paribas pour ma part).... Et par rapport à ce problème : Comment créer la commande dans la BdD ? (Car je ne ferai pas de MAJ vers la 1.5...) Quelles sont les tables à modifier ? Et dans quel ordre car pb avec les clés primaires/étranégères ? (Et quid du champ secure_key dans la table orders ?) Merci beaucoup Edited June 6, 2013 by alain56 (see edit history) Link to comment Share on other sites More sharing options...
Jimmy Posted June 7, 2013 Share Posted June 7, 2013 Bonjour, Après une multitude de test j'ai de plus en plus l'impression que le problème est lié à l'hébergement ? on parle de ovh (mutualisé ou vps dans mon cas) , online.net ... si cela peut te rassurer, j'ai aussi ce problème sur un serveur dédié. c'est arrivé une dizaine de fois sur un total de plus de 1500 commandes. Link to comment Share on other sites More sharing options...
alain56 Posted June 7, 2013 Share Posted June 7, 2013 (edited) Up : donc pas de réelle solution apparement...Juste espérer que le %age soit le plus bas possible... Sinon, pour les versions avant la 1.5, c'est plutôt galère de créer une commande dans la base... J'ai réussi en allant dans les tables - ordeers - orders_detail - orders_history Mais le problème surgit lorsque je veux changer le statut de la commande dans le BO : il met le msg d'erreur suivant : Fatal error (Order -> secure_key = -1) Donc comment gérer ce champ secure_key dans la table orders ? (Car sinon je suis obligé d'aller de nouveau dans la BdD pour ajouter une ligne dans order-history...et c'est très très chiant ) Merci bcp Edited June 7, 2013 by alain56 (see edit history) Link to comment Share on other sites More sharing options...
Julie S. Posted June 9, 2013 Share Posted June 9, 2013 bonjour, je déplace votre sujet dans la section appropriée. Le forum "discussion générale" traite de sujets généraux (quel serveur choisir ? comment devenir e-commerçant ?) qui n'entrent pas dans le cadre de l'utilisation/configuration/développement/adaptation de prestashop... Discussion généraleTout ce qui n'entre pas dans l'une des catégories ci-dessous. Merci Je fais remonter l'info. à l'équipe Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted June 10, 2013 Share Posted June 10, 2013 Bonjour, Il peut y avoir autant de raisons à ce problème de commande pas validée dans le BO que d'utilisateurs qui en ont parlé dans ce sujet. Cela peut provenir : - de l'hébergement, - du module de paiement, - d'un développement spécifique, - mais aussi de n'importe quel autre module greffé sur un hook appelé pendant la validation de commande... Dans ce cas, je conseille plutôt un appel au support de PrestaShop (01.40.18.30.04) Link to comment Share on other sites More sharing options...
ohoho Posted June 10, 2013 Share Posted June 10, 2013 Dans ce cas, je conseille plutôt un appel au support de PrestaShop (01.40.18.30.04) :lol: > Link to comment Share on other sites More sharing options...
Xavier du Tertre Posted June 10, 2013 Share Posted June 10, 2013 Bien entendu, vous pouvez aussi appeler ohoho, il résoudra votre problème gratuitement et en 30 secondes 1 Link to comment Share on other sites More sharing options...
ohoho Posted June 10, 2013 Share Posted June 10, 2013 haha Link to comment Share on other sites More sharing options...
iorek Posted June 10, 2013 Share Posted June 10, 2013 si vous me permettez, je vais vous dire comment payzen traite le problème de paiements sans commande: La notification à la fin du paiement est faite via un appel peer 2 peer. (Url serveur dans le jargon de Payzen et/ou Systempay). Cet appel lorsqu'il fonctionne permet de transformer le panier en commande en déroulant tout le processus de Prestashop. Il arrive que cette notification ne fonctionne pas. Pour de multiples raisons: En ce moment bcp de HTML 408 chez OVH des HTML 503 car le temps de réponse est trop long ou par exemple parce qu'il y a un problème de peering entre les opérateurs internet (ceux de la plateforme de paiement et ceux de votre hébergeur. C'est bien plus courant qu'on ne pense) des changements de serveur sans penser à la propagation des dns (pensez dans ce cas à coder l'adresse ip) des problèmes applicatifs temporaires dans la solution e-commerce (serveur indisponible) des modifications de votre architecture (firewall, htaccess, redirection impromptue ..) qui empêche la notification peer2peer. En résumé le monde parfait n'existe pas et vous ne le trouverez pas. il faut donc des palliatifs pour être informé, si possible en temps réel. Car rien de pire que d'avoir un client au téléphone qui a payé mais n'a pas de commande dans votre site. Donc comme le monde n'est pas parfait, Payzen a prévu de vous notifier par mail en temps réel pour chaque échec de notification, empêchant la transformation de votre panier en commande. Que faire à ce stade: D'abord définir dans Payzen qui doit recevoir la notification d'échec: service technique, personne compétente, .. Définir si payzen doit tenter de rejouer la notification (jusqu'à 3 fois. si le problème est temporaire, cela peut-être intéressant) et ensuite, si cela ne suffit pas, vous pouvez vous connecter au back-office de Systempay et rejouer la notification peer2peer qui va créer la commande (sans limite de temps) L'important, vous l'aurez compris, c'est la transparence, car le monde parfait n'existe pas. Et si vous vous plaignez d'avoir autant de paniers payés mais non transformés en commande, c'est que vous n'êtes pas prévenus en temps réel d'un échec de connexion peer2peer. Payzen a prévu cela dès sa conception. L'historique des événements d'un paiement vous donne: l'heure de la connexion peer2peer le temps de traitement l'erreur HTML si échec Les messages d'erreur lus sur le socket (qui donnent souvent la solution en faisant une recherche sur internet) Payzen ne résout pas les problèmes d'environnement technique, mais vous aide à les appréhender. Link to comment Share on other sites More sharing options...
Thor007 Posted July 19, 2013 Share Posted July 19, 2013 Bonjour, il me semble que ce sujet a déjà été résolu il y a quelques mois, de mémoire, dans les grandes lignes il s'agissait de la version du système qui envoi les mails automatiquement qui est obselète depuis quelques années... Il lui arrive de bugguer et quand il plante il bloque l'édition de la commande en back office... Link to comment Share on other sites More sharing options...
ITIS-Commerce.com Posted August 27, 2013 Share Posted August 27, 2013 Bonjour Il peut y avoir une autre solution aussi : il ne faut pas que le fichier validation.php soit en chmod 777 mais 755. Bonne journée! Link to comment Share on other sites More sharing options...
devlogi Posted September 26, 2013 Share Posted September 26, 2013 (edited) Bonjour, Je rencontre le même probléme sur une boutique 1.5.4. Je crois que le problème se pose avec les modules : PayPal , Atos Spips et chèque. Aléatoirement certaines commandes ne s'enregistrent pas dans la base de données, seul l'inscription du client et le panier qu'il a rempli sont visible sur le backoffice. le client est bien redirigé vers la boutique aprés le paiement et le script de validation de la commande est fonctionnel. Je sais pas d'ou vient le probleme ,si quelqu'un à la moindre idée pour le résoudre , je suis prenneur. Merci Edited September 26, 2013 by devlogi (see edit history) Link to comment Share on other sites More sharing options...
bnjii Posted September 27, 2013 Share Posted September 27, 2013 Bonjour à tous, je me suis arraché les cheveux sur ce problème pendant des semaines et hier, enfin résolu.. Et hop un petit 1 rouge qui reapparait joyeusement à chaque commande Sur presta 1.5.5.0 et Paypal 3.6 rien à faire.. je suis passé à une version antérieur de paypal, télécharger backward compatibility, j'ai désactivé les notifications IPN et bingo.. Espérant que ça pourra aider.. Link to comment Share on other sites More sharing options...
BIG PRINT Posted September 27, 2013 Share Posted September 27, 2013 Pour moi le pb venais du module YOTPO. Depuis la dernière mise à jour plus de pb!!! Link to comment Share on other sites More sharing options...
Soyons Solidaire Posted September 27, 2013 Share Posted September 27, 2013 Bonjour à tous J'ai eu le même problème ça venait de mon hébergeur je suis d'accord avec Missye. Amitiés Link to comment Share on other sites More sharing options...
pbf Posted December 10, 2013 Share Posted December 10, 2013 (edited) Bonjour à tous, je me suis arraché les cheveux sur ce problème pendant des semaines et hier, enfin résolu.. Et hop un petit 1 rouge qui reapparait joyeusement à chaque commande Sur presta 1.5.5.0 et Paypal 3.6 rien à faire.. je suis passé à une version antérieur de paypal, télécharger backward compatibility, j'ai désactivé les notifications IPN et bingo.. Espérant que ça pourra aider.. Merci ,après avoir essayé plusieurs solutions j'ai récupérer un module Paypal plus ancien (V 3.5.8) effectivement sa fonctionne. Le site en question est héberger chez OVH et est sous Prestashop 1.5.6.1. Edited December 10, 2013 by pbf (see edit history) Link to comment Share on other sites More sharing options...
saucis Posted January 14, 2014 Share Posted January 14, 2014 Bonjour, je rencontre le même problème sur une boutique (en version 1.5.6). Toutes les commandes payées depuis le module CM-CIC ne sont pas visibles, contrairement à celles payées par chèque et Paypal. Le problème est apparu il y 3-4 jours alors qu'avant cela, il n'y avait pas le moindre problème. Il n'y a eu aucune mise à jour ou modification de fichiers faite. D'après le support du Crédit Mutuel, cela vient de l'interface retour, je ne vois pas ce que ça peut être. Quelqu'un aurait il une idée? Merci beaucoup 1 Link to comment Share on other sites More sharing options...
iorek Posted January 14, 2014 Share Posted January 14, 2014 Le chèque n'a pas d'interface retour et Paypal via une API REST n'en a pas besoin non plus. Donc pas anormal qu'il y ait une différence. On ne peut pas comparer les 3 qui s'appuient tous les 3 sur 3 mécanismes différents. Il vous chercher du côté de ce qu'on appelle l'IPN (instant payment notification) du module CIC. Il y a eu forcément une évolution de votre côté si cela fonctionnait: changement de DNS, htaccess, .. Analysez les logs sur l'url peer2peer entre le CIC et votre PS. Link to comment Share on other sites More sharing options...
saucis Posted January 15, 2014 Share Posted January 15, 2014 Il vous chercher du côté de ce qu'on appelle l'IPN (instant payment notification) du module CIC. De quoi s'agit il exactement? Dans le BO, dans la rubrique Paramètres avancés/Log, j'ai ces messages : The file /data/web/vhostprod/order-confirmation.php is deprecated and will be removed in the next major version. (en date d'aujourd'hui) The function getOrderShippingCost (Line 252) is deprecated and will be removed in the next major version. (en date du 7 janvier) Le problème est apparu le 9 ou le 10. Est ce que ça peut avoir un rapport? Link to comment Share on other sites More sharing options...
valade Posted September 18, 2014 Share Posted September 18, 2014 bonjour le même problème avec Atos des pistes nouvelles depuis ? Link to comment Share on other sites More sharing options...
Autourdupc Posted January 8, 2015 Share Posted January 8, 2015 Bonjour. PS1.6.0.9.J'ai un soucis qui ressemble... Un client a ouvert un compte et passé sa commande... Tout a bien été.Il est revenu 1 semaine plus tard et a repassé une commande identique.Sa commande n'apparaît pas dans le BO, mais uniquement si je regarde son compte de près.J'ai bien changé l'état de "payé" en état "en cours de livraison" mais quand je reviens l'état est revenu en "payé". Cela me fait peur si j'ai d'autres clients qui reviennent... Je ne vais pas voir leurs commandes ! A vous lire.Laurent. Link to comment Share on other sites More sharing options...
kokodoko Posted February 5, 2015 Share Posted February 5, 2015 (edited) Problème réglé (voir post #55) qui n'a rien a voir avec Prestashop mais du a une erreur de DEV... Bonjour à tous, en effet un nouveau bug 2015 sur prestashop 1.6.0.9 avec tous les modules mis a jour: depuis début 2015, plusieurs commandes passées par des clients n'apparaissent pas en BO: 1) Le client passe sa commande et paye par chèque (ou virement). 2) Il reçoit un mail automatique de confirmation de commande avec un numéro de commande faux ! ce numéro reprend un ancien numéro au hasard ancien de plusieurs mois ! 3) Il effectue son paiement... jusque là, nous n'avons aucune connaissance de l'existence de cette commande ni de ce client ! 4) Le paiement arrive, recherche dans le BO: le client n'existe pas (nouveau client), son numéro de commande ne correspond pas, sa commande n'existe pas. C'est aléatoire, mais représente maintenant 1% a 2% des paiements, inutile de vous dire les énormes problèmes que cela pose. Phénomène étrange apparu début 2015, inexistant en 2014... Any idea about it ??? Le fait que nous soyons 2 déjà à rencontrer ce problème démontre qu'il y a une faille dans prestashop, mais laquelle... pour info, Site hébergé en VPS chez PlanetHoster Edited February 6, 2015 by kokodoko (see edit history) Link to comment Share on other sites More sharing options...
Autourdupc Posted February 6, 2015 Share Posted February 6, 2015 Bonjour. Je me suis aperçu que j'ai un pb de rafraîchissement avec le cache des navigateurs. Il faut très souvent vider le cache ou forcer un Alt-F5, et bien sûr cliquer sur l'icône de rafraîchissement. Je n'avais pas ces soucis en 2014. Ce pb de rafraîchissement impactte aussi la création/modification de produits. Je suis sous PS 1.6.0.9 (ma migration vers 1.6.0.11 ayant totalement cassé le site) Laurent Link to comment Share on other sites More sharing options...
Eolia Posted February 6, 2015 Share Posted February 6, 2015 Un conseil: Arrêtez de faire toutes les mises à jour de module, sauf si c'est pour un problème de sécurité. Surtout pour les modules de paiement. En effet ceux-ci permettent la validation de la commande en retour. Si le moindre problème intervient, le retour sera en erreur et Prestashop n'aura pas les données lui permettant de créer ou remplir la commande correspondante. Il y a un problème avec ces mises à jour. Il est anormal d'en avoir autant (3 à 4 par jour). Ces modules sont soit disant multi-plateformes (1.3 à 1.6) ce qui est faux et fait planter les boutiques. Donc, si votre boutique fonctionne correctement, n'installez pas de mise à jour sans savoir pourquoi (regardez les changelogs, comparez les fichiers, faites un test en local, etc...) Dans "Administration" -> "Préférences" désactivez : Vérifier automatiquement les mises à jour de modules C'est dommage à dire, mais on ne peut plus faire confiance au contenu de ses fichiers. En attendant des jours meilleurs... Link to comment Share on other sites More sharing options...
saucis Posted February 6, 2015 Share Posted February 6, 2015 Pour ma part, le problème venait du module de paiement qui n'était pas à jour/compatible avec la nouvelle version mise à jour de Prestashop. Après la mise à jour de ce module, plus de problème Link to comment Share on other sites More sharing options...
Eolia Posted February 6, 2015 Share Posted February 6, 2015 Pour ma part, le problème venait du module de paiement qui n'était pas à jour/compatible avec la nouvelle version mise à jour de Prestashop. Après la mise à jour de ce module, plus de problème Là, on est d'accord. Si vous mettez à jour votre version de Presta, vous devez mettre à jour vos modules (logique en même temps, un module développé à une date X ne peut pas savoir quelles modifications vont être effectuées dans le core quelques temps plus tard ^^) Link to comment Share on other sites More sharing options...
kokodoko Posted February 6, 2015 Share Posted February 6, 2015 Hou la la la , grosse méprise pour ma part, Prestashop n''est pas en cause! Une mauvaise redirection de DNSd'un nom de domaine utilisé que pour le dev envoyait mes clients sur le site de développement... ou ces derniers passaient commande, croyant être sur le site en prod... Bref mon problème était du à une erreur de notre part... Désolé auprès de la communauté pour mon post précédent ! Link to comment Share on other sites More sharing options...
Chrisjj34 Posted March 26, 2015 Share Posted March 26, 2015 Bonjour à tous, je remets les pieds dans le plat... Comment résoudre ce problème réccurent !? J'ai acheté le module de paiement CIC, fait toutes les démarches pour l'ouverture auprès du CIC, transmis l'adresse de validation de mon site http://www.mondomaine.fr/modules/cmcicpaiement/validation.php.Reçu leur mail de confirmation. Les paiements test fonctionnent correctement, ils sont bien enregistrés sur le CIC. Pourtant quand le paiement est validé, le client revient sur mon site à la page historique des commandes et le panier ne s'est pas vidé, la commande ne s'est pas validée dans le BO pourtant le client a bien reçu un mail lui confirmant le paiement via CIC (mais pas de mail de confirmation de commande de la boutique). Si quelqu'un a enfin LA solution, ça fait plusieurs jours que je fais tous les forums, je n'en peux plus, PLEASE HELP J'utilise prestashop 1.6.0.11 URL de retour Ok : http://www.mondomaine.fr/index.php?controller=order-confirmationURL de retour Ko : http://www.mondomaine.fr/index.php?controller=order Merci pour votre aide Link to comment Share on other sites More sharing options...
lechapelier Posted April 26, 2015 Share Posted April 26, 2015 Bonjour, Essayer en désactivant le module de paiement paypal et ebay. Videz le cache presta et navigateur. Cordialement Link to comment Share on other sites More sharing options...
Eolia Posted April 27, 2015 Share Posted April 27, 2015 Le problème peut venir de 2 choses: - Mauvaise écriture des cookies - Un autre module accroché au header plante et du coup empêche l'exécution des autres (dont la gestion du retour paiement) Regardez donc dans modules -> positions, ceux qui sont accrochés au header et/ou retour/validation de commande (actionValidateOrder) et décrochez ceux qui ne vous paraissent pas utiles. Certains modules sont mal codés et ne génèrent aucun retour en cas d'erreur, ce qui bloque l'éxécution des suivants Link to comment Share on other sites More sharing options...
Melliarine Posted September 2, 2015 Share Posted September 2, 2015 Bonjour, Je rencontre ce genre de problème également. Je gère deux boutiques, une pour moi, et une pour mon copain. La mienne fonctionne très bien, est hébergée chez PHPNET, ma version de Prestashop est 1.6.0.5, tous mes modules sont à jour et je ne rencontre aucun problème. Celle de mon copain est aussi chez PHPNET, mais utilise Paypal USA (la mienne utilise Paypal Europe). Au début, seul les commandes passées par les clients d'un groupe spécifique n'étaient pas validées automatiquement. J'ai mis à jour la boutique sur la version 1.6.0.14, ce qui a réglé notamment un bug d'affichage des pages que j'avais, mais le problème des commandes n'est pas résolu. Les commandes en euros sont validées automatiquement mais affichent "en attente du paiement par Paypal", tandis que les commandes dans une autre devise ne se valident pas du tout. Ce qui est curieux c'est que l'euro n'est même pas la devise par défaut de la boutique. Bref,j'ai beau chercher je ne trouve pas comment régler ce bug. Quelqu'un aurait une idée? Link to comment Share on other sites More sharing options...
dkbane Posted April 14, 2016 Share Posted April 14, 2016 Bonjour, J'ai le même problème, une commande fantôme et impossible de trouver une trace avec le client, les produits ou autre. Je vais devoir rembourser la cliente via mon e-transactions, sauf si vous avez une solution pour retrouver cette commande ! Link to comment Share on other sites More sharing options...
Wibleo Posted June 15, 2016 Share Posted June 15, 2016 Bonjour à toutes et à tous, Je rencontre un problème sur l'affichage de la facture depuis le compte client. La commande passe normalement, les e-mail avec la facture en PJ s'envoi correctement, la commande et la facture sont bien présentes en BO. Mais en revanche, les facture ne sont plus présentes sur le compte des clients en FO. Est-ce que quelqu'un a rencontré un problème similaire ? Sachant que je viens juste de m'en apercevoir car je ne vais pas souvent sur cette partie du FO. Je suis sous prestashop 1.6.1.4 Merci d'avance et très bonne journée connectée Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now