batman42ca

I don't know. Perhaps you've found another solution.

1) gergos, you have to create the tools.php file in the overrides directory. 2) Beyond what I've explained in my solution, I don't understand why this change is necessary, but it does seem to be necessary.

I had been trying to derive that equation myself but kept tripping up for some reason. It would work fine if not for rounding errors. Here's a real example: product cost: 599.99 tax rate = 13% discount = 1 - 1/1.13 = 11.504424778761 ... BUT prestashop will round this to 11.5 subtotal = 530.99 13% tax = 69.03 total = 600.02 So, it's close but not the same as truly excluding the tax. UPDATE: seems my client is content with the improved math so for now, I no longer need any special code for this. Thanks for the help Enrique.

Thanks but from what I think I've seen, unless I have it configured wrong somehow (hopefully I am wrong) it actually works like this using some very easy numbers: product cost = $100 10% discount = $10 subtotal = $90 10% tax = $9 total = $99 So I can't just use a 10% discount if my taxes are 10%. Is there some configuration option I can use to fix this?

I have a client that wants to be able to create a Cart Rule (a voucher) so that when the voucher code is entered, the contents of the shopping cart are tax free. Anyone want to suggest a cost for modifying Prestashop to permit this type of cart rule (if possible in a way that will survive an update of Prestashop)? Or does anyone know of a module (free or for purchase) that would already do this? I'm a PHP programmer but I don't have time to learn what I need to know about Prestashop to do the work myself.

Still hoping someone can offer some advice, even a paid module would be welcome.

Is there any way I can configure Prestashop so that if a customer enters the right code at checkout, they don't have to pay the tax? If the tax is 10%, simply applying a10% discount doesn't work of course.

extraproducttabs is a plugin that is not part of prestashop normally. It was a plugin I added that someone else wrote. I don't know how he fixed the problem. My suggestions is to start disabling plugins one at at a time until you discover which one is causing the problem.

I discovered the cause. It was a 3rd party plugin (extraproducttabs) that apparently was no longer compatible after upgrading to Prestashop 1.5.6.1 from 1.5.5.0. After upgrading the module, the problem has gone away.

I recently upgraded to 1.5.6.1 and now I'm seeing this error when I attempt to update a product. Unknown column 'a.start_day' in 'where clause' Attached is a screen capture of the full error. Edit: Actually I just realized, this happens as soon as I log into Prestashop, provided that I have debugging enabled with define('_PS_MODE_DEV_', true);

After a little more research, I've discovered that the method I used to delete test orders is known to be incomplete. Since there are no real orders yet anyway, I just used the Prestashop Cleaner plugin to remove all orders and all customers. Thanks for your help bellini13

It appears that the only order in the ps_orders database table is the one belonging to the picture in my original post, but other tables, such as ps_order_details and anything else starting with ps_orders, have records. It seems the plugin I used to delete the test orders was not very thorough. Is it safe for me to empty all the ps_orders_* records (since I know there are no real orders yet)?

Yes, but there is no way the orders I deleted could have included orders for those extra products by that customer. All the default products were removed long before a test purchase by that particular customer could have occurred.

Has anyone seen this problem before? Look at the top 2 products in the image of the PDF invoice I generated. The top 2 products don't even exist in my store and they did not contribute to the total. How is this even possible? (I'm using Prestashop 1.5.5.0)

Just to be complete. I did get some help from the template authors. What they did to fix the problem is as follows: in hookDisplayTop() in modules/blockmegamenu/blockmegamenu.php, they changed the very first line from: $shopUrl = 'http://'.$_SERVER['HTTP_HOST']. __PS_BASE_URI__.'modules/blockmegamenu/ajax.php'; to $shopUrl = '//'.$_SERVER['HTTP_HOST']. __PS_BASE_URI__.'modules/blockmegamenu/ajax.php';