Jump to content

Odjavel

Members
  • Posts

    389
  • Joined

  • Last visited

  • Days Won

    1

Odjavel last won the day on February 25 2012

Odjavel had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Odjavel's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • One Month Later Rare
  • One Year In Rare
  • Week One Done Rare

Recent Badges

4

Reputation

  1. Bonjour, Merci pour votre réponse Mediacom. Donc, pour mon domaine italien, je vais avoir une paramétrage du type Identifiant de la langue: it Identifiant du pays: fr C'est bien ça ? J'avais un doute sur l'identifiant du pays. Dans la mesure où l'IP est italienne, peut-être aurait-il fallu harmoniser ce champs. Par ailleurs, heureusement que j'ai votre module "1 langue par boutique". Dans mon cas, ça facilite singulièrement la vie ! 👍 Merci !
  2. Bonjour, Sur PS 1.7.7, dans BO > International > Localisation > Avancé, on trouve les options "Identifiant de la langue" et "Identifiant du pays". Je ne trouve aucune info détaillée sur ces options. Je suis en multi-boutiques. En fait, c'est la même boutique, mais j'ai un nom de domaine "local" par langue, du type site.fr, site.it, site.de etc. J'ai aussi une adresse IP "locale" pour chaque langue (ip française, italienne, allemande etc.) A l'arrivée, ça fait un shop par langue, chaque shop étant donc très optimisé pour son pays cible respectif. Le tout est édité/géré/facturé par ma société française. Question: comment remplir les options Avancées ? Pour mon shop en italien avec IP italienne, dois-je mettre "it" dans les deux champs ? Il semble évident de répondre "oui", mais j'ai un doute, car je ne comprends pas à quoi servent ces champs, ni où ils sont utilisés. Si quelqu'un peut m'éclairer... Merci !
  3. Merci pour votre participation ! Cela dit, un message envoyé au client à propos de sa commande (order_merchant_comment) demande la plupart du temps une réponse. Exemple: - Votre code postal ne correspond pas à votre ville. Merci de nous informer; - Quel est votre nom, nous n'avons que vos initiales; - Est-il normal que votre commande soit livrée au Kosovo alors que votre carte bancaire est canadienne et que votre adresse IP est a Hong-Kong; - Êtes-vous certain de vouloir 12 fois la même paire de chaussures; - Votre prénom est-il réellement "la coquine du 64" ? Attention au replissage automatique du formulaire ! - etc. (ça sent le vécu, non ? 😋) Bref... En ce qui me concerne, un message envoyé au client nécessite quasi-systématiquement une réponse. Ma question reste donc entière.
  4. Bonjour, Je me pose une question sur le système de SAV. Lorsqu'un client envoie un message depuis l'historique de sa commande, un nouveau thread SAV est créé. Si on lui répond depuis le SAV, il reçoit un email (template reply_msg) contenant un lien pour qu'il puisse lui-même répondre en tenant compte du fil de discussion (lien du type shop.com/nous-contacter?id_customer_thread=452&token=pbvHtnz5NQxp). Super ! ça permet au client de répondre au bon thread, même s'il n'est pas connecté à son compte, ou même s'il a la flemme de retourner sur le récap de sa commande. Par contre, si c'est le marchand qui initie la conversation en envoyant un 1er message depuis la commande en BO, alors le client reçoit un email (template order_merchant_comment) qui ne contient pas ce lien pour répondre. Pourtant, un nouveau thread est bien créé dans le SAV. S'il n'est pas connecté, il se retrouve sur le formulaire de contact et envoie un message qui ne sera pas référencé dans le même thread que notre message initial. Un nouveau therad sera ouvert, car aucun numéro de commande ne sera associé au message. Vous me suivez ? Bon. Ma question: pourquoi order_merchant_comment ne fonctionne-t-il pas de la même façon que reply_msg ?? S'agit-il simplement d'une "mauvaise" conception de Prestashop, ou est-ce que je passe à côté d'un détail plus subtil ? Ne serait-il pas normal que le client reçoive notre message initial sur le même modèle que reply_msg, avec un lien pour répondre ? Après tout, tout ça, ça reste du SAV. Précisions: - je suis sur PS 1.7.7.2 - j'ai désactivé les emails dans le module contactform. Le but est de pleinement exploiter le système de SAV. Merci pour vos éclaircissements !
  5. Hello, The post is a bit old, but you just saved my day !! I could finally solve the problem of translating subjects of emails from ps_emailalerts modules, which doesn't even bother itself to create those lines in ps_translation table, or at least an easy way to do it ouserlves. It is also just incredible that the Translations page of Back Office doesn't allow to do that easily. Noooo... You have to hit directly into the database to make a such a dummy thing. Thanks again !
  6. Merci pour ta réponse très bien argumentée et sourcée. ça flingue un peu mes plans, là.... 🤔 Mais c'est toi qui as raison, sans nul doute. Je vais donc certainement re-mettre la case des CGV. Mais franchement, j'aurais préféré éviter encore un click obligatoire de plus avant de pouvoir valider la commande. Quelle lourdeur... Merci encore Divine ! PS: je reste très intéressé par la méthode pour ouvrir une page dans une modale. ça peut forcément servir. Si un sachant passe par là...
  7. Merci de t'intéresser à mon post. Oui, techniquement c'est vrai. Mais en pratique, voilà une case de plus à cocher avec des mentions en plus à lire. C'est pour cette raison que je veux fusionner les deux, et après tout, pourquoi pas. Avec une seule case, j'accepte les CGV et la politique de confidentialité. La loi RGPD est donc bien respectée, puisque je garde le bouton "Commander avec obligation de paiement, par ce que je suis débile et que j'imagine forcément que mes commandes sur internet son gratuites". C'est surtout sur ce bouton que la DGCCRF insiste, car c'est via ce bouton que le consommateur reconnait explicitement que la commande entraine une obligation de payer. Donc je pense que mon système de case fusionnée ne posera pas de problème. Reste encore à savoir comment faire un lien qui s'ouvre dans une fenêtre modale 😏
  8. Personne ? Si une bonne âme pouvait m'expliquer comment faire ce lien href pour que la page cible s'ouvre dans une fenêtre modale, ce serait sympa. PS 1.7.6.3 Merci !
  9. Bonjour, J'utilise le module RGPD officiel sur PS 1.7.6.3. Comme il me semble faire double emploi avec la traditionnelle case d'acceptation des CGV, j'ai désactivé cette dernière pour ne garder que la case à cocher du module RGPD. Tout marche bien. Par contre, je ne parviens pas à refaire un lien vers les CGV dans le paramétrage du Message de demande de consentement. Je configure le lien dans la boîte TinyMCE, celui-ci s'affiche bien en FO, mais il ne fonctionne pas. La page deviens grise, et rien. Quelqu'un connaîtrait-il le code exact à utiliser pour ouvrir les GCV ou autre page cms dans une fenêtre modale, comme pour l'option de base d'acceptation des CGV ? Merci d'avance
  10. Bonjour, Juste un petit up pour savoir si la version 1.7 sera bientôt disponible. Qu'on le veille ou pas, il va bien falloir y passer et je prépare ma migration. Ce module fait partie des mes happy indispensables. Merci !
  11. Merci de ton intérêt, Janett. Je comprends, mais j'en doute. La table ps_orders et les ps_order_xxxxx contiennent toutes les données de chaque commande en brut, afin que rien ne soit recalculé, ce qui est plutôt bien. Il n'y a donc jamais re-calcul des frais de port pour une commande validée, même si tu re-crées une facture. Et si tu crées une nouvelle commande, tu n'auras de toutes façons plus accès au transporteur ayant été utilisé la première fois si tu l'as supprimé entre-temps. Non, vraiment, je n'arrive pas comprendre pourquoi PS ne nettoie pas ces tables lors de la suppression d'un transporteur. Négligence ou but bien précis ?
  12. Re, Je me permets de remonter ce sujet, car je tache actuellement d'optimiser mon site et cette question reste toujours en suspend. Un spécialiste pour me donner un avis là-dessus ? Dans la liste des tables à nettoyer, j'ajouterais même: ps_carrier_shop et ps_carrier_tax_rules_group_shop, dont les données ne serviront plus. Merci !
  13. Et moi j'utilise ta solution depuis plusieurs années. 😁 ça fonctionne très bien ! Ok, je l'ai un peu modifié pour coller parfaitement à mes besoins, mais j'ai aujourd'hui 1 boutique pour chaque langue avec un domaine différent (un .fr pour le FR et un .com pour le EN). De plus, Johann a raison: perso, j'ai des catégories et produits disponibles sur le site en français, mais pas en anglais. Il n'y a qu'avec un système multi-boutiques que l'on peut faire ça.
  14. Bonjour, J’ai une petite question à poser aux spécialistes. Lorsque je supprime un transporteur, PS fait une suppression logique (deleted=1). Normal, cela permet de conserver les noms des transporteurs utilisés dans le passé afin que les anciennes commandes restent renseignées. Par contre, je ne comprends pas pourquoi certaines tables ne sont pas nettoyées à la suppression des transporteurs. La table ps_delivery, par exemple. Quel intérêt de conserver les tarifs sur tranches de prix/poids pour un transporteur supprimé ? Ces tranches ne resserviront plus jamais, non ? Idem pour ps_range_weight et ps_range_price. Chez moi, le transporteur supprimé reste référencé dans ces tables. Pourquoi ? Ces tranches ne serviront plus. Idem pour ps_carrier_group (on se fiche désormais de savoir à quel groupe de clients étaient affecté ce transporteur), ps_carrier_lang (plus besoin d’annoncer les délais de livraison à l’avenir), ou même ps_carrier_zones. Pensez-vous que je peux supprimer de ces tables (surtout ps_delivery et ps_range_weight/price) toutes les lignes correspondant aux transporteurs supprimés ? Merci d’avance pour votre éclairage.
×
×
  • Create New...