[18.0][MIG] l10n_es_vat_prorate: Migration to 18.0 #4251
Conversation
The VAT prorate tax line should contain the analytic info from the expense line. With this commit, we put such information, and make sure that is synchronized on any change. TT41832
When doing a refund, the account of the prorate line is changed to the tax repartition line default one (472). That's because there's some code on the method `_reverse_move_vals` that is checking `tax_repartition_line_id` value in the returned dictionary for ignoring the copied value. See https://github.com/odoo/odoo/blob/82b1e68b60eb14896666adfd3ad1f753e944d393/addons/account/models/account_move.py#L2515-L2533 What we do for tricking it (as it's atomic and can't be intercepted in other part) is: - When copying values, we move the `tax_repartition_line_id` into another field name. - Thus, `_reverse_move_vals` is not modifying the account. - Immediately after returning from `_reverse_move_vals`, we restored the field value. TT44656
The dynamic lines management has totally changed in this version, so the code has been rewritten mostly from scratch, but now is cleaner thanks to the avoid of a lot of hooks. Some JSON from tests were not correct in previous version due to rounding, and now they are OK: 10 / 1.2 = 8.3333333, which is 8.33, not 8.34. TT43236
Currently translated at 100.0% (24 of 24 strings) Translation: l10n-spain-16.0/l10n-spain-16.0-l10n_es_vat_prorate Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-16-0/l10n-spain-16-0-l10n_es_vat_prorate/es/
Currently translated at 100.0% (24 of 24 strings) Translation: l10n-spain-16.0/l10n-spain-16.0-l10n_es_vat_prorate Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-16-0/l10n-spain-16-0-l10n_es_vat_prorate/ca/
BetoRaja
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
2 times, most recently
from
c965323 to
3173fc7
Compare
@Jaimermaccione Thanks for your feedback! The requested changes have been implemented. Prorate is now applied and updated in draft mode as in previous versions (≤ Odoo 17). We’ve tested it thoroughly — the deductible and non-deductible VAT amounts are recalculated correctly when editing draft invoices. |
There was a problem hiding this comment.
Hi @BetoRaja
I've tested the new changes and found some unexpected behavior when resetting the invoice to draft:
-
The prorated breakdown is correct in "Draft" status.
-
If I move the invoice to "Posted", the amount remains correct.
-
When I reset the invoice to Draft, the amount of deductible prorated VAT increases to match 100% of the tax in the journal entries (see attached screenshot), while still keeping the non-deductible portion recorded as well.
At this point, if I validate the invoice again, the amount due includes:
- Product
- 100% of the tax amount (VAT in this case)
- The portion of the tax not subject to prorated deduction (VAT in this case)
If I change the invoice date and there is a different prorated percentage configured for that date, saving the record triggers a full reset — everything is recalculated and corrected properly. However, once I validate the invoice and then set it back to draft, the issue appears again.
Thanks
| moves._apply_vat_prorate() | ||
| return moves | ||
|
|
||
| def write(self, vals): |
There was a problem hiding this comment.
Be careful with canceling the call to the super.
On the other hand, be careful with the application of the prorated rate, as there will be cases that are not covered by this method.
There was a problem hiding this comment.
@BetoRaja feedback?
|
A tener en cuenta #4288, especialmente https://github.com/OCA/l10n-spain/pull/4288/files#diff-b98482b0eba53728bc7ae07431251e2bd1d61f5fc7001e15a80316693efe1b74R21 |
@pedrobaeza Fixes #4288 y http://github.com/OCA/l10n-spain/pull/4279 revisados y tenidos en cuenta para nuestra migración,Muchas gracias. |
When you publish a vendor bill with prorate taxes, and then reset it to draft and change amounts, there's a chance that Odoo rewrites the move lines switching the prorated expense and the tax, causing that the new tax line, being the old expense one, have the flag `vat_prorate` set, and thus not being included in AEAT reports. As it seems we can't do anything for assuring the same move lines processing order upstream, what we do is to force in all the entries the False value, and then only putting to True when building the VAT prorate expense line. TT57089
- account.move~with_special_vat_prorate can't depend on company prorate modifications, or this will trigger the line check computation, marking/unmarking all the existing invoices. - Remove double assignation vat_prorate = False. - Terms homogenized. - Make prorate tree editable again. - Better text for invoice line column. - Translations.
BetoRaja
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
6 times, most recently
from
37c7585 to
8f8c0bc
Compare
There was a problem hiding this comment.
Tested the case reported in the latest revision by @javierizaca, specifically the behavior when resetting the invoice to Draft after being Posted.
All functionality works as expected:
- The prorated VAT calculation behaves correctly.
- Reverting to draft and revalidating the invoice maintains the correct deductible and non-deductible amounts.
- Changing the invoice date with different prorated percentages triggers accurate recalculation.
Tested on Runboat. Everything looks good.
LGTM!
Thanks!
BetoRaja
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
7 times, most recently
from
317393b to
7994a41
Compare
BetoRaja
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
from
7994a41 to
b2f4506
Compare
We migrated the VAT prorate module from Odoo 17 to 18, adapting the old _compute_all_tax logic to the new flow using create, write, and button_draft.
We generate prorate journal lines with display_type='tax' to keep them out of the invoice lines and avoid UI clutter.
@HaraldPanten @Jaimermaccione @ValentinVinagre
[T-8592]