Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#116944
Forward-Port-Of: odoo/enterprise#115085

Backport of 7c68c3dbb29eaad4e09d59ef7c86bd525969caec Including its fix: e490c0c66561715853a3f80658f47c940bc453dc

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO, amnufactured product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
#### > There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 0
#### > The delivery is cancelled but no activity is logged what's so ever

### Expected behavior:

Both of these operations should log an activity as the demand of the MO is not updated on quantity decrease.

opw-6010109
opw-6105366
opw-6100043
opw-6087909

X-original-commit: 796316c341c4346152ad9610c30679f47aaa2ff8

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

Forward-Port-Of: odoo/odoo#264732
Forward-Port-Of: odoo/odoo#258093

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#263913
Forward-Port-Of: odoo/odoo#251993

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#116670
Forward-Port-Of: odoo/enterprise#115285

When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language.

This has a few issues:
- When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name.
- When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name.

The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten.

To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated.

Related: https://github.com/odoo/enterprise/pull/116369

Forward-Port-Of: odoo/odoo#262981

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#115760

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

Forward-Port-Of: odoo/enterprise#117414

Steps to produce:
---
- Install website_sale module.
- Enable `Comparison Price` from settings.
- Create a product with sales price = 25 and compare price = 25.
- Go to the shop page and search for the product.

Issue:
---
- The strikethrough appears on the compare price (25) even when the compare price equals the sales price.
- The strikethrough should only appear when the compare price is strictly greater than the sales price.

Root cause:
---
- In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal.

Solution:
---
- Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2].

Before:
---
<img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" />

After:
---
<img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" />


[1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834
[2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346

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

Forward-Port-Of: odoo/odoo#264912
Forward-Port-Of: odoo/odoo#262434

When computing `qty_to_order` 1-3 extra queries are made by `get_lead_days()`, which can cause performance issues when computing `qty_to_order` for a large number of orderpoints.

This commit aims to prevent these extra queries by returning early if the current product is not associated with a bom. The amount this commit speeds up the compute depends on how many of products passed into `_get_lead_days()` are associated with a bom.

`qty_to_order` is no longer a stored field after this commit: https://github.com/odoo/odoo/pull/159432
This benchmark was done in 18.0 on /stock.warehouse.orderpoint/search_panel_select_range. This call does not trigger the compute on all orderpoints in 17.0 as the field is stored but calling the compute directly on all orderpoints results in the same speed up as seen in 18.0.

| Orderpoints | % of products linked to a bom | Time before | Queries before | Time after | Queries After |
|-------------|-------------------------------|-------------|----------------|------------|---------------|
|         800 | 50%                           | 2.8s        |           1570 | 2.3s       |           818 |
|       8,000 | 0%                            | 28.2s       |         16,698 | 15.3s      |           242 |
|       8,000 | 25%                           | 29.6s       |         16,833 | 19.2s      |          4497 |
|       8,000 | 50%                           | 29.8s       |         16,925 | 23.2s      |          8693 |
|       8,000 | 75%                           | 31.6s       |         16,949 | 27.6s      |         12827 |

Forward-Port-Of: odoo/odoo#262321

Customers placing an order without logging in and with the "Pick up in store" delivery method are not notified when the delivery is confirmed

1. Install eCommerce and Sales
2. Go to Settings > Website > Delivery and enable "Click & Collect"
3. Go to Settings > Inventory > Shipping and enable "Email Confirmation"
4. Go to Website > Configuration > Payment Providers and Install Demo
5. Go to Website > Configuration > Delivery Methods and open "Pick up in store", set YourCompany as warehouse and publish it
6. Go to Sales > Products, open product "Office Lamp", click on "Update Quantity" in the status bar and add 5 units
7. Log out
8. Go to the shop, add product "Office Lamp" to the cart and checkout
9. Fill in the address form and continue checkout
10. Select "Pick up in store" as delivery method and select a location
11. Confirm the order and pay with Demo
12. As user Mitchell Admin, go to Sales, remove the default filter and open the newly created sale order
13. Open the related delivery with the smart button and validate it
14. No delivery order confirmation was sent to the customer (check emails)

Issue:
Confirming an order with a "Pick up in store" delivery method replaces the `partner_shipping_id` of the sale order with an archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/delivery/models/sale_order.py#L178-L192
which updates the `partner_id` of the related `stock.picking` with the archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/sale_stock/models/sale_order.py#L130-L132
This will unsubscribe the old `partner_id` on the `stock.picking` and try to subscribe the archived partner
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/stock/models/stock_picking.py#L1120-L1125
Because the partner we want to subscribe is archived, he will be filtered out and the subscribe action will have no effect, preventing him from receiving the delivery confirmation
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/mail/models/mail_thread.py#L4367-L4369

Solution:
Subscribe the parent of the archived partner when we write a `partner_id` on pickings with "in_store" `delivery_type`. This ensures the unarchived partner is subscribed to the picking allowing him to receive the mail confirmation.

opw-6095396

Forward-Port-Of: odoo/odoo#264926
Forward-Port-Of: odoo/odoo#263005

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)

Those colors are a bit special (see full discussion on the opw)

    Their existence is described in module web
    Their CSS definition is implemented in module html_editor
    Reports don't use them at all We probably don't want reports' style
    to be influenced by the presence or lack thereof of the html_editor
    module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143


community: https://github.com/odoo/odoo/pull/264917

Forward-Port-Of: odoo/enterprise#117555