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.
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.
Got finally around to fixing totals, now they are correct.
I’ve made tests using the following scenarios:
Item price: 100 euro
Item discount: 10 euro
Item tax: 19% VAT
subprice: 90 euro
tax amount: 17.10 euro
discount: 10 euro
total: 107.10 euro
subprice: 91.59 euro
tax amount: 17.41 euro
discount: 10 euro
total: 109 euro
Item price: 105 euro
Item quantity: 2
Item discount: 12 + 5% euro
Item tax: 19% VAT
subprice: 175.50 euro
tax amount: 33.34 euro
discount: 34.50 euro
total: 208.84 euro
subprice: 168.84 euro
tax amount: 32.08 euro
discount: 48.98 euro
total 200.92 euro
To me it’s correct, consider merging in 1.6.0 when someone can.
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:
| Identifier | Value |
|—|—|—|
| name: | TaxTestv1.6.0.zip |
| md5: | 0eb0db1a3ba5779a52dcbd99bdfbe5fb |
| sha256: | b0c2ff61f5d5e8b1754e367e3f9b4d1389080f118424220c5895cbecc1a3a12a |
| size: | 13.801 MiB |
| dl file (com): | https://dl.invoiceplane.com/TaxTestv1.6.0.zip |
| txt sums (com): | https://dl.invoiceplane.com/TaxTestv1.6.0.zip.txt |
| dl file (org): | https://dl.invoiceplane.org/TaxTestv1.6.0.zip |
| txt sums (org): | https://dl.invoiceplane.org/TaxTestv1.6.0.zip.txt |
NOTE: This TestBuild is probably just PHP 7.0-7.2 compatible, so pls do not test with PHP 7.3 or PHP 7.4 yet
Pls report after testing if everything was like expected or not.
Have fun testing!
@Luca_Pellizzari
thank for the screenshot, i now understan and thanks to Martin and you for solving this in 1.6.
regards Jan
@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.
great martin thanks for your swift reaction. will also invest some time this week to contribute
@Luca_Pellizzari @bob
thanks for your work and for testing!
Anytime you need a new Test-Build pls tell me. We have optimized some Backend-Tasks to be able to generate Test-Builds much faster and much more frequently to support people which are supporting the project with Test-Builds.
Hi @bob ,
first of all, sorry for the late response, I saw your reply right away, but I was waiting to have some free time to check the numbers since I’m surprisingly busy working from home.
but let’s start from the beginning:
Issue 1:
Here it’s not clear to me what’s the issue, can you be more clear?
I don’t understand what’s that 20% that you’ve highlighted?
It feels like you are relating the item tax to the total tax in a matter of proportions, and if that’s the case, it doesn’t make any sense,
cause IP calculates everything on rows, and then collapses everything in total (what you see in the square below).
The item tax specified there is the total amount going in taxes, as value to show, it shouldn’t be parted by item or such.
Tell me if I got right what you mean.
Issue 2:
Ooops.
I just run on my version and I get the same numbers.
This is a legit problem, we don’t use net discount, so I never realized it.
I have to look at the code to be sure, but I can fix it in no time.
product1: 100
itemTax: 9%
itemDiscount: 10
discountedAmount = 100 - 10 = 90
calculate: 90 + (90 / 100 * 9) = 90 + 8.1 = 98.1
product2: 100
itemTax: 21%
itemDiscount: 50
discountedAmount = 100 - 50 = 50
calculate: 50 + (50 / 100 * 21) = 50 + 10.5 = 60.5
Issue 3:
Percent discount on the invoice was already there before I added the one on the row. This is not a problem due to my code.
The problem you are reporting is present on the bog-standard version as well.
I can fix it as a good measure.
Issue 4:
Here as well I did not touch the discount on totals, but I can fix it to have a well-rounded version.
@ Luca_Pellizzari, thank your efforts are valuable!
So I basically want to addres all these issues because I believe they come from this main problem.
The 20% what you refer to is the discount I want to give after I’ve used 2 products with different item tax.
What net value(priceqty) do you discount? Because we have 2 item taxes 9% and 21%.
So in order to keep this “feature”( and I really mean this is for me very important and valuable feature!)
we should have the possibility to have:
UNIT TAX
product item taxes and product item discounts(% or amount) in product rows, subtotals and in total summary Item Tax named as Invoice Tax(VAT)
OR
INVOICE TAX
product, subtotals and in totals summary discount (% or amount)
then that would make thnings more clear in the functions calculate.
And the Ajax controller can hide/show the inputs accordingly.
Sorry for not addressing the issues separately, because they are just matter of calculations in right order.
I am sure you know your algebra!
NB. below I will post my last finding(this was posted on github) which points out another problem function calculate
Hi, sorry if it took me a while to take a look at the code.
I can’t find the print screen @bob provided last time,
so I had to check based on the numbers I saved last time.
I was skeptical about problems with my branch since I tested through everything,
and taking a second look there is no problem with the calculation.
The number you are seeing are a product of “after-tax” calculation,
while you are expecting “before-tax”.
By default, as talked before with @M4rt1n, the calculation is set to “after-tax”,
to keep a sort of continuity, but 95% of users will use “before tax”, so this confusion can happen.
We can talk to changing that or, let the user choose what’s the default at installation time (I don’t have time to code this at the moment, someone has to take this if we are choosing this route).
The only problem I see as said before is:
-total discount not affecting anything.
-showing items discount in totals to make things more clear
I can fix those.
I’m not sure if this will make it ok for @bob, I think after this is done we have all the options to have discount/tax by item, and by invoice, I don’t think we need to alternate in the calculation.
Tell me if there is something I forgot.
By the way I opened this thread proposing a testing framework, to reduce bugs and frustration while working on IP.
Check it out:
I seemed to have accidentally removed screenshots. so here they are again.
@ Luca you seem to miss the point. I dont say your calculations are incorrect. But there is no such thing as after-tax and before-tax.
Because if you have different taxes in item-tax and give discount in totals column you see there occurs a problem. To keep things simple and same as in real life; there should be only item-tax (with chosen different tax values) OR invoice-tax with chosen tax values.
So the choice must not be before-tax OR after-tax. But item-tax OR invoice-tax. Then you solve the problem for good.
Let me know anything to help you and make this thing work like I suggest. That way it will become a feature which many others dont have.
Forgot to say: The same yields for discount as well.
So when it is clear if we use variable item-tax and discounts or fixed invoice-tax and discounts
then we can have a look at the calculations.
There was some calculation problems I remember, and there always will be if this decision is not made.
I’m sorry but I have difficulties getting to your point of view, explain the points of discussion clearly.
I don’t say your calculations are incorrect | There was some calculation problems I remember, and there always will be if this decision is not made.
If this calculation problem is what I’ve got in my notes, there is no problem, if you remember you should point out what it is clearly (use an example).
But there is no such thing as after-tax and before-tax.
After-tax is plain wrong, what @M4rt1n was intending previously in the discussion was the to offset the discount by an x amount to have the discount cut from the final price, but it is still calculating discount before tax. Both systems are Before tax.
95% of the people of the world will use the regular calculation, I call them Before/After for a practical reason, but in practice, the difference is to calculate discount from the net price or the total.
there should be only item-tax (with chosen different tax values) OR invoice-tax with chosen tax values. So the choice must not be before-tax OR after-tax. But item-tax OR invoice-tax. Then you solve the problem for good.
Wait a second, hold the horses. Those things have nothing to do with each other.
Before/After-tax is the calculation you do to produce the final price based on the tax and discount.
Item/Invoice-tax is a basic tax setting row-by-row or the whole invoice.
These are not interchangeable and not a solution for the problem of the other.
Also, there is to say the importance of an invoice tax is limited since if all the items have same tax you would end up with the same operation. And you can preset a tax value for the article, so you don’t have to input them one-by-one. The invoice tax is there if you have to act on the total. (Or at least in my mind)
Image 1:
Item tax represents the amount of money, out of the total, going into taxes from the item:
27,00 = 8,10 + 18.90
It’s correctly called Item Tax, maybe could be called Item Tax Total??
Invoice tax it’s an additional tax you apply on the subtotal, so if you were to apply 9% on this 180 invoice it would be 16.20.
So they are named correctly, and there is a chance you are gonna be using both, so why rename/hide them?
Image 2:
Here is probably the calculation error you were pointing out last time, you are using the “After tax” formula set by default,
so it’s calculated like this:
109 - 10 = (100 - x) + ((100 - x) / 100 * 9)
109 - 10 = 90.82 + (90.82 / 100 * 9)
99 = 90.82 + 8.17
and
121 - 50 = (100 - x) + ((100 - x) / 100 * 21)
121 - 50 = 58.67 + (58.67 / 100 * 21)
71 = 58.67 + 12.32
It’s correct if you want to switch to the standard use the setting.
Otherwise, we should discuss what should be the default.
Image 3:
That’s a problem.
Image 4:
That’s a problem.
Image 6:
Same image as 4.
Image 7:
Same image as 3.
Image 8:
Subtotal is correnct, we should not rename any of the others.
So in conclusion, as I said, fix the totals displaying more info, to be clearer.
Tell me if you object.
