boran

Well the third comment indicates one immediate fix to modules/mailalerts/mailalerts.php. The fourth indicates that total_discounts, total_shipping, total_wrapping are probably also wrong, and asks why different formulas are used to calculate the totals?. I was trying to understand the reasons behind the current code. Should total_products not be calculated in exactly the same way in mailalerts.php and PaymentModule.php (i.e. the quote line in comment 4 for PaymentModule.php should be replaced with the one from mailalerts.php). Sean

Looking at classes/PaymentModule.php confirms the above issue, in that file, which generates the 'Order Confirmation' sent to the customer, the relevant lines are as follows (note the last two false parameters meaning no conversion): '{total_paid}' => Tools::displayPrice($order->total_paid, $currency, false, false),^M '{total_products}' => Tools::displayPrice($order->total_paid - $order->total_shipping - $order->total_wrapping+ $order->total_discounts, $currency, false, false),^M This, then begs the question as to why the code is duplicated, and in this case different, between classes/PaymentModule.php and modules/mailalerts/mailalerts.php. With the 'Order Confirmation' and 'New Order' emails in two different classes they have to be maintained/corrected in parallel, which will lead to future inconsistencies? Reviewing the differences would indicate that total_discounts, total_shipping, total_wrapping also need to be corrected in the same way. Looking at the total_products the calculation in done differently in each case. modules/mailalerts/mailalerts.php: '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency, false), classes/PaymentModule.php '{total_products}' => Tools::displayPrice($order->total_paid - $order->total_shipping - $order->total_wrapping+ $order->total_discounts, $currency, false, false), getTotalProductsWithTaxes() is in classes/Order.php and does the quantity*price+tax for each item, so its what a product should cost. Does this difference make sense? The logical for calulating totals should only be in one place, probably in the Order class?

As I work more and more with PS, I keep coming back to the debugging issue, and feel it should be possible to keep debug code and enabled when needed. Anyway, I was digging for a way to tie in FirePHP very simply in any class I needed. Trying the OO didn't work to well, but this did: in config/config.inc.php, add include_once(dirname(__FILE__) .'/../FirePHPCore/fb.php'); extract FirePHPCore into the shop root. And from any line a module (for example), add a debug print like this

I think I've found one issue, in modules/mailalerts/mailalerts.php In hookNewOrder(), when building $itemsTable, Tools::displayPrice() is called with a "false" paramter not to do conversion Whereas the totals are converted: '{total_paid}' => Tools::displayPrice($order->total_paid, $currency),^M '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency) So I changed those lines to: '{total_paid}' => Tools::displayPrice($order->total_paid, $currency, false, false),^M '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency, false, false), This is a tentative fix, the total products line in the confirmation email seem correct. I'm not sure though, could someone with PS experience please confirm?

What is not identical? They look the same to me. If the DB and files are copied over, the only thing to worry about is that file permissions, and the DB settings are correct. A little checklist I keep after setting up a copy: # disable friendly URLs on development system, Regenerate thumbnails, maybe change the theme is needed, switch paypal to sandbox mode Back Office >> Preferences Back Office >> Preferences >> Image >> Regenerate thumbnails Back Office >> Preferences >> Apparence >> Teme >> Vl Back Office >> Payment >> Paypal > Sand box mode # Maybe change emails alerts: Back Office >> Modules >> Mail alerts Back Office >> Employees >> Contacts Back Office >> Preferences >> Contact >> Shop Email # Add TEST to the shop name if needed: Back Office >> Preferences >> Contact >> Shop name Check file permissions cd /var/www/shop1 # assume we install in this dir chown -R boran * . # assume we work as "boran", apache runs as group "www-data" chgrp -R www-data . chmod -R g+rx * .htaccess chmod 755 . chmod -R g+rwx img mails modules themes/prestashop/lang translations upload download chmod g+w config upload download tools/smarty/compile/ sitemap.xml config/settings.inc.php chmod -R a+rwx img # don't know why but regenerate would not work otherwise

I've just noticed that the difference between the correct and reported total exactly corresponds to the Euro/CHF exchange rate. So the order is for 6 × 15.43 Euros = 92.59 Euros But the reported total is 57,16, which is in fact 92.59 * 0.617284 0.617284 is the exchange rate Euro/CHF in the shop at th moment. So, it seems like PS calculates the line total correctly 92.59 Euros, but when then applies the CHF/Euro conversion rate and "converts" it to Euros, even though its already Euros. So, for the order confirmation, and payment request, the exchange rate is applied twice. But, as noted in the original post, the order confirmation email is correct. Perhaps someone could explain the differences in the way these totals are calculated, and where I might start looking?

