I'd probably start best with the glitches....
When a product is on sale, it stores only the salesprice in the db. The original price, doesn't get stored in the [sf_ec_order_details] table. The [sf_ec_order_detail] table shows both the on-sale price in the [ttal] and the [price] fields. The [is_on_sale] is flagged with a '1' but nowhere does the discounted amount get stored or the original price.
Glitch: Child departments can't be moved up or down in the backend overview.
Glitch: Product search not updated.
When a product is added, it currently doesn't trigger the product search index to be updated. For SEO purposes it should also update the generic html search index and not just the product index so a catalog page will also be reflecting the latest page output.
Glitch: Product listing widget error.
When placing a product list widget on a page when there aren't any (active) products results in the widget giving a 'Object reference not set to an instance of an object'.
Scenario: Product catalog / selling can't be limited.
As a Dutch company I'd only like to sell (non-)shippable products to the Netherlands. Currently there's no mechanism in place to limit sales to a certain country or a few countries.
It is possible to setup shipping conditions to apply for only certain countries, but with electronic products shipping limitations don't apply. Will this change in future versions?
Scenario: Products shipping & selling from multiple countries.
As an European company I've got 2 factories, one in the Netherlands and one in Belgium, Dutch orders get shipped and billed from the Netherlands, Belgian orders get billed from the Belgium. I've got 1 ecommerce enabled website in Dutch.
The only way to allow this to work (and have the right taxes applied) is to create 2 FE languages for the entire website. After having localized all the ecommerce pages and all it's subsequent components I have to translate all my products aswell. Currently localized products isn't implemented yet but I'm guessing its going to be manually add a localized variant, open it and change the applicable tax rate.
And this solution will only work if the Customer is smart enough to select the proper checkout language version.
Scenario: Multiple front end languages & catalogs.
Imagine we have British company website with 3 FE languages installed (EN-US for America, EN-GB for the UK and EN for Europe). This way our blog/news and pages will be able to serve localized content.
If we ship & bill the entire world from 1 location, we'd have to find a way to circumvent all the localization with regards to eCommerce.
If we ship & bill the entire world from 2 locations, the US and the UK, we'd have have to create not 2 but 3 product variants, taxes & shipping one for each localized FE.
If I was stuborn and didn't want to create 2 FE languages & product catalogs, only the Dutch people would have to pay taxes and the Belgium people wouldn't have to even though they are shipped & billed from Belgium.
Suggestion: Store location is set in multiple areas.
In the general store settings we enter the store location, which doesn't do a thing. In taxes we set the location where they apply, but since we're tying taxes to a specific product/language combination, we basically tie them there aswell to a location.
Wouldn't it be smarter to create some sort of catalog_profile? In there we store the units/culture and shipping/billing location of the catalog and base our catalog on that catalog_profile instead of a FE language version. This would
also allow for limiting sales (a certain catalog can only be sold in Country of Origin, EU, US or Worldwide).
Suggestion: Remove the ability to apply taxes based on shipping.
Shipping costs should be applied to shipping adress, Payment & Taxes on billing address. The ability to basing taxes on shipping adress is asking for trouble and not just with your accountant...
Suggestion: Add the ability to restrict payment methods to countries.
Store pickup as an example of an offline payment method should be allowed to be limited to a certain country.
Suggestion: Apply proper international tax rules
Currently if a product is sold outside the country of origin, it just dumps all the taxes and considers it an intl sale, resulting in wrong taxes being applied. Tax laws in the EU have some restrictions and rules, and there could be easily incorporated to assure proper billing of intl sales. Can't we follow these steps during checkout:
1. IF personal order >> Tax applies >> finish.
2. ELSE IF
IF local (CountryOfStoreLocation = BillingCountry) >> Tax applies >> finish.
ELSE IF (CountryOfStoreLocation in EU) AND
(BillingCountry in EU AND NOT vat number provided) >> Tax applies >> finish.
Tax exempt >> finish.
All sales to (personal) consumers should have taxes applied of the Store country (local, EU, US, WORLD). If it's a business order, within the EU one needs a proper VAT number or else taxes should apply.
Suggestion: Untie taxes to a specific country.
Can't taxes be grouped and then have individual values? And not individual values based on FE language, but freely based on whatever shipping/selling country is specified. Imagine have store outlets in every EU country, but the website only in English.
This would require several applicable taxrates (NL:19%,BE:21%,DE:19%,UK:15%) to the same product. If taxes are localized based on FE languages, I'd have to create localized values for each tax and each product to assign it the proper tax.
So someone who only sells from the Netherlands defines the tax 'Highrate' just to Netherlands 19% but someone billing from Netherlands and BE can set 'Highrate' to 19% for NL, 21% for BE and 19.6% for FR.
He could even accomplish this with 2 FE languages Dutch & French and leave it up to people in Belgium which language version they'd like to view.