Matthieu Biart

Bonjour a tous, Un petit passage sur ce post - non pas pour discuter du bug (si vous me connaissez, vous savez bien que ca se passe toujours sur le bug tracker ) mais - pour rappeler que TOUS les rapports de bugs sont traites. Et que ce n'est pas parcequ'il y a "des centaines de bugs" en attentes que le votre ne sera "jamais" corrige. Notre politique actuelle de developpement est telle que ces dernieres semaines ont ete bien plus productives sur la realisation de nouvelles fonctionnalites que sur la correction de bugs, mais ca s'inversera ne vous en faites pas. Les developpeurs ne peuvent pas - croyez moi on aimerai bien pourtant - etre au four et au moulin en meme temps. J'en profite pour vous signaler que l'heure de la correction de ce bug a sonne.

Bonjour a tous, Comme l'atteste le rapport de bug #5975, ces problemes ont ete resolu.

Hi everyone! First of all I'd like to correct something: I'm very interested on where inside the PrestaShop source code you find out that. Since the PrestaShop source code is open, you can see by yourself that we only store I'd say 5 values maximum simultanously inside the user cookie. Which are indeed the PrestaShop customer ID, its cart ID and some other primary data IDs. Secondly, if the PrestaShop cookie is "that big" it is because it is encrypted (via the blowfish algorithm) for security reasons and therefore bigger than the few bytes required by those five values. If you want to remove this cookie encryption (that will for sure reduce significantly its size) and let your customer bypass the authentication process by changing their customer ID (taking other ones or even the merchant one), you're welcome. The source code is available, you can change it by yourself. But the official code source is secure and therefore technically need a big cookie.

Hi Nelit! Thank you for this contribution :-) I still have questions. What about voucher/discount coupon, shipping & handling? Moreover, do the PrestaShop order process and invoice fit all legal requirements?

Hi everyone! Any news about the voucher/discount coupon tax application?

Pourriez-vous nous detailler la configuration de vos produits de maniere a reproduire le bug ? Leur prix HT, leur taxe, leurs prix degressifs. Merci.

Bonjour Maurice, Je comprends bien la problematique. Le probleme etant que cela ne resulte pas d'un bug du logiciel mais d'une fonctionnalite qui ne repond pas a vos attentes. Cela n'a rien a voir avec les rabais, mais veritablement avec la methode de calcul HT de PrestaShop. En effet, le prix "paye" est le prix affiche. Ainsi si la fiche produit affiche un prix a deux decimales, alors le prix a payer sera a deux decimales. Que ce soit pour le HT ou le TTC. Par consequent si vous configurez votre PrestaShop pour afficher des prix HT a vos clients (ici le groupe revendeurs), les prix saisi a 6 decimales seront arrondi a 2 avant tout autre calcul (rabais specifique, rabais de groupe de client, ...). La etant l'incompatibilite avec vos calculs exiges. Je vous invite une nouvelle fois a reporter ce probleme sur la "fiche" taxe et loi de la Suisse. Merci pour ces remontees.

Mea culpa. J'avais commit sur la mauvaise branche (la 1.4... :red: ). L'erreur est desormais corrigee. Vous trouverez le correctif a la revision 2913 ;-)

Je viens de corriger un probleme sur les arrondis quand les prix degressifs etaient configure sur le meme produit. Mais sans scenario de votre part, je ne peux confirmer que cela corrige bien votre probleme. Pourriez-vous de votre cote tester apres une mise a jour SVN. Et si cela ne fonctionnait toujours pas, reporter sur le bug tracker le scenario complet de la configuration de votre produit ainsi que des actions effectuees lors de la commande. Merci par avance.

Et je reconfirme que c'est tout a fait normal. Je travaille actuellement sur les problemes d'arrondis lors de l'utilisation de prix degressifs. Merci pour les liens, je vais y jeter un coup d'oeil. Edit: Je viens de lire votre post ainsi que les rapports de bugs. J'y ai repondu dans votre dernier rapport.

bonjour Matthieu le bug celui de la ligne en trop dans le screenshot ? a bientot La ligne n'est pas en trop, mais le detail des produits personnalises. Ici une seule personnalisation donc une unique ligne. (On peut y distinguer le texte saisi par le client "RAL1117"). Si un client commande 5 produits "identique" mais avec chacun une personnalisation differente, on voit bien apparaitre 5 "sous-lignes" (une par personnalisation) en plus de la "generale".

Bonjour a tous, En ce qui concerne le premier bug souleve dans ce post (celui avec le screenshot) c'est resolu (SVN 1.3.x). Pour le reste nous travaillons a reproduire les bugs.

Bonjour a tous, Comme dit dans ce post, le nouveau module Paypal corrige ce probleme d'arrondi. jp77: Pourriez-vous soumettre un rapport de bug dans le bug tracker de maniere a reproduire ce probleme ? Merci par avance.

Bonjour Maurice, Tout d'abord, merci pour ce post interessant et le rapport qui y est lie. Je vais tenter d'y repondre le plus clairement possible. C'est normal, cette fonctionnalite n'existe actuellement pas dans PrestaShop. Je vous invite a poster (en anglais) dans le forum "Tax & law" sur le topic reserve a la suisse ce probleme de maniere a ce que nous implemention cette fonctionnalite au plus vite. Vous vous trompez, et je vais vous expliquer pourquoi. C'est exact, 6 decimales sont stockees en base de donnees, mais le prix final affiche - et donc paye par le client - est bien a 2 decimales. Pas d'accord. 6 decimales suffisent. Les problemes ayant existes sur les versions anterieures etaient du a une defaillance (bugs) du systeme de calcul de prix. Tout a fait. Apres discussion avec Alain (responsable du module Paypal natif), avec la nouvelle version du module (disponible en natif dans la version SVN 1.4, ou en libre acces sur notre page de telechargement pour PS 1.3.x) les prix des produits communiques a Paypal (qui ne le sont que si l'option selectionne est le mode "Standard") est bien TTC et a 2 decimales. Il ne peut donc pas(plus) y avoir de probleme de correspondance entre PrestaShop et Paypal. Je suis d'accord, et c'est tout a fait normal. Il faut faire un choix sur le moment de l'arrondi, et ce choix impacte directement (c'est mathematique) le resultat final. (D'ou la difference de 3 centimes dans votre exemple). Ce choix est fait de maniere correcte par PrestaShop a partir de la methode d'affichage (et donc de paiment) des prix. Si vous selectionnez "Prix TTC", alors le HT ne sera jamais arrondi. Seul le TTC le sera. Par contre si vous selectionnez "Prix HT", le HT sera arrondi, et les taxes s'appliqueront sur un montant deja a 2 decimales. Vous pouvez trouver cette option dans la configuration de vos groupe de clients. Exactement. Mais... ... pas du tout. La precision a 6 decimales est requise pour arriver a des prix TTC ronds. Merci a vous. J'espere avoir repondu a vos attentes. N'hesitez pas a conmpleter ce post si vous avez des questions supplementaires, je me ferai un plaisir de vous repondre.

I'm not so sure of that I wasn't talking about the 2 euros but the 25% VAT applied. From the carrier (DHL) or from the highest product tax rate (Rubik's Cube)?