Co-budget and organization around the tax overhaul dev

International
1

Continuing discussion from Specification for tax management overhaul and Outstanding Tax Requirements (Jan 2016)

The tax job is something needed by all the international instances, but for France, we have some kind of emergency, this is an urgent requirement for two serious users in France, we need to have it done by the end of the year (or we might lost those two important users), I know @oeoeaio you are taking some time to work on the estimate I asked by email for one of those two users + the overhaul VAT job (we are super grateful for that!) but I’m also conscious that the Aussi pipeline is full till the end of the year, so I need to find a solution.

It happens that we have found a super talented developer in France, @pierredelacroix who is super excited by the project and who will start working on it even if the amount of work is not so clear yet… so he is ready to start working on the 3 features I mentioned by email (2 of them are included in the spec discussed in the other discussion), so no need anymore to work on the estimate for this @oeoeaio :wink: BUT we need to agree on the global spec so that he can start working on those 2 VAT related features.
The second user is based in Spain and will contribute to a co-budget for the overhaul tax refund project (as he can only use the system if the whole tax system is reviewed…) he needs that as soon as possible, if not possible to provide something functional by the end of the year he will need to choose another system.

SO, I want open a co-budget to finance the whole tax overhaul. As @pierredelacroix will dive into the code and the VAT management, he will also have a clearer view of the work needed for the whole job. @oeoeaio as you so kindly accepted to dedicate time to work on this estimate for the whole job (so that we know which amount to put in the cobudget bucket!), do you think that makes sense if you work together with Pierre on it? I know it’s not trivial to enter the code, and even if Pierre seems to read in it like me in a book, he might need some “mentorship”/help at some point. Pierre has the time to do the overhaul tax dev job in the coming weeks also potentially, so it could be done by the end of the year (finger crossed).

Another option would be to directly open the co-budget with a first arbitrary amount (ex: 5000€), with the two users in France we know we can get 1000 to 1500 (maybe 2000), maybe Norway and UK can chip in as well. Pierre could start working directly on the dev instead of people spending days in doing estimates, if we all agree on the spec. With the objective to have this done by the end of the year. If he sees on the way it takes more time we raise a complementary bucket. If it takes less we got a remaining budget to reallocate.

What do you think?

Ping @RohanM @maikel @Kirsten @danielle @CynthiaReynolds @NickWeir @lin_d_hop

2

Hi @MyriamBoure, I think the UK could contribute an amount towards this work, we’ll figure out how much. With regard to the estimate, it might be good practice to suggest Pierre does an estimate such that he can plan the task and break it into smaller chunks and get feedback on his implementation plan. This is such a complex issue, let’s do it the best way possible :slight_smile:

3

@danielle @oeoeaio - can we chat about this tomorrow (weds?)

4

Please check quickly the spec document in here Specification for tax management overhaul that can be useful in your discussion, I think that could make the estimate job easier…

5

Hi @MyriamBoure et. al.

@oeoeaio and @Kirsten and I have sat down and chatted about the tax overhaul work today. Here’s a download of what we discussed:

First up, we absolutely agree about building local dev capacity and very excited about @pierredelacroix joining the team! Great to have you on board and we look forward to working together :slight_smile: Also, incredible job @MyriamBoure getting your head around all this and taking massive leap towards designing a solution that could work for everyone. We can see where you’re going with this, and it could be seriously great. There’s a trade off though, between flexibility in the system vs complexity to build and turnaround time to launch. We note this because this kind of flexibility requires a lot of work to get through before the end of the year.

To get into the detail . . .

  1. When it comes to understanding how the newly designed/overhauled tax function needs to work for the Australian instance, this is something that Rob @oeoeaio and Sally @sstead will do as representatives of Australian users.

  2. Something to keep in mind is the Spree Upgrade work that @RohanM is currently doing (more detail on this here and here and here and here) will change a lot of the tax set up, and may solve some of the problems that OFN France currently have. Changes made now to tax may increase the complexity of the Spree Upgrade work. We would suggest the first task for @MyriamBoure and @pierredelacroix is to closely review the latest version of Spree and understand to what extent this version resolves the some of the problems. If it gets a long way there, then another option might be for Pierre to help with the spree upgrade

  3. Rob @oeoeaio has allocated an extra 1-2 days of his time to work on the estimate (as we discussed on email @MyriamBoure). This is on top of his OFN allocated time, and is being carved out of his life to try and help you get this moving. So it absolutely has to be paid. It will cost $100/hour, so $1200 AUD for 2 days of work. OFN AU was going to cover this initially as a loan and include in the estimate, to recoup the cost once the funding came through (i.e. we carry risk). We figured this was the best approach as you guys still needed to source funding and didn’t have the cash for the time needed to complete initial solution scoping and estimate. Rob has indicated that he can take on a total of 3 extra days worth of work up till the end of the year to assist with this work, uncertain as to whether this is enough to cover what you’ll need in terms of assistance for @pierredelacroix, code reviews, testing, and release. It needs to be paid for, preferably as incurred if there is money available.

  4. Given the complexity of the work required to do a tax overhaul, we wanted to make sure everyone understands that this isn’t going to be a quick thing to do - we think getting it done by Christmas is very ambitious. What’s in the spec you’ve written @MyriamBoure is not straightforward, many of the changes require a fundamental change to the way tax works in the OFN platform and will have flow through effects throughout the site. Some of the individual changes may not be that complex, but making sure that nothing has broken further along the chain is going to take a fair bit of time and effort. It’s likely to break a fair few things and they’ll each have to be discovered and then fixed (solution designed and fix implemented).

IS THERE A MORE AGILE WAY TO GO ABOUT THIS? Given the users you’re trying to keep, is it possible that a smaller sub-set of a solution would get across the line, and perhaps be more feasible sooner?

That’s it from the 3 of us. A long response and a lot to digest :smile:

Thoughts on the next steps?

6

HOLD THE FORT! :smile:

Rob’s been doing some thinking and discussing with Kirsten and has come up with a nifty solution to how this could be done without impacting on the Spree Upgrade and in a way that will be fairly easy to implement (though still not sure on hitting the end of the year given it’s only 6 weeks away).

He’s in the process of writing this up, stay tuned!

1 Like
7

Thank you @danielle and all the Aussie team for getting your head on it. We’ll wait for Rob’s nifty solution and I’ll discuss with @pierredelacroix then about all that to give you a quick feedback on your proposals :slight_smile: +1 for agility :slight_smile:

1 Like
8

Hiya all,

Nice work @MyriamBoure on thinking everything through! I think for the most part the ideas you’ve put forward are great, particularly in allowing enterprise users greater flexibility and power to control how products appear in their shopfront.

The first thing that I wanted to say is that regardless of how we go about this, there is a lot of work here, and I need to stress that the end-of year deadline looks very ambitious to me. I am sure @pierredelacroix is incredibly talented, but I know that I would need several months to get all of this implemented if I were working by myself. Who knows, maybe I will be wrong (or maybe I am just slow ;)).

My major concern is with making significant changes to the way that calculation of tax works, especially while we are attempting an upgrade (by this I mean removing tax_categories). I suspect that such changes will be very time consuming to undertake, and will certainly make the upgrade process much more difficult, and may mean that we don’t get the benefit of the upgrade with regard to tax.

I noticed that a lot of the issues you mention stem from the way things appear to the user, rather than a fundamental problem with the way the OFN handles calculation of tax. I have been trying to think of a way to resolve these issues without changing/breaking the underlying tax system. I think this should be possible by adding an additional ‘layer’ to the products user interface, to simplify the choices for enterprise users, while still using the existing underlying model to store tax information.

The second problem with removing tax_categories is that it will break the functionality that tax categories are designed for. As I’m sure you know, a tax category can have multiple tax rates associated with it, and each tax rate belongs to a tax zone. When an order is placed, the system works out which zone the purchaser is in, and applies the appropriate tax rate to each product in the order based on that zone. If we remove tax categories and instead ‘hard wire’ each product to a tax rate, we lose this functionality completely.

Removing tax categories also means that we lose the ability to apply multiple tax rates to a single product. We don’t need this in Australia (at the moment) and I am not aware of anywhere that does, but Spree touts this as a feature, so perhaps it is relevant somewhere.

Proposal

Setting tax-inclusiveness at the product level

I like the idea of being able to designate (and override) tax-inclusiveness of a product directly, rather than via a tax rate, via a tax category. However, I think that this is primarily a user interface issue, there is actually nothing stopping up from doing this in terms of the data model. We could keep the tax category on each product and add an additional checkbox for ‘price includes tax’, which could be used to intelligently allocate the appropriate tax rate later on like this:

If each tax category were set up with both a ‘tax inclusive’ and ‘tax exclusive’ tax rate, for each rate of tax required for that category, then we can use the ‘price includes tax’ value (on the product) to decide which one to apply to the product in the shopfront or at the checkout. This will require diligence on the part of instance owner as they will need to remember to set up both inclusive and exclusive rates each time, though hopefully they will only need to do this once. We could also set up a regular automated check to make sure that both inclusive and exclusive tax rates exist if we thought that was necessary.

