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.
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.
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:
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).
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!
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.
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.
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
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.
I’ve merged master on branch v1.6.0, and added both before and after-tax calculation based on a switch in settings. I’ve noticed there was a switch already there called ‘default_invoice_tax_rate_placement’ connected apparently to nothing, and I’ve used it for this.
To a first comparison, the numbers should be ok for both cases, we need to check the total invoice numbers, that are still wrong. Let’s go by steps. I don’t want to push too much stuff all at once.
I’ll make another commit fixing the total.
In the meantime,
lets’ all check the numbers together and make sure we all agree they are correct.
I’ve made a couple of invoices to check the calculation, but I don’t use the “after-tax” day-by-day, so please do a test and check.
Befor merging I would like to publish a Test-Release for v1.6.0 made of your Fork (LINK) to give the community the opportunity to test it and to give some feedback.
Therefor I just build a “TaxTestv1.6.0” release which is just for testing purposes and should not be installed on any productive System, but on Testing/Dev System.
I have not tested it yet but will do so soon.
Here is the Test-Release:
@bob thanks for your valuable feedback.
Pls have a look here: LINK
As this is the official Pull Request and may contribute your Code-Change here.
I also added a comment to the PR and let @Luca_Pellizzari know that there are some issues/questions and may he clarifies how this exactly should work, or if this behaviour is a bug or a feature.
