-
-
Notifications
You must be signed in to change notification settings - Fork 784
[13.0][FIX] l10n_es: assure move lines and repartition lines have correct tags #3146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 13.0
Are you sure you want to change the base?
Conversation
|
Is it so important as tags are not used by OCA/l10n-spain and as so you can pass |
|
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 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 |
|
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). |
bbf2b32 to
bbc2cb1
Compare
|
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: |
0226dab to
0c38532
Compare
0c38532 to
3fd9e4e
Compare
Long time ago I wanted to make this kind of fix, but I forgot. Now it is time!
- Without this fix:

- With this fix:
