**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#277969
Forward-Port-Of: odoo/odoo#275294

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

Forward-Port-Of: odoo/odoo#279033
Forward-Port-Of: odoo/odoo#270008

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Bank Journal** and go to the **Inbound Payment Methods** tab.
* Add the **Manual** payment method multiple times and give each payment method line a different name.
* Go to **Customers → Payments** and create a payment using any of these payment method lines.
* Print the **Payment Receipt** from the gear menu.

**Observed behavior:**
* The receipt always displays the **Manual** payment method name.
* The custom name configured on the selected payment method line is ignored.

**Cause:**
* The report retrieves the payment method name from `account.payment.method`.
* However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name.

**Fix:**
* Read the payment method name from the selected `account.payment.method.line`.
* The payment receipt now displays the configured payment method line name.

opw-6395829

Forward-Port-Of: odoo/odoo#277104

**Steps to reproduce:**

1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.

**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`

The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
 we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.

**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.

task-6233423

Forward-Port-Of: odoo/odoo#266304

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/9308e17b14 [REL] 19.4.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4a390af94f [FIX] DefaultPlugin: no format should be preserved [Task: 6345022](https://www.odoo.com/odoo/2328/tasks/6345022)
https://github.com/odoo/o-spreadsheet/commit/5a19a3e344 [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268403)
https://github.com/odoo/o-spreadsheet/commit/5c7b5a0afd [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/31ff8d1991 [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)
https://github.com/odoo/o-spreadsheet/commit/b48a8737ec [FIX] calendar chart: skip missing value tooltips [Task: 6276800](https://www.odoo.com/odoo/2328/tasks/6276800)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Currently, an error occurs when grouping invoice lines by tax.

**Steps to Reproduce:**
 - Install the `Accounting` module.
 - Go to `Accounting` > `Customers` > `Invoices` and `create an invoice`.
 - Add an `invoice line`, set a `price`, and select an `account`.
 - Go to `Accounting` > `Configuration` > `Chart of Accounts`, open the account used on 
   the invoice line, and clear its `Code` field.
 - Return to the `invoice`, click `Action` > `(Un)Group lines by tax`.

`ValueError: TypeError('sequence item 1: expected str instance, bool found') while evaluating`
`'if records:\n records.action_group_ungroup_lines_by_tax()'`


After this [recent commit], account codes became optional and can be removed. As a result, 
when a user adds an account with no code to an invoice line and groups the lines by the same 
tax, it creates the grouped line from here [1]. Then, when it gets the account code from the 
grouped line to prepare the name, the code is False, which raises the error [2].

This commit ensures that the grouped line name is built using filter(None, ...), which removes 
None and other falsy values, so that the account code is included if it exists; otherwise, 
it is not included.

[recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277

[1]- https://github.com/odoo/odoo/blob/92ced215895d027a2b5606dbecbf3eb96b9dcd10/addons/account_edi_ubl_cii/models/account_move.py#L156-L158

[2]- https://github.com/odoo/odoo/blob/92ced215895d027a2b5606dbecbf3eb96b9dcd10/addons/account_edi_ubl_cii/models/account_move.py#L189-L193

sentry-7598941609

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

Forward-Port-Of: odoo/odoo#275026

When refunding an order that had a fixed-amount global discount, the refunded total was inflated: e.g. a 65.00 order (80.00 - 15.00 fixed discount) was refunded as 95.00 instead of 65.00. On the refund order `amount_paid` then differed from `amount_total`, so the POS session's closing entry could not balance; `_validate_session` rolled back and no `account.move` was created, leaving the session closed with no accounting.

When a refund is created, the product lines are negated and the discount line is excluded, then `pos_discount` re-applies the global discount to the refund order through `applyDiscount`. For a fixed amount, `reduce_base_lines_to_target_amount` targets an absolute value and does not follow the sign of the (now negative) base, so the discount keeps the sale sign. Percentages scale with the base and are not affected.

Negate the fixed discount amount when the destination order is a refund so it mirrors the negative base. The stored `discount_value` is left unchanged so the auto-resync of the discount stays idempotent.

opw-6400738

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

Forward-Port-Of: odoo/odoo#278180

### Steps to reproduce:

- Create a table (e.g. /table).
- Write text inside a cell and select it partially.
- Border options (color, width, style) are shown in the toolbar, but width and style cannot be applied.

### Description of the issue/feature this PR addresses:

- Table border styles can only be applied when table cells are fully selected, so these toolbar options should not be shown during partial cell content selections.
- Applying custom borders to table cells caused the default borders of other unselected cells to disappear on the website, though they worked in the backend. The default border style is `inset`. In the backend, the border color is solid gray ('$o-gray-300'), which renders fine. On the website, the border color is semi-transparent. Browsers cannot render semi-transparent colors properly with the `inset` style, making the borders invisible.

### Desired behavior after PR is merged:

- Show border toolbar options only when table cells are fully selected, and hide them for partial text selections.
- Resolve this by keeping the `inset` style but forcing the default cell border color to use the solid opaque '$o-gray-300' in `base_style.scss`.

task-6356370

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

When refunding an order that had a fixed-amount global discount, the refunded total was inflated: e.g. a 65.00 order (80.00 - 15.00 fixed discount) was refunded as 95.00 instead of 65.00. On the refund order `amount_paid` then differed from `amount_total`, so the POS session's closing entry could not balance; `_validate_session` rolled back and no `account.move` was created, leaving the session closed with no accounting.

When a refund is created, the product lines are negated and the discount line is excluded, then `pos_discount` re-applies the global discount to the refund order through `applyDiscount`. For a fixed amount, `reduce_base_lines_to_target_amount` targets an absolute value and does not follow the sign of the (now negative) base, so the discount keeps the sale sign. Percentages scale with the base and are not affected.

Negate the fixed discount amount when the destination order is a refund so it mirrors the negative base. The stored `discount_value` is left unchanged so the auto-resync of the discount stays idempotent.

opw-6400738

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

The `Quantity On Hand` field doesn't always show up directly

To reproduce the issue:
1. Create a product template without any tracking
2. Switch the tracking to 'Quantity'

Error: if we don't save the form, the `Quantity On Hand` field doesn't show
up. That's terrible and reminds us the so old click-to-edit Odoo 14.

The field `qty_available` is wrapped into a `div` container that is
invisible in some conditions, and one of them is based on `is_storable`:
https://github.com/odoo/odoo/blob/913efdfe9af3d1dd75a0687a72a7ec5ecb7297fe/addons/stock/views/product_views.xml#L194-L195

The field is a computed one and will be set to `False` under some
conditions in its compute method. The compute will never mark it as `True`,
which is a first issue. Second, in the above use case, it only changes to
`True` when saving thanks to the inverse method of the `tracking field`:
https://github.com/odoo/odoo/blob/1fdc147b75b1746f85d810f1288bd1d632166083/addons/stock/models/product.py#L1003-L1005
This therefore explains why the `Quantity On Hand` doesn't show up during
step 2: it's an onchange mechanism, the inverse methods are not triggered.

A similar issue will also happen on a variant form, but because of another
reason. This time we need to look at the field `qty_available` itself, which
depends on `show_qty_update_button`:
https://github.com/odoo/odoo/blob/913efdfe9af3d1dd75a0687a72a7ec5ecb7297fe/addons/stock/views/product_views.xml#L200
The field is a computed one and the method is missing one dependency.

No ticket
Discovered during PR review of opw-6316788

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Bank Journal** and go to the **Inbound Payment Methods** tab.
* Add the **Manual** payment method multiple times and give each payment method line a different name.
* Go to **Customers → Payments** and create a payment using any of these payment method lines.
* Print the **Payment Receipt** from the gear menu.

**Observed behavior:**
* The receipt always displays the **Manual** payment method name.
* The custom name configured on the selected payment method line is ignored.

**Cause:**
* The report retrieves the payment method name from `account.payment.method`.
* However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name.

**Fix:**
* Read the payment method name from the selected `account.payment.method.line`.
* The payment receipt now displays the configured payment method line name.

opw-6395829

Forward-Port-Of: odoo/odoo#277104

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3dd56325d8 [REL] 19.3.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7d7ac96719 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/476b1731db [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268403)
https://github.com/odoo/o-spreadsheet/commit/186ab9ce81 [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)
https://github.com/odoo/o-spreadsheet/commit/2a4f4991cb [FIX] calendar chart: skip missing value tooltips [Task: 6276800](https://www.odoo.com/odoo/2328/tasks/6276800)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**

1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.

**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`

The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
 we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.

**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.

task-6233423

Forward-Port-Of: odoo/odoo#266304

While preloading chart template data, if an account already exists in the db but has `active=False`, it is not found because archived records are excluded from the [`_search`].

As a result, the load attempts to create a new account. During creation, the Python constraint [`_ensure_code_is_unique`] searches with `active_test=False`, finds the archived account with the same code, and raises a ValidationError:
```py
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 735, in _load_data
    'noupdate': True,
                     ^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4519, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4426, in _load_records_create
    records = self.create(vals_list)
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1057, in create
    records._ensure_code_is_unique()
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1135, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 1.1.1.02.003, 1.1.1.02.004
```

Steps to reproduce:
- In a `v19.0` database, install `l10n_ar` with demo data.
- The accounts with codes `1.1.1.02.003` and `1.1.1.02.004` are created by [`_create_outstanding_accounts`].
- Archive those accounts and upgrade to `v19.2`.
- During the upgrade, [`_get_latam_check_outstanding_account_account`] attempts to create new accounts with the same codes, triggering the duplicate code validation.

tbg-2840

[`_search`]: https://github.com/odoo/odoo/blob/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd/addons/account/models/chart_template.py#L438
[`_ensure_code_is_unique`]: https://github.com/odoo/odoo/blob/19.0/addons/account/models/account_account.py#L1133
[`_create_outstanding_accounts`]: https://github.com/odoo/odoo/blob/06a46b083fde5688d71c5602553316c9e7160b6a/addons/account/models/chart_template.py#L925C9-L949
[`_get_latam_check_outstanding_account_account`]: https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_latam_check/models/account_chart_template.py#L60-L76



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

Forward-Port-Of: odoo/odoo#279313
Forward-Port-Of: odoo/odoo#279092

Steps to produce: 

1) Install Manufacturing & enable "Work Order Dependencies" in the settings
2) Make a new BOM with 2 operations
3) Check "Operation Dependencies" in the miscellaneous tab on the BOM's form view.
4) Configure the first sequential operation to be blocked by the second
5) Make and confirm an MO using this BOM
6) Uncheck "Operation Dependencies" on the BOM
7) Press "Plan" on the MO, a validation error is thrown stating "You cannot create cyclic dependency."

Issue occurs because after the MO is confirmed the blocked_by_workorder_ids field for mrp.workorder records is set based on the order manually configured on the BOM (operation 1 is blocked by operation 2). After the BOM is edited to have allow_operation_dependencies = false, then Odoo uses the default sequential ordering when planning the operations (operation 2 is blocked by operation 1). Since the old ordering is never cleared, a cycle is created unintentionally. 

This PR resolves this issue by clearing the blocked_by_workorder_ids field on mrp.workorder records. 

opw-6334271

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

Forward-Port-Of: odoo/odoo#278255
Forward-Port-Of: odoo/odoo#275154

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378

Routes inherited from product category are not available when on replenish.

Steps to reproduce:
-------------------
* Create a new route and allow it on product category
* Create a product category and add the route
* Add the category to a product
* use the repenish button 
-> the category route is not available on the replenishment

Observation:
-------------
When opening replenishment, it will open the view_product_replenish, in that view, it will use allowed_route_ids to allow us to choose a route for this replenishment: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/wizard/product_replenish_views.xml#L37 
allowed_route_ids is compute in the mixin with the following domain: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L18-L21 https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L25-L31 
this only take into account route from the product and not the ones from the product category. https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/stock/models/stock_location.py#L511

opw-6297308

Forward-Port-Of: odoo/odoo#271535

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#278526
Forward-Port-Of: odoo/odoo#276211

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378

While preloading chart template data, if an account already exists in the db but has `active=False`, it is not found because archived records are excluded from the [`_search`].

As a result, the load attempts to create a new account. During creation, the Python constraint [`_ensure_code_is_unique`] searches with `active_test=False`, finds the archived account with the same code, and raises a ValidationError:
```py
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 735, in _load_data
    'noupdate': True,
                     ^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4519, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4426, in _load_records_create
    records = self.create(vals_list)
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1057, in create
    records._ensure_code_is_unique()
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1135, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 1.1.1.02.003, 1.1.1.02.004
```

Steps to reproduce:
- In a `v19.0` database, install `l10n_ar` with demo data.
- The accounts with codes `1.1.1.02.003` and `1.1.1.02.004` are created by [`_create_outstanding_accounts`].
- Archive those accounts and upgrade to `v19.2`.
- During the upgrade, [`_get_latam_check_outstanding_account_account`] attempts to create new accounts with the same codes, triggering the duplicate code validation.

tbg-2840

[`_search`]: https://github.com/odoo/odoo/blob/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd/addons/account/models/chart_template.py#L438
[`_ensure_code_is_unique`]: https://github.com/odoo/odoo/blob/19.0/addons/account/models/account_account.py#L1133
[`_create_outstanding_accounts`]: https://github.com/odoo/odoo/blob/06a46b083fde5688d71c5602553316c9e7160b6a/addons/account/models/chart_template.py#L925C9-L949
[`_get_latam_check_outstanding_account_account`]: https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_latam_check/models/account_chart_template.py#L60-L76



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

Forward-Port-Of: odoo/odoo#279092

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Bank Journal** and go to the **Inbound Payment Methods** tab.
* Add the **Manual** payment method multiple times and give each payment method line a different name.
* Go to **Customers → Payments** and create a payment using any of these payment method lines.
* Print the **Payment Receipt** from the gear menu.

**Observed behavior:**
* The receipt always displays the **Manual** payment method name.
* The custom name configured on the selected payment method line is ignored.

**Cause:**
* The report retrieves the payment method name from `account.payment.method`.
* However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name.

**Fix:**
* Read the payment method name from the selected `account.payment.method.line`.
* The payment receipt now displays the configured payment method line name.

opw-6395829

Forward-Port-Of: odoo/odoo#277104

Steps to reproduce
---
1. Confirm a purchase order and receive it a few days later.
2. Open Purchase, Reporting, Purchase and add the "Effective Days To Arrival" measure.

Observed: the value is counted from the line's scheduled date instead of the order date, and can even be negative when the scheduled date precedes the confirmation date.

