something394124

I think I found the easiest and hopefully best solution, @fedesib I changed: $shipping_cost = (float)Tools::ps_round((float)$shipping_cost, (Currency::getCurrencyInstance((int)$this->id_currency)->decimals * _PS_PRICE_DISPLAY_PRECISION_)); To: $shipping_cost = (float)Tools::ps_round((float)$shipping_cost, _PS_PRICE_DISPLAY_PRECISION_); The ps_round function (in this instance) takes in two parameter, the shipping cost and the decimal precision (integer). Originally it would check if "Localization > Currency > Decimals" is enabled true/false (which is turned off in my case) and multiply the bool value by the decimal precision integer (Set in "Settings > General > Number of decimals"). The line would therefore equate to: ps_round($shipping_cost, false). And false/null for the second parameter which would default it to 0 decimal precision (which would end in rounding the whole primary number (248.750000 to 249, instead of 248.750000 to 248.75) This solution worked for me, but I also had to change rounding precision in the paypal module in the following files: /paypal/paypal.php /paypal/classes/PaypalCapture.php /paypal/integral_evolution/notifier.php It "works" without changing the PayPal files, but then orders would come in with the following error, which is also sent in the order confirmation email to the customers: "Payment error: Price paid on paypal is not the same that on PrestaShop.", because the PayPal module were rounding up the total the same way as Prestashop (checking first if decimals are enabled for the front of the shop). I hope that any of this made sense to the readers If anyone else runs in to this or a similar problem, don't think twice, just leave a post here and I'll do my best to help you out! Thanks!

I am one step closer, thanks to @fedesib! I found the code in Cart.php starting at line 3025: if (Configuration::get('PS_ATCP_SHIPWRAP')) { if (!$use_tax) { // With PS_ATCP_SHIPWRAP, we deduce the pre-tax price from the post-tax // price. This is on purpose and required in Germany. $shipping_cost /= (1 + $this->getAverageProductsTaxRate()); } } else { // Apply tax if ($use_tax && isset($carrier_tax)) { $shipping_cost *= 1 + ($carrier_tax / 100); } } $shipping_cost = (float)Tools::ps_round((float)$shipping_cost, (Currency::getCurrencyInstance((int)$this->id_currency)->decimals * _PS_PRICE_DISPLAY_PRECISION_)); Cache::store($cache_id, $shipping_cost); return $shipping_cost; } As far as I can see, it does calculate the correct price for shipping (tax incl.), but rounds the number before sending it back. What I'm wondering about now is this line: $shipping_cost = (float)Tools::ps_round((float)$shipping_cost, (Currency::getCurrencyInstance((int)$this->id_currency)->decimals * _PS_PRICE_DISPLAY_PRECISION_)); The getCurrencyInstance method, is it connected to the decimal option in "Localization > Currencies"? If so, does would this mean a solution might be to enable decimals showing on the front-end of the shop for all of the products and rather edit the template to hide the decimals? Or is there a way to have it send back the $shipping_cost without rounding? Thanks for the help so far!

Thank you for the really quick response Yes, the client's version is 1.6.1.5. I have tried all of the different combinations of the rounding options, but it still rounds the price of shipping incl. tax. But thanks a lot for a point in the right direction, I'll go dig for a bit

Hi there I am trying to help a client move over to a new accounting system, but without having to change cart system. So I found an integration provider that could connect the new accounting system to the webshop. But the integration provider stops orders with wrong tax calculation (wich they should), but this problem is a bit unique: When Prestashop calculates the tax of the shipping, wich in my case is 25%, it rounds the total incl. tax. How it should look: 199 * 1.25 = 248.750000 What Prestashop calculates: 199 * 1.25 = 249.000000 And that in turn gives a wrong total that the customer is paying. They should be paying: 3,112 * 1.25 = 3,890.000000 But they end up paying 3,890.250000 Does anyone know which file and/or line that rounds the shipping price, or have any suggestions to how else I could solve this? Thank you.

Hello! I fixed this by modifying the following file: "public_html/themes/YOUR-THEME/css/modules/blocktopmenu/css/superfish-modified.css" You can try using the same CSS as I did, I have pasted it here: https://pastebin.com/VjNGx8vG

Hi there! Been at this for a couple of hours now, but I can't seem to find the solution. In my custom.css file I have been trying to style the following tags to no avail: <div class="popover sub-menu js-sub-menu collapse" id="top_sub_menu_XXXXX"> <ul class="top-menu" data-depth="1"> I'm trying to turn the horizontal sub-menu in to a vertical sub-menu. Check out the images if you don't understand what I'm trying to achieve. If anyony got a pointer, or some advice, that would be really appreciated! Thanks!

Changing the class file did not work, makes all orders throw a server 500 error when validating order from customer end.

After much searching and testing I found the root of the problem. (atleast I think so) After upgrading prestashop to 1.6.1.5, the one-click-upgrade module deleted most of the files in "/tools/swift" folder and also the "/modules/mailjet" folder. After re-uploading the files from a 1.6.1.4 backup, the problem was solved! - Joakim

Thanks for the quick reply, guys! I'll try to get back into the "Modules" page, and disable all of the non-prestashop modules to see if that has any effect. Meanwhile I have cache disabled, and keep clearing my browser cache along the way. I'll post an update as I go. Thanks

Ok, this is weird... When I turned "Smart cache for css" and "Smart cache for javascript" back on, the front office css dissappeared, but I could now access the modules page. I then turned those to options back off and the front office got repaired, and now I am unable to access the "Modules" page again.. Something happened in 1.6.1.5, but what?

Hello! After I upgraded prestashop to 1.6.1.5 on my test domain, the css in the theme bugged out. I solved this by turning off "Smart Cache for css" in the BO, then clearing the cache of both PS and my browser. Now everything works perfectly.. Or atleast almost! The only problem I encounter now, is when I try to access the "Modules" page in the BO, the page tries to load for 300 seconds, then times out, giving me a "Error 504 - Gateway timeout" (as seen in attached image) Nothing else is wrong in either front office nor back office, and no error logs are to be found in the root or /log/ folder. Any help would be greatly appreciated! Kind regards

Update to version 1.6.1.5 if you have not done that yet. That fixed a problem with combined products with group reductions or something in those lanes. Regards

I think i have found the source to the problem, but not an fix! If you guys go to the 'ps_image' AND 'ps_image_shop' tables in you database, and look for rows where `cover` is set to 0 instead of NULL. If you change these rows to NULL, it will let you upload ONE more picture, but this picture will have a `cover` value of '0'... Can anyone understand why this happens? Or are all the `cover` values in 'ps_image' and 'ps_image_shop' supposed to be the value '0'?

Bump

Bump