Two issues solved in 1 commit; as their solutions depend on one another.
** ISSUE 1 **
To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.
=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.
This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.
** ISSUE 2 **
To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice
=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !
This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).
The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.
This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.
======
Forward-port note:
In 16.2, https://github.com/odoo/odoo/commit/84d7aab94e2984a81923f0546e24caf54cd53033 actually wrongly inverted the sign of the Mexican withholding tag in repartition lines. Those taxes are negative, so a tag needing to get the retention amount in positive must be negative itself. The bugs fixed in this commit shadowed the problem, and this fix reveals it. A fix of the tags's signs was added into this forward-port.
OPW 3255511
closesodoo/odoo#123187
X-original-commit: 688ab4d6688ccd2377ea9702c00b1ec16f99527a
Related: odoo/enterprise#41748
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
oco-odoo
0aeeb5374e