Occam

You can find the bug in function getPackageShippingCost of class Cart.php It starts absolutely right from line 1882: if (Configuration::get('PS_ATCP_SHIPWRAP')) { // With PS_ATCP_SHIPWRAP, pre-tax price is deduced // from post tax price, so no $carrier_tax here // even though it sounds weird. $carrierTax = 0; (...) But it ends wrong from line 2003 on, because with AEUC option enabled the tax is added to the shipping costs and not deducted from this figure which would be correct: if (Configuration::get('PS_ATCP_SHIPWRAP')) { if ($useTax) { // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping // costs. This is on purpose and required in many countries in the European Union. $shippingCost *= (1 + $this->getAverageProductsTaxRate()); } A workaround is quite simple. Just deactivate line 2007 if (Configuration::get('PS_ATCP_SHIPWRAP')) { if ($useTax) { // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping // costs. This is on purpose and required in many countries in the European Union. //$shippingCost *= (1 + $this->getAverageProductsTaxRate()); }

Yep, I guess @mdekker just wasn't aware that AEUC treats the entered shipping fee as tax included. Which means, the calculation algorithm for the proportionate tax has to be slightly reworked.

It's indeed intention! With enabled AEUC you have to be aware that shipping costs will be treated as tax included. But I can confirm this, tb treats the tax as net and adds the tax to shipping costs in checkout, really confusing. This is a bug!

It's not only the modules (similar problem currently with PS 1.7.2 btw). When I tried to upgrade my test installation from 1.01 to 1.0.2, thirty bees install hang when trying to backup. The upgrade could only be completed successfully after I disabled the backup.

Sounds great, @Traumflug. You should have a look into EU legal. The German forerunner to AEUC had more features than the slimmed-down French successor.

@Traumflug Just to quote a working draft I wrote for the PrestaShop team referring to requirements of AEUC in February 2016: Mistakenly the programmers seem to assume that it is enough in B2B mode to indicate all prices net and refrain entirely from a statement of VAT on goods and shipping. Product prices B2B are displayed correctly excl. tax in order summary, but without tax total amount and total amount incl. tax and products and shipping, which is mandatory for B2B within the same European country. Pure net prices are only correct for orders from other European countries or outside the EU. The latter makes it difficult to identify a business customer alone by his tax ID, because you need a proof if he is EU resident or not (Orders from Switzerland are btw a good example that this wouldn't even work within Europe). And given the EU business partner is a company, but doesn't offer his VAT no. you need to apply the taxes of the delivery country. Moreover, you need to add a note on every invoice depending on the destination country, e.g. - tax free export delivery for orders from non-EU countries (B2C/B2B) - tax exempt intra-Community supply for orders from EU countries (B2B) etc. And if this weren't enough you have to take into account the delivery quota for B2C. If you cross a certain threshold (depending on the destination EU country's law) you need to apply the taxation according to the country of destination, wheras below this threshold it's the tax of the delivery country. And then there is the special case of the small scale entrepreneur, who is not even allowed to specify any tax, but needs to indicate in his shop and on the invoice that he is not allowed to display taxes at all (which is not equal to a display tax incl.!) Here some informations for German community members. Eventually every infomation the shop gives his customers is a display thing. Ok so far! So basically I totally agree with you, but the devil's in the nuts and bolts, especially for those poor chaps (in Germany, Austria and other countries) who are in urgent need to apply this botched module AdvancedEUCompliance, which in my view deserves to be completely rewritten. And this is just the situation in Europe. So don't forget that thirty bees is a US company - and the tax laws and particular rules in the States are legion afaik.

@Traumflug I'm sorry but I'm afraid you didn't get what I was talking about - or you are not familiar with the legal requirements in Germany and other European countries. I't is not that simple! It took me a lot of time to explain this to the PrestaShop team, how the checkout (and the invoice) for B2B has to look like. And finally it works for 1.6 and I guess in thirty bees too. Your proposal would be a step back.

@lesley said in Get this Wholesale thing correct.: I personally would like to see thirty bees move into the place of being the data arbitrator in the future, while the other systems are populated by thirty bees, not the other way around. Think big, eh? :) I guess, this was the PrestaShop developers' dream too for a long time. And what happened? Currently they end up in a metamorphosys to a peculiar world wide license monitoring provider named Prestatrust.

And what is it good for? Small shops don't really need this field, big shops usually run a separate ERP solution or minimum a stand alone order management with or without interface to the shop software.

@Traumflug @Traumflug said in Get this Wholesale thing correct.: This whole strategy looks a bit narrow minded to me. I think the right thing would be to remove this "wholesale price" and also "B2B" mode. Why? Well, business partners are just customers, too. They usually get a different price, just like customers buying often or customers being of a specific profession or whatever qualifies for a non-standard price. This means, specific customer groups should be able to get specific prices, as a general solution. Want B2B? Well, create a group for B2B customers and put these prices there. Okaay ... and how would you make it happen then for example that the checkout - let's say in in Germany - displays the net sum plus required tax totals after you defined this (B2B) customer group with prices tax excl.? The wholesale price field afaik has no dependencies, but the B2B mode definitely has! I would rather agree to a solution to make this whole B2B mode dependent on a certain customer group instead of a general option for all customer groups. This would help shops with mixed B2B and B2C.

Despite the fact that this wholesale/cost price discussion is sort of a déjà vu for me, because I tried to explain in vain this difference to the PrestaShop team that didn't even understand what I was talking about - where is the problem, guys? This is just an input field with no dependencies. Feel free to rename it in the English translations to cost price or whatever. ?

The displayPaymentEU hook first came along with EU legal, the (German) previous version to the (French) Advancedeucompliance. For people with German language skills it may be helpful to read Chris Gurk's excellent documentation. Here you'll find a description how it works and what all the hooks of AEUC are good for. displayPaymentEU will be hooked by AEUC during installation. So in some cases it is sufficient to reinstall or refresh the formerly installed payment modules so that they can be integrated. In other cases it is necessary to rework the payment modules' hooks, too.

Currently it seems that even the unapproved items are available for download which I would not recommend. Given 1.0 is fully translated, you should download a zip, which always contains both branches, copy release 1.0 into whatever else release and upload the file again. It would be much easier to activate the zip download/upload for every file minimum for the proof readers to exchange only those files of the new branch that were not complete yet. Crowdin doesn't always work properly, so this would be a safer way. From my experience I wouldn't recommend the xliff down- and upload.

I@mdekker said in Localization Pack German (de): I think it’s a question of style. IKEA only used informal speech in Germany, and people love it. Banks, on the other hand, are typically very formal. That’s why I think having two localization packs is a good idea. Let the merchant decide whether they’d like to use formal or informal speech. I have been thinking about that as well, but the problem here is that both Crowdin and thirty bees use one language code per language. There is no language code for the informal version, so hard to keep track of it, unless we start another Crowdin project, but that is just way too much to handle at the moment. Both too much for us and contributors. Not really because PrestaShop introduced 3 other "languages" to Crowdin (German Austria, German Luxembourg, German Switzerland). Nonsense in my view. Anyway, there was this guy with the nickname Papapillon who wanted to translate the average 5% differences for Switzerland, therefor we uploaded the then completed 86% German for PrestaShop 1.6 into this language. When we made him proofreader he may have realized that this would be much work for him and vanished from one day to another. From this day on this translation ( included in TB too) remained nearly untouched and is now outdated. But this implies there is already a language code. This could be renamed and used for a "Du"-Version of German. But ... it would cause much work, because Traumflug is right, you have to change the grammar in thousands of items. We discussed this in the German PS Forum. There is a topic in the PrestaShop forum where I published the estimated quantities of Items to be changed. If Michael would be so kind to upload the current translation into this language, I would post a tutorial how to use Crowdin's advanced features to minimize the efforts for the required changes for those who want to deal with this. I mean, given Crowdin will be properly configured. Currently it is not even possible to search and replace the word "Sie", because you get the notification that no matching strings were found.

Ww

If shipping is 12.50 and given a small rounding effect, I would agree.

Upload/Download: You need to check the allowed features for every language separately (have a look into Crowdin's help desk). e. g. uploads: Translations upload via Public Project Page - Select the language on the project page - Click the Three Dots button across the file translations should be uploaded to - Choose Upload Translations - Configure the system behavior checking appropriate options in the pop-up that appears. Search & Replace - my bad! Searched for English words, but I only signed up for the German translation. In PS translations I had both rights. Anyway, there is this funny thing that you cannot find the expression PrestaShop, prestashop or Prestashop (normally Crowdin search isn't even case sensitive!) to change it to thirty bees in one step. Strange!

@mdekker said in Translations: Makes not really sense for me pas long as some really useful features are deactivated for thirty bees translations. Search & Replace Upload feature where do I find these settings? Seems like you are more familiar with Crowdin than I am. I'd suggest to go to the Advanced Project Setup and - adjust the Privacy Settings and check ( and make sure) that translators may download zip files, both in specific language and whole project, - adjust the Export Settings and check Export only approved translations. Furthermore - allow Replace in suggestions... (=search & replace), seems it doesn't work properly - allow download and upload of files (but only for proof readers). Hints Crowdin has a full text index, so you may Search for source or target language snippets or even hash codes In combination with a check on menu item File --> All strings you may search the whole project (useful when searching for specific words)

Lol, never mind. When we started on Crowdin, I introduced Xavier et al. to some features they didn't know either.

@mdekker Nothing of note. It's just that I quit Crowdin translations. (both PS and TB). Makes not really sense for me pas long as some really useful features are deactivated for thirty bees translations.

This is why I asked to activate the Crowdin Search & Replace feature. But it seems they wouldn't listen. Upload feature is usually linked to proof reading rights. However, just word-for-word-translations without being able to use Crowdin's advanced features makes no sense. I left the tb project on Crowdin.

Ok, seems to be a misconfiguration of your server. English: English translations, normal behavior Bulgarian: translated currently 88%, approved translations 0 %. Whatever, translations should be imported and untranslated fields left blank. This would be the normal behavior. Didn't you try to update your language in the translations section? It works for me on my test environment (BO currenly just 72 of 5266 Bulgarian translations missing / error message 28 of 860) Prestashop 1.6.1x Bulgarian translations btw are 100% complete.

This is weird, because there is just one way that this could happen. Did you copy the English translation in the translations section of the Back Office into your language translations? Just by accident? What is btw the language you want to translate? Did you check if your language is 100% translated at Crowdin?

@mdekker said in Wrong amounts when applying discount cart rule: Sure, we'll have a look with 1.0.3 The cheapest product calculation has been fixed, too. My guess is that PrestaShop skipped it, because they couldn't register the data for the order detail table. Even after validating the order with a correct cheapest product calculation there is no way you can later access the data for generating the invoice. Did not realize it, but I can confirm this for 1.6.1x. However, it worked properly in 1.5 (and I guess until 1.6.0.14) The only problem were the wrong net prices and tax amounts on the invoice then. All cart rules including cheapest product by percentage are correctly applied in a PrestaShop 1.5 shop.

Perfect! And the changed CSS class like in my post above provides the correct alignment on the invoice: