I suggest to not push such a heavy change into a patch version like 1.5.10.
As I said, the change was planned for 1.6 and should be implemented to let the user choose how the calculation should be done, because there simply is no single correct calculation.
The defaults were always the standards used by the US market because most of the users come them the US.
1 Like
We can make the change behind a setting and not change the default.
If I am not wrong the US, taxes on the net amount, so we would have to change things later on.
I agree with @Kovah in that once we decide how this should work, it should be planned for a future release. We don’t want to get in the habit of rushing features into a release and not have it fully vetted or tested. @Luca_Pellizzari, do you have access to https://development.invoiceplane.com? If so, add this request there so we can properly plan it.
I know you want to be steady, but think that every discounted price right now comes out wrong, if you don’t handle manually (all of our invoices are discounted).
I can use my own fork for now, but let’s not have this going for months, ok?
Hi,
My understanding is that’s only a way to present things : looking back at the 2 examples given, I could say that if I look at it in a customer point of view (in net prices including taxes), I get a 11.9€ discount in the first case, and I get 10€ discount in the second case.
And looking at it in a professional manner I get 10€ discount in the first case (and a professional is not interested in the second case).
So at the end of the day it all depends on who your are sending invoices to. My 200+ clients using an ERP (mostly small businesses) are mainly dealing with professionals so they are happy with a discount before taxes. For the businesses dealing with end customers, most of them are also happy with discounts before taxes as this is the way it is done in France, even in big shops (like DIY shops). However, some customers in a highly competitive area, wanted to make it clear to their customers, what was the final discount (including taxes) for the customer. Also they wanted to be able to type a round net discount (e.g. 10€) so the customer could see the discount clearly.
However, in France (and I suspect it’s the same in any other country), you can not apply a discount on the amount including the taxes (as the taxes go to the government). So you need to apply the discount before tax, and in that case, recalculate the amount to make sure you get the result you want (a 10€ net discount) … but again it is not allowed to discount taxes.
So the example is (100-8.4) + ((100-8.4)/100 *19) = 109€ (compare to 119€ catalogue price)
.In this example, the IP user would type in 10€ and then IP would calculate the discount before tax 100-(100-(10/1.19)) = 8.403…
On the invoice, you could show a 10€ discount after taxes (or more likely on the quote to get the customer interested), but you will have to word it properly to avoid confusing an accountant who won’t be happy with a discount after taxes. If you display on the invoice (which I never did, I always displayed only the discount before taxes on the quote), you might want to display both discounts (before taxes and after taxes), but then again, that might confusing as this can be taken that you are applying both discounts.
To sum up, in France (and I assume in most-all ?- countries) you can not apply a discount after taxes, but you may type in a round amount of net discount that will recalculated as discount before taxes. Then you can create a nice quote with net prices and a tag like “you save X€” (where X is the net discount that has been typed in -10€ in our example), but as an accountant point of view the discount is 8.403… and that should be displayed on the invoice (then again you could have the same tag “you save X€” with the net price as long as you don’t write discount).
Sorry for the long post, but this is quite important to get it right. Still I don’t pretend that this could satisfy everybody, as the one thing I know for sure is that every body need is different (but then again, for the most part it is identical).
Let’s set aside the habits or the laws in the various countries,
what you say has sense, and I’ve done it before.
To discount a taxed price until it matches a number that sounds good in the customers ears,
that’s ok. I would not have in the ERP, but that’s ok.
What you market to your customer and what you save in your database is kind of different,
and if you really care that when you say “-10 euros”, you can make that happen with math.
It’s important that an invoice solution has right number in the DB.
Adding discounts after taxes is wrong because the tax amount in the price does not match the net amount.
So you are giving more to taxes in the price, unless you reverse the math and keep the difference, while sorting your taxes.
But the data in your database are off, then. It’s making your life more difficult.
Am I making myself clear?
I saw your PR, and it’s frankly how I would have done it. We can recover it, tweak it and test it.
It matters that we all are on the same page.
1 Like
- you are wrong here.
If you calculate your discount AFTER taxes they are paying 91.60€ for your product. and 17.40€ (19% of 91.60€) taxes. Together its the 109€ you already mentioned. - This is already planned for v1.6.0 (LINK, LINK2)
There will be an official answer from @Severenth @UnderDog and me in the next coming days.
1 Like
No brother, you are simply redistributing the proportion of what is item price and what is tax, but this will give you nonsense numbers.
We are not doing math for number’s sake, the numbers actually stand for something.
If you take the example from before:
-price: 100 euro
-discount: 10 euro discount
-taxes: 19% taxes
You’ll never be able to obtain the numbers you gave from the actual data:
In my price book, this item minus the discount should be 90 (100-10), but in the result I get 91,60 euro. What is 91,60? What does it stand for?
In my price book, this item should be sold for 100, but I’m selling it for 101,60 if I remove the discount… What is 101,60?
The result is different from the sum of the parts.
In the current Italian e-invoice XML, I have to specify the tax base, and if I put the number that IP gives me it will be wrong.
For reasons like this, like @ComputingFroggy said, in most countries, you cannot discount after-tax, period.
If you do solve both ways, it’s clear that with this system you are taxing the wrong amount, look:
Step 1:
Before tax: ((100 - 10) + ((100 - 10) / 100 * 19)) = 107.1 euro
After tax: ((100 + (100 / 100 * 19)) - 10) = 109 euro
Step 2:
Before tax: (90 + (90 / 100 * 19)) = 107.1 euro
After tax: (90 + (100 / 100 * 19)) = 109 euro
The tax bases are both 90, but you are taxing in the second case the full amount and not the discounted amount.
The difference between the two prices is the 1.9 euro in excess you are adding, look:
Difference: ((100 - 90) / 100 * 19) = 1.9 euro
1 Like
This is the reason why this change should be made as soon as possible,
cause aside DE and how is done there, for the rest of us, the calculation is literally wrong.
In the same breath, the different interpretations of how the taxes and discounts are applied is a good motivation of not rushing into the completion of the process while it is not properly speced out.
Since this will be new functionality, I would rather all possible scenarios be specified and build, instead of catering for one market and re-coding later on, which become expensive (in terms of time, complexity, stability etc).
I want to step aside from my opinion on discounts, taxes, etc. and purely looking at the code.
Version 1.5.10 is purely meant as a patch version. We want to improve:
- compatibility with PHP 7.3
- bootstrap CSS version
- numerous javascript dependencies (package.json)
After we get this version released we can focus on other things and yes, we’ll figure out this topic, but let’s not do that in 1.5.10
1 Like
You are wrong with this statement.
Taxes in the secon example are 17.40€ not 19.00€! So we are not taxing the full amount.
Pls understand this. This is how it works in germany and I can say that its not working the same way in other countrys.
(I marked what you did wrong)
Here is how “After Tax” is done right:
After tax: (91.60 + (91.60 / 100 * 19)) = 109.004 euro
But as 91.60 stands for 91.5966386555€ (as it is rounded) so its basically :
After tax: (91.5966386555 + (91.5966386555 / 100 * 19)) = 109.00 euro
Now you also know what the “91.60” stands for.
To leave a few words about it:
If you give a discount, who are you giving that discount for? For you or for your client?
Most probably for your client. So if you give a discount of 10€ the client in the end should pay exactly 10€ less then before, right?
So in the end he should pay 109.00€ if the product costs 119.00€ (with 10€ discount).
If you calculate discount after taxes you will make more profit.
I understand that this is not the case in other countrys. But this feature will not make it into IP before v1.6.0. Other countrys are working differently and InvoicePlane should aim for statisfying the international market. There are open Feature Requests and they will be implemented.
To make this happen we first have to get IP back on track. IPv1.5.10 is a big step for this, as its the first release since abount 2 years which will make sure IP is up to date. IPv1.5.XX will not include any new features or any new functions, its a maintain release.
We are not getting anywhere with this discussion, anyway like it is right now most people cannot use it without jumping the discount system all together, it’s fine to do it at v1.6.0, leaving v1.5.9 as a fixup, in the meantime I’ll fork from our end, until fixed.
Since it’s America the first user base, and America uses before tax by default, I would consider this a priority.
I also ask myself how the program does/will do accounting, since the subprice from the article side and the calculation side are different? Offsetting all the calculations?
Back on the discussion:
I think I know what you are doing @Martin_Anonym, I think I got it:
This is the problem! You are definitely not doing after-tax! you are doing before-tax equating to the discounted amount.
Look:
final_price_not_discounted - discount = before_tax(x) --> x is the amount needed to arrive to that price, but you are using before-tax formula!
item price: 100
discount: 10
tax: 19%
final_price - discount = (price - x) + ((price - x) / 100 * tax_perc)
119 - 10 = (100 - x) + ((100 - x) / 100 * 19)
we set (100 - x) = k
109 = k + (k / 100 * 19)
109 = 119/100 k
k = (100 * 109)/119
bring back (100 - x)
100 - x = (100 * 109)/119
x = 1000/119
x = 8.4 euro
this is the x amount we need to offset the calculation to get 10 euro discount, so:
109 = (100 - 8.4) + ((100 - 8.4) / 100 * 19)
109 = 91.60 + 17.40
and those are the numbers you are getting…
So @Martin_Anonym you didn’t understand the point of the conversation, you are still using before-tax formula but you are offsetting an amount to get the 10 euros from the final price. This is not like using after-tax discount. IP is using after-tax discount. And this is wrong.
And this was pointed out from many users:
https://community.invoiceplane.com/t/topic/6056/3
IP is not using another method, is doing the calculation wrong.
This should be on top of our priority. Users might not be aware.
1 Like
I do not want to interfere too much, but . . .
say Netprice is 100
say Discount is 10
say VAT is 19%
Discount can be given on Net-Price or on Gross-Price
Netprice-Discount is easy - Calculation gros-price -> (100 - 10) * 1.19 = 107,1 instead of 119
Grossprice-Discount Gross-price without discount 119 - with discount 109 meaning
Netprice = 109/1.19 = 91,60 and VAT is 110 - 91.60 = 17.40
Using this simple arithmetic and the choice for NET-Discount or GROSS-Discount should do it.
If a percentage is used, then the arithmetic must first calculate the sum with which the grosprice is reduced in order to recalculate the netprice.
I have been dealing with POS-Systems for years and with some ERPs, I have checked this with several tax consultants in NL, D and A.
Feel free to do the same with any tax consultant where ever in the world.
Regards,
Jan
Hi @janvl,
let me be clear, the problem here is not Net price or Gross price, we can easily make a setting switching between the two.
The problem is that right now IP is using none of 'em. It is just subtracting discounts after tax.
We should first fix this problem, and then we can discuss, what option to give the user, what should be the default, how, where, when…
To make this clear, I invite you to fill an invoice with your data, and see this yourself:
say Net-price is 100
say Discount is 10
say VAT is 19%
As you said:
Netprice-Discount (or before-tax) gets you: 90 + 17.1 = 107.1 euro
As you said:
Gross-price-Discount (or equating-from-the-final-price) gets you: 91.60 + 17.40 = 109 euro
But now get IP, and make this invoice:
it gets you 90 + 19 = 109
and this is clearly wrong, you are getting the wrong tax amount for that net.
After merging the IT version with 1.5.10, I did this PR to add percent discounts on items and fix the total calculation for the time being.
It applies the discount on the net amount, as it’s accustom in Italy, we can add a setting to switch between the two calculations in IP international 1.6.0.
Eventually, we will merge and rectify it with 1.6.0.
Thanks for the PR, but actually the InvoicePlane-it is not the official Repository, so if you want this to be included in official Releases you should open a PR to the official InvoicePlane Repo into the branch v1.6.0
Thanks.
Of course, InvoicePlane-it is the Italian fork.
What I mean is that we are prob. going to anticipate these fixes into 1.5.10, and they are going to be used and tested.
So whenever works for 1.6.0 will start, it can be a base for 1.6.0 for the international version. Just that.
I can make a second PR for the 1.6.0 branch myself when I finish on the other end.
1 Like