`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

**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

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

# 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#252325
Forward-Port-Of: odoo/odoo#249025

### Issue:
When in the Gantt view of service projects, grouping by project results in a traceback.

### Steps to reproduce:
- Create another field service project 
- Create a task in the new project and add start and end dates
- Go to Field service > my tasks > gantt view > group by project 
- Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'`

### Cause:
This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82

But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format:

https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626

### Solution:
We use the method `parse_date()`, which was added with dynamic dates, to parse them.

opw-5955317

Forward-Port-Of: odoo/enterprise#109236

****Behavior:****
**Current:**
In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user.

**Expected:**
The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list.

**Steps to reproduce:**
- Be in a multicompany environment: company A and B
- Create User with access to both but only one employee record for company A
- Switch to company B
- Create 2 services product, both creating a task in the same project.
- Activate Billable Rate Indicators in the settings
- Create a quote with both services and confirm
- Go to the related project, and in the Invoicing tab, link employee from company A to SOL2
- As the user, check both companies but set company B as current active
- Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured.

opw-5159195

Forward-Port-Of: odoo/odoo#234200

# 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

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

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

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

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

### 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#109645