### Issue:
The FacturX XML has a field `BillingSpecifiedPeriod`, it should depend on `deferred_start/end_date` if they are there. Currently, it only outputs the invoice date as start date and the due date as end date.

### Steps to reproduce:
- Install "l10n_de" and switch to a German company
- Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)"
- Create an invoice for this contact
- Add a start date and end date on the line of this invoice (`deferred_start/end_date`)
- Confirm and send to Factur-X
- In the generated XML the dates used are the invoice date and the due date

### Cause:
As the `deferred_start/end_date` fields are defined in enterprise and the XML generation is in community, this [commit](https://github.com/odoo/odoo/commit/f0c5d5b46444a289bf55ad5846623d48ac3a3b71) set dates defined in community instead of the deferred ones.

### Solution:
Mimicking [the way it's done for UBL20](https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L846) we check if  `deferred_start/end_date` are defined (i.e. account_accountant is installed). If it's the case, we use the min/max of the `deferred_start/end_date` as start/end date of the `BillingSpecifiedPeriod` in the XML.

To include as much info as we can this commit also adds the `deferred_start_date` and `deferred_end_date` on lines.

opw-4874370

Forward-Port-Of: odoo/odoo#218888
Forward-Port-Of: odoo/odoo#215595

**Current behavior:**
Returning an intercompany dropship (product vendor is another
`res.company`) increases the original sale order line's
delivered qty.

**Expected behavior:**
The delivered qty should decrease once the return is completed.

**Steps to reproduce:**
1. Create two companies, enable all the inter-company
synchronization rules

2. Create a product with the dropship route and set the other
company as the vendor

3. Create a sale order for the dropship product, confirm

4. Confirm the corresponding purchase order -> validate the
dropship picking

5. Return the dropship picking

6. See the sale order line's delievered qty is wrong

**Cause of the issue:**
The dropship return move(s) are incorrectly flagged as outgoing.

**Fix:**
Use the `_is_dropshipped_returned()` method to filter these
moves from being considered outgoing.

Also added on to an existing dropshipping test so that there is
now coverage for this use-case when the vendor is not another
company, as this was previously not covered.

opw-4526750

Forward-Port-Of: odoo/odoo#200133

When a sales order with online payment is paid, the automatically generated invoice was not consistently using the email template defined by the 'sale.default_invoice_email_template' system parameter.

This was due to the `_send_invoice` method in `payment_transaction` calling `_generate_and_send_invoices` without passing the configured template.

This commit modifies the `_send_invoice` method to retrieve the 'sale.default_invoice_email_template' system parameter. If found and valid, the corresponding mail template record is passed in the context to `_generate_and_send_invoices`, ensuring the correct email template is used for auto-sent invoices after online payments.

Added unit tests for the different scenarios.

FW-18.4:
Seems like cls.partner in the unit test does not have an email address set. This causes issues and the invoice email is not sent because it gets filtered out for not having an email set (see https://github.com/odoo/odoo/blob/aca52bc9135083050aa09cd1598638dce5438399/addons/account/models/account_move_send.py#L203-L204).
For simplicity, an explicit assignment for email on the partner was added to the unit tests.

## Reproduction Steps:
1.  **Enable Auto-invoicing:** Go to Sales > Configuration > Settings. Under "Invoicing," enable "Automatic Invoicing." Set a specific email template in "Invoice Email Template" (e.g., "Customer Invoice"). Save.
2.  **Configure Payment Acquirer:** Go to Invoicing > Configuration > Payment Acquirers. Activate and configure any payment acquirer (e.g., Bank Transfer). Ensure it's published.
3.  **Create Sales Order:** Go to Sales > Orders > Quotations. Create a new SO, add a product, and Confirm it.
4.  **Simulate Online Payment:** As a customer, navigate to the SO's public portal link. Click "Pay Now," select the configured acquirer, and complete payment.
5.  **Observe the Issue:** Check the communication history on the generated invoice. The email will have been sent using Odoo's default invoice template, ignoring the configured setting.

opw-4865475

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

Forward-Port-Of: odoo/odoo#219177
Forward-Port-Of: odoo/odoo#217878

**Commit 1:**
Commit re-enables the test_01_configurator_translation test, which was broken and skipped due to the DOM changes introduced by the new Website Builder. It also adapts the tour selectors accordingly.

In the configuration screen, after clicking the "Build My Website" button, the website was taking unexpected time to load. To address this, we added `expectPageUnload` to wait for fill page load. After that, we wait for the configurator to finish.

**Commit 2:**
Steps to reproduce:
Go to edit mode and quickly click "Save" within 200ms.
It will throw the error:
Cannot read properties of null (reading 'classList')

Reason:
In the useEffect of WebsiteBuilderClientAction

1. User enters edit mode → isEditing = true.
2. This adds "o_builder_open" class to <body>.
3. A setTimeout is started to run builder-related DOM updates.
4. Before the timeout runs, user clicks "Save" → isEditing = false.
5. The "o_builder_open" class is removed from <body>.
6. When the timeout executes, it tries to access:
     document.querySelector(".o_builder_open .o_main_navbar")
7. This returns null because ".o_builder_open" no longer exists.
8. Calling .classList.add() on null throws a TypeError.

Fix:
Added a cleanup function to the useEffect hook to ensure that any pending timeouts are cleared when the dependency (`isEditing`) changes. This prevents unexpected DOM updates and ensures consistent behavior when toggling edit mode rapidly.

runbot-226533

Issue
-----

- create a new car (or a new bike) with a futur_driver_id

- So either car_domain or bike_domain remains with the value Empty domain
- expression.OR with and empty domain '[]' give True leaf

(Pdb) expression.OR([car_domain, []])
[(1, '=', 1)]

- the read_group find all active record and set plan to change = True on them

Solution
---------

- default value of car_domain and bike_domain should be expression.FALSY_DOMAIN, so a "domain or False" give just the domain

(Pdb) expression.OR([car_domain, expression.FALSE_DOMAIN]) ['&', ('driver_id', 'in', {25465}), ('vehicle_type', '=', 'car')]

But the group by seems a premature optimisation, two search would make the code much more readable, shorter and not much slower

- following up with https://github.com/odoo/odoo/pull/197812/files since plan_to_change_car and plan_to_change_bike are not related anymore the sudo write of this field is not needed anymore.
_clean_vals_internal_user can be remove






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

Forward-Port-Of: odoo/odoo#213989

Description of the issue/feature this PR addresses:
- Viettel SInvoice will automatically change the signs of the amount values (except for unit price) we sent for credit notes (on accounts with data validation step). So the "right" values will appear in the portal. Currently (before the commit) the values have the wrong sign in the portal (because they are changed but we sent the right ones already).
- We need to retain the original signs of those values when submitting them to SInvoice.

Current behavior before PR:
- All the amount values, including `itemTotalAmountWithoutTax`, `taxAmount`, `itemTotalAmountAfterDiscount` and `itemTotalAmountWithTax` are sent to Viettel SInvoice in negative values for credit note. Viettel SInvoice changes the sign of these values to positive (which is not correct for credit note).

Desired behavior after PR is merged:
- Only the sign of `unitPrice` is changed when we send the credit note to SInvoice.

**Note:**
- The signs will not automatically be changed for accounts with data validation step removed. So this commit will break credit notes for them (since the signs are not automatically adjusted but our values have the wrong signs).

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

Forward-Port-Of: odoo/odoo#201993

**Description**
- The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be created.
However, this wasn't respected for `account.tax.group`. As a result, tax groups could still be created even when `force_create=False`, leading to null values in accounts fields like `tax_payable_account_id` and `tax_receivable_account_id`.

**The issue which prompted this patch:**
- A recent patch in upgrade: odoo/upgrade@d2d16a2321abb525fe3fe2c403f89009f51c1394 This patch was made to update the `reconcile` and `non_trade` flags on standard accounts due to recent changes across localizations. During the upgrade, we overrode the `write` method of `account.tax.group` to conditionally update these flags. However, in a client’s database, `account.tax.group` records were missing for the `l10n_pk` module, while the standard account records were present. When `try_loading` was triggered at the end, it attempted to `create` the missing tax groups. But since the create method is called during creation and does not include the conditional update logic for `reconcile` and `non_trade` the upgrade failed with the same error that the original patch aimed to resolve.

- To avoid such errors and prevent tax groups from being created with null account fields when `force_create=False`, this patch ensures `force_create` is respected for `account.tax.group`.

**Steps to reproduce:**
- Create a `v17` DB and install `l10n_pk`
- Delete the standard tax groups
- Upgrade to `v18`

OPW-4915394

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

Forward-Port-Of: odoo/odoo#219211

Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
    - line 1: price_unit 93.76, quantity 172, tax 16%
    - line 2: price_unit 74.18, quantity 161, tax 16%
    - line 3: price_unit 74.18, quantity 162, tax 16%
    - line 4: price_unit 93.76, quantity 384, tax 16%
    - line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI

Issue: Payment validation will fail with error

> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".

opw-4750981

Forward-Port-Of: odoo/enterprise#90003
Forward-Port-Of: odoo/enterprise#88952

**Problem:**
when the product in the sale order linked to a field service task is a kit and the task is marked as done, the delivery is not validate (as it would for a non kit product)

**Steps to reproduce:**
- Create a product and set up a Kit-type Bill of Materials for it (with at least two components)
- Create a service-type product.
- Set the Invoicing Policy to Prepaid/Fixed
- set the "create on order" field to Task
- assign the Project to Field Service.
- Create a Sales Order using the service product.
- Confirm the Sales Order.
- In the linked task, click on the Products smart button
- add the kit-type product from step 1.
- Mark the task as done.

**Current behavior:**
On the sale order, the delivered quantity for the kit product is 0.
If you click on the delivery smart button, you'll see that the picking is not validated yet

**Expected behavior:**
the picking should be validated

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/d8dc0cabd83a29d0522cb5fd25c6956968d4408b/industry_fsm_stock/models/project_task.py#L23 the orer_line is considered as an exception because the order_line product_uom_qty is smaller than total_qty (the sum of the move_ids' product_uom_qty)
But this is normal in the case of a kit

opw-4848444

Forward-Port-Of: odoo/enterprise#89616
Forward-Port-Of: odoo/enterprise#88363