Enterprise PR: https://github.com/odoo/enterprise/pull/100331

**This PR contains 2 commits:**

- **[IMP] iot_base: allow use of LNA for IoT requests**
Chromium 142 added support for HTTPS -> HTTP requests on the local network (Local Network Access). This commit adds a flag to the IoT longpolling class to enable LNA support. The flag forces all requests to use HTTP even in an HTTPS environment. It also sets the `targetAddressSpace` option to `local` in the `fetch` request.

- **[IMP] point_of_sale: use_lna support for IoT requests**
Since https://github.com/odoo/odoo/pull/235702, there is a `point_of_sale.use_lna` system parameter. When it is set, ePOS requests will use HTTP instead of HTTPS, and the `targetAddressSpace: "local"` option is used in the `fetch` request. This bypasses the need for a HTTPS certificate.

This commit adds the same functionality to all IoT requests from the POS. This should allow the IoT box to function correctly without a HTTPS certificate.

task-5353672

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

Forward-Port-Of: odoo/odoo#237598
Forward-Port-Of: odoo/odoo#237147

Currently, in a continental perpetual setting for the stock valuation, the inventory valuation lines are not created when closing the session if the orders when not invoiced.

Steps to reproduce:
-------------------
* Using My Belgian Company
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Any cost method, AVCO for example
  * Set up valuation account and journal
* Create a product
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing method, AVCO for example
  * Set inventory valuation to perpetual
* Open pos session
* Make an order for the product, put partner, invoice it
* Close session, go to session journal items
> Observation: Valuation lines are present
* Open pos session
* Make an order for the product, no partner, no invoice
* Close session, go to session journal items
> Observation: Valuation lines are missing.

Why the fix:
------------
When the company is set with perpetual inventory valuation, in the context of the point of sale, there should not be any difference between anglo saxon and continental accounting.

When we check the same flow with anglo-saxon, there is no difference for the creation of the inventory valuation move line whether we invoice the order or not. Inventory valuation lines are always present.

Valuation entries are created in `_create_stock_valuation_lines()` if information is available regarding `stock_valuation`. https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L1258-L1273

The information for `stock_valuation` is supposed to be computed in `_accumulate_amount()`.

However this is currently only computed when we have the anglo saxon accounting:
https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L953

Instead we will now only check if the company is valuating the inventory in real time.

We also apply the same fix on paid orders we want to invoice afterwards.

opw-5167946

Forward-Port-Of: odoo/odoo#240176

When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it.

Steps to reproduce:
1. Install a European localization (ex: l10n_at)
2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT.
3. Create a valid foreign customer. (within the EU)
4. Create and send an invoice for this customer.
5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position.

This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML.

This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it.

opw-5182837

Forward-Port-Of: odoo/odoo#241436
Forward-Port-Of: odoo/odoo#236692

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041

Forward-Port-Of: odoo/odoo#240978
Forward-Port-Of: odoo/odoo#235356

When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated.

Steps to reproduce:
-------------------
* Create a product A with a bom of type kit
* Add a product "comp" in the bom (don't give it a description)
* Create a sales order with the product A and confirm it
* Go on the delivery and create a delivery slip
-> Issue, the name of the product "comp" appears twice.

Observation:
-------------
The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name:
https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301

In _compute_description_picking, information about the bom will be added :
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236

This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML:
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85
However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name.

opw-5265906

Forward-Port-Of: odoo/odoo#236948

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#241744
Forward-Port-Of: odoo/odoo#241060

**Issue 1:**

Steps to reproduce:
- Insert a icon in an empty paragraph.
- Remove the inserted icon.
- The paragraph becomes unreachable.

Cause:
- When a paragraph contains only an icon, removing that icon during the delete process does not trigger `fillEmpty`. As a result, the paragraph ends up with no content, leaving it empty and unreachable.

Solution:
- During the delete process, after the icon is removed, call the `fillEmpty` method. This ensures that if the block becomes empty, a `<br>` is inserted inside the paragraph, keeping it accessible.


**Issue 2:**

Steps to reproduce

- Insert an icon in an empty paragraph.
- Place the cursor before the icon.
- Press Enter.
- Nothing happens.

Cause
- When the cursor is placed before a `contenteditable=false` element, `getDeepRange` sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context.

Solution

- Instead of setting the selection inside `getDeepRange`, set the selection after calling `getDeepRange` only if the returned range is not within a `contenteditable=false` element.

task-3540454

Forward-Port-Of: odoo/odoo#241125
Forward-Port-Of: odoo/odoo#237891

**Description of the issue this PR addresses:**
------------------------------------------------
In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the view flickered and the scroll position jumped back, preventing users from reaching the latest message.

This happened because the browser’s native scroll anchoring interfered with the scroll-to-bottom behavior when messages were reloaded.

**Current behavior before PR:**
---------------------------------
- In non-aside chatter, clicking **Jump to Present** caused flickering.
- The view jumped back instead of staying on the latest message.
- Users could not reliably reach the most recent messages.

**Desired behavior after PR is merged:**
-----------------------------------------
- Clicking **Jump to Present** in non-aside chatter scrolls directly to the
  latest message without flickering.
- The scroll position remains stable and does not jump back.
- The **Jump to Present** button works consistently.

**Task:** 5264332

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

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#241744
Forward-Port-Of: odoo/odoo#241060

**Issue 1:**

Steps to reproduce:
- Insert a icon in an empty paragraph.
- Remove the inserted icon.
- The paragraph becomes unreachable.

Cause:
- When a paragraph contains only an icon, removing that icon during the delete process does not trigger `fillEmpty`. As a result, the paragraph ends up with no content, leaving it empty and unreachable.

Solution:
- During the delete process, after the icon is removed, call the `fillEmpty` method. This ensures that if the block becomes empty, a `<br>` is inserted inside the paragraph, keeping it accessible.


**Issue 2:**

Steps to reproduce

- Insert an icon in an empty paragraph.
- Place the cursor before the icon.
- Press Enter.
- Nothing happens.

Cause
- When the cursor is placed before a `contenteditable=false` element, `getDeepRange` sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context.

Solution

- Instead of setting the selection inside `getDeepRange`, set the selection after calling `getDeepRange` only if the returned range is not within a `contenteditable=false` element.

task-3540454

Forward-Port-Of: odoo/odoo#241125
Forward-Port-Of: odoo/odoo#237891

overlook of https://github.com/odoo/odoo/pull/239717
### Before this commit:
Runbot was red on weekends, as there are no work intervals on weekends.

### After this commit:
Use Friday as a fallback on weekends. In addition, improve the test performance by mocking the total number of weeks of planning to 2 instead of 50 (before: 6s, after: 1s).

runbot-237575

---

Note: ran the test for the next 5 years, and it works :+1: 
```diff
diff --git a/addons/mrp/tests/test_bom.py b/addons/mrp/tests/test_bom.py
index 7acf19e89add..bfadc8e487c1 100644
--- a/addons/mrp/tests/test_bom.py
+++ b/addons/mrp/tests/test_bom.py
@@ -13,6 +13,7 @@ from odoo.tests.common import HttpCase, tagged, freeze_time
 from odoo.tools import float_compare, float_round, float_repr
 
 
+@tagged("-at_install", "post_install")
 @freeze_time(fields.Date.today())
 class TestBoM(TestMrpCommon):
 
@@ -963,6 +964,16 @@ class TestBoM(TestMrpCommon):
             self.assertEqual(report_values['lines']['operations_time'], 15.0)
             self.assertEqual(report_values['lines']['producible_qty'], 2)
 
+    def test_bom_report_planning_with_producible_qty_loop(self):
+        from datetime import date  # noqa: PLC0415
+        start, stop = date.today(), date.fromisoformat("2031-01-01")
+        with freeze_time(start) as frozen_date:
+            for i in range((stop - start).days):
+                print("date:", str(date.today()))
+                with self.subTest(str(date.today())):
+                    self.test_bom_report_planning_with_producible_qty()
+                    frozen_date.tick(timedelta(days=1))
+
     def test_21_bom_report_variant(self):
         """ Test a sub BoM process with multiple variants.
         BOM 1:
```

Forward-Port-Of: odoo/odoo#241582

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#241744
Forward-Port-Of: odoo/odoo#241060

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

**Issue 1:**

Steps to reproduce:
- Insert a icon in an empty paragraph.
- Remove the inserted icon.
- The paragraph becomes unreachable.

Cause:
- When a paragraph contains only an icon, removing that icon during the delete process does not trigger `fillEmpty`. As a result, the paragraph ends up with no content, leaving it empty and unreachable.

Solution:
- During the delete process, after the icon is removed, call the `fillEmpty` method. This ensures that if the block becomes empty, a `<br>` is inserted inside the paragraph, keeping it accessible.


**Issue 2:**

Steps to reproduce

- Insert an icon in an empty paragraph.
- Place the cursor before the icon.
- Press Enter.
- Nothing happens.

Cause
- When the cursor is placed before a `contenteditable=false` element, `getDeepRange` sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context.

Solution

- Instead of setting the selection inside `getDeepRange`, set the selection after calling `getDeepRange` only if the returned range is not within a `contenteditable=false` element.

task-3540454

Forward-Port-Of: odoo/odoo#241125
Forward-Port-Of: odoo/odoo#237891

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

overlook of https://github.com/odoo/odoo/pull/239717
### Before this commit:
Runbot was red on weekends, as there are no work intervals on weekends.

### After this commit:
Use Friday as a fallback on weekends. In addition, improve the test performance by mocking the total number of weeks of planning to 2 instead of 50 (before: 6s, after: 1s).

runbot-237575

---

Note: ran the test for the next 5 years, and it works :+1: 
```diff
diff --git a/addons/mrp/tests/test_bom.py b/addons/mrp/tests/test_bom.py
index 7acf19e89add..bfadc8e487c1 100644
--- a/addons/mrp/tests/test_bom.py
+++ b/addons/mrp/tests/test_bom.py
@@ -13,6 +13,7 @@ from odoo.tests.common import HttpCase, tagged, freeze_time
 from odoo.tools import float_compare, float_round, float_repr
 
 
+@tagged("-at_install", "post_install")
 @freeze_time(fields.Date.today())
 class TestBoM(TestMrpCommon):
 
@@ -963,6 +964,16 @@ class TestBoM(TestMrpCommon):
             self.assertEqual(report_values['lines']['operations_time'], 15.0)
             self.assertEqual(report_values['lines']['producible_qty'], 2)
 
+    def test_bom_report_planning_with_producible_qty_loop(self):
+        from datetime import date  # noqa: PLC0415
+        start, stop = date.today(), date.fromisoformat("2031-01-01")
+        with freeze_time(start) as frozen_date:
+            for i in range((stop - start).days):
+                print("date:", str(date.today()))
+                with self.subTest(str(date.today())):
+                    self.test_bom_report_planning_with_producible_qty()
+                    frozen_date.tick(timedelta(days=1))
+
     def test_21_bom_report_variant(self):
         """ Test a sub BoM process with multiple variants.
         BOM 1:
```

Forward-Port-Of: odoo/odoo#241582

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

Currently, in a continental perpetual setting for the stock valuation, the inventory valuation lines are not created when closing the session if the orders when not invoiced.

Steps to reproduce:
-------------------
* Using My Belgian Company
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Any cost method, AVCO for example
  * Set up valuation account and journal
* Create a product
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing method, AVCO for example
  * Set inventory valuation to perpetual
* Open pos session
* Make an order for the product, put partner, invoice it
* Close session, go to session journal items
> Observation: Valuation lines are present
* Open pos session
* Make an order for the product, no partner, no invoice
* Close session, go to session journal items
> Observation: Valuation lines are missing.

Why the fix:
------------
When the company is set with perpetual inventory valuation, in the context of the point of sale, there should not be any difference between anglo saxon and continental accounting.

When we check the same flow with anglo-saxon, there is no difference for the creation of the inventory valuation move line whether we invoice the order or not. Inventory valuation lines are always present.

Valuation entries are created in `_create_stock_valuation_lines()` if information is available regarding `stock_valuation`. https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L1258-L1273

The information for `stock_valuation` is supposed to be computed in `_accumulate_amount()`.

However this is currently only computed when we have the anglo saxon accounting:
https://github.com/odoo/odoo/blob/51f1982367809581530e4d126ed515c0df6c4daa/addons/point_of_sale/models/pos_session.py#L953

Instead we will now only check if the company is valuating the inventory in real time.

We also apply the same fix on paid orders we want to invoice afterwards.

opw-5167946

Forward-Port-Of: odoo/odoo#240176

When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it.

Steps to reproduce:
1. Install a European localization (ex: l10n_at)
2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT.
3. Create a valid foreign customer. (within the EU)
4. Create and send an invoice for this customer.
5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position.

This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML.

This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it.

opw-5182837

Forward-Port-Of: odoo/odoo#241436
Forward-Port-Of: odoo/odoo#236692

When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated.

Steps to reproduce:
-------------------
* Create a product A with a bom of type kit
* Add a product "comp" in the bom (don't give it a description)
* Create a sales order with the product A and confirm it
* Go on the delivery and create a delivery slip
-> Issue, the name of the product "comp" appears twice.

Observation:
-------------
The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name:
https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301

In _compute_description_picking, information about the bom will be added :
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236

This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML:
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85
However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name.

opw-5265906

Forward-Port-Of: odoo/odoo#236948

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#241744
Forward-Port-Of: odoo/odoo#241060

When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it.

Steps to reproduce:
1. Install a European localization (ex: l10n_at)
2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT.
3. Create a valid foreign customer. (within the EU)
4. Create and send an invoice for this customer.
5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position.

This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML.

This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it.

opw-5182837

Forward-Port-Of: odoo/odoo#241436
Forward-Port-Of: odoo/odoo#236692

When creating a delivery slip, if the product sold is a kit and it's component doesn't have a description, the name will be repeated.

Steps to reproduce:
-------------------
* Create a product A with a bom of type kit
* Add a product "comp" in the bom (don't give it a description)
* Create a sales order with the product A and confirm it
* Go on the delivery and create a delivery slip
-> Issue, the name of the product "comp" appears twice.

Observation:
-------------
The name is added in description_picking field, since it is considered that the fallback for the description for outgoing deliveries should be display_name:
https://github.com/odoo/odoo/blob/584f94e3246b6b59641bf83d4e707f2e872bc1e8/addons/stock/models/product.py#L293-L301

In _compute_description_picking, information about the bom will be added :
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/mrp/models/stock_move.py#L235-L236

This causes the issue because the filter to prevent repeating the name on the delivery slip is implemented directly in the XML:
https://github.com/odoo/odoo/blob/08c5fbbb5bc44c4810cd07188b29090c3060e14f/addons/stock/report/report_deliveryslip.xml#L83-L85
However, since we have added elements to the description (the bom information), this filter will not be applied, leading to the repeated name.

opw-5265906

Forward-Port-Of: odoo/odoo#236948

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#241744
Forward-Port-Of: odoo/odoo#241060

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#239008

This PR fixes issues after the revamp in PR https://github.com/odoo/odoo/pull/138670

The first fix was to move some of the SCSS in the `calendar` module into the `web` module. Because some modules such as `planning` don't require `calendar`, if it isn't installed, `planning` would not have the styling and colors of the events. By moving things around, this makes for a major part of the diff in this PR.

Some event styles were also not being applied in the Year view. This is because we moved all the styles for event styling inside the `.fc-event` selector, but the Year view doesn't have this class on its events, instead we changed it to the `o_event` class which is in every view.

This PR includes other improvements such as making the events' colors stand out more in Year view, making "mandatory days" more readable, and improving the calendar header's layout. 

Entreprise PR https://github.com/odoo/enterprise/pull/50251

task-3575827

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