[19.0][MIG] l10n_es_vat_prorate: Migration to 19.0 - #4907
Open
isturiz wants to merge 47 commits into
Open
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/
Currently translated at 100.0% (36 of 36 strings) Translation: l10n-spain-17.0/l10n-spain-17.0-l10n_es_vat_prorate Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-17-0/l10n-spain-17-0-l10n_es_vat_prorate/es/
Currently translated at 100.0% (36 of 36 strings) Translation: l10n-spain-17.0/l10n-spain-17.0-l10n_es_vat_prorate Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-17-0/l10n-spain-17-0-l10n_es_vat_prorate/ca/
…taxes Odoo screwed up the tax XML-IDs in the middle of the 17.0 lifecycle, introducing an unfolding of the exempt taxes, using existing ones that belongs to the sales intra and extra community taxes. After that, they have renamed the XML-IDs of both taxes to new ones. We need to handle this in 2 ways: - Detect and correct existing installations previous to this taxpocalypse for renaming them. - Change the reference in all places to the new XML-IDs. Besides, we have to add the unfolded exempt taxes in the reports.
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.
Before fix you cannot duplicate vendor bill, a raise happened "You can't delete a posted journal item. Don’t play games with your accounting records; reset the journal entry to draft before deleting it." This happened because the field `prorate_line_ids` was copied to new bill. In addition, copy to false is added to fields from move and move line to run always the compute methods when duplicate or refund MT-12497 @moduon
…h l10n_es_vat_prorate The tax fee amount is not always the same as the deductible amount when your company is in the prorate regime. AEAT splits both amounts in the corresponding columns, and we previously were setting the same value on both. After this commit, there's a separated field for the deductible amount, and data is computed through the standard methods from `l10n_es_aeat`, so when plugging `l10n_es_vat_prorate`, the deductible amount is automatically changed by this module. The refactoring needed for this to happen has been the minimum one for minimizing the possible impacts, only affecting in the creation in memory of one extra dictionary per vat book tax line, which is acceptable. A deeper refactorization can rename fields of "l10n.es.vat.book.line.tax" to match the returned values of the standard methods for not having double dictionaries. The new field is shown also on the UI, used for the XLS export, and a migration script fill it with the same value as the amount for the existing records. A change of the map lines mapping has also been needed: tax_account_id has been replaced by tax_excluded_account_id, reversing their usage: now it excludes the account set instead of including, as if not, we were filtering out the lines of the prorates. The renaming is on purpose to warn people extending this module when they have used the previous field, as updating this, they will have an error. The non deductible VAT has been also adjusted according what we have checked in the AEAT: the fee is reported, but the deductible amount is 0.
…Journal Entry creation Before the fix, it was not possible to add a new line when creating Journal Entries. After the fix — by removing the decoration-danger attribute from the line_ids field in the account.view_move_form view (which previously hid lines when both debit and credit were 0) — it is now possible to add new Journal Item lines again, restoring the standard workflow.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: l10n-spain-18.0/l10n-spain-18.0-l10n_es_vat_prorate Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-18-0/l10n-spain-18-0-l10n_es_vat_prorate/
…nd goods properly by default For simplified invoices, the taxes breakdown is not required, but right now if you make a PoS order mixing goods and services, the dictionary structure is a mix between breakdown and not breakdown. Let's fix it handling properly the no breakdown, and only performing it when needed. But this has led to change the base module, so not doing breakdown on other ocassions that previously were done. TT60718 s
Member
|
Please check the CIs. |
Author
The CIs failing is about the test that depends on the l10n_es_vat_book module. I checked that existing PR about the module: #4884 However, is this correct? I can add a commit with a temporal reference, although it is not in the module manifest as a dependency. |
Member
|
Aquí podemos hablar en español, que no me he dado cuenta. Esperamos a que se fusione el del libro de IVA. /ocabot migration l10n_es_vat_prorate |
Author
|
Vale, quedo atento. |
2 tasks
Contributor
|
Siempre puedes añadir referencias a otros PR para pasar el CI https://github.com/OCA/maintainer-tools/wiki/Use-temporary-reference%28s%29-to-another-pull-request%28s%29 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Migration from 18 to 19.