Stabbquadd

C'est bon, problème corrigé avec ma solution ! Pour le moment tout fonctionne en tous cas

En fouillant un peu plus, j'ai trouvé quelque chose qui m'intrigue. Tout d'abord j'ai compris pourquoi il ne s'agissait pas d'une erreur lorsque j'ai cité la fonction changeIdOrderState de la classe OrderHistory.php. if ($new_os->invoice && !$order->invoice_number) { $order->setInvoice($use_existing_payment); } elseif ($new_os->delivery && !$order->delivery_number) { $order->setDeliverySlip(); } En fait la fonction setDeliverySlip() ne sert à créer un BL que si une facture n'a pas encore été faite avant. C'est la raison pour laquelle il y a le elseif, donc à ne pas changer. Plus loin dans la classe, j'ai trouvé le morceau qui créé le BL après la facture : // updates delivery date even if it was already set by another state change if ($new_os->delivery) { $order->setDelivery(); } La fonction setDelivery() est bien là pour créer le BL lorsque l'état de la commande le demande, après la facture. Mais je pense que le problème vient de cette fonction, voici l'extrait en question : // Get all invoice $order_invoice_collection = $this->getInvoicesCollection(); foreach ($order_invoice_collection as $order_invoice) { /** @var OrderInvoice $order_invoice */ if ($order_invoice->delivery_number) { continue; } // Set delivery number on invoice $order_invoice->delivery_number = 0; $order_invoice->delivery_date = date('Y-m-d H:i:s'); // Update Order Invoice $order_invoice->update(); $this->setDeliveryNumber($order_invoice->id, $this->id_shop); $this->delivery_number = $this->getDeliveryNumber($order_invoice->id); } On voit que la boucle foreach parcourt les factures de la commande et fait appel à la fonction setDeliveryNumber(), qui est bien celle qui créé le numéro de BL. Seulement voilà, cette partie de la boucle n'est effective que si la commande possède déjà un numéro de BL ! if ($order_invoice->delivery_number) { continue; } Si la commande n'a pas encore de numéro de BL, alors la boucle passe à la commande suivante. Et donc ne créé jamais le numéro de BL. Cependant je ne comprends pas encore pourquoi lorsque je passe la commande à "En cours de livraison", le numéro de BL est créé.

Bonjour Broceliande, comment va ma Bretagne ? Très bien vu pour le PS_DELIVERY_NUMBER, sa valeur est NULL. Tout comme le champ id_shop pour l'intégralité des enregistrements de la table ps_configuration sauf un, PS_SHOP_ENABLE. Néanmoins, je tiens à préciser que j'ai utiliser le 1-click upgrade, et que je n'ai plus rien touché d'autre après que la correction des quelques erreurs de thème. De manière à moitié amusante, le bon de livraison trouve son numéro une fois la commande passée en cours de livraison. Car en effet, en passant la commande à "En cours de livraison", les numéros de BL se suivent bien sagement comme il faut, même avec ceux générés avant la MAJ. Pourquoi ne pas passer toujours par cette méthode ? Bref, j'ai renseigné dans le BO le numéro du prochain BL en prenant le max (delivery_number) +1 de la table ps_orders. J'ai vérifié et il s'est bien inscrit en BDD. J'ai donc passé une commande de test... Et le bon de livraison ne s'est pas généré avant l'étape "En cours de livraison"... Et la valeur de la clé PS_DELIVERY_NUMBER est repassé à NULL. Mince, j'y avais cru pourtant ! Mais en fait, voici ce que j'ai trouvé dans la classe Order.php à la ligne 1384, au sein de la fonction setDeliveryNumber() : $number = Configuration::get('PS_DELIVERY_NUMBER', null, null, $id_shop); // If delivery slip start number has been set, you clean the value of this configuration if ($number) { Configuration::updateValue('PS_DELIVERY_NUMBER', false, false, null, $id_shop); } J'insiste sur le "If delivery slip start number has been set, you clean the value of this configuration". Je sais bien que ça pourrait vouloir dire qu'on la nettoie pour la mettre à jour, seulement on passe à la fonction de configuration la nouvelle valeur "false". Il semble donc intentionnel que cette clé n'ait plus de valeur. Visiblement, cette clé de configuration n'est plus utilisée. Le reste de la fonction est cohérent, puisqu'en l'absence de clé de configuration pour le DELIVERY_NUMBER, il utilise la requête suivante : (SELECT new_number FROM (SELECT (MAX(`delivery_number`) + 1) AS new_number FROM `'._DB_PREFIX_.'order_invoice`) AS result) Mais pourquoi cette fonction n'est-elle pas utilisée plus tôt dans mes commandes ? En fait elle n'est appelée qu'une seule fois, par la fonction... setDelivery() ! De l'intérêt de créer une fonction qui ne sert à être appelée que par une autre fonction... Bref. Cette fonction, setDelivery(), n'est elle aussi appelée que par une seule autre fonction, changeIdOrderState(), mais de la classe OrderHistory.php cette fois-ci. Au sein d'une petite ligne toute timide : // updates delivery date even if it was already set by another state change if ($new_os->delivery) { $order->setDelivery(); } Et malheureusement, je retombe sur le même problème. $new_os->delivery correspond à la valeur de delivery dans la table ps_order_state à l'enregistrement id_order_state correspondant. Or, delivery est à 1 pour les id_order_state 2, 3, 4, 5 et 12, ce qui correspond à "Paiement accepté", "Préparation en cours", "En cours de livraison", "Livré", et "Paiement à distance accepté". Une fois de plus, tout va bien, mais ça ne fonctionne pas Retour à la case départ... Parenthèse concernant la ligne chronologique des commandes. Je ne comprends pas l'intérêt de faire traîner la création du bon de livraison. Après tout la facture est générée immédiatement, et contrairement à elle, le bon de livraison n'engage à rien ! Il ne prouve pas que la commande a été payée ou quoi. Il dit juste que, dans cette commande, il y a ces éléments. Que la commande ait été payée ou pas, peu importe. AMHA, un bon de livraison, c'est comme un panier, mais qui a été validé, c'est tout.

Bonjour à tous. Je suis face à un problème assez particulier après avoir mis à jour ma boutique de la version 1.5.2 (ouch) à la version 1.6.1.6. En fait, mes commandes n'ont un bon de livraison disponible qu'après l'envoi (statut "En cours de livraison"). Avant, ce bon de livraison était disponible dès "Préparation en cours". Je suis donc allé éditer les statuts des commandes afin que le bon de livraison se génère dès que le paiement est accepté. Mais toujours rien avant que je mette "En cours de livraison". Pire encore, il m'est impossible de modifier dans le Back Office les options du statut "Préparation en cours". En réalité, quand j'envoie le formulaire, la mise à jour se fait en base de données, mais quand je clique à nouveau sur modifier, tout est comme avant. J'ai pensé à un problème de cache du navigateur, mais non, j'ai eu beau vider le cache de prestashop et du navigateur, rien n'y fait. Ces données viennent pourtant bien de quelque part. Bref. Mon plus gros problème est le suivant : Quand je consulte la base de données, je vois bien que les commandes qui ne sont pas encore en cours de livraison n'ont pas de numéro de bon de livraison (table préfixe + "order_invoice", champ "delivery_number"). J'ai donc cherché à quel moment ce numéro était créé et envoyé en base de données. Je suis rapidement tombé sur la fonction setDeliverySlip() de la classe Order.php. Cette fonction me renseigne sur le fait qu'une facture DOIT pré-exister à mon bon de livraison. C'est le cas de toutes mes commandes dès le paiement, le problème ne vient donc pas de là. J'ai donc cherché où cette fonction était appelée, et je n'ai trouvé qu'une seule occurrence ! Dans la fonction changeIdOrderState de la classe OrderHistory.php. Voici la partie concernée : if ($new_os->invoice && !$order->invoice_number) { $order->setInvoice($use_existing_payment); } elseif ($new_os->delivery && !$order->delivery_number) { $order->setDeliverySlip(); } Il me semble que ce n'est pas optimum. De ce que je vois, si le nouveau statut implique la création d'une facture et que la commande n'en a pas encore, celle-ci est créée. Sinon, on s'occupe du bon de livraison. Pourquoi sinon ? Pourquoi ne pas s'occuper du bon de livraison AUSSI ? Il serait peut-être préférable de faire ceci : if ($new_os->invoice && !$order->invoice_number) { $order->setInvoice($use_existing_payment); } if ($new_os->delivery && !$order->delivery_number && $order->invoice_number) { $order->setDeliverySlip(); } Ainsi, la facture ET le bon de livraison peuvent être créés en même temps. Quoi qu'il en soit, ça ne résout pas mon problème. Malgré cette modification, malgré de nombreux changement de statut sur les commandes concernées, malgré avoir vérifié en base de données que mon statut demande bien la création d'un bon de livraison, rien n'y fait. Tant que je n'ai pas passé la commande en cours de livraison, mon bon de livraison n'est pas créé et son numéro n'est pas renseigné en base de données. Et à partir de là, je ne comprends plus. Si tout est bon, pourquoi le résultat ne correspond pas ? PS : Ah oui, dernière chose. Si je demande au site de générer le pdf du bon de livraison, concrètement en allant sur la page suivante : http://www.monsite.com/admin/index.php?controller=AdminPdf&token=trucbidule&submitAction=generateDeliverySlipPDF&id_order=XXXX Et que je remplace le id_order par celui de la commande dont je veux le bon de livraison, j'obtiens un bon de livraison de numéro LI000000 avec les bonnes informations à l'intérieur. L'outil de génération des PDF n'est donc pas en cause.

