Occam

Oops, I didn't check the tax page, sorry. And, yes, discount on the cheapest product, but with the condition just one specific category. The condition is ignored now. It wasn't like this before.

@mdekker said in Wrong amounts when applying discount cart rule: Order is computed with a tax rate 13% while the tax in fact is 21% Actual tax is still set to 13% I think, due to the tests, which makes the tax rule's name confusing. ??? The cheapest product of all ordered products is discounted, no matter if it’s part of the action or not. Yes, it's been configured like that Where? Not in the cart rule. And btw it looks rather unformatted: Strange, that must be a template problem. I could have left an extra 0 in it. This was problem in former releases of PS 1.6.1 One fo the reasons why it was changed to a rate without decimals. Taxes can be entered with three decimals (both db and admin pages handle it like that), so we should format all the percentages like that, I guess. number_format is basically the same function, except it's a raw PHP function rather than a ported C one. Ok, no problem for me. For users in Germany and all other countries where tax decimals are uncommon on invoices I'd recommend to change /pdf/invoice.tax-tab.tpl, line 71, from * {$line.rate} % to * {$line.rate|round:"0"} %

Made some tests. I'm not sure if this is what you really wanted: (Average?) tax for products discounted Order is computed with a tax rate 13% while the tax in fact is 21% Same on invoice: The cheapest product of all ordered products is discounted, no matter if it's part of the action or not. I had my reasons when I convinced the PrestaShop team to show the tax rate without decimals in tax details. I'm sorry, but in my view this change in OrderInvoice.php is not a real improvement, but a step back: You replaced $rate = sprintf('%.3f', $row['tax_rate']); with $rate = numberformat($row['taxrate'], PSPRICEDISPLAYPRECISION_); And btw it looks rather unformatted:

Great! Really a tremendous effort. Anyway, take my advice and don't work through all day and night, you don't need to set a new speed record after all. ? Eager to walk through the code and do some testing, but later in my leasure time.

@mdekker said in Wrong amounts when applying discount cart rule: The contextual value function takes the average tax of the cart. This is why you see different discounts when changing the other product. It seems like it has nothing to do with the category in which the discount is valid. It has definitely nothing to do with any category!

@mdekker said in Wrong amounts when applying discount cart rule: _PS_PRICE_COMPUTE_PRECISION_ [..] Not really a joke, this was just a touching up. The define is now going to be used to determine the amount of decimals to save in the database (6). Rounding should only occur on the configured places. I totally agree, though simplifications like this seem to be the Preston hallmark since 1.6.1, undermining the main code.

One more experience I made: Given, the cart includes products with different tax rates, the cart discount (as applied above) - decreases with every added product with a different taxe rate, and - increases on the other hand with every other product with the same tax rate as the discount products, no matter if it's belonging to the 3 for 2-category or not. I would exclude the possibility that all this happens because of the rounding methods in Tools.php, because I get the same results when overriding all this with the function I introduced in September 2014 in the PrestaShop forum: banker's rounding reworked function ps_round

Not really a joke, this was just a touching up. PS_PRICE_COMPUTE_PRECISION is used in several functions and classes, but initially with a fixed value. Later on PrestaShop added this new input field for price precision in the preferences menu, which was stored under the new name PS_PRICE_DISPLAY_PRECISION in the ps_configuration table. The line you quoted saved a lot of code changes, but caused new problems ( see my pm).

I'd suggest you have a close look into function getContextualValue in /classes/Cart.php. I mean, just a gut feeling ...

Your demo and my own test environment 1.0.1. - same results.

Maybe this is a helpful hint: It seems that all this only happens when you have products in the cart with different tax rates. As long as the products share the same tax rate, the discount does not change when you increase or decrease any quantity.

Tax and price computation in checkout and invoices were a mess in PrestaShop 1.5 and 1.6, when applying cart rules with discounts. But I'm afraid that thirty bees as well did not yet resolve the problems. Example, tested on thirty bees 1.0.2 beta: Cart Rule: 3 for 2 Conditions: Product selection for 1 category, The cart must contain at least 3 product Action: Apply discount of 100% for cheapest product Preferences --> General: Round mode: Round half even (as recommended) Round type: Round on the total AEUC activated, Rounding method "Round on the total" (this dropdown for options is new in 1.0.2), anyway, same result with option "no rounding" Result is a bit disappointing so far, no matter if with activated or deactivated AEUC. Shopping cart in checkout Discount, net totals and totals are wrong Same in BO order page Further bug in these "mixed" orders: Payment of previous order is "accepted" when you change status to paid, which causes a WRONG warning Invoice with activated AEUC and proportionate tax display in tax details is then totally messed up (wrong amounts marked yellow) 01499417112661IN000004 -TB order Invoice.pdf It took me some time to realize that the errors are mainly caused by the fact that every other product in cart from a different category (which is not included in the applied tax rule) diminishes the discount, increased by units. Is the initial discount e.g. 19,98, it decreases - to 19,10 if you add one more other product - to 18,96 if you add 2 more other products and so on. Obviously the cart rule thus has an impact on the computation behavior for other products in the cart which is not correct. It works perfect as long as you just buy products from the discounted category. Same behavior btw in tb 1.0.1.

Then take JEdit, TextWrangler or TextMate instead. All 3 run on OS X.

Why so complicated? How about this? Copy the folder /mails/en to your locale computer. Open all html files at once with notepad++. Choose Replace from menu, then Replace with option in all open files the following: {shop_name} powered by PrestaShop™ Click on Save all Repeat this with the phrase powered by PrestaShop(tm) [http://www.prestashop.com/] for the txt files in this folder. Upload the folder to /themes//mails

Roundabout 2 years ago I summarized in the Geman PrestaShop subforum how to find and change translations. Those of you who understand German may follow this link, because the proceeding is the same in thirty bees: How to find Translations and change translations in thirty bees/Prestashop (in German)

@30knees said in Email template translations - core or theme?: Under Localization> Translations one can select "Email templates translations". One then can select the theme one is using or the core. Can I make changes to the core and these will get pulled to the theme if the theme doesn't have its own translations? Also, what happens to the modifications during theme/core updates? Standard behavior of mails translations is this: 1. Choose your theme 2. Always choose your language and not core no theme selected 3. Doing so tb clones automatically the language subdirectory of the mails folder to /themes//mails/ 4. Next time you change something changes will be written to this themes subdir.

Seems there was a problem with the installation process. Can you confirm that there exists a subdirectory /mails/ at all? I'd guess no. If the subdirectory would exist, tb will accept the changes and clone the changed mails directory to /themes//mails/, where it will be searched automatically in case of further changes. Solution: Go to localization --> translations --> section: Add / Update a language and import your language. Then try again to modify the mails.

@Pedalman It worked for me, too. This is why I had proposed in the PS forum to apply this fix. But then I learned from Whiley that despite this change some of his customers from time to time faced this cache error. From that point on we recommended just the disabling of smarty cache. But I would not prefer this solution for TB.

@mdekker Sounds good, but I really doubt how to manage this by just using the configuration table. This may be ok for a predefined currency pattern, but you would need a db field to store the different patterns. In general I'd agree not to touch the db schema, but in this case it would be helpful to redefine the format field in tb_currency from tinyint(1) to varchar(12).

I'm sorry, but this workaround doesn't do it in every case. We tested this already. You can disable smarty cache to avoid this annoying caching error. This works in any case! But that's not really an elegant solution. Neither the PS 1.7 solution by splitting hookDisplayProductPriceBlock.tpl. We have a great module in Germany, Presta plus by Online Shopsysteme, which can be combined with AEUC. Among a lot of other features it provides the possibility of individual delivery times per product and repairs the AEUC cache problem. Works like a charm with TB. In Prestashop it is quite easy to reproduce the AEUC cache error by just login in as customer during order. As soon as you log out the double or triple display of the tax label vanishes. But it's different in TB, though sometimes you still get this error, but not with login. May be this is a result of improved cache management in TB.

Why don't you just clone the the theme translations of the standard theme? Just scroll down to the bottom of BO menu localization --> translations You'll find a copy option here. If the theme fullfills the standard, most items will be tranlated automatically thus.

@mdekker said in Currency format: Hi BeeSide, The currency format is now automatically adapted to the visitors locale (language + country). This, because e.g. the euro can be displayed in several ways in the euro countries. Is there a reason why you want to change the decimal separator in your locale? Despite the fact that this does not work properly yet, I'm afraid this is the same logical error like in PS 1.7. If the currency format does no longer depend on the currency but on language and country, every currency will be displayed the same way for the customer, as soon as he chooses a language. This causes problems. Some examples: Language: German, Currency: Euro Currency display: 1. Austria: € 399,10 2. Germany: 399,10 € 3. Switzerland: 399.10 € Language: German, Currency: CHF/FR Switzerland: CHF 399.10 or 399.10 FR Language: French, Currency: FR Switzerland: FR 399.10 or 399.10 FR Language: German, Currency: USD thirty bees: 399,10 $ PS 1.5 - 1.6: $ 399.10 (with or without blank after curreny sign depending on chosen option) Next you should consider the thousands seperator: Switzerland: inverted comma USA, GB, Canada (English), Israel etc: comma Germany, Belgium, Denmark, Italy, Sweden etc.: dot or blank Canada (French): blank ... and so on. And btw there is no special language for Switzerland, Austria or GB. (Try to import for example German(CH) and the customer will meet a 95% English shop language.) So it actually makes sense to restore the former behavior with options currency format and blank. A real improvement would be to replace the format options by a free input field stored in a new db table for every currency format you want to define.

I added a switch in product preferences to suppress the condition display on product page for all those shops who don't need it because they offer just new products. Feel free to use these changes: Switch off conditions You can do this alternatively in BO for every single product, but this would demand changes (or overrides) of several files and two database tables.