This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.

Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.

LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
  cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
  month following the month in which the transactions occurred. For example,
  the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
  transactions include:
  1. Intra-Community acquisition of Goods
  2. Intra-Community acquisition of Services
  3. Intra-Community triangular trades
  4. Intra-Community supplies of Goods
  5. Intra-Community supplies of Services

REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
  The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
  'DUKIntegrator'. This tool allows businesses to:
  1. Validate the generated XML file against the official schema to ensure it is
     correctly formatted.
  2. Generate the final PDF file with the XML attachment, which is the official
     format for submission.

TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
  with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
  attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
  'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
  For collecting these details, we've created a wizard that will be on the
  return validation action. Along with these details, we ask the user if the
  current return is the corrected/rectified one, with the 'corrective_declaration'
  field in this wizard. This wizard will then store these details in the
  respective return. And in the XML export file generator, we are retrieving
  these details from the return to show in the report.

REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
  software and XML report attribute explanation in English: (
  https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
  https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
  https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)

Forward-Port-Of: odoo/enterprise#109921

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:

- 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

When an order from a closed session is invoiced, a misc reversal move is created to "extract" the order from the session closing entry.

When the PoS config uses a currency different from the company currency, posting that reversal move could fail with "The entry is not balanced.", making it impossible to invoice the order.

Steps to reproduce:
- company in currency A, PoS config in currency B, with a conversion rate producing rounding drift (e.g. 0.4007)
- sell a product of 20.0 B + 15% tax (23.0 B), paid by bank, without invoicing
- close the session
- set a partner on the order and invoice it => UserError: "The entry is not balanced."

Cause: in `_prepare_aml_values_list_per_nature`, the product and tax lines each get their balance converted and rounded individually (20.0 * 0.4007 -> 8.01, 3.0 * 0.4007 -> 1.20), while the payment term line was converted from the payment total, without rounding (23.0 * 0.4007 -> 9.2161). Per-line rounding does not distribute over the sum, so the balances could differ by a few cents (8.01 + 1.20 != 9.22) and the move could not be posted. The closing entry has the balancing-account wizard as an escape valve for such differences; the reversal move had none.

Fix, following what is done for regular invoices (see `account.move._compute_needed_terms`, where the payment term balance is derived from the sum of the already rounded lines):
- round the payment term conversions
- put the conversion residual on the last payment term line so the payment terms exactly counterbalance the other lines, but only when the amounts in currency are balanced, so it can only absorb rounding drift
- include the cash rounding amounts in the accumulated totals
- fix the swapped `amount_currency`/`balance` values when merging two non-split payments on the same receivable account

opw-6375309

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

Forward-Port-Of: odoo/odoo#279874
Forward-Port-Of: odoo/odoo#275673

Issue:
Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to.

Steps to reproduce:
Open a PoS session, never open the customer display, and add a product to an order.

Current behaviour:
An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive.

Expected behaviour:
Nothing is sent as long as no customer display was ever opened.

Solution:
Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected.

task-6408513

Forward-Port-Of: odoo/odoo#277687

Issue:
Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to.

Steps to reproduce:
Open a PoS session, never open the customer display, and add a product to an order.

Current behaviour:
An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive.

Expected behaviour:
Nothing is sent as long as no customer display was ever opened.

Solution:
Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected.

task-6408513

Forward-Port-Of: odoo/odoo#277687

Steps to reproduce:
- Open any PoS session
- Click on Orders and filter by "Paid" orders
- Select an order and click on "Details"
- Open the "Payments" tab and click on the "View" button of a payment
- Click on the payment method link

Traceback:
OwlError: The following error occurred in onWillStart: "Cannot find key "pos_payment_provider_cards" in the "view_widgets" registry"

Backend views opened from within the PoS UI (order details dialog, drill-down on many2one links, ...) share their arch with the backend, but `point_of_sale._assets_pos` excludes everything under `static/src/backend/`, so widgets defined there (e.g. `pos_payment_provider_cards`, `lna_checklist`,
`point_of_sale_test_epos`) are never registered in the PoS UI. Unlike missing field widgets, which fall back to the default widget with a warning, an unknown `<widget>` node makes the whole view crash since `Widget.parseWidgetNode` reads the registry without a fallback.

Those widgets are backend configuration helpers that are irrelevant in a PoS session, so instead of bundling each of them (and any future one) in the PoS assets, patch `Widget.parseWidgetNode` in the PoS bundle to skip unknown widgets with a warning, like missing field widgets do. This covers the form, list and kanban arch parsers at once.

opw-6382156

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

Forward-Port-Of: odoo/odoo#279823
Forward-Port-Of: odoo/odoo#276912

Description of the issue/feature this PR addresses:

  Mail server ports are identifiers rather than quantities. The incoming and outgoing mail server views use the unsupported `format` option, so locale-based integer formatting remains enabled.

  Steps to reproduce:

  1. Enable developer mode.
  2. Go to Settings > Technical > Email > Outgoing Mail Servers.
  3. Create a server and set SMTP Port to `8069`.
  4. Move focus away from the field.
  5. The same issue occurs on an Incoming Mail Server with a port such as `10143`.

  Current behavior before PR:

  Ports are displayed with thousands separators, e.g. `8,069` and `10,143`.

  Desired behavior after PR is merged:

  Mail server ports remain unformatted, e.g. `8069` and `10143`.

  Fixes #275937

  ---
  I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
  
"As a recent Computer Engineering graduate, I made my first open-source contribution to Odoo." :)

Forward-Port-Of: odoo/odoo#278329

## Issue
When generating an invoice for a service product with an invoicing policy based on timesheets, the amount of hours invoiced is wrong if there exists a credit note linked to that SO.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Create on Order: Task
    - Project: Any project
    - Invoicing Policy: Based on Timesheets
3. Create a SO
    - Any Customer
    - Product P (any quantity)
    - Confirm the SO
4. In the created task, add a timesheet entry
    - Date: Today
    - Time Spent: 10:00 (10 hours)
5. Create and confirm the invoice for the SO
6. Create a Credit Note from the invoice, set the quantity to 4 hours, and confirm it
7. From the created task, add a second timesheet entry
    - Date: Any future date (e.g., today + 7)
    - Time Spent: 15:00 (15 hours)
8. Create a second invoice, but set a Timesheets Period that only covers the second timesheet entry
9. **The quantity on the newly created invoice is 9 hours, even though we're clearly trying to invoice the 15 hours from the second timesheet entry.**

## Cause
The second invoice is impacted by the credit note generated from the first one. When generating that second invoice, the [`_recompute_qty_to_invoice`](https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L149) method incorrectly computes the amount to invoice by taking into account `account.analytic.line` from outside the provided range.

The delivered quantity is correctly calculated by taking into account the provided range (through the `start_date` and `end_date` added to the domain passed to `_get_delivered_quantity_by_analytic`:

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L176-L180

But then, for each `sale.order.line`, we look at the related `account.analytic.line` without taking into account the provided dates, which leads to lines outside of the range impacting the invoice.

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L182-L193

In the example described in the *Steps to reproduce*, we start with a (correct) amount delivered of 15.0, we find two `invoice_lines_to_calculate` (the invoice of 10 hours, and the credit note of 4 hours), which leads to the quantity to invoice being set to `15 - (-4 + 10) = 9`. This seems like an odd behavior as it:
- doesn't invoice all the hours within the provided range (15 hours within the range, and we're only invoicing 9)
- doesn't invoice **all** the hours left to be invoiced (6 hours are already invoiced, 25 should be in total, and we're invoicing 9)

opw-6373870

Forward-Port-Of: odoo/odoo#277727

Issue:
Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to.

Steps to reproduce:
Open a PoS session, never open the customer display, and add a product to an order.

Current behaviour:
An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive.

Expected behaviour:
Nothing is sent as long as no customer display was ever opened.

Solution:
Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected.

task-6408513

Forward-Port-Of: odoo/odoo#277687

**Issue**
Selling a kit with dropshipping in AVCO/FIFO could wrongly set the standard_price of the component product to 0 after validating the dropship transfer.

**Steps to reproduce**
- Create a kit and component product
- Activate MTO and dropship route for the kit
- Activate dropship route for the component
- Add a vendor for the component (ex: 100 dollars)
- Set component to AVCO valuation
- Create and confirm a sale order
- Confirm the associate purchase order and the dropship transfer
- Go to the product -> The standard price is still 0 instead of being updated from the supplier price.