Option to display prices inclusive or exclusive of tax in the shopfront (set in OC)

I think this proposal is fine. Adding an option to the OC should be fairly straight forward. Actually getting it to function properly will be more work, @pierredelacroix will need to pre-calculate the tax on each product before it is displayed in the shopfront. This will need to be cached in the same way as other product information destined for the shopfront, via the ProductsRenderer.

Displaying tax-inclusivity in the shopfront (incl. VAT, excl. VAT)

Yes, especially if we can make it configurable (which should be easy).

Overriding tax category and tax-inclusiveness of price in Inventory

Sounds good to me. This will mean that we have to take tax_category and tax-inclusiveness of overrides into account at all points we need to calculate tax, but I think this should be achievable. Tweaking the selection of categories should be achievable in the same way as you proposed for hard-wired tax rates: we only show tax categories with rates in the relevant zone.

Adding an option to apply tax based the shop’s zone or the customer’s zone

I think this should be ok. The most recent version of Spree allows for tax to be calculated on the shipping address or the billing address, so I suppose we can just add some additional logic here to allow it to be calculated on the shop address. Not sure about conditionally showing this option only for hubs outside of the instance’s default zone…will need to investigate.

Changes to sales tax report

Not sure I have fully understood, but regardless: the report is not going to affect anything else, so we can pretty much do whatever we want with it.

Displaying separate tax rates in the checkout, order confirmation and invoice

This is one thing that will become much easier after the Spree upgrade, as tax for each rate in split out for each item in the order (and for shipping too). For now however, I think we should be able to work out an aggregate for each tax rate on the order as a whole and report them at the checkout, confirmation and on the invoice, but we will not be able to do finer grained reporting of tax until the upgrade is complete (I don’t think you require this so it should be fine).

Deciding whether or not to display item prices with tax or not in the confirmation, invoice etc. should maybe follow the same convention as the shopfront? So if the shopfront is displaying prices inclusive of tax, the invoice should also itemise product’s prices inclusive of tax (we can still display how much total tax is included in the order at the bottom). Does this sound ok? I think that this is the norm in Australia.

If the opposite is true (shopfront is showing tax-exclusive price) we can itemise product’s prices without tax in the invoice etc. Yeah?

The main trick will be getting the inclusive and exclusive tax rates (as per my proposal above) to display on the one line here. We may need to think more about how we get the system to understand that they are the same tax rate and report them together. I suppose we could just match them based on their name, eg. if they are both called ‘4% VAT’) then we can combine them together at the bottom of the invoice.

I think that pretty much addresses everything in the document. Thoughts?

Alternative Wacky Proposal

We make tax categories and tax rates the responsibility of each enterprise. ie. each shop sets up their own tax categories and tax rates, which only they can use. That way they can manage them however they like, without have to fit into whatever arbitrary conventions we decide are right. Haven’t thought it through but might be an approach worth considering?

9

I am so impressed with the work put into this everyone! I am still trying to wrap my head around the whole thing, and imagine that will take some time :wink:

The only thing I can add at this moment is in reference to the ability to apply multiple tax rates to a single product. As far as I recall (it has been a while) Canada will need this. @tschumilas How are GST and PST applied on your instance? GST is a national tax, while PST varies from province to province unless things have changed in the last decade or so :wink:

10

This is amazing work - it has taken me a bit to get my head around it too.
In Canada - every province has different tax ‘rules’ - and I think we want a Canadian level instance (vs separate instance at each province)

Some foods in Canada are taxed and others are not - so this has to be at the product level. And there are 2 possible taxes - PST (provincial sales tax) and GST (general sales tax). In some provinces (Like where I am in Ontario) these are combined into one tax (HST - harmonized sales tax), but in some provinces they are still both applied and calculated on the base price separately. So in short, yes, we need the capacity to add 2 different taxes to products.

Just like Canadians to complicate things :slight_smile: (But I suspect there are differences across different states in the US too.)

11

I thought I should also affirm (and I think you are all already assuming this - but just to be sure) that these different tax rates are applied to some ‘services’ as well as to selected ‘products’. So - we also need the capacity to calculate more than one tax rate on a service like shipping, delivery, packing… Right now many food hubs I’m working with don’t do this - because not for profits across Canada do not pay tax, and most of the food hubs are not for profits. BUT as soon as we get a registered business user, they will need the capacity to tax the delivery, or the packing…as well as selected products.

12

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 :wink: I summed up the new options to organize tax in this new google doc document:
’ International-fit VAT treatment v2 - Google Docs
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 :wink:

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 :wink: 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 :slight_smile:

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”