Grand classique, il m'est arrivé la même chose, plusieurs fois. Et à chaque fois c'était la plus petite commande que j'avais jamais eu, du genre 5 € plus les frais de port... A chaque fois la commande était à livrer sur Paris, et je suis sûr qu'on tomberait sur les mêmes adresse si on prenait le temps de les comparer entre toutes les boutiques victimes.

Bonjour Monsieur du Tertre, Comme vous le savez, les propos ne sauraient être qualifiés de diffamatoire qu'à partir du moment où ils ne relèvent pas de la réalité et qu'ils sont destinés à nuire à autrui. Si mes propos nuisent effectivement à Twenga, ils ne caractérisent pas pour autant un cas de diffamation puisque je n'ai fait que conter mon expérience avec cette entreprise. Twenga est donc le seul responsable de l'image que je donne de leur entreprise. De nombreux utilisateurs racontent, comme moi, qu'on leur facture des quantités invraisemblables de clics, parfois même dans des catégories où ils n'ont aucun produit. La moitié de la facture Twenga que je refuse de payer est constituée de pâte d'amande, de fruits secs et de pâte à tartiner. Je suis un vendeur de thé et d'infusion, et je vous met au défie de trouver l'un de ces trois produits sur ma boutique de thé. Autre point, le taux de rebond des visiteurs Twenga était de 90%. Twenga vend son trafic horriblement cher puisqu'il est censé être qualifié. Pourtant, le taux de rebond de Google est de 53% à peine ! Comment est-il possible qu'un moteur de recherche amène un trafic plus qualifié qu'un comparateur de prix ? Mon interprétation est que ces clics sont falsifiés, je ne vois aucune autre solution. Ensuite, je ne saurai me réjouir de la présence sur ce forum d'une personne venue faire l'inverse de ce que vous me reprochez : le mensonge positif, la publicité mensongère. Cette personne arrive avec ses gros chiffres sortis de nulle part pour faire croire que son entreprise est sérieuse. Je parie que je suis compté parmi ses "3500" clients. Combien de ces milliers de clients sont dans ma situation et dans celle de tous les utilisateurs du module prestashop de Twenga ? 90%, comme le taux de rebond ? Dans ce cas, est-il bien légitime de parler de clients si ceux-ci sont piégés pour se faire extorquer un maximum d'argent ? Ne devrait-on pas plutôt parler de 3500 victimes ? Je m'interroge. Alors je suis tout à fait pour le dialogue cordial, mais il n'y en a ici aucun. D'un côté des utilisateurs qui se plaignent, de l'autre une entreprise qui fait la sourde oreille et fait sa publicité à coup de statistiques manipulées. Avant même de parler de cordialité, où est le dialogue ? Vous nous conseillez de les solliciter en cas de problème mais notre problème est leur existence et leur mauvaise foi. Ils ne tournent que pour facturer et il m'a fallu plus d'un mois pour qu'un seul de mes produits ne soit replacé dans la bonne catégorie (sur les 10 ou 15 qui s'étaient égarés). Twenga_support, ce pseudonyme même est une contradiction : il n'y a aucun support chez Twenga. Tant que j'acceptais de payer les yeux fermés, je n'ai pas pu avoir de réponse à aucun de mes problèmes. Lorsque j'ai arrêté de payer (en refusant le prélèvement automatique, c'est que la machine est bien rodée), d'un seul coup j'étais le centre du monde et je recevais plusieurs coups de fil par jour pour me forcer à payer. J'y ai mis la condition que mes produits soient correctement classés, et on m'a répondu qu'ils ne le seraient que lorsque j'aurai payé. Est-ce qu'il n'y aurait pas comme une forte odeur de malhonnêteté dans ces pratiques ? Alors le dialogue, je suis pour, la cordialité, tout à fait, j'en veux. Mais pour autant ce ne peut être possible que si la volonté est partagée, et ce n'est pas le cas. EDIT : la procédure de sauvegarde judiciaire n'est pas non plus une diffamation, je l'ai lue sur clubic : Twenga est placé sous sauvegarde judiciaire

