Fixes
```
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2647, in _process_end
    self._process_end_unlink_record(record)
  File "/home/odoo/src/odoo/addons/website/models/ir_model_data.py", line 35, in _process_end_unlink_record
    return super()._process_end_unlink_record(record)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_model.py", line 2576, in _process_end_unlink_record
    record.unlink()
  File "/home/odoo/src/odoo/addons/mail/models/ir_model_fields.py", line 52, in unlink
    'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
                ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/api.py", line 612, in __getitem__
    return self.registry[model_name](self, (), ())
           ~~~~~~~~~~~~~^^^^^^^^^^^^
  File "/home/odoo/src/odoo/odoo/modules/registry.py", line 240, in __getitem__
    return self.models[model_name]
           ~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'my.custom.model'
```

To reproduce:

* add a model with a tracked field to a module
* create a record and update field value to create a tracking message
* remove the model from the module and update the module


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#204978

This started with noticing that the way the rejected invoices were handled in the response changed.  Before, it was handled as a json in a string in a json, now it is directly in a json and most importantly, when the invoice is considered "rejected", ZATCA returns it as a 400 error.

This made us check further and e.g. when we resend a rejected, the issue time is supposed to be the same, so the logic of the confirmation time was changed so it still behaves the same in pure l10n_sa, but if you have a rejected one, it won't be overwritten when you confirm the invoice again.

We also added the rejected invoice as an attachment for auditibility and put a mechanism in place to avoid the user to delete it.

When we have a 400 error, the chain index is reset (ICV field), because then, when we send a new one, it will have a new ICV. The goal for auditibility is that each chain index corresponds to one submission of an invoice.  E.g. if we have a timeout, the chain index is kept and we are supposed to check that invoice first before proceeding with other invoices because we do not know whether the invoice was submitted or not, so we need to retry and that way it might override the existing ICV with ZATCA.

We do the same for 401+ errors just to make sure that one ICV equals one invoice (although here, we could reset the sequence after we get the error if it causes too much trouble)

The error/warning messages were a bit updated to clearly indicate the HTTP status code and the error code from ZATCA in bold and to avoid putting Python dicts, but nicely formatted messages.

opw-4689622

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#207346
Forward-Port-Of: odoo/odoo#205671

Otherwise, it will create massive domains, which may exhaust the memory available to PG:

```
 Traceback (most recent call last):
   File "/home/odoo/src/odoo/18.0/odoo/tools/safe_eval.py", line 397, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
   File "ir.actions.server(364,)", line 5, in <module>
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_orderpoint.py", line 257, in action_open_orderpoints
    return self._get_orderpoint_action()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_orderpoint.py", line 500, in _get_orderpoint_action
    qty_by_product_loc, dummy = self.env['product.product'].browse(product_ids)._get_quantity_in_progress(location_ids=location_ids)
   File "/home/odoo/src/odoo/18.0/addons/purchase_stock/models/product.py", line 50, in _get_quantity_in_progress
    groups = self.env['purchase.order.line'].sudo()._read_group(domain,
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1989, in _read_group
    row_values = self.env.execute_query(query.select(*groupby_terms.values(), *select_terms))
   File "/home/odoo/src/odoo/18.0/odoo/api.py", line 978, in execute_query
    self.cr.execute(query)
   File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 572, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/18.0/odoo/sql_db.py", line 354, in execute
    res = self._obj.execute(query, params)
 psycopg2.errors.SyntaxError: memory exhausted at or near "("
LINE 1: ...((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((...
                                                             ^
```

upg-2461663

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#207421
Forward-Port-Of: odoo/odoo#202065

Steps to reproduce:
Using POS configs in french company with l10n_fr_post_cert module installed.
- Checkout 1: Prepare an order with several lines held in stock, to ensure that Odoo takes sufficient time for payment.
- Cash desk 2: Prepare an order
- Cash-desk 1: Start order payment.
- Cash-desk 2: Start order payment while cash-desk 1 is still paying.

Issue:
When writing 'paid' in a pos_order the l10n_fr_post_cert sets the l10n_fr_pos_cert_sequence_id field. A competition error occurs on cash desk 2 during payment: could not obtain lock on row in relation “ir_sequence”. The odoo.service.model retries to create the order and since the ir_sequence of pos_config used in the pos_order name is not set to "no_gap", the pos_order names have a gap equal to the number of retries.

Task-4708543

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#207288
Forward-Port-Of: odoo/odoo#205935

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

Problem: When a company has both Swiss and Belgian modules installed,
a cache invalidation issue causes computed fields to be missing after a 
write() operation. This results in errors when accessing l10n_be_is_below_scale_warning.

Purpose: Change the field assignment method to avoid cache invalidation
caused by Swiss module operations that occur during write() transactions.

Steps to Reproduce on Runbot: This issue can't be easily reproduced on 
runbot due to complexity requirements. It requires:
1. Both Swiss and Belgian modules installed
2. Contracts with Swiss companies being processed by Belgian payroll code
3. Accumulated Swiss data that's only generated after pay periods elapse

Notes: The failure occurs because the Swiss module deletes
l10n.ch.lpp.mutation records during the write operation, which invalidates
the cache for computed fields. Using update rather than write for the field
values avoids this issue.

opw-4710135

Forward-Port-Of: odoo/enterprise#84082