Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98325
Forward-Port-Of: odoo/enterprise#96852

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

-> Resolved in 19.0 see https://github.com/odoo/enterprise/commit/060f4c3e24e7add05273cfad5853884546937d0e#diff-3c84b414a086808e446ae3f90b3b803edf964c28237c153af19edda3ed05cc6bL21

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#97497
Forward-Port-Of: odoo/enterprise#96299

Currently, on creating a budget using split budget causing an error.

**Steps to Reporduce:**
1) Install **account_budget module(with Demo)**
2) Navigate to **Accounting>Accounting>Analytic Budget** 
3) Click on `Generate` set `Analytic Plan` and click on `Split`

Error:
`ValueError: Cannot convert budget.line.achieved_amount to SQL because it is not stored`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/224667/commits/53b4670b1ad375ffc3800fc3beb97e960f229dc6), a new aggregate spec `sum_currency` was added. As a result, the code at [1] is executed for currency-aware aggregates. From the line, `self._field_to_sql(self._table, fname, query)` the ORM tries to create an SQL expression for `achieved_amount`. Because `achieved_amount` is computed `_field_to_sql` fails and error is raised.

Fix:
Provide a default SQL expression for computed fields on Budget Line

[1]: https://github.com/odoo/odoo/blob/af668f545676f72385c52629f8498edfe22219cd/odoo/orm/models.py#L1972-L2004

Used Reference: https://github.com/odoo/odoo/blob/d42102cac8fff3967cb605a897bbb0e8690464ed/addons/crm/models/crm_lead.py#L286-L298

sentry-6917352415

### use overlay offset for basic editor

In this prior [fix], overlays spawned by the HtmlBuilder and its children have a
modified offset in order to prevent the `MassMailingIframe` from unloading its
content.

However the `MassMailingHtmlField` also handles a Simple Editor feature, which
does not use the Builder.
This feature still uses an iframe and also uses overlays (popover toolbars).

This work moves the [fix] in `MassMailingIframe` so that it applies also for
the Simple Editor.

[fix]: https://github.com/odoo/odoo/commit/dd31e31f3cecd4d23dc90f9c88780bf3b969a294

### ensure correct editor instance on record switch

Issue:
When switching from one record to another using the Form view pager, the
`activeTheme` was set to the theme value of the previous record, resulting in
the wrong Editor instance in some cases.

How to reproduce:
- Open the list view in Email Marketing
- Ensure there are 2 records in the list view:
  - one editable with the builder (default theme)
  - one editable with the simple editor (basic theme)
- click on the record with the simple editor
- use the pager to switch to the next record

Issue:
- switching from simple -> builder, the builder is not instanced but it should
  have been
- switching from builder -> simple, the builder is instanced but it should not
  have been

Resolution:
Update the active theme based on the value of the nextRecord instead of the
record currently in `props`, because `this.props.record` is updated after
`updateActiveTheme` is called.

task-5217595

In version `19.0` new hierarchy views was added to module `hr_appraisal` by this commit[^1]. But the module `web_hierarchy` is not dependency of `hr_appraisal`.

When we install `hr_appraisal` it triggers the installation of `hr` because of dependency. On the other side `hr_org_chart`[^2] gets installed because of auto_install=true. So it makes `web_hierarchy` installed because of the `hr_org_chart` dependency.

If we upgrade db from `18.0` to `19.0` which `hr_appraisal` installed and `web_hierarchy` uninstalled we will get issue as `hr_appraisal` requires dependency to `web_hierarchy` because of new views.

Steps to reproduce (case 1):
1. Install `hr_appraisal` in `18.0`
2. Uninstall `web_hierarchy`
3. Upgrade to `19.0`

Steps to reproduce (case 2):
1. Install `hr_appraisal` in `16.0`
2. Uninstall `hr_org_chart`
3. Upgrade to `19.0`

In this 2nd case, the `web_hierarchy` is not existing yet and `hr_org_chart` is auto installed module, so during upgrade it will not be re-installed again.

