odoo/odoo · error · UserError

You cannot modify the field %s of a journal that already has

Error message

You cannot modify the field %s of a journal that already has accounting entries.

What it means

In write(), if 'restrict_mode_hash_table' is being turned off and the journal already has account.move rows matching _get_move_hash_domain (entries with inalterable_hash set), Odoo refuses with this UserError naming the field. Hashed (inalterable) entries were signed while locking was on, so disabling it retroactively would break the audit guarantee.

Source

Thrown at addons/account/models/account_journal.py:801

                        'company_id': company.id,
                        'partner_id': company.partner_id.id,
                    })
            if 'currency_id' in vals:
                if journal.bank_account_id:
                    journal.bank_account_id.currency_id = vals['currency_id']
            if 'bank_account_id' in vals:
                if vals.get('bank_account_id'):
                    bank_account = self.env['res.partner.bank'].browse(vals['bank_account_id'])
                    if bank_account.partner_id != company.partner_id:
                        raise UserError(_("The partners of the journal's company and the related bank account mismatch."))
            if 'restrict_mode_hash_table' in vals and not vals.get('restrict_mode_hash_table'):
                domain = self.env['account.move']._get_move_hash_domain(
                    common_domain=[('journal_id', '=', journal.id), ('inalterable_hash', '!=', False)]
                )
                journal_entry = self.env['account.move'].sudo().search_count(domain, limit=1)
                if journal_entry:
                    field_string = self._fields['restrict_mode_hash_table'].get_description(self.env)['string']
                    raise UserError(_("You cannot modify the field %s of a journal that already has accounting entries.", field_string))
        result = super(AccountJournal, self).write(vals)

        # Ensure alias coherency when changing type
        if 'type' in vals and not self.env.context.get('account_journal_skip_alias_sync'):
            for journal in self:
                alias_vals = journal._alias_get_creation_values()
                alias_vals = {
                    'alias_defaults': alias_vals['alias_defaults'],
                    'alias_name': alias_vals['alias_name'],
                }
                journal.update(alias_vals)

        # Ensure the liquidity accounts are sharing the same foreign currency.
        if 'currency_id' in vals:
            for journal in self.filtered(lambda journal: journal.type in ('bank', 'cash', 'credit')):
                journal.default_account_id.currency_id = journal.currency_id

        # Create the bank_account_id if necessary

View on GitHub (pinned to 1e661df964)

Solutions

1. Leave restrict_mode_hash_table enabled on journals that already produced hashed entries.
2. Create a new journal without hashing for editable entries and keep the hashed journal frozen.
3. In a disposable test database only, remove/RESET the hashed entries first (never in production — legal requirement in many jurisdictions).

Example fix

# before
journal.write({'restrict_mode_hash_table': False})  # UserError: hashed entries exist

# after
hashed = env['account.move'].sudo().search_count(journal._get_move_hash_domain(
    common_domain=[('journal_id', '=', journal.id), ('inalterable_hash', '!=', False)]), limit=1)
if not hashed:
    journal.write({'restrict_mode_hash_table': False})

hashed = env['account.move'].sudo().search_count(
    env['account.move']._get_move_hash_domain(
        common_domain=[('journal_id', '=', journal.id), ('inalterable_hash', '!=', False)]),
    limit=1)
if not hashed:
    journal.write({'restrict_mode_hash_table': False})

When it happens

Trigger: journal.write({'restrict_mode_hash_table': False}) on a journal that has at least one entry with ('inalterable_hash', '!=', False); toggling 'Lock Hash Entries' off in the accounting lock settings after entries were hashed.

Common situations: Trying to relax fiscal-lock settings after enabling hashing; test databases that enabled hashing then wanted to edit entries; scripted setup flipping lock flags.

Related errors

• The partners of the journal's company and the related bank a
• You cannot duplicate a Lock Date Exception.
• You cannot add/modify entries prior to and inclusive of: %(l
• You cannot delete this entry, as it has already consumed a s
• You cannot edit the following fields: %(fields)s. The follow

AI-assisted analysis of odoo/odoo@1e661df964 (2026-08-15). Data as JSON: /api/errors/34e0818aef995553. Report an issue: GitHub.