[18.0][MIG] l10n_es_vat_prorate #4442
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.
There was a problem hiding this comment.
Revisión funcional hecha. Buen trabajo
Dejo un vídeo de la prueba funcional
https://www.loom.com/share/a8fd70cb465d40a689dbdf4ec094c9fe
Muchas gracias @Andrii9090
Andrii9090
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
from
11f1408 to
fc14cc2
Compare
|
This PR has the |
1 similar comment
|
This PR has the |
|
Hola a todos: Estuvimos hablando con @ValentinVinagre y con @HaraldPanten y estuvimos de acuerdo en terminar en este PR que se puede hacer merge. Agregamos a los autores del anterior PR como co-autores en un win2win @Tisho99 ping. Por favor, ¿Le podéis dar una revisión para dejarlo terminado? Es una prioridad por lo que tenemos tiempo. Muchas gracias |
|
Hola @Anxo82 creo que el mensaje de arriba es para ti. Por parte de Sygel, Anxo es quien estuvo con la migración, aunque si el no puede revisarlo no creo que haya problema en que lo revise otro PD: Gracias por el trabajo realizado y por indicar la co-autoría |
|
Hola a todos: Muchas gracias. |
There was a problem hiding this comment.
@Andrii9090 gracias por el esfuerzo con esta migración.
He revisado funcionalmente y he encontrado algunos bugs.
- Hay un error con las rectificativas cuando hay un cambio de periodo de prorrata entre la factura origen y la rectificativa.
- Hay un error con las cuentas que selecciona al aplicar la prorrata cuando se tienen diferentes cuentas.
He grabado un vídeo para mostrartelo visualmente:
Andrii9090
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
from
fc14cc2 to
a514b3d
Compare
|
¡@EmilioPascual gracias por revisar! He grabado una prueba de los cambios |
|
Siguen fallando algunas cosillas:
He grabado un vídeo con estos casos de uso: |
There was a problem hiding this comment.
He vuelto a probar mezclando, como comenta Emilio líneas con diferentes impuestos, cuentas contables y cuentas analíticas. He pasado un video interno porque he grabado 16 vs 18 en la instancia del cliente.
El comportamiento efectivamente ha cambiado en algún momento y ahora es no esperado.
Avísame para volver a probar por favor.
Gracias
|
Coincido con las pruebas que hizo Emilio y los comentarios de Rafa; el resultado no es el esperado. Ya vais informando sobre los avances. Gracias. |
Andrii9090
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
2 times, most recently
from
63becec to
222ffe7
Compare
|
Hola! He modificado el código contando con las revisiones de @rafaelbn y @EmilioPascual |
|
This PR has the |
| prorate_id = fields.Many2one( | ||
| string="Prorate", |
There was a problem hiding this comment.
¿en la v18, cuando un campo acaba en _id Odoo no te lo incluye en el string por defecto?
Al menos en versiones anteriores, si quitas string="Prorate", el campo pasaría a llamarse Prorate id...
There was a problem hiding this comment.
El campo tiene label Prorate , creo que han cambiado en v18
| string="With VAT Prorate", | ||
| help="The line will create a vat prorate", |
There was a problem hiding this comment.
IMHO these lines should be restored.
It was better before than now. Besides, changing translations means more work for the translations team, which can be avoided if they are kept.
| readonly=False, | ||
| ) | ||
|
|
||
| prorate_line_ids = fields.Many2many( |
There was a problem hiding this comment.
question: me pregunto igual que antes... ¿El campo no se llamará Prorate line ids? ¿No sería mejor añadirle un string?
Andrii9090
force-pushed
the
18.0-mig-l10n_es_vat_prorate
branch
from
222ffe7 to
2426fdb
Compare
17 participants
Migración a 18.
Hay otro PR 4251 de la migración de este modulo y nosotros empezamos a trabajar con el código de este PR (en versión hasta commit) para ayudar a terminar la migración, pero al al final hemos ido por diferentes caminos y por eso abro este PR.
La prorrata se calcula en los métodos create y write de
account.moveUn vídeo corto con la prueba funcional desde runbot
https://www.loom.com/share/65d61eb381a54ef69093fea0284f19db?sid=fb1fe2b6-ec55-4058-b2a4-a852de28ada4
@moduon MT-11110