#### Issue:
- After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency.

#### Step to reproduce:
1. Install l10n_pe_edi
2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN).
3. Create a downpayment invoice, could be any percentage.
4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567.
5. Confirm this invoice.
6. Now go back to the sale order and deliver your product.
7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose).
8. Confirm the invoice.

#### Current behavior:
- Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN>

#### Expected behavior:
- The currency displayed should match the invoice currency

#### Cause of the issue:
- the currency of the company emitting the invoice was used instead of the currency of the invoice.

opw-5061019

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code to the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this.

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Enterprise PR:
https://github.com/odoo/enterprise/pull/92310
Ticket:
opw-4755357

Forward-Port-Of: odoo/odoo#228375
Forward-Port-Of: odoo/odoo#223517

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
 
    def _can_be_invoiced_alone(self):
        """ Whether a given line is meaningful to invoice alone.

        It is generally meaningless/confusing or even wrong to invoice some specific SOlines
        (delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
        in the SO.
        """
        self.ensure_one()
        return self.product_id.id != self.company_id.sale_discount_product_id.id

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_reward_line

We just have to be careful not to accidentally include delivery fees because of

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_delivery

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357

Forward-Port-Of: odoo/enterprise#95435
Forward-Port-Of: odoo/enterprise#92310

Manual forward port of https://github.com/odoo/enterprise/pull/90878

**Problem:**
When scanning a package with a different UoM than the barcode line, the
conversion is not made.

**Steps to reproduce:**
- Enable the "Packages" setting;
- Create a new storable product and set kg as its UoM;
- In the inventory tab, add "g" in the packagings
- Click on the on hand smart button and select update quantity
- Add a new line;
- In the package column create a new package;
- Set a quantity of 10 kg;
- Create a delivery and select your product;
- Set a demand on 10000 and select g as the UoM;
- Mark as todo;
- Open the delivery in the Barcode app;
- Scan the package.

**Current behavior:**
The quantity on the line is now 10 / 10000 g

**Expected behavior:**
It should be 10000 / 10000 g

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505
remaining_qty is expressed in the uom of the quant so it will be 10 but
qty_needed is expressed in the uom of the line is it will be 10000.
qty_used beeing the minimum of those two it will be 10.

**Fix:**
To define how much quantity to take from the package, we convert the
line's quantity by using the package's UoM.
Then, when we add this quantity to the line's quantity, we re-convert it
by using the line's UoM.

opw-4860064

Forward-Port-Of: odoo/enterprise#93693

Since [1], the page dependencies algorithm was updated, requiring
adjustments to the tour logic. Additionally, following [2], the
"Add new content" button was changed from an `<a>` tag to a `<button>`,
which also needed to be reflected in the tour.

Furthermore (see [3]), removing a page from the menu could silently fail
when the page URL was changed in the same save because the wizard only
looked up menus by the current URL. Resolve menus by page_id (fallback
to URL) in both compute and inverse, and unlink accordingly, ensuring
"In Menu" toggles work reliably across URL changes.

Also, since [4], the "New Page" dialog cached the templates list, so
pages newly marked as "Is a Template" didn't appear until a reload.
Fetch templates without client-side caching so the Custom tab reflects
changes immediately. This fixes the tour steps for "Verify is not in
menu" and "Verify template Cool Page exists."

Steps to reproduce:

A. "In Menu" toggle fails when URL also changes (unlink by URL only)

- Website > Go to any page (e.g., /cool-page).
- Click Edit > Page (properties).
- Change URL from /cool-page to /cool-page-2.
- In the same dialog, disable "In Menu" (It should be automatic).
- Click Save & Close.
- Bug (before): The corresponding menu item is not removed because the
  unlink resolves only by the old/current URL.

  Now: Menus are resolved and unlinked by page_id (fallback to URL), so
  the menu entry is correctly removed.

B. "New Page" > Custom templates list becomes stale (client cache)

- Create a normal website page (not a template).
- Open Page (properties) and enable "Is a Template". Save.
- Without reloading the site, click New (Add new content) > New Page.
- Open the Custom tab.
- Bug (before): The page you just turned into a template doesn't appear
  because the dialog used a cached list.

  Now: The dialog fetches templates without client caching, so the new
  template appears immediately.

[1]: https://github.com/odoo/odoo/commit/cd4b0c91c1cf60ff72e91cf0544cb255ee5aff3f
[2]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
[3]: https://github.com/odoo/odoo/commit/d6c8177824be3
[4]: https://github.com/odoo/odoo/commit/b7fe6e6704fad
runbot-224020

