Contributors mailing list archives

Browse archives


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

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 has been introduced. Now in 13, some tags are defined in xml files as 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 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:
I've moved some of the code into helper functions:
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

The database is using Mis Builder to generate accounting reports. These
reports are based on account.account.tag that are linked to
(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 via a simple field tag_ids :

Starting from 13.0, tags are no more linked to directly.
They are linked to an which is linked to an

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.

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

When migrating the database the existing all account.account.tag linked
to the are moved to all the of
the Meaning that if there is account.account.tag named
"03", "49", "54" that are all linked to an After migration
each line of 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, particulary their 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):

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:
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 =
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

I also take a look at this:
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.

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


Rémy Taymans @ Coop IT Easy
+32 493 02 69 85 - <>

Post to: