Still the Shipping Method bug... this is sad :( - Sitefinity - Ecommerce

All Replies

Posted by Community Admin on 26-Dec-2011 00:00

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:

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.

Replication:
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.
---

Probable cause:
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.

Fix:
By extracting the amount from the [shipping_price] as a double and afterwards converting it to currency should get rid of the culture problem.

Daniel

Posted by Community Admin on 27-Dec-2011 00:00

Daniel,

Just posting the screenshots you forgot to attach plus a link to the PITS issue so people can vote on it...

Jochem.

---
Update:
I've checked the ticket we created for this item 30th november and I quote "It is in our to do-list and we'll do our best to have it fixed for the 4.4 service pack due to be released in January."

Posted by Community Admin on 29-Dec-2011 00:00

Hi,

Thanks for the feedback, guys. We realize this is an issue that needs to be referred to and we are working on fixing as many bugs as possible for our releases, but sometimes time is pressing us and some bug fixes get rescheduled. I was informed that this bug will probably be fixed for our next release. I apologize once again for the inconvenience caused.

Kind regards,
Svetoslav Petsov
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

Posted by Community Admin on 29-Dec-2011 00:00

Thanks for the update.
Still, the bottomline is I purchased 2 Ecommerce modules for dutch website which are useless at the moment. How to deal with this until the next release? Probably over two months. That is not going to work.

What should we do?

Daniel

Posted by Community Admin on 29-Dec-2011 00:00

@Svetoslav,

No need to apologize at all, yes it is an inconvenient bug but you guys aren't miracle workers. We reported the bug not even a week before the first v4.4 release candidate and Grace informed us immediately that this (probably) wouldn't be fixed before the release.

This one wasn't just a matter of applying a quick hack to accommodate for reading the proper decimal separator, but as explained in the screenshots also required the backend storing to be altered.

In my book it's always better to have a solid bug you're aware of than quickly applying dirty hacks due to time constraints and see the system fall apart two steps down the line.

---

@Daniel,

I'm sure Telerik will come up with a more refined workaround, but since we're talking about 'Quick and Dirty hacks', you can easily replace the Dutch language with EN and load the Dutch language pack onto the EN.

As long as you're not doing multi-lingual sites, this will take care of everything, (both BE & FE).

Jochem.

This thread is closed