Description of the issue/feature this PR addresses:
  In a multi-company environment, confirming a Purchase Agreement (Blanket Order) automatically generates Vendor Pricelist (product.supplierinfo) entries for the linked
  products. Currently, these entries default to the user's current active company rather than the company specified on the Purchase Agreement. This leads to data
  inconsistency where pricelists are visible and owned by the wrong company.


  Current behavior before PR:
  When a Blanket Order belonging to Company A is confirmed by a user who has Company B as their current active company, the resulting Vendor Pricelist record is
  assigned to Company B. This is because the company_id is not explicitly passed during the creation of the product.supplierinfo record, causing it to fall back to the
  environment default.


  Desired behavior after PR is merged:
  The Vendor Pricelist record will explicitly use the company_id from the Purchase Agreement it originated from. This ensures that the pricelist is correctly assigned
  to the agreement's company rather than from the active company

related to ticket i made #5909892

When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated.

### Steps to reproduce:

* Create a product A with variants of type never
* Create a sales order with two product A and confirm it
* Go on the delivery (don't validate it) and create a delivery slip
-> Issue, the name of the product appears twice.
* Reduce the quantity of product delivered to one
* Confirm and create a backorder
* Print the deliveryslip
-> Issue, the name of the product appears twice in the backorder section

### Observation:

When confirming the SO:
It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant:
https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300
This information is added to the picking_description (for which the fallback value is the product name):
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340
When printing the delivery_slip, it uses description_picking (and attempts to filter out the name):
https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74
However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name.

The same issue is present here :
https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180

opw-5153222

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
The fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 will result
in a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/d58ecdccb89401751c8ee056c4166427ea005f5e
was to correct an issue related to the computation of some `project.task`
fields calling resource methods, we can instead go for a safer solution
in `project` which doesn't affect `resource`/`hr` modules.

Code below the search already ensures that leaves are only applied
when their company matches the resource's company:
https://github.com/odoo/odoo/blob/fdd9edb6a4ef3aa18449be537c954a06b32578e3/addons/resource/models/resource_calendar.py#L409-L410
When `_leave_intervals_batch` is called without resources, existing code
adds a company domain (see `_get_unusual_days` for example).

opw-5496999
opw-5401425

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4587c34166 [REL] 18.0.56 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/83a2147ebf [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311)
https://github.com/odoo/o-spreadsheet/commit/03ebb687fa [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/d953505355 [FIX] tests: fix network serialization in mock [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/2f4cf70fc1 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007)
https://github.com/odoo/o-spreadsheet/commit/0dcc3ce629 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

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>

### Issue:
When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0

### Cause:
In `export_boe()`, the `report_lines` were get based on the `section_report` options
However, `section_reports` do not store the date
or return periodicity of the selected report
As a result, using their options always fetched data for the current period instead of the specified year

### Note:
`_generate_mod_390_page2()` also had issues:
some lines were missing or incorrectly indexed

The mod 360 format, it strict in the structure with specific index so it may produce invalid documents

The latest documentation for mod 390:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` and switch to ES Company
- Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025)
- Open Tax Return, switch to Mod 390, and set year to 2025
- You should see data in the 2 first sections
- Use the gear icon, and download the BOE
- Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report

opw-5457374

Forward-Port-Of: odoo/enterprise#104928

## Behavior before

When registering a payment from a payslip, the action opened the payment register wizard on **all** journal entry lines (`move_id.line_ids`). This could:

- produce an inconsistent payment wizard (because it’s not anchored to a single payable/receivable line),
- reconcile against unintended lines,
- and fail to reliably trigger the **Paid** transition.

Additionally, after reconciliation, the payslip was marked as **Paid** only if **all** journal entry lines had zero residual, which is not a reliable indicator of whether the employee **NET payable** has been fully paid.

## Behavior after

- The payslip **Register Payment** action now opens the payment register wizard only on the payslip’s **NET payable** move line (credit line on the NET salary rule’s credit account, with the employee work contact as partner).
- After reconciliation, the payslip is marked as **Paid** once its **NET payable** line(s) are fully reconciled (residual is zero), and the wizard posts chatter messages linking the payment and the payslip (preserving upstream behavior).

## Root cause

Two issues combined:

1. The payment register wizard was invoked on `move_id.line_ids` instead of on the payable line(s) only. The wizard is designed to work on payable/receivable lines; opening it on all move lines breaks assumptions and can lead to incorrect behavior.
2. The **Paid** transition relied on checking residuals for **all** move lines, which does not correctly represent “employee NET salary has been paid”. Only the residual of the **NET payable** line is relevant for payroll payment completion.

## Steps to reproduce

1. Ensure the company is configured for the **individual payslip accounting entry** workflow (one journal entry per payslip), and that the **NET** salary rule has a **reconcilable** credit account.
2. Validate a payslip so it generates a **posted** journal entry containing a **NET credit** line.
3. Open the payslip and click **Register Payment**.
4. Observe that the wizard is opened on **all** move lines (not just the **NET payable** line), and payment/reconciliation behavior can be inconsistent.
5. Register and post the payment; observe that the payslip may fail to transition to **Paid** unless **all** move lines are fully reconciled.

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Currently journal items shown don't belong to the account group that
they should belong to, and from saas-18.3 an error will be generated
after following the below steps or step mentioned in ref PR [1].

- Install `Accounting (accountant)` with demo data
- Create account groups e.g., name as `Test 1` and code prefix `1 to 1`
- Go to the general ledger report
- Click on `Journal Items` of the account group line `1 Test 1`

Error from saas-18.3:
`ValueError: Cannot convert account.account.group_id to SQL because it is ...`

This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the
`account.account` model to the search domain. However, in 18.0, commit [2] modified
this field so that it is no longer stored. As a result, when a search domain includes
this `non-stored` field, Odoo skips the domain evaluation and logs a error at code
line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0.

Also, starting from saas-18.3, passing such a non-stored field in a domain raises an
explicit error at code line [4], instead of being silently ignored.

This commit resolves the issue by introducing an SQL query that
returns the account ids related to `record_id(account group id)`
include `record_id` as `None`.

[1]: https://github.com/odoo/enterprise/pull/100191
[2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767
[3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174
[4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201

sentry-7100657414

Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons:

1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date.
2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report.

Additional fixes and improvements:

- Correctly map columns 18 to 26 in Report 13.1:
  - 18–20: Incoming movements
  - 21–23: Outgoing movements
  - 24–26: Final balance
- Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost.
- Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation.
- Extend test coverage to include cases where the report includes opening balances due to past transactions.
- **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements.
- **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type:
  - `25` for incoming reversals
  - `24` for outgoing reversals
- Force operation type `99` for all `A1` lines, as required by the report.
- Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo.

Forward-Port-Of: odoo/enterprise#88592