Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112818
Forward-Port-Of: odoo/enterprise#112566

In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant.

When no sequence number is provided, the system automatically assigns one by taking the highest existing sequence among articles with the same parent and incrementing it by 1.

When demo data is enabled, additional users are created along with their corresponding onboarding articles. As the onboarding articles does not have any parent, the onboarding article are included in the computation of the sequence number of the new article we create in the test. These extra articles impacts the sequence number of the new article, causing the test assertion to fail.

To resolve this, the test computes the expected sequence number dynamically based on the current state of the data. This ensures consistent behavior regardless of whether demo data is present.

runbot-error-id~231695

Forward-Port-Of: odoo/enterprise#106326

## Issues
When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears.

Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab.

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a second company
3. Create a subscription product and set a company in the *Company* field (`company_id`).
4. In the *Recurring prices* tab, add a line (any recurring plan, any price)
5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_**

For the second issue, after the same 3 first steps:
1. Create a *Recurring Plan* RP with its *Company* field set to the current company
2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP
3. **The Recurring plan RP is missing from the list of available plans.**

## Cause
When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases.

https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26

By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`:

https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173

opw-5981629
opw-6051978

Forward-Port-Of: odoo/enterprise#109403

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112616
Forward-Port-Of: odoo/enterprise#109204

### Issue before this commit:
When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'.

### Steps to reproduce the issue:
1. Select two or more companies from multi company menu
2. Accounting / Reporting / Ledgers / General Ledger
3. Posted Entries, Accrual Basis button
4. Pick Consolidation
5. Error

### Cause of the issue:
When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected).
However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError.

### Reason to introduce the fix:
To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors.

opw-5933074

Forward-Port-Of: odoo/enterprise#112567
Forward-Port-Of: odoo/enterprise#109036

A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled

Steps to reproduce:
1. Install eCommerce and Subscriptions
2. Go to Settings and enable `Prevent Sale of Zero Priced Product`
3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website
4. Go to Subscriptions > Pricelists and edit pricelist "Benelux"
5. In the Recurring Prices tab, create a new entry for product "subscription"  with a Fixed Price of $20.00 and a monthly Recurring Plan
6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected)
7. Try to add it to the cart
8. Nothing happens and an error is displayed in the log

Issue:
When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs
We reach this code
https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero
Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches
https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans
Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart

Solution:
We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart.

Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`.

opw-5993614

Forward-Port-Of: odoo/enterprise#111624

Currently an error is generated when the user tries to save a report
with an empty XML format.