We will get traceback like this:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1509, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 185, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 449, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 211, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 58, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 646, in convert_file
    convert_xml_import(env, module, fp, idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 745, in convert_xml_import
    obj.parse(doc.getroot())
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 616, in parse
    self._tag_root(de)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 570, in _tag_root
    raise ParseError(msg) from None  # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/19.0/hr_appraisal/views/hr_appraisal_goal_template_views.xml:71
Invalid view type: 'hierarchy'.
You might have used an invalid starting tag in the architecture.
Allowed types are: list, form, graph, pivot, calendar, kanban, search, qweb, cohort, gantt, grid, map, activity

View error context:
'-no context-'

```

[^1]: https://github.com/odoo/enterprise/commit/dbe4946218b3523bea4fb8a79be8f3fc29d8d33e
[^2]: https://github.com/odoo/odoo/blob/dec621e60794ede263222e3b5be0ebfc33ed6f40/addons/hr_org_chart/__manifest__.py#L16-L17

Currently, an error occurs when creating a sale order for a project.

**Steps to Reproduce:**
 - Install the `sale_project` module.
 - Go to `Project` and, in the `list view`, create a `project` and `set a customer`.
 - Click the `Sales Order` button in the header.
 - Save the `sale order` without adding `any product` or by adding a `non-service product`.

**Error:**
`AttributeError: 'bool' object has no attribute 'order_id'`

This error occurs, when user creating a sale order for a project without adding a service product, then 
service sol becomes empty [1], which raises an error here [2] when trying to access the sale order.

This commit ensures that if there is no service sol, empty sol is taken in the service sol.

[1]- https://github.com/odoo/odoo/blob/3121577430cdfa485af4d69792745a6f9c2ffe2f/addons/sale_project/models/sale_order.py#L272

[2]- https://github.com/odoo/odoo/blob/3121577430cdfa485af4d69792745a6f9c2ffe2f/addons/sale_project/models/sale_order.py#L276

sentry-6948584510

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

Description of the issue/feature this PR addresses:
Issue reported[ here ](https://github.com/odoo/odoo/issues/233130)

Impacted versions:
19.0 (and likely earlier stable versions: 17.0, 18.0)

Steps to reproduce:

Open the Website Editor or HTML Editor (e.g., editing a website page).
Insert or select an image that has been saved as an attachment (source is a /web/image/... URL, not a Base64 string).
Perform an action that triggers the attachment modification logic (e.g., applying a filter, or a WebP conversion step).


**Current behavior before PR:**
- The client-side JavaScript correctly omits the data parameter in the RPC request to /html_editor/modify_image/<attachment_id>.
- The Python modify_image controller receives data=None, and subsequent image processing fails because it expects the image content, leading to a server-side traceback (e.g., a KeyError or a failure in image manipulation libraries).

**Desired behavior after PR is merged:**
The modify_image controller should successfully retrieve the existing image content from the database and process the modification without error.

- This controller endpoint handles modifications for existing attachments. When the client is modifying a server-stored image (sourced via /web/image/...), the client efficiently omits the image data payload.
- The controller should be resilient to this behavior by retrieving the image content directly from the existing attachment record.
- The fix introduces a conditional check to load the image's base64 content (attachment.datas) into the data variable if the client does not provide a new payload (data is None).
- This is the most robust and performant solution, as it ensures the controller has the necessary image data without forcing the client to re-upload potentially large files


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

Currently, new IndexedDB object stores are only created during the 'onupgradeneeded' event. This event only fires if the database version is manually incremented in the code.

If a new module (e.g., restaurant) adds a new object store to the PoS database schema but the `dbVersion` is not bumped, the store is never created. This causes the PoS session to fail when it tries to access the missing store.

This commit modifies the `databaseEventListener` to add a check inside the `onsuccess` handler. After the database opens, it compares the list of required stores (`this.dbStores`) with the list of existing stores (`this.db.objectStoreNames`).

If a mismatch is detected:
1. The current database connection is closed.
2. The `dbVersion` is incremented.
3. The database connection process is re-run.

This forces the `onupgradeneeded` event to trigger, which then correctly creates the missing object stores, ensuring the database schema is always up-to-date.

opw-5166049

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

Forward-Port-Of: odoo/odoo#233268