There are still issues with the way tax is calculated and displayed, particularly when ‘forward’ calculated tax rates (included_in_price=false) are used. It is becoming obvious that using tax rates that are calculated ‘backwards’ (included_in_price=true) is not the preferred option for most OFN instances other than Australia.
This thread is designed to hold a list of outstanding issues relating to tax (currently documented in GitHub issues #773, #725 and #788)
See this comment for a technical overview of how tax is currently calculated and stored for line_items and enterprise fees.
[Bugfix] Calculate tax on fees with ‘forwards’ calculated tax rates correctly. (This is currently broken on all instances - see #773) - Done
HIGH PRIORITY
[Feature] Add ‘forward’ calculated tax to price of products + fees as they are displayed in the shopfront / cart / order summary / invoices (see @Olivier’s comment and @MyriamBoure’s comment here and here) - DOING
[Feature] Allow Enterprise Fees to ‘inherit’ their Tax Category from the products to which they are applied. For use case see #788 - Done
LESS URGENT
[Feature] Show a breakdown of aggregate tax for different tax rates (legal requirement for France/Norway?) in the cart, order summary, invoices, etc. (see @MyriamBoure’s comments here and here)
NICE TO HAVE
[Feature] Included tax is shown in the price breakdown on the shopfront (regardless of whether it has been calculated ‘forwards’ or ‘backwards’ - see second dot point in @MyriamBoure’s comment )
[Feature] BtoB hubs can opt to not add tax to prices of individual products / line_items in shopfront / cart / order summary / invoice (see first dot point in @MyriamBoure’s comment )
The breakdown of aggregate tax for different tax rates is not an issue in the UK - we only have one tax category for food products.
Stroudco has found a way to work around the VAT problems by doing all that work in quickbooks. I will check with the Stroudco manager and get his view on all this but for now these priorities look good to me
Thanks for all your work
Here there is something I don’t understand (I read the technical post also but not sure I understand either :-o)… because from what I had understood, in Australia the master price of the products doesn’t include tax, does it? See here Kirsten’s comment on the 7th December: “you don’t put the prices in with vat, you choose whether the product should have tax attached or not, then it will be added or not”
So when I read that I just want to be sure I understand well and we are on the same page, so I made a quick table:
I think it’s a good practice to put the prices in master price always without VAT, so that then if the product is used by another hub, there is no misunderstanding, and especially for hubs that buy to producers in another country, it’s important that all the master prices are without VAT.
So definitely, Norway, and France, want to write the master price without VAT and select in the product page the VAT rate that should apply to the product.
So I if (included_in_price=false) means exactly what I said, then that’s our preferred option, so if that’s the preferred option for Australia then we are on the same page
BUT I think the main difference is that we want the price displayed in the shopfront to include the VAT, which doesn’t seem possible today. That is why actually @NickWeir uses an entreprise fee called “VAT” to be able to include the VAT in the shopfront view (but I’m not sure that’s really what we should do, because it appears as “admin fee” for the customer…)
So of course, ideally we would like to give the choice to the order cycle coordinator to choose, for the order cycle, if he wants to display the VAT in shopfront or at checkout (so that a hub working with business and customers can adapt his shopfront to his customers type). BUT as you say, this is just nice to have for the moment.
What we need is (I will reformulate as I don’t understand the “forward calculated tax”)
1- HIGH PRIORITY [feature] to be able to display the price in the shopfront including the VAT.
Ex: banana cost 10, 10% VAT, 20% admin fee with 10% VAT on the fees, price shown is 13,2 in shopfront (10+1+2+0.2)
NICE TO HAVE [feature] Allow the order cycle coordinator to choose if the VAT is displayed in the shopfront or only at checkout
2- How is that shown in price breakdown? HIGH PRIORITY [feature] should be one of the 2 options:
Each line is shown including VAT, without precising the VAT in the price breakdown > If easier we can go for this option. Ex: price breakdown shows item=11, fee=2.2
BUT it will definitely be more transparent if in the price breakdown, you would have one line for the VAT, because actually the item line for me show how much get the farmer (and the VAT is not something the farmer get!) Ex: price breakdown shows item=10, fee=2, VAT=1.2
What do you think @NickWeir?
I’m actually pretty fine with both options, maybe too much details make things hard to read too…
I think we should just choose together one of the two options, as both are consistent, so what is the easiest and more easy to grab while remaining transparent for the customer? Ping @Olivier and @CynthiaReynolds on that point
3- How is that shown in the basket page / checkout page? [feature] show a breakdown of aggregated tax for different tax rates
Yes, that’s it, but from what I see it might already be done in the checkout page (we just need to check when the bug on fees tax is solved if the tax on fees are added in the aggregation process). Actually I checked back and the legal obligation is only on the invoice, so maybe we should treat that point in a seperate discussion about Norwegian invoices, and take that out of this whishlist. But we will need that info to be displayed in the invoice so it’s good to have that in mind so that the info can be taken somewhere
Ouf! I hope all y comments are clear
And I send you lots of energy @oeoeaio, working on tax is not that fun I guess
From: Stroudco [mailto:manager@stroudco.org.uk]
Sent: 22 January 2016 11:20
To: nick@nickweir.co.uk
Subject: Re: FW: [openfoodnetwork] Orders show VAT figure based on master price (excluding mark-up) (#773)
Hello Nick,
First of all let me say what we need it to do and what we don’t need it to do as far as I can see.
IF we show tax at all:
For any VAT-able product, the system should be able to find a total of price plus enterprise fee and calculate how much VAT is included in this. This should be the total divided by 5, in the case of a 20% UK VAT rate.
Ideally this should happen for each line item as well as the total, so that the customer can see which item had VAT included.
We, as the hub, don’t need it to calculate anything on the master price, that is, the product price, as far as tax is concerned. But I realise that may not apply to the needs of the producer.
If I understand the question correctly, setting enterprise fees at product level doesn’t do anything at the moment. So anyone with both VAT and no-VAT items has a problem? For us, it only affects our own producer account, so we can find a work-around. For example, we can calculate the price offline and not use any enterprise fees at all - or one for 0%? We then simply enter the price plus markup plus any tax if needed readily calculated into the master price field.
BUT, BUT, BUT WE REALLY WANT TO GO LIVE WITH OFN AS SOON AS POSSIBLE SO…
If all this is too complicated to fix within the next couple of weeks, we can simply not show any tax. The order confirmation is not a tax invoice so we can do all the VAT invoice work in Quickbooks.
All the best
Oliver
Oliver Müller
Stroudco Manager
Firstly, I’m very very sorry, but my Friday afternoon brain made an extremely crucial typo in my overview (which I have now fixed). It should have been (true and false have been reversed from what I originally posted):
For the sake of simplicity I am going to use ‘forwards’ and ‘backwards’ from now on, so that I don’t get them mixed up: Forwards calculated tax rates assume that tax is not included in the price of the item they are applied to, and should be calculated and added to the price of the product when it is purchased. This behaviour corresponds to a setting on the tax rate of included_in_price=false. Backwards calculated tax rates assume that tax is included in the price of the item to which they are applied. Tax is then calculated as a proportion of the existing master price. This behaviour corresponds to a setting on the tax rate of included_in_price=true.
Australian Situation
Following a discussion with @sstead and @maikel yesterday, even though we currently use backwards calculated tax rates on Australian production, we are not really sure that this is actually the preferred way of calculating tax in Australia in the long term. I tend to agree with you @MyriamBoure, that “it is good practice to put the prices in master price always without VAT”. ie. calculated ‘forwards’. We are in the strange situation where we haven’t really had much need to deal with how tax works because it does not apply to the vast majority of food products in Australia.
Kirsten’s Comment
Kirsten’s comment “you don’t put the prices in with vat, you choose whether the product should have tax attached or not, then it will be added or not” is partially true when the tax rate applied is calculated forwards. At the moment, tax will be added to the tax total for the order from the cart page onwards but it will not be visible in the price of the item on the shop front, cart, order summary or invoice. [Feature] Add ‘forward’ calculated tax to price of products + fees aims to fix this.
Kirsten’s comment is not true at all when the tax rate applied is calculated backwards, as the price of the product is assumed to already contain the tax.
Myriam’s Table
I’m really sorry Myriam, but I don’t think I understand your table… Why do the rows split into two when they . For example in the “Included In Master Price = YES” row, what do the two sub-rows under “Displayed -In Shopfront” represent?
I Think We Agree
“So I if (included_in_price=false) means exactly what I said, then that’s our preferred option” - YES, it means exactly what you said
"BUT I think the main difference is that we want the price displayed in the shopfront to include the VAT, which doesn’t seem possible today. " - CORRECT, it is not possible yet: this is what I am proposing as high priority as [Feature] Add ‘forward’ calculated tax to price of products + fees.
“So of course, ideally we would like to give the choice to the order cycle coordinator to choose, for the order cycle, if he wants to display the VAT in shopfront or at checkout” - YES again, as you say, this is nice to have point [Feature] BtoB hubs can opt to not add tax to prices.
Myriam’s Priority List
Looks good to me. I have altered my priority list because it seems as though [Feature] Show a breakdown of aggregate tax for different tax rates ie. Myriam’s point 3 is less urgent for everyone than [Feature] Add ‘forward’ calculated tax to shopfront price of products + fees. ie. Myriam’s point 1.
For 2- How is that shown in price breakdown? I also think that the second option would be best, as it is more transparent, as you say, it is cleaner to look at and it is probably easier to implement.
Nick’s Comment
Thanks for that info @nick.
Note that I added #788 as a VERY HIGH PRIORITY, but I now think this needs to be addressed in another way as per my comment on #788
From Oliver’s response it sounds like the remaining VERY HIGH PRIORITY BugFix I listed above is your main priority, as this will allow you to see a correct total tax for your orders. We can then work on exposing the detail of which individual products have attracted VAT in the invoice as a secondary priority. Does that sound right to you?
Wahou, thank you @oeoeaio, that’s very much clearer now
About the table, I understand what you mean.
You are right that if the VAT is included in Master Price, we could naturally tend to think that it should be displayed at shopfront…
BUT let’s imagine a case where a hub sells products from different farmers. Some farmers have included in the master price of the products in their inventory VAT (backwards calculated tax) and some other have not… What if the hub sells to businesses and want to show the price without VAT in shopfront? That should be possible no?
I know it tends to complicate the calculation, and to be honest my answer would be: let’s make a common rule that
1- the master price is filled in without VAT (we write in the back office "Master price (excl VAT)"
2- then you select the rate (make it a compulsory field)
3- and THEN say if we want the VAT to be displayed in shopfront or at checkout at the order cycle level
I think that would make it easier for everyone
And when you think about the US where all the VAT rates are different from state to state… hum… I really think we should, more generally, ask ourselves if that last option wouldn’t be the preferred one Maybe @MikeiLL or @Angie-US has a comment on that?
Thanks @oeoeaio for making sense of the enterprise fee issue. I agree that resolving this needs to be considered with other issues. In terms of our short term needs we can find ways to work around this so we don’t need any work done on this urgently.
Thanks again
Nick
[quote]So of course, ideally we would like to give the choice to the order cycle coordinator to choose, for the order cycle, if he wants to display the VAT in shopfront or at checkout" - YES again, as you say, this is nice to have point [Feature] BtoB hubs can opt to not add tax to prices.
[/quote]
Because actually, as we implement the possibility to show the price including VAT in shopfront, won’t we anyway HAVE to ask the coordinator (or the distributor?) if the price would be displayed in shopfront or at checkout? Or did you see that as an instance configuration for the whole hubs in one dedicated instance?
Also a comment to @nick issues about fees applied… You said you use, as a workaround, an entreprise fee to charge VAT and display it at shopfront (your master price is without VAT but you also want to show the price in shopfront with VAT, so you add fee called “VAT”), is the case you describe related to that? I was wondering reading your post… do you mean in the Github #788 that you want to apply a fee “VAT” to the products that attract VAT and not apply that fee to the other ones?
Because if it’s that case, I’m not sure that should be the priority, maybe the prioity should be to enable to show prices in shopfront including VAT (depending on the VAT category they are associated with…). So maybe the “high priority” feature sholud be very high
I am really afraid that there is a confusion @oeoeaio with @nick using the entreprise fees to be able show the VAT added on the product in Shopfront… But maybe I misunderstood myself
I was making the assumption that including added tax in the price of the product in the shopfront would be an instance level configuration (because there is usually a convention for this at the country level, except for maybe the USA), and then individual shops can opt to change this if they wish. Realistically, we would probably do both pieces of work at the same time, as the additional work to allow shops to have a different setting from the instance is quite small.
I agree with your comment about @NickWeir’s situation @MyriamBoure, that we need to implement the above (displaying added tax in the price on the shopfront) but this will only partially solve Nick’s problem. The issue remains that he has no way of applying VAT to fees on VATable products, and not to fees on non-VATable products when they come from the same producer. See my comment.
I am thinking more and more that the best resolution to this would be to allow fees to ‘inherit’ their tax category from the products they are applied to, while retaining the ability to set an explicit tax category if that is desired. Does that make sense?
I just wanted to precise, when you say individual shops can opt to change if they wish, that should be done, in the order cycle, at the distributor level (because you could imagine that a hub in an order cycle has one distributor for BtoB and one for BtoC and will want to show the price with VAT in one distributor and without in the other one. And awesome if both piece of work can be done at the same time!
Ok, I think I understand better the UK case.
And I think you’re right with that solution as all the “markup type” fees will have to inherit the VAT category of the product they apply to… unless we specify, in the case of a transport fee for example, that this fee should be, for all products, X tax category.
So yes, I guess that’s a good way to implement that @oeoeaio, very well thought
Now I think you got everything clear in your mind @oeoeaio… thumbs up
Hi @oeoeaio ! I hope you manage to swim in the VAT sea We were discussing yesterday with @Selmo about the French entity, and I was wondering about one thing.
Today the choice of people filling in their master price / variant price including or not VAT is done for the whole instance, in the configuration panel (Tax rates)
But it seems the natural behaviour of hub managers change depending on the nature of the hub:
for a CSA, or buying group, people are used to talk only including VAT, also with the producers, so they naturally tend to fill in the price with VAT included (they don’t even know the price without VAT!)
for a BtoB hub, they will put the price without VAT as they always talk without VAT with their customer.
Is it possible not to have to configure that point for the whole instance, but when someone put a new product, put the price, says which tax category the product is, and check a box “VAT included in price”… that way the system would allow every user to do what is more convenient for them when they upload products, but then will leave the flexibility of hub managers to display prices with or without VAT in the shopfront, independant from the fact that the price have been filled in including VAT or not…
I know I said first that it would be better to say that all prices are without VAT, but it doesn’t seem really adapted to the users’behaviours…
Let me know what you think.
Could you solve this problem by having two Tax Categories? One where the rates are “Included in the price” and one where they are not. Then the hub can select which one applies for each product.
So in your example, you could have the tax categories: “TVA 5,5% (included in price)” and “TVA 5,5% (added to price)”. Does that sound workable?
how important is this issue? is it stopping anyone using ofn right now?
is there a plan for resolving it? I have a vague idea that it might be connected to spree upgrade?
would it be possible for someone to do a quick high level summary of what the current issue is (or point me to github if it’s already there?) so that we can easily assess whether potential users / instances can use as is or are blocked by it. Don’t want to direct anyone straight to this thread as is a bit overwhelming!! . . [scratch that - just found @MyriamBoure’s description - is this still best summary … .]
In brief:
give the choice to user whether to display VAT in the shop or not (in some countries like France, and I think most European countries, the prices need legally to include VAT for BtoC sales, but VAT is usually not displayed in BtoB shops, so if the hub sells to professionals like restaurants, the shop should display prices without VAT. I think it’s similar in other European countries?
and the invoice appearance should be configurable by each instance, as the rules differ from country to country. For example in France we have some specific mentions that need to appear on the invoice, and we need one line for the total VAT amount for each VAT rate.
@Kirsten for France it is definitely something that we will need to fix in the coming weeks and that is preventing users to use OFN. The first users were not subject to VAT and was not issuing invoices so it was ok, but if we want any serious player to use the system we need that to be fixed. We have a big buying group (700 families) who is starting to use OFN and they are subject to VAT so we need to sort that out now… we told them we would have to review that point with them, so they can be part of the defining the VAT process. I hope they can maybe chip in some money to solve that, I’m don’t know yet, we have just started the discussion.
I would add to the summary a third point, which for me is a “technical conflictual point” today:
define the “included in price” process more clearly: for me, by default the tax category setup should not propose to include or not in price, as there is no way then for the user who add a product to know that it is set up that way! It needs to be configurable at the product level (see my proposal). Some users will naturally put a price including tax (like the farmer who sells on the farmers market, he uses only BtoC prices so he will naturally put that on the master price, and we can’t ask him to recalculate the price without VAT), some will not (those selling BtoB, we can’t ask them to put the price with VAT). And Rob’s solution doesn’t work as we need in France to display on the invoice one line per tax category (and it would be very rare to have two lines for VAT 5,5% (included in price) and VAT 5,5% (added to price), the client won’t understand what that means…)
So to sum up, to make the VAT configuration fits any international case, I would suggest this three step process:
1- delete the “included in price” button from tax category setup and add it at the product upload level. With the possibility for the instance to define what display by default (so in a country where all prices are without VAT, by default the case is not selected)
2- give the choice to user whether to display VAT in the shop or not at the OC level (in some countries like France, and I think most European countries, the prices need legally to include VAT for BtoC sales, but VAT is usually not displayed in BtoB shops, so if the hub sells to professionals like restaurants, the shop should display prices without VAT.) The info about "are the price in the shopfront with or without VAT should also be displayed.
3- and the invoice appearance should be configurable by each instance, as the rules differ from country to country. For example in France we have some specific mentions that need to appear on the invoice, and we need one line for the total VAT amount for each VAT rate.
Ok I documented a case to show more precisely the issue here.
@Kirsten is it possible to have an estimate of the dev time required and budget to solve this?
Even with possibly some phasing. Urgent for me is point 2. @CynthiaReynolds I guess this might be as important for Norway than for France (we are in the same case here). I hope we can find some grants soon, or ask some of our first users if they can chip in to develop this feature, so hope we can manage to contribute a bit to the cobudget. But do you think Norway could chip in as well? @NickWeir@lin_d_hop would UK need that and be able to chip in as well? Or is everything working find for you on VAT at the moment?
@MyriamBoure We will chip in as much as we are able to. It will be good to have an estimate to know how to move forward.
But it seems that a significant portion of the tax issues will be fixed with the spree upgrade. Do we have any idea what tax issues will remain outstanding post upgrade? @Kirsten
… and yes, I agree that an estimate of an estimate is the best way to go
We’re happy to do an estimate, but there’s 2 things holding us back on doing this:
We have a very full workload at the moment, standing orders and merging/testing PRs have been taking up the majority of our time, alongside of completing estimates for new work. At present we’re trying to focus on getting version 1 of standing orders out for the community to review, plus there are 2 estimates in our backlog for multilingual switching and also for mangopay payments. Both of those estimates are going to take some time, and the UK have thankfully agreed to pay for those…which leads me to point #2…
We don’t have any cash in the AU core funding bucket anymore to pay for the time it takes for @oeoeaio and @maikel to provide estimates for work The last few major pieces of work we’ve estimated on have been paid for by @serenity and @Kirsten’s enterprise alongside of the UK team and @oeoeaio donating his time as a representative of his food hub. If you look at the multilingual topic, you can see that @maikel has provided an estimate of the time he will need to come up with an actual estimate for the work. We can look at providing one of these for you, so then you can discuss with @CynthiaReynolds and the UK team about whether there is a way to cover this cost to get the estimate.
OK, long response but I think you can see the constraints we have at the moment. Let me know how you’d like us to proceed, we really want to be as responsive as possible but it’s proving a little difficult at the moment
We were discussing yesterday with 
The last few major pieces of work we’ve estimated on have been paid for by 