_______________________________________
## Short functional explanation of the error
Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens.

## Reproduction Steps
1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2.
2. Select both companies. In planning, create a slot for company_2 and publish it.
3. Log in as the user you created. Make sure that the current company is company_1. Select company_2.
4. Go to planning and try to assign yourself to the slot you've just created as an admin

### Expected behavior
Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected).

### Unexpected behavior
Nothing happens

## Origin of the issue
When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee,
self.env.user.employee_id is set at False

_________________________________________
opw-4963674

---

Forward-Port-Of: odoo/enterprise#91616

# Issue:
In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error.

# Cause
This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists.

# Fix
This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field.

# Steps to reproduce
- Install sale_project and accountant modules
- Check "Analytic Accounting" in the Accounting settings
- Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic")
- Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order.
- Delete the analytic.account "Test AC"
- Go back on "Test SO", try to change the field "Project" - a Missing error is thrown

---

Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore.

Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated.

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

Forward-Port-Of: odoo/odoo#224895

Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed by `DeletePlugin`, the interaction is not destroyed, and a recurrent interval keeps expiring every second triggering multiple errors.

This commit introduces the following changes:
1. `EditInteractionPlugin.refreshInteractions`, which is called on normalization, now checks for every interaction and destroyes the ones linked to a disconnected DOM element.
2. `websiteEditService.refresh` now checks if the target element is disconnected, and in this case stops the interaction.
3. `Countdown` now uses the `waitForTimeout` function, which does not execute any callback if the interation has been destroyed.

How to reproduce the problem with `s_countdown`:
1. Insert the snippet `s_text_block`
2. Insert the snippet `s_countdown` in the middle of the text
3. Place the cursor after the countdown
4. Press "backspace" until the countdown is deleted
5. The error appears

(Alternatively, place the cursor before the countdown and press delete, or select a portion of text including the countdown and press backspace).

task-4367641

**Current Behavior:**
With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.

**Expected Behavior:**
All rentals for the same SN should appear in the rental schedule.

**Steps to Reproduce:**
- Go to Rental > Configuration > Settings and enable Rental Transfers
- Create a new product that is storable, can be rented, and is tracked by unique serial number
- Receive 25 of the product with assigned serial numbers
- Create and confirm a rental order for 25 units of product
- Validate both OUT and IN transfers
- Duplicate the rental order and confirm it
- Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25

**Cause of the Issue:**
Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental.

This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule.

**Fix:**
Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times.

opw-5003247

Forward-Port-Of: odoo/enterprise#95315

**Current Behavior:**
With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.

**Expected Behavior:**
All rentals for the same SN should appear in the rental schedule.

**Steps to Reproduce:**
- Go to Rental > Configuration > Settings and enable Rental Transfers
- Create a new product that is storable, can be rented, and is tracked by unique serial number
- Receive 25 of the product with assigned serial numbers
- Create and confirm a rental order for 25 units of product
- Validate both OUT and IN transfers
- Duplicate the rental order and confirm it
- Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25

**Cause of the Issue:**
Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental.

This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule.

**Fix:**
Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times.

opw-5003247

Forward-Port-Of: odoo/enterprise#95315

**Steps to Reproduce:**
1. Install `l10n_mx_edi_extended` module without demo data.
2.  Set company's country to "Mexico" and switch Fiscal Localization.
3. Deactivate USD currency.
4. Configure CFDI Certificate and activate Testing mode in PAC.
5. Create a new product with "UNSPSC Category".
6. Create an invoice with CFDI to the public and "Definitive" in External Trade.
7. Confirm and send the invoice.

**Sample certificate:**
Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link 
Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link 
Private key password: 12345678a

**Error:**
`ValueError - Expected singleton: res.currency()`

**Cause:**
When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation.

**Fix:**
This commit handles the case when USD currency is deactivated.

sentry-6860601127

Forward-Port-Of: odoo/enterprise#94179

This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures.

- **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown name, it previously resulted in an empty response, causing the conversation to stall. This change ensures that a proper error message is now returned to the LLM for the invalid tool call. This allows the LLM to process the failure and continue the conversation.

- **Failing on Limits**: The query processing loop in `_request_llm` has limits for both successive API calls and the number of tool calls per request. Previously, these limits would be reached silently.

  - **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached without the LLM providing a final answer, a `ValueError` is now raised. This prevents silent failures and makes it clear to the calling code that the request could not be completed.

  - **Tool Call Limit**: If the number of tool calls in a single response exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now provided with a result stating that the limit was reached. This gives the LLM the opportunity to try the unprocessed tool calls again in a subsequent turn.

- **Ignore Explanatory Text**: The text that LLMs often include alongside a tool call request (the "thinking" text) is now ignored to provide a cleaner and more concise final response to the user.

Forward-Port-Of: odoo/enterprise#94413

This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.

- **[REF] iot: extract printer select into separate function**
  Before this commit, the printer selection wizard was tightly coupled to
  the IoT report handler, and the call to send to the printer was
  duplicated in the wizard and the handler.
  
  After this commit, the printer selection wizard is contained in a
  function that will always return the selected printers directly to the
  caller, whether the dialog needs to be opened or not. The wizard is
  simplified as a result and the print call always occurs in the handler.
  
  This refactoring will allow other places to use the printer selection
  wizard, namely for invoice printing.


- **[FIX] pos_iot: print invoices via IoT**
    In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
  bypass the `ir.actions.report` model, instead working directly via an
  action on the invoice model. A side effect of this is that it broke
  printing invoices via the IoT, as it relies on the report printing
  action to function.
  
  To fix this, this commit introduces an override in `pos_iot` for the
  `account_move_service`, which will print the invoice PDF via the IoT
  instead of downloading it directly (if a printer is associated with the
  report).
  
  
task-5109814

Forward-Port-Of: odoo/enterprise#95689
Forward-Port-Of: odoo/enterprise#95586

#### Issue:
- After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency.

#### Step to reproduce:
1. Install l10n_pe_edi
2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN).
3. Create a downpayment invoice, could be any percentage.
4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567.
5. Confirm this invoice.
6. Now go back to the sale order and deliver your product.
7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose).
8. Confirm the invoice.

#### Current behavior:
- Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN>

#### Expected behavior:
- The currency displayed should match the invoice currency

#### Cause of the issue:
- the currency of the company emitting the invoice was used instead of the currency of the invoice.

opw-5061019

Forward-Port-Of: odoo/enterprise#93885

This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.

- **[REF] iot: extract printer select into separate function**
  Before this commit, the printer selection wizard was tightly coupled to
  the IoT report handler, and the call to send to the printer was
  duplicated in the wizard and the handler.
  
  After this commit, the printer selection wizard is contained in a
  function that will always return the selected printers directly to the
  caller, whether the dialog needs to be opened or not. The wizard is
  simplified as a result and the print call always occurs in the handler.
  
  This refactoring will allow other places to use the printer selection
  wizard, namely for invoice printing.


- **[FIX] pos_iot: print invoices via IoT**
    In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
  bypass the `ir.actions.report` model, instead working directly via an
  action on the invoice model. A side effect of this is that it broke
  printing invoices via the IoT, as it relies on the report printing
  action to function.
  
  To fix this, this commit introduces an override in `pos_iot` for the
  `account_move_service`, which will print the invoice PDF via the IoT
  instead of downloading it directly (if a printer is associated with the
  report).
  
  
task-5109814

Forward-Port-Of: odoo/enterprise#95689
Forward-Port-Of: odoo/enterprise#95586

## Version
saas-18.4+

## Issue
*Use mobile device or mobile view*
- Configure Paypal as a Payment Provider;
- Go to the shop and buy an article;
- Move to checkout and select PayPal;
- No PayPal button is displayed.

## Cause
In saas-18.4, a refactoring of the checkout layout (7a564237579603bcaef46efd6ffaaaffefb54b11) introduced the `o_mobile_summary` block which results in the full payment form being duplicated in the DOM:
- One copy for desktop:
  - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3524-L3529
- One copy inside `.o_mobile_summary` for mobile:
  - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3557-L3560

This causes the `payment.submit_button` template (and its extension by PayPal) to be injected twice.
As a result, the DOM ends up with two elements sharing the same IDs (`o_paypal_button_container`) which breaks PayPal’s SDK rendering logic.

## Fix
JavaScript logic based on cca908741c7fdd701a4539e5d43c71248b73b14f has been added to detect and rename the duplicated DOM structure:
The PayPal button can be rendered everywhere based on unique IDs.

opw-4942831

Forward-Port-Of: odoo/odoo#220516

# Issue:
In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error.

# Cause
This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists.

# Fix
This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field.

# Steps to reproduce
- Install sale_project and accountant modules
- Check "Analytic Accounting" in the Accounting settings
- Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic")
- Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order.
- Delete the analytic.account "Test AC"
- Go back on "Test SO", try to change the field "Project" - a Missing error is thrown

---

Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore.

Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated.

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

Forward-Port-Of: odoo/odoo#224895

