OpenUpgrade
OpenUpgrade copied to clipboard
[13.0][FIX] l10n_es: assure move lines and repartition lines have correct tags
Long time ago I wanted to make this kind of fix, but I forgot. Now it is time!
- Without this fix:

- With this fix:

Is it so important as tags are not used by OCA/l10n-spain and as so you can pass account_chart_update later?
Yes, it is important to me if I want to directly run a v14 migration consecutively after v13 migration and don't be bothered about running account_chart_update later or between the process.
But, hey, I think the question here is not about what I am doing or not, or what I like or not, I think it's just something simple: someone new into this that does a migration with OU to v13, what they would expect? Should/must they know about account_chart_update o related? or simply should they expect all tags being correctly in their place? :)
The question is that tags are useless for most users, as they are not used in AEAT models. For which goal are you using them?
@pedrobaeza but if this fix ensures proper migration of the tags, that's better. And imagine the case of someone using Enterprise that wants to use OU for any reason (for example, to have move control on the migration process).
Nice, I've made a similar fix for l10n_nl, will be PR-ing soon.
@pedrobaeza The Dutch VAT reports are relying fully on these tags. Is it different in Spain?
Yes, totally. In OCA/l10n-spain we are relying since a lot on dynamic mapping configuration from tax templates for getting the scope of each tax report field, and populating them on the tax report computation. Advantages: Dynamic definition through time without relying on previous tax configuration. Disadvantage: a computation needs to be done, but it's quick and follow the real process (to make the tax declaration as a document). See for example what not having this approach has provoked for enterprise reports using the tags approach in a recent fiscal change:
https://github.com/odoo/odoo/pull/78650 https://github.com/odoo/odoo/pull/78987