Steps to reproduce:
- Install web_studio and sale_management
- Sales > Studio > Reports > New > External > Type Text in report
- Save > Edit Sources > Remove full XML > Save

Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)`

This error occurs because line [1] in `web_editor` attempts to access
nodes by using `etree.fromstring()` with an empty `view.arch`, which is
empty, resulting in an error.

In earlier versions, this error was already handled by the `_check_xml`
constraint, which raised a validation error when an `etree.ParseError`
occurred while parsing `etree.fromstring(view.arch)` with an empty
`view.arch` (see code reference [2]). However, recent changes introduced
in commit [3] allow  `view.arch` to be empty. As a result, this error
is no longer handled by the constraint.

This commit fixes the issue by adding a condition to prevent calling
`etree.fromstring()` when `view.arch` is empty, avoiding attempts to access
nodes from invalid data. It also updates the logic in the `web_studio`
module's `get_xml_editor_resources` method to ensure resources are processed
only when a valid view architecture is available.


[1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367
[2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377
[3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f

sentry-6288795955

Forward-Port-Of: odoo/enterprise#112111
Forward-Port-Of: odoo/enterprise#88613

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566

In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant.

When no sequence number is provided, the system automatically assigns one by taking the highest existing sequence among articles with the same parent and incrementing it by 1.

When demo data is enabled, additional users are created along with their corresponding onboarding articles. As the onboarding articles does not have any parent, the onboarding article are included in the computation of the sequence number of the new article we create in the test. These extra articles impacts the sequence number of the new article, causing the test assertion to fail.

To resolve this, the test computes the expected sequence number dynamically based on the current state of the data. This ensures consistent behavior regardless of whether demo data is present.

runbot-error-id~231695

Forward-Port-Of: odoo/enterprise#106326

### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#112478
Forward-Port-Of: odoo/enterprise#111662

Currently, an error occurs when user tries to undo a calendar event.

Steps to replicate:
- Install `appointment` with demo data.
- Navigate to `Appointments > Schedule > Resource Booking`.
- Drag to create a calendar event.
- Reschedule the event to a later time (drag and drop forward).
- Click Undo on the notification that appears.

Error:
`ValueError: Invalid field 'originId' in 'calendar.event'`
`KeyError: 'originId'`

Cause:
- The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it.
- The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur.

Solution:
- Remove the `originId` key from `fallbackdata` before the orm call.

[1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116

[fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425

[orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477

[line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248

sentry-7020359653

Forward-Port-Of: odoo/enterprise#112614
Forward-Port-Of: odoo/enterprise#100570

## Issues
When adding a line in the *Recurring prices* tab (`product.pricelist.item`) of a product with a `company_id`, a "company inconsistencies" error appears.

Also, recurring plans with their *Company* field set do not appear in the list of recurring plans when adding a line in the *Recurring prices* tab.

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a second company
3. Create a subscription product and set a company in the *Company* field (`company_id`).
4. In the *Recurring prices* tab, add a line (any recurring plan, any price)
5. **An _Invalid Operation_ error appears: _"Uh-oh! You’ve got some company inconsistencies here"_**

For the second issue, after the same 3 first steps:
1. Create a *Recurring Plan* RP with its *Company* field set to the current company
2. On the *Recurring prices* tab of the subscription product, try to add a line with the Recurring plan RP
3. **The Recurring plan RP is missing from the list of available plans.**

## Cause
When adding a line to the *Recurring prices* tab, a new `product.pricelist.item` is created, with no `pricelist_id`. The `ProductPricelistItem._compute_company_id` from `sale_subscription` filters out the items that don't have a `pricelist_id`, which is the case for the line we create. Also, the (potentially new) plan has no `company_id` in most cases.

https://github.com/odoo/enterprise/blob/ccab0c261040ed995d12dca891caae9596bbe1eb/sale_subscription/models/product_pricelist_item.py#L18-L26

By filtering the items with no `pricelist_id`, nothing is passed to the `super()._compute_company_id`, even though it would also handle cases where the item has a `product_tmpl_id`:

https://github.com/odoo/odoo/blob/9c8112d794af1ba84ade8af124967495c2ff8995/addons/product/models/product_pricelist_item.py#L170-L173

opw-5981629
opw-6051978

Forward-Port-Of: odoo/enterprise#109403

Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000.

### **Steps to Reproduce:**
1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 
2) Switch to PK company.
3) Create an employee and a running contract with yearly cost 2,200,001 
4) Create a payslip and compute it from the Salary Computation tab.

### **Observed Behavior:**
'Tax Bracket Yearly' is computed as `122000.24`

### **Expected Behavior:**
'Tax Bracket Yearly' should be `116000.24`

### **Root Cause:**
since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on  [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value.

[official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf)

### **Fix:**
Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket.

**opw-5979265**

Forward-Port-Of: odoo/enterprise#112642
Forward-Port-Of: odoo/enterprise#110939

Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs.

## Steps to replicate:
- Install Inventory
- Go to Settings and enable Multi-Step Routes > Set Warehouse Routes.
- Configure 2 steps for outgoing shipments.
- Go to Inventory and  create a new delivery with
   - **Source Location:** WH/Stock
   - **Product:**  [E-COM10] Pedal Bin with demand 1
- Mark as Todo then Archive the Pedal Bin product.
- Open that delivery in barcode app
- Pencil icon > +1 > Confirm

## Observed behavior:
TypeError: Cannot read properties of undefined (reading 'qty_available')

## Root cause:
After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above.

## Solution:
Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error.

It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button
followed by validation, ensuring consistency.

[commit]:
https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 
[2]-
https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45

opw-5980428

Forward-Port-Of: odoo/enterprise#112616
Forward-Port-Of: odoo/enterprise#109204

A subscription product that has a price of zero on the product form and the price is set on the pricelist instead cannot be added to the cart when the `Prevent Sale of Zero Priced Product` setting is enabled

Steps to reproduce:
1. Install eCommerce and Subscriptions
2. Go to Settings and enable `Prevent Sale of Zero Priced Product`
3. Go to Subscriptions > Products and create a new product "subscription" with Sales Price $0.00 and publish it to the website
4. Go to Subscriptions > Pricelists and edit pricelist "Benelux"
5. In the Recurring Prices tab, create a new entry for product "subscription"  with a Fixed Price of $20.00 and a monthly Recurring Plan
6. Log in as portal user, go to the shop and look for "subscription" (pricelist "Benelux" should be selected)
7. Try to add it to the cart
8. Nothing happens and an error is displayed in the log

Issue:
When we check if a product can be added to the cart https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/controllers/cart.py#L116-L120 we do not use the plan_id specified in kwargs
We reach this code
https://github.com/odoo/odoo/blob/b1f4647313eb2dbdbbe98b51649604b4e650a8aa/addons/website_sale/models/product_product.py#L146-L147 which will prevent the addition of a product in the cart if the option `prevent_zero_price_sale` is enabled and if `_get_contextual_price` returns zero
Calling `_get_contextual_price` tries to find a `product.pricelist.item` by building a domain in `_get_applicable_rules_domain` but calling this method without a plan_id eventually reaches
https://github.com/odoo/enterprise/blob/252c5ab78b51d0d2f06178cf92f0489b4a46958f/sale_subscription/models/product_pricelist.py#L69-L72 which restricts the domain to pricelists that are not subscription plans
Therefore, we cannot find any pricelist that applies to the product and we consider that the product cannot be added to the cart

Solution:
We need to use the plan_id selected by the customer in order to correctly check if a product can be added to the cart.

Use the plan_id in kwargs to update the request context so we can check if a product can be added to the cart according to the plan_id the user has selected. Use this plan_id in `_get_applicable_rules` in order to correctly select the applicable `product.pricelist.item`.

opw-5993614

Forward-Port-Of: odoo/enterprise#111624

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566

**Steps to reproduce:**
* Install the *Manufacturing (`mrp`)* module.
* Enable *developer (debug) mode*.
* Open the *Shop Floor* interface.
* Select  work center as `Assembly 1`
* In the bottom-right corner, click the *gear icon*.
* Select **Move to Work Center** from the  *gear icon*.

**Observed behavior:**
* A traceback occurs when opening the *Move to Work Center* dialog.
* The following Owl error is raised: 

`OwlError: Invalid props for component 'MrpWorkcenterDialog': 'loadWorkcenters' is missing (should be a function)
    Error: Invalid props for component 'MrpWorkcenterDialog': 'loadWorkcenters' is missing (should be a function)`

**Cause:**
* `MrpWorkcenterDialog` is opened in *two different ways*:

https://github.com/odoo/enterprise/blob/7805022e77ff80a74563b7ff0032d8975c00b709/mrp_workorder/static/src/mrp_display/mrp_display.js#L469-L480

  * One caller opens the dialog and provides `loadWorkcenters`.
    In this flow, the dialog fetches work centers by calling this
    function.

https://github.com/odoo/enterprise/blob/7805022e77ff80a74563b7ff0032d8975c00b709/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L68-L76

  * Another caller opens the dialog and directly provides a
    `workcenters` list. In this flow, the dialog already has the data
    and does not need `loadWorkcenters`.

* Therefore, the real behavior is that `loadWorkcenters` is only
  required *sometimes*, not always.

* However, the component props defined it as mandatory:
  `loadWorkcenters: { type: Function }`

* In *debug mode*, Owl strictly validates component props by comparing
  what the component declares in `static props` with what the caller
  provides. When the dialog is opened without `loadWorkcenters`, Owl
  detects that a required prop is missing and raises an
  *Invalid props* error.

**Fix:**
* Mark `loadWorkcenters` as *optional* in the component props so the
  dialog works correctly in both supported flows:
  * Lazy loading of work centers via `loadWorkcenters`.
  * Using preloaded `workcenters` data.

---

opw-6010261

Forward-Port-Of: odoo/enterprise#110361

Currently, maintenance stages are global and shared across all teams. This 
improvement allows stages to be restricted to one or more maintenance teams, 
or left empty to remain available to all teams.

- Add 'maintenance_teams' M2M field to 'maintenance.stage' model.
- Update tree view to display maintenance teams using many2many_tags.
- Create a new form view for stages to allow team selection.
- Add domain to 'stage_id' on maintenance requests to filter by team.
- Update '_get_default_team_id' to infer the correct team when creating
  requests from specific Kanban columns.
- Enhance '_compute_maintenance_team_id' to maintain consistency between
  the request team and the equipment's assigned team.
- Add onchange on 'maintenance_team_id' to automatically reset the
  stage to the first valid option when the team changes.
- Update '_read_group_stage_ids' to get only the stages that the
  maintenance team can work on.
      
task-5104582

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

Behavior before:
Opening the inventory valuation report on databases with 300k+ products
(storable) caused an out-of-memory (OOM) error, making the report completely
unusable at this scale.

Behavior after:
The inventory valuation report loads successfully and efficiently for 300k+
products without any memory errors or RAM spikes.

Root Cause:
In `_get_accounts_by_product()`, querying all storable products creates a massive
recordset. When iterating through this recordset, the call to `_get_product_accounts()`
accesses various relational and property fields (like categories and accounts).
Because standard ORM prefetching was active, accessing these relational fields on the
first loop iteration triggered a massive batch-fetch for all 300k+ products in the
recordset simultaneously. This cascading prefetch overloaded the environment cache
and caused an immediate OOM crash.

Fix:
Wrapped the `_get_accounts_by_product()` call in `with_context(prefetch_fields=False)`.
This disables the greedy batch-loading behavior across the entire recordset. The ORM
now fetches the required relational accounting fields surgically, record-by-record
inside the loop, maintaining a minimal memory footprint and preventing the crash.

Benchmark:

| Products Count | Memory Before  | Memory After | Time Before | Time After |
|------------------------|-------------------------|----------------------|------------------- |----------------|
| 300k+                  | Memory Error     | 1.1. GB             | 46.63 s           | 1.9 m         |
| 200k                    | Memory Error     | 566.4 MB         | 1.2 m              | 1 m            |
| 100k                    | 873.1 MB             | 286.8 MB         | 36.74 s            | 32.15 s      |
| 50k                      | 442.1 MB             | 145.6 MB         | 18.96 s            | 17.65 s      |

opw-5462037



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

This PR addresses three edge cases in the Click & Collect and Delivery availability widget where incorrect availability states were being shown to the user.

Before this PR:
* If a product variant had a tag excluding it from Click & Collect, the logic bypassed the entire stock preparation block. This resulted in the variant falsely hiding the standard Delivery option and showing C&C as unavailable.
*  Products that are not tracked in inventory (consumables/services) were not properly displaying the availability widget with all options open (bypassing stock checks).
* If a product variant was excluded from standard delivery methods via tags, the delivery portion of the widget would still incorrectly render on the frontend.

After this PR:
* The C&C `excluded_tag_ids` check is moved further down so it only restricts the generation of `in_store_stock_data`. Standard `delivery_stock_data` is now evaluated independently.
* *Untracked products now correctly bypass standard stock checks and display all available widget options as expected.
*  Standard delivery carriers are now explicitly filtered against the product's tags (`dm.excluded_tag_ids & product_tags`). If all available delivery methods are excluded, the delivery stock data is correctly omitted, hiding the section.


opw-5990419

## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.

## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
    - Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
    - Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
    - Add a row for the current month, with *Next Number* set to 1
    - Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
    - Any Customer
    - Any Product
    - Set the *Quotation Date* to next month
    - Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**

<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />

The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.

## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.

https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216

In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.

https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270

**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**

opw-5950028

Forward-Port-Of: odoo/odoo#256449
Forward-Port-Of: odoo/odoo#256320

**Description:**
The issue is raised in this pr(v19.2) : https://github.com/odoo/odoo/pull/236971
The compute method used a [`return`](https://github.com/odoo/odoo/pull/236971/changes#diff-4e1a18a369f7dd4de264139227676dd818c06612681c88019f43d238bd8a1490R91) statement when a `if condition` was met. While this works correctly for a single record, it causes issues when multiple records are present.
**For example**, if `self` contains records like `project.project(3, 2, 4)`, and the condition **is satisfied** for the first `record (3)`, the method exits early. As a result, the remaining `records (2 and 4)` are **not** processed.
When the compute method is [triggered](https://github.com/odoo/odoo/blob/8c3043b436f8aae295f247341e3ac427fab05474/odoo/orm/fields.py#L1746) this incomplete computation leads to
missing values for some records and can result in errors.

**Solution:**
To resolve this issue, `return` has been replaced with `continue`. 
This ensures that:
Only the current record is skipped when the condition is satisfied and the loop continues processing the remaining records.

**Traceback:**
```.py

Traceback (most recent call last):
  File "/tmp/tmp2cuqrnuy/migrations/testing.py", line 483, in test_check
    self.check(value)
  File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line 228,
 in check
    self.assertFalse(diff, msg)
AssertionError: [('project.menu_projects', 391, 'Project > Projects', 593)] is
not
false : At least one menu or view working before upgrade is not working after
upgrade.

('project.menu_projects', 391, 'Project > Projects', 593):
 Traceback (most recent call last):
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py",
line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2735, in read
    return self._read_format(fnames=fields, load=load)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2991, in
_read_format
    vals[name] = convert(record[name], record, use_display_name)
                         ~~~~~~^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 6007, in
__getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1805, in
__get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign
project.project(2, 4).stat_timesheet_value
```
opw-6046808



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

Forward-Port-Of: odoo/odoo#256048

**Issue:** 
odoo/odoo#250051 consolidated multiple `width: 100%` rules into a single broad selector:

    .o_form_view .o_form_sheet .o_field_widget:not(…) { width: 100% }

This broadened scope from `.o_group/.o_inner_group` to the entire `.o_form_sheet`, which was needed for the new `o_input_box` overlay system. However, the high specificity (0,4,0) now overrides any module-specific rule with lower specificity, such as setting.scss's `width: 50%` rule (0,3,0) for `<setting>` blocks.

This broke settings panels: field widgets stretched to 100% width instead of 50%, causing overflow in layouts like the helpdesk team email alias row.

**Fix:**  
wrap the field widget portion of the selector in `:where()`.

The `:where()` CSS pseudo-class works identically to `:is()` in terms of what it matches, but always contributes zero specificity.

(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
(ref: https://developer.mozilla.org/en-US/docs/Web/CSS/:where)

```
Before (A=0, B=4, C=0):
    .o_form_view .o_form_sheet .o_field_widget:not(…)
    ↑(0,1,0)    ↑(0,1,0)     ↑(0,1,0)      ↑(0,1,0)

After (A=0, B=2, C=0):
    .o_form_view .o_form_sheet :where(.o_field_widget:not(…))
    ↑(0,1,0)    ↑(0,1,0)     ↑(0,0,0) ← :where zeroes this
```

The rule still matches every field widget in the form sheet, but now any component-specific override (settings, helpdesk, custom views) wins naturally without needing specificity hacks.

CSS specificity tiebreaker order:
```
    A: inline styles > B: IDs > C: classes/attrs/pseudo-classes
    Equal specificity → last rule in source order wins
```

task-6005002

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

Currently, the BOE export for `Mod 347` uses incorrect indicators for 
`Substitutive` and `Complementary declarations`.

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`
- Navigate to Accounting > Reporting > Tax Report
- From the smart button, select `Report: Tax Report (Mod 347) (ES)`
- Download the BOE file using the dropdown.
- In the wizard:
  - Enable `Substitutive Declaration` or `Complementary Declaration`
  - Set `Previous Report Number` (e.g., 123456789)
  - Click `Generate BOE`
- Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required)

**Observation:**
AEAT does not recognize 'X' as a valid indicator for substitutive or 
complementary declarations and interprets the file as a standard return.

**Root Cause:**
At [1], the BOE Mod 347 generation writes 'X' for both substitute 
and complementary declarations.

**Fix:**
This commit ensures the file contains correct indicators:
- 'C' for `complementary declarations`
- 'S' for `substitute declarations` 

This aligns Modelo 347 with AEAT specifications and ensures 
consistency with the implementation of Modelo 349 at [2].

Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html

[1]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062

[2]:
https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491

opw-6048711

Forward-Port-Of: odoo/enterprise#112566

### Issue:

The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature.

### Steps to reproduce:

- Have 2 companies: company 1 and company 2
- Set the barcode nomenclature of company 1: default, company 2: GS1
- Incarnate a user allowed in both companies but with default company 1
- With company 2, create a product and set its barcode to 36939282410106
- From the main menu open the barcode app and scan 0136939282410106
#### > No product was found (even thought it is correct in GS1)

### Cause of the issue:

Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 
However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view:
https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11
As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083
based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722

### Fix:

Setting the company slices the `current_company` in first position of the `allowed_company_ids`:
https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81
which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491
Note that passing the context in the arguments of the `main_menu` JSON  route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f

### Additional Issue:

The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Set the barcode nomenclature to GS1
- Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365
- From the main menu open the barcode app and scan 4133033710074365
#### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination)

opw-5847529

Forward-Port-Of: odoo/enterprise#112478
Forward-Port-Of: odoo/enterprise#111662