**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

Forward-Port-Of: odoo/odoo#246699
Forward-Port-Of: odoo/odoo#246084

**Problem:**
when there is multiple pages for the avco reports
the total value and quantity are not correctly computed

**Steps to reproduce:**
- create an avco storable product with a cost of 10
- create and validate 3 in moves for a quantiy of 1 each
- navigate to Inventory/ Stock and search your product
- click on the unit cost
- (see how the total quantity is 3 and total value is 30)
- change the view to display only the first 2 records
(write 1-2/4 on the top write)

**Current behavior:**
the total quantity is now 2 and total value 20

**Expected behavior:**
it should still be 3 and 30

**Cause of the issue:**
inside _compute_cumulative_fields, we start with a 
total_value and total_quantity of 0, then those variables 
are increased or decreased by each record in records
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L94-L104
but records is computed based on self which contains
the lines displayed on the view
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L91

**fix**
I need to add an if statement to avoid writing on the records
not displayed on the view because this causes an access_error

opw-5421925

Forward-Port-Of: odoo/odoo#244070

### Steps to reproduce:

- In the settings enable: Batch, Wave & Cluster transfers
- Inventory > Configuration > > Warehouse Management > Operation types
- Enable Auto-batches, Batch grouping by partner on Delivery orders
- Create and confirm a delivery for 2 units of a storable product that you do not have in stock.
- Change the quantity of the move to 1 unit
#### > The delivery is not auto-batched

### Expected behavior:

As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver.

### Cause of the issue:

The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow:
First at confirmation:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`.

opw-5441718

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

Forward-Port-Of: odoo/odoo#246164
Forward-Port-Of: odoo/odoo#245542

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#244758
Forward-Port-Of: odoo/odoo#238989

Current behavior:
When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the last selected attribute value is kept in the URL of the pager.

This happens because the `/shop` controller processes query parameters using a standard Python dictionary (**post). Since a dictionary cannot hold duplicate keys, an URL like `?attrib=1&attrib=2` is reduced to `{'attrib': '2'}`, losing all previous values.

Steps to reproduce:
1. Install `website_sale`.
2. Reduce "Products per Page" (e.g., to 4) to easily trigger pagination.
3. Go to the /shop page.
4. Select a first attribute (e.g., Color: White).
5. Select a second attribute (e.g., Size: M).
6. Ensure the result spans at least two pages.
7. Click on page "2".
8. Observation: The second attribute filter is lost, and the product list changes incorrectly.

Fix:
Ensure that `attribute_values` are stored as a list within the `url_args` passed to the pager. Since Odoo's `website.pager` uses `url_encode` internally, passing a list of values for a single key correctly generates repeated parameters in the resulting URL (e.g., `attrib=1&attrib=2`).

opw-4152637

Forward-Port-Of: odoo/odoo#245784
Forward-Port-Of: odoo/odoo#244941

Before this commit, the channel member actions were hard to find:
- Click on Members panel.
- Click on Member to open popover card.
- Click on "..." in top-right corner of card.

This is hard because only this avatar card from this menu has the "..." button, and the actions are hidden in this menu. This is easy to miss since avatar cards in message list or other places don't have this "...", and since the actions are hidden there many people could easily miss these actions.

This commit improves the visibility of action by their showing as a "..." on the member item on hover in the "Members" panel. This works like the "..." button in the discuss left sidebar, where the button is shown on mouse-hover. Mobile view (small or mobile device) shows the button all the time next to member, making the discoverability of the action very clear.

Task-5871730

Before / After
<img width="589" height="385" alt="Screenshot 2026-01-23 at 14 45 17" src="https://github.com/user-attachments/assets/bca66975-13cd-423a-a43d-9eb2be03741a" />
<img width="249" height="270" alt="Screenshot 2026-01-26 at 11 56 09" src="https://github.com/user-attachments/assets/edfe34c9-6b4c-4394-b532-7f79f9653b4a" />


----

This PR also makes channel member actions available in guest items, so we can now "Remove Member" on guests too.

<img width="252" height="296" alt="Screenshot 2026-01-27 at 18 25 54" src="https://github.com/user-attachments/assets/ee4b1271-0529-4e96-bda1-e621d7592555" />

Description of the issue/feature this PR addresses:

Fixes timer not showing to participants of a live session after submitting an answer.

Current behavior before PR:

Steps to reproduce:

Create a Survey with two questions of any type.
Set some Question Time Limit on both.
Create Live Session for that Survey.
Access Live Session as a participant.
Start Survey as the host.
The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question.
Bug: timer for the second question does not appear to the participant.

Desired behavior after PR is merged:

Fix:
The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function.
Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function.
This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress`
and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'`
Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received.

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

