The issue with the way in which BC deals with product prices and tax leads to round off errors that produce incorrect selling prices.
This problem is well known in the BC community, has been an issue for years and reported many times. Despite promises of a fix, nothing has been done and the BC development team continues to ignore the problem.
This is not a complex problem, as made out by past responses from BC when the issue has been raised. On the contrary, fixing it is simple. The tax-inclusive selling price should be loaded into the system and the tax calculated from that. If the ex-tax price is needed, then it is calculated by the selling price minus the tax. Round off in the calculated tax will then not cause problems because the ex-tax price + tax will always be equal to the selling price.
I understand BC needs to keep the current system. An option (check box) on the price panel to flag it as the tax-inclusive price can be used to change the way these calculations are done and fix the current problems.
Fixing this problem is well overdue and needs to be addressed now.
Support pushed for the fix for this issue about a month ago and we were told by the engineering management that the bug is too large for them to fix at this stage. It is a bug with most votes against it, on the top of the list of all the bugs, with read status and highest priority set. But it will not be fixed before the creative cloud launch.
- Voucher/Discount codes not being calculated correctly in inovices/admin. (They fixed it for a bit then it broke again)
- Shipping calculations by Dimensions is off
- Offline Payment Calculation and bits around that trying to pay in the admin (if you update the order its not updating the amounts due etc) is off as well.
Just name a few quite major ones with just around the eCommerce alone I know you guys at support known and pass them on but still sucks this list of issues that are not minor are still on going and growing.
I am setting up a shop where they want GST added at checkout stage, rather than the product stage.
So does this mean I should import the items with tax inclusive prices to get the tax amount working correctly?
And can I display the product with an ex tax price as they shop?
I just need a bit of guidance on how to get around this bug and keep the customer happy.
Thanks so much.
Good news! The rounding issue is being worked on this sprint.I don't have all the details about it, like how it's being tackled, what's being worked on etc, but I',m sure Cristinel, our PM, will publish some details on the blog.
Mary, with GST, are you selling in OZ only or are you selling overseas? The easiest way to handle GST, if you're not selling overseas, is to add your products inc GST and then use the tax percentage tag to display the GST component inside the shopping cart, invoice etc.
By law you have to display the prices with GST inc to Australian customers.
They finalising it.
It not just about rolling out the fix, there is always implications.
Take the fact that it will effect all existing data and round things up. For your tax man and other record reasons and on going orders etc the values change and so you need to be able to grab a backup report so you do not loose that old info.
How do you go about this? how do you ensure no one misses out on being able to grab and view the old values?
How it effects all the tags that render values etc..
Things like this are being discussed and sorted. Which for me is great! A very common issue with BC has been releasing changes and not realising or thinking about the concequences of that change. Take the password changes effecting several things and workflows.
Asking for feedback and nutting these out is a great step into improving releases. If it takes a little longer but roles out sweet I personally approve. Rather then us having a release and dealing with clients with things broken or messed up that makes them angry.
I can only picture a client call complaining that their client is moaning about a large order and how they now owe them $$$$ because the rounding issue changed the values but they have no record of the last number in the system and how they mange it etc because they did not realise the change.
Totally understand it's not a straight forward fix, my clients are farily small so the effect of any change wouldn't be as great as it would be for larger busniesses moving substantial quatities of goods and services.
Was a victim of the password curfuffel as well so appreciate that BC are taking the right steps to think this one through.
Fingers crossed it's sorted soon.
We spotted that Day one morning, **** being stored as the password on update forms. We had to laugh, lol. To their credit they did hot fix it fairly quickly but they did mess the whole email notification workflow which was worse as a result of it though.
That password creation workflow confuses the hell out of my clients customers.
Pre fixing the system email:
Post fixing system email:
An so on.
Working on a well worded system email at the moment to explain why you will arrive at a password reset page instead of a password creation page.
But how many customers actually read emails, I know I barely glance at system emails.
Europe, Middle East and Africa