Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation.

This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance.

This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase.

A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here.

#### speedup

In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s

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

Forward-Port-Of: odoo/odoo#231206

… number

Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts.

This commit introduces overrides for SE-specific account types:

_get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML.

_skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file.

This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries.

Backport of https://github.com/odoo/enterprise/commit/0534491bcd7eed7d246bea85d6ac217a80af815b

Forward-Port-Of: odoo/enterprise#97330

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

Forward-Port-Of: odoo/enterprise#89808

## Issue:
In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised

## Cause:
When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS

## Steps to reproduce:
- Install an app like stock_sms to create blocking entries
- Create and confirm a Delivery
- Choose Send SMS
- Enable developer mode
- Search for the technical settings SMS
- Retry sending the automatically sent SMS

opw-4904157

Forward-Port-Of: odoo/odoo#230733

To reproduce:
1. Ensure Analytic Accounting is activated in the accounting settings
2. Uncheck the option Auto-Check on Post in the Vendor Bills journal
3. Create a vendor bill and set analytic accounts in at least one line
4. Post the vendor bill
5. Go to Accounting > Analytic Items
6. No analytic item was created for the vendor bill

In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines.

Cause:
In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted.

Solution:
The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals.

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

Forward-Port-Of: odoo/odoo#231874

**Problem:**
When confirming the invoice of an order delivered via dropship for some kit bom 
product with fifo/avco comp, if the price was manually set on the purchase order, 
the invoice lines generated for the cogs are inaccurate

**Steps to reproduce:**
- In settings enable dropshipping, automatic account and anglosaxon accounting
- Create a kit product with one component.
- Set the route as Dropship for the component.
- add a vendor in the purchase tab of the component.
- set the cost of the component at 2
- Set the product category to AVCO (Automated) for the component and the product.
- Create and confirm a sales order with a quantity of 2 for the product.
- On the purchase order set the unit price at 20 for the component.
- Confirm the purchase order, then validate the delivery and create the customer invoice.
- Confirm the invoice

**Current behavior:**
In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 22

**Expected behavior:**
The value should be 40, in accordance with the purchase order

**Cause of the issue:**
In the mrp_account override of _compute_average_price,
the stock move has no bom because it was generated from the purchase order, 
so this condition will be true
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L67
This is not a problem, however the problem comes from the fact that
move.product_id is already equal to qty_to_invoice \*component_quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L73
Multiplying it a second time by qty_to_invoice is an error.
For instance in our steps, qty_to_invoice is 2, compenent_quantity is 1 
and move.product_qty is 2.
So when calling _compute_average_price for the comp, we call it with a 
qty_to_invoice parameter of 4 instead of 2.
As a result, because the candidates svls only have a quantity of 2, there will 
be we a missing quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/stock_account/models/product.py#L927-L934
So the result will be the average between the quantity on the purchase order (20)
and the standard price (2).
Which is why the account line has a value of 22 (2*11)

opw-4985440

Forward-Port-Of: odoo/odoo#229956

Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation.

This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance.

This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase.

A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here.

#### speedup

In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s

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

Forward-Port-Of: odoo/odoo#231206

To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).

1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra>  (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact> 
        *Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999

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

Forward-Port-Of: odoo/odoo#221073

1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate". 
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
    * Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate". 

3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes. 
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.

Task latam side: 1330
Task Adhoc side: 52999

Forward-Port-Of: odoo/enterprise#91392

… number

Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts.

This commit introduces overrides for SE-specific account types:

_get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML.

_skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file.

This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries.

Backport of https://github.com/odoo/enterprise/commit/0534491bcd7eed7d246bea85d6ac217a80af815b

Forward-Port-Of: odoo/enterprise#97330

**Steps to reproduce:**
1. Install the *Fleet* and `accounting` modules.
2. Create a new purchase tax.
3. Configure the tax with a 50% repartition line for an `600000 expense` account and a 50% repartition line for a `101000 current asset` account for both income and refund.
4. Create a vendor bill with two product lines, each having a different vehicle assigned with the newly created tax in both lines.
5. Check the *Tax Report*(account>tax), including the date of this vendor bill.

**Observed behavior:**
* Tax lines linked to the current asset account are merged.
* Tax lines linked to the expense account remain separate (since `vehicle_id` is set on the `account.move.line`).
* This mismatch triggers an error in the tax report.

**Root cause:**
The tax details query does not account for the `vehicle_id` field when matching tax lines with base lines. As a result, tax lines are incorrectly merged across different vehicles.

**Solution:**
Override `_get_extra_query_base_tax_line_mapping` to include the `vehicle_id` in the matching condition, ensuring tax lines are only paired with base lines having the same `vehicle_id`. This prevents incorrect merging and resolves the report error.

opw-5013757

Forward-Port-Of: odoo/odoo#228422

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

Forward-Port-Of: odoo/enterprise#89808

## Issue:
In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised

## Cause:
When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS

## Steps to reproduce:
- Install an app like stock_sms to create blocking entries
- Create and confirm a Delivery
- Choose Send SMS
- Enable developer mode
- Search for the technical settings SMS
- Retry sending the automatically sent SMS

opw-4904157

Forward-Port-Of: odoo/odoo#230733

In [^1], a new feature was introduced to allow users to synchronize their eCommerce with Google Merchant Center and increase their product visibility, keep stock status updated, and improve product listings.

However, the initial implementation attempted to include shipping information in the feed, which required computing rates for every product, carrier, and country. This quickly became infeasible due to performance constraints and third-party carrier rate limits, forcing us to disable the feature [^2].

This commit reintroduces the GMC feed without shipping details, making it lightweight and reliable. To ensure scalability, we also (i) enforce a limit of 5000 products per feed, and (ii) introduce a caching mechanism to avoid recomputing expensive product data (e.g., prices) for subsequent requests.

~~task-5049357~~
task-5144256

See also:
- https://github.com/odoo/upgrade/pull/8605

[^1]: https://github.com/odoo/odoo/pull/186976
[^2]: https://github.com/odoo/odoo/pull/224649

To reproduce:
1. Ensure Analytic Accounting is activated in the accounting settings
2. Uncheck the option Auto-Check on Post in the Vendor Bills journal
3. Create a vendor bill and set analytic accounts in at least one line
4. Post the vendor bill
5. Go to Accounting > Analytic Items
6. No analytic item was created for the vendor bill

In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines.

Cause:
In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted.

Solution:
The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals.

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

Forward-Port-Of: odoo/odoo#231874

**Problem:**
When confirming the invoice of an order delivered via dropship for some kit bom 
product with fifo/avco comp, if the price was manually set on the purchase order, 
the invoice lines generated for the cogs are inaccurate

**Steps to reproduce:**
- In settings enable dropshipping, automatic account and anglosaxon accounting
- Create a kit product with one component.
- Set the route as Dropship for the component.
- add a vendor in the purchase tab of the component.
- set the cost of the component at 2
- Set the product category to AVCO (Automated) for the component and the product.
- Create and confirm a sales order with a quantity of 2 for the product.
- On the purchase order set the unit price at 20 for the component.
- Confirm the purchase order, then validate the delivery and create the customer invoice.
- Confirm the invoice

**Current behavior:**
In the journal items tab of the invoice the lines for the cogs (expenses and stock interim) have a value of 22

**Expected behavior:**
The value should be 40, in accordance with the purchase order

**Cause of the issue:**
In the mrp_account override of _compute_average_price,
the stock move has no bom because it was generated from the purchase order, 
so this condition will be true
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L67
This is not a problem, however the problem comes from the fact that
move.product_id is already equal to qty_to_invoice \*component_quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/mrp_account/models/product.py#L73
Multiplying it a second time by qty_to_invoice is an error.
For instance in our steps, qty_to_invoice is 2, compenent_quantity is 1 
and move.product_qty is 2.
So when calling _compute_average_price for the comp, we call it with a 
qty_to_invoice parameter of 4 instead of 2.
As a result, because the candidates svls only have a quantity of 2, there will 
be we a missing quantity.
https://github.com/odoo/odoo/blob/936ab5f3f120413c7af901dd6ecc414d3e3a6d78/addons/stock_account/models/product.py#L927-L934
So the result will be the average between the quantity on the purchase order (20)
and the standard price (2).
Which is why the account line has a value of 22 (2*11)

opw-4985440

Forward-Port-Of: odoo/odoo#229956

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#96814
Forward-Port-Of: odoo/enterprise#96299

1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate". 
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
    * Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate". 

3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes. 
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.

Task latam side: 1330
Task Adhoc side: 52999

Forward-Port-Of: odoo/enterprise#91392

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

Forward-Port-Of: odoo/enterprise#89808

Steps to reproduce:
-------------------------
1. Install `hr_payroll` module
2. Enable debug mode and click on Become Superuser
3. Go to All Payslips and open any payslip record
4. Click on the Export Payslip button

Observation:
-------------------------
A 404 (Page Not Found) error appears when clicking the Export Payslip button

Issue:
-------------------------
The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit
https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359
The route was never reintroduced afterward, but the Export Payslip button remained in the view.
As a result, clicking it leads to a 404 error

Solution:
-------------------------
1. Temporarily bypass the `action_export_payslip` function.
2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button

opw-5115946

Forward-Port-Of: odoo/enterprise#97361
Forward-Port-Of: odoo/enterprise#96359

To reproduce:
1. Ensure Analytic Accounting is activated in the accounting settings
2. Uncheck the option Auto-Check on Post in the Vendor Bills journal
3. Create a vendor bill and set analytic accounts in at least one line
4. Post the vendor bill
5. Go to Accounting > Analytic Items
6. No analytic item was created for the vendor bill

In some cases, such as when the vendor bill journal has `Auto-check on Post` disabled or a there is a lock date set, the analytic items are not created when posting the move, even if analytic accounts were set on the move lines.

Cause:
In #222196, a check is performed when writing an account.move.line, which unlinks analytic lines created for draft moves. However, this condition is too general, and if additional writes happen in between the analytic line creation and changing the move state to `posted`, the analytic lines are deleted.

Solution:
The unlinking on analytic lines should only be performed if `analytic_line_ids` are in vals.

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

Forward-Port-Of: odoo/odoo#231874

## Issue:
In debug mode, the administrator could not resend or cancel an SMS that was sent by the system (e.g. delivery confirmation) using the `Retry` / `Cancel` button in the Technical Settings An Access Error was raised

## Cause:
When using the `Retry` or `Cancel` button, the method `_update_sms_notifications()` is called and finds `mail.notifications` records to update However, `notifications.write()` triggers an Access Error because only the recipient of a `mail.notification` is allowed to modify it: https://github.com/odoo/odoo/blob/98610ea2a1369b84b10adb8913c5d7725a0fad67/addons/mail/security/mail_security.xml#L184-L192 This happens even when the user has the rights to resend or cancel the SMS

## Steps to reproduce:
- Install an app like stock_sms to create blocking entries
- Create and confirm a Delivery
- Choose Send SMS
- Enable developer mode
- Search for the technical settings SMS
- Retry sending the automatically sent SMS

opw-4904157

Forward-Port-Of: odoo/odoo#230733

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

Forward-Port-Of: odoo/enterprise#89808

This PR is the opportunity to fix two mistakes in the XML generation of the e-Factura : 

1. It is possible for a product to have more decimals than the currency, but the facturae always rounded according to the currency. This would sometimes lead to both rounding errors and incomplete or incorrect values on the generated XML. This commit rounds product prices according to the unit price decimal while leaving the other computed field untouched as to not disturb the correct computation elsewhere.

2. When the tax rounding was set to round_globally, the TotalTaxOutput in the XML might differ from the actual tax_amount from the invoice because of rounding errors occurring during uncessary re-computation while building the XML. While stable is not the place to change all functions related, we can isolate computed tax output and tax withheld values and transmit them without any intermediary. 

As this file was changed in 18.0 another PR was needed from 17.0: https://github.com/odoo/odoo/pull/209623 (unit price decimals) and https://github.com/odoo/odoo/pull/229017 (tax rounding issue, detected after 209623 was closed)

task-4650439

Forward-Port-Of: odoo/odoo#231424
Forward-Port-Of: odoo/odoo#229236

[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT)
    
Steps to reproduce:
1. Install `l10n_in_edi`
2. Create an invoice with a RC tax/SEZ (with LUT) tax
3. Confirm and Process for E-invoice
4. See the EDI content, The GST rate is 0%

Before this

For RC and SEZ (with LUT) the tax rate and tax amount were sent
as `0`  and  (data going wrong for SEZ/Exports) for Indian E-invoicing.

Following the fix:

1. We rename the the IGST x% (SZ/EX) -> IGST x% (EX)
2. Introducing new taxes for SEZ with LUT
3. Fiscal for Export and SEZ renamed to Export (same for LUT)
4. Introducing new fiscal for SEZ and SEZ (LUT)
5. In case of Special Economic Zone normal taxes (IGST) should be applied 
because as per the [API Doc](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#validations)
    It states -
    **However, in case of Reverse charge and Export transactions (EXPWP), Total value of Item can match with either with tax values or without tax values. That is, the total value of item can include or exclude the tax values as per the business requirements.**

So SEZ without LUT should be passed as normal IGST


For Export without LUT

Label                                               | Taxes            | credit        | debit| Tags
-------------------------------------------------------------------------------------------------------------
Product A                                       | 18% IGST S (EX)  |    100 |          | Base IGST
IGST 18%                                        |                              |       18 |          | IGST
IGST Paid on SEZ/Export Sales   |                              |             |     18| 
Creditor                                          |                              |             |   180|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 100}


For SEZ without LUT

Label     | Taxes            | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) |    100 |       | Base IGST
IGST 18%  |                  |     18 |       | IGST
Creditor  |                  |        |    118|

