[grojof]

Module

l10n_es (12.0 -> 13.0)

The bug

Up to 12.0, the reverse charge and intra-community purchase taxes of l10n_es are group taxes. The
group holds no account; its two children hold them (472 for the deductible side, 477 for the
self-assessed side). In 13.0 each of them is a single tax with repartition lines.

use_new_taxes_and_repartition_lines_on_move_lines creates those repartition lines for the 15 group
taxes, and takes their account from the group itself:

SELECT CASE WHEN tax_exigibility = 'on_payment' THEN cash_basis_account_id ELSE account_id END, ...
FROM account_tax WHERE id IN (<the group taxes>)

A group tax has no account, so the four tax repartition lines of each of the 15 taxes are left without
one. After the migration:

• the journal items that existed keep their accounts (472 and 477);
• a bill posted with one of these taxes puts both tax amounts on the expense account of its line, and
  472 and 477 are not moved.

Nothing fails and the tax amounts are right, so it is easy to miss.

Why not leave it to account_chart_update

On 13.0, account_chart_update with "Update Tax Accounts" does fill these accounts, and a database
that runs it right after this step does not see the problem. Three things still make me think the
migration should keep them itself:

• The wizard sets the template's accounts, not the database's. A company that had its own account on a
  child tax (say 472001) gets 472000 from the wizard; with this change the migration keeps 472001.
• A database carried on to later versions without running it keeps the taxes without account: on 18.0
  the bill still posts both amounts on the expense account.
• On 18.0 the wizard can no longer repair a tax that has been used: it finds the difference
  ("Distribution") and stops with a ForeignKeyViolation on
  account_move_line_tax_repartition_line_id_fkey, since it replaces the repartition lines the journal
  items point at. With this change that tax shows no difference in its distribution, and the wizard
  applies.

The fix

Once the group's repartition lines exist, give each tax line the account of its child's repartition
line, matched by repartition type and sign. It is the match the same function already uses, a few lines
below, to move the journal items from the child's repartition line to the group's.

Only lines without an account are written.

To reproduce

Affected versions: 12.0 -> 13.0 (OpenUpgrade 13.0 at 489d722; OCB 12.0 at 4b525526)

1. Create a 12.0 database with l10n_es, without demo data:
   odoo-bin -d repro -i l10n_es --without-demo=all --stop-after-init
2. In odoo-bin shell, post a vendor bill with an intra-community tax:

   tax = env.ref('l10n_es.1_account_tax_template_p_iva21_ic_bc')
   partner = env['res.partner'].create({'name': 'EU supplier', 'supplier': True})
   journal = env['account.journal'].search([('type', '=', 'purchase')], limit=1)
   expense = env['account.account'].search([('code', '=like', '600%')], limit=1)
   inv = env['account.invoice'].create({
       'type': 'in_invoice', 'partner_id': partner.id, 'journal_id': journal.id,
       'date_invoice': '2019-06-01',
       'invoice_line_ids': [(0, 0, {
           'name': 'goods', 'quantity': 1, 'price_unit': 1000, 'account_id': expense.id,
           'invoice_line_tax_ids': [(6, 0, tax.ids)]})]})
   inv.compute_taxes()
   inv.action_invoice_open()
   env.cr.commit()

   Its entry: 600000 debit 1000, 472000 debit 210, 477000 credit 210, 410000 credit 1000.
3. Migrate to 13.0: odoo-bin -d repro --update all --stop-after-init
4. The group taxes have no account on their tax repartition lines:

   SELECT count(DISTINCT t.id)
   FROM account_tax t
   JOIN account_tax_repartition_line rl ON t.id IN (rl.invoice_tax_id, rl.refund_tax_id)
   WHERE rl.repartition_type = 'tax' AND rl.account_id IS NULL
     AND EXISTS (SELECT 1 FROM account_tax_filiation_rel f WHERE f.parent_tax = t.id);

   Without the fix: 15. With it: 0.
5. In odoo-bin shell (13.0), post the same bill again:

   tax = env.ref('l10n_es.1_account_tax_template_p_iva21_ic_bc')
   partner = env['res.partner'].search([('name', '=', 'EU supplier')], limit=1)
   expense = env['account.account'].search([('code', '=like', '600%')], limit=1)
   bill = env['account.move'].create({
       'type': 'in_invoice', 'partner_id': partner.id, 'invoice_date': '2020-06-01',
       'invoice_line_ids': [(0, 0, {
           'name': 'goods', 'quantity': 1, 'price_unit': 1000, 'account_id': expense.id,
           'tax_ids': [(6, 0, tax.ids)]})]})
   bill.post()
   for line in bill.line_ids.sorted('id'):
       print(line.account_id.code, line.debit, line.credit)

   Without the fix: 600000 1000/0, 600000 210/0, 600000 0/210, 410000 0/1000.
   With it: 600000 1000/0, 472000 210/0, 477000 0/210, 410000 0/1000, as in 12.0.

Checks

On that database, migrated once without the fix and once with it:

• the only difference is 60 repartition lines (15 taxes, 4 tax lines each), from no account to an
  account;
• the accounts are those of the 13.0 tax templates of l10n_es for each of the 15 taxes;
• journal items and taxes are identical.

The points about account_chart_update were run too: on 13.0 on that database, with the wizard at
4d0c3d8 (the own account was set on the child tax in 12.0, before migrating); and on 18.0 on the same
database with the company's country set to Spain in 12.0, carried on with OpenUpgrade and OCB 14.0 to
18.0 (core modules only), with the wizard at e4c1b86.

This contribution was prepared with AI assistance (Claude Opus 5.5), and reviewed and tested by me. The
commit carries an Assisted-by: trailer, per the OCA AI policy.

[pedrobaeza]

You have to avoid the so verbose explanation and go to the point, but let's add this extra query for fine-graining the conversion although you should run account_chart_update after.