When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

Forward-Port-Of: odoo/enterprise#121575
Forward-Port-Of: odoo/enterprise#118824

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

When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

Forward-Port-Of: odoo/enterprise#121575
Forward-Port-Of: odoo/enterprise#118824

**_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

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:

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

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

### 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 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:
- 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

Before this PR, the merge details popup needed a redesign, now the different views showcase the merge better to the user.

| Before | Before | After |
|--------|--------|--------|
| First section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 44" src="https://github.com/user-attachments/assets/81faaad4-f950-4031-bd1c-66b46c1e61c3" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 07 59" src="https://github.com/user-attachments/assets/46895709-3575-4bae-864e-f33a96a7737b" /> |
| Second section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 47" src="https://github.com/user-attachments/assets/1fd3381c-d93c-4a2e-892b-134633279677" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 05" src="https://github.com/user-attachments/assets/0400e9f4-00ee-4d8b-9d77-a1566b1242f5" /> |
| Third section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 52" src="https://github.com/user-attachments/assets/dce3590c-4f16-473a-abd7-611f781f70f3" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 13" src="https://github.com/user-attachments/assets/a8315904-0067-4794-b48d-6b357445d1c7" /> |
| Record hover | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 11 02" src="https://github.com/user-attachments/assets/1fa8fa2e-e9e0-45a6-a8c0-6dd4a8e6fa9b" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 17" src="https://github.com/user-attachments/assets/78434801-f34e-4e8f-87d9-bc9841a1628a" /> |
| Field display | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 52" src="https://github.com/user-attachments/assets/d410867c-3013-4b90-99a2-b26bbab22e86" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 12 02" src="https://github.com/user-attachments/assets/38b1e359-02b5-4586-990e-f11805390ddd" /> |
| Tab focus (accessibility) | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 44" src="https://github.com/user-attachments/assets/162b0a57-5138-45f7-b595-76337a5793dc" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 09 18" src="https://github.com/user-attachments/assets/3b79e21a-ab1c-47a8-874a-0f9f157938f3" /> |

task-6196149

**_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:

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

From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service

Steps to reproduce:
1. Install website_sale_renting_planning module
2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period
3. In the General Information tab, click on the internal link to "Developer"
4. Enable Sync Shifts and Rental Orders
5. Go to the eCommerce website and search for product "test"
6. Add as much product "test" to the cart as possible (the quantity is limited)
7. Open the cart
8. You can increase the amount of the product regardless of its availability

Issue:
We don't check the renting availabilities to limit the maximum quantity of the product

Solution:
Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates

opw-6274035

Forward-Port-Of: odoo/enterprise#126497
Forward-Port-Of: odoo/enterprise#123056

### 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#126750
Forward-Port-Of: odoo/enterprise#126466

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

* = account_invoice_extract, l10n_nl_reports

Example of steps:
- Install web_studio and `accountant`
- Open the corresponding form view in Studio
- With debug mode toggle "Show invisible Elements" and edit
"Invisible" on the second partner_id field
- Traceback

`normalize()` compares the combined arch without the studio
customization to the one with it, in order to compute the smallest
possible set of xpaths. To do so, it calls `apply_inheritance_specs`
(the low-level function from `odoo.tools.template_inheritance`)
directly on the statically combined arch.

Some models add or duplicate nodes dynamically in `_get_view()`
(Python postprocessing, run after the static view combination). A
studio operation can target such a node, since it is what the user
actually sees and clicks on. But that node has no counterpart in the
purely static combined arch used by `normalize()`, so
`apply_inheritance_specs` raises a ValueError.

`edit_view()` only catches `ValidationError` to fall back to an
un-optimized (but valid) studio arch instead of failing the request.
Since the low-level function raises a plain `ValueError` here, that
fallback never triggers, and the exception is not caught anywhere.

To fix this, we will keep the behavior from version 18.0 and catch the
ValueError raised by `apply_inheritance_specs` in
`normalize_with_keyed_tree` and re-raise it as a ValidationError, like
`ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets
`edit_view()`'s existing fallback handle the case gracefully instead
of crashing.

Additionally, the two models responsible for the dynamically-added nodes
described above are fixed at the source. `account_invoice_extract`'s
duplicated `partner_id` field and `l10n_nl_reports`'s injected
`company_id` field are now marked with `data-used-by`, the same
attribute `_add_missing_fields` already sets in `ir_ui_view.py` for the
fields it adds.
Studio already skip rendering and computing xpaths for any node carrying
this attribute (since https://github.com/odoo/enterprise/pull/92862),
so these nodes are no longer exposed to the user and can no longer
produce a studio operation that `normalize()` is unable to locate.

opw-6332911