Invoice Total 118
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 118}


For Export/SEZ with LUT

Label     | Taxes            | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) |    100 |       | Base IGST
IGST 18%  |                  |     18 |       | IGST
IGST 18%  |                  |        |    18 | IGST
Creditor  |                  |        |    100|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0.0, 'TotItemVal': 100}


For RCM

Label                          | Taxes            | credit | debit | Tags
-------------------------------------------------------------------------------
Product A                      | 18% IGST S RC    |    100 |       | Base IGST || BASE IGST RC
IGST 18% RC                    |                  |     18 |       | IGST
IGST 18% RC                    |                  |        |     18| IGST RC
Creditor                       |                  |        |    118|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0, 'TotItemVal': 100}


task-4878805


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

Forward-Port-Of: odoo/odoo#228871
Forward-Port-Of: odoo/odoo#213931

When coming back to a view using the breadcrumb or with the view switcher, we want to restore the local state of the view as it was when we left it, in particular the scroll position. This is handled by the `useSetupAction` hook, for all views (except for the list as the scrolling container is custom, because of the fixed table header).

However, since [1], it was no longer working in kanban, pivot and list (mobile only). This was due to the fact that those views are now "lazy", i.e. they are rendered directly, without the data, such that the control panel is available asap. As a consequence, when `onMounted` is called (i.e. when the hook attempts to restore the scroll position), there's no scrollable content yet.

