Currently an error occurs when user uninstalls the `databases` module.

**Steps to replicate:**
* Install and uninstall databases

**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`

**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.

**Solution:**
* Revert the domain back to the one defined in project module.

[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46 
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62 
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26

sentry-7035410943

Forward-Port-Of: odoo/enterprise#99987

Problem
--------

In v18.0, the day billing period was removed from the sale.subscription.plan model.

For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance.

However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value.

- Screenshot Order with plan Daily: 
<img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" />

- Screenshot when trying to get in order on the website: 
<img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" />


Proposed Solution
--------

This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list.

The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection).

This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance.

- 
<img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" />

Forward-Port-Of: odoo/enterprise#100084
Forward-Port-Of: odoo/enterprise#99207

**Issue:**
When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the correct rounded value.

**Steps to Reproduce:**
1. Go to Accounting → Reporting → Profit and Loss Report
2. Enable Column Budget
3. Enter budget value: 5.00
4. Save → Value displays correctly as: 5.00 ✓
5. Click to edit the same cell
6. Input field shows: 5.000000000174602 ✗ (instead of 5.00)
7. Save without changes → Display shows: 5.00 ✓
8. Edit again → Still shows: 5.000000000174602 ✗

**Root Cause:**
The frontend reads from cell['no_format'] when populating the edit input field. This field receives the raw column_value which contains floating-point precision errors accumulated during aggregation operations. While the display formatting applies rounding, the edit mode receives the unrounded value.

**Solution:**
Round column_value using float_round() immediately after detecting an editable budget column, before the value is used anywhere. This ensures both the display path and edit path receive the same properly rounded value based on the company's currency decimal places.

opw-5158862

Forward-Port-Of: odoo/enterprise#98478

Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API.

In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL.

Steps to reproduce spelling issue:
1. Create a Sales Order with a customer reference and a deliverable product.
2. Validate the SO.
3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key
  [recepientReference] is not permitted.

Steps to reproduce datetime issue:
1. Create a delivery using the DHL carrier.
2. Confirm the delivery.
3. Return the delivery.
4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted
  (expected format: '2010-02-11T17:10:09 GMT+01:00').

Official DHL documentation:
https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml

opw-5024363

Forward-Port-Of: odoo/enterprise#98981

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

Forward-Port-Of: odoo/enterprise#99799
Forward-Port-Of: odoo/enterprise#99565

- Install Accounting and `l10n_de_reports`
- Switch to a German company
- Create a bill:
  * Price: `100.00`
  * Taxes: `19%`
- Edit the tax total with the pencil button
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
=> The tax amount is the one that has been edited manually
- Download `Datev DATA (zip)`
- Open `EXTF_accounting_entries.csv` file

The total amount in the file is the one before the edition of the tax amount.

The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually.

We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used.

Ticket [link](https://www.odoo.com/odoo/project.task/4951488)
opw-4951488

Forward-Port-Of: odoo/enterprise#100244
Forward-Port-Of: odoo/enterprise#98684

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745

[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA

https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history).

We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line.

opw-5212801

===============================================================

[FIX] l10n_fr_reports : add new accounts in P&L

Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well.

Forward-Port-Of: odoo/enterprise#100116
Forward-Port-Of: odoo/enterprise#100077