Effectivement, j'ai bien été contacté par Twenga, de nombreuses fois, pour me forcer à payer une facture illégitime gonflée de clics effectués dans des catégories où je n'ai aucun produit. En fait il ne s'agit pas d'une solution qui s'adapte à chacun, mais d'une seule et même solution adaptée à tous : payez, et arrêtez de vous poser des questions. Quant à la pérennité et au capital confiance, la procédure de sauvegarde judiciaire parle d'elle-même...

Dans l'hypothèse où ces clics sont des faux pour grossir les factures des clients, le taux de rebond devient tout à fait normal. Après tout, il est très simple de simuler une visite avec un ping, et la manoeuvre rapporterait à Twenga 1 € tous les 5 ou 6 pings. Ce serait malhonnête, mais je comprends que ce soit tentant.

Ce n'est pas une grosse perte si vous n'arrivez pas à être référencés sur Twenga. J'ai tenté l'expérience récemment. Non seulement j'ai du modifier moi-même le script Twenga pour corriger un export incompris par le robot Twenga (les scripts Twenga ne se comprennent même pas entre eux), mais en plus de ça on m'a facturé des centaines de clics de produits rangés dans de mauvaises catégories à un prix exorbitant. Le tout alors que le trafic de Twenga possède le plus gros taux de rebond que je n'ai jamais vu (à croire qu'ils nous facturent de visites fictives) et que le taux de conversion est proche de 0 % quand il est dans mon cas de près de 3 % pour les autres services similaires. Enfin, les rares conversions ne dépassent pas la dizaine d'€uros, à croire que Twenga utilise ce qu'il me facture pour faire semblant que son service fonctionne ! Et je ne parle pas du dialogue de sourd avec le service client qui essaye de me convaincre que je dois payer ma facture parce que j'ai reçu le trafic. Alors oui, j'ai reçu le trafic, mais si je paye aussi cher c'est pour du trafic qualifié, pas pour qu'on m'envoie des visiteurs qui cherchent de la pâte d'amande ou du sirop d'érable alors que je ne vends que du thé... Et je ne suis pas le seul à m'être fait facturer du vent : on est un paquet ! En bref, ça marche mal, mais ça facture bien. FUYEZ !