This commit fixes the issue by allowing the controllers to restore the scroll position themselves, when their content is ready. In addition, a custom treatment was necessary for the kanban view, in mobile *and* if grouped, as each column has its own vertical scrollbar.

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

task~5086324

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#231339
Forward-Port-Of: odoo/odoo#230968

This error occurs when the domain URL contains `'.' or '..'` segments.

Steps to reproduce:
---
- Install `website` module
- Settings > Domain > Add URL with `'/../'` (eg: `https://power.odoo.com/OA_HTML/help/../ieshostedsurvey.jsp`)
- Open `Website` module

Traceback:
---
`ValueError: Dot segments are not allowed`

This issue occurs because at [1], we intentionally raise a `ValueError` to prevent the use of `'.' or '..'` in the URL path. In Chrome, the sequence `'/../'` is interpreted as a **back path** AFAIK.
For example:
`http://localhost:8069/odoo/action-218/../2 → http://localhost:8069/odoo/2`

This commit fixes the issue by validating the domain URL path. If it contains `'.' or '..'`, a **ValidationError** is raised to clearly inform the user that the entered URL is invalid.

[1]: https://github.com/odoo/odoo/blob/dc6dd927faea1f4501d6c50c586d5ea46bd1fc95/odoo/tools/urls.py#L72-L73

sentry-6932797319

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

### Issue:

Due to this issue, in the project sharing, the customer preview doesn't reflect the actual behaviour of the portal view. It shows non-validated timesheets even if invoicing policy is validated timesheets only.

#### To reproduce:
1- Create a db with sale_project and sale_timesheet_enterprise
2- Configure invoicing policy to validated timesheets only
3- Create a service product:
- Create on Order: Project & Task
- Invoicing policy: Based on Timesheets

4- Create a Quotation for the product and confirm it
5- Open project from smart button
6- Share project with a portal user with Edit access
7- Open tasks, and add two timesheets to the task
8- Open timesheet app, and validate one of the timesheets
9- From project page, click on Customer preview
10- In preview, open the task. You can see both timesheets which is a different behaviour if you view the project using portal user. Using portal user, only validated timesheets are shown.

### Cause:

The timesheets are filtered here to only show validated timesheets:

https://github.com/odoo/enterprise/blob/8223ed0765c6064b88280656a5ab6b13ca9a431f/sale_timesheet_enterprise/models/project_task.py#L73-L91

However, it is filtered only if user is portal. In customer preview the user is still the internal user, as a result the timesheets will not be filtered.

To fix that we can add a context in sharing project action and use it as a check to filter timesheets.

opw-5093339

In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if this is in response to `stop`-ing the page, or a pre-existing navigation directive interfereing with the stop-ing of the browser. I tried reproducing locally under the assumption that the `Page.stopLoading` might be the cause but got nowhere[^1].

This issue seems extremely infrequent, and in most cases is but a minor annoyance, an error appears on the corresponding build, and that's it.

However if the error occurs during `ChromeBrowser.stop` then the browser is not terminated, which on runbot prevents the docker image from shutting down properly, and leaves zombie builds.

Therefore make `ChromeBrowser.stop` more resilient to errors in the initial section so that we do terminate the browser even if the "graceful CDTP shutdown" fails. While at it, add a fallback to kill the browser if it does not terminate gracefully.

https://runbot.odoo.com/odoo/error/233442

[^1]: and the error only happening in 18.0 and later when `Page.stopLoading` was present long before that makes it likely the proximal cause is in the code being run, especially as all the errors sampled from the builds list are related to pos and the failure are immediately preceded by ongoing HTTP requests

## Versions
17.0+

## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.

## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
  - Create a new invoice in "CNY" currency for any customer with at least 1 product;
  - Confirm and click on the preview button:
    - Click on the "Pay now" button then "Pay" button of the wizard.

## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.


opw-5071893

**Steps to reproduce:**
- Install Accounting and Contacts

- Go to "Settings / Translations / Languages"
- Activate another language (e.g. French)

- Create a contact with an email and French as language
- Create another contact with an email and English as language

- Go to "Settings / Technical / Email / Email Templates"
- Edit "Invoice: Sending" email template
- In "Email Configuration" tab, add the email of the English contact in "Cc" field

- Create an invoice for the French contact
- Confirm the invoice
- Send the invoice

**Issue:**
The invoice is sent by email to the customer and to the email configured as CC in the template.
Both emails are in French, but some terms in the email header for the CC contact are in his configured language.
For example, instead of "Voir Facture", it's written "View Facture". And instead of "$10 dû le 01/01/2025", it's written "$10 due 01/01/2025".

**Cause:**
The content of the email and the model description is translated in the language of the customer of the invoice.
However, when grouping the recipients of the email, they are grouped by their language, leading to a mix of languages for some recipients.

**Solution:**
In the method grouping the recipients by lang, there is a parameter named "force_email_lang" that is the lang used for the content of the email, but it is only used as a fallback when a recipient doesn't have a lang configured.
From the name of the parameter (i.e. force_email_lang), it should be use in priority if set.

opw-4904029




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