Co-budget and organization around the tax overhaul dev


#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.


Specification for tax management overhaul
#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 @nick @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 https://docs.google.com/document/d/1xr27DEnGzmuh2WA74gRPZ90J7w-nZMatr8VJKQ6WPS0/edit


#21

Sorry I’ve been silent - I have been trying to follow this - and I’m not sure I do. But - let me explain the Canadian case –
FIrst - luckily - only a small number of food products traded on OFN are taxed in CAnada - for example, only so called ‘snack’ or ‘convenience’ items - so for our hubs this would mean products like: popcorn - or other things sold in single-use packaging. Plus - we have hubs that sell non-food items - herb plants, vegetable seedlings, soap, flowers - these are all taxed. But still - it is a specific sub-set of products.
Second - we have a ‘double’ tax system that applies to the above taxable products. Each different province or territory (what you call ‘state’ in the above discussion) decides how to integrate these.
There is federal tax (GST or general sales tax - which is the same rate for the whole country and calculated on the same products ) and provincial (state) tax (PST - which varies in percentage, and in the products it applies for each province). To complicate this - in some provinces (like Ontario where we are launching OFN first) these two different taxes are combined into one - HST (harmonized sales tax) . So those provinces are easy. BUT, where the province has decided to keep them separate - so they have 2 tax categories (GST and PST) - we need to be able to calculate them SEPARATELY and show them separately on an invoice.
One option would be to set up different instances with different tax categories at the instance level - that would mean we would set up separate instances for each Canadian province (state) - but then this would curtail trade across provincial borders - which one day we will certainly want to do. Plus there are likely added expenses to set up all these separate instances.

This said - right now in Canada we can make the current system work for us - with the solution suggested above - each province/state has ONE designated tax category. That means combining PST - Provincial Sales Tax and GST - general sales tax - for a single tax percentage). This means that a vendor would need to separate out and hand calculate the PST and GST portions for reporting and remitting purposes (these taxes are paid to different governments) - but since the number of products they have to do this for will be small - it is not THAT problematic. Long term it would be great to fix it - but if a short term solution ‘tables’ the problem for a later fix, that is fine.
@MyriamBoure @oeoeaio @Kirsten @CynthiaReynolds @nick (not sure who else should be pinned)


#22

EDIT: I ran this idea by @Kirsten and she picked up a few problems with it… :frowning: I’ll keep working on fleshing it out as an idea, but let’s go with @MyriamBoure’s approach for now. :slight_smile:

Sorry @MyriamBoure, I articulated my idea very badly. My idea was not to set the tax category at the shop level. I am simply thinking about setting the tax category on products in a slightly different way. I will try and explain it better. NOTE: this idea involves a reconfiguration of how products and prices work, but we are talking about that as part of the p/v overhaul. Some of what I am about to say will go off the topic of tax, but I am just trying to provide a context for the idea have had.

I suppose that this is what I am proposing. Tell me if this is wrong for your countries (@MyriamBoure, or @tschumilas, or anyone else), but when a producer sets up a product, they do not need to know whether the tax applied to the product when it is sold will be “included in” or “added to” the price, right? They should be able to just enter the tax-exclusive cost-price (ie. the price they will be selling it to hubs for). If this assumption is wrong then I suppose my idea will not work, but read on and tell me what you think.

I am thinking about the products page as the place where producers do most of their work, and the inventory page as the place where hubs to most of theirs. So, assume that we have a product that has a cost price that has been set up by a producer on the products page. It probably needs a markup added to it before it is sold through a hub. If we think about the inventory page as the place where markups are applied to products, and where tax categories are applied, then we remove the problem of hubs having to think about whether the the prices coming from producers are tax inclusive or exclusive: they know that they are tax-exclusive, and so they can apply tax-categories in a uniform way across products from all producers.

This may even allow us to completely remove tax inclusiveness from the management of products entirely, because we could potentially set up whole inventories as having either tax-inclusive or tax-exclusive prices by convention. Just an idea, but this seems logical to me. What hub manager wants to enter a mixture of tax-inclusive and tax-exclusive prices within one inventory?

SIDE NOTE: by “markup”, I mean something very similar to enterprise fees (they may even be the same thing, I haven’t worked that out yet). If we introduce the idea of “cost-price” (from the products page), we can then add a “markup” that could be a percentage, or a fixed amount, or maybe even a formula to determine the “sale price”, which can then be marked as tax-inclusive or tax-exclusive. I am imagining that these markups could be “pre-canned”, ie. you set them up just like enterprise fees, and then apply them to whichever products you like.

If we implement this separation of responsibilities between the products page and the inventory page, producers who are selling B2B can just not set a markup in their own inventory. If they also want to sell B2C, then they can have a separate inventory for that, where appropriate markups are applied. These different inventories can then feed into their respective order cycles.

So that is the context for my comment that “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.” I just didn’t explain myself at all. Sorry. :grimacing:

I think in this regard we are culturally much more similar that you think. :wink: In general retail prices in Australia always include GST (our version of VAT). For example the bill at a restaurant, the total will always be given as GST inclusive. The only difference here is that at the moment most unprocessed food products are not taxed at all, but things may not stay that way forever. For the few foods that are taxed, my understanding is that this works in a very similar way to European VAT, both culturally and technically.

Same goes for B2B, because most business expenses are tax deductible, prices for most commercial (B2B) products and services are provided as an amount “plus GST” ie. tax-exclusive.


#23

@tschumilas I think that that this is only partially (or temporarily) true:

For provinces with two separate tax rates, you should be able to add both rates to the tax-category for that province, and they will be calculated separately. At the moment, these separate rates are not split out on the invoice, but it is my understanding that they should be visible separately in the sales tax report? If I am wrong, we should be able to get the system to do this, particularly after the Spree upgrade is complete. Splitting them out in the invoices is a priority for France too I believe, and @MyriamBoure and @pierredelacroix will be working on a solution.


At the risk of adding confusion to this discussion: I have been thinking about the Canadian case, and there is an alternative and possibly simpler way of setting up taxes (more closely modelled on the US approach, which is the system Spree was initially designed around). Am I correct in understanding that the tax-exempt status of a product does not vary between provinces? By that I mean, are there examples where a particular product would be subject to tax in one province but not in another?

If the only difference between how a product is taxed in one province vs another is the tax rate(s), then I think you may be able to use just one tax category, which is loaded with all of the different rates for each province (each province is set up as a tax-zone). If you then apply this tax category to a product, the system should just automatically work out which rate(s) to apply based on the zone that the order is being shipped to.

Perhaps this setup is problematic if you wanted to display the prices inclusive of tax in the shopfront (this is standard practice, yes?), because there is no way of knowing which tax rate to apply without the customer somehow specifying where they are located before they place their order - though I suppose this could be achievable.


#24

