Thank you @oeoeaio for having dedicated time to share your thoughts on it. I’ll try to answer them, and also the Canadian case… sorry it’s a bit long. It’s easier sometimes to comment on a google doc so that we can answer each other on a given point I summed up the new options to organize tax in this new google doc document:
Please feel free to answer direcly in the document (comment / suggest)
Actually my problem is that this functionality is flawed. In Europe for ex, but also in Canada from what @tschumilas said, we have no common categories for our different tax rates. I was saying that for example “Food”, we have one rate for all
food and one other for raw fish in France, but in Spain they have one rate for all basic product (bread, etc.) and another for other food. We don’t have “common ground categories”, I think the Spree tax system is just not designed properly, the foundation of the Spree tax system is not adapted to the reality
Yes it’s true but again, this functionality doesn’t work anyway in practice, we are not going to create one tax category per product But we go over this with overriding VAT.
The problem is that when uploading a product, you have to choose the tax category of the product, and if we have duplicated each tax category to have a “included in tax” and “non included in tax” version, then the user has to choose among… 10 different tax categories, which is super confusing, and also he has to check again the “included in price” checkbox? I think the checkbox is redundant in that option… And to make things more complex, in the case of France we have a hub based in Spain selling only in France, so we need to add all the tax categories of Spain and duplicate them… the user has 15-20 choices of tax categories to choose from, and worse, some tax categories that don’t even apply to his country (I tried with a user account for a hub based in France, and I was proposed the tax category for the zone “Spain”…)
For me that doesn’t work. But maybe I don’t understand what you mean and I need a drawing
So to make it simple:
- either we have a check box “tax included in price?” and then only one tax category for each rate (no duplicate includes/doesn’t includes tax)
- either we duplicate the tax category and then don’t need the check box…
For me only the first option works because UX is not acceptable, sincerely the user will be completely lost with 10 or 20 tax categories to choose from.
OR maybe a third option would be to have the check box “included in tax” first and dynamically then only display the tax categories that answer those two conditions:
- if check box “yes”, then only display the tax categories with “included in price = yes”
- and only display tax categories related to the zone of the producer enterprise address
If that is possible then I agree that we can keep the tax category (even if for me it’s like simplifying law by adding new laws that make it more complicated, etc. But I understand your point about not changing the way tax is calculated to save time now…)
This is not working. I made a mistake in my proposal, that was not working either. As we said, as the logic of tax categories is flawed, the workaround is to create one tax category for each tax rate. SO there is NO LOGIC anymore here, for example: a producer in Spain sells oranges, and let’s say oranges are taxed 4% in Spain and 5,5% in France…
even if the hub says he wants the customer zone rate to apply, oranges are not in the same categories!!! so the logic can’t apply anymore. And again, we are not going to create one tax category per product!!!
I think we can only go through that by overriding VAT and enable a hub to associate either the tax rate of the hubs or the tax rate of the customer.
It seems in Canada if you sell to people in another State you have to charge tax of the customer State.
Here the hub will have the possibility if a producer is based in another State, to override the VAT to the rule of the customer State.The only limitation I see here is that a hub will have to create one hub per State if he sells to various groups in various states, as he will have to set up the tax overrides for the hub as a whole, and this set up will vary for each case…
Ok, then it has to take the same process as underlined above, BUT the process will be slightly different.
For a given product, the hub will say if price includes VAT or not ‘check box “included in price” - yes or no + he has to say if the VAT that applies is the one of the hub zone or he can select another zone if he wants (ex: hub based in Spain sells to France, need to apply French VAT).
Then the list of the VAT categories proposed is displayed following two conditions:
- If included in price = yes, only the categories set up with included in price = yes display
- AND if he has chosen to apply VAT of the hub zone, only the categories of the zone of the HUB displays, or else, only the categories of the chosen zone displays.
I think this is ok. In France for example if I choose to display VAT in shopfront (I target individual customers), I need at least to see after the total amount paid (VAT incl) one line per VAT rate included in this amount. So it’s ok to give a receipt to the customer with only the prices including VAT as long as there is the info of the total VAT included for each rate. And if prices doesn’t include VAT, ok for the invoice to be without VAT but after the total without VAT, need one line per VAT rate and amounts to be added and a line with the total price including VAT (to pay).
Hum… it seems a bit dangerous, but I don’t see any other option than the name to aggregate products which are on two different tax categories inclusive/exclusive on tax, but have the same tax rate. We will have to be super careful as also the name of the tax rate will display I guess. I’m afraid it’s error prone if there is any small typo mistake…
Another suggestion (see below related to Canadian case) would be to use as a key the rate itself. The VAT could be displayed following a pattern such as “including VAT [%rate 20%] = amount”
I hadn’t thought about it either… but could be something to think through. I’m not sure, if a user has to set up zone, tax category and tax rate (which we already have difficulties to understand) it won’t be an accessible platform If we have a simpler version, with only zones and tax rates to configurate that could be ok. And then those rates display in the product set up… but if various hubs work with the same producer, as there is only one tax rate attached to the product in the catalog producer… how would we handle that? I don’t think that would work… we need the tax rate to be attached to the producer catalog, and that any hub can propose and display the product in his shop. So I think we need to have a broader approach on tax. If someone see how this could work please feel free to share
On the canadian case
@tschumilas about “we need the capacity to add 2 different taxes to products.”…I guess we could potentially add a “+ add tax” button that open anew line of tax set up.
Then the hard part @oeoeaio is that this modifies the way tax is calculated… as you will have to add potentially two VAT amount to the price without VAT (when two VAT in Canadian case, both are calculated on base price).
In the Canadian case then, depending on the address of the hub (so the state), and depending on if the entreprise enter the price “including tax” or not (checkbox), then only the tax category of the given state are displayed in the list, but there is both in the list the PST and GST (and for some state, only HST). So the person select the PST first, then clic on “+ add tax” and can select the GST as a second tax to apply to the product.
Or I see another possibility, which is to create for each state all the possible combinations joined each one in one category: Ex: “PST 10 + GST 2” then rate =12% / “PST 20 + GST 2”… Would this be doable @tschumilas? When I look here, it doesn’t seem there is so many combination possible… I didn’t see info about how that vary from product to product?
BUT if you need a detailed line for PST and GST at the end of the invoice, then this option doesn’t work (as you won’t be able to separate GST and PST afterward…
What do you think @oeoeaio on the canadian case?
Ping @CynthiaReynolds for comments as well. @sreeharsha would be great to have also your input about India to see if what we imagine can work there.
I definitely vote for agility in the way we are going to implement all that then but this question is so structural for international capacity to use OFN that we need those discussion first