Second tax no more taken into account

[mannybiker]

Bug

The second tax is not taken into account when adding a line into a supplier invoice that use a tax rate duly configured with second tax.
All was previously working on the same instance of Dolibarr on version 21.0.0

Dolibarr Version

22.0.1

Environment PHP

8.0.30

Environment Database

MySQL 5.7.23-23

Steps to reproduce the behavior and expected behavior

Create a second tax, activate the second tax on your supplier and in the main config of your company.
Add a line into an invoice using a tax rate that use the second tax.

Attached files

No response

[JonathanAlexandro]

I confirm the same bug for the second and third tax, it seems that it takes array 0 by default

[vdegrandpre]

Can you post a screenshot of the steps to reproduce?

[JonathanAlexandro]

Better sending video https://drive.google.com/file/d/1boP0YCqZeVNH-nYudagofzw5Z5hAN-zu/view?usp=vids_web

[pixodeo]

Need to narrow this down before patching. A few specifics would help:

1. Which path triggers the issue: adding a line in supplier-invoice via the UI form, importing it, or via the API? Each goes through a different addline() with different defaults for localtax1/2.

2. The second-tax setup screen at admin/dict.php?id=10 (VAT rates): is the localtax2 column for the rate you picked actually populated (taux2 column in llx_c_tva), or is it set only on llx_c_country_country localtax2_assuj_pct? The supplier-invoice line picks localtax2_tx from a different source than the customer-invoice line in some paths.

3. Can you share what SELECT * FROM llx_facture_fourn_det WHERE rowid = <yourline>; shows for the freshly added line - is localtax2_tx stored as 0 / NULL, or is it stored correctly but not totalised in the PDF?

That tells me whether it is an input-side bug (compute fails) or an output-side bug (compute OK but display drops it). The v21 -> v22 regression you mention narrows the window significantly, so once I know the path I can git log -S for the breaking commit.

[mannybiker]

Hi @pixodeo, sorry for the late reply.

1. I have only used the UI form
2. The second tax setup screen shows that the Second Local Tax (that should correspond to localtax1, localtax2 should be the third tax and taux the first) is populated
3. I attach a screenshot of the line of the invoice, localtax1 it's populated

I think it is an output side bug.

Thank you very much for your support

[pixodeo]

Thanks, that narrows it a lot. I compared 21.0 and 22.0 and the input side is unchanged: the get_localtax() calls in fourn/facture/card.php (buyer = mysoc, seller = the supplier) and the total-table display conditions in the same file are identical between the two branches, which matches your observation that localtax1 is stored correctly on the line.

So this is likely in the shared total/tooltip path rather than the supplier-invoice file itself. To reproduce your exact config I still need a couple of values:

1. On the faulty invoice line, the stored row in llx_facture_fourn_det: localtax1_tx, localtax1_type, total_localtax1, and tva_tx. If total_localtax1 is 0 while localtax1_tx is set, the amount was lost when the total was computed (input/compute side); if total_localtax1 is non-zero but not shown, it is purely display.
2. On your company (mysoc) and on the supplier: localtax1_assuj (0 or 1) for each. The invoice total shows the AmountLT1 line only when the relevant party has localtax1_assuj = 1.
3. The c_tva row you use: taux, localtax1, localtax1_type.

With items 1 and 2 I can tell whether the 15 percent is missing from the total or only from the display, and reproduce it on a 22.0 instance. The screenshots show the field is populated but I cannot read the exact numeric values from them.

[mannybiker]

Thanks to you for your prompt reply.
I write you the values you are not seeing. I hope I didn't misunderstand your request, since I can see these values from the screenshot.

localtax1_tx = -20.0000
localtax1_type = 1
total_localtax1 = -237.000000
tva_tx = 22.0000

localtax1_assuj is 1 for the supplier, llx_mysoc does not exist, I think this is activated into llx_const with MAIN_INFO_LOCALTAX_CALC1=1 and FACTURE_LOCAL_TAX1_OPTION=localtax1on

c_tva row (as in the screenshot) is taux=22, localtax1=-20, localtax1_type=1

I am 99% sure it is a display problem, but I am not sure if there are more implications with this bug on the calculation side.
I am using a very dirty autonomously patched commonobject.class.php file where I have changed this at line 5563:

if (empty($line->subprice_ttc) && $line->qty) {

with this

if ((empty($line->subprice_ttc) or $line->subprice_ttc == 0) && $line->qty) {

to make the calculation display works again, but this is not taking into account probably many other aspects of the second tax functionality and I think I am using this workaround that was intended for recalculating the unit price as a fallback fix in some cases.

Thanks again

[pixodeo]

@mannybiker I built your exact configuration and could not reproduce the missing tax, on 22.0 nor on 23.0.

Setup used: company country IT, MAIN_INFO_LOCALTAX_CALC1=1, FACTURE_LOCAL_TAX1_OPTION=localtax1on, c_tva row taux=22 localtax1=-20 localtax1_type=1, supplier with localtax1_assuj=1. Line of 1185 HT at 22 percent, which reproduces your stored values exactly: localtax1_tx=-20.0000, localtax1_type=1, total_localtax1=-237.000000, tva_tx=22.0000.

On both branches the supplier invoice card shows the local tax line and the correct total (Montant Tax 2 = -237,00, TTC = 1208,70). I tried both ways of adding the line, the object API and the real UI form posted to fourn/facture/card.php, and the header totals in llx_facture_fourn are right in both cases.

Since your stored line values are correct and the same values display fine here, something in your instance differs from a stock 22.0. Two things would help:

1. You mention having patched commonobject.class.php locally. Line 5563 in a clean 22.0 is unrelated code, and subprice_ttc does not exist at all in 21.0 or 22.0, it appears only in 23.0. So your file is modified beyond that one line, or it comes from another version. Could you test on an unmodified 22.0 checkout? If the tax shows up there, the culprit is in the local changes.
2. If it still fails on a clean install, the value of total_localtax1 in llx_facture_fourn for that invoice, not the line, plus the localtax1_assuj of the supplier as stored in llx_societe.

Separately, while tracing this I found a real defect in the same file, unrelated to your symptom: at fourn/facture/card.php:1607 the bulk action that applies one VAT rate to all lines calls get_localtax($vat_rate, 1, $object->thirdparty, $mysoc), with buyer and seller swapped compared to every other call in the file, which uses ($tva_tx, 1, $mysoc, $object->thirdparty). For a non-ES country get_localtax() returns 0 when the seller is not subject, so with a supplier that is not subject to localtax1 the correct call returns 0 while the swapped one returns -20 and applies a tax that should not be there. It is identical since 18.0, so it is not your v21 to v22 regression, and I will handle it separately.