**Cause**
While confirming the PO, a picking is created:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_stock/models/purchase_order.py#L371 With its associated moves:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_stock/models/purchase_order.py#L383 During the move preparation, the `cost_share` is not propagated on the generated move values, so it remains equal to 0.

The `cost_share` is computed while exploding the kit BOM: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/purchase.py#L94 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/mrp/models/mrp_bom.py#L463 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/mrp_bom.py#L62 https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/mrp_bom.py#L70

However, only the `bom_line_id` is propagated on the move values: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/purchase.py#L94-L99

Later, while validating the dropship transfer:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/stock_move.py#L177 the move value is used to recompute the standard price: https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/product.py#L651 
While `move.value` is not zero, `move._get_value` is:
https://github.com/odoo/odoo/blob/cac987867b083355d3366228d0c551b34f366d92/addons/stock_account/models/product.py#L485-L487
since it depends on the move `cost_share`:
https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/purchase_mrp/models/stock_move.py#L25

Since the move `cost_share` is 0, the AVCO/FIFO recomputation uses an incorrect value and the component standard price is not updated.

**Solution**
No need to use `cost_share` to compute the value if the price_unit is already given for the component

opw-6176571

Forward-Port-Of: odoo/odoo#264341

Before this commit, expect.waitForSteps and expect.waitForErrors gave 2 seconds, less than the 3 seconds of the DOM waits sitting next to them, on the same page and the same RPCs. Over 340 call sites in addons tests reach waitForSteps and not one of them passes an explicit timeout, so 2 seconds is what every step wait gets.

The problem is that the RPC chain a step wait sits on takes longer than that on a loaded machine. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the steps are in, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

Companion of https://github.com/odoo/odoo/pull/279983 to fix https://runbot.odoo.com/odoo/error/944188 kind of issues.

Forward-Port-Of: odoo/odoo#279984

**PROBLEM**
When using fixed tax not affecting the base on line with discount, the xml generated is invalid and refused by peppol.

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create an invoice with the following line:
  - qty: 2, price_unit: 100, discount: 10%, taxes: 21% + fixed tax 1€
  - qty: -2, price_unit: 0, taxes: fixed tax 1€
3. Generate an xml, and try validating it on peppol.
4. The validation fails with the error: [BR-27]-The Item net price (BT-146) shall NOT be negative.

**CAUSE**
Fixed tax not affecting the base of other tax are dispatched into new base lines and then merged into one line per fixed tax.
The new base lines they are dispatched to are created as a copy of the line they originated from.
It means we copy the discount from the original lines.
The fixed tax amount is the unit price of each new base lines.
When reducing the base lines into one line, we take the unit prices of the line, and apply the discount to the unit price.
But, since the unit price is the fixed tax amount, and fixed tax are not affected by discounts, we shouldn't apply discount.

**PROBLEM 2**
fixed division by 0 traceback when the aggregation of invoice lines is 0

**STEP TO REPRODUCE**
1. Install l10n_be.
2. Create the following invoice:
  - qty: 1, unit_price: 100, tax:0% + fixed tax 1€, set an analytic distribution account
  - qty: -1, unit_price: 50, tax:0% + fixed tax 1€, set the same analytic distribution account
3. Send the invoice to peppol.
4. A division by 0 should occur.

opw-6388219

Forward-Port-Of: odoo/odoo#276945

## Issue
When generating an invoice for a service product with an invoicing policy based on timesheets, the amount of hours invoiced is wrong if there exists a credit note linked to that SO.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Create on Order: Task
    - Project: Any project
    - Invoicing Policy: Based on Timesheets
3. Create a SO
    - Any Customer
    - Product P (any quantity)
    - Confirm the SO
4. In the created task, add a timesheet entry
    - Date: Today
    - Time Spent: 10:00 (10 hours)
5. Create and confirm the invoice for the SO
6. Create a Credit Note from the invoice, set the quantity to 4 hours, and confirm it
7. From the created task, add a second timesheet entry
    - Date: Any future date (e.g., today + 7)
    - Time Spent: 15:00 (15 hours)
8. Create a second invoice, but set a Timesheets Period that only covers the second timesheet entry
9. **The quantity on the newly created invoice is 9 hours, even though we're clearly trying to invoice the 15 hours from the second timesheet entry.**