Oh, if it were that simple :wink: The federal tax (GST) applies to the same products and at the same rate (%) across the country. BUT, provinces are empowered to set different provincial taxes (PST). So this can result in the same product being zero rated in one province, but taxed in another. (Muffins would be an example - and I was just chatting with a hub about this. This is a hub in a large workplace, and they want to sell single muffins when they do their delivery in the afternoons. (nice idea). This is considered a snack food (vs a basic grocery). In Ontario this is taxable (13 % HST), but in BC I believe this incurs tax.

These taxes are getting so ridiculously complicated here - and they are constantly changing. so I’d say for the sake of a ‘easy’ future - planning from the premise that different provinces will have different tax exempt products AND different tax rates is the best approach.

But i want to say again - don’t let the Canada situation hold back something that works for everyone else because in the end, very few products traded on OFN will be taxed anyway.


#25

You are correct. And I like your approach here. A ‘producer’ on OFN, in essence might wear 2 hats - one as a ‘pure’ producer who sets the ‘cost’ price (I’d call this a ‘base’ price ) . This is the money they expect to get when they sell to another enterprise (who adds a ‘markup’…). But in addition, for some (but not all) producers, they also become B2C sellers in a shop. So in a way they become like another ‘middle’ enterprise, and (at least in Canada) usually add a ‘markup’ to their base price when they sell directly to consumers. So they’d add a tax here too for taxable products.

just as an example to be clear - i am a flower farmer. flowers are taxable in Canada. . I vary the base price (you call this the cost price) based on the quantity they by - but in no case do I add taxes. The hub adds the taxes. In Canada, a consumer must only pay the tax (whether it is provincial or federal) once. There is to be no ‘double taxing’, and no ‘taxes on taxes’. (And consumers watch for this.) So, when I sell flowers in my own shop, I add the tax for the consumer, and I remit this to the government(s).

Theresa


#26

@oeoeaio the work has already been done by @pierredelacroix on seperating the different tax rates on the invoice and sales_tax report, it’s been pushed and just waiting or approval. Si this should be available for the community in the next release.

Thank you @tschumilas for those new elements. We need to find a system that works for the Canadian / French / Scandinavian instances as well as stay ok for UK and Australia… basically find a “one fits all” solution… So the system we set up needs to work for Canada, it’s a good use case.
We have the same issue on the French instance where already hubs based in Spain are trading and soon from Belgium maybe. Tax rates vary also from type of products between countries in Europe :-o

Also on your flower case, what I see is that there is a cultural factor here that we should also consider… Technically in France a producer could set up his price excluding tax, so we could set this as a rule for the whole instance. BUT we already had negative reactions from farmers/hubs who only sell in BtoC and don’t even know their price excluding tax… so it would mean for 90% of our users they would have to recalculate all their price to exclude VAT before filling them in. This is no acceptable for our users I’m afraid… for most European countries it will be the same.

I found for Ontario (I guess it’s the same for other states) “Usually, HST is added at the cash register so the amount on the price tag may not be the final price.” but it doesn’t seem to be ALWAYS the case… @tschumilas can you confirm that some people might want to display price in the shopfront including taxes? In which case for example? (for our understanding)

Also I have a question @tschumilas, culturally speaking how do people usually talk about VAT in Canada? Do you talk in term of products (Food VAT) or in terms of rates (12%) or …
Like in France, we say that for Food the rate is 5,5%, but no one know about the tax category (“reduced rate” here)
It seems in Canada people will say that Food is taxable or not taxable and GST/PST/HST and not in terms of rate… am I right? You won’t say that “this muffin is taxed 12%” but “this muffin is taxable and the VAT that applies is HST” but you won’t talk in terms of rate. Am I right?
I think it’s important that the way we overhaul the tax system “talk to the people”, so that tax categories should be designed in that prospective. In France we need the name of taxe category to be “Reduced 5,5%” but for Canada it could be only “HST” or “PST+GST”.

It seems in Canada the rate that applies in trans-province sales is the one of the buyer so the default Spree set up could apply. But this doesn’t work in the case of France. A hub based in Spain selling in France, until his turnover is below 100K€ the VAT rate he has to apply it the one from the origin country, above the threshold he has to collect French VAT. So basically the rate that apply is not the one of the consumer zone until he sells for more than 100K… the Spree tax system doesn’t consider that case…

Here is a modelisation attempt raising also some issues and comparison with needs in Europe:
https://docs.google.com/document/d/1MYJMZxIeLDMYCwjeBFUW7Vu9Lz1l33LXTkAnm9Xrn3g/edit
Feel free to comment on it :slight_smile:

@oeoeaio the main issue I still see in the last version we came up with (https://docs.google.com/document/d/1xr27DEnGzmuh2WA74gRPZ90J7w-nZMatr8VJKQ6WPS0/edit) is that for a hub selling trans-provinces or trans-countries he might need to set up a different entreprise for each zone he sells to… I explain it at the end of the document.

If you have another idea on how to move forward in that super messy VAT festival… Unless rethinking it from scratch and accepting to change all the calculations :-o


#27

Sorry I replied before having read your last post @oeoeaio!

I’m afraid your assumption doesn’t work for France and most European countries @oeoeaio :frowning:
As I said by default in France some people talk and think in tax-inclusive prices (those working mainly in BtoC = small producers, buying groups) and other will talk and think in tax-exclusive prices (those working mainly in BtoB = distributors, wholesalers) So a hub can have in his inventory products that have been filled up as tax-exclusive and products that have been filled up as tax-exclusive…


#28

I see an issue here, with tags. We have shops setting up to outgoing distributors with different markup depending on customer tags… so that can’t be done at the inventory level :frowning:

This is technically possible but hard to apply in France at least as explained before… a hub managing a catalog producers on his name will usually receive an excel spreadsheet or a PDF with tax-inclusive prices… The hub always pay the tax-inclusive price to the producer.

  • If the hub is not within the VAT scheme (2/3 of our users so far) he will just add up the markup to the tax-inclusive price he has paid to the producer (he does’t deduce nor collect tax so he can’t add up a markup only on a tax-exclusive price…)
  • If the hub is within the VAT scheme he will write in his accounting the amount he has paid as “tax deduction”. he will add the markup on the tax-exclusive price of the products and collect VAT on (original tax-excl. price + markup) and write the amount in “tax collection” in his accounting, so in his accounting he will pay to the state VAT collected - VAT paid to the producer.

That makes me think that we might have also to add in an entreprise fee set up if the fee applies on the base price incl. or excl. VAT… I forgot that point.

##Other idea building on your proposal

I will try to think more in your direction @oeoeaio as I understand the interest of your point of separating the pure “product list” and tax excl. price manage by the “producer hat” and the markup and VAT added by the “distributor hat”… there might be a way maybe to allow a producer to import a list of products with tax-inclusive price + the VAT category info and that the system “retreat” that information to register the tax-exclusive amount + VAT rate in the default inventory information… (@lin_d_hop I guess this is connected also to the data import discussion… so I ping you here.)
Then for the info to be super clear to the user I think in the product info should appear both the default tax rate, tax excl. price AND tax-incl.price (they might be surprised if they import a tax incl. to see that the price displayed is different… so they should see both prices and they would understand clearly).
By default every “distributor hat =hub” would have an inventory, which would be the same info as in the producers catalogs he is connected with (as it is today).
With my “distributor hat” I could add a mark-up to my own products, and I could check a checkbox saying “apply on: 1- tax excl. price or 2- tax-incl. price”… but that should be done in the OC-outgoing section as the markup could vary depending on tags.
Would something in that direction be possible?

It doesn’t solve our problem on how to set up the tax categories though (and we still have the issue if we follow my proposal that a hub selling to different VAT zone will need one inventory/hub/shopfront per zone), but it removes the tax-inclusive/tax exclusive thing though.


#29

I think one of our underlying issues here is that when I talk about tax - I mean ‘retail sales tax’ and when @MyriamBoure talks about tax (and likely all the EU) she means ‘value added tax’. These are different in subtle ways and that is our challenge. I had never even heard of ‘VAT’ before OFN - I just assumed it meant the same thing as ‘sales tax’ as we call it. so - I finally googled it - https://tax.thomsonreuters.com/blog/onesource/sales-and-use-tax/difference-sales-tax-vat-2/

Sales tax is collected by the retailer when the final sale in the supply chain is reached via a sale to the end consumer. End consumers pay the sales tax on their purchases. No part of this money goes to the producer or seller. but sometimes its hard to know when someone is the ‘end consumer’. so for example: A small sized flower shop (like me) might ‘buy in’ flowers I don’t have to re-sell. The supplier I buy from might consider that I am the ‘end consumer’ because my order is small. So - i paid a tax on something I want to re-sell. As a retailer, I should not have to pay this tax - it is not one of my costs. So - I list the product, with the tax in my shop - the consumer pays it. (Now that tax has been paid twice - once by me when I bought it, and once by the consumer when they bought it). SO - I ‘claim’ it and get the tax i paid back. The burden is on the consumer not the retailer. So thats why in a sales tax system - the easiest thing for us - is for the producer to have no tax on their products when they sell to the hub, and have the hub add the tax where applicable. That way the hubs don’t have to ‘re-claim’ all the tax they pay.

VAT (Value-Added Tax) as I understand it - is collected by all sellers in each stage of the supply chain. Suppliers, manufacturers, distributors and retailers all collect the value added tax on taxable sales. Suppliers, manufacturers, distributors, retailers and end consumers all pay the VAT on their purchases. Businesses must track and document the VAT they pay on purchases that will be resold in order to receive a credit for the VAT paid on their tax return. Tax jurisdictions receive the tax revenue throughout the entire supply chain as opposed to at the sale to the final consumer chain.
So OFN also needs the capacity for VAT.

So we need capacity for both sales tax (added onto a ‘base’ price by a seller and paid by a consumer) and VAT (included in the producers price, and also added on at subsequent steps in the ‘chain’) - Is that helpful? Does the platform have 2 different ‘systems’ at work - and an instance chooses first - this is a VAT system or this is a sales tax system? (Then what happens when we sell between instances?)


#30

If the vendor is a small business (I think the limit is gross revenue less than $30,000/yr or something like that) - they do not have to register as a tax collector. So in that case - a non-registered seller would not add tax to a product. BUT - if you are not registered, not only do you not add on tax and charge the consumer, you also have no possibility of re-claiming taxes you pay. So for example - on my flower farm, I buy lots of inputs (straw, floral packaging, tools, fuel, mobile phone…) and I typically pay taxes of 13% when I purchase these. If I am ‘registered’ with the federal government as a ‘tax collector’ (in other words i charge taxes to consumers on my flowers - REGARDLESS of the fact that I am under $30,000/yr in sales) then I have the opportunity to claim back all the tax I paid. SO - most small businesses (farms and food hubs included) would register and charge tax, even though they don’t have to, because what they can ‘claim back’ (taxes they paid out) is greater than the taxes they charged. So last year for example - I think I received something like $500 is taxes from end consumers - but when i added up all my receipts from inputs I bought for the farm - i paid out over $3000 in tax. So - I got a refund for $2500. So while it is possible that a vendor is not registered and therefore doesn’t charge tax - it is not very typical because it usually works in their favour to be registered.

Regarding shopfont display - I think that sometimes - especially smaller firms/farms want to show their price is competitive with a ‘conventional’ seller (like a big store). So, for things like selling plants (which is taxable) - they would say ‘tax included’ - so the consumer can do a mental calculation and compare the cost with a big nursery’s prices (where tax is not included and would be added at checkout). BUT - this comes about because those small hubs/farms are accustomed to face to face sales (farmers markets, roadside sales, event sales) where no one wants to do the calculation at the checkout because it is primarily cash. So - I’d say OFN is different because the consumer will see that tax is on their invoice.


#31

This is a good point - see my post re sales tax vs VAT. For one thing - we have no idea what VAT is (I never heard this before OFN). We would just say - that the muffin is ‘taxable’ - in other words - remind the consumer that this is a food item that incurs tax. (and in that example we’d remind them that if they buy 6 there is no tax - because now this is no longer considered a ‘snack’ purchase - it is a ‘staple food’ purchase and those are not taxable.)
We would not reference that ‘tax rate’ because in a given jurisdiction we would all know what the rate is.


#32

Wahou, what a beautiful Canadian / French / Australian cooperation :slight_smile: YES! Theresa, you got it :slight_smile: Now I start to understand better.
SO I think to overcome that issue,the easiest thing could be the last idea I proposed: in the product infos,why not having 3 fields: price excl. tax, price incl. tax, and VAT category, and leave the user choose if he wants to fill in the price inc. or excl. tax and set up the VAT category for the product? And the other one fills in automatically.

That way we would have the info with or without tax.

  • If the producer/hub sells to end consumer:
  • in the Canadian case he can display the price without tax but add the tax at checkout.
  • in Australia and France he can display the price incl. tax and just display clearly what was the tax included at checkout
  • If the producer/hub sells BtoB:
  • in the Canadian case he can display prices without tax and not add the tax at checkout
  • in France he can display prices without tax and add the tax at checkout.

Wouldn’t that solve all our issues @oeoeaio ?

For a buyer selilng both BtoB and BtoC he could manage with tags which shopfront to display to the user. For ex in your flower case @tschumilas your supplier could have a shop for “tax registered clients” and another for end-consumer clients, or manage that with tags.

As you said before @tschumilas the “taxable” quality of a muffin can vary from state to state. So it goes in the direction that every hub selling a product should define in his situation if the muffin is taxable or not… so you could have two tax categories type:

  • taxable

  • non taxable
    And you will have multiple tax rates then to cover the cases of your users and use the default Spree functionality which uses the tax rate corresponding of the zone of the buyer.
    So if a hub sells in Ontario a muffin primarly sold by a producer in BC. The producer in his inventory has set up the muffin as “non taxable” as it’s not taxed in BC. The hub in Ontario will override that info and set it up to “taxable”

  • The tax rates behind “taxable” are set up like this:

  • Tax zones=
    Canada > state type zone, associated with Canada
    GST 5% > region type zone, associated with YT, NT, NU, BC, AB,SK, MB, QC
    PST 7% > region type zone with BC, MB
    PST 5% > … SK
    PST 9,975% > … QC
    HST 15% > … NS
    HST 14% > … PE
    HST 13% > … NL, NB, ON

  • Tax rates=

  • category “taxable”, zone “HST 15%”, tax rate name “HST 15%”, rate “0,15”

  • category “taxable”, zone “GST 5%”, tax rate name “GST 5%”, rate “0,05”

  • category “taxable”, zone “PST 5%”, tax rate name “PST 5%”, rate "0,05"
    etc.

So If I’m in SK and the muffin has the tax category “taxable” the valid tax rates will be the 2 associated with SK zone, which are GST5% and PST5%.
If I’m in ON, only the HST 13% tax rate will be the valid one as the only one associated with ON

Would that work?

The only remaining issue is that a hub selling to multiple VAT zone will have to manage an inventory/shopfront/hub for each region… but I don’t see how to overcome that as VAT rules are so specific from country to country… the case of our Spanish hub who needs to apply the origin rate below a certain turnover and the customer rate above is a good example, I don’t see how to find a rule that fits all…


#33

Hi everyone here!
I have launched the co-budget bucket for the estimation stage: http://cobudget.co/#/buckets/1012
One of our French users said he would contribute to this estimation for $500 AUD, so it remains $700 to cover. Can Norway @CynthiaReynolds contribute to it? UK @nick or @lin_d_hop? Canada @tschumilas?
Lets kickstart our first mutli-instance co-budget bucket :slight_smile:
Whenever we have decided on cobudget stewardship we’ll add your promised contribution into co-budget.
As @oeoeaio is going to work on it the money will be to transfer to OFN Australia (unless Rob want us to pay him directly?)
Ping @Kirsten for info.
Cheers :wink: