### Issue:
During RunBot single module tests, some tests caused an error: `Maximum call stack size exceeded` after repeated: `[Owl] Unhandled error. Destroying the root component`

### Affected tests:
- `sign_money_in_out.called at right time`
- `sign_drawer_open.called at right time`
- `sign_work_in.called when opening register, setting & resetting cashier`
- `sign_work_in_employee.called from login screen (closed session)`

### Cause:
The tests passed `dialogData: {}` to the component env But `dialogData` must at least define `scrollToOrigin`, which is called automatically in `onWillDestroy`:
https://github.com/odoo/odoo/blob/0042e83fb60353a49d4759a79a3ceb0eee6f74b6/addons/web/static/src/core/dialog/dialog.js#L122-L126

Calling `scrollToOrigin()` on an empty object raises a `TypeError`, which Owl catches and re-throws repeatedly until the call stack is exceeded

The full `dialogData` shape is defined in `makeDialogMockEnv`: https://github.com/odoo/odoo/blob/62c540d96fc49d9e74d8c660019754651cb0e085/addons/web/static/tests/_framework/env_test_helpers.js#L151-L161

### Steps to reproduce:
- Install `l10n_be_pos_blackbox` (fresh `-i`, or `-u` with `web` on an existing db)
- Run the tests in MobileWebSuite

Before the fix, the errors are triggered

runbot-941232

Forward-Port-Of: odoo/enterprise#125474

Steps to Reproduce:

1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set  to any date and click into an aging bucket for that partner.

Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.

Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.

Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:

    action['context'] = {
        'recon_limit': options['date']['date_to'],
    }

Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.

Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.

opw 6333699

Forward-Port-Of: odoo/enterprise#126021

**_Steps to reproduce:_**

* Install `l10n_br_avatax` and configure Avalara Brazil.
* Create at least two customer invoices.
* Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**.
* Select the invoices and click **Action → Confirm Entries**.

**_Observed behavior:_**

* A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated.

**_Cause:_**

* During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records.
* Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices.

**_Fix:_**

* Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`.
* This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error.

opw-6334761

Forward-Port-Of: odoo/enterprise#126437
Forward-Port-Of: odoo/enterprise#124993

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes and rental transfers
- Unarchive the MTO route
- Create a rental product P with a buy route and a set vendor
- Create a rental order for 1 x P and set the the MTO route on the sol
- Confirm the order
#### > The delivery as well as the purchase for 1 unit of P was generated but the return was not.

### Cause of the issue:

The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297
However, in the present case, the mto  route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated.

opw-6361322

Forward-Port-Of: odoo/enterprise#126410
Forward-Port-Of: odoo/enterprise#124097

### Issue before this commit:
When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice.

### Steps to reproduce the issue:
1. Download Accounting and l10n_mx
2. Create an invoice and send it to CFDI
3. Select 'Request for cancel'
4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled
5. Print the invoice again
6. See PDF does not show fiscal information (QR, fiscal folio, etc.)

### Cause of the issue:
https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields.

### Reason to introduce the fix:
A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled.

opw-6393656

Forward-Port-Of: odoo/enterprise#126466

On the website booking page, moving to a later month can show no available times even though the weekly schedule clearly has some.

### Steps to reproduce

- Install Appointments.
- Create a recurring appointment type available on a single weekday (say Monday), with a user or resource assigned and a date range spanning a few months.
- Set `Allow bookings at least` (the minimum booking delay) so that the current time plus the delay falls after this month's last Monday. Close to the end of a month, a day or two of delay is enough.
- Open the booking page: the first month shown is next month, because the delay skipped this month's last slot.
- Click the arrow to move forward one more month.

=> the reached month shows no slots, even though it has Monday availability.

### Cause

The calendar computes availability one month at a time. It builds a list of months, and the browser refers to each month by its position in that list (0, 1, 2, ...). Clicking the next arrow sends that position back to the server.

The server turns the position into a real month by adding it to a start month, which it computes as `now` plus the minimum booking delay. But the list shown to the visitor does not start there: it starts at the month of the first slot that can actually be booked.

These two are usually the same, so the position lines up. They stop matching when the delay moves the earliest bookable time past the last availability day of the current month. In the steps above, `now` plus the delay lands after the month's last Monday, so the first bookable slot is a Monday in the next month. The visitor's list then starts one month later than the server assumes, every position points one month too early, and the server computes availability for a month the visitor is not looking at. The reached month comes back empty.

### Fix

Count the visitor's month position from the same first bookable slot the list starts from, instead of from `now` plus the delay. The navigation offset is passed to the slot computation and resolved against that slot, so the filled month always matches the month the visitor sees.

opw-6353569

Forward-Port-Of: odoo/enterprise#123994
Forward-Port-Of: odoo/enterprise#122494

Issue:
In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date)

Steps to reproduce:
1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered)
2) Pick any "As of" date
3) Open any row
4) Click breadcrumb to return to the accrual list
5) Observe the "As of" date has been reset to today's date
To generate some data you could:
create a PO, then upload the bill, validate the receipt, then you'll find it in bills received

Cause:
`AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16

Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65

Solution:
- Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation.
- Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path.
- In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore.

opw-6232263


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

Forward-Port-Of: odoo/enterprise#126371
Forward-Port-Of: odoo/enterprise#118669

**_Steps to reproduce:_**

* Install `l10n_br_avatax` and configure Avalara Brazil.
* Create at least two customer invoices.
* Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**.
* Select the invoices and click **Action → Confirm Entries**.

**_Observed behavior:_**

* A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated.

**_Cause:_**

* During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records.
* Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices.

**_Fix:_**

* Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`.
* This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error.

opw-6334761

Forward-Port-Of: odoo/enterprise#126437
Forward-Port-Of: odoo/enterprise#124993

### Issue before this commit:
When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice.

### Steps to reproduce the issue:
1. Download Accounting and l10n_mx
2. Create an invoice and send it to CFDI
3. Select 'Request for cancel'
4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled
5. Print the invoice again
6. See PDF does not show fiscal information (QR, fiscal folio, etc.)

### Cause of the issue:
https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields.

### Reason to introduce the fix:
A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled.

opw-6393656

Forward-Port-Of: odoo/enterprise#126466

Steps to Reproduce:

1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set  to any date and click into an aging bucket for that partner.

Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.

Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.

Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:

    action['context'] = {
        'recon_limit': options['date']['date_to'],
    }

Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.

Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.

opw 6333699

Forward-Port-Of: odoo/enterprise#126021

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#125821

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

Clicking a slot on an appointment type with a non-ASCII name (for example an Arabic title) puts the browser in an endless 301 loop, so the info form never opens.

### Steps to reproduce

- Create an appointment type with an Arabic name, e.g. `عنوان`.
- Open its page and pick a time slot.
- The browser keeps redirecting on `/appointment/<slug>/info` and fails with "too many redirections".

### Cause

The info URL is built from the slug `<name>-<id>`, here `عنوان-1`. We build a `URL` with `encodeURIComponent(slug)`, so `url.href` is already encoded once (`عنوان` becomes `%D8%B9...`). But we then navigate with `encodeURI(url.href)`, and `encodeURI` escapes the `%` signs a second time, so `%D8%B9...` becomes `%25D8%25B9...`. The slug is now encoded twice.

To canonicalize the URL, the server decodes the request path and the path it rebuilds from the route, once each, and redirects if they differ. For a normal URL they are equal. For ours they are not, because one side is decoded one step less than the other, so the server keeps answering 301 with the same double-encoded URL. An ASCII slug has no `%` for `encodeURI` to escape, so only non-ASCII names hit this.

### Fix

Navigate to `url.href` directly. It is already encoded, so the extra `encodeURI` only broke it. Same fix on the manual resource confirmation path.

opw-6409641

**_Steps to reproduce:_**

* Install `l10n_br_avatax` and configure Avalara Brazil.
* Create at least two customer invoices.
* Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**.
* Select the invoices and click **Action → Confirm Entries**.

**_Observed behavior:_**

* A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated.

**_Cause:_**

* During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records.
* Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices.

**_Fix:_**

* Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`.
* This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error.

opw-6334761

Forward-Port-Of: odoo/enterprise#126437
Forward-Port-Of: odoo/enterprise#124993

Steps to reproduce the bug:
- Install l10n_us_hr_payroll_adp without hr_attendance/hr_holidays_attendance
- Run the test suite (runbot build 941182)
- TestL10nUsHrPayrollADPExport.setUpClass fails

Problem:
setUpClass raised `ValueError: Invalid field 'overtime_deductible' in
'hr.work.entry.type'` when writing on the overtime work entry type.
The field overtime_deductible is only defined by hr_holidays_attendance
https://github.com/odoo/odoo/blob/saas-19.2/addons/hr_holidays_attendance/models/hr_work_entry_type.py#L10-L12
which depends on hr_attendance and auto-installs only when hr_attendance is
present. l10n_us_hr_payroll_adp's dependency chain (l10n_us_hr_payroll ->
hr_payroll) never pulls in hr_attendance, so the field doesn't always
exist in the test's registry.

However, when hr_holidays_attendance IS installed (e.g. on the full
runbot build), the field must still be set to False: leaving it at its
default causes hr.leave.create() to run
hr_holidays_attendance's _check_overtime_deductible(), which raises
"The employee does not have enough extra hours to request this leave."
for the overtime leaves created further down in setUpClass, since the
test employees have no recorded attendance/overtime hours.

Solution:
Only include overtime_deductible in the write() vals when the field
exists on hr.work.entry.type, keeping it disabled either way.

runbot-941182

Steps to Reproduce:

1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set  to any date and click into an aging bucket for that partner.

Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.

Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.

Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:

    action['context'] = {
        'recon_limit': options['date']['date_to'],
    }

Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.

Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.

opw 6333699

Forward-Port-Of: odoo/enterprise#126021

### Issue before this commit:
When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice.

### Steps to reproduce the issue:
1. Download Accounting and l10n_mx
2. Create an invoice and send it to CFDI
3. Select 'Request for cancel'
4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled
5. Print the invoice again
6. See PDF does not show fiscal information (QR, fiscal folio, etc.)

### Cause of the issue:
https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields.

### Reason to introduce the fix:
A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled.

opw-6393656

Forward-Port-Of: odoo/enterprise#126466

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#125821

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#121733

When using the click & collect option, the available qty for renting was not taking the selected warehouse into account.

Steps to reproduce:
-------------------
* Create 2 different warehouses with 2 different adresses
* Create a product available for renting
* Setup the product to use serial numbers
* Create 2 serial number, 1 in each warehouse
* Activate the click & collect option on the website
* Create a first sale order to collect in warehouse 1
* In the backend, confirm the order and pick it up
* Go back to the website and make a second order for the second warehouse
> Observation: When clicking on the "Add to cart" you get an error
  saying that there is no quantity available

Why the fix:
------------
When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses.

opw-6328475

Forward-Port-Of: odoo/enterprise#126545
Forward-Port-Of: odoo/enterprise#124969

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#125703
Forward-Port-Of: odoo/enterprise#122038

### Issue before this commit:
When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice.

### Steps to reproduce the issue:
1. Download Accounting and l10n_mx
2. Create an invoice and send it to CFDI
3. Select 'Request for cancel'
4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled
5. Print the invoice again
6. See PDF does not show fiscal information (QR, fiscal folio, etc.)

### Cause of the issue:
https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields.

### Reason to introduce the fix:
A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled.

opw-6393656

Forward-Port-Of: odoo/enterprise#126466

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#121733

### This is a revision of #119399 which had to be reverted.

Original issue
-----
Deliveries cannot be validated using DPD with Sendcloud, users get an error.

Steps to reproduce
-----
- Set up Sendcloud DPD
- Create a SO
	- Interntional customer
		- Some VAT number
	- Some product
	- Add sendcloud delivery
- Confirm SO
- Validate the linked picking

> Error: “The receiver VAT number is missing; please provide it to continue”

Issue's cause
-----
Tax numbers should be included in the `customs_information` field of the request as per the API

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-customs-information-tax-numbers

For the `vat_label` field, we have to force the language to English in the context because the field is translated by default, but sendcloud only accepts the english names (eg French "TVA" is not accepted, expected value is "VAT").

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

Revert cause
-----
The vat_label field is marked for translation (translate=True)

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

So if the user has the DB in french for example, we are sending "TVA" instead of "VAT" in the name field.

Other issues
-----
- We need to provide an actual fallback for `customs_invoice_nr`. As it stands, if we create a new delivery it cannot be validated because Sendcloud doesn't accept for the field to be empty.
- Same for `name`, we need to provide an actual fallback.

-----
Ticket:
opw-6250860

Forward-Port-Of: odoo/enterprise#124245

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#125821

### Issue:
When accessing the Bank Reconciliation view directly via URL or bookmark, auto-matching with reconciliation models may not trigger and the upload button may be visible on synchronized journals

### Cause:
`_action_open_bank_reconciliation_widget` injects two context keys:
- `auto_statement_processing`: triggers auto-reconciliation on statement creation
- `bank_statements_source`: hides the upload button for synchronized journals

When the view is accessed directly, these keys are not present, causing the UI to ignore them

`auto_statement_processing` is now set directly in the user context via `onWillRender`/`onWillDestroy` in `BankRecKanbanController` `bank_statements_source` requires an ORM call to fetch the journal's value and is resolved via `fetchBankStatementsSourceInto` on startup

Notes:
The fix for `bank_statements_source` was added opportunistically while addressing `auto_statement_processing`

Steps to reproduce:
- Install `accountant` with demo data
- Duplicate the Bank Journal and set Bank Feeds to Online Synchronization
- Open the Accounting Dashboard and open the Bank (copy)
- Create a transaction (Label: Test, any amount) and click Add & Close
- In the 3 dots menu, choose Manage Models
- Create a Reconciliation Model (Label contains: Test, Lines: any account, default values)
- Click Automate
- Go back to the Bank Reconciliation page and verify:
 -- The transaction is reconciled automatically
 -- No Upload button is displayed
- Create a new transaction, it should be reconciled automatically
- Copy the URL and open it in a new tab
- Create a new transaction