## Cause
The second invoice is impacted by the credit note generated from the first one. When generating that second invoice, the [`_recompute_qty_to_invoice`](https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L149) method incorrectly computes the amount to invoice by taking into account `account.analytic.line` from outside the provided range.

The delivered quantity is correctly calculated by taking into account the provided range (through the `start_date` and `end_date` added to the domain passed to `_get_delivered_quantity_by_analytic`:

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L176-L180

But then, for each `sale.order.line`, we look at the related `account.analytic.line` without taking into account the provided dates, which leads to lines outside of the range impacting the invoice.

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L182-L193

In the example described in the *Steps to reproduce*, we start with a (correct) amount delivered of 15.0, we find two `invoice_lines_to_calculate` (the invoice of 10 hours, and the credit note of 4 hours), which leads to the quantity to invoice being set to `15 - (-4 + 10) = 9`. This seems like an odd behavior as it:
- doesn't invoice all the hours within the provided range (15 hours within the range, and we're only invoicing 9)
- doesn't invoice **all** the hours left to be invoiced (6 hours are already invoiced, 25 should be in total, and we're invoicing 9)

opw-6373870

Forward-Port-Of: odoo/odoo#277727

Issue:
Every change of the selected order makes the PoS call `pos.config.update_customer_display`, which publishes the order on the bus for the customer display paired with this browser. The device uuid identifying that pairing is only generated when the customer display dialog is opened, so a PoS whose customer display was never opened sends `device_uuid: null` and the server publishes on `UPDATE_CUSTOMER_DISPLAY-null`, a channel nobody can listen to.

Steps to reproduce:
Open a PoS session, never open the customer display, and add a product to an order.

Current behaviour:
An rpc is sent for each change of the order, and each of them ends up as a bus notification that no customer display can ever receive.

Expected behaviour:
Nothing is sent as long as no customer display was ever opened.

Solution:
Skip the rpc while no device uuid exists. A customer display opened in the same browser as the PoS is served by the BroadcastChannel, which is unaffected.

task-6408513

Forward-Port-Of: odoo/odoo#277687

The bugfix introduced in https://github.com/odoo/odoo/commit/01d11a770f89c391f7c6a2c46a3d770d10afb428 made it so that "personal" outgoing mail servers are blocked/ignored from being used in email marketing as dedicated servers.

In doing so, it missed the fact that while in *Email Marketing > Settings*, the "Dedicated Server" picker now correctly ignores personal OMS entries, the selection widget for `mail_server_id` in `view_mail_mass_mailing_form` still let's you manually select a OMS with an owner set. As there is not warning or an explicit error, this can lead to accidental miss configurations on an email marketing campaign, where the selected OMS will be actually ignored by the backend.

To align the changes introduced by the bugfix, we add a search domain to the selection field, so that only OMS with `('owner_user_id', '=', False)` will be presented as a choice.

OPW-6388562

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

Forward-Port-Of: odoo/odoo#278595

## Issue
When generating an invoice for a service product with an invoicing policy based on timesheets, the amount of hours invoiced is wrong if there exists a credit note linked to that SO.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Create on Order: Task
    - Project: Any project
    - Invoicing Policy: Based on Timesheets
3. Create a SO
    - Any Customer
    - Product P (any quantity)
    - Confirm the SO
4. In the created task, add a timesheet entry
    - Date: Today
    - Time Spent: 10:00 (10 hours)
5. Create and confirm the invoice for the SO
6. Create a Credit Note from the invoice, set the quantity to 4 hours, and confirm it
7. From the created task, add a second timesheet entry
    - Date: Any future date (e.g., today + 7)
    - Time Spent: 15:00 (15 hours)
8. Create a second invoice, but set a Timesheets Period that only covers the second timesheet entry
9. **The quantity on the newly created invoice is 9 hours, even though we're clearly trying to invoice the 15 hours from the second timesheet entry.**

## Cause
The second invoice is impacted by the credit note generated from the first one. When generating that second invoice, the [`_recompute_qty_to_invoice`](https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L149) method incorrectly computes the amount to invoice by taking into account `account.analytic.line` from outside the provided range.

