Due to the `qty_to_order` field on `stock.orderpoint` being a stored computed field, it needs to be recalculated every time one or more of its dependencies could have changed, to keep a consistent record in the database.
It is, however, dependent on the `qty_forecast` field which is a non-stored computed field, depending itself on all the stock moves that are linked to the product set on the orderpoint.
This results in a complete recalculation of the `qty_on_hand`, `qty_forecast` and `qty_to_order` on ALL the orderpoints linked to a product every time some `stock.move` has been touched or created with that product. Even if many of those orderpoints may not even be located in the concerned warehouse.
This situation can create a performance bottleneck when just processing pickings, as its constantly (and often pointlessly) recalculating these field values to store. This becomes a major issue in case the concerned database contains many warehouses with many different orderpoints.

This issue is remedied in a more permanent way for master in [1], but due to the stable policy we use a different approach here: The `qty_to_order` field on `stock.orderpoint` is now no longer dependent on `qty_forecast`. Instead, when creating `stock.moves` or writing on its `state`, `product_uom_qty` or `date` fields, we manually trigger a recalculation of the `qty_to_order` on all the orderpoints on the relevant product, but only in the relevant warehouses. In case there is no relevant warehouse for the `stock.move` (none on the source or destination move), we fall back to the previous behavior of recalculating `qty_to_order` for all orderpoints linked to the product.

[1] https://github.com/odoo/odoo/pull/159432

task-3822497

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

Forward-Port-Of: odoo/odoo#174873
Forward-Port-Of: odoo/odoo#164300

**Before commit**
  - When the electronic scale is disconnected, its connection status is not updated.

**After commit**
  - When the electronic scale is disconnected, the status of the electronic scale will be updated.

**Error Description**
  - If you have a digital scale that is connected and selected for use in POS.
  - The status of IoT devices is updated via the router `/hw_proxy/status_json` and the function `get_status()`
  - However, the status of the digital scale is not updated when it is disconnected. This leads to the scale still reporting that it is connected when calling the `get_status()` function.
 
The scale status is updated via `self._status`
https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialScaleDriver.py#L110-L114

However `self._status` is not updated when disconnected.
https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialBaseDriver.py#L129-L144

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

Forward-Port-Of: odoo/odoo#175063

In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company.

Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`).

The peppol official documentation states:

1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller VAT identification number) or the local identification (defined by the Seller’s address) of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status." [1]

2. `PartyLegalEntity/CompanyID`: "An identifier issued by an official registrar that identifies the Seller as a legal entity or person." [2]

Consequently, it is not certain whether the company_registry should always be used to fill the element `PartyLegalEntity/CompanyID` or not, hence we only use it in Luxembourg for now.

[1] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyTaxScheme/cbc-CompanyID/
[2] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/

opw-4075457

Forward-Port-Of: odoo/odoo#175379

Steps to reproduce the bug:
- Create a storable product “P1” with BoM
    - Component: 1 unit of C1 tracked by Serial Number
- Update the quantity of P1 with “SN1”

- Create a MO to produce one unit of P1:
    - Confirm it
    - Select “SN1” for C1
    - Validate the MO

- Create a repair order to remove C1 from P1 and confirm, start, and complete the repair:
    - Destination location: WH/Stock
    - Serial Number: “SN1”

- Perform the same steps to add C1 (SN1) into P1 again.
- Remove C1 (SN1) a second time.

* After these steps, C1 with SN1 is available in stock.

- Create a new MO to produce one unit of P1:
   - Confirm and select “SN1” for C1
   - Try to validate it

Problem:
When checking the availability on the MO, SN1 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number SN1 used for component C1
has already been consumed."

opw-4029309

Forward-Port-Of: odoo/odoo#173536
Forward-Port-Of: odoo/odoo#173191

… when the package type is scanned using the barcode

Description of the issue this PR addresses: 
This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale.

Steps to reproduce:
1. Enable packaging configuration.
2. Create a sales order and confirm it; this will generate a delivery.
3. Find that delivery in the ‘Barcode’ app.
4. Add/scan the product.
5. Scan the package type.

Current behavior before PR:
Following the above steps, when the package type is scanned using the barcode, the scanned package type is not populated in the opened package wizard. Consequently, the shipping weight field is not visible, preventing the retrieval of the weight from the IoT scale.
Please refer to the screen recording before the PR: 
https://github.com/user-attachments/assets/e4764005-6758-4f80-a189-e27e8897f853

Desired behavior after PR is merged:
After merging this PR, when the package type is scanned using the barcode, the scanned package type will be correctly populated in the opened wizard. As a result, the shipping weight will be visible, and it will be able to retrieve the scale weight from IoT.
Please refer to the screen recording after the PR:
https://github.com/user-attachments/assets/f408ee60-2495-48a5-96ea-3ced502c85dc

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

Forward-Port-Of: odoo/odoo#173949

Problem:
An issue arises due to a negative analytical distribution. If the analytical percentage is negative, its sign will match the sign of the amount_currency of its move line. However, in the query that groups by the analytical account for P&L, the amount value is inverted. This does not cause a problem when the analytic percentage is positive because the amount_currency sign is opposite to the sign of the analytic line amount. But, in cases where the sign is the same, there will be a balance with a different sign than the amount, which will not comply with the constraint of the account.move.line table:
"account_move_line_check_amount_currency_balance_sign".

Steps to reproduce:
1. Activate "Analytic Accounting" in the settings
2. In an invoice, set an analytic distribution with a negative percentage
3. Validate the invoice
4. Go to P&L report an try to group by an analytic account
5. A validation error will occur.

Proposed solution:
Remove the constraint in the temporary table.

opw-4092475
opw-4092232
opw-4086515
opw-4084850
opw-4083077

Forward-Port-Of: odoo/enterprise#68057
Forward-Port-Of: odoo/enterprise#67953

Currently, a traceback may occur when we get the token as false

Error:-
```
TypeError: can only concatenate str (not "bool") to str
  File "odoo/tools/safe_eval.py", line 390, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(348,)", line 1, in <module>
  File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi_stock/models/account_move.py", line 14, in cron_run_sii_workflow
    super(AccountMove, self).cron_run_sii_workflow()
  File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 806, in cron_run_sii_workflow
    self_skip._l10n_cl_ask_claim_status()
  File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 780, in _l10n_cl_ask_claim_status
    move.l10n_cl_verify_claim_status()
  File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 288, in l10n_cl_verify_claim_status
    response = self._get_dte_claim(
  File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/l10n_cl_edi_util.py", line 408, in _get_dte_claim
    settings = Settings(strict=False, extra_http_headers={'Cookie': 'TOKEN=' + token})
ValueError: <class 'TypeError'>: "can only concatenate str (not "bool") to str" while evaluating
'model.cron_run_sii_workflow()'
  File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
    self.env['ir.actions.server'].browse(server_action_id).run()
  File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
    res = super().run()
  File "odoo/addons/base/models/ir_actions.py", line 971, in run
    res = runner(run_self, eval_context=eval_context)
  File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
    res = super(ServerAction, self)._run_action_code_multi(eval_context)
  File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self))  # nocopy allows to return 'action'
  File "odoo/tools/safe_eval.py", line 404, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

But here in the code, only the None case was handled. https://github.com/odoo/enterprise/blob/5dae45bea35b55e88e1d7199a555f9cc5375c899/l10n_cl_edi/models/l10n_cl_edi_util.py#L407-L410

After applying this commit it will resolve this issue by handling all the falsy cases for the token.

sentry-5539925394

Forward-Port-Of: odoo/enterprise#66232