**Step to reproduce:**
1. Install `sale_management`
2. Open any email template (e.g., Sale: Order Confirmation).
3. Add an attachment to it
4. Create a Sale Order, confirm it, and click "Send by Email".
5. In the mail composer, remove the template attachment

**Issue:**
- The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails.

**Cause:**
- The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment.

**Solution:**
1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server.
2. In `onFileRemove`, check the `res_model` of the attachment.
3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink)
   and only remove it from the composer view.

opw-5163679

Forward-Port-Of: odoo/odoo#250086
Forward-Port-Of: odoo/odoo#238692

Steps to produce:
---
- Install `website_sale` module.
- Go to website > open editor.
- Add an image snippet to the homepage.
- Click on the image and enable `Pop-up on Click`, then save.
- Click on the image.

Traceback:
---
`TypeError: Cannot read properties of undefined (reading 'length')`

Root cause:
---
- In the `setup` method, when the image is not part of a carousel,
  the element `.carousel-indicators` does not exist. As a result,
  `indicatorEl` is null, and the guarded block(at [1]) is skipped.
  Because of this, `this.liEls` is never initialized.
- Later, when the `onSlidCarousel` method is executed,
  its internal condition evaluates and find `liEls` as null and
  then `hide` method is called(see [2]).
- Inside the `hide` method, the code attempts to iterate
  over `this.liEls`(see [3]).

Solution:
---
- Initialized `liEls` in `setup()` to ensure it is always defined.
- Added a length check in `onSlidCarousel()` to execute the logic
  only when `liEls.length > 0`.
- This prevents this.page from being computed using invalid
  values and avoids it being set to `NaN`.
- Additionally, as requested by the boje(po), hide the popup
  on click setting on product images.
  
**Alternative approaches:**

1. We can also call the `onSlideCarousel` method from `setup`
    when multiple images are present.
2. Also, we can add a simple check inside the `onSlideCarousel`
    method to ensure that `liEls` is defined before proceeding.

[1]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L31-L57
[2]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L144-L152
[3]: https://github.com/odoo/odoo/blob/945f44e55f9a67b0744a183200de728b00202b1c/addons/website/static/src/snippets/s_image_gallery/gallery_slider.js#L119-L120

opw-5921123
---

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

Forward-Port-Of: odoo/odoo#247936

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

## Description of the issue/feature this PR addresses:
If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)
![image](https://github.com/user-attachments/assets/7747b0ee-fb36-43d1-bfde-5f3ad29ce77d)

First column: Client ref
Second column: committment date
Third column: Customer

## Current behavior before PR:

When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. 
The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d  format .
This is an error because that column does not contain a date .
The reason is that check_patterns when convert the pattern to reg ex using
`def to_re(pattern):`
on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex .


## Desired behavior after PR is merged:
No error should appear and the correct date format from the right date column should be guessed 



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

Forward-Port-Of: odoo/odoo#252488
Forward-Port-Of: odoo/odoo#196477

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954

Forward-Port-Of: odoo/enterprise#109655
Forward-Port-Of: odoo/enterprise#107268

When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.

As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.

Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`

Before this commit, parsing crashes with KeyError('bin/plain').

This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.

opw-5439156

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

Forward-Port-Of: odoo/odoo#251440

**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.

**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
    - Non-null cost per hour (e.g. 100)
    - Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.

Please notice that the price is correctly computed in the BOM overview

**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77

During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106

But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835

opw-5909570

Forward-Port-Of: odoo/odoo#248758

### Step to reproduce:

- Take a user with only basic inventory user access rights
- Create a new delivery, add a stock move, try to save the record
#### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids

This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module.

Cause of the issue:

Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model:
https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53
Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error.

runbot-240937

Forward-Port-Of: odoo/enterprise#109817

[FIX] hr_payroll: adjust proper version in payslip

Bug reproduction: Select an employee that has at least 1 payslip already, go to employee tab -> smart button payslip -> then you are in list view of payslips -> off cycle -> then your version is the first version of the employee, even though you are trying to create a payslip with the latest version of you. 

Bug cause:
    1 - Before version saas-19.2, date_from in hr_payslip is used to determine the version_id (in compute_version_id)
    2 - When version>=19.2, date_to is used for version_id calculation, also employee_id is passed in context when we are coming from smart payslip button.
    3 - Both compute_version_id (due to employee context) and compute_date_to triggers in hr_payslip and there is kind of race condition in here.
        3.1 - Even though sometimes date_to is started to calculate before, when version_id is calculating the date_to is always False, the computation is not done yet.
        3.2 - Since date_to is false, _get_version in hr_employee returns the first version of the employee, that's why in UI it is always the first version.

Bug solution:
    1 - I passed the version_id from smart button to the payslip directly to prevent unwanted behavior.

task - 6014170

## Steps to reproduce:

- Configure event registration with only free-text fields (no selection field).
- Open the POS, add an event ticket product, and fill in the registration form.
- Click Payment and validate the order.

## Issue:

- Registration answers were only sent to the backend when at least one selection-type question was filled.
- When no selection field was present, free-text answers were not synced at all.

## Reason:

- The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85

- This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75

## Fix:

- Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`.


task-5438565

Forward-Port-Of: odoo/odoo#252932
Forward-Port-Of: odoo/odoo#242465

Currently, an error occurs when the user opens the shop page.

**Steps to Reproduce:**

 - Install `website_sale_stock` module.
 - Go to `Settings` and enable `Product Variants`.
 - Create a `product template` of type `Goods`.
 - Enable `Track Inventory`.
 - In the `Sales tab`, disable `Sell when Out-of-Stock`.
 - In the `Attributes & Variants` tab, add one attribute with two values and save.
 - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants.
 - Go to `Website` > `Shop`.

**Error:**
`ValueError: Expected singleton: product.product()`

After [this commit], when opening the shop page, it calculates the quick add availability [1] 
for every product. It checks whether the product is sold out [2] to determine whether the quick 
add to cart button should be displayed or not. Since the product has no variants, it raises the 
error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4].

This commit ensures that if a product has no variants, it is treated as sold out. As a result, the 
quick add to cart button is not shown, as in the previous version.

[this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c

[1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39

[2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33

[3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41

[4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403

sentry-7287364112


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

Forward-Port-Of: odoo/odoo#250373

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

There is an inaccuracy in the steps of the tour:
- test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step confirms the order without waiting for all the associated onchanges to be taken into accounts: https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale_management/static/tests/tours/sale_flow_tour.js#L14-L20 https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale/static/src/js/tours/tour_utils.js#L27-L47

In the case where the confirmation happends before the product edition is taken into account, the order fails to confirm and stays in draft which makes the rest of the tour fails.

Note:

The same issue could happen at some point on the equivalent purchase test, so that we also modify the test:
- test_basic_purchase_flow_with_minimal_access_rights

runbot-241198

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

Forward-Port-Of: odoo/odoo#252154

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder leads to traceback.

Steps to reproduce:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quite builder tab, select a document.
4- Print -> PDF Quote.

This will lead to traceback.

Cause:
---
There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be
supported in future. Instead we use pypdf==5.4.0.

In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0):
https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061

FIX:
---
We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370

Note:
---
In this fix, we replace `is_upper_version_pypdf2` with specific version comparison.
To be precise `getNumPages` is depreciated in version 1.28.0 [2].

References:
---
[1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0
[2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514

opw-5784464

Forward-Port-Of: odoo/odoo#250329

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#110013
Forward-Port-Of: odoo/enterprise#107760

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#109693

**Steps to reproduce:**
- Install Expenses
- Activate "Incoming Emails" in the settings
- Configure the expense Alias
- Configure an "Incoming Mail Server"

- Create a Branch for a company
- Create a User:
  * Email Address: [an existing email address]
  * Allowed Companies: [the parent company + the branch company]
  * Default Company: [the branch company]
  * User Types: Internal User
- Create an employee for the user in the parent company

- From the email address, send a PDF to the expense alias

**Issue:**
The expense is not created in the database due to a UserError: "Incompatible companies on records".

**Cause:**
When the email is received and treated, the system tries to create an expense.
From the email address, it retrieves an employee that is linked to the expense.
For the company of the expense, if a user is linked to the employee, it takes the default company of the user.
Otherwise, it takes the company of the employee.
In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check.

**Solution:**
Always use the company of the employee, even if there is a user linked to the employee.

opw-5346809




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

Forward-Port-Of: odoo/odoo#253313
Forward-Port-Of: odoo/odoo#249415

This issue occurs on Single App and Single L10n, without demo data

### Summary
This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings.
https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498

### Observation
The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total.

Without the production lot group active, the conditional checks will bypass the grouping process:
https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 

When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187)


### Impact
When stock.group_production_lot is disabled:
 - Lines remain ungrouped.
 - The total sum of the grouped line is never generated.
 - The test fails as it cannot find or validate the expected sub-line totals.

This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) 
runbot-241109

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#109693

__

## Error description
The test fails when it is launched at 23h.
We obtain an assertion error:
`AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)`

## Origin of the issue
In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future.

X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e

note:
backport of
https://github.com/odoo/enterprise/pull/108891

Forward-Port-Of: odoo/enterprise#110126

**Steps to reproduce:**
- Install `l10n_de, website_sale and appointment` modules.
- Create a website for the `DE company` and make it default.
 (simply place it first in the sequence.)
- From settings enable `Automatic Invoice` and `Discounts, Loyalty & Gift Card`.
- Go to the appointment module and create a new appointment for the DE company.
- In the options tab, enable `Up-front payment` and publish it.
- Create a new gift card program and generate a gift card to test (should cover the entire cost of the appointment booking).
- Now go to an Incognito tab, go to the appointment, and book the currently created appointment. When confirming the order, use the gift card and then confirm the order.

**Issue:**
- When you confirm the order, an access error occurs.

**Root cause:**
- Since automatic invoicing is enabled, at [1] the method
  `get_product_accounts` is called for the DE company.
  Inside this method at [2], self.sudo(False) is used, which removes the
  elevated access rights. As a result, the `Public product template` record
  rule is triggered, and because the public user cannot access the product,
  an AccessError is raised.
- In this [commit], we can see that `sudo(False)` was added when coming from
  the stock flow because the stock valuation layer was being created as sudo.

**Solution:**
- Instead of adding `sudo(False)` in **l10n_de**, we can apply `sudo(False)`
  at the point where the **stock valuation layer** is created using `sudo()`.

[1]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/account/models/account_move_line.py#L603-L604
[2]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/l10n_de/models/datev.py#L20

[commit]: https://github.com/odoo/odoo/pull/236931/changes/0919774791bb998954b870798c88843f999f2de4

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

Forward-Port-Of: odoo/odoo#253131
Forward-Port-Of: odoo/odoo#246920

### Steps to reproduce:
	- Create a Overtime hours time off type
	- Create mutliple allocations with different start dates but no end date
	- Create some leaves for the created allocations one after each allocation start date
	- Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report.

### Cause:
After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery.

### Fix:
Following the same approach we use in  if
the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date

opw-5474596

Forward-Port-Of: odoo/odoo#251704
Forward-Port-Of: odoo/odoo#250432

Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`

Issue:
- The image is a full-size image


<table>
    <tr>
        <th style="text-align: center;">Before</th>
        <th style="text-align: center;">After</th>
    </tr>
    <tr>
        <td style="text-align: center;">
            <img width="1395" height="728" alt="Before" 
                 src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
        </td>
        <td style="text-align: center;">
            <img width="1383" height="662" alt="After" 
                 src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
        </td>
    </tr>
</table>

opw-5915587

Forward-Port-Of: odoo/odoo#249000

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#109693

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#110049
Forward-Port-Of: odoo/enterprise#105040

Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#109294
Forward-Port-Of: odoo/enterprise#104771

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#110062
Forward-Port-Of: odoo/enterprise#102126

Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs.

**Steps to Reproduce:**

 - Install the `pos_pricer` module.
 - Go to `Scheduled Actions` and run `"POS Pricer: Tags Update Synchronization"`.

**Error:**
`
ValueError: TypeError("PricerStore._update_pricer_tags() got an unexpected keyword argument 'update_all'") while evaluating 'model.search(([("pricer_tag_ids", "!=", False)]))._update_pricer_tags(update_all=False)'`

This error occurs because, after this [recent commit], `_update_pricer_tags` was changed to 
no longer accept the `update_all` argument and now relies on the `needs_pricer_update` instead. 
However, the scheduled action still passes the `update_all` argument [1], which causes the
 error when the cron job runs.

This commit removes the unexpected `update_all` argument from the tag update synchronization cron.

[recent commit]: https://github.com/odoo/enterprise/commit/166a8a240d0588f4e908ce09c4639da1216ba3b7

[1]- https://github.com/odoo/enterprise/blob/0ef7643bba5b3fa3d22ab122ef3b65f0d67c8fb7/pos_pricer/data/pricer_ir_cron.xml#L9

sentry-7324339777

Forward-Port-Of: odoo/enterprise#110242

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954

Forward-Port-Of: odoo/enterprise#109655
Forward-Port-Of: odoo/enterprise#107268

__

## Error description
The test fails when it is launched at 23h.
We obtain an assertion error:
`AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)`

## Origin of the issue
In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future.

X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e

note:
backport of
https://github.com/odoo/enterprise/pull/108891

Forward-Port-Of: odoo/enterprise#110126

This includes a back port of this commit: efc59084fbd3fe314a686699e42bfdcc4553ad85

### Issue:
The user group "Fleet / Officer: Manage all vehicles" don't see vehicles with no employee when he also have the 

### Steps to reproduce:
- Create a user having the group "Fleet / Officer: Manage all vehicles" and "Employees / Officer: Manage all employees"
- Create a new vehicle
- Switch to this user and go to the Fleet app
- The vehicle doesn't appear

### Cause:
1. The user group "Fleet / Officer: Manage all vehicles" have no rule allowing them to read the vehicle model. Currently users access only vehicles with an employee defined because of the rule "Hr Officer read rights on vehicle with employees assigned" if they have the group "Officer: Manage all employees". 

2. This rule was kept by the commit we are backporting. When it gets applied (when the user has the group "Officer: Manage all employees"), the user cannot see vehicles without employees. This is because the commit we are backporting didn't add any rule to give the access to "Fleet / Officer: Manage all vehicles" so the default access is overridden by this rule.

### Solution:
1. We backport the commit efc59084fbd3fe314a686699e42bfdcc4553ad85

2. We modify the rules giving rights to Administrators to give the same rights to Officers. As Administrator implies Officer we don't change anything for them.

opw-5344528