Creating a POS order with negative quantity to manually refund a product (without using the Refund action, e.g. when the original order is not in the POS) and then requesting an invoice produced a customer invoice (INV) instead of a credit note (RINV).

Steps to reproduce:
-------------------
* Open a POS session.
* Create a new order (do not use "Refund" from an existing order).
* Add a product with negative quantity to simulate a manual refund.
* Set a customer and request an invoice for the order.
* Pay the order (negative amount).

> Observation:
The system creates a customer invoice (INV) instead of a credit note (RINV).

Why the fix:
------------
* Invoice type was decided only from the `is_refund` flag, which is set only when the order is created via the Refund action. Manual refunds (negative qty) never had `is_refund` set, so they were treated as sales and got `out_invoice`.
* `_prepare_invoice_vals` now treats an order as a refund when `is_refund` is True or `amount_total < 0`, so `move_type` is `out_refund` for manual refunds and a RINV is created.
* `_get_invoice_lines_values` now uses the same condition (`is_refund or amount_total < 0`) to compute `is_refund_order` for the quantity sign. That way invoice lines keep positive quantities and the credit note has a positive total.

opw-5898700

Forward-Port-Of: odoo/odoo#248791

Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen.

### **Steps to Reproduce:**
1) Install the POS Restaurant app with demo data.
2) Open a Restaurant Session.
3) Click on 'Register' to create a Direct Sale.
4) Add a product (e.g., Water with Qty 2) and a customer (e.g., 'Billy Fox'). 
5) Click on 'Orders' from the navbar and load the recently created order. 
6) Update the quantity of Water from 2 to 5 and click on 'Orders' again.

### **Error:**
The quantity of Water is not updated, the order line still shows a quantity of 2.

Ref video: https://drive.google.com/file/d/1XR5W5Klyyll3KujirKb3UuAELjMcA7yD/view

### **Root Cause:**
Clicking on 'Orders' calls `syncAllOrders` (see [1]), which is responsible for updating the orders. However, `this.getPendingOrder()` returns null in this scenario, causing the orders array to be empty and the function to return early without syncing.

### **Fix:**
Override `updateSelectedOrderline` in `OrderSummary`. This method is
invoked whenever the Numpad modifies an orderline. By calling
`addPendingOrder` within this method, we ensure that Numpad modifications
are correctly registered. This allows `syncAllOrders` to properly sync
the updated order with the server when navigating away.

[1]- https://github.com/odoo/odoo/blob/7fd5f90fe8fce4de49ec10c683f92e7a3557981a/addons/point_of_sale/static/src/app/services/pos_store.js#L1485-L1512

opw-5405402

Forward-Port-Of: odoo/odoo#240366

**Steps to reproduce:**
1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time):
- Thursday: 20:00 to 24:00
- Friday: 00:00 to 04:00
2. Assign the above calendar to an employee.
3. Set the Employee’s Timezone to Asia/Kolkata (UTC+5:30).
4. Assign an active Overtime Ruleset to the employee.
5. When the attendance calendar is in Europe/Brussels TZ 
- Check-in: Jan 15, 15:30 CET
- Check-out: Jan 15, 23:30 CET

Expected Behavior: Worked Hours = 8.0, Overtime (Extra Hours) = 0.0 
Actual Behavior (Bug): Worked Hours = 8.0, Overtime = 4.0

**Bug Cause:**
1. The _update_overtime function normalized the Ruleset version periods using time.min for both the start and end of the day.
This forced the validity period of the rules to end exactly at 00:00:00 UTC on the final day.
2. The overtime recalculation logic failed to delete existing overtime records because the search domain was incorrectly computed.
Specifically, using relativedelta(SU) and relativedelta(MO(-1)) without the weekday= keyword argument did not shift the dates to the week boundaries.
This resulted in an empty or incorrect deletion range, leading to duplicated overtime hours as new records were layered on top of un-removed old ones.

**Solution:**
1. Modified the version_periods_by_employee mapping to use time.max (23:59:59) for the end of the version period.
This ensures that the ruleset remains active through the entire final calendar day in UTC, allowing shifts that cross the midnight boundary to be fully captured.
2. Corrected the date range logic by explicitly passing the weekday argument to relativedelta.
This ensures the domain correctly targets the full week window - from the preceding Monday to the following Sunday, ensuring all relevant stale overtime lines are purged before recalculation.
3. Updated Manual Edit Handling: Refined the logic to detect days with manual overrides or "To Approve" statuses before unlinking. If an attendance change triggers a recalculation on such a day, the system now replaces the manual entry with the mathematically correct value but flags the new record with a to_approve status for manager review.
4. Adjusted the expected overtime in test_weekly_overtime to 18.0 to correctly reflect the cumulative calculation of daily overtime (2h/day) plus the weekly overtime threshold reached on Friday.

Task: 5710273

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

Forward-Port-Of: odoo/odoo#245247

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#109790
Forward-Port-Of: odoo/enterprise#105040

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#104771

Currently some providers require a customer to be registered on the order because the email address needs to be sent with the request. We the order does not have a customer the payment cannot be made using that provider.

Step to reproduce:
------------------
- Set up Amazon payment services on a online pos payment method
- Set this method as the online payment method for a self and also set is as payment method of the pos
- Place an order in the self or without a customer on the normal pos
- Try to pay it
> Observation: When the page is redirected to provider's checkout page,
an error occurs: Signature mismatch

Why the fix:
------------
On a normal pos shop we are simply ensuring that a customer with an address mail is registered on the order if the provider of an online payment method requires customer identification.
- When selecting the payment method on the payment screen if the payment method is online, requires customer identification and there's no customer on the order, the validate order button will be unavailable and the customer button is highlighted.
- When there is a customer the validate button is highlighted
- When validating the order if the customer does not have an email it will not go through and warn the cashier that the customer needs an email. This behavior is similar to the present "Delivery" which, if the cashier disregarded all popups, will not have the validate button available until a cashier is registered. Also if the selected customer doesn't have an address it will show a popup upon validation.

We are not doing anything regarding the self order as using presets like "Delivery" is compatible since the information required filled by the customer creates a partner in the db and sets it on the order. This preset ensures we always have a partner.

Other preset don't but we don't want to block flows that are currently working.

The list of providers requiring customer identification can be extended.

opw-5406501

Forward-Port-Of: odoo/odoo#245016

__

## Short functional explanation of the error
When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page.

## Reproduction Steps
1. Go to Time off > Configuration > Time off Types and click on any time off type.
2. A smart button Allocations should appear with a number in it. Note the number and click on the button.
3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation.
4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now.
5. Go back to the Time off type page and look at the number on the Allocations smart button.

### Expected behavior
As the allocation we set is still valid, the number shouldn't have changed.

### Unexpected behavior
The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity.

## Origin of the issue
The domain of the allocations to take into account when computing the count of valid allocations is defined here:
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year.
The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above.
__
opw-5504272

Forward-Port-Of: odoo/odoo#250992
Forward-Port-Of: odoo/odoo#248482

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

Forward-Port-Of: odoo/odoo#242264
Forward-Port-Of: odoo/odoo#224298

When the product category valuation is set to `real_time` but the
company is set to `periodic`, the POS session closing was not posting
COGS entries as expected. If the product category valuation is set to
`real_time`, it should always prevail over the company setting. And if
no valuation is set on the product category, then the company setting
should be used.

Steps to reproduce:
-------------------
* Create a product category with `Inventory Valuation` set to
  `real_time` (Perpetual).
* Create a product in this category and make sure it is storable and has
  a cost price.
* Set the company `Inventory Valuation` to `periodic` (Periodic).
* Create a POS order with this product and pay it.
* Close the POS session.
> Observation: In the session no COGS entries are created for the sold
  product.

Why the fix:
------------
We adapt the `_search_valuation` to correctly fallback on the company
setting only if the product category valuation is not set. It was not
working before because in some cases the product had no company set
(it means that it is visible to all companies) and the domain was not
matching. To fix that we check that the current company matches the
search value, and if it does we also match all the products without
company set.

We also adapt the PoS code to use the `product_id.valuation` field to
filter all the stock_moves that should create COGS entries when
closing the session.

opw-5885960

Forward-Port-Of: odoo/odoo#247011

`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:

- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model

We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:

```
  File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
    if invoice.pos_order_ids:
       ^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
    recs._fetch_field(self)
  File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
    self.fetch(fnames)
  File "/c19-1/odoo/orm/models.py", line 3055, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
    field.read(fetched)
  File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
    raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:

```
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
    return super()._create_update_invoice_document_from_invoice(invoice, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
    document = remaining_documents._create_update_document(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
    result_document = self.create({
                      ^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
    records = self._create(data_list)
              ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
    field.create([
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
    self.write_batch(record_values, True)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.

[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590

opw-6000974

Forward-Port-Of: odoo/enterprise#109461

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109880
Forward-Port-Of: odoo/enterprise#102126

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/enterprise#109873
Forward-Port-Of: odoo/enterprise#109645

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

### Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

### Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

### Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/odoo#252568
Forward-Port-Of: odoo/odoo#252190

Currently, in the Belgian VAT report, `61 – Various VAT regularizations in favor of the State` 
is displayed with a negative amount under `Taxes > IV Due`, which triggers a warning in the report.

**Steps to reproduce:**
- Install the `l10n_be` module and switch to the `BE company CoA`.
- Navigate to `Invoicing > Configuration > Taxes` and open any tax (e.g., 6%).
- Replace the `Tax Grid` with `61` on the second line under `Distribution for Invoices`, then `save`.
- Navigate to `Customers > Invoices` and create and confirm an invoice using this `tax`.
- Navigate to `Reporting > Tax Report` and select the current month.

**Observation:**
- The report shows a warning: `The report contains negative amounts. This is normally not allowed and could cause the tax authorities to reject it.`
- Case `61` under `Taxes > IV Due` displays a `negative` value.

**Root Cause:**
At [1], all formulas under `IV Due` use a negative sign (-XX) except for case `61`, 
which uses `61` instead of `-61`. Since the concept of `inverted tax tags` was 
removed in v19 in PR [2], case `61` must follow the same sign convention 
as the other `IV Due` cases to ensure correct reporting behavior.

**Fix:**
This commit updates the formula of case `61` to `-61`, aligning it with the 
other `IV Due` lines. As a result, the VAT report no longer displays an incorrect 
negative amount for case `61` and prevents the related `warning` from appearing.

[1]:
https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/l10n_be/data/account_tax_report_data.xml#L497-L596

[2]:
https://github.com/odoo/odoo/pull/225252

opw-5866225

Forward-Port-Of: odoo/odoo#248961

Currently, an error occurs when the user opens the shop page.

**Steps to Reproduce:**

 - Install `website_sale_stock` module.
 - Go to `Settings` and enable `Product Variants`.
 - Create a `product template` of type `Goods`.
 - Enable `Track Inventory`.
 - In the `Sales tab`, disable `Sell when Out-of-Stock`.
 - In the `Attributes & Variants` tab, add one attribute with two values and save.
 - Delete all variants using the `Variants smart button` or from Inventory > Products > Product Variants.
 - Go to `Website` > `Shop`.

**Error:**
`ValueError: Expected singleton: product.product()`

After [this commit], when opening the shop page, it calculates the quick add availability [1] 
for every product. It checks whether the product is sold out [2] to determine whether the quick 
add to cart button should be displayed or not. Since the product has no variants, it raises the 
error here [3]. Before 19.0, the quick add availability was calculated if the product had variants [4].

This commit ensures that if a product has no variants, it is treated as sold out. As a result, the 
quick add to cart button is not shown, as in the previous version.

[this commit]: https://github.com/odoo/odoo/commit/43d5226b500d64c3902eb1528e5d8e461766982c

[1]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L35-L39

[2]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_template.py#L33

[3]: https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/website_sale_stock/models/product_product.py#L41

[4]: https://github.com/odoo/odoo/blob/18d9baa690d6b103fbf8dbe875b3e00b056dd873/addons/website_sale/views/templates.xml#L400-L403

sentry-7287364112


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

Forward-Port-Of: odoo/odoo#250373

An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below.

Step1:
- install `crm` and `base_automation`
- Create a new automation rule for the `Activity` module and set the `Apply On` domain as below: `[("res_model", "=", "crm.lead"), ("state","=","done")]`
- An error will occur in the log when you open this record.

Step 2:
- Install `mass_mailing`
- Go to Email Marketing and create a record as below data
    - Recipients: `Contact`
    - Set domain as `[("vat_label", "=", 'test')]`
- An error will occur in the log when user open this record.


This issue occurred because the recently refactored commit [1] used `validate` of Domain for the domain instead of `search_count`. The `validate` method only checks the structure of the domain and does not verify whether the domain is actually executed or not.

This commit fixes the issue by reverting commit [1], restoring the previous behavior where the domain is evaluated using `search_count`.

[1]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b

sentry-7004977102

Forward-Port-Of: odoo/odoo#252379

The field `employee_salary_amount_is_percentage` is computed, but the computation[^1] relies on `hr_employee.salary_distribution`, a field restricted[^2] to members of `hr.group_hr_user`.

If you try to check a bank account without an hr group, you will get an access error:
```
odoo.exceptions.AccessError: You do not have enough rights to access the field "salary_distribution" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 21
Groups: allowed for groups 'Employees / Officer: Manage all employees'
```

This also happens during the mock crawl test of upgrades if the admin lacks the group.

To reproduce in standard:
- Install contacts and hr.
- Use a user without hr permissions.
- Try to create a new bank account.

[^1]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/res_partner_bank.py#L26
[^2]:https://github.com/odoo/odoo/blob/57573994313988837d89329d77ab1def63a8cfdd/addons/hr/models/hr_employee.py#L147
---

I've also added another commit to make the percentage symbol stick to the salary amount.
Before:
<img width="366" height="38" alt="image" src="https://github.com/user-attachments/assets/ef890852-50ca-40b1-8c09-07c4aa2d330d" />
After:
<img width="219" height="35" alt="image" src="https://github.com/user-attachments/assets/88e4a6c4-bc3f-483e-97f9-3080c6aa85c9" />
I know the number is not formated correctly but I don't think I can do more just from the view.

Forward-Port-Of: odoo/odoo#239298

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder leads to traceback.

Steps to reproduce:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quite builder tab, select a document.
4- Print -> PDF Quote.

This will lead to traceback.

Cause:
---
There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be
supported in future. Instead we use pypdf==5.4.0.

In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0):
https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061

FIX:
---
We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370

Note:
---
In this fix, we replace `is_upper_version_pypdf2` with specific version comparison.
To be precise `getNumPages` is depreciated in version 1.28.0 [2].

References:
---
[1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0
[2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514

opw-5784464

Forward-Port-Of: odoo/odoo#250329

# How to reproduce
- A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx)
- This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size)
- If the system parameter web.max_file_upload_size is set, delete it and refresh your page
- Pick any form view and add a file field with studio
- Upload a file larger than the limit set in the proxy, but smaller than 128mb
- Save the form

# The problem
The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+)

# Why
When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb).

So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json.

Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one.

opw-5891662

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

Forward-Port-Of: odoo/odoo#252527
Forward-Port-Of: odoo/odoo#249025

*google_address_autocomplete,partner_autocomplete

This commit aims at fixing the behavior of 2 field widgets using the Autocomplete component.

Those widgets rely on the `useInputField` hook, because they basically render an input (spiced with the autocomplete feature), so they must handle "manual" updates (listen to `input`, `change`, `keydown` events), like regular input fields.

However, the input also acts as a "search bar" for the autocomplete. As a consequence, it might happend that the `useInputField` hook internals weren't correctly reflecting the actual state of the field.

Here's a faulty scenario to highlight the issue, involving any of the two widgets:
 - open a form view with the field set to value "XYZ"
 - type in the input "ABC" and select a suggestion from the autocomplete dropdown => say the value is now "Value ABC"
 - manually erase the content of the input and type "XYZ" as before
 - save => the value sent to the server was actually "Value ABC"

The reason is that the hook still believes that the field is dirty after the value has been picked from the dropdown, and set (in the model) to "Value ABC", so `lastSetValue` isn't correctly updated to "Value ABC" (it's still "XYZ"). Later on, after the manual update to go back to the value "XYZ", we compare this value with `lastSetValue`, and as they are the same, we do nothing, so the value in the model remains "Value ABC".

Those widgets need to use the hook, because the logic encapsulated inside it is really tricky and we don't want to duplicate it. But the hooks internals aren't exposed, and we don't want to expose them to keep it under control. So we did the fix inside the hook itself: in `useEffect`, so after a patch, if the value in the model is the same than the value in the input, it means that the field isn't dirty anymore, so we force-reset the flag to `false`. This scenario only makes sense for inputs that are handled both internally by the hook and externally (e.g. by the autocomplete).

Task~6018655

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#252829

Currently, an error occurs when the scheduled action "POS Pricer: Tags Update Synchronization" runs.

**Steps to Reproduce:**

 - Install the `pos_pricer` module.
 - Go to `Scheduled Actions` and run `"POS Pricer: Tags Update Synchronization"`.

**Error:**
`
ValueError: TypeError("PricerStore._update_pricer_tags() got an unexpected keyword argument 'update_all'") while evaluating 'model.search(([("pricer_tag_ids", "!=", False)]))._update_pricer_tags(update_all=False)'`

This error occurs because, after this [recent commit], `_update_pricer_tags` was changed to 
no longer accept the `update_all` argument and now relies on the `needs_pricer_update` instead. 
However, the scheduled action still passes the `update_all` argument [1], which causes the
 error when the cron job runs.

This commit removes the unexpected `update_all` argument from the tag update synchronization cron.

[recent commit]: https://github.com/odoo/enterprise/commit/166a8a240d0588f4e908ce09c4639da1216ba3b7

[1]- https://github.com/odoo/enterprise/blob/0ef7643bba5b3fa3d22ab122ef3b65f0d67c8fb7/pos_pricer/data/pricer_ir_cron.xml#L9

sentry-7324339777

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/04d519e592 [REL] 19.2.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/fdaade3e5c [FIX] spreadsheet: fix zoomable chart cursor [Task: 5012198](https://www.odoo.com/odoo/2328/tasks/5012198)
https://github.com/odoo/o-spreadsheet/commit/ed7ce1c9e4 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572)
https://github.com/odoo/o-spreadsheet/commit/1c54150e4c [IMP] functions: Add `ISFORMULA` function [Task: 6013888](https://www.odoo.com/odoo/2328/tasks/6013888)
https://github.com/odoo/o-spreadsheet/commit/32709c4560 [FIX] selection_input: disable spill references [Task: 5945112](https://www.odoo.com/odoo/2328/tasks/5945112)
https://github.com/odoo/o-spreadsheet/commit/b0f06197d4 [FIX] charts: remove zoom slicer for scatter plot [Task: 5388389](https://www.odoo.com/odoo/2328/tasks/5388389)
https://github.com/odoo/o-spreadsheet/commit/0cd9a76df9 [FIX] pivot_style: assert pivot is valid before creating a table [Task: 5932073](https://www.odoo.com/odoo/2328/tasks/5932073)

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>

Currently an error occurs when user tries to upload a svg image as a logo in document layout.

Steps to replicate:
- Initialize a db and open settings.
- Under the Document Layout section, click on `Configure Document Layout`.
- In the logo field add any SVG image.

Error:
```
  File '/home/odoo/odoo19/community/addons/web/models/base_document_layout.py', line 106, in _compute_logo_colors
    wizard.logo_primary_color, wizard.logo_secondary_color = wizard.extract_image_primary_secondary_colors(wizard_for_image.logo)
                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo19/community/addons/web/models/base_document_layout.py', line 215, in extract_image_primary_secondary_colors
    base_w, base_h = image.size
                     ^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'size'
```

Cause:
- As user added an svg to the logo field, `tools.ImageProcess(logo)` tried to load the SVG which returned `self.image` as False because we dont process SVG or WEBP images [1].

- Later when we try to access `image.size` where image is false, we get error.

Solution:
- In earlier versions the method `base64_to_image()` was used [2], which raised an UserError on attempting `Image.open()` on a SVG.

- This error was caught by the try except block and returned `False, False` [3].

- To match to this behavior we return from the function when there is no image.

[1]: https://github.com/odoo/odoo/blob/4b2aaf2b711c9cfd8fd9f4a5915d6310064af6a9/odoo/tools/image.py#L83-L85

[2]: https://github.com/odoo/odoo/blob/39974cea6c37d21e21e3ed46a914d58f5ac16aad/addons/web/models/base_document_layout.py#L207

[3]: https://github.com/odoo/odoo/blob/4b2aaf2b711c9cfd8fd9f4a5915d6310064af6a9/addons/web/models/base_document_layout.py#L207-L211

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