Zebx

Votre affichage des prix est HT si je ne me trompe ? Donc au lieu de faire une remise de 15€ TTC, il convient peut-être de faire une remise de 12.50€ HT Ce qui au final revient au même mais évitera peut-être à PS de se planter dans les calculs... C'est tjs qu'une hypothèse ^^

A : 103.33 -15.00 = 88.33 *1.20 = 106.00€ B : 103.33 -12.50 = 90.83 *1.20 = 109.00€ PS fait un mix de ces 2 calculs et affiche la base HT selon le calcul A et le montant TTC selon le calcul B La question est donc surtout de voir si votre réduction est censée être de 12.50€ HT ou 15.00€ HT et de vérifier la règle panier...

PS a toujours eu l'art de s'emmêler les pinceaux avec les affichages HT et TTC. A priori c'est la réduction de 15€ qui est à l'origine de l'erreur de calcul. Le calcul de cette facture étant un mix de réduction de 12.50€ HT et de 15.00€ TTC. Il faut voir peut-être du côté de la règle panier... si vous avez opté pour un affichage HT des prix, il convient sans doute d'appliquer également une réduction avec un montant HT et non TTC. Ce n'est qu'une hypothèse... je n'ai plus mis les mains dans le cambouis de PS depuis longtemps ;-)

Bonjour, Je viens d'être confronté à un problème similaire et pour ma part c'est un module qui était en cause (module de changement de statut depuis la liste des commandes par Linea Grafica) Le bug de stock survenait uniquement en changeant le statut via le module, depuis la fiche de commande ça réagissait normalement. Je viens de leur signaler le souci donc j'imagine qu'une mise à jour va suivre. Sinon il suffit simplement de commenter la ligne $order->current_state = $status; (dans AdminOrderStatusSwitchController.php), qui selon moi ne sert d'ailleurs à rien 😉 A+

Bonjour, Je viens de rencontrer ce problème aujourd'hui. Il semble qu'Ebay rejette désormais les noms d'images qui ont des caractères spéciaux ou accentués. Perso j'ai résolu le problème comme ceci : Dans classes/EbayRequest.php , fonction uploadSiteHostedPicture : 'picture_name' => Tools::str2url($picture_name), Ce qui donnera à peu de choses près le même résultat que ce qu'Ebay faisait avant tout seul comme un grand...

Lol doekia, c'est plus des arguments là, c'est de la mauvaise foi... @coes.pro : les coordonnées entre elles des comptes invités "enregistrés" sous le même email Je répondais en fait à l'exemple des emails jetables, de la jeune fille et du vieux pervers ^^ En même temps si on veut pousser le bouchon avec des exemples tirés par les cheveux, on peut aller loin, et ça marche aussi avec des vrais comptes : - la jeune fille crée un vrai compte avec un email jetable pour passer sa commande - le vieux pervers arrive 6 mois plus tard avec le même email et souhaite s'enregistrer mais la boutique dit que cet email est déjà utilisé. "Voulez-vous récupérer le mot de passe ?" Bref, si les gens sont idiots au point d'associer des données personnelles à un email jetable, manquerait plus qu'on vienne nous le reprocher. @Twistix : je ne vois pas pourquoi il y aurait plus facilement question de fraude. La facture d'un invité va en compta comme toutes les autres... Euh sinon, vous pensez qu'il faudrait prévenir Ebay de préparer 300 millions asap ? Parce que l'achat immédiat en tant que visiteur est toujours possible apparemment

Ces arguments sont encore une fois vrais avec une vision automatisée ou autonome du processus suite aux requêtes RGPD des clients. Mais je le répète, l'intervention humaine côté marchand et un minimum de contrôle restent inévitables dans certains cas. Et à ce sujet : Can we ask an individual for ID? If you have doubts about the identity of the person making the request you can ask for more information. However, it is important that you only request information that is necessary to confirm who they are. The key to this is proportionality. You need to let the individual know as soon as possible that you need more information from them to confirm their identity before responding to their request. The period for responding to the request begins when you receive the additional information. Donc si on a un doute sur l'identité, à cause de l'adresse email ou à cause de données non concordantes... on a le droit (voire l'obligation) de demander des éléments complémentaires prouvant l'identité.

