18 Feb 2004
26 Dec 2011
Link to this post
This bug is still active and I find it really sad that customers that are using Sitefinity outside the US have to strugle on and on with the Ecommerce module. It just isn't working as it should and therefore not useable.
But I guess the SF team in the US doesn't care. I just can't understand. But here again the bug:
While English being the default language, the cost of a shipping method is 2.50, when switched to Dutch, on the Frontend of the site, the shipping cost is displayed AND calculated as 250. This incorrect price is used throughout the checkout process and results in faulty calculations.
With English as Default backend language, create shipping method 'TestA' (see 1st screenshot).
Add Dutch to backend languages and set as Default, log-out, log-in and Backend language is changed.
Create new shipping method 'TestB' (no screenshot, since its Dutch but similar to TestA).
Backend overview displays both shipping methods as € 2,50. Go to Frontend, add product to cart and start checkout process. On the shipping method step, you'll see shipping method 'TestA' displayed as € 25,00 and shipping method 'TestB' displayed as € 250,00. (see 2nd screenshot)
Select either one and proceed checkout process to confirm that these wrongful costs are being used (calculated with) and not just displayed.
To confirm and isolate the issue, I've ran it as a test in a v4.3.1873 project, but v4.3.1885 is identical (just cluttered with client data) also persistent in v.4.3.1926.
The problem is two fold.
First the most likely caused by the difference in decimal separator. As can be seen in the top of the 2nd screenshot, [shipping_price] in the [sf_ec_shippingmethod] table is stored inline with the 'based on' and stored with a '.' as a decimal separator. This happens both when EN is the default Backend language as when NL is set as the default Backend language.
In the Netherlands we don't use '.' as a decimal separator but ',' During Checkout process, when NL is set as the Frontend language on read out of the database, it ignores the '.' because in Dutch culture it looks for a ',' and thus ignores it and instead of retrieving 2,50 it reads 25.
This cultural error happens with any language that uses a comma as a decimal separator instead of a period.
Secondly, when creating a Shipping method in English (TestA) the [shipping_price] cuts of the 2nd decimal, storing '2.5'. When Culture is set to NL, [shipping_price] is stored with 2 decimals.
This causes the difference between TestA being 25 and testB being 250 when checking out in Dutch.
By extracting the amount from the [shipping_price] as a double and afterwards converting it to currency should get rid of the culture problem.