Jump to content

d3m0t3x

Members
  • Posts

    22
  • Joined

  • Last visited

Everything posted by d3m0t3x

  1. 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!
  2. 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!
  3. 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
  4. 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.
  5. 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
  6. 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!
  7. Changing the class file did not work, makes all orders throw a server 500 error when validating order from customer end.
  8. 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
  9. 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
  10. 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?
  11. 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
  12. 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
  13. 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'?
  14. Also; I cannot change the max upload file size and attatchment size from BO -> Administration -> Settings. Here it say maximum 2MB upload size, and when I try to change this to 10MB (max 32MB is allowed in php.ini), I get error with: "This exceeds the servers max allowed upload settings." or something close to that!
  15. When I try to add a new product combination, either manually or by using the product combinations generator, I get a success message, and NO combinations are added. I tried changing BO language as I read this may help, but it did not. I'm using Prestashop version 1.6.0.14 (default theme) If anyone can help, I would greatly appreciate it! Thanks! Kind regards D3m0t3x
  16. Hello, I'm having a problem with uploading product images, and get an error, no matter what image size (both pixels and MB) I'll add screenshot of error! I have tried to change php.ini to allow greater size for upload_max_filesize, post_max_size and memory_limit. I have also checked the SQL-database tables: 'ps_images' & 'ps_image_shop' to verify that the row 'cover' is set to NULL as standard. File and folder permissions are 755 for folders 'img' and 'images'. I'm using Prestashop 1.6.0.14 and have updated all modules. Anyone have any fix that I can try? Would greatly appreciate it! If you need more info, just tell me and I'll supply! Kind regards D3m0t3x
  17. Found the problem! It was because of this module: "/public_html/modules/lyoshowvatfree/views/js/product4.js" At line 53, edit: priceWithGroupReductionWithoutTax = basePriceWithoutTax * (1 - group_reduction); to: priceWithGroupReductionWithoutTax = basePriceWithoutTax * (1 - groupReduction);
  18. When I try to use the contact form, the messages get saved in the back-office, but no email is sent, either to the customer or to the admin. And when I try to reply to the messages from the back-office, no email is sent out. I have set up both standard email adress for the site, and "contacts" for the contact form. All e-mails used are @ the same domain. I tried to use SMTP settings to no avail. I have tried several other "hot-patches" wich did not work either (I backed up all the files before i tried editing, and reverted to the backup files after trying with no success) My hosting provider recommends using the standard mailto() php function, but that didn't work either. Please help me here, my customer has missed 7 orders worth nearly a total of $100k, this isn't fun! Respectfully - Joakim
  19. Hello! We're having a 'small' issue since updating to the lastest release of PrestaShop (1.6.1.1) When we change prices for a product in the back-office, the new price won't show up on the product's page, untill you add it to the shopping cart... Anyone have a clue what's going on here? - Have tried clearing both the cache in the back-office and in my browser, but neither worked. Link to one of the product's with this problem: http://www.skiltdisplay.no/plakatrammer/277-norges-mest-solgte-plakatramme.html If you change the "format" to ex. 'A2 - 42cm x 59,4cm' , the price won't update, but if you add it to the cart, the proper price shows. Any help at all will be greatly appreciated! Regards - Joakim
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More