Twenga ? C'est triste à dire, mais ça commence à être reconnu comme une arnaque. J'ai tenté l'expérience moi aussi. Non seulement j'ai du modifier moi-même le script Twenga pour corriger un export incompris par le robot Twenga (les scripts Twenga ne se comprennent même pas entre eux), mais en plus de ça on m'a facturé des centaines de clics de produits rangés dans de mauvaises catégories à un prix exorbitant. Le tout alors que le trafic de Twenga possède le plus gros taux de rebond que je n'ai jamais vu (à croire qu'ils nous facturent de visites fictives) et que le taux de conversion est proche de 0 % quand il est dans mon cas de près de 3 % pour les autres services similaires. Enfin, les rares conversions ne dépassent pas la dizaine d'€uros, à croire que Twenga utilise ce qu'il me facture pour faire semblant que son service fonctionne ! Et je ne parle pas du dialogue de sourd avec le service client qui essaye de me convaincre que je dois payer ma facture parce que j'ai reçu le trafic. Alors oui, j'ai reçu le trafic, mais si je paye aussi cher c'est pour du trafic qualifié, pas pour qu'on m'envoie des visiteurs qui cherchent de la pâte d'amande ou du sirop d'érable alors que je ne vends que du thé... Et je ne suis pas le seul à m'être fait facturer du vent : on est un paquet ! En bref, ça marche mal, mais ça facture bien. FUYEZ !

Twenga ? C'est triste à dire, mais ça commence à être reconnu comme une arnaque. J'ai tenté l'expérience moi aussi. Non seulement j'ai du modifier moi-même le script Twenga pour corriger un export incompris par le robot Twenga (les scripts Twenga ne se comprennent même pas entre eux), mais en plus de ça on m'a facturé des centaines de clics de produits rangés dans de mauvaises catégories à un prix exorbitant. Le tout alors que le trafic de Twenga possède le plus gros taux de rebond que je n'ai jamais vu (à croire qu'ils nous facturent de visites fictives) et que le taux de conversion est proche de 0 % quand il est dans mon cas de près de 3 % pour les autres services similaires. Enfin, les rares conversions ne dépassent pas la dizaine d'€uros, à croire que Twenga utilise ce qu'il me facture pour faire semblant que son service fonctionne ! Et je ne parle pas du dialogue de sourd avec le service client qui essaye de me convaincre que je dois payer ma facture parce que j'ai reçu le trafic. Alors oui, j'ai reçu le trafic, mais si je paye aussi cher c'est pour du trafic qualifié, pas pour qu'on m'envoie des visiteurs qui cherchent de la pâte d'amande ou du sirop d'érable alors que je ne vends que du thé... Et je ne suis pas le seul à m'être fait facturer du vent : on est un paquet ! En bref, ça marche mal, mais ça facture bien. FUYEZ !

Personnellement je vais passer mon tour en ce qui concerne de faire appel à la justice : je n'ai perdu que 35 € dans l'affaire, et un peu de temps, mais je ne pense pas qu'on m'accorde quoi que ce soit pour si peu de dommages. Je vous souhaite néanmoins bon courage et si je peux faire quelque chose, n'hésitez pas à me demander ! Par exemple un témoignage écrit. EDIT du 13/02 : je viens d'avoir un nouvel appel de "Nathalie" de Twenga, pour m'inciter à payer ma facture. J'explique le problème, et s'ensuit un véritable dialogue de sourd plein de réponses préformatées. Elle me dit que je leur doit cette somme parce que j'ai reçu le trafic correspondant, je réponds que la somme correspond à du trafic qualifié, alors que là l'essentiel vient de catégories dans lesquelles je n'ai pas un seul produit, elle me réponds qu'ils vont recatégoriser mes produits (pour le quatrième fois), mais qu'il faut que je paye d'abord, etc... Mais j'ai néanmoins compris un nouvel élément, peut-être parce qu'elle a fait une bourde sans faire exprès : en fait mon flux n'avait pas été récupéré avant que je ne cesse de payer. Twenga avait procédé à un ajout de mes produits par crawling automatique sur mon site. Pas étonnant que ce soit n'importe quoi ! Ce n'est qu'après que j'aie bloqué les paiements qu'enfin ils ont récupéré mon flux et que les choses ont commencé à s'arranger. Sauf pour trois produits, qui sont ceux qui comptabilisent 80% des clics de la facture qu'on me présente aujourd'hui. Vous avez dit bizarre ? J'ajouterai incompétent ! Plus d'un mois après mon inscription sur Twenga et de multiples uploads, mon logo n'y est jamais apparu...

Non seulement j'ai du modifier moi-même le script Twenga pour corriger un export incompris par le robot Twenga (les scripts Twenga ne se comprennent même pas entre eux), mais en plus de ça on m'a facturé des centaines de clics de produits rangés dans de mauvaises catégories à un prix exorbitant. Le tout alors que le trafic de Twenga possède le plus gros taux de rebond que je n'ai jamais vu (à croire qu'ils nous facturent de visites fictives) et que le taux de conversion est proche de 0 % quand il est dans mon cas de près de 3 % pour les autres services similaires. Enfin, les rares conversions ne dépassent pas la dizaine d'€uros, à croire que Twenga utilise ce qu'il me facture pour faire semblant que son service fonctionne ! Et je ne suis pas le seul à s'être fait facturer du vent : on est un paquet ! En bref, ça marche mal, mais ça facture bien. FUYEZ !

Bonjour à tous. Je viens moi aussi partager mon expérience désastreuse avec Twenga, que je considère pour ma part comme des escrocs dorénavant. J'ai réussi à limiter ce que je considère comme une arnaque à 34 € environ, mais on me réclame encore plus d'une centaine d'€uros, le tout pour un chiffre d'affaire Twenga ne dépassant pas les 60 €, uniquement réalisé sur des petites commandes impossible à marger (deux commandes de 2,5 € hors frais de port, et plusieurs de 5 et 10 €). Non seulement le trafic de Twenga est mauvais, avec un fort taux de rebond et un taux de conversion misérable, mais en plus les rares conversions ne rapportent rien du tout ! Voici l'histoire complète : Début janvier, j'installe le script Twenga sur ma boutique de thé féeduthé.com. Rapidement, mon contrat est accepté et le prélèvement PayPal amorcé. Jusqu'ici c'est pratique, rapide, génial ! J'ai vite déchanté. Dès le départ, mes produits sont classés n'importe comment. Le "Thé noir gourmand - Orange, pâte d'amande" est classé avec la pâte d'amande, par exemple. Et bizarrement, tous mes produits mal classés génèrent une quantité de clics incroyable en comparaison des autres. J'envoie un message à Twenga, et pas de réponse. Mon logo, envoyé dès le premier jour d'activation de mon compte, ne s'affiche pas. J'ai pourtant fait une image pile poil de la bonne dimension dans le bon format, juste pour eux. Mi-janvier, ma "consommation" a déjà atteint 35 €. J'envoie encore un message pour dire que je ne vais pas payer pour des clics inutiles puisque non qualifiés. La seule réponse que j'obtiens est un prélèvement sur mon compte PayPal ! Je ne savais même pas qu'ils avaient le droit de me prendre des sous, comme ça, sans que j'ai mon mot à dire. Je contacte encore Twenga, et sans réponse, je trouve le moyen de refuser les prélèvement PayPal de Twenga. Je modifie également leur script natif prestashop afin d'essayer de rendre l'export plus pertinent. J'envoie de nouveau mon logo dans l'interface prévu à cet effet. Ceci fait, je constate un mieux, sauf sur quelques produits toujours mal classés. Par exemple, le thé noir pâte d'amande est toujours classé dans la pâte d'amande, le thé vert amande noix de coco est toujours classé dans les fruits secs (!!!) et le thé vert au sirop d'érable et aux noix est classé dans "Douceurs à tartiner > Sirop d'érable". Ces trois produits cumulent plus de 150 clics ! Fin janvier, une facture de 82 € est émise, sur laquelle environ 50 € sont facturés sur mes produits mal classés, puisque tous les produits bien rangés ne reçoivent pratiquement aucun clics. Sur les 32 € restant, il y a 30 € de facturés sur des produits qui n'ont JAMAIS été vendus à un seul visiteur Twenga, sur des centaines de clics. C'est notamment le cas de mes caramels mous qui ont cumulé plus d'une centaine de clics sans qu'une seule vente ne soit réalisée. Pourtant, j'estime mon prix de vente très raisonnable, et mes frais de port sont plancher ! 0 % de conversion là dessus, c'est inexplicable, quand le taux de conversion moyen de ma boutique est plutôt bon pour Adwords par exemple ( 3 % ). Le paiement automatique échoue donc, et, étrangement, le dialogue avec Twenga peut enfin s'amorcer. Il aura donc fallu les toucher au porte-monnaie pour qu'ils m'écoutent. J'explique le soucis, et leur réponse est la pire de toutes : une réponse préformatée dans laquelle on me prend clairement pour un con. En gros, on m'explique que je dois mettre mon fil d'ariane dans le champ catégorie de mon flux, et que pour mon logo je dois l'envoyer en utilisant l'interface prévu à cet effet dans mon espace marchant. Je regarde mon flux, et mon champ catégorie contient... mon fils d'ariane ! Logique, puisque j'utilise leur propre script ! Je répond une première fois cordialement que j'ai fait tout ça, et qu'on me prend pour un con. Je reçois un coup de téléphone ! La femme me propose un avoir de 35 € (la première facture) à valoir sur ma facture de février, si je paye celle de janvier. Elle me promet également que mes produits ont été recatégorisés correctement. Mais pour le vérifier, je dois payer ma facture de 82 €, parce qu'en attendant mon compte est suspendu et je ne peux rien vérifier. J'explique que je ne paierai pas pour du vent, et je réclame qu'on me déduise au moins les clics des produits mal rangés, quitte à prendre sur moi et à payer les 30 € de facture sur les clics de produits JAMAIS vendus. Je demande également une échéance de paiement, le temps de vérifier que mes produits sont bien référencés dans les bonnes catégories. Seulement sous cette condition je consentirai à payer ma facture Et là encore, la pire réponse possible. On me refuse mes conditions, sans rien me proposer d'autre, et on me dit que c'est de ma faute si mes produits sont mal rangés parce que je dois faire apparaître mon fil d'ariane dans le champ catégorie (je rappelle que c'est le cas depuis le premier jour d'activation de mon compte), et que pour mon logo je peux utiliser l'interface du site ou leur envoyer par mail. Elle m'informe aussi que je peux mettre un plafond mensuel pour gérer ma facturation. Ce plafond est au minimum de 100 € (dans le vent), et je l'ai effectivement configuré dès le premier jour. Et ça marche tellement bien qu'on m'a réclamé au total pour le mois de janvier 116 €... Depuis quand 116 € ne dépasse pas le plafond de 100 € ? Bon, là, je vois carrément rouge. J'explique que ce n'est pas en facturant du vent à ses clients que Twenga va sortir de sa procédure de sauvegarde judiciaire. Alors oui, leurs résultats sont "prometteurs" sur la fin 2012, mais si c'est en arnaquant leurs clients, ils ne seront pas prometteurs longtemps ! Je souhaite donc à la dame bon courage dans sa future recherche d'emploi, en espérant que Twenga ferme rapidement et définitivement ses portes. Je fais le bilan, et l'expérience Twenga m'a coûté 34 €, et rapporté 60 € de chiffre d'affaire, sur lequel ma marge n'a pas du dépasser les 10 €. J'ai donc perdu 24 € pour avoir un peu plus de trafic non qualifié sur mon site et gonfler mon chiffre d'affaire de 60 €. Je ne renouvellerai pas l'expérience et ne souhaite à personne l'aventure Twenga. FUYEZ !

Dans le dernier code il y a un {if} qui teste si il y a des tags ou pas. S'il n'y en a pas, tout ce qui est entre le {if} et le {/if} ne s'exécute pas ! Pour le product-list je ne comprends pas. Le code est tronqué où ? Moi je le vois en entier :s Je n'ai pas bien compris non plus la demande du visual tag avec référence à un CMS, désolé.

Pour ne pas afficher le code lorsqu'il n'y a pas de tag, ceci devrait fonctionner (non testé) : {if isset($product->tags) && $product->tags} {assign var='id_lang' value=Language::getIdByIso($lang_iso)} {assign var='productTags' value=$product->tags} {l s='Ce produit a les tags suivant :'} {foreach from=$productTags[$id_lang] item=productTag name=productTags} <a href="{$base_dir}index.php?controller=search&tag={$productTag|escape:'url'}"><strong>{$productTag}</strong></a>{if !$smarty.foreach.productTags.last}, {/if} {/foreach} {/if} Pour le product-list.tpl, essayez peut-être comme ça (non testé) : {if isset($product.tags) && $product.tags} {assign var='id_lang' value=Language::getIdByIso($lang_iso)} {assign var='productTags' value=$product.tags} {l s='Ce produit a les tags suivant :'} {foreach from=$productTags[$id_lang] item=productTag name=productTags} <a href="{$base_dir}index.php?controller=search&tag={$productTag|escape:'url'}"><strong>{$productTag}</strong></a>{if !$smarty.foreach.productTags.last}, {/if} {/foreach} {/if}

Non j'ai fait le module moi-même Je parle d'AdWords. Effectivement je peux toujours utiliser l'argent pour autre chose, mais ce que je veux dire c'est d'être obligé de payer pour essayer Google Merchant Center, et d'en être banni malgré tout sans la moindre explication ni avertissement ! Venant de n'importe quelle entreprise, ça serait intolérable. J'en sais quelque chose, Twenga m'a fait un truc un peu similaire : mes produits étaient (et sont toujours) référencés dans des catégories improbables, et pourtant des dizaines de clics sont facturés chaque jour, et le pire c'est qu'ils se servaient directement sur mon compte PayPal sans jamais répondre à mes plaintes au support technique. J'ai du couper le robinet pour qu'enfin on me contact et on prenne en compte mes observations... Dingue quand même !

Merci ! J'ai retiré l'encodage des caractères accentués en HTML et je retombe en dessous des 70 caractères. L'exemple est en effet américain, mais je n'ai pas trouvé d'exemple français et les spécifications ne me semblaient pas toutes très claires. Bref, merci encore, peut-être qu'avec de la patience la correction de ces quelques petites erreurs m'apportera un allègement de la peine qui m'est tombée dessus comme la misère sur le tiers-monde :s Le pire est quand même d'avoir payé pour rien - pour l'instant -, et de ne même pas avoir d'information sur la raison du problème !

Merci en tous cas pour ta réponse. Penses-tu qu'un de ces éléments aurait pu constituer une infraction suffisante pour avoir mon compte suspendu sans préavis (et surtout sans en être informé ni alerté sur le problème) ?

Justement ! J'avais compris le problème des infractions et de la qualité des données. Mon problème en particulier est plus étrange. Pour commencer je ne sais pas combien j'ai fait "d'infractions" puisqu'on ne m'en a jamais signalé une seule. Donc impossible de savoir combien de temps va durer la suspension, ce n'est marqué nulle part. Mais le plus bizarre, c'est ça : Ca a toujours été ainsi, depuis le début. Jamais le moindre problème détecté dans mon flux, jamais le moindre signalement de quelconque erreur ou autre, je nage en plein brouillard. En résumé, mon aventure c'est : Inscription -> Suivi scrupuleux des étapes -> Création d'un campagne AdWords (avec paiement de 25 € pour tester le service) -> Insertion des produits (Hourra ! Ca marche !) -> (mais deux jours plus tard) Retrait des produits et suspension -> Plus rien Et du début à la fin, pas le moindre message d'erreur, pas le moindre mail, tout va pour le mieux dans le meilleur des mondes, sauf que mes produits ne sont pas insérés dans Google Shopping pour "Violation" de quelque chose que je connais et que j'ai toujours respecté ! Je désespère sérieusement. De plus, comme mon flux se met à jour tous les jours, j'ai pu violer indéfiniment depuis des semaines quelque chose, mais comme tout a toujours été marqué comme OK et qu'on ne m'a rien signalé, je n'ai pas pu m'en rendre compte.

Bonjour, Impossible d'avoir mes produits référencés sur Google Shopping. J'ai tout essayé ces deux derniers mois, et je n'ai pas trouvé d'où venait le problème, ni comment obtenir une réponse de Google. Voici ce que mon tableau de bord affiche : Maintenant voici mon flux : http://www.feeduthe.com/export_google.php Je ne vois qu'un flux gentillet, avec plein de produits parfaitement innocents, qui a passé avec succès la validation XML, et le tout dans une syntaxe qui est une stricte copie des exemples fournis par Google ! Mais qu'ai-je donc fait de mal ??? Je précise également que oui, j'ai associé une campagne AdWords créditée avec de l'argent réel (et non un bon de réduction). J'ai fait tout dans l'ordre et de la manière que Google demande ! Si quelqu'un avait par hasard une intuition, une expérience, ou quoi que ce soit à partager, je lui en serait éternellement reconnaissant ! Merci.

Thanks Yzzy for the solution. I had the same problem, I went to product-list.tpl, but I missed this issue ! You saved me a lot of time, and I really thank you for that

Gazoline > Le thème mobile n'a jamais marché pour moi, dès la 1.5.2, celle avec laquelle j'ai fait mon entrée dans ce merveilleux monde de Prestashop 1.5 :s Vivement la 1.5.3.2, ou peut-être la 1.5.3.1.1, tant qu'on y est...

Bon, finalement je m'en suis sorti. Du coup, je vais implémenter les scripts de la 1.5.3 un par un, au fur et à mesure, nuit après nuit, en les testant immédiatement après histoire que la boutique ne connaisse pas de période de maintenance pendant qu'il y a des visites. C'est d'un compliqué, pour pratiquement rien changer...

Après m'être débattu toute la matinée avec le 1.5.3, je voulais repasser en 1.5.2. Le panier ne marchait plus, le menu en haut était devenu immonde (le thème ne s'appliquait plus, allez savoir pourquoi), le back-office m'affichait des informations différentes de celles présentent en front-office... bref, une horreur. Et là surprise, ma sauvegarde de 1.5.2 ne fonctionne pas, sans doute la 1.5.3 a modifié un truc en BDD ou autre. Bref, là je suis grave dedans...