peterbuzzin Posted May 5, 2016 Posted May 5, 2016 Hi All, I'm looking for some help. I've discovered a bug with order totals created by a mixture of includes/classes/currencies.php and includes/classes/order.php (and includes/classes/cart.php if viewing shopping_cart.php) Consider the following GBP (default currency) basket (this is without any attributes or tax). Product A: 22.99 Product B: 22.99 Product C: 26.99 Sub Total: 72.97 The above Sub Total without any currency conversion is correct. Now changing currency to EURO with a currency value of 1.25 using the values above as base values to perform calculations. 1 x Product A: 28.74 EURO (22.99 x 1.25 = 28.7375 then passed to tep_round() = 28.74) 1 x Product B: 28.74 EURO (22.99 x 1.25 = 28.7375 then passed to tep_round() = 28.74) 1 x Product A: 33.74 EURO (26.99 x 1.25 = 33.7375 then passed to tep_round() = 33.74) Displayed Sub Total: 91.21 EURO The above Sub Total is incorrect when you add the Product Line Totals and should be 91.22 EURO OSC calculates Sub Total by the following (22.99 + 22.99 + 26.99) * 1.25 = 91.2125 then passes to tep_round() which rounds down to 91.21 Either the sub total calculation need to change by adding up the totals after conversion or the tep_round() function needs to change to stick with one method only, round up or round down. Depending on the payment module and how relaxed the visitor to the website is about maths this may not matter much. But when using the PayPal Pro Hosted module which actually charges the right amount the callback/IPN is rejected because of the 0.01 discrepancy. Harald if you read this, I know you've looked into similar issues of this in the past but this really is an out-of-the-box bug and I could really use some help with this because my client is complaining about orders that aren't being processed by the store but funds are being taken by PayPal. If anyone else can offer a bugfix also it really would be appreciated. If it still don't work, hit it again! Senior PHP Dev with 18+ years of commercial experience for hire, all requirements considered, see profile for more information. Is your version of osC up to date? You'll find the latest osC version (the community-supported responsive version) here.
♥kymation Posted May 5, 2016 Posted May 5, 2016 The Paypal modules included in the osCommerce distribution are obsolete. Install the Paypal App from the Addons site and try again. Regards Jim See my profile for a list of my addons and ways to get support.
peterbuzzin Posted May 5, 2016 Author Posted May 5, 2016 Hi Jim, Thanks for your input but I think you might have misread my post. Disregard PayPal, the bug first presented on a live/production site with PayPal but I then performed a clean install on a test server to see if the problem occurs on an unmodified install without addons (as stated in my post subject). This bug is present on the sub-total displayed on shopping_cart.php and checkout_confirmation.php On the live install I mentioned, we have already installed the latest PayPal App. But I must make it clear, the problem is not with the PayPal App, it is with the calculations performed by oscommerce within includes/classes/order.php, includes/classes/currencies.php and tep_round () which is producing incorrect values due to different rounding methods and calculations. Try it yourself on a clean install of 2.3.4 with 3 products listed above, same prices and 1 additional currency that has a value of 1.25. The calculations for the default currency will be fine but when you switch to the secondary currency and view the cart/checkout confirmation you'll see the sub total will be 0.01 out. Pete If it still don't work, hit it again! Senior PHP Dev with 18+ years of commercial experience for hire, all requirements considered, see profile for more information. Is your version of osC up to date? You'll find the latest osC version (the community-supported responsive version) here.
♥kymation Posted May 5, 2016 Posted May 5, 2016 This is a known issue with the old osCommerce 2.3.4 code. I don't believe that it has been fixed yet in 2.3.4r either. Customers don't seem to care about the 0.01 error. I doubt that most of them notice it. The Paypal App should take care of the issue with checkout, so customers can still purchase even with the bug. If you find that there is still a problem with checkout even with the App, then the issue becomes more important. Otherwise there's little urgency in fixing it. If you think it's important, patch the code and issue a pull request on Github. I suggest doing this on the osCommerce Responsive branch, as I don't think anybody's monitoring the standard 2.3.4 branch. Regards Jim See my profile for a list of my addons and ways to get support.
MrPhil Posted May 5, 2016 Posted May 5, 2016 This is something that has shown up forever -- you often get slightly different results when you multiply each item by a fractional multiplier and then add up the (rounded) numbers, versus adding up the items and then multiplying the total by the same factor. It's not limited to osCommerce. You just have to be careful in the code to add up the converted/rounded numbers, to match what is shown to users. You can't add up the unconverted total and then convert that and round it, nor can you add up the unrounded totals of converted values (hidden digits) and round that total, or you end up with the slight error you saw. With a large enough basket of numbers, the variations due to rounding will tend to cancel out, so the effect will show up most often in small baskets. Do NOT fiddle with rounding algorithms (to always round up, or round down)... that's not the correct solution.
peterbuzzin Posted May 6, 2016 Author Posted May 6, 2016 Customers don't seem to care about the 0.01 error. I doubt that most of them notice it. The Paypal App should take care of the issue with checkout, so customers can still purchase even with the bug. If you find that there is still a problem with checkout even with the App, then the issue becomes more important. Otherwise there's little urgency in fixing it. Hey Jim, I'm now having to rely on customers not being observant and terrible at maths lol. I've decided to give up trying to fix the calculations, I don't have the time or budget to do so. So I've had to come up with a dirty little fix within paypal_pro_hs.php. On line 674 of payapl_pro_hs.php I've changed this... if ( $tx_amount != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) ) { to this if ( $tx_amount != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) && $tx_amount != ($this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value'])+0.01) ) { I've developed literally hundreds of OSC stores over the years, thought I knew all of the little annoyances and this one pops up out of the blue. It was quite embarrassing to tell the client (very well known globally) that something so crucial is calculating incorrectly by 0.01 on currencies other than the default currency. Off topic: This has made take another look at what's happening amongst devs of OSC (official and unofficial), I was totally unaware of the BS GOLD/Edge fork. We BS'd our own fork of OSC years ago, store and admin also with Minified CSS and JS to make it more compact for mobile devices. Many of the annoying steps to acheive things with admin have been replaced by modals and tabs using ajax. If I get time I might have a go at cleaning up my code and making it available for all on Github. If it still don't work, hit it again! Senior PHP Dev with 18+ years of commercial experience for hire, all requirements considered, see profile for more information. Is your version of osC up to date? You'll find the latest osC version (the community-supported responsive version) here.
MrPhil Posted May 6, 2016 Posted May 6, 2016 Customers do notice such things (numbers not quite adding up), and it leaves them with an uneasy feeling if the store can't seem to do basic math. I see no reason that where the page shows a total of numbers, that the visible (rounded) numbers can't be added up, rather than add up unrounded and round the total, or add up straight numbers, multiply by the conversion factor, and round that. The latter two methods risk having totals off by a penny or two. This applies any time you multiply a value by a non-integer factor, such as currency conversion and tax calculation. You must add down the columns, not across subtotals. Don't forget cross-page totals, such as displaying a product cost with tax, and then adding up the untaxed total and applying the tax rate to that (which often produces results off a little), rather than adding up the rounded/displayed "with tax" numbers. Be sure to follow accepted accounting practices if you don't want your local Consumer Protection agency asking you questions. If you're supposed to do things in a way that risks producing inconsistent results, be sure to add a notice that "results may not add up exactly due to rounding", and explain how you get your results. This explanation could be as simple as giving a different color background column on the multiplied and rounded values, and the total (of rounded values), so it's clear that the total is the sum of that column, and not the multiplied subtotal (horizontal). If you're supposed to add up unmultiplied values first, and then apply a multiplier (rate conversion or tax) to that subtotal, color that row to make it clear where you got your numbers.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.