Forward-Port-Of: odoo/odoo#246789
Forward-Port-Of: odoo/odoo#241086

Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.

opw-5496999
opw-5401425

Forward-Port-Of: odoo/odoo#244052

_______________________________________
## Short functional explanation of the error
Let's say we have a products that has 2 suppliers. In the list of suppliers, the first one set has an expired date. If we generate a PO from an SO with the MTO route, the assigned supplier for this product will be the first one set in the list, therefore having an expired date.

## Reproduction Steps
1. Go to Inventory > Configuration > settings. Check the option Multi-Step routes.
2. Click on Configuration > routes and unarchive the Replenish On Order (MTO) route.
3. Create or use an already existing product. Go to the Inventory tab, and under Operations, check the routes Replenish on Order (MTO) and Buy.
4. Click on the Purchase tab. There, set a first vendor for which the end date is earlier than today. For the second one, set an end date for which the date is later than today.
5. Go to Sales and create a new quotation. Set a customer and add a line with the product you just set. Click confirm. A smart button 'Purchase' should appear. Click on it.

### Expected behavior
The assigned vendor of the PO should be the second vendor as it isn't expired yet.

### Unexpected behavior
The assigned vendor is the first vendor, expired.

## Origin of the issue
When generating a PO from an SO, the partner is the person ordering the product, not the vendor. Therefore, when this code is executed:

https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L62-L66

no corresponding supplier is found, as
```self._get_partner_id(procurement.values, rule)``` returns the customer
and not the vendor. This leads us to the fallback:
https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L68-L72
which doesn't take into account the end date of vendors.

__
opw-5030849

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#245313
Forward-Port-Of: odoo/odoo#225684

Description of the issue/feature this PR addresses:

Fixes timer not showing to participants of a live session after submitting an answer.

Current behavior before PR:

Steps to reproduce:

Create a Survey with two questions of any type.
Set some Question Time Limit on both.
Create Live Session for that Survey.
Access Live Session as a participant.
Start Survey as the host.
The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question.
Bug: timer for the second question does not appear to the participant.

Desired behavior after PR is merged:

Fix:
The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function.
Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function.
This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress`
and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'`
Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received.

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

Forward-Port-Of: odoo/odoo#246147
Forward-Port-Of: odoo/odoo#241086

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#105405
Forward-Port-Of: odoo/enterprise#100749

### Issue:
When creating a subscription with several lines whose quantities add up to zero, the next invoice date is not updated and set to the start date.

### Steps to reproduce:
- Install 'sale_subscription'
- Create a new Subscription with two lines and a tart data several months in the past
- One with a quantity of 1 and a higher price
- The other with a quantity of -1
- It can be the same service product with invoicing based on ordered quantity
- Confirm the Subscription
- Click "Create Invoice" and confirm the invoice
- Back to the Subscription, the next invoice date was not updated.

### Cause:
In `_get_max_invoiced_date()` to compute the invoiced periods we check the quantity corresponding to this period. But if an invoice has two lines with opposite quantities, they will cancel each other out at this line:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move_line.py#L131

So the method will return not return the date in `invoice_dates`.

Later, if `_get_max_invoiced_date()` returns nothing for `last_invoice_end_date` then `next_invoice_date` is set to `start_date`:

https://github.com/odoo/enterprise/blob/c2ac44f492ec53083864f07ff5bfbff9458ddf2a/sale_subscription/models/account_move.py#L66-L67

### Solution:
The goal was to not include invoices that were fully refunded for the `last_invoice_end_date`. This is why `_get_max_invoiced_date()` substract the quantities from refunds.

To make this work we can take the absolute value of the quantity returned by the compute method before giving it the wanted sign based on if it's an invoice or a refund.

opw-5360930

Forward-Port-Of: odoo/enterprise#103705

l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended

**STEP TO REPRODUCE**
1. Create a invoice with:
    - product price = 72.89
    - discount = 10%
    - tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.

This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
    - for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
    - changes in how the negative lines are dispatched.
    - using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.

Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).

Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434

opw-5382423

Forward-Port-Of: odoo/enterprise#105615

**Steps to reproduce:**
* Install the **Accounting** and **partner_commission** modules.
* Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab.
* Create and confirm a customer invoice with multiple lines (e.g. 750, 750).
* Then go to **Dashboard → Transactions**, create a new transaction (e.g. 750) and reconcile it with the created invoice.
* Create a **credit note** from the invoice and confirm it.
* Open the contact and access **Purchase Orders** from the stat button.

**Observed behavior:**
* Only the commission line from the original invoice appears in the partner purchase order.
* No **negative commission line** is created for the credit note.

**Cause:**
* Credit notes reused the original commission linkage instead of generating a dedicated commission entry.
* This prevented commission reversal from being recorded for refunds.

**Fix:**
* Generate a **separate commission line** with a negative amount for each credit note.
* Assign a dedicated `commission_po_line_id` to credit notes.
* Copy only the `referrer_id` to credit notes, not the original commission line reference.

opw-5357773

Forward-Port-Of: odoo/enterprise#103328

Steps to reproduce:
-------------------
1. Install sale_subscription with demo data.
2. Create a new subscription and add a Section and a Subsection.
3. Add a recurring product (Invoice_policy = 'order') and configure a recurring plan.
4. Confirm the subscription and click Preview.

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
`_get_invoiceable_lines` does not treat subsection lines as children of their parent section.
As a result, `lines_to_report` contains a subsection without its corresponding section,
leaving current_section set to None and causing the traceback when accessing current_section.collapse_prices.

Solution:
---------
Ensure subsection lines are appended together with their parent section
when an invoiceable line is encountered

Related community PR: https://github.com/odoo/odoo/pull/241634

opw-5367739

Forward-Port-Of: odoo/enterprise#103686

After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left
join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records.

In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the
the relevant dates not all dates between the min starting date and max ending date
of all slots.

Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c

The testing cardinality of the tables:
`planning.slot` 7178 rows
`hr.employee` 332 rows
`resource.resource` 332 rows
`resource_calendar_leaves` 4061 rows
`account_analytic_line` 267376 rows
`generate_series()` will produce 206417 rows

| Before                                  | After |
|-----------------------------------------|-------|
| Query keep being active with no results | ~2s   |

opw-5089052

Forward-Port-Of: odoo/enterprise#105696
Forward-Port-Of: odoo/enterprise#102283

To reproduce:
=============
1. Create an new Overtime Ruleset using these options:
- The rule is based on: Timing
- With tolerance in favor of the employer of: 00:00
- If the employer works: Outside of a specific schedule
- Schedule: 40/hour work week
- Pay extra hours: with rate of 100%
- Work entry type to use: Overtime Hours
- Give back as time off
2. Create an employee or edit an existing employee to use the overtime ruleset in the settings of the form view of the employee.
3. Navigate to attendance and create a new entry for that employee.
4. Make clock in time and clock out time run through a Friday. For example:
Clock in: 12/22/2025 12:00:00 AM
Clock out: 12/26/2025 6:30:00 AM
5. Then edit the entry to run through the Saturday or Sunday. For example:
Clock out: 12/27/2025 6:30:00 AM
6. Navigate to Work Entries and navigate to the month or week that that entry was made at.
7. There should be a traceback error for more than one overtime line related to that specific entry.

Problem:
========
When allocating multiple overtime lines to consecutive time periods, the
`_set_real_overtime_intervals` method was merging them into single intervals
with recordsets of overtime lines (e.g., hr.attendance.overtime.line(102, 106, 103, 104))
instead of keeping each overtime line in its own separate interval. This happened
because the allocation logic incorrectly calculated the position within intervals
and subtracted the wrong duration from remaining overtime, causing the `|=` merge
operator to combine adjacent allocations into recordsets.

Solution:
=========
Refactored the overtime allocation loop to maintain singletons

opw-[5468598](https://www.odoo.com/web#id=5468598&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#105555

…eductions

Currently, if users modify the MX Payroll structure in order to have no deductions in the final payroll, CFDI validation for the payroll entry will fail.

Steps to reproduce:
- Set up Payroll Structure "Mexico: Regular Pay" with Salary Rules:
  - Used subsidy:
    - Code: SUBSIDY
    - Category: Allowance
    - CFDI Concept: (O02) Employment Subsidy (Effectively Delivered to the Worker)
  - Deduction:
    - Code: DEDUCTION
    - Category: Deduction
    - CFDI Concept: (D04) Others
  - Net Salary:
    - Code: NET
    - Category: Net
    - CFDI Concept: (P01) Salaries, Wages, Stripes, and Day Labor
    - Formula: `result = payslip.paid_amount`
- In Payroll > Payslips, Click 'New Off-Cycle'
- Select employee, compute sheet, create draft journal entry and post it
- Back to the payslip, mark as paid and generate CFDI

Issue:
CFDI Validation will fail with error
`Code : 301 Message : Error en complemento Nómina. [Error #NOM38] El atributo Nomina.TotalDeducciones, no debe existir. Folio: 0002. Serie: SLR/2025/12.`
It occurs because, according to the official specs [1] attribute `TotalDeducciones` should not be reported in case there are no deductions

[1] http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/GuiallenadoNomina311221.pdf

opw-5348789

**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
 - The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice is automatically created and amount_paid is also updated.
- At [1], the logic subtracts both the total invoice amount and amount_paid from the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is encountered again, it should be skipped to avoid double-counting.

[1]https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime

**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.

This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`

**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.

related PR: https://github.com/odoo/odoo/pull/205594

opw-5245367

Steps to reproduce:
-------------------------
1. Install Timesheets and Time Off.
2. Create an employee and create a Time Off in the past week, then approve it.
3. Open All Timesheets for that employee and observe the overtime indicator.
4. Enable a multi-company environment by creating another company.
5. Remove the `company_id` from the employee’s working schedule (40h/week).

Issue:
----------
The overtime indicator shows an incorrect value.
It displays 40h instead of the expected 32h.

Cause:
----------
Since there is no company defined on the working schedule, `self.company_id.id` becomes False.
The actual leave records are linked with the employee’s company, so the search results
in an empty recordset. As a result, the employee leave is ignored.

Solution:
--------------
Take the resource company into account when building the domain,
before falling back to the calendar company.

opw-5499737




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

#### [FIX] account_edi_ubl_cii: `DeliveryParty` export

Follow-up to commit 0b3c12670e5f606a36e7d94982656ed998d67322

In the aforementioned commit we added the `DeliveryParty` node under
the `Delivery` tag.

But there are 2 remaining issues with it.
- In BIS 3.0 the `DeliveryParty` tag has only one child `PartyName` (which is mandatory)
  https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-Delivery/cac-DeliveryParty/
  This was done for the version with the new helpers (`account_edi_ubl_cii.use_new_dict_to_xml_helpers`)
  but not the version without the helpers.
- For UBL 2.0 the `DeliveryParty` tag was added for the version
  without the new helpers but not the version with the helpers.

That is fixed in this commit.

#### [FIX] account_edi_ubl_cii: export intrastat commodity code

Currently we do not export the intrastat commodity code of products.
But a field for it is available after installing `account_intrastat`.

After this commit the intrastat code is exported in the tag
`cac:CommodityClassification/cbc:ItemClassificationCode[@listID="HS"]`.

#### [FIX] account_edi_ubl_cii: update AllowanceChargeReasonCode for EPD

Currently we are using the code `66` ("New outlet discount") as
`AllowanceChargeReasonCode` for early payment discounts.
After this commit we use `64` ("Special agreement") since it seems
more fitting / general.

#### [FIX] account_edi_ubl_cii: BEG test cases: minimal invoice

This commit adds a test corresponding to the test case "Testcase01" / "Minimal invoice"
from the business expert group.

https://efacture.belgium.be/fr/article/business-expert-group-ressources

#### [FIX] account_edi_ubl_cii: BEG test cases: multi-currency

This commit adds the following nodes to the BIS 3.0 XML in case
the document currency is different from the company currency.
- `cbc:TaxCurrencyCode`: gives the company currency (it is supposed to
  be the currency in which the taxes for the invoice will be paid)
- A second `cac:TaxTotal` node that only contains a `cbc:TaxAmount` node
  giving the total tax amount in company currency / the currency specified
  by `cbc:TaxCurrencyCode`.

See here:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_vat_accounting_currency

Some local formats had this information already. The logic was removed
there. The  affected modules were:
- `l10n_anz_ubl_pint`
- `l10n_jp_ubl_pint`
- `l10n_my_ubl_pint`
- `l10n_ro_edi`

See also here:
- https://docs.peppol.eu/poac/aunz/pint-aunz/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/my/pint-my/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/sg/2024-Q2/pint-sg/bis/#_invoice_totals_in_gst_accounting_currency

This is in line with the following test cases from the business
expert group. They were added as tests in this commit
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
- "Testcase 10": "Invoice in USD and EUR vat"
- "Testcase 11": "Invoice in USD and EUR vat and 2021"kkjkkj

#### [FIX] account_edi_ubl_cii: PaymentMeansCode from payment method

Currently the `PaymentMeans/PaymentMeansCode` node is filled
w/o considering the "Preferred Payment Method Line" (`preferred_payment_method_line_id`)
set on the move.
We choose
- for invoices: 30 ('credit transfer') or ZZZ ('mutually
defined') depending on whether a bank account is set.
- for bills: 57 ('standing agreement')

After this commit we use the Code of the Payment Method of the
"Preferred Payment Method Line" to determine the the PaymentMeansCode

We also add the following Payment Methods so that the user has more choices.
- Credit Card
- Debit Card
- Bankgiro
- Standing Agreement
- SEPA Credit Transfer

#### [FIX] account_edi_ubl_cii: BEG test cases: cash discount

Consier a paid invoice for which we granted an early payment discount.
in case the XML is generated after the invoice is paid (discounted amount)
we do not account for that fact in the XML generation.

The total amounts in the `cac:LegalMonetaryTotal` node are not adjusted
- The `cbc:TaxExclusiveAmount` and `cbc:TaxInclusiveAmount` and
`cbc:PrepaidAmount` should reflect the reduced amounts
- This is i.e. problmeatic for the `cbc:PrepaidAmount`. It would show
  the total (unreduced) amount of the invoice; more than was actually paid.

In the XML for an unpaid invoice there are
The `cac:AllowanceCharge` node(s) representing the potential early payment discount and
`cac:AllowanceCharge` node(s) raising the total back to the unreduced amount.
In case the early payment discount was applied the latter node(s) can
/ should be removed.

This is in line with "Testcase06" from the business expert group.
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
The following examples were added as tests in this commit
- "Testcase05": "Cash Discount" (not paid yet)
- "Testcase06": "Discount with cash payment" (XML generated after paid
and epd applied)

#### [FIX] account_edi_ubl_cii: sale order discount as AllowanceCharge

Global discounts from sales orders are just displayed as invoice
lines on the inovice.
Currently they are treated the same as any other invoice lines for
the XML generation.

But they should be displayed as an `AllowanceCharge` instead.
After this commit that is the case.
The `AllowanceCharge` node has
- `AllowanceChargeReasonCode`: `95`
- `AllowanceChargeReason`: `Global discount`

To add a global discount follow theses steps
1. Ensure `sales` is installed
2. Go to Settings -> Sales -> Pricing section and enable "Discounts"
3. On a Quotation / Sale Order there should now be a "Discount"
   right above the widget displaying the total amounts.
   Click it.
4. Select "Global Discount" and a percentage.
5. A line using a special discount product is added.
6. Click "Create Invoice"
7. The same line is now on the invoice

#### references
task-4885680

Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.

### Steps to reproduce

1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
   - Expected: The message is blocked.
   - Actual: The message is sent successfully.

### Root cause

The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.

1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.

### Fix

Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.

opw-5401789

Forward-Port-Of: odoo/enterprise#104556

Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.

### Steps to reproduce

1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
   - Expected: The message is blocked.
   - Actual: The message is sent successfully.

### Root cause

The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.

1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.

### Fix

Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.

opw-5401789

Description of the issue/feature this PR addresses: When you create a refund order, and there's many products theres an error

Current behavior before PR: Error, this is the traceback.
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/models.py", line 5896, in ensure_one
    _id, = self._ids
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/odoo/src/odoo/odoo/http.py", line 1803, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/src/odoo/odoo/service/model.py", line 152, in retrying
    result = func()
  File "/home/odoo/src/odoo/odoo/http.py", line 1831, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/odoo/http.py", line 2035, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/odoo/http.py", line 772, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 29, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 21, in _call_kw
    return call_kw(Model, method, args, kwargs)
  File "/home/odoo/src/odoo/odoo/api.py", line 484, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/home/odoo/src/odoo/odoo/api.py", line 469, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/home/odoo/src/odoo/addons/point_of_sale/wizard/pos_payment.py", line 70, in check
    order._process_saved_order(False)
  File "/home/odoo/src/odoo/addons/point_of_sale/models/pos_order.py", line 184, in _process_saved_order
    self._compute_total_cost_in_real_time()
  File "/home/odoo/src/odoo/addons/point_of_sale/models/pos_order.py", line 412, in _compute_total_cost_in_real_time
    lines._compute_total_cost(stock_moves)
  File "/home/odoo/src/odoo/addons/point_of_sale/models/pos_order.py", line 1537, in _compute_total_cost
    product_cost = self.refunded_orderline_id.total_cost / self.refunded_orderline_id.qty
  File "/home/odoo/src/odoo/odoo/fields.py", line 1148, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/odoo/models.py", line 5899, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: pos.order.line(16923, 16924, 16925)
```
Desired behavior after PR is merged:
No traceback error?


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