### Steps to reproduce:

- In the settings website > Shop:
    - Disable `Out-of-Stock: Continue Selling`.
    - Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
    - COMP, put 1 unit in stock.
    - KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product

### Cause of the issue:

The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.

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

Forward-Port-Of: odoo/odoo#228881
Forward-Port-Of: odoo/odoo#222945

### Steps to reproduce:

- Create and confirm a delivery with 2 moves:
    - 1 x product 1
    - 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.

#### Cause of the issue:

Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.

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

Forward-Port-Of: odoo/odoo#228490
Forward-Port-Of: odoo/odoo#227995

**Current Behavior:**
With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.

**Expected Behavior:**
All rentals for the same SN should appear in the rental schedule.

**Steps to Reproduce:**
- Go to Rental > Configuration > Settings and enable Rental Transfers
- Create a new product that is storable, can be rented, and is tracked by unique serial number
- Receive 25 of the product with assigned serial numbers
- Create and confirm a rental order for 25 units of product
- Validate both OUT and IN transfers
- Duplicate the rental order and confirm it
- Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25

**Cause of the Issue:**
Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental.

This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule.

**Fix:**
Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times.

opw-5003247

Forward-Port-Of: odoo/enterprise#95315

Currently, an error occurs when user editing the budget report items.

Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view):
 - Install the `Accounting` module.
 - Go to `Profit and Loss` > `Budget` and `create a budget`.
 - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line.
 - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again.
 - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more.

`TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'`

