Steps to reproduce:
-------------------
1. Install Fleet with demo data.
2. Create a contract for a vehicle (A) with a recurring cost of 1000
 and "Monthly" frequency.
3. Go to Reporting > Costs and verify the monthly cost
 (it shows 1000).
4. Create another contract for the same vehicle (A) with a
 recurring cost of 50 and "Monthly" frequency.
5. Check the monthly cost again.

Issue:
------
The reported cost is incorrect. Instead of 1050 (1000 + 50), it shows 2100.

Cause:
------
The query uses multiple LEFT JOINs on the contract table, including:
https://github.com/odoo/odoo/blob/9ca36dbe53692309bac84329de3b54a1c510cce0/addons/fleet/report/fleet_report.py#L103

These joins overlap and produce duplicate rows for the same
vehicle and month, which results in inflated cost totals.

Solution:
---------
Replace the multiple LEFT JOINs with a single LATERAL join.
This ensures the contract table is processed once per vehicle per month and
avoids duplication, resulting in correct totals.

**Before:**
<img width="940" height="609" alt="image" src="https://github.com/user-attachments/assets/e5b3e747-1135-4674-97c9-4e4fd9986dfd" />

**After:**
<img width="1053" height="590" alt="image" src="https://github.com/user-attachments/assets/f0df3819-07fb-4de5-aab3-5b4c6f10d213" />



opw-6024132





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

Forward-Port-Of: odoo/odoo#256051

Have an x2many field displayed as a list in a form view. In the arch, the x2many form view **isn't** inlined. In that x2many form view, there's a properties field.

When a record is clicked, `extendRecord` is called to add the new fields (those of the form) into `this.fields` and those fields are fetched. If there're properties in the property definition, fake fields are created to represent them (see `_processProperties`). However, because of extendRecord, the static list and the record don't share the same reference to the `fields` object. As a consequence, the `fields` object of the static list isn't updated with the fake property fields.

If the user closes the record, and opens/closes it again, there's a crash, because the record is re-updated with the fields of the static list, and thus doesn't know about those property fields anymore.

This commit fixes the issue by ensuring that we keep the same `fields` object when extending a record, s.t. the list and all its records always share the same object.

Bug originally reported here: https://github.com/odoo/odoo/pull/268312


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

Forward-Port-Of: odoo/odoo#269717

Version:
----------
- 18.0+

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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

Forward-Port-Of: odoo/odoo#269971
Forward-Port-Of: odoo/odoo#262396

### Steps to reproduce:

1. Create a product tracked by lot
2. Put 10 units in WH/Stock without lot
3. Inventory > Operations > Adjustments > Physical Inventory
4. Select the line referring to your product and request an inventory count + Show Expected Quantity
5. Open the barcode app > Count Inventory
6. Scan your product
#### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product.

### Cause of the issue:

Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632
However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863
But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731
Note however that the super call does:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798

### Issue 2:

### Steps to reproduce:

- Steps 1 -> 5
- Click on your product line to select it
- Scan a new lot to add one new unit referring to that lot
- Confirm (1)
- Apply Now
#### > User Error: Quant's editing is restricted, you can't do this operation

Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant:
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798

Additional issue:

Fixing issue 1 and 2 highlight and other issue of the validation process:

- Steps 1 -> 6
> The line gets selected
- Scan a newlot
> a new subline is added referring to 1 unit of your new quant
- Confirm (1) > Some serials where not counted, set them as missing
#### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot

### Cause of the issue:

Applying all quantities is expecting to toggle them as counted before applying to update the existing quants:
https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63

opw-6212923

Forward-Port-Of: odoo/enterprise#118373

Problem:
When printing an invoice for a Latin American (LATAM) company, the company's document layout is not used in the header of the invoice. For example, if an Argentinian company has set up a Bubble layout as its document layout, the header of the invoice will not have the bubble.

Steps to reproduce:
1. Install l10n_ar
2. Create an invoice using Electronic Sales Journal
3. Set document layout to Bubble in the company settings
4. Print the invoice
5. Notice that the header of the invoice does not have the bubble

Cause:
Most LATAM localizations use custom headers for their reports. In report_templates of l10n_latam_invoice_document, it checks if custom_header is set to decide whether to display the custom header. If custom_header is set, the div with class "header" will be hidden, and the custom header will be displayed after the div with class "header". Since the div with class "header" contains the background image that corresponds to the document layout, the background image will not be displayed when div with class "header" is hidden.

Solution:
Instead of hiding the entire div with class "header" when custom_header is set, only hide the table inside the header. This way, the background image of the document layout will still be displayed even when a custom header is used.

opw-6204062

Forward-Port-Of: odoo/odoo#267164

Description of the issue/feature this PR addresses:
Fixes an issue where the sale order reference computation was fetching the invoice journal based on the logged-in user's current company instead of the company associated with the specific payment provider or transaction context. This caused incorrect reference processing or errors in multi-company environments when a user was logged into one company but processing an order from another.

Current behavior before PR:
The function searches for the account.journal using self.company_id.id. Since self in this context (likely a payment provider or transaction record) might be evaluated under the active user's environment context, it fetched the journal from the user's currently active company (allowed_company_ids), disregarding the actual company related to the sale order or the transaction.

Desired behavior after PR is merged:
The invoice journal search uses the correct company context (e.g., order.company_id.id or the specific company linked to the payment record), ensuring that the sale order reference is processed using the appropriate journal from the correct company, regardless of which company the logged-in user is currently switched into.




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

Forward-Port-Of: odoo/odoo#269558

[FIX] hr_appraisal: fix auto-fill of employee in appraisal

Bug production:
    1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top -> employee_id is not coming

Bug cause:
    1 - When we press smart button of appraisal action_send_appraisal_request in hr_employee is called.
    2 - It send the self.env.context as a context and active_model and active_id.
    3 - In hr_appraisal, _get_default_employee function calculates the default employee_id by looking to context and especially by looking to active model and id.
        3.1 - If active_model is hr.employee and there is active_id, it finds the employee automatically (that is the case when we are coming directly from employee -> smart button hr_appraisal)
        3.2 - When we first click to department and then we click to employee and smart button, active_model is hr.department and default_employee_id cannot be calculated in default version.

Bug solution:
    1 - I have passed the default_employee_id to the context in action_send_appraisal_request function. Since we know the employee in the action_send_appraisal_request function we can pass it directly.

task - 6285434

Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.

Forward-Port-Of: odoo/enterprise#120424
Forward-Port-Of: odoo/enterprise#119701

Steps to reproduce
---
1. With Accounting installed, import a bank statement CSV that has separate Debit and Credit columns using number separators (e.g. a line with "1.234,56").
2. Map the columns to Debit and Credit and import.

The imported amounts are multiplied by 100: "1.234,56" is imported as 123,456.00.

Issue
---
This only happens when both `account_bank_statement_import_csv` and `account_bank_statement_extract` are installed, which is the default in any Accounting database since both modules are auto-installed.

`account_bank_statement_extract` turns debit and credit into real Monetary fields on `account.bank.statement.line`:

https://github.com/odoo/enterprise/blob/af863c5a53d0ab50fe67cb9ea910391d4a1979dd/account_bank_statement_extract/models/account_bank_statement_line.py#L7-L8

Because they are now real fields, the generic importer already converts those columns to floats:

https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/base_import/models/base_import.py#L1281-L1285

The CSV statement wizard then parses the same columns a second time:

https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L92-L93

The first pass correctly reads "1.234,56" as "1234.56", but the second pass sees a lone dot, mistakes it for the thousands separator, strips it, and produces 123456. The wizard now parses debit and credit only when they are virtual fields, so when they are real fields the values parsed by the generic importer are reused instead of being parsed twice.

Without `account_bank_statement_extract`, debit and credit exist only as virtual import fields, so the generic importer skips them and the wizard parses them once. That is why the regression stays hidden until the extract module is present.

opw-6227083
---

Forward-Port-Of: odoo/enterprise#118979

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Steps to reproduce:
- Start from a database where the eCommerce app is not installed.
- Open the website configurator.
- In the first step, choose "I want an eCommerce".
- In the Pages and Features step, select all Pages.
- Select a theme that adds an eCommerce category snippet, for example "Treehouse".
- Build the website. => During the first `configurator_apply`, `website_sale` is installed
   after the theme and the configured menu items are already created.
=> The homepage rendering then needs a `website_sale` configurator
   snippet template requested by the theme, but it was not generated
   during that first call.
=> The client retries `configurator_apply`. It now succeeds because
   `website_sale` is fully installed, but page and menu creation runs
   again and duplicates the menu items.

Before this commit, primary snippet template generation only read the manifest of the module being generated. When `website_sale` was installed from the first `configurator_apply`, it did not see addon snippets declared by the already installed theme. The first call could therefore fail while rendering the homepage after pages and menus were created.

After this commit, generation also reads installed theme addon snippets that target the module being generated. The `website_sale` configurator templates requested by the selected theme are created before the first homepage rendering, so `configurator_apply` does not retry after creating menu items.

task-5973739

Forward-Port-Of: odoo/odoo#261022

Have an x2many field displayed as a list in a form view. In the arch, the x2many form view **isn't** inlined. In that x2many form view, there's a properties field.

When a record is clicked, `extendRecord` is called to add the new fields (those of the form) into `this.fields` and those fields are fetched. If there're properties in the property definition, fake fields are created to represent them (see `_processProperties`). However, because of extendRecord, the static list and the record don't share the same reference to the `fields` object. As a consequence, the `fields` object of the static list isn't updated with the fake property fields.

If the user closes the record, and opens/closes it again, there's a crash, because the record is re-updated with the fields of the static list, and thus doesn't know about those property fields anymore.

This commit fixes the issue by ensuring that we keep the same `fields` object when extending a record, s.t. the list and all its records always share the same object.

Bug originally reported here: https://github.com/odoo/odoo/pull/268312


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

Forward-Port-Of: odoo/odoo#269717

Version:
----------
- 18.0+

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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

Forward-Port-Of: odoo/odoo#269971
Forward-Port-Of: odoo/odoo#262396

### Steps to reproduce:
- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 2 x COMP (lot tracked)
- Put a lot for 6 units in of COMP in stock
- Create and confirm an MO for 5 units of FP
- Set the quantity producing on the MO to 1, requiring 2 of the 6 available units of COMP
- Validate the MO and create a backorder for the remaining quantity.
#### > The consumed qty on the main MO is of 0 units rather than 2.

### Cause of the issue:

Since the component is tracked, and since the pbm move was backordered, the move quantity will not be automatically set when setting the `qty_producing`:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1405-L1411 And in particular, the move is not picked as it would if the product was untracked or if the pbm move was not backordered:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1421-L1427 And, since the move will not be picked at any other point in this flow, the move will be unreserved during the `button_mark_done`: https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L2216 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1895-L1896 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1901

opw-6128575

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

Forward-Port-Of: odoo/odoo#269235

### Steps to reproduce:

1. Create a product tracked by lot
2. Put 10 units in WH/Stock without lot
3. Inventory > Operations > Adjustments > Physical Inventory
4. Select the line referring to your product and request an inventory count + Show Expected Quantity
5. Open the barcode app > Count Inventory
6. Scan your product
#### > The line is not selected, in particular, next scans will be re-interpreted as product scans rather than new serial creation for your product.

### Cause of the issue:

Scanning your product search a line to select if any: https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1432-L1435 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1630-L1632
However, the `findLine` will fail since this method calls the `_canOverrideTrackingNumber` to determine if the lot of the barcodData matches the one of the line:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L1859-L1863
But, the override of the `_canOverrideTrackingNumber` method for the `BarcodeQuantModel` does not handle the absence of lotName in the barcodeData correctly as it does not consider that a line without lot can be overridden by an empty lotName:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_quant_model.js#L729-L731
Note however that the super call does:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/stock_barcode/static/src/models/barcode_model.js#L795-L798

### Issue 2:

### Steps to reproduce:

- Steps 1 -> 5
- Click on your product line to select it
- Scan a new lot to add one new unit referring to that lot
- Confirm (1)
- Apply Now
#### > User Error: Quant's editing is restricted, you can't do this operation

Since the line is selected, you have a currentLine during the `processBarcode` and hence the existing line will be updated using the `lotName``:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L1560-L1584 However, writing on the line will then try to write on the related quant during the validation process which will be forbiden since we are not allowed to change the lot of an existing quant:
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/stock/models/stock_quant.py#L351-L360 Now, the issue is that actually due to the nature of the line and of the barcode data, the line lot is not expected to be updated but rather a new line is expected to be created:
https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/stock_barcode/static/src/models/barcode_model.js#L795-L798

Additional issue:

Fixing issue 1 and 2 highlight and other issue of the validation process:

- Steps 1 -> 6
> The line gets selected
- Scan a newlot
> a new subline is added referring to 1 unit of your new quant
- Confirm (1) > Some serials where not counted, set them as missing
#### > Check your quants: the 10 unit lotless quant was not updated but a new quant for 1 units was created for your newlot

### Cause of the issue:

Applying all quantities is expecting to toggle them as counted before applying to update the existing quants:
https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L72-L82 https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L287-L296 However, only line tracked by serial numbers are set as counted: https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/stock_barcode/static/src/models/barcode_quant_model.js#L60-L63

opw-6212923

Forward-Port-Of: odoo/enterprise#118373

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Forward-Port-Of: odoo/enterprise#119217

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#119370

Description of the issue/feature this PR addresses:
Fixes an issue where the sale order reference computation was fetching the invoice journal based on the logged-in user's current company instead of the company associated with the specific payment provider or transaction context. This caused incorrect reference processing or errors in multi-company environments when a user was logged into one company but processing an order from another.

Current behavior before PR:
The function searches for the account.journal using self.company_id.id. Since self in this context (likely a payment provider or transaction record) might be evaluated under the active user's environment context, it fetched the journal from the user's currently active company (allowed_company_ids), disregarding the actual company related to the sale order or the transaction.

Desired behavior after PR is merged:
The invoice journal search uses the correct company context (e.g., order.company_id.id or the specific company linked to the payment record), ensuring that the sale order reference is processed using the appropriate journal from the correct company, regardless of which company the logged-in user is currently switched into.




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

Forward-Port-Of: odoo/odoo#269558

**Steps to reproduce on a new db:**
(bug also reproducable on runbot but the impact 
is less easy to compute because of influence of other
existing companies)

- create a new company as company 2 and use the existing 
default company as company 1.
- create a warehouse for both company
- for both comp, in settings for the 'fiscal localization' set 
Package : Generic Chart of account, if not already set
(to have account journals).
- for both comp, in settings for inventory valuation set 
'periodic' and for periodic valuation set 'daily'

From company 1 : 
- create a storable product with standard price method and 
set a cost of 30
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 30 
  - the variation lines have a balance of 30
  - all of this is expected

From company 2 :
- change the cost of the product to 10
- set an onhand quantity of 1
if you navigate to 'inventory valuation' you'll see that : 
  - initial balance is 0
  - ending stock is 10 
  - the variation lines have a balance of 10
  - all of this is expected
 
From any company :
- navigate to 'scheduled actions' and select the action 
'Stock Account: Inventory Valuation Closing'
- click on 'Run Manually'
- navigate to 'inventory valuation'

**Current behavior:**
with company 1 selected :
  - the initial balance is now 30 
  - ending stock still 30
  - no variation lines
  - the initial balance was correctly increased by the closing entry

with company 2 selected: 
  - the initial balance is now 40
  - the ending stock is still 10
  - the variation lines credit 30 in stock valuation

In company 2 the closing entry debitted 40 in stock valuation 
instead of 10 which increased the initial balance to 40 instead of 10

If you open the journal items you'll find the closing amls have a 
balance of 40 instead of 10

**Cause of the issue:**
The _cron_post_stock_valuation() method 
calls action_close_stock_valuation() on both companies
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L143-L144

This methods calls _action_close_stock_valuation
with a context modified with only self.env.company.ids
in 'allowed_company_ids'
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L56

This is needed because inside stock_value() we use 
the total value of the product 
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/res_company.py#L92
which will be the sum of the values of the product 
for each company inside allowed_company_id
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/addons/stock_account/models/product.py#L274
So in case action_close_stock_valuation() was called from 
the 'generate entry' button from the inventory valuation view
we need only the main company selected to be in the
'allowed_company_ids' so that the inventory value is computed 
based only on this company (as is the accounting value).

The problem is that this does not work when calling the 
method from _cron_post_stock_valuation because then
there is no 'allowed_company_ids' in the context (because it was
called from _process_job() with a new env).
so self.env.company will be the company of the user 
which will be company 1.
https://github.com/odoo/odoo/blob/bfa39854e56da4bf23295d62f63d66973ad0d78e/odoo/orm/environments.py#L243

Therefore when _action_close_stock_valuation will be 
called on company 2, in the context, allowed_company_ids 
will be company 1. Then, when computing 'products', with_company() 
will add self (company 2) to the context.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L151-L152
So stock_value will return the sum of the total_value 
of each product for company 1 and company 2 which is 40 (instead 
of 10 for just company 2)
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L242

We then create the closing accounting entry to match the 
accounting value with the stock value, which explains why 
the new initial accounting balance of company 2 is 40.

**fix:**
We set the context using self instead of self.env.companies
This makes more sense as both in the cron use case and 
the generate entry use case the stock value we want is the 
one of the company in self. 
- In cron use case, it's obvious as the method is called 
in a for loop on each company
- In the generate entry use case, self will also be the main 
company, because it's called, in actionGenerateEntry, 
on this.companyId 
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L75
which is computed based on the get_report_values
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L21
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/static/src/stock_valuation/controller.js#L28-L30
Which returns the main company
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/report/stock_valuation_report.py#L29


Most importantly, this is also aligned with how the accounting 
values are computed.
https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock_account/models/res_company.py#L103-L105


opw-6237402

Forward-Port-Of: odoo/odoo#266932

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Forward-Port-Of: odoo/odoo#266894

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#269973
Forward-Port-Of: odoo/odoo#265169

Steps to reproduce:
- Set up a Mexican company (MXN, l10n_mx_edi) able to send CFDI.
- Create a Gift Card / eWallet program (e.g. 680 MXN).
- Create a sale order with two products (e.g. 400 and 300).
- Apply the gift card so the first product is fully covered.
- Deliver, invoice, confirm and send to the SAT.

Issue:
The product entirely covered by the gift card (net amount = 0) is missing from the generated CFDI. The SAT requires every delivered product to appear in the XML for inventory and tax traceability, so omitting the line makes the document no longer reflect the transaction.

The line was dropped because the negative-line dispatching (`_dispatch_negative_lines`) moves a positive line that is fully consumed by a negative one into `nulled_candidate_lines`, and those were never re-added to the CFDI lines.

Simply re-adding them is not enough: a fully-discounted line has a tax base of zero, and the SAT rejects a Traslado/Retención with Base = 0 (CFDI40174 / CFDI40181).

Fix:
Re-add the nulled candidate lines so the concepto is kept with Descuento == Importe, and, when the line net is zero, drop its tax breakdown so it is reported as "No objeto de impuesto" (ObjetoImp '01') without an Impuestos node. This matches the behaviour already present in later versions.

opw-6062845