Currently, an error occurs when a user starts a new pay run.

Steps to Reproduce:

 - Install `l10n_hk_hr_payroll_empf` module with demo data. 
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Payslips` > `Pay Runs`.
 - Click `New`, remove the `period value`, and click `Continue`.

`TypeError: value.toFormat is not a function`

After this recent [commit] that changed the required field validation behavior, when the 
date field is empty and it attempts to serialize the date [1], which raises the error here [2].
Although the start and end date field is required, the ORM call is executed without the 
value for the date field.

This commit ensures that, similar to the base PayslipBatchFormController [3], the fields 
are validated before making the ORM call.

[commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8

[1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14

[2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536

[3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20

sentry-7207509338

Forward-Port-Of: odoo/enterprise#108885

Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Switch to `mobile view`.
- Now search for `drawer` in product search.

Issue:
---
- In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed.

Root cause:
---
- At [1], in the search template definition, the action attribute is missing in the search form.

Solution:
---
- Set the form action using keep(search=0) instead of leaving it undefined.
- This ensures that the search behaves correctly depending on the context (global or category-scoped).

[1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259

opw-5992052

---


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

Forward-Port-Of: odoo/odoo#254221
Forward-Port-Of: odoo/odoo#251694

Issue
-----
Orders created through the MPS aren't grouped in a single RFQ.

Steps to reproduce
-----
- Create a product with a vendor
- Add it to the MPS with the buy route
- Change the forecast to 2
- Order
- Change the forecast to 5
- Order
- Go to RFQs

> There are 2 different RFQs

Cause
-----
When doing `_run_buy`, no existing PO is found

https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102

so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15

However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB.

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10

This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime.

-----
Ticket:
opw-5171041

Forward-Port-Of: odoo/enterprise#106968

Problem:
When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch views to fix it.

Specifically:
- Filters can no longer be selected.
- Adding new activities throws UI errors (even if technically successful).

Cause:
The `getSelectedFolder` method returned undefined because the `searchPanel` logic was skipped. The Activity view does not display the `searchPanel`, so the model failed to run `_fetchSections` which retrieves the data used by `getSelectedFolder`. Under normal circumstances, the view relies on data already loaded by the Kanban or List views, but that data is unavailable here.

Solution:
- Force the search model to load the data explicitly, ensuring the view initializes correctly regardless of the `searchPanel` visibility. We kept the dependency upon `_fetchSections` rather than removing it, as it is required by the `search_model` to maintain other features like `breadcrumbs`.

- Add a test to verify the fix and prevent regression.

Co-authored-by: Pierre-Yves Dufays <pydu@odoo.com>
Co-authored-by: Charlier Florian <flch@odoo.com>

Currently, an error occurs when user tries to change simulation employee in salary simulation.

Steps to replicate:
- Install `hr_contract_salary_payroll` with demo.
- Open any employee (e.g.- Abigail Peterson).
- Click `Simulation` > Change `Yearly Employer Cost` to `Gross Per Month`.
- Try to change the Employee, error will occur.

Error:
```
  File '/home/odoo/odoo19/enterprise/hr_contract_salary_payroll/models/hr_contract_salary_offer.py', line 157, in _compute_offer_values_from_template
    version = offer._get_version()
              ^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo19/enterprise/hr_contract_salary/utils/hr_version.py', line 39, in hr_version_context_wrapper
    raise RuntimeError(
RuntimeError: Method '_get_version' must be called within a savepoint context. Use `hr_version_context(...)` context manager before calling this method.
```

Cause:
- The method `_get_version()` has the decorator `@requires_hr_version_context()` which makes the method to be callable  within a savepoint context for `hr.version` [1] i.e. it can only be called within a `hr_version_context()` block.

- As here the method was not called under the `hr_version_context()`it raises an error from [here].

Solution:
- Used the `hr_version_context()`block instead of savepoint (similar to [this]).

[this]: https://github.com/odoo/enterprise/pull/108005/changes#diff-97aeb940d5058abc95cb617e5a2015320c37e8d50a15cffc2c08eac1839ac16dL98-R100

[here]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L39-L42

[1]: https://github.com/odoo/enterprise/blob/626598abe4fdbc8391a428928e197e7735cbb298/hr_contract_salary/utils/hr_version.py#L14-L17

sentry-7335824597

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

Steps to reproduce the bug:
- Install voip and open the Odoo backend on Firefox
- Setup your voip settings
- Call your softphone number, thanks to your smartphone
- Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller.

This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*".

The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done).

Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists.

This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added.

[1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf
[2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0
[3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
[4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850

task-5902700

Forward-Port-Of: odoo/enterprise#110833

Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error

The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.

This commit improves error handling for both public and internal AI chat
by:

- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.

The following behavior will now be observed during error in the UI.

- Public AI chat:
  - Initial fetch failed: shows "oops" message
  - Stream interrupted:
    - Server handled: shows "oops" message
    - Server stopped: shows "Connection Interrupted" dialog

- Internal AI chat:
  - Initial fetch failed: show RPCError dialog
  - Stream interrupted:
    - Server handled: shows RPCError dialog
    - Server stopped: shows "Connection Interrupted" dialog

We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.

TASK-ID: 5886825

Forward-Port-Of: odoo/enterprise#105875

Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#250065
Forward-Port-Of: odoo/odoo#219081

Problem
------------------------
When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce:
1. Create allocated leave for employee and approve and validate it.
2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect.

Objective
---------------------------
Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable.

Solution
--------------------------
Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created.

Task: 5911074





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

Forward-Port-Of: odoo/odoo#253425
Forward-Port-Of: odoo/odoo#249527

Currently, certain `valid GSTINs` for Non-Resident taxpayers are not 
recognized by the partner `autocomplete` feature.

**Steps to reproduce:**
- Install the `l10n_in` and `partner_autocomplete` modules.
- Navigate to Settings > Users & Companies > Companies.
- Click `New` and set `Tax ID` to `9922JPN29001OSU`.
- Wait for 5–10 seconds.

**Observation:**
The partner autocomplete does not trigger, although it is valid and verifiable 
on the official GST portal: https://services.gst.gov.in/services/searchtp

**Root Cause:**
The issue was already fixed in core validation by PR [1], but the 
GSTIN validation logic used in partner autocomplete was not updated.

At [2], the GSTIN validation regex for NRI taxpayers only supports 
formats ending with `NRX` (X = any alphanumeric character). However, 
certain valid GSTINs follow a revised structure and therefore are not 
matched by the existing regex.

**Fix**:
This commit ensures that valid NRI GSTIN formats are accepted 
during validation by applying a fix similar to [1] to the partner 
autocomplete GSTIN validation at [2].

Related IAP PR: https://github.com/odoo/iap-apps/pull/1491

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

[2]:
https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52

Forward-Port-Of: odoo/odoo#253799

…f uom

**Problem:**
partial cogs are computed incorrectly when 
the uom of the invoice is different than the one 
of the product

**Steps to reproduce:**
-1) created a stored product with category std price perpetual
-2) set a cost of 1 and an on hand quantity of 12
-3) for the invoicing policy select 'delivered quantities'
-4) in the sales tab add the packaging 'pack of 6'
-5) confirm a sale order for 2 packs of 6

Problem A: 
-6a) validate the delivery
-7a) create and confirm an invoice for all the quanity 
-8b) on the delivery create a return for a quantity of 6 and validate
-9b) select 'create invoice' on the sale order
-10b) confirm the credit note

Problem B: 
-6b) change the quantity to 6 units on the delivery
-7b) validate with backorder
-8b) create and confirm an invoice for the delivered quantity
(1 pack of 6)
-9b) validate the back order
-10b) create and confirm an invoice for the remaining (1 pack of 6)

**Current behavior:**
Problem A : 
the cogs lines are : 
- crediting stock valuation of 54$
- debiting expenses of 54$

Problem B: 
the cogs lines are: 
- debiting stock valuation of 24
- crediting expenses of 24

**Expected behavior:**
Problem A:
the cogs lines should be: 
- debiting stock valuation of 6
- crediting expenses of 6

Problem B: 
the cogs lines should be: 
- crediting stock valuation of 6
- debiting expenses of 6

**Cause of the issue:**
Both problems have the same cause.
To compute the price unit for the cogs we call _get_cogs_value()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value, in the computation of the return value:
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L74
- price_unit is computed (in both use cases) using _get_cogs_price_unit
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L68
and is expressed in the uom of the product 
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/stock_move.py#L238-L240
- self.quantity is expressed in the uom of the invoice (pack of 6)
- cogs_qty is computed using _get_cogs_qty()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L66
and is expressed in the uom of the invoices (pack of 6)

Because of this, in both use cases, the computation is incorrect.

**fix:**
we use the uom of the product everywhere because _get_cogs_value()
should return the price unit in the products uom
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L51-L52

opw-5901706

Forward-Port-Of: odoo/odoo#250154

Currently on creating a time off that falls under a past contract still generates timesheet hours based on the employee's current contract.

### **Steps to Reproduce:**
1) Install `project_timesheet_holidays` module with demo data. 
2) Create an employee with two contracts/versions:
-  Past contract: 1 Jan 2025 to 31 Dec 2025 with standard 40h/week (8h/day).
-  Current contract: 1 Jan 2026 to indefinite with standard 35h/week (7h/day). 
3) Create and validate Time off for this employee in the past (e.g, 29 Dec 2025) 
4) Navigate to `Timesheets>All Timesheets`, search for this employee and switch
   list view for clear view.

### **Observed Behavior:**
7:00 hours are displayed on the timesheet, pulling from the employee's current active contract calendar.

### **Expected Behavior:**
8:00 hours should be displayed, as the leave date falls under the 40h/week past contract.

### **Root Cause:**
In the `_generate_timesheets`, the caledar values is fetched using `employee_id.resource_calendar_id` see[1], which always points to the employee's currently active calendar. Furthermore, this calendar is not explicitly passed to `_list_work_time_per_day` see[1], causing the method to fall back on the current default.

[1]- https://github.com/odoo/odoo/blob/c2595e47e3b36120f4c3da8bfe8c16f6c5969a70/addons/project_timesheet_holidays/models/hr_leave.py#L36-L55

### **Fix:**
Change the logic to use `leave.resource_calendar_id`, which correctly computes and retrieves the resource calendar active during the specific `date_from` and `date_to` of the leave and pass this `calendar` to `_list_work_time_per_day` to ensure the correct historical hours are used for timesheet generation.

**opw-5922695**

Forward-Port-Of: odoo/odoo#248207

## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896

## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.

## Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871

Issue
-----
Orders created through the MPS aren't grouped in a single RFQ.

Steps to reproduce
-----
- Create a product with a vendor
- Add it to the MPS with the buy route
- Change the forecast to 2
- Order
- Change the forecast to 5
- Order
- Go to RFQs

> There are 2 different RFQs

Cause
-----
When doing `_run_buy`, no existing PO is found

https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102

so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15

However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB.

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10

This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime.

-----
Ticket:
opw-5171041

Forward-Port-Of: odoo/enterprise#106968

Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469

Forward-Port-Of: odoo/odoo#235801
Forward-Port-Of: odoo/odoo#224002

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

Step to reproduce:
- Install point_of_sale
- Enable Identify Customer on the Card payment method
- Create an order with a customer and refund it
- Use Card as the payment method
- Close the POS session
- Go to Invoicing → Customers → Payments

Observation:
- Two payment records are created
- Both payments have payment_type = inbound
- The refund payment should be outbound

Cause:
- When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records
- The method does not adjust payment_type for refund transactions

Fix:
- Add helpers to swap destination and outstanding accounts
- Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority
- Ensure refund payments are created as `outbound`

few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e
https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228
https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8

opw-5437456


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

Forward-Port-Of: odoo/odoo#254079
Forward-Port-Of: odoo/odoo#247760

**Steps to reproduce:**
- Create a product tracked by lot, set it's price to 1000
- Create a quotation add a line with the created product and change the price to 1200
- Add another line with the same product and change it's price to 600
- Go to PoS and settle this quotation
- The lines' prices will be 1000 and 600 instead of 1200 and 600

**Why the fix:**
In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation.

This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set.

To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually.

opw-5223463

Forward-Port-Of: odoo/odoo#252480
Forward-Port-Of: odoo/odoo#238295

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#108666
Forward-Port-Of: odoo/enterprise#98701

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#110823
Forward-Port-Of: odoo/enterprise#96029

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#102335

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#110823
Forward-Port-Of: odoo/enterprise#96029

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#105115

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#99784

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#102335

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#105115

## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896

## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.

## Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

Issue
-----
Orders created through the MPS aren't grouped in a single RFQ.

Steps to reproduce
-----
- Create a product with a vendor
- Add it to the MPS with the buy route
- Change the forecast to 2
- Order
- Change the forecast to 5
- Order
- Go to RFQs

> There are 2 different RFQs

Cause
-----
When doing `_run_buy`, no existing PO is found

https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102

so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15

However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB.

https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10

This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime.

-----
Ticket:
opw-5171041

Forward-Port-Of: odoo/enterprise#110068
Forward-Port-Of: odoo/enterprise#106968

Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error

The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.

This commit improves error handling for both public and internal AI chat
by:

- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.

The following behavior will now be observed during error in the UI.

- Public AI chat:
  - Initial fetch failed: shows "oops" message
  - Stream interrupted:
    - Server handled: shows "oops" message
    - Server stopped: shows "Connection Interrupted" dialog

- Internal AI chat:
  - Initial fetch failed: show RPCError dialog
  - Stream interrupted:
    - Server handled: shows RPCError dialog
    - Server stopped: shows "Connection Interrupted" dialog

We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.

TASK-ID: 5886825

Forward-Port-Of: odoo/enterprise#110478
Forward-Port-Of: odoo/enterprise#105875

**Problem:**
When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.

**Steps to reproduce:**
1. Go to Settings app and enable debug mode
2. Navigate to Technical → Reports
3. Search for "slot_report"
4. Click "Add to print menu" button
5. Refresh the browser
6. Go to Planning app and switch to list view
7. Select a few planning.slot records
8. Click Print → Planning

**Current behavior:**
A blank or invalid PDF is generated.

**Expected behavior:**
Users should receive a clear error message directing them to use the correct print method from the calendar view.

**Cause of the issue:**
The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports.

**Fix:**
Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data.

opw-5477184

Forward-Port-Of: odoo/enterprise#108772
Forward-Port-Of: odoo/enterprise#105168

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed.

Solution:
- In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day.
- In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors.
- In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.

opw-5931665

Currently, an error occurs when the currency in the CAMT file differs from the bank journal currency.

**Steps to reproduce:**
- Install `account_bank_statement_import` module.
- Create a new country with EUR as currency and switch to it.
- In the Bank journal, upload this CAMT file: https://drive.google.com/file/d/1hKZIUPwdtcWAvxcoTLPFGpW-F5LnqDy9/view?usp=drive_link

**Error:**
`TypeError - unsupported operand type(s) for /: 'NoneType' and 'float'`

**Cause:**
When the `<Bal>` or `<Ntry>` amounts in the CAMT file are in a different currency, `get_value_and_currency_name` [1] cannot fetch a matching amount for the journal currency. This returns `None`, which leads to an invalid division during exchange rate computation.

**Fix:**
This commit handles missing currency data in CAMT files by raising a validation error instead of throwing a traceback.

[1] -  https://github.com/odoo/enterprise/blob/e7ae981000a4e53dc608c76605d8b2dbfb972c6a/account_bank_statement_import_camt/lib/camt.py#L632-L638

sentry-6874016845

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#102335

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

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

Forward-Port-Of: odoo/enterprise#106662

**Problem:**
compensation amls are not created for dropshipped 
products when there is a difference between the 
price of the PO and the price on the bill

**Context:**
For non dropship avco real time products: 
When you create a PO for a product @ 10
- stock interim received is credited of 10
- stock valuation is debitted of 10

And you then validate a bill for a price of 8
- stock interim received is debitted of 8
- account payable is creditted of 8

This leaves stock interim received with credit of 
2 and stock valuation is over valued by 2. 
So we create 2 extra account move lines 
- One debit of 2 for stock interim received
- One credit of 2 for stock valuation (or Expenses 
if the product is not in stock anymore because then 
it's the expense account which was over valuated)
nb: if the product is still in stock those 2 lines are 
created via stock valuation layer

In the case of a dropshipped product, the product 
is not in stock anymore so it should be creditting 
expense, but no extra amls are created at all.

**Steps to reproduce:**
- enable the "dropshipping" and "anglo saxon accounting" 
settings
- create a storable product with avco automated category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 10$ and 
confirm
- validate the dropship move
- create a bill for the purchase order
- set the price to 8$ and confirm
- navigate to journal items and search for your product

**Current behavior:**
no compensation account move lines were created

**Expected behavior:**
2 account move lines should have been created: 
- One debitting 2 in stock interim received
- One creditting 2 in expense

**Cause of the issue:**
*the following logic was introduced by* https://github.com/odoo/odoo/pull/126536
to create those extra amls and layers, 
_apply_price_difference() is called inside _post()
https://github.com/odoo/odoo/blob/32408a8dea43f57bba1a56c775ae228131720749/addons/purchase_stock/models/account_invoice.py#L129

There we have 2 problems : 

Problem 1: When fetching the layers linked to the account move line, 
we fetch both the incoming and the outgoing valuation 
layers because they are both linked to the dropship move. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L46
But we only want the incoming layer because the outgoing 
layer should not interfere with the bill.
nb: In a standard case like the one of the steps to reproduce, 
it would work to leave both layers, but : 
- it works for the wrong reasons : the quantity of the aml would 
first be consumed on the incoming 
layer and nothing would happen with the second layer as the 
quantity of the incoming layer is the same as the one of the aml.
- it would probably break in more complex use cases.

So it feels unnecessarily risky to leave it like that.

Problem 2: Inside _generate_price_difference_vals we call _replay_history
which returns two values that are assigned to two variables. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L82
The second variable, layers_and_invoices_qties is a default dict
which keys are tuples (layer L, invoice I) mapped with [the initial 
quantity invoiced by I on L, the remanining qty invoiced by I on L]
(here 'remaining' is related to invoice and has nothing to do with stock qties)
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L168-L171

So in our very basic use case, with a single invoice and a single layer, 
we should have a key (our layer, our invoice) linked 
to the value [1,1].
But this key is not in the dictonary. 

*The reason is the following :* 
inside _replay_history the parameter "history"
contains the layers and the amls (in our case 
1 layer and one aml which is self). 
Each layer is added to qty_to_invoice_per_layer
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L177-L178
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L191-L192

Then, for each aml: the layers are added to 
layer_to_consume, alongside their remaining 
quantity.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L215-L221
And for each layer which has a quantity billed
by the invoice, a key is added to layers_and_invoices_qties
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L222-L231

In our case, the move linked to the layer is the
dropship move so _is_in() will be false and 
the layer won't be added to layers_to_consume.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L220-L221
So the key will not be created.

*The consequence is the following:*
Later in _generate_price_difference_vals() we acces the value 
of this key (the key that should be there (layer, invoice)) 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L91
to get the invoiced qty which will later be used to determine which 
quantity is still in stock and which is out of stock (giving us 
the quantities for the compensation layers and amls) 
but as the key does not exist, invoicing_layer_qty will have a value of 0 
so we will exit the loop and no amls or svls will be created
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L92-L93

opw-5498878

## Issue
When clicking the *Preview* button on a draft invoice with an early discount payment term and no invoice date, the following traceback would appear:

```
File ".../addons/account/models/account_payment_term.py", line 274, in _get_last_discount_date
    return date_ref + relativedelta(days=self.discount_days or 0) if self.early_discount else False
           ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'
```

## Steps to reproduce
1. Install *Accounting* (`account_accountant`)
2. In Accounting > Configuration > Payment Terms, chose a Payment Term PT and toggle its *Early Discount* field
3. In Accounting > Customers > Invoices, create **but do not confirm** a new Invoice
    - Any Customer
    - Payment Term PT
    - Any Product
    - **No Invoice Date**
4. Click the *Preview* button
5. **A _500: Internal Server Error_ traceback appears**

## Cause
The traceback occurs in `AccountPaymentTerm._get_last_discount_date`:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/models/account_payment_term.py#L272-L274

where `date_ref` is False. This method is called by `AccountMove._is_eligible_for_early_payment_discount`:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/models/account_move.py#L2026-L2032

where `self.invoice_date` is False, because that field is not required, and the user can click the *Preview* button before a date is set. If the invoice is confirmed before being previewed, the issue does not occur, as confirming an invoice with no date will use today's date by default. This is done in `AccountMove._post`:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/models/account_move.py#L3967-L3971

## Fix
We can apply the same behavior as if the invoice was confirmed, and use today's date by default if no invoice date is given when trying to preview a draft invoice. The same logic should be applied to `_get_last_discount_date_formatted` for the date to be correctly evaluated in `account/views/report_invoice.xml`:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/views/report_invoice.xml#L252-L254

where `o.invoice_date` is also `False`, leading to `AccountPaymentTerm._get_last_discount_date_formatted` to return None:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/models/account_payment_term.py#L276-L280

which then displays the default date (`2024-01-01`) instead of *today + the early discount time limit*.

## Test
[The test](https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/tests/test_early_payment_discount.py#L92-L116) added by https://github.com/odoo/odoo/commit/572a6a82576a91005d9eedb673acfb088eb52cd1 and edited by https://github.com/odoo/odoo/commit/abe7fb51235dc3d47e6352505065fcd15100b21b does not follow the same execution flow as the *Preview* button. In the test case, the `reference_date` passed to the `is_eligible_for_early_payment_discount` method is `False`, skipping the problematic section of the condition. When using the *Preview* button, a `reference_date` is passed from `AccountMoveLine._get_epd_data` since https://github.com/odoo/odoo/commit/b9abe46c1492b09e369434e76ec8196c6b02dd19:

https://github.com/odoo/odoo/blob/6cc36886c612c7ed8878117637ee11bc6234d0e4/addons/account/models/account_move_line.py#L3287-L3295

opw-6008959

**Issue**: Importing a vendor bill from XML may lead to two taxes being applied to the same product if:
- The product exists in the database.
- It matches a product reference in the XML.
- The product has a default service tax (e.g. 22% S).

**Steps to reproduce**:
- Create a product with a service tax (22% S).
- Ensure you have a test XML referencing that product (see tests for an example).
- Go to Accounting > Vendors > Bills.
- Upload the XML file.
- Observe that the product line has two taxes: 22% G (from XML) and 22% S (from product).

**Cause**: Two taxes are applied because:
- The tax defined in the product: [Line 875 in `account_move_line.py`](https://github.com/odoo/odoo/blob/767341d4ec6aaa4fbd379827da4baf04e561eb32/addons/account/models/account_move_line.py#L875) which is triggered by [L1285C1-L1288C30 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1285C1-L1288C30)
- Then, the XML tax is also added: [L1012C1-L1016C44 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1012C1-L1016C44)

An attempt to reset the `tax_ids` after setting the product is already present:   [Line 1319](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1319), but it is ineffective because the original `tax_ids` are re-applied afterward, dues to side effects.

**Solution**: There are two possible ways to fix this:
- Make sure `move_line.tax_ids = []` works as intended
- Clean the `move_line.tax_ids` recordset.

Chose the second option as it's simpler and avoids modifying unrelated code

**Additional Notes**: The tax extracted from the XML does not take into account whether the product is a good or a service. For example, if the tax rate is 22%, the logic return taxes[0] if taxes else taxes will always return 22% G, even if the product should be taxed as 22% S.

To solve this, an extra domain filter is added based on the product type to ensure only applicable taxes are considered.

opw-4844469

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


BACKPORT OF #218309

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