Jump to content

Mpic

Members
  • Posts

    88
  • Joined

  • Last visited

Mpic's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. Pour ma part, j'ai contacté 1and1 pour qu'ils fassent le nécessaire. Le lendemain tout était ok. C'est à eux d'envoyer l'erreur de blacklistage à Paypal qui eux transmettent à leur fournisseur. Cela s'est fait en 24h mais aussi nous avons un "gros" compte chez eux, cela explique peut-être cela. Sinon 1and1 reconnaissent parfaitement l'erreur.
  2. Bonjour, Nous rencontrons un problème avec la version 1.4.0 d'ebay : Il est impossible d'indiquer notre code postal (belgique) car cela fait planter l'export. On a donc le fameux message d'erreur : Veuillez saisir un code postal valide. Vous n'avez pas indiqué le lieu où se trouve votre objet. Cette indication permet aux acheteurs de calculer les frais de livraison de l'objet et est indispensable. J'indique donc un "faux" code postal, mais voilà que j'ai l'erreur Vous avez atteint vos limites de vente à l'international Je précise que nous avons un compte "confirmé" sur ebay, depuis la Belgique et surtout que l'ancien module fonctionnait parfaitement, du coup, nous voilà bloqué. Cordialement
  3. Même problème chez plusieurs clients, pas de mise à jour rien. Depuis ce matin cela fait ça. - Commandes fantômes - Envoi d'un mail "à rembourser" au client.
  4. Bonsoir, La solution (je l'ai appliqué chez un client belge aujourd'hui) est de créer une zone "belgique" contenant "belgique" et n'activer le transporteur "cash on delivery" uniquement en belgique. Ensuite, actives un transporteur "Bpost - Contre remboursement" et en frais de port ajoute frais de port + frais de contre remboursement. Et voilà. Il y a toutefois un problème dont prestashop se moque complètement depuis 2008, c'est l'impossibilité de désactiver le moyen de paiement "Cash on delivery" si le transporteur n'est pas ici "Bpost contre remboursement", si bien que des clients pourraient dans mon cas prendre tnt 24h , payer 35 euros de frais de port et 0 de frais de contre remboursement puis demander le contre remboursement en moyen de paiement...au final on perd les frais de contre remboursement et en plus, si le transporteur ne propose pas le contre remboursement il sera tout de même proposer. Bref, un problème important mais inutile d'espérer quoi que ce soit.
  5. Bonsoir à vous, Je bute totalement sur la problématique suivante : La boutique d'un client dispose d'un seul certificat SSL, avoir 3 SSL supplémentaires pour les CDN serait possible mais d'une part ce serait très couteux et d'autre part cela ralentirait le site au point d'inverser l'intérêt du CDN. La solution est donc de désactiver le CDN lorsque l'on bascule sur une page https:// , j'ai beau tout essayé je n'y arrive tout simplement pas. Avez-vous une piste ou bien la solution si jamais vous l'avez déjà appliquée? Bonne soirée à vous et merci bien!
  6. J'ai mis une solution qui a fonctionné pour moi: http://www.prestashop.com/forums/index.php?/topic/154990-important-y-atil-vraiment-une-soluce-contre-lerreur-de-commande-non-validee-cause-par-paypal/page__view__findpost__p__752204
  7. J'ai réussi à réparer ce soucis, pour l'instant cela fonctionne : - Désinstaller, supprimer et réenvoyer et installer puis paramétrer les modules de paiement - Faire une modification sur les réglages paiements, sauvegarder, remettre comme initialement (avant votre modification) puis réenregistrer. Attention, pour les commandes "fantômes" ayant eu lieu avant les manipulations, il faudra toutefois les remettre dans un statut sinon elles ne s'afficheront pas. L'astuce pour détecter : Mettre "20 commandes", si moins de 20 s'affichent (voir avec les numéros de commande et faire une soustraction) c'est qu'il y a une commande fantôme.
  8. Même soucis depuis ce week-end aussi. Je cherche actuellement une solution...Je reviendrais si je trouve.
  9. Bonjour merci pour la réponse, j'ai depuis résolu mon soucis. Il s'agissait en réalité d'un petit oubli dans le .htaccess. Lorsque vous êtes chez ovh, ajoutez à la fin tout comme le .htaccess de la boutique: SetEnv PHP_VER 5 SetEnv REGISTER_GLOBALS 0 Pour rappel, il y avait un léger soucis, en effet les commandes du module atos ne s'affichaient pas dans le back-office prestashop malgré la validation de paiement, chez l'hébergeur OVH.
  10. Bonjour à vous tous! Je rencontre depuis ce matin un petit soucis sur un site fraichement installé. Le module "Atos" ne renvoi pas les commandes dans le BO. Toutefois, le client voit les commandes sur son compte client à la banque. J'ai désactivé le pare-feu applicatif, passé les chmod en 755 La boutique est chez OVH en mutualisé. Je contact le développeur dans la foulée mais si vous avez une solution ou bien déjà rencontré ce soucis, merci de m'indiquer Prestahop 1.4.5.1 Atos : 2.2 Le module (autre version) est installé sur d'autres boutique (1.4.3), sans aucun soucis. Merci d'avance et bonne journée à vous.
  11. Exactement, il faudrait que ce soit le client qui soit impacté du coût des sms.
  12. Un client est chez eux et ne juge que par eux, après il fait près d'un million de CA (via ogone) par an, donc peut-être est-il bichoné.
  13. Je viens de lire et je confirme bien pour le rss, sur mes sites je supprime toute référence à prestashop notamment sur la page d'accueil de l'administration. Ces boutiques là ne sont aucunement infectée. En revanche, pour des raisons de stabilité j'ai laissé les références sur de récentes boutiques toutes infectée. Déçu pour ce coup là. Indiquez un tutoriel pour nettoyer tout proprement svp.
  14. Allez dans l'onglet "Modules", vérifiez que vous avez séléctionné "Tous les modules" "Installé et désinstallé" et "activé et désactivé". Ensuite dans la catégorie "Publicité et marketing" regardez "Relancez vos clients" Le topic est ancien mais je répond pour les prochains
×
×
  • Create New...