1. Mailing Lists
  2. Contributors
  3. Re: Question about migration of account.tax and related entity (in my case on l10n_be)

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Module name, name collision

OCA - RFQ - Improving the Documentation of Open Upgrade

Avatar

Re: Question about migration of account.tax and related entity (in my case on l10n_be)

by
Therp, Tom Blauwendraat
- 22/11/2022 15:42:02

Hi Remy,

We had the same problem in the migration of a few of our Dutch customers. My colleague Danny who is not on this list (yet, but he will sign up) worked on that and says the following:

-----------------------------------------

Dear Remy,

We have had a very similar thing happen in our migration from 10 to 14, between 12 and 13 yes. Although some of the things you mentioned we did not encounter, I had no problem with account.account.tag's being deleted for example.

Part of the problem with the tags is this, in 13.0 a new model, called account.tax.report.line has been introduced. Now in 13, some tags are defined in xml files as account.tax.report.line instead of account.account.tag (as they were before). The report line model is responsible for creating new account.account.tag records in python, prefixed with a minus and plus sign.

So you are dealing with new account.account.tag records, while all your account move lines and other stuff is still linked to the old account.account.tag records. There is no direct link to old and new tag records, so you kind of have to 'know' which old account.account.tag records are replaced with which new account.tax.report.line records, and then you could map them.

I took the route of remapping the old tags to the new tags, and that work can be viewed here: https://github.com/OCA/OpenUpgrade/blob/13.0/addons/l10n_nl/migrations/13.0.3.0/post-migration.py
I've moved some of the code into helper functions: https://github.com/OCA/openupgradelib/blob/master/openupgradelib/openupgrade_130.py
So I hope it will be easy enough to use those helper functions in your own script. Or maybe the convert_old_tax_tags_into_new_report_line_tags function of l10n_nl could even be completely reused? This is the function that does the mapping.

Best regards,

Danny de Jong

------------------

With the following PS: ---> I noticed that the "l10n_be" migration scripts are missing from OpenUpgrade so that was the same as we encountered for l10n_nl



------------------------------------------

On 11/21/22 16:07, Rémy Taymans wrote:
Dear community,

I'm currently migrating a database from version 9.0 to version 14.0.
My problem is between 12.0 and 13.0 where accounting element has
changed.

The database is using Mis Builder to generate accounting reports. These
reports are based on account.account.tag that are linked to account.tax
(and also account.move.line in 13.0).

As I have seen, in 9.0 (and until 12.0), account.account.tag are linked
to an account.tax via a simple field tag_ids :
https://github.com/OCA/OCB/blob/12.0/addons/account/models/account.py#L937

Starting from 13.0, tags are no more linked to account.tax directly.
They are linked to an account.tax.repartition.line which is linked to an
account.account.tax.
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account.py#L1340-L1341

In 13.0, the account.chart.template has been updated accordingly.

As is, the migration did not succeed. At some point, odoo try
to remove the old account.tag. But that's not possible because these
tags are linked to existing account.move.line.
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account_move.py#L2792-L2796

To avoid such deletetion, I flagged existing account.account.tag as
noupdate=True.

When migrating the database the existing all account.account.tag linked
to the account.tax are moved to all the account.tax.repartition.line of
the account.tax. Meaning that if there is account.account.tag named
"03", "49", "54" that are all linked to an account.tax. After migration
each line of account.tax.repartition.line will have "03", "49" and "54"
as tags.

This does not reflect the new account.chart.template for belgium.

So my first intention was to update the account.tax, particulary their
account.tax.repartition.line to replace the old account.account.tag by
the new one created during the migration. Using the new
account.chart.template as an example. But that does not works, because
existing account.move.line always points to the old account.account.tag.

I have no idea how to update the tags on the account.move.line to
reflects the new account.chart.template and the new tags.

I tried to find the logic that computes tags on an account.move.line.
But it's really obscure for me. And simply applying the following
recompute method does not works (it causses issue about non balanced
account element):
https://github.com/OCA/OCB/blob/13.0/addons/account/models/account_move.py#L990-L1049

Anther option is to map the old tags to the new one. But here comes the
problem that there is more new tags than old ones. So that I'm not sure
how to perform the mapping. For example the following records:
https://github.com/OCA/OCB/blob/12.0/addons/l10n_be/data/account_tax_template_data.xml#L16-L19
https://github.com/OCA/OCB/blob/13.0/addons/l10n_be/data/account_tax_report_data.xml#L45-L52
In 13.0 the account.account.tag created have sign. There exist two
version for the tag 03:
SELECT name, applicability, tax_negate
FROM account_account_tag WHERE name ILIKE '%03';
           name            | applicability | tax_negate
---------------------------+---------------+------------
 Belgium VAT Form: grid 03 | taxes         |               <- the old one
 -03                       | taxes         | t             <-|
 +03                       | taxes         | f             <-L the two new ones
(3 rows)

Should I replace the old "03" tag by the "+03" one, or should I
sometimes replace it by the "-03" and when ?

When this will be solved, I will still be wondering if such a line is
ok ?
SELECT account_move_line_id, name
FROM account_account_tag_account_move_line_rel AS aatamlr
JOIN account_account_tag AS aat
ON aatamlr.account_account_tag_id = aat.id
WHERE account_move_line_id = 9166;
 account_move_line_id |           name
----------------------+---------------------------
                 9166 | Belgium VAT Form: grid 03
                 9166 | Belgium VAT Form: grid 54
                 9166 | Belgium VAT Form: grid 49
                 9166 | Belgium VAT Form: grid 64

Where we see that an account.move.line is linked to 4 differents
account.account.tag.


I also take a look at this:
- https://github.com/OCA/OCB/blob/12.0/addons/account/models/chart_template.py#L14-L52
- https://github.com/OCA/OCB/blob/13.0/addons/account/models/chart_template.py#L14-L31
But it does not seams to solve the previous issue.

And finaly I looked at account_chart_update module, but it did not seams to solve the previous issues niether.
https://github.com/OCA/account-financial-tools/tree/14.0/account_chart_update

If you have any clue, it will be very helpfull. :)

Regards,

--
Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <https://github.com/remytms>
<https://coopiteasy.be>

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference