Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Occam last won the day on October 23 2020

Occam had the most liked content!

Community Reputation

95 Excellent

Recent Profile Visitors

2,064 profile views
  1. ... and hope that your Prestashop theme is compatible with TB, which from my experience is rarely the case, even if it may work on the whole.
  2. 1) It makes no sense to open several topics for the same problem. 2) From your example it is not clear how much the gross amount of the shipping costs actually is. Or did you mean shipping costs tax incl. when you wrote "Gross tax is set at 4.80"? If so, the problem can be identified as a bug in tb's AEUC, because though the taxes are correctly calculated, they are computed not from the net shipping amount (4.25), but from the shipping price incl. taxes (4.80)! This bug is not new, but still unsolved. I totally forgot that this was the reason why I use my own modified AEUC in tb. Works properly without any changes in classes like Cart.php.
  3. Of course! German invoice with mixed taxes: RE000019.pdf And please, don't try to "approve" the Cart.php. Leave the code (where it deals with AEUC) like this: 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(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } $shippingCost = round($shippingCost, _TB_PRICE_DATABASE_PRECISION_); Cache::store($cacheId, $shippingCost); return $shippingCost;
  4. Nope, no shipping rate, just the shipping costs! Otherwise the proportional calculation wouldn't make sense.
  5. There's a bracket missing: ... = .... get_contents_dirname(_FILE_)...
  6. Seems to me that it was a misconfiguration. Never set a shipping tax rate when you use AEUC (hopefully my own modified release)
  7. I wouldn't agree, because I cannot reproduce the behavior you were talking of at Github. My fix there from 2017 is currently implemented in a slightly different way to tb so that the workaround I posted is obsolete and outdated now. 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(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } In my release issue-905 from Bleeding Edge it's line 2138-2149 in /classes/Cart.php. I tested it with both the standard invoice and my own invoice (adapted to tb). Each and every figure is correct. Works fine. I guess there's else something causing your problems, provided that everything configured is properly.
  8. Du hast völlig recht. Ich hatte übersehen, dass sich nicht nur der Feldinhalt, sondern auch die ID geändert hat.
  9. Ja und Nein. Hier ist der gleiche Fehler drin wie auch in PrestaShop 1.6. Es wird zwar ein neuer Datensatz angelegt, aber der alte verschwindet ganz, weil er in der Datenbank als deleted geflagt wird, aber noch aktiv ist. Er lässt sich aber übers Back Office nicht mehr reaktivieren, sondern nur durch Eingriff in die Datenbank selbst. Und ganz übel wird die MwSt-Umstellung, wenn man Varianten und Grundpreisangaben hat. Der "floating"-Grundpreis wird völlig unverständlich. Bevor du dich vorzeitig über die zugegeben nicht immer glückliche Diskussion im Prestaforum mokierst, solltest du dich vielleicht selbst mal auf Fehlersuche begeben. Wenn es wenigstens wieder so klappen würde wie in PrestaShop 1.5, so wäre das schon ein Riesenvorteil. Näheres s. im Bitrag eines Users im besagten Topic: https://forum.thirtybees.com/topic/4197-mehrwertsteuer-umstellung/?do=findComment&comment=36241
  10. Did you recompile the theme afterwards?
  11. Occam


    I believe this is exactly what happened in actual practice. You've really spent a lot of time on this, and you've pushed this project a huge step forward. Your decision has my utmost respect and is also very reasonable for me. This said, I'm afraid this is just another step towards the burial of tb. And I really hope I'm wrong.
  12. Maybe it helps to rename all instances of $dir to $dirX.
  13. 😊 You don't have to, this wasn't meant personally. Yep, and this means the developer will loose money if he or she doesn't adapt his module. But what does he loose when he refuses to adapt his module to thirty bees? But Bleeding Edge states that Panda isn't compatible. However, Sunnytoo's Transformer theme works properly with thirty bees 1.1.1. EDIT: Sorry, obviously it wasn't the current release of bleeding edge. After running the Core Updater Transformer stopped working, too. You have to manually reset each and every module though all are displayed as active in the back office. Is this what compatibility and being free of bugs looks like? It is not sufficient if just the two custom templates are working properly!
  14. All this may be true, but your argument still doesn't work. If thirty bees were a widespread and correspondingly potent shop system, you could require third party modules and themes to be adapted by their developers to each new version. But this is not the case. If users report that cache still worked with 1.1.0, but not with 1.1.1, then it may of course be due to the programming of the panda theme and its modules. Maybe you are right. I guess you are. But that won't help you. thirty bees is not in the position to impose conditions on third parties. Instead, in order to survive and secure some small market shares, thirty bees must guarantee full compatibility - and not the other way around. Almost nobody develops themes or modules specifically for thirty bees, and this is the big difference to Prestashop. They can afford to make such demands. I'm afraid, you cannot.
  15. Occam


    This is not what a shop system should do. However, I guess you can use a Smarty statement In the product.tpl to format the price: {$price|string_format:"%.2f"} Or use number_format {$price|number_format:2} will output 10,00 (EU standards) {$price|number_format:2:",":"."} will output 10.00 (US standards)
  • Create New...