image_taxrate.png735×239 14.3 KB

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 :wink: 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 :slight_smile:

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 :slight_smile:

13

Thanks @MyriamBoure! See comments on the new document. :slight_smile:

14

You are correct that there are not that many different tax combinations - BUT if a shop is selling a taxable product or service in a province that has 2 different taxes (PST - provincial sales tax and GST - general sales tax for example), then the shop needs to know and report how much of each different tax they collected. The reporting of PST and GST would go to different levels of government - so a shop would have to be able to separate them. A combined total would not work in these provinces for the hub manager, and it wouldn’t really work for the consumer either - since in CAnada consumers are accustomed to seeing each tax and its percentage as a separate line on any invoice (since we never include taxes in the price). Consumers look for these on taxable products.
I’m amazed at you @MyriamBoure, @oeoeaio and @CynthiaReynolds for your work on this. It boggles my mind.

15

Thank you @oeoeaio for your comments, I think I answered them all, I really think it’s gonna be hard to use the tax category / zone management feature… see my comment.
Your proposal to let every enterprise select among the tax categories configured by the instance which ones she wants to be able to choose from when adding / overriding a product seems to me doable, a bit more work to do for the hub, but maybe a necessary hub (they have to ask themselves the question anyway), and going in the direction of your “wacky” proposal :wink:
I think it’s ok to say that you have a dedicated hub for each zone you target, and in the entreprise set up for the hub, you override differently the products with the right rates depending on the rules for each zone you target. It enables to modelize complex cases. And then you can manage them all in one OC just having multiples hubs in the outgoing section.

Just for the case of Canada, we need the possibility to associate two VAT categories to one product, I explained a case in the document.
I left all in a “modification visible status” so that we keep track of the modifications (I deleted stuff and made changes given your suggestions Rob) If anyone want a more “readable” version you can always select the “viewing” mode :slight_smile:

16

Hi @MyriamBoure, sorry I couldn’t respond until now, I know that time is important for this.

I will add more specific comments in the document later, but I think we are getting closer to a solution in regard to tax-categories and tax rates. How does this sound?:

  • We have ‘instance’ tax categories that are set up by the instance owner, to cater for the most common tax configuration within the relevant country. These will behave in the same way as existing tax categories, no need for enterprise users to configure or select them, they will just be there to use - so presumably most users will just use these and will never have to engage with the next two dot points.
  • To cater for enterprises with specific requirements, we allow each enterprise to have the option to add its own ‘custom’ tax categories (which only they can see), which they can configure however they would like. They can name them however they like, and configure the rates however they would like in each.
  • Enterprises also have the option to ‘disable’ the default instance-level tax categories, so that they don’t see them any more.
  • As discussed, we allow tax category to be overridden in the inventory page.

Does that sound like it will handle most of our problems (particularly ones relating to cross-border trading)?

With regard to the Canada scenario, and having two tax rates apply to a single product, the system can already handle this. If the tax category on a product has two tax rates for the relevant zone, they will both be applied to the product at checkout. You might have a tax category for BC called: ‘GST + PST (7%)’, and have one rate for GST (5%) and one rate for the PST in BC (7%). If it was me, I would probably set up a category for each of the different combinations of GST/PST/HST across the provinces at the instance level, and allow users to select/hide them as required. I guess that decision is up to @tschumilas though… :wink: Does that make sense?

Still not 100% sure about the need to specify tax-inclusiveness at the product level. I think I understand the use case (users want to enter prices as tax-inclusive or tax-exclusive), but I’m just wondering if this is actually better solved using custom tax-categories for users who really need it, rather than forcing every user of OFN to specify tax-inclusiveness on every single product. I am just a bit wary about making large and time consuming changes for what turns out to be a rare use case: we’ve done that a few times on this project and it is not fun… :upside_down:

17

I’m all for simplifying things @oeoeaio - thanks. I’m going to go back and try to set up the instance level tax categories in Canada as you suggest - not sure why I didn’t try that before - maybe I just assumed I could only set up one category. I’m going to do some experimenting today.

18

Thank you @oeoeaio for this new proposal.