Issue
---
The metric is meant to be the effective lead time, the number of days between the order confirmation and the actual receipt, falling back to the planned "days to receive" when nothing has
been received yet according to [task](https://www.odoo.com/odoo/project/809/tasks/3691573).
The query instead computes age(date_planned, COALESCE(date_done, date_order)), so once a receipt exists it returns date_planned - date_done (the gap between the
scheduled date and the receipt) rather than date_done - date_order.
https://github.com/odoo/odoo/blob/c06be48ce7277a667719fd756e0a1f63e91cda27/addons/purchase_stock/report/purchase_report.py#L20-L28

opw-6226523

Forward-Port-Of: odoo/odoo#278990
Forward-Port-Of: odoo/odoo#268843

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b4f7ab8fa3 [REL] 19.1.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0c8351c1f3 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/76606bc2de [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**

1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.

**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`

The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
 we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.

**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.

task-6233423

Forward-Port-Of: odoo/odoo#266304

### Issue:
When importing EDI documents such as Peppol files, Swiss VAT numbers may be formatted or unformatted
When `base_vat` is installed, VAT is stored formatted in Odoo (e.g. `CHE-530.781.296 TVA`)
If the format differs, the matching fails and a new partner is created at each import

### Cause:
`_retrieve_partner` lacked Swiss-specific VAT normalization logic in `_get_country_specific_vat_variants`, causing it to miss formatted variants with language suffixes (`TVA`, `MWST`, `IVA`)

Even when the match succeeded, `_import_ubl_create_missing_customer` still compared VAT strings without stripping `-` and lang suffixes for CH partners, causing a false mismatch and triggering partner creation anyway

### Notes:
The partner match improvement is backported from 18.3: https://github.com/odoo/odoo/commit/f1a5a3d72a26ee471d2ef1d8034136208b2bcebc
The original fix was incomplete — it added `_get_country_specific_vat_variants` but missed the VAT comparison fix in `_import_ubl_create_missing_customer`, allowing the issue to persist after a successful match
`base_vat` is required to get the fix fully working

### Steps to reproduce:
- Install `account` and `base_vat`
- Create a Vendor (Name: Test CH Vendor, Country: Switzerland, Tax ID: CHE-530.781.296 TVA)
- Import a [Peppol Bill](https://github.com/user-attachments/files/27202997/CH_bill_to_import.xml) with VAT `CHE530781296TVA`

Before the fix, a new partner is created instead of matching the existing one

opw-6353387

Forward-Port-Of: odoo/odoo#274398

Steps to reproduce the bug:
- Install point_of_sale
- Open the POS frontend and create a new product from the register
- Add it to the order, then open its product info popup and edit it
    - Rename it and change its price
- Confirm the edit dialog
- Click on the (renamed) product again to add it to the order

Problem:
On runbot the tour test_product_create_update_from_frontend (point_of_sale/tests/test_frontend.py, MobileTestUi) intermittently times out waiting for the orderline to show the edited product name/quantity/ price combination.

editProduct()'s onSave callback in pos_store.js closed the edit dialog via act_window_close right after firing this.data.read("product.template", ...) and this.data.searchRead("product.product", ...), without waiting for either call to resolve. When the dialog closes before those RPCs land, the in-memory product record used by canBeMergedWith() (pos_order_line.js) to decide how to merge/create the next orderline can still hold the stale price, so re-clicking the product right after editing produces an orderline that never matches the expected quantity/price.

Solution:
Make onSave async and await both this.data.read() and this.data.searchRead() before closing the dialog, so the reactive store is guaranteed to hold the updated product data before the user (or the tour) can interact with the product again.

runbot-223630

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/a2d77fdcdb [REL] 18.3.58 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a29c792580 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/587fb7568a [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Routes inherited from product category are not available when on replenish.

Steps to reproduce:
-------------------
* Create a new route and allow it on product category
* Create a product category and add the route
* Add the category to a product
* use the repenish button 
-> the category route is not available on the replenishment

Observation:
-------------
When opening replenishment, it will open the view_product_replenish, in that view, it will use allowed_route_ids to allow us to choose a route for this replenishment: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/wizard/product_replenish_views.xml#L37 
allowed_route_ids is compute in the mixin with the following domain: https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L18-L21 https://github.com/odoo/odoo/blob/2f25b2a70eca5b4f3c2e1d6c7003b1760afc0ba0/addons/stock/models/stock_replenish_mixin.py#L25-L31 
this only take into account route from the product and not the ones from the product category. https://github.com/odoo/odoo/blob/deeecf7cd02e7383b591835b0c6495e3ddead0ff/addons/stock/models/stock_location.py#L511

opw-6297308

Forward-Port-Of: odoo/odoo#271535

Steps to reproduce
1. Create two products and assign the same vendor to both in the Purchase tab
2. Create two Sales Orders using the dropship route (one product per order)
3. Generate and merge the corresponding Purchase Orders, then confirm the merged PO
4. Validate the dropship transfer

Issue
stock.picking.sale_id is a Many2one (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/sale_stock/models/stock.py#L99)
computed from procurement.group.sale_id, and stock.picking.group_id is a
stored related on move_ids.group_id (https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/stock/models/stock_picking.py#L186).
A single picking can therefore only resolve to one SO. _create_picking
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order.py#L290)
builds one picking per PO and _prepare_stock_moves assigns every move
the merged PO's group_id
(https://github.com/odoo/odoo/blob/18c3a034b7d3772baca62d8d86efba2ca15f17b0/addons/purchase_stock/models/purchase_order_line.py#L307),
so when a merged dropship PO carries lines from multiple SOs every move
lands in one picking under the PO group. Only one SO gets linked and
the others stay "not fully delivered" even after validation.

Solution
Override PurchaseOrderLine._prepare_stock_moves to set group_id to the
SO's procurement_group_id when sale_line_id is set, so each dropship
move is created in its originating SO's procurement group.

Override PurchaseOrder._create_picking to detect dropship POs whose
order lines span more than one SO and create one picking per SO group
by calling _prepare_picking and _create_stock_moves per group.
picking.group_id then resolves to the SO group via the stored related
field, picking.sale_id points to the right SO, and delivery_status
updates correctly on validation.

opw-6094608

_(updates on July-17th and July-28th for points 2. and 3. in `hr_expense`)_

# Introduction
**1\.** A fix to `hr_org_chart` was initially proposed.
I think it is mergeable because it fixes the user-experience properly like expected in Odoo standard.

Other commits are suggested to `hr_expense`.
They were designed to allow more flexibility in the management of `hr_employee.company_id` (in multi-company context) and allow not to duplicate the `hr.employee` of each companies of the `res.users`.
**2\.** The [FIX] silences a multi-company access error when searching for Expense validators => it seems safe
**3\.** The [IMP] largely allow more flexibility for a "Expense: Team Approver" when creating expenses on behalf of its subordinates

# 1. in hr_org_chart [FIX]
Prevents multi-company error when recursively searching for ancestors.

<img width="1035" height="789" alt="image" src="https://github.com/user-attachments/assets/d5517f79-7efc-4223-ae77-0af8b25a3d1e" />

### Issue description

In a multi-company environment, when one of the `hr_employee.company_id` of a hierarchy is not in the allowed companies of a Manager's `res_users.company_ids`, this Manager can view `hr.employee` in the list view but cannot open their forms.

This happens when:
- `hr_org_chart` module is installed
- the Org Chart is displayed on the 1st page of the `hr.employee` form, like when the HR settings "Skills Management" is disabled (in `res.settings`) => thus the whole form becomes inaccessible from the manager

When a `hr.employee` form is opened, a multi-company access error is thrown to him, even if the `company_id` of the opened `hr.employee` is in the user's `res_users.company_ids`, because of the hierarchy's `company_id`.
It should be expected that the part of the Org Chart which is not allowed to be seen would just be hidden. 

### Steps to reproduce
Data setup:
- Employee "A" in company A
- Manager "M" in company A, manager of "Employee A"
- Manager of manager "MM" in company A, manager of "Manager M"
- And now, in company B (let's say a Holding), the "Director" is manager of "Manager MM"
- "Manager M" is only given access access to Company A
- the module "hr_org_chart" is installed

Actions:
- Login with Manager M
- Browse to Employees list and try and open the form of "Employee A" (up to tab _"Professional information"_, if it is not the 1st of the notebook)

### Proposed fix

This PR re-uses the already existing method `_check_employee` which contains all the logic to solve the issue. Maybe the call to this method was forgotten?
This PR simply call this method when finding an ancestor, in the controller of `hr_org_chart`. This fix is thus very limited to the call to the public method `hr_org_chart.get_org_chart()` made by the Org Chart widget.

### Desired behavior after PR is merged

The part of the Org Chart not allowed to be seen by "Manager M" is hidden.


# 2. hr_expense [FIX]

<img width="541" height="415" alt="image" src="https://github.com/user-attachments/assets/d594815b-2b77-4088-878b-9b192b64d6a3" />

### Issue description
As an employee, I click on the button "View Report" on my expense.
I get a multi-company access error, preventing me to view and edit my expense report.
This is because the manager of the department I belong is in a company I'm not allowed to see.

This can also happen just when opening my Expense (instead of Expense Report).

### Current behavior before this PR
The employee is blocked to continue editing its Expense or to submit it to a Report.

### Current behavior after this PR
The employee can edit and submit its Expense no matter the `company_id` of its hierarchy.
Technically: the `can_approve` field on the expense sheet uses a localized `.sudo()` method to bypass multi-company limits when searching if the current user is a validator.



# 3. hr_expense [IMP]

<img width="1028" height="549" alt="image" src="https://github.com/user-attachments/assets/1096c0d4-d025-46a9-8559-6bab5de71577" />

### Improvement summary
In multi-company environment, allow a "Expense: Team Approver" to create Expenses for its subordinates (`hr_expense.employee_id`) **no matter the `hr_employee.company_id` of its subordinates**.
The domain of `hr_expense.employee_id` keeps the security of `check_company=True` => thus the Manager only sees `hr.employee` having their `company_id` in the manager's allowed companies (`res_users.company_ids`).

### Current behavior before this PR
Context: a 8-companies environment where the `hr.employee` of each hierarchy chains are splitted in many different companies, like:
- top-level (admin board): 1 company
- middle management: approx. 2 companies
- down level: the other companies
The "down level" have `hr.employee` but no `res.users`. The "middle management" have `res.users` and must create the Expenses of their "down level" subordinates on their behalf.

Issue: as a manager, as per Odoo proposal, I need to have a `hr.employee` in the same company of my subordinates to be able to create Expense of their behalf.
However, this is very inconvenient because as a Manager, I can have employees in various companies. And my own manager it not in the same company than me, so the same issue applies recursively.

### Behavior after this PR is merged
The domain of the field `expense_id.employee_id` is more permissive. As a Manager, it allows me to select the Employee I manage in my active company, no matter if I have or not myself a `hr.employee` in this company.

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

* = l10n_fr_pdp_pos

last backported commit: 373711ba04bd2585f51be26cec31cd80d21d0571

The main difference for the e-invoicing part are the difference in
- peppol (i.e. partner and company / settings)
- the account move send wizard

They were both refactored between 17.0 and 18.0

task-6356968

For the e-reporting part

Co-authored-by: Jérémy Bazin (baje) <baje@odoo.com>

#### [IMP] l10n_fr_pdp: backport Flow 10 e-reporting

Flow 10 e-reporting is needed on 17.0 while its implementation was
introduced in 18.0. The business builder can be reused, but account
EDI helper signatures and company account fields differ between
versions.

Keep the 18.0 dict_to_xml rendering so node ordering, omissions and
control-character sanitization remain identical. Add the local tax
compatibility required for configured exemptions, acquisitions,
reverse charge and UoM codes. Also adapt account lookup to the 17.0
company field.

Validate the generated report against the 0290 reserve fixture and
cover invalid XML control characters. Compose the e-reporting chatter
markup without concatenating translated strings.

This preserves the reference payload while keeping e-reporting
separate from the ongoing e-invoicing backport.

task-6356968

#### [ADD] l10n_fr_pdp_pos: backport Flow 10 POS e-reporting

POS e-reporting depends on closing entries being included in Flow 10.
The 18.0 implementation relies on POS and accounting fields and APIs
which are not available on 17.0.

Detect closing entries through pos.session.move_id, adapt order
creation tests to create_from_ui, and extend the Flow 10 query. Filter
17.0 POS counterpart lines because they are still marked as product
lines. Preserve the sign of separate refund income lines so sales and
refunds are reported net.

This preserves the 18.0 reporting result without changing the
e-invoicing path.

task-6356968

Supersedes #275986 and fixes its approach: that PR updates the withholding rates **in place** on the existing tax records (`ret_10_income_person`, `ret_10_income_rent`, `ret_2_income_person`, and repurposes `ret_2_income_transfer` into a different concept). Those records exist in production databases with posted history behind them, and the pre-law rates remain legally applicable to operations dated before the law's entry into force, so rewriting them breaks prior-period postings, corrections and reports. Following the approach used for equivalent legal rate changes in other localizations on stable branches (`l10n_ee`, `l10n_sk`, `l10n_fi`), this PR adds **new taxes** for the new rates, keeps the pre-law taxes active, archives the superseded 27% remittance withholding, gives the new 15% withholding its own payable account instead of reusing the one tied to L253-12, and leaves the module authorship untouched.

## Description

Dominican Republic Law 30-26 ("medidas pro-crecimiento económico, simplificación fiscal y mitigación de la crisis internacional"), enacted on June 18, 2026, amends several provisions of the Tax Code that affect taxes shipped with the `l10n_do` chart template:

| Concept | Before | After | Effective |
|---|---|---|---|
| ISR withholding on fees/services provided by individuals (art. 309 b) | 10% | 15% (payment on account) | July 2026 |
| ISR withholding on rents paid to individuals (art. 309 a) | 10% | 15% (single and final) | July 2026 |
| ISR withholding on payments abroad for software licenses/subscriptions, royalties, online advertising and cloud data storage (arts. 305-1 / 305-2) | 27% (general remittance rate) | 15% (single and final) | June 18, 2026 |
| ISR withholding on technical services provided by individuals (art. 309 rate over the 20% presumed base of art. 70, Regulation 139-98) | 2% effective | 3% effective | July 1, 2026 (DGII notice 10-26) |

Changes:

- New taxes `ret_15_income_person` and `ret_15_income_rent`. The pre-law 10% taxes are kept active since their rates remain applicable to operations dated before the law.
- New taxes `ret_3_income_person` and `ret_3_income_transfer` for the effective 3% withholding on technical services, posting to a new payable account `l10n_do_21030311` ("Other Withholdings (L30-26)") since their pre-law counterparts' accounts are tied to previous regulations; the pre-law 2% taxes also remain active.
- New tax `ret_15_income_remittance_tech`, posting to a new payable account `l10n_do_21030310` ("ISR Withheld on Remittances Abroad (L30-26)"), since the existing remittance account is tied to L253-12.
- `ret_27_income_remittance` is deactivated in the template, superseded by the new reduced withholding.

The new tax names follow the module's existing convention of tagging the enforcing law (as with "(L253-12)").

No changes are needed in the tax report: the ISR withholding taxes only distribute to payable accounts, without tax grids.

Scope note: Law 30-26 also raises the tax on checks and electronic transfers from 1.5‰ to 2.0‰ (art. 382 of Law 288-04, as amended), deliberately left out here: it is not an invoiceable tax — banks withhold it directly on account debits, so it is handled outside invoice accounting.

References:
- https://presidencia.gob.do/leyes/ley-30-26
- https://www.hacienda.gob.do/ley-30-26-no-dispone-impuestos-por-suscripciones-de-ciudadanos-a-plataformas-digitales-reduce-de-27-a-15-la-retencion-a-empresas-que-contratan-servicios-tecnologicos-en-el-exterior/