The delivered quantity is correctly calculated by taking into account the provided range (through the `start_date` and `end_date` added to the domain passed to `_get_delivered_quantity_by_analytic`:

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L176-L180

But then, for each `sale.order.line`, we look at the related `account.analytic.line` without taking into account the provided dates, which leads to lines outside of the range impacting the invoice.

https://github.com/odoo/odoo/blob/0512ebd4c8cc277fdb4fbe0f57619a0bd61192c2/addons/sale_timesheet/models/sale_order_line.py#L182-L193

In the example described in the *Steps to reproduce*, we start with a (correct) amount delivered of 15.0, we find two `invoice_lines_to_calculate` (the invoice of 10 hours, and the credit note of 4 hours), which leads to the quantity to invoice being set to `15 - (-4 + 10) = 9`. This seems like an odd behavior as it:
- doesn't invoice all the hours within the provided range (15 hours within the range, and we're only invoicing 9)
- doesn't invoice **all** the hours left to be invoiced (6 hours are already invoiced, 25 should be in total, and we're invoicing 9)

opw-6373870

Forward-Port-Of: odoo/odoo#277727

This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.

Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.

LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
  cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
  month following the month in which the transactions occurred. For example,
  the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
  transactions include:
  1. Intra-Community acquisition of Goods
  2. Intra-Community acquisition of Services
  3. Intra-Community triangular trades
  4. Intra-Community supplies of Goods
  5. Intra-Community supplies of Services

REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
  The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
  'DUKIntegrator'. This tool allows businesses to:
  1. Validate the generated XML file against the official schema to ensure it is
     correctly formatted.
  2. Generate the final PDF file with the XML attachment, which is the official
     format for submission.

TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
  with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
  attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
  'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
  For collecting these details, we've created a wizard that will be on the
  return validation action. Along with these details, we ask the user if the
  current return is the corrected/rectified one, with the 'corrective_declaration'
  field in this wizard. This wizard will then store these details in the
  respective return. And in the XML export file generator, we are retrieving
  these details from the return to show in the report.

REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
  software and XML report attribute explanation in English: (
  https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
  https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
  https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)

Forward-Port-Of: odoo/enterprise#109921

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

Replaced `useLayoutEffect` (from `@web/owl2/utils`) with `onMounted`
+ `onPatched` because `useLayoutEffect` is deprecated in OWL3.

`useLayoutEffect`'s shim is literally `onMounted + onPatched` with a
deps-diff guard; a native reactive `useEffect` does NOT work here —
it runs outside OWL's patch lifecycle and stops re-running once the
first selection settles, leaving topbar actions stale. A manual diff
of `[this.props.targetRecords, this.ui.isSmall]` inside `onPatched`
reproduces the post-patch, gated recompute the original shim performed.

The useLayoutEffect refactored in this PR had test coverage — below
are some tests that failed when the effect was commented out, and are
now passing:
- @documents/kanban_view/Check actions with preview
- @documents/kanban_view/Download button availability
- @documents/list_view/only show common available actions
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2593680/build/114734104

`useEffect` from `@odoo/owl` is NOT an equivalent replacement —
despite both `this.props.targetRecords` and `this.ui.isSmall` being
reactive signals, the effect stops firing after the first selection
settles. Only patch-tied lifecycle hooks sustain the subscription.

Replaced the `useLayoutEffect` in `DocumentsDropZone` that registered
dragover, dragleave, and scroll listeners on `props.parentRoot()` and
tracked `scrollTop` for overlay positioning. Used `useListener` from
`@odoo/owl` and a class-level `signal(0)` for the scroll offset.
`useLayoutEffect` is deprecated in OWL3.

`useListener` is the idiomatic OWL3 API for external listeners: it
accepts the ref getter directly as its target, subscribes to it
reactively, and handles add/remove lifecycle automatically — no manual
cleanup or `onMounted`/`onUnmounted` pairing required. The `proxy`
state property for `topOffset` was replaced with a `signal(0)` so the
template reads `this.topOffset()` with fine-grained reactivity.

When commenting out the useLayoutEffect there was no error,
the code we refactored had NO TEST coverage. A test was written
to ensure our fix was correct, and it was tested against the
previous useLayoutEffect:
- Passed with previous useLayoutEffect.
- Failed with previous useLayoutEffect commented.
- Passed with our OWL3 replacement.

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