**Steps to reproduce:**
* Install the **Italy – E-invoicing (l10n_it_edi)** module.
* Create a product with a non-zero cost price.
* Create a **vendor bill** for an Italian vendor using the **RC fiscal
  position**.
* Add the product with **unit price = 0**, apply **RC tax**, and set the
  **Origin Document Type**.
* Confirm the bill and click **Send to Tax Integration** to generate the
  XML in the chatter.
* Upload the generated XML through  
  **Accounting → Vendors → Bills → Upload**.

**Observed behavior:**
* The imported bill ignores the XML value **0.00** and uses the product's
  default price instead.

**Cause:**
* The XML’s `<PrezzoUnitario>` value is mandatory and may be **0**, but the
  code skipped it because `0.0` evaluates as falsy in the walrus
  assignment.

**Fix:**
* Always set the parsed `PrezzoUnitario` value (including **0.0**) on the
  invoice line.

ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/PrezzoUnitario  

opw-5322187

Forward-Port-Of: odoo/odoo#239419

This commit adds expense import test when using total_amount_currency with price_unit missing.

opw-5211041

---

**Workaround:** Use `total_amount_currency` instead of `total_amount`. Original bug complaint described below.

**Version:** Odoo 18.0, 18.4, and 19.0. The feature works as expected in Odoo 17.

**Steps:**

1. On an Odoo 18 or 19 database, ensure an Expense Category (e.g., "Meals") is configured with a tax (e.g., 12% VAT, Price Included).
2. Prepare an import file (XLSX/CSV) with columns for Total (tax-included amount) and Category.
3. Go to Expenses > My Expenses > Actions > Import records.
4. Upload the file. Map the Total column to the "Total" field and the Category column to the "Category" field.
5. Complete the import and open the newly created expense.
6. Result: The Total is correct, the Category is correct, and the 12% tax is listed, but the **`Tax Amount`** field shows 0.00.
7. Expected Result (from Odoo 17): The system should auto-calculate and populate the Tax Amount based on the Total and the tax rate from the Category.


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

when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.

```
   File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
    views = get_views(
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
    res = super().get_views(views, options)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
    result = super().get_views(views, options=options)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
    return super().get_views(views, options)
   File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
    result['models'][model] = {"fields": self.env[model].fields_get(
   File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
    res = super().fields_get(allfields, attributes)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
    return super().fields_get(allfields, attributes=attributes)
   File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
    res = super().fields_get(allfields, attributes)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
    description = field.get_description(self.env, attributes=attributes)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
    value = value(env)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
    model._read_group_groupby(model._table, groupby, query)
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
    return super()._read_group_groupby(alias, groupby_spec, query)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
    coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
   File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
    records = self.sudo().with_context(active_test=False).search_fetch(
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
    return self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
   File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
    self.cr.execute(query)
   File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
 psycopg2.DatabaseError: out of memory for query result
```

opw-5260147
upg-3444635

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

There are two issues:

1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.

Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order

1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.

2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear

Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483

1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.

2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8

Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```

- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#239809

Steps to reproduce [18.2+]:

1. Add a dynamic snippet to a website page (e.g., Events).

2. Unpublish all event records.

3. The snippet first appears with a visible header, which then
disappears.

[A]- Starting from [1], the `o_dynamic_empty` class was introduced to
handle the dynamic snippets visibility, and an upgrade script (see [3])
set this class by default on them.

Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in
the XML template, while on the JS side, the class used to toggle snippet
visibility was `o_dynamic_snippet_empty`. This class was also added to
snippets on destroy (before saving).

[B]- As a result, a dynamic snippet may end up with:

- `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but
edited snippets.
- `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0.
- `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created
in 18.0.

Remark: the `s_dynamic_empty` class was introduced by mistake and does
not have any associated CSS

Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the
interaction flow became inconsistent (starting from 18.2): snippets were
initially visible, then hidden if no content was found... which caused
the flickering behavior described above.

And because of [B], old snippets with the `o_dynamic_empty` class
will be visible by default in 18.0.

This commit restores the intended (and original) behavior:

- A dynamic snippet should be invisible by default,

- Then the interaction decides (based on actual content) whether the
snippet should be displayed.

[1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878
[2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b
[3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906

opw-5354523

Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.

**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".

**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)

Blame the following rules:
- Employee multi-company rule

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.

This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.

ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>

ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.

**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.

sentry-7032880299

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6a0e768aee [REL] 18.0.51 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d17a974ba7 [FIX] CorePlugins: Prevent dispatch during adaptRange [Task: 5380747](https://www.odoo.com/odoo/2328/tasks/5380747)
https://github.com/odoo/o-spreadsheet/commit/7c2da49579 [PERF] evaluation: cached dynamic dependencies [Task: 5407156](https://www.odoo.com/odoo/2328/tasks/5407156)
https://github.com/odoo/o-spreadsheet/commit/cd4deac676 [FIX] cf: conditional formatting preview is truncated for nothing [Task: 5344000](https://www.odoo.com/odoo/2328/tasks/5344000)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)


ticket #5180122