I think it will be more job actually to let every hub create it’s own tax category and tax, for two reasons:

  • it’s complicated to understand, I am 100% sure that we will need to support the hubs in setting hub their VAT categories and rates if they don’t enter the main instance tax categories… and I would like to avoid that. It is easier to manage for the instance to enter the new tax categories needed by a hub in a new zone, so that we don’t have to do the job again when a second enterprise in the same zone show up.
  • AND I think there is value added to enable the hub to set up the default tax categories they want to be proposed when setting up products, etc. So they only see what they need. The instance set up what tax categories are checked by default for all enterprise (the main instance tax categories, so most of the enterprises won’t touch the default set up), and then if the enterprise want only to see the 5,5% tax category because they only sell food or see the Spanish tax categories because they sell food from Spain, they can select or deselect the categories.
    So I prefer your previous solution :slight_smile:
    I would add one thing in the “VAT set up” menu for “producers”: choose if their prices are by default including VAT or not (so we know by default if the “VAT included in price” checkbox is checked or not, and if a hub want to connect with an existing producers later on, he could easily know if the catalog of the producer includes or not VAT)

Tax inclusiveness has to be at the product level.
It is super hard to impose users to fill in all their prices including or not incuding VAT… It’s not a rare case, I have been confronted myself to the case when running my hub in Norway and I know @CynthiaReynolds has it too. We were selling products from a distributor whose product catalog was excl. VAT, and products from producers whose catalogs was incl. VAT, we had to calculate manually for each product of the distributor the price incl. VAT to enter it in OFN, and we did made mistakes because rates were not the same for all products also… so it’s a super common case! And the custom tax solution doesn’t solve the problem anyway.
Also look at that case: Hub A join the OFN and wants to work with Producer A and Producer B. The super admin connect him with the two producers. Hub A want to add products to his order cycle. He has no idea if the price in the producer catalog includes VAT or not if it’s not managed at the product level…
A producer usually will have one way of entering prices, all incl. VAT or all excl. VAT so that’s why I propose to set it up in the “VAT set up menu”. BUT it’s better to let the flexibility to uncheck the box so that we can handle all cases.

So I’m sorry @oeoeaio but we won’t be able to avoid that big change I’m afraid… :confused:

I made some other changes in the document, please feel free to accept the changes if you agree with them or add others so that we can step by step clarify the document and only let the comments and suggestions that are not yet solved :slight_smile:
'https://docs.google.com/document/d/1xr27DEnGzmuh2WA74gRPZ90J7w-nZMatr8VJKQ6WPS0/edit?usp=sharing

Great to know that two tax rates can apply, it seems we have an easy solution for Canada, hopefully that works!

19

@Kirsten just wondering if this somehow relates to private vs open products or some other aspect of the p/v overhaul? Thinking that maybe something there could get us to the point where we don’t have to set a tax category on a product until we actually know where it is going to be sold? Having producers set tax categories on their products that then need to be overridden by shops seems like a very confusing way to set this up.

@MyriamBoure, just so that I am clear: it seems to me that the difficulty here is derived from producers setting a tax category on products that are then sold through other shops, is there any reason for producers to set tax categories on their products at the top level? If we made it so that tax categories were only set in the inventory, would that make this more manageable?

20

@oeoeaio in France if a distributor buys and sells a product with a markup, the VAT that applies is the same as the one of the original product, so it doesn’t depend on the distributor, but on the product. That’s why UK had added in enterprise fees VAT set up “inherit from product”.
Also, a producer himself can use it’s own product catalog for his own shop… and some producers have to pay VAT. So I find it hard not to put the VAT at the product level. It usually doesn’t depend on who is going to sell the product… BUT it can, depending on local legislation. Like in Spain for exemple, the VAT rate that applies depend on the legal status of the distributor, it can change. That can’t happen in France, a carrot always has the same VAT rate. That’s why we need the possibility to override…
Most of hubs don’t use the inventory feature also…

By default in the inventory (for the hubs using it) the VAT rate is the same as original product, and the distributor won’t have to touch it.
But in some cases, like the guy in Spain selling to France on the French OFN instance, he buys products at a Spanish VAT rate and sell them at another Spanish VAT rate (there the VAT depends on his legal status), so he will need to override the VAT rate…

Even if we completely review the inventory / incoming products in OC, and say every shop has an inventory by default, which is the list used for “incoming”… how would a distributor know if the producer have filled in his master price with or without VAT? Does it mean every hub would have to redo the same job of putting the same VAT category to the product “carrot”?
Culturally, on the VAT, Europe (and Canada from what I understands) is super different from Australia, in Australia everyone think without VAT, which is mostly not the case in France, people who work in BtoC mostly think and talk with VAT, but people working in BtoB think and talk without VAT.

@tschumilas @CynthiaReynolds @NickWeir @sreeharsha please correct me if I’m saying something wrong for your own cases…

@oeoeaio there were various files shared, so to make sure there is no confusion here was the latest version from our iterations International-fit VAT treatment v2 - Google Docs