Attention que je parle dans l'absolu. Je n'ai pas dit que c'était nécessairement simple ni qu'un module existait déjà pour réaliser les tâches... Mais techniquement je ne vois pas en quoi ce serait insurmontable. Le guest passe sa commande avec une adresse email donc ça me semble être une base suffisante pour l'identifier et extraire (ou anonymiser) ses informations (on obtiendrait une liste de x clients avec x adresses et x commandes) Pareil pour ses consentements, on peut très bien les enregistrer sur base de son email, à chaque commande ou "inscription" du coup. Ca ne fait pas une grosse différence avec un simple formulaire de contact qui restera de toute façon utilisable aussi bien par les visiteurs que par les clients enregistrés. D'ailleurs, une bonne chose quand même avec un compte guest, c'est que ses données sont limitées et s'éparpillent donc moins dans différents modules (pas de favoris, pas de fidélité, pas de programme d'affiliation, ...). Il faut bien que le client s'identifie auprès du marchand d'une manière ou d'une autre. Donc s'il a passé commande en guest avec x adresses email différentes, à lui de les fournir. Au même titre qu'il pourrait très bien avoir créé x vrais comptes avec des adresses email différentes. En fait, on pourrait même pousser un peu plus loin et donner au compte guest un réel intérêt pour le client. On pourrait en effet imaginer : - un nettoyage régulier des comptes invités sans commande (pas besoin de les conserver, donc toutes les semaines ou tous les mois, poubelle) - une suppression ou anonymisation automatique des données en ligne sur une période relativement courte. Tous les 3 mois, 6 mois, 1 an, 2 ans, ça peut dépendre un peu du business de la boutique. Rien n'empêche de toute façon de conserver une version offline des factures pour raisons administratives légales. En gros ce serait peut-être l'occasion de faire de ces comptes invités de réels comptes invités, comme le client l'a (naïvement) compris Avis donc aux développeurs de modules... Et puis, je viens seulement d'y penser, mais quid des commandes qui proviennent des marketplaces ? Prenons par exemple le module Ebay, qui rapatrie les commandes sur des comptes "visiteurs". Il va bien falloir les gérer toutes ces données personnelles aussi... J'ai pas encore creuser l'affaire, et je suppose que là le consentement est "hérité" depuis les marketplaces, mais ça n'empêche pas de devoir gérer ces données clients par la suite. Donc si une gestion doit être prévue pour eux, elle sera automatiquement compatible avec les comptes invités créés directement sur la boutique. Ca me semble kif-kif

Je suis bien d'accord que la différence entre un vrai compte et un compte invité, ça n'est jamais qu'un mot de passe. L'intérêt jusqu'ici était donc surtout psychologique... le client pouvait en effet croire naïvement que ses données n'étaient pas enregistrées. Mais de là à dire que c'est devenu illégal avec le RGPD, sincèrement, je ne crois pas. D'après moi la seule différence à présent c'est que désormais le client ne doit justement plus croire naïvement que ses données ne sont pas enregistrées. D'où l'intérêt des popin et autres cases à cocher lui signifiant ce qu'on va faire de ses données et pendant combien de temps... En ce qui concerne l'accès, la modification ou la suppression des données d'un tel compte invité, bah à priori rien ne nous oblige à ce que tout ceci soit accessible en live et sans intervention humaine côté marchand, en effet, on a 1 mois pour réagir. Je dirais en fait qu'il faut plutôt comprendre "droit d'accès" par "droit de savoir". D'ailleurs le garagiste du coin va (peut-être ^^) vous faire une facture, mais il va pas vous donner accès à un compte personnel en ligne... Au passage quelques liens : Un site franchement bien structuré façon checklist et très complet, but in english : https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-of-access/ Une version assez claire en français à ce sujet (site belge, équivalent CNIL en quelque sorte) : https://www.autoriteprotectiondonnees.be/droit-dacceder-a-vos-donnees-art-15-rgpd Ceci étant dit, est-ce qu'il y a du coup encore un intérêt aux comptes invités ? Je dirais moins qu'avant, mais sans doute encore un peu... disons que ça reste utile tant que les clients penseront que c'est mieux pour quelque raison que ce soit... (genre allergie aux mots de passe ^^)

Bonjour Il s'agit d'un OU exclusif. A chaque formulaire son cas de figure évidemment... Les données reçues dans un formulaire de contact n'autorise donc pas à inscrire à la newsletter mais permettent de répondre uniquement à la demande. En revanche une simple vente permettrait toujours d'inscrire automatiquement le client à votre newsletter pour autant que celle-ci concerne des produits ou services analogues à ce que le client a déjà acheté précédemment. Le RGPD semble ne pas avoir modifié cette exception, ce qui est une bonne chose... mais cela nécessite d'être plus rigoureux sur le contenu de ce que vous envoyez et à qui vous l'envoyez (encore que la notion de "produit analogue" est un concept assez vague et selon le point de vue ça peut vite devenir très vaste).

Bonjour, Afin de pouvoir optimiser la gestion des exportations hors UE, je cherche un module qui permettait de générer le formulaire CN23 de manière automatisée (en intégrant les codes Taric et le pays d'origine des produits). J'avais remarqué à une époque un module qui proposait cela, et je l'avais mis dans un coin de ma tête... mais apparemment il a été supprimé de la plateforme addons Je retrouve juste un lien cassé dans le sujet ici : https://www.prestashop.com/forums/topic/211576-codes-taric/?do=findComment&comment=1970026 Et un bref descriptif sur ce site "bizarre" : http://addons.ovh/prestashop-modules/shipping-and-delivery/cn23-taric-informations.html Bref, quelqu'un saurait-il comment remettre la main sur ce module ? Une idée de qui en serait l'auteur ?

Salut, Disons que je fais très très peu de pub sur Facebook donc je me suis contenté de tracker la conversion. Je viens de jeter un oeil vite fait, à priori l'idée serait alors d'appliquer la méthode décrite ici : https://developers.facebook.com/docs/facebook-pixel/api-reference#doublewhammy Ce qui reviendrait à mettre le code de base complet dans header.tpl, et juste ajouter l'événement "purchase" dans ganalytics. A tester...

Attention à l’ambiguïté de cette phrase. Il faut évidemment comprendre : les résultats de conversion dans le panneau d'administration facebook, comme pour google adwords, ne seront jamais fiables a 100% Ce qui est tout à fait vrai L'exemple de Paypal en revanche n'est vrai que dans certains cas... tout dépend comment vous intégrez le suivi de conversion... Sinon l'idée du coupon est bonne, mais pas nécessairement fiable à 100% non plus, puisque cela implique que le visiteur n'oublie pas de l'utiliser... Disons qu'une combinaison des 2 solutions permettrait d'avoir les stats les plus fiables... sans pour autant atteindre les 100%

Bonjour, J'avais eu un souci similaire de page de retour avec un autre module de paiement, l'origine était l'utilisation d'un serveur smtp trop lent pour l'envoi des emails de confirmation de commande. Si vous utilisez un serveur smtp, essayez peut-être un moment avec phpmail pour voir si ça va mieux...

A priori ça remarche normalement