### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appears as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result, the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, taxes with `['taxImpact']['accounting'] == 'none'` should be part of the accounting: no line should be created for this tax. So we filter them out in `_get_external_taxes`.

We also log these taxes in the chatter to keep a trace of them. As the parameter `'accounting': 'none'` is linked with the tax and not the line, if a tax on one line has `'accounting': 'none'` then the same tax will also have 'accounting': 'none' on all other lines. We use this to fetch all non accounting taxes, then we use the summary to construct the message like it was done before.

The logging in the bridge with pos needed to ba adapted because now the taxes may not be unarchived as they are ignored when they have `'accounting': 'none'`.

opw-4964315

Forward-Port-Of: odoo/enterprise#91916

Currently, an error occurs when user tries to select any measure in cohort view.

Steps to replicate:
- Install `sale_management` and `web_studio`.
- Open the Sales app and turn on studio mode.
- Under the Views tab, turn on cohort view.
- Under the Measures field, select any value and observe the error appearing in the terminal.

Error:
`ValueError: Invalid aggregate method 'None' for 'create_date:None'`

Cause:
- The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`.

- This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view.

Solution:
- Corrected the choices of Measure field to `measureFields`.

- Also added a condition to allow only those fields that have an aggregator
  (for some fields like `sequence` that dont have an aggregator).

- Also removed context field from arguments [2] in the rpc call as function doesnt need it [3]
  (This shows warning on runbot as well).

[1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30

[2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87

[3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805

sentry-6781792463

Forward-Port-Of: odoo/enterprise#94615
Forward-Port-Of: odoo/enterprise#91599

Before this commit, if a blackbox was unplugged and re-plugged, and it was assigned a different serial port by the Raspberry Pi, it would show up as a new device in the database meaning the existing configuration wouldn't work.

After this commit, we handle the blackbox as a special case, and if the name of the device matches exactly with our existing blackbox, we update its identifier instead of creating a new device.

This does require a new device specific check in the controller which is quite ugly. Another approach would have been to make the identifier of the blackbox equal its FDM ID instead of the serial port, but this was not done for the following reasons:
- Changing the identifier format in stable would cause all existing clients' blackboxes to become unconfigured once their IoT box restarts.
- Making the identifier different to the serial port would require a hack in the blackbox driver to change its own identifier and update the devices dictionary, since the serial interface assumes all devices use the port as their identifier.

task-5055027

Forward-Port-Of: odoo/enterprise#93665
Forward-Port-Of: odoo/enterprise#93593

[FIX] account_reports: external value check lock date

This commit add the check that protects external values from being edited out of the lock date.
For example when the tax report is submitted, the user is not supposed to modify any external values anymore.

To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow.

Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error.

task-5012442

Forward-Port-Of: odoo/enterprise#94853
Forward-Port-Of: odoo/enterprise#92949

The `hr_contract` table is renamed to `hr_version` as part of the https://github.com/odoo/upgrade/blob/3bea30d1fd0cd202006da4ad11e00e283cbc78d0/migrations/hr/saas~18.4.1.1/pre-migrate.py#L29, script, which is executed before any `hr_contract_salary` script, including module ones. As a result, any database from 18.3 to 18.4+ with `hr_contract_salary` < 2.1 will run into:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 181, in load_module_graph
    migrations.migrate_module(package, 'pre')
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 220, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/migration.py", line 257, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/enterprise/saas-18.4/hr_contract_salary/upgrades/saas~18.3.2.1/pre-unarchive-partially-signed-offers.py", line 4, in migrate
    cr.execute(
  File "/home/odoo/src/odoo/saas-18.4/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
psycopg2.errors.UndefinedTable: relation "hr_contract" does not exist
LINE 4:                 FROM hr_contract c
                             ^
```

As a fix, the query is moved into the `hr` script mentioned above.

see: https://github.com/odoo/upgrade/pull/8466

opw-5071923
upg-3121357
tbg-2136

Forward-Port-Of: odoo/enterprise#94931

Currently, an error is produced while creating an invoice for a subscription order
with combo products, and it can be triggered in two different ways.

1. Directly create an invoice.
    - Create and confirm a subscription with a combo product.
    - Create an invoice for this subscription and try to confirm it.
    - Validation error shown in display and error generated in log

2.  When cron "Payment: Post-process transactions" trigger:
    - Enable the Automatic Invoice option in the Subscription settings.
    - Activate a demo payment provider (e.g. Demo: Payment Provider).
    - Create and confirm a subscription that includes a combo product.
    - Click on "Pay" to process the subscription payment.
    - An error occurs when the above-mentioned cron is triggered, and it
      tries to create an invoice for a subscription order.

Error: `new row for relation "account_move_line" violates check constraint
 "account_move_line_check_accountable_....`

This issue arises during the creation of an account move line for deferred entries for
the 'Combo Product' column of the original invoice (subscription):
- At [1], `deferred_start_date` and `deferred_end_date` were added to all invoice line values within `_prepare_invoice_line` used to create the original invoice
- Then, at [2], during confirmation of the `original invoice`, the code attempts to generate `deferred entries` for for move where any move lines that has a `deferred_start_date`
- At code line [3], during the generation of deferred entries, an account move line is created without an associated `account_id`
- During `display_type` computation at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L480-L484), `line.move_id.is_invoice()` evaluates to `False`. As a result, the line is assigned a `display_type` as a 'product'.
- Since `display_type` is 'product' and `account_id` is missing, it violates the following check constraint at [Code](https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/account/models/account_move_line.py#L451): `CHECK(display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL)`

This commit fixes the issue by preventing the addition of the `deferred_start_date` and `deferred_end_date` keys for invoice lines whose corresponding sale order lines have products of type 'combo' at [1].

[1]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/sale_subscription/models/sale_order_line.py#L448-L449
[2]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L113-L114
[3]:- https://github.com/odoo/enterprise/blob/9642f7d8026149a6524e036c523b65ccbdf17258/account_accountant/models/account_move.py#L309

sentry-6763423503

Forward-Port-Of: odoo/enterprise#90989

*{quality_control,stock}_picking_batch

### Steps to reproduce:

- Got to Quality > Quality control > Control Point
- Create a quality control point:
  - Operation: receipt
  - Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated. 
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.

### Cause of the issue:

While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185

### Fix:

While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).

Community: https://github.com/odoo/odoo/pull/223852

opw-5009635

Forward-Port-Of: odoo/enterprise#93995
Forward-Port-Of: odoo/enterprise#92951