croqueurdos

Bonjour, J'ai un problème très similaire, à savoir que je me retrouve d'un coup avec pour ainsi dire toutes mes pages avec ce tag http x-robots-tag en noindex Idem, cela est apparu d'un coup, je ne vois pas ce qui pourrait avoir généré cela...... Comment aviez-vous solutionné ? D'avance merci.

Salut, Je pensais mon problème résolu après avoir créer / remplacé mon transporteur pro problématique, mais le bug resurgit ces jours-ci... Je vais tenter à nouveau de recréer un nouveau transporteur... J'ai sinon, d'autres bugs qui sont revenus également, y aurait-il un lien ... ? En l'occurrence, des demandes clients établies via le formulaire du site qui nous sont délivrées mais notifiées avec l'adresse email d'un autre client.......donc impossible de répondre au bon demandeur. Et j'ai également parfois des commandes dédoublées/splittées, le matériel commandé est splitté en deux commandes comportant le même numéro.......J'ai eu ça par le passé, il s'agissait alors de produit qui étaient bridés sur un transporteur, la commande était donc 'normalement' splittée, mais lorsque cela se produit maintenant, c'est avec des produits non bridés sur certains transporteurs. Bref, encore un problème lié aux transporteurs, d'où mon interrogation sur cette étrange concomitance... Je présume éventuellement un problème de cache, mais comment traquer cela...

C'est une piste de réflexion... Dans mon cas, et du fait de la typologie de produits vendus, il y a typiquement concordance entre franco et transporteur disponible, dans le sens où cela arrive pour des panier dont le poids ne peut être pris en charge que par ce transporteur 'messagerie pro', mais qui n'est (n'était) alors pas proposé. Autre piste : j'avais le problème notamment pour les paniers issus de devis (solution Roja45 en l'occurrence). Les paniers issus des devis générés par ce module ne se voyaient pas proposer de transporteur, par contre en vidant le panier et en ajoutant les même produits et qtés depuis les pages produits, pas de pb... Bref, dans tous les cas, je pense (j'espère...) avoir résolu, au moins temporairement, ce problème en ayant recréé ce transporteur problématique. J'aviserai au prochain cas, si toutefois cela devait arriver...

Salut tous @Mediacom87 J'ai vérifié également, tout est bien configuré... @Natc77 J'ai un module "Frais de port par code postaux", pour gérer la Corse et les DOM notamment, aurais-tu le même module ? Il est vrai que je n'ai jamais tenté de le désactiver pour ces cas particuliers... EDIT : je précise également que le site est "derrière" Cloudflare... EDIT 2 : pour préciser encore un peu, j'utilise trois transporteurs (DPD, Colissimo et un pro messagerie). Seul le transporteur pro pose problème. Je viens de faire un essai tout bête : recréer mon transporteur problématique. J'ai l'impression, avec mes qques essais, que cela serait fonctionnel. MAIS...on a ce matin, comme de juste, un nouveau cas : cette fois, c'était ce transporteur problématique seul qui était proposé, et les autres (DPD et Colissimo) qui ne l'étaient pas... J'ai remarqué une seconde chose : je me suis aperçu que les id des transporteurs s'incrémentent 'régulièrement' (probablement à chaque fois que je procède à une modif du-dit transporteur...). Est-ce que cela pourrait être une piste ?

@PierreFKT Merci pour ta réponse rapide. " Pour l'instant le bug n'est pas réapparu ou ne m'a pas été signalé." C'est ma crainte : combien ai-je de clients qui nous appelle pour ce problème VS combien de client qui n'appellent pas ... ? D'ailleurs, pour l'anecdote, on vient de faire quasi deux semaines à un rythme particulièrement intense : grosse augmentation du rythme de manière 'brutale' (sur deux jours, on a fait genre +30/40% de ventes en plus ; sur une journée ou deux, why not mais sur deux semaines...) puis grosse baisse tout aussi brutale (du jour au lendemain...) pour retomber à notre rythme habituel...Certes, nous sommes sur une fin de mois (et comme toutes les fins de mois, il y a baisse de régime que j'appelle "syndrome de la fin de mois" ^^ ), mais quand même. J'ai justement fait le lien avec ce potentiel problème de transporteur qui aurait pu disparaitre pendant cette période...Bref. Pour revenir au sujet, je ne me sens pas de migrer vers une 1.7.8.8, je n'aurais pas les compétences. Bien que la migration 1.5 -> 1.7.6.8 a été faite par une agence mais n'a pas été toute rose...C'est à se demander... Une chose me revient également : j'ai fait l'essai de configurer l'option transporteurs "Comportement hors tranche" sur "Prendre la tranche la plus grande" mais idem parfois cela fonctionne et souvent non. Bref, j'ai la sensation que ça provient de la sélection de la zone, qui ne se fait pas ou mal... Quelle méthode pourrais-je utiliser pour identifier cela ... ? EDIT : il y a p-e une piste en s'inspirant de ce cas :

@Chris13200 @PierreFKT Bonjour, Je rencontre également ce même soucis (PS 1.7.6.8), à savoir que parfois j'ai des clients qui se manifeste avec ce problème "qu'aucun transporteur ne livre à cette adresse". J'ai tenté d'identifier un point commun à travers tous les cas, j'ai tenté diverses solutions, qui parfois fonctionne ponctuellement. Dans ce qui a fonctionné jusque là : - supprimer l'adresse puis la recréer depuis le compte client - supprimer l'adresse puis la recréer dans le processus de commande - supprimer un produit puis le remettre dans le panier - faire vider cache et cookie du navigateur du client ou utiliser un autre navigateur Je n'ai donc pas encore trouvé de méthode fonctionnelle systématiquement... A savoir pour mon cas que ce PS 1.7.6.8 a été migré depuis un PS 1.5, et la gestion des adresses n'était pas la même car passé un temps j'avais gérer la Corse d'une certaine façon, et j'ai l'impression qu'il en reste des traces qque part dans une database, et que le PS 1.7.6.8 se mélange les pinceaux... Mais dans ce cas, pourquoi ça le fait aussi pour certains nouveaux clients... ? Aussi, j'ai un module "frais de port par code postaux" qui me permet de zoner la Corse et les DOM, mais idem les problèmes se posent pourtant pour les clients en France, avec un code postal valide... Mes pistes/idées/réflexions : - poids des produits ? pourtant cela arrive avec des produits couramment commandés... - poids total de la commande ? peu probable ; je fait d'ailleurs l'essai de modifier la qté d'un article, dans l'espoir que ce soirt recalculé, mais sans succès... - création en BO de la commande qui fonctionne, donc à priori c'est coté FO que ça coince... - comment savoir quel processus de PS est utilisé pour lister (ou non dans ce cas...) les transporteurs... Merci ! Fred

Salut, La solution est ailleurs ^^ J'ai été confronté à cela, il faut simplement retirer ce module Paypal de 202ecommerce, et installer en lieu et place le module "Prestashop Checkout" qui permet d'y implémenter Paypal. La grosse différence, c'est qu'il n'y a plus de problème ensuite... Du moins, ça avait fonctionné pour mon cas. F

Il semble qu'il n'y ait pas d'annexe à ton message =/ Et en mettant ce produit à tarif unitaire 0.070000€HT (plutôt que 0.070833 et bien remplir le champ "prix HT" de sa page produit ou déclinaison) et en vérifiant également que "nombre de décimales" dans configuration est bien sur "2" ? Ca donne quoi ?

Lorsque j'avais des commandes en erreur de paiement, je contrôlais simplement sur Paypal si c'était bien crédité et je validais alors manuellement la commande en BO. Bien entendu, selon tes volumes de vente, cela n'est p-e pas faisable... Concernant les erreurs de paiement : il m'a suffit de mettre en place le module Prestashop Checkout dans lequel je n'ai configuré que Paypal, et depuis plus de problème. Sacré château de cartes que ce PS, hein ^^

En lisant ta réponse, voila ce qui me revient : en configuration "Arrondir le total" j'avais le problème avec Paypal (certaines commandes étaient en erreur de paiement (80%...) voire même parfois pas créées du tout en B.O. ...) et si je mettais en "arrondir ligne par ligne" c'était la TVA qui était fausse... Il est probable que si tu configure en "arrondir le total" que tu n'ai plus le problème...

Bonjour, J'ai eu le pb par le passé (j'ai la même typologie de produits que toi, à savoir des produits vendus à la coupe avec donc un tarif unitaire bas, mais avec des qtés potentiellement grandes), mais j'avoue que je ne sais plus si c'était sur l'ancien PS 1.5 ou suite à la migration sur une 1.7 (1.7.6.8 pour être précis). De mémoire, j'avais je crois défini des tarifs HT sur deux décimales uniquement et c'était alors le TTC qui était arrondi. De fait, j'applique toujours cette méthode. Donc pour reprendre ton cas de figure : 0.058333€HT => 0.060000€HT Evidement, ça fait un écart de prix de vente de 2.8%. J'ai eu par ailleurs des soucis avec Paypal (erreur de paiement à cause de la différence de calcul), cela avait été résolu par la mise en place du module PS Checkout qui intègre Paypal. EDIT : il y a aussi la configuration des "paramètres généraux" à regarder. je suis configuré ainsi et ça fonctionne : Fred

Bonjour, Le post est plutôt ancien, mais j'ai ce même besoin : plusieurs adresses emails de connexion pour un seul et même compte client, pour que plusieurs collaborateurs puissent passer des commandes. Est-ce que depuis une solution existe ? Je suis en PS 1.7.6.8 Merci !

Idem ici... Une piste ? Merci !

Salut, Le problème est enfin solutionné dans mon cas. On m'a conseillé d'installer Prestashop Checkout, qui permet d'accepter les paiements Paypal et CB (CB via paypal, mais que j'ai désactivé car j'ai une autre solution pour cela ; ce module ne gère donc que les paypal). J'ai pourtant laissé ma config pour les arrondis en "arrondir le total", et tout fonctionne : pas d'erreur d'arrondi, pas d'erreur de paiement, pas d'erreur de TVA... Fred

Salut, J'ai eu à nouveau un problème de mise à jour de produit impossible. Après recherches, il s'avère que j'avais une référence de déclinaison qui se terminait par "...-OR". Ce simple terme de deux lettres "OR" pouvant être interprété comme un mot clé de programmation, j'ai modifié ma référence ; par contre, j'ai également modifier la déclinaison par défaut avant d'enregistrer le produit (qui a donc fonctionné à ce moment-là), je ne sais pas si c'est la réf de déclinaison qui posait soucis, ou bien le choix de déclinaison par défaut. Ou les deux... M'enfin, je présume qu'il y a qd même une forte probabilité pour que ce soit le 'OR' contenu en fin de la référence de déclinaison qui faisait coincer... Fred