Hi, On http://old.boran.ie:8084/shop1 there is a test shop that has Swiss Francs as the default currency but also allows orders in Euros. If one orders 6 of the product "General Donation 25 Francs Suisse" in Euros, this is 6 x 15.43 Euros = 92.59 Euros. If one makes the above order with Payment by Bank wire, PS then sends out two emails 1. An order confirmation to the client which shows a correct total of 92.59 euros, 2. a second 'New Order' email to the shop administrator with a total of 57.15 euros. Which is wrong. This email looks like this: Commande 001010 passée le 26-02-2009 Paiement : Bank Wire Référence Article Prix unitaire Quantité Prix total General Donation 25 Francs Suisse 15,43 € 6 92,59 € Produits 57,15 € Réductions 0,00 € Emballage cadeau 0,00 € Frais de port 0,00 € Total 57,16 € Note that the total for that detail line is correct, but the lines "Produit" and "Total" are wrong. Now that is email is wrong is not so bad, the serious problem is that if one pays via Paypal, the amount request from Paypal is 57.16, i.e. the wrong amount is requested, and paid! Analysis - Version: I've tested this on SVN 463 (2 weeks old) and SVN 298 (Jan 9th). - Does not happen with the default currency Any suggestions please?

I'm trying to attach a patch to this post, but it is not showing up. Is there some trick to get attachments to work correctly? I've posted it here: http://boran.com/sites/boran.com/files/ps_patch_forum_10649_0.txt

Ok, the issues is resolved, a patch that does the job has been attached to this post. Changes are needed to classes/Product.php product.php classes/Cart.php themes/default/product.tpl I'll put it up on boran.com/presta where I keep my notes.

How about a module to: - list end edit products, but not by first navigating through categories. The products would be listed in grid form. - back office ordering: already noted. - History of currency updates - multiple shops: http://www.prestashop.com/forums/viewthread/9664/modules/is_it_not_time_for_multi_store_multiple_shops__module - newsletter (already noted), but that allow pull the emial list from another table, or from a CSV file.. As regards payment: my PS installation is for a charity so I don't get paid. But I would contribute 50 or 100 euro to an interesting _OpenSource_ module that was really necesary..

> isn’t there any statistics tables ? Yes, good point, can someone give information on how to clean up that stats if orders are deleted as noted above?

If you want to go that way, there is also a tool for windows: http://www.spectralcore.com/datasync/index.php Its about $170

> Why do you say that it’s not enough to just run the upgrade script… I think it’s enough if the Prestateam does’nt forget to update the upgrage.sql file. I imagine that the PS team review and double check the upgrade sql file on each point release, but not for every single SQL change (i.e. SVN commit). However I understand that the other SQL files are updated for each commit. > Imagine that the curent version is 1.1… but your interest is to work with the SVN revision 1.2.0.1 You update all your files via the SVN (with tortoise for ex.) and install your prestashop. Your are now with revision 1.2.0.1 running on your server… > When updating your files via SVN you check if the 1.2.0.1.sql file is updated… if yes you report manualy the changes on your datebase via PHPMyAdmin (this works if Prestateam has not forgoten to update its 1.2.0.1.sql file… wink > The day a new release is ready on the SVN for exemple 1.2.0.2, you juste make an upgrade with classic prestashop procedure. My feeling (I'm not on the PS team, can Damien or a team member confirm?) is that if you upgrade from point release like 1.2.0.1 to 1.2.0.2, then the upgrade SQL file will be fine, and thus the GUI upgrade procedure too. Sean

Like Damien says, its not enough to just run the upgrade script, it may be incomplete (and it was for me) I've started documenting my notes on http://boran.com/presta#Upgrading if that helps you. Attached is an SQL script I've been testing as part of the above. My suggestion would be to wait for a point release if at all possible (but still use SVN), otherwise prepare to have a a few days to manually check for changes in code and SQL with a fine comb.

I see no problem doing step-by-step DB fixes, I just paste one upgrade command at time into the MySQL command prompt. For me what is difficult was going through the SVN diffs and building the SQL update file. >> You said that the install GUI update option cannot be used because it is grayed out (because the official version in settings.inc has not changed). Do you think it could be possible to ungrayed by changing something in the prestashop code ? Just change the version number indicated in settings.inc, then it will compare and allow an upgrade, I think.