-
-
Notifications
You must be signed in to change notification settings - Fork 784
Description
So, in the process of fixing the migration of the dutch tax tags (account.account.tag), I have come across multiple problems. One of them, is that because of the new accounting structure in 13.0, tags get copied to the account.tax.repartition.line's. However, these lines should have one specific tag for each line.
EDIT: And that makes sense, more or less, because there isn't enough information in the account.acount.tag model to determine whether it was meant to be for tax lines or non-tax lines. So the migration script of account should not be able to apply the right tag to the right repartition line, so it just copies all of them to all lines, as a best effort I guess.
#3146 fixes that same problem for their localization (l10n_es). However, because it seems to be problem that isn't specific to any localization, you could say that each localization module needs to fix this for themselves. However, I think this is a bad idea, because the problem lies in the way the structure of the account module changes from 12.0->13.0.
However, because each repartition line requires one of the tags, not all of them (right? correct me if I'm wrong), you need to know which tag is about VAT, and which tag is about turnover. I'm not familiar with other countries tax systems, so I can't really say if VAT and turnover tags are the 2 only tags that are relevant for everybody. Nevertheless, I think something can be done for the account migration that benefits most localizations.
I think determining what tags belong to what repartition lines is information that the general account module does not have. I'd say it is up to the localization module (l10n_*) to determine which tags belong to which lines.
For l10n_nl, I've made the following queries like this:
openupgrade.logged_query(env.cr, """
DELETE FROM account_account_tag_account_move_line_rel r
WHERE
account_account_tag_id IN (
SELECT res_id FROM ir_model_data
WHERE
model = 'account.account.tag' AND
module = 'l10n_nl' AND
name IN ('""" + "','".join(tax_tag_xmlids) + """')
) AND
account_move_line_id IN (
SELECT id FROM account_move_line
WHERE tax_base_amount = 0
)
""")
openupgrade.logged_query(env.cr, """
DELETE FROM account_account_tag_account_move_line_rel r
WHERE
account_account_tag_id IN (
SELECT res_id FROM ir_model_data
WHERE
model = 'account.account.tag' AND
module = 'l10n_nl' AND
name IN ('""" + "','".join(base_tag_xmlids) + """')
) AND
account_move_line_id IN (
SELECT id FROM account_move_line
WHERE tax_base_amount <> 0
)
""")
In here, I've compiled the xmlid's of the VAT tags in tax_tag_xmlids and base_tag_xmlids are the non-VAT tags. This seems to work for l10n_nl, and if there are other localizations which can resolve their problem in the same manner, I'd say maybe we should put this in a helper function of the account module. That way, it becomes really easy for other localizations to fix the same problem on their side.
What do you guys think?