djfm

Hi lennartoester, Thanks for your report. I took the liberty of editing your original post to add the link to your bug report so that people looking on an answer here can follow the status of the bug on forge

Bonjour à tous, Nous avons eu un incident technique sur notre plate-forme de gestion des traductions (Crowdin) qui a conduit à la perte temporaire des traductions dans certaines langues. Si vous mettez à jour vos traductions 1.6.0.11 maintenant vous devriez récupérer les traductions complètes. Nous travaillons en ce moment à la résolution permanente de ce problème.

Après avoir regardé de plus près, il semble que cette approche ait été retenue pour gérer le cas où on a plusieurs réductions sur le prix : on peut avoir une réduction pour le groupe de client et en plus un prix spécifique par exemple. Donc on ne peut pas simplement regarder le prix spécifique, c'est un tout petit peu plus compliqué que ça. Bien sûr, il y a de meilleures solutions, et on va traiter ça.

Exactement On est arrivés à la même conclusion en même temps.

@Atch, @Coeos.pro : pour les 5.01%, si l'explication vous intéresse, c'est parce que le template essaye de calculer la réduction en pourcentage à partir de la différence entre prix après réduction et prix avant réduction, en ignorant donc le fait que ce coup ci, on savait déjà que c'était une réduction de 5% qu'il fallait afficher. Comme les prix sont arrondis, on ne retombe pas forcément sur les 5% initiaux... mais c'est bien une réduction de 5% qui est calculée. On va corriger ça dans la 1.6.0.12 !

Hello doekia, les commandes existantes conservent leur type d'arrondi, migration ou pas migration (si vous générez une facture en mode "Article", puis changez le type d'arrondi en mode "Total", alors la facture en mode "Article" reste en mode "Article").

Bonjour Atch, Pour ce problème là, au moins la partie 132.57, c'est une question de configuration. Si vous allez dans "Préférences" > "Paramètres généraux", et que vous choisissez "Arrondir pour chaque ligne" dans "Type d'arrondi", la somme sera bien égale à 132.57. Le coeur du problème, c'est que les prix hors-taxes ont ici plus de deux décimales (beaucoup de logiciels empêchent pour cette raison de saisir des prix avec plus de décimales que les décimales affichées pour la devise). Il y a donc un arrondi à chaque ligne pour l'affichage. Or, lors du calcul du total, l'arrondi est fait en dernier, d'où la différence. En mode "Arrondir pour chaque ligne", le total du panier est bien égal à la somme des lignes. C'est le paramètre "Type d'arrondi" qui détermine quand les arrondis sont faits. "arrondir pour chaque article" => tout va être cohérent dans le panier, mais des écarts risquent d'apparaître dans le récapitulatif de TVA des factures "arrondir pour chaque ligne" => le prix de la ligne ne sera pas forcément égal au prix unitaire affiché x la quantité, mais la somme des lignes sera égale au total à payer. De légers décalages sont possibles dans le récapitulatif de TVA sur la facture. "arrondir le total" => le total à payer ne sera pas forcément égal à la somme des lignes, mais les erreurs d'arrondi seront globalement minimales. Si vous avez la possibilité d'utiliser des prix hors taxes à deux décimales uniquement, alors vous devriez observer beaucoup moins de problèmes.

Hi doekia, Can you please explain how you get the 77.35 total to pay? I have a feeling it might be a template issue (are you using the default one?), because here is how it looks like on my PrestaShop 1.6.0.11 : Yes, there is a 1 cent error, and we're on it. But where is the 8.6€ error you report here? Here is the corresponding invoice, (still 1.6.0.11, with the 1 cent error that we're working on): And here is what it will look like after the next tax iteration (can you see anything wrong ?) : The rounding errors that you see today should never exceed 1 cent per tax rate. They are only due to the fact that tax bases are rounded before the rounded VAT is added. If you have 2 different tax rates in your cart you might have a 2 cent error, but no more. By default, in 1.6.0.11, rounding is done at the latest possible time.

Hi Doekia, Problem 1/ is indeed a rounding issue, well, kind of. It arises because the cart computes separately the tax base and the tax then sums them : round(4.125, 2) + round(4.125*20/100, 2) = round(4.125, 2) + round(0.825, 2) = 4.13 + 0.83 = 4.96 On the other hand, the product sheet computes : round(4.125*120/100, 2) = 4.95. So this is rounding related. I'm working on the issue on this repository: https://github.com/djfm/PrestaShop/tree/taxes-patch, you're welcome to check it out and comment, keeping in mind that it is at this point still a work in progress, because changing the way the cart computes totals has a lot of consequences. Please feel free to contact me in private if you want to discuss the issue further! And slight correction to Xavier's post, I'm not the one working on issue 2/

Hi, to anyone interested in the translation thing: we've removed version 1.6.0.9 from Crowdin (it was getting old anyway), seems like it was the only way to clean things up in the future, we'll try to have at MOST 2 versions on Crowdin to make things easier for the system: most of the time there will be only the latest stable version, and during release periods, we'll add the upcoming version too We'll switch to this new workflow right after 1.6.0.11 is out, which means we will remove 1.6.0.10, leave only 1.6.0.11 for a while, and then add the next version a while before the next release. The should be much less opportunities for translations to propagate to the wrong version

Hi karolwild, In theory translations should be ported automatically from 1.6.0.10 to 1.6.0.11 (and from any version 'n' to any version 'n+1' when we publish it). In practice you're unfortunately right: it seems Crowdin sometimes makes a "mix" of versions when porting the translations. I'm looking at the options to fix this, and hopefully nobody will need to do the translations again. Please give us some time to try and find the best solution, and thank you for reporting the issue!

Glad it's working as you expected using "round on total" This one is on purpose: it should be impossible for an invoice to change after it has been generated once, otherwise you risk getting into even worse accounting issues

Hi MacRoy, Which language are you talking about please?

Hi doekia, Thanks for reporting this. I'm afraid I cannot reproduce your issue exactly, can you please provide more details on how you obtained invoice 10? I attach the invoice I got when trying to reproduce the issue. The settings I have are as follows: - "Produit à 4.95 TTC": pre-tax retail price = 4.125000, retail price with tax = 4.95 (VAT = 20%) - "Produit à 4.95 TTC avec 1% remise": pre-tax retail price = 4.125000, retail price with tax = 4.95 (VAT = 20%), specific price = -1% In my invoice the specific price is correctly applied, but it doesn't seem to be in yours, I don't understand why. Maybe you created the 1% discount using another method? IN0000010 - kind of.pdf

No no they are merged, I don't know git well enough to explain why when you compare both branches you see so many differences (https://github.com/PrestaShop/PrestaShop/compare/1.6...1.6.0.10), but the developers assure me that everything is merged. Branch 1.6 should only have additional stuff, not less. So, @PxlTech "last updated version is 1.6 and all new changes and updates already added to 1.6 also ?", then answer is yes! Furthermore, the regressions I was speaking about yesterday are fixed, so feel free to keep testing