Before the fix, the transaction is not reconciled and the Upload button is present

opw-6391107

Forward-Port-Of: odoo/enterprise#126359

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

Forward-Port-Of: odoo/enterprise#113253

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#125703
Forward-Port-Of: odoo/enterprise#122038

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

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

Forward-Port-Of: odoo/enterprise#120709

### Description of the issue/feature this PR addresses:
This PR fixes an issue in the Sign module where replacing a document breaks the link between a signer and their multiple signature fields, causing Odoo to erroneously generate separate signers for each individual field.

### Current behavior before PR:
When a document with multiple signature fields assigned to the same person is replaced, the _copy_sign_items_to function duplicates the sign.item records. During this duplication process, Odoo duplicates the old responsible_ids, creating copies with new ids. These new copies overwrite the old responsible_ids, ensuring that the newly created sign_items have entirely new responsible_ids. 
Because a shared responsible_id is the primary key Odoo uses to group multiple signature items under a single signer, this change in ID causes the system to lose the grouping. As a result, Odoo treats each copied field as belonging to a completely new, separate signer. 

_Note_:
Because of the limitation mentioned before, any responsible_id that is passed through the copy function, and thereby the copy_data function, is overwritten with new ids. The only work-around then is to update the responsible_id value attached to the new_sign_item after the copy_data function has completed and the new_sign_item has been created. 

### Desired behavior after PR is merged:
The original responsible_id is explicitly carried over and assigned to the newly copied sign.item immediately after the copy operation completes. This ensures the copied signature fields retain their original role IDs and grouping, keeping them correctly assigned to the single original signer.

opw-6354334

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

Forward-Port-Of: odoo/enterprise#123628

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126504
Forward-Port-Of: odoo/enterprise#120392

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126504
Forward-Port-Of: odoo/enterprise#120392

Problem:
When scanning the first product, the second move line is clicked immediately after. https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode_picking_batch/static/tests/tours/tour_test_barcode_batch_flows.js#L1529-L1541 If this happens before the first scan has finished, its quantity is incorrectly applied to the second move line that is clicked. This causes a 0 - 3 split instead of a 1 - 2 split, which results in there only being 6 move lines instead of 7.

We updated our quantity on the `currentLine`
https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1478

When finding `currentLine`, we go through `_findLine` and use `this.selectedLineVirtualId`, which is the one that is currently selected in the UI https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1705-L1712

Purpose:
By adding this step, we wait until the first line’s quantity to be updated before it moves on and clicks on the second product.

runbot-941211

Forward-Port-Of: odoo/enterprise#124162

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126504
Forward-Port-Of: odoo/enterprise#120392

### Description of the issue/feature this PR addresses:
This PR fixes an issue in the Sign module where replacing a document breaks the link between a signer and their multiple signature fields, causing Odoo to erroneously generate separate signers for each individual field.

### Current behavior before PR:
When a document with multiple signature fields assigned to the same person is replaced, the _copy_sign_items_to function duplicates the sign.item records. During this duplication process, Odoo duplicates the old responsible_ids, creating copies with new ids. These new copies overwrite the old responsible_ids, ensuring that the newly created sign_items have entirely new responsible_ids. 
Because a shared responsible_id is the primary key Odoo uses to group multiple signature items under a single signer, this change in ID causes the system to lose the grouping. As a result, Odoo treats each copied field as belonging to a completely new, separate signer. 

_Note_:
Because of the limitation mentioned before, any responsible_id that is passed through the copy function, and thereby the copy_data function, is overwritten with new ids. The only work-around then is to update the responsible_id value attached to the new_sign_item after the copy_data function has completed and the new_sign_item has been created. 

### Desired behavior after PR is merged:
The original responsible_id is explicitly carried over and assigned to the newly copied sign.item immediately after the copy operation completes. This ensures the copied signature fields retain their original role IDs and grouping, keeping them correctly assigned to the single original signer.

opw-6354334

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

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#121733

Problem:
When scanning the first product, the second move line is clicked immediately after. https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode_picking_batch/static/tests/tours/tour_test_barcode_batch_flows.js#L1529-L1541 If this happens before the first scan has finished, its quantity is incorrectly applied to the second move line that is clicked. This causes a 0 - 3 split instead of a 1 - 2 split, which results in there only being 6 move lines instead of 7.

We updated our quantity on the `currentLine`
https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1478

When finding `currentLine`, we go through `_findLine` and use `this.selectedLineVirtualId`, which is the one that is currently selected in the UI https://github.com/odoo/enterprise/blob/bfb8bab7636a84c829f16087771e00bf31ad2cce/stock_barcode/static/src/models/barcode_model.js#L1705-L1712

Purpose:
By adding this step, we wait until the first line’s quantity to be updated before it moves on and clicks on the second product.

runbot-941211