This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`.

This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained..

[1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49

[2]-
https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79

[3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72

[4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61

sentry-6883207225

### Issue 1:

Summary:
When a user adds a comment inside a baseContainer element, the comment
beacons created during the comment insertion can be discarded during
the document normalization step.

How to reproduce:
- Open an article in Knowledge.
- Select text and change the block style from "Paragraph" to "Normal"
  using the powerbox.
- Add a comment on the selected text using the powerbox.
- Write a message in the comment thread.
- Save and reload the article.

Issue:
- The comment beacons disappears from the editor and the user can't see it
  anymore.

Resolution:
When the editor is initialized, `div` are not yet categorized as
paragraph related elements. The `comments_plugin` logic to identify valid
positions for comments beacons should take that into account and allow elements
which are candidates to be a paragraph related element.

### Issue 2:

Summary:
There was an issue where comments were not displayed when switching from a
locked article to another (read-only).

How to reproduce:
- Create two articles and add a comment on each.
- Lock both articles (so that they are effectively read-only).
- Switch from one article to the other.

Issue:
- Comments are not displayed to the user.

Resolution:
When switching between read-only articles, `KnowledgeHtmlViewer` is
not fully reloaded and continues using the same `CommentBeaconManager`
instance for the newly opened article. As a result, comment beacons
are not displayed when switching article. The simplest solution to this issue is
to re-instantiate a new `CommentBeaconManager` whenever the HTML value changes
to ensure comments are correctly displayed.

### Issue 3:

There is an issue in the logic of `computeVerticalDimensions` to display
comments. If the `top` value of a thread in the article is `0`, it will be
filtered out and not displayed because `top` was used as a boolean value.
Instead, it should properly consider `top` as a finite number to display the
comment or not.

Note:
This issue is not easily reproducible because there are few configuration where
a comment would have a top value equal to 0.

### Issue 4:

There is a crash when inserting a knowledge comment in a `/code` block:
In this previous [task], insertion in `pre` elements was filtered to prevent
non-phrasing content from being inserted (as it is invalid per the html
specification). To prevent a crash, knowledge comments will be disabled in
`<pre>` elements, as they rely on `anchor` elements for the comment position in
the article body.

[task]: 216e9eb

task-4984152

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

calendar.resource has a method, `_attendance_interval_batch`, that
can cause a bug if someone is trying to book an appointment with a 
staff with flexible hours.There's an elif block that you enter if the 
calendar.resource has flexible hours. In that block, we determine 
how much time is allocated for the appointment. For instance, 1 hour
 if the appointment is meant to be 1 hour long and the staff still has at
least 1 hour left to work that week. Then, a work interval gets centered
around 12 noon. 12 noon is hard-coded in. If there's one hour 
allocated for the appointment, that work interval will always be from
11:30 to 12:30, no matter what appointment time slot was selected. So,
unless by lucky coincidence, the person selected an 11:30 appointment,
they won't be able to schedule an appointment at all.

The hard coding with 12 noon was implemented 4 months ago. It's 
meant to "solve issues in various apps such as work entry generation, 
attendance overtime calculation and time off calculations." Since the 
hard coding around 12 noon serves useful purposes, I didn't remove it.
Instead, I added a flag `booking_apt=True` to signal that an
appointment is currently being booking. And I added conditional logic
so the work interval won't be centered around noon iff an appointment
is being booked.

I introduced the flag in the appointment.type method 
`is_appointment_slot_valid`. I originally tried introducing it in a 
function further up the call stack, but that lead to the flag being true
when the current process was getting all possible appointment slots,
and it broke that process. It seemed clear from 
`_is_appointment_slot_valid`'s title and docstring that its sole purpose
is to check whether an appointment being booked is at a valid time.

Solves ticket 5094795

Description of the issue/feature this PR addresses:
It solves ticket 5094795.

Current behavior before PR:
If you try to book an appointment with a staff with a flexible schedule,
and the appointment type's `work_hours_activate` field is true, you'll
get a 404 page missing error. (See ticket.)

Desired behavior after PR is merged:
You will not get a 404 page missing error anymore, and will be able
to successfully book an appointment.

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

### Steps to reproduce:

- In the setting enable lots and serial numbers
- Create a product tracked by LOT
- Create and confirm a receipt for 1 unit of that product
- Create a new lot: LOT001 from the move in the picking form
- Click Validate
#### > Invalid operation: you need to provide Lot/Serial numbers of the product

### Cause of the issue:

The set method of the `lot_ids` field of the `stock.move` model does nothing for product tracked by lots:
https://github.com/odoo/odoo/blob/7a8f9b7fe4dded4cfa140103d51b52e08149cadb/addons/stock/models/stock_move.py#L575-L579 In particular, while the lot appears on the move in the view, none of the move lines refer to it and the transfer can not be validated as indeed no lots are provided to these reservations.

### Fix:

The feature of writing `lot_ids` for lots has been introduced in https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e https://github.com/odoo/odoo/blob/1c52e2e9e8e00a19e2db00bf70d658496f9a0f29/addons/stock/models/stock_move.py#L596-L600 But this major refactoring can of course not be backported in 18.0. Therefore, it was decided put the field in readonly when its set method is inefficient.

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

**Current Behavior:**
With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.

**Expected Behavior:**
All rentals for the same SN should appear in the rental schedule.

**Steps to Reproduce:**
- Go to Rental > Configuration > Settings and enable Rental Transfers
- Create a new product that is storable, can be rented, and is tracked by unique serial number
- Receive 25 of the product with assigned serial numbers
- Create and confirm a rental order for 25 units of product
- Validate both OUT and IN transfers
- Duplicate the rental order and confirm it
- Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25

**Cause of the Issue:**
Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental.

This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule.

**Fix:**
Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times.

opw-5003247

Forward-Port-Of: odoo/enterprise#95315

## Issue:
The Intrastat report currently uses the company region from settings instead of the warehouse region
even when the warehouse has a region defined.

## Cause:
The original 'stock.intrastat.report.handler' model defines a `_name` and implements
`_fill_missing_values()` to override the company region with the warehouse region.
However, this model does not appear to be called directly in the report and,
in this particular case, its `_fill_missing_values()` method is not executed.

For aggregated header lines, `_fill_missing_values()` cannot restore the region even
if it were called, because these lines do not contain `invoice_ids` or `move_ids`.
Without such identifiers, the warehouse cannot be determined post-query, so the company region was always used.
https://github.com/odoo/enterprise/blob/03d9353d85ed80c6e44fd231e5340d2378af8c81/stock_intrastat/models/account_intrastat_report.py#L11-L37

## Fix:
Introduce a new model that _inherits from 'account.intrastat.report.handler' without a _name.
The _fill_missing_values() method is kept in the model to preserve potential future usage,
but in this case, the query changes already ensure that the region in the report is correct.

## Steps to reproduce:
Note: Belgium localization is used here because it provides pre-defined regions that are easy to modify in the Settings App.
- Install l10n_be_intrastat + sale_management + stock
- Select a Belgium Company
- In Settings, set Company Intrastat Region to "1 Flemish region"
- Create a Product (Commodity Code: 01012100..., Weight: 10, Country of Origin: Belgium)
- Set Warehouse > Intrastat region to "3 Brussels region"
- Create and confirm a Sale Order for a French Customer (Tax ID: FR23334175221, Country: France)
- Create and confirm the invoice
- Open Accounting > Reporting > Intrastat Report
- Select the Report: Intrastat (Goods) and This Month as date
- Before the fix, the Region is 1 and it's the same for the details lines

opw-5011272