### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#122519
Forward-Port-Of: odoo/enterprise#120740

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not
  updated

Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664 Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`, `workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664 https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629 However, many other cahnges can and are actually relevant.

Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Community: https://github.com/odoo/odoo/pull/269747

opw-6285878
opw-6261738

Steps to reproduce
1. Create two customer invoices that share the same VAT tax, with a payment term granting an early payment discount.
2. Create one bank statement line whose amount equals the sum of both invoices' discounted totals.
3. From the bank reconciliation widget, select both invoices and validate in a single batch reconciliation.
4. Open Accounting > Reporting > Tax Return, switch the variant to "Group by: Account > Tax".

Issue
The cash-discount expense row shows a Net base column equal to twice the real
discount base. The Tax column is correct.

The bank-statement reconciliation paths (set_line_bank_statement_line,
set_batch_payment_bank_statement_line, _reconcile_payments) loop over each
invoice and call _apply_early_payment_discount one invoice at a time. Each
call writes one discount base line and one discount tax line on the resulting
bank entry, so when two invoices share the same tax the bank entry ends up
with two pairs carrying the same (account, partner, currency,
tax_repartition_line_id, tax_ids).

The SQL that feeds the tax report at
https://github.com/odoo/odoo/blob/d7d0efd39a65bfb6fee307b661cd2523a6b8231d/addons/account/models/account_move_line_tax_details.py#L100
matches every base line of a tax with every tax line of that tax inside the
same move. With two pairs sharing one tax that turns two rows into four, and
SUM(base_amount) doubles. The Tax column does not double because the same SQL
redistributes each tax line's recorded amount across its matched rows so the
totals still add back to the original tax.

The payment register flow does not have this problem because it calls
_get_invoice_counterpart_amls_for_early_payment_discount once with every
invoice, and that helper already collapses duplicates with the merge key at
https://github.com/odoo/odoo/blob/f3b317310b84edb073009f7d15d7fec002f3ccf0/addons/account/models/account_move.py#L5082-L5093

opw-6199906

**Steps to reproduce:**
- Install `stock` and `purchase` modules
- Enable `Units of Measure and Packages`  and `Storage Locations` from setting
- Create a storable product with vendor purchase UoM set to "Pack of 6"
- Create and confirm a Purchase Order with quantity 6 Units
- Open the generated receipt
- Update a move line in Detailed Operations:
  - Quantity: 1
  - UoM: Pack of 6
- Save and open the Barcode view using smart button.
- Increase quantity using "+" button by 1.
- Exit barcode view without validating and refresh the receipt

**Issue:**
After refresh, the stock move quantity becomes 1 instead of 6,
while the move line correctly shows 1 Pack of 6.

**Cause:**

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162

- Exiting the barcode view triggers `__onExit()`, which forwards
`reserved_uom_qty` and `qty_done` from move lines to
`post_barcode_process()`.
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898

This `post_barcode_process()` function triggers `_truncate_overreserved_moves()`
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58

- During this flow, `_truncate_overreserved_moves()` updates the stock move quantity
by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns
this value directly to the move without converting it into the stock move UoM.

- In this case, both values are 1 because the move line is UoM is "Pack of 6"
Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units,
this conversion is skipped. As a result, the move quantity is incorrectly set to 1
instead of 6.

https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54

**Fix:**

- Convert quantities coming from barcode processing into the stock
move UoM before updating the move quantity, ensuring packaged
UoM values are preserved correctly.

----

opw-5472598

**Steps to reproduce:**
* Install the **Accounting** module.
* Unhide the **Deferred Start Date** and **Deferred End Date** (Deferred Date) fields on invoice lines.
* Create and post a customer invoice with deferred dates.
* Go to **Accounting → Review → Deferred Revenue Report**.
* Add an annotation to a deferred revenue line by clicking the **message** icon next to the account.
* Export the report in **XLSX** format.

**Observed behavior:**
* The export fails with a server error: `UnboundLocalError: cannot access local variable 'annotations_x_offset' where it is not associated with a value`

**Cause:**
* The variable `annotations_x_offset` is assigned inside the `for header_level_index, header_level in enumerate(options['column_headers'])` loop, which writes the "Annotations" column header for each header level.
* The Deferred Revenue Report produces an empty `column_headers` list, so the loop body never executes and `annotations_x_offset` is never assigned.
* When the code later tries to write annotation data for each report line, it references the unassigned variable, causing Python to raise `UnboundLocalError`.

**Fix:**
* Initialize `annotations_x_offset = None` before the header loop.
* After writing all individual column headers (where `x_offset` already points to the first free column after all data columns), add a fallback: if `report_annotations` is set but `annotations_x_offset` is still `None`, assign it from the current `x_offset` and write the "Annotations" header.

opw-6354473

Issue:
Voice transcript 'share by email' button would get post the transcript summary to the chatters of all records of a given model.

Steps:
1) install crm and ai
2) activate openai and gemini by saving the api keys inside settings. 3) create 2 crm leads in order
a) lead 1 and lead 2
4) go into lead 1 and in the description then type in '/voice-transcription'. 5) Go into the 'transcription' section of the voice transcription 6) type something and save
7) then click 'start recording'
8) click 'stop recording' - it doesn't need to actually record 9) wait to process
10) click the 'share by email' button
11) check lead 2 for a message created (there shouldnt be one) 12) go back to lead 1 and click the 'share by email' button 13) check lead 2 again and a second message appears. that is becuase it makes a new mail.compose.message with res_ids of a list of multiple crm.lead.id (e

This was fixed in 19.2+ with the pr https://github.com/odoo/enterprise/pull/115978. But it didnt make it in 19.0 and 19.1

Fix:
default_res_ids: model?.config.resIds, -> default_res_ids: [model?.config.resId] take the single record id instead of the list res_ids

opw-6285883

Version: 19.0

`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.

- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.

- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.

- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.

taskid- 6329037

### Description of the issue this PR addresses

Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with:

```
psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist
```

### Current behavior before PR

To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`.

Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation.

### Desired behavior after PR is merged

`_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged.

### Steps to reproduce

1. Have several companies using different currencies.
2. Select more than one of them in the company switcher.
3. Open **Accounting > Reporting > Partner Ledger**.
4. Click **Send by email** → the wizard crashes on opening.

A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`.