Currently, an error occurs when a user attempts to pay an invoice.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):**

 - Install the `Accounting` module.
 - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`.
 - Go to `Invoices` and `create a new Invoice`.
 - Add one invoice line and set the `Payment Term` to the `newly created payment term`.
 - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden).
 - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`.
 - Now `Confirm the invoice` and `Click on Pay`.

**Error:**
`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

**Cause:**
This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised.
Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error.

**Fix:**
This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above.

[1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703

[2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635

[3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305

[4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522

sentry-713241246

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

Forward-Port-Of: odoo/odoo#241060

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging with a barcode to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and to scan it.
8. Now scan the barcode of the packaging
-> It triggers an traceback

### Cause of the issue:
The product_id and their uom_uom that are in the move_lines are added in the cache:
https://github.com/odoo/enterprise/blob/d0a7619bb87fb1fad45451a1c79dca73994ee8bd/stock_barcode/models/stock_picking.py#L92-L94
However the kit product and the product_uom are not added in the cache, since they are not in the move_lines ( the components are in the move_lines not the kit product).

In _get_barcode_data, where it's supposed to retrieved the product_uom (packaging in previous version, see (1)), it retrieve the uom_uom of the products again: https://github.com/odoo/enterprise/blob/4d3c33ed152f014e4965613756845fb054c9f2bc/stock_barcode_mrp/models/stock_picking.py#L12-L17

For the scan of the packaging barcode to work properly it also need the corresponding product_id, because if the product_id it's not present an it will raise and error:
https://github.com/odoo/enterprise/blob/6e2c39ea2898e870f348e0bbe4ad29abe35794b6/stock_barcode/static/src/models/barcode_model.js#L1104-L1108
https://github.com/odoo/enterprise/blob/6e2c39ea2898e870f348e0bbe4ad29abe35794b6/stock_barcode/static/src/models/barcode_model.js#L1635
https://github.com/odoo/enterprise/blob/6d4fe2b03b7d981e3092e42d1b5e1786734d9427/stock_barcode/static/src/lazy_barcode_cache.js#L102-L115

(1) Changes from this commit:
https://github.com/odoo/enterprise/commit/b4f285138edc227050c89c92fd15d39fb656da6b
"This commit removes `product.packaging` model completely and merges it
into units of measure feature."

The packaging changed in a new model called product.uom that is the link between the product and it's uom.uom

opw-4852875

Forward-Port-Of: odoo/enterprise#87867

This PR adds 2 migration scripts which allow older iot box images (<= 25_07) to work with databases in saas-19.1 and later.

It updates os to debian trixie and installs all of the necessary packages to allow working after upgrades or with new databases. The update takes approximately 30 minutes. A warning about the necessity to update is added in this
upgrade script: https://github.com/odoo/upgrade/pull/9153

1) Our IoT Boxes which the clients are currently using are running under "Bookworm" os with Python 3.11 with Odoo on it.
2) We have a mecanism which aligns the iot box code to the connected database version using `git checkout`
3) In saas-19.1 Odoo bumped the Python minimal version requirement to 3.12
4) As a result when our iot boxes will do 'git checkout saas-19.1' Odoo will never be able to start anymore
5) When this happens the only way to fix it is either remotely connect to the iot box and run a script like in this PR (remote debug must be activated before upgrading) or flash the iot box with a new image based on Trixie
6) This PR avoids this by updating the current OS to Trixie and the Python version accordingly so that the clients can keep using their iot boxes in saas-19.1

Forward-Port-Of: odoo/odoo#241129

Steps to reproduce:
-------------------
1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order
2. From PoS, make an order, select it to invoice, and click the pay button.
3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed).
4. Come back to the initial page, a traceback will appear and the ticket is not printed.

Why it happens:
---------------
The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`!

The fix
-------
Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`.

opw-5124585

Forward-Port-Of: odoo/odoo#241781
Forward-Port-Of: odoo/odoo#239008