**Steps to reproduce:**
1. Install Payroll and Time Off modules on v19.2.
2. Create a public holiday via the form view (Time Off -> Configuration -> Public Holidays). Do not enter a work entry type and save.
3. Open Payroll and try to create a payslip for any employee in the same month as the public holiday you will face below traceback.

**Issue:**
The `work_entry_type_id` is required for payroll calculations. If it is null the `_round_days` calculation evaluates an empty recordset, producing a [ValueError](https://github.com/odoo/enterprise/blob/39095789c2b6a7e558d11f479a249871b3b800b6/hr_payroll/models/hr_payslip.py#L1021
). 
While in this [PR](https://github.com/odoo/odoo/pull/254666/changes) made this field was made required in the
list view, it was missed in the form view. This allows users to save a holiday without a work entry type, crashing payslip generation later.

**Solution:**
Make the `work_entry_type_id` field required in the form view as well to prevent the creation of inconsistent public holiday records.

**Traceback:**
```.py

  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/hr_payslip.py",
line 1021, in _round_days
    day_rounded = float_round(days, precision_rounding=precision_rounding,
rounding_method=work_entry_type.round_days_type)
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/float_utils.py", line 152, in
float_round
    raise ValueError(msg)
ValueError: unknown rounding method: False
```

opw-6477587

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

Forward-Port-Of: odoo/odoo#283762

## Steps to reproduce:

- Create a customer with France E-Invoicing (UBL2.1) as eInvoice format in a French company
- Go to the PoS, select that partner
- Make a sale and ask for an invoice
- The downloaded invoice will be a pro-forma invoice

## Why the fix:

The pro-forma should not be used here, it is because it is used as a fallback when we get an error while trying to print the invoice.
https://github.com/odoo/odoo/blob/4a508586970e44367bbdbbb3cbe88ffb5a1eadb7/addons/account/models/account_move.py#L6187-L6204

As we get an error while trying to send the data with this setup, it goes to the fallback and prints a pro-forma invoice, even though this should not be the case, a regular invoice would do.

This happens because when an error is found, we do not populate invoice_pdf_report_id, so it goes to the fallback.

We now check if there are any errors in the order, and if there are and the customer requests an ubl_21_fr invoice, we just print the invoice as it is, without going to the pro-forma fallback, as this is not the intended flow.

With this fix, we now have the same flow as we do in the sales module, that allows the sale even if the customer has missing data. It will just print the invoice and allow the sale but won't send anything to external entities.

opw-6428369

Forward-Port-Of: odoo/odoo#281420

**Steps to reproduce:**

- Install PoS and Purchase
- Make 2 companies, A and B
- On product "Office Lamp" that is accessed by both companies, put Partner A in the vendor tab for company B
- Company A should have a Partner A and Partner B in this tab
- In the stock, set a replenishment for company A, with Partner A on Office Lamp
- Go to company B and open the PoS
- Try to buy Office Lamp while requesting an invoice
- An access error appears

**Why the fix:**

When requesting an invoice in the PoS, we try to create the stock picking. Doing so will trigger the replenishment rules linked to the product to be recomputed.

Those are executed when we **flush_all()**, processing Company A's replenishments as sudo(), meaning all of Company A's **seller_id** are fetched and cached. This means the product's **seller_ids** now contains Company A's **seller_id**, even though we are currently in Company B.

While trying to get the product's code, we iterate over **product.seller_ids**, but we do not have access to every record in that product.
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/product/models/product_product.py#L337-L343

As we don't have access to those, we get an access error when we stumble upon it.

To avoid those errors, we now filter the sellers to only have the ones compatible with our current Company in the given product we are currently buying.

Another solution would be to do **product.invalidate_recordset(['seller_ids'])** before looping over it, but feels more like a band-aid than the current fix IMO.

We could also write **self.lines.product_id.mapped('code')** in **_create_order_picking(self)** to have the solution be in PoS directly, but the error might arise from somewhere else at some point, and this just hides the issue by adding the code to the cache so that we don't have to fetch it again later.

opw-6308182

Forward-Port-Of: odoo/odoo#275354

Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types.

This results in invoice reports showing the identification number next to an incorrect label.

This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in
their respective invoice template to match the selected identification type.

Steps to reproduce:
- Install a latam localisation (Uruguay or Guatemala)
- Change company to that country's Company
- Create a partner located in said country, ensure the identification number is set to something else than the default one
- Create an invoice for the partner, confirm it, and then Send it
- In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label

opw-6087359

related to: https://github.com/odoo/odoo/pull/260159

Forward-Port-Of: odoo/enterprise#122512

# How to reproduce
- Set the current employee's schedule to one with :
    - Schedule Type : Flexible
    - Total : a different amount than "Full Time Equivalent"
- Go to My Timesheets
- Add a new line with some Time Spent > 0
- Hover the bottom right cell of the grid (this is the total overtime for the week)

# The issue
The computation of the overtime for the week is based on "Full Time Equivalent" instead of "Total". This is inconsistent with the Planning app and the All Timesheets view.

# Cause
This [PR] introduced the usage of `full_time_required_hours` to compute the total overtime. This field was used because `hours_per_week` ("Total") was thought to be computed using `resource.calendar.attendance`. However, that is not the case when the schedule is flexible : https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L220 https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/resource/models/resource_calendar.py#L163-L166

[PR]: https://github.com/odoo/enterprise/pull/81057

opw-6303520

Forward-Port-Of: odoo/enterprise#130087
Forward-Port-Of: odoo/enterprise#125510

Versions
--------
19.0 and later

Steps
-----
- Install `sale_stock_renting`.
- Go to Rental > Orders > Rental Schedule.
- Create a new rental order line from a cell of the gantt view, on a row grouped by a storable rentable product.

Issue
-----
The first line of the description of the created line is named "Bike (3 items)" instead of "Bike".

Cause
-----
The `display_name` override adding that quantity is keyed on the `in_rental_schedule` context key. That key is set on the `action_rental_order_schedule` action itself, so it is part of the search context and is propagated to every record, dialog and dropdown opened from the schedule, while it is only meant to flag that we are in the schedule (default values conversion, hidden onchange buttons, group expansion, ...).

Solution
--------
Introduce a dedicated `display_renting_stock_quantity` context key and depend on it instead when fetching data to build the gantt rows, leaving the records opened from the schedule with their regular display name.

Forward-Port-Of: odoo/enterprise#130513
Forward-Port-Of: odoo/enterprise#130322

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

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

Forward-Port-Of: odoo/odoo#258604

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

Forward-Port-Of: odoo/enterprise#113498

### Issue before this commit:
When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Currencies and activate another currency like EUR
3. Go to Journals and create a new one with bank type and curency EUR
4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal
5. Go to test bank journal and create a new bank matching
6. After the line is created click the 3 dots and go to Manage Models
7. See that the new model Tester created does not appear

### Cause of the issue:
Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. 
https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100

### Reason to introduce the fix:
The filter is not working correctly. In this case it's better to change 
it to a domain instead of a default filter.

opw-6481970

Forward-Port-Of: odoo/enterprise#129992

The module introduced in [PR](https://github.com/odoo/odoo/pull/253629) has a side-effect when updating the translation, for whatever reason, the overridden __iter__ [file reader classes](https://github.com/odoo/odoo/blob/0f905e81b1c69d6c5dd2a7facf2a772f86036450/addons/test_translation_mode/tools/translate.py#L80-L93) were being used eventhough a given DB hosted on the same server **had not** installed `test_translation_mode`.

How to reproduce locally
* locally, generate at least two distinct saas-19.3 DB
* run odoo-bin with a db-filter that whitelists both
* start it up
* Go to DB-A, and install a new language and check the JSONB columns (e.g. "name" on ir.model) -> All good
* Go to DB-B do the same -> all good
* On DB-B, install `test_translation_mode` -> the PO files get reloaded and the strings will have the bitmap encodings
* (Without shutting down the odoo-bin instance) Switch to DB-A. Reload a given language -> The PO files will be re-read and ALSO have the bitmap encodings
* Uninstall `test_translation_mode` on DB-B and restart odoo-bin. Then reload languages -> Problem gone

What is happening:
The way the [module works](https://github.com/odoo/odoo/blob/saas-19.3/addons/test_translation_mode/tools/translate.py) is by overriding the base file reader classes used in the standard update translation code base. But as is, this means when the module get's initialized for any DB, it will override the class for the whole python runtime and inject `contextualize_entry()` into the __iter__ attribute of the Class, defacto modifying the file readers classes for all DBs on a given server and changing the behaviour of updating the language files and translations stored in SQL.

Proposed stable fix:
Make `contextualize_entry()` "context" specific, i.e. check if the DB that calls the file readers has the module installed, if not, return the unmodified value instead of the overridden value with the hidden unicode characters.

OPW-6485935

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

Sending an invoice to ZATCA again after it was rejected raises a traceback.

Steps to reproduce the error:
- Install the ``l10n_sa_edi`` module with demo data
- Switch to the Saudi Arabian company.
- Create a new invoice:
    - Customer: ``Your Company``
    - Add two invoice lines:
        - Line 1: Price = 1, Tax = 15% Sales
        - Line 2: Price = -1, Tax = 0% EX G
- Confirm the invoice.
- Click Send, select To ZATCA, and click Send(Invoice will be rejected by ZATCA)
- In the ZATCA tab, click the Retry button on the record.

After [commit], ``l10n_sa_qr_code_str`` is set to False for rejected invoices at [1].
When the rejected invoice is sent again, the QR code is applied to ``signed_xml`` at [2].
However, ``l10n_sa_qr_code_str`` is False, causing a traceback when its value is assigned to ``qr_node.text``.
https://github.com/odoo/odoo/blob/7c5362afdff8a5bba8593087ce8fbb04ef3a0fb2/addons/l10n_sa_edi/models/l10n_sa_edi_document.py#L279-L281

[commit]:https://github.com/odoo/odoo/commit/71e43c97ba344202114ff283360ebc5edd796a61

[1]:https://github.com/odoo/odoo/blob/7c5362afdff8a5bba8593087ce8fbb04ef3a0fb2/addons/l10n_sa_edi/models/zatca_mixin.py#L22-L26
[2]:https://github.com/odoo/odoo/blob/7c5362afdff8a5bba8593087ce8fbb04ef3a0fb2/addons/l10n_sa_edi/models/l10n_sa_edi_document.py#L291

Solution:
Prevent the QR code from being applied when ``l10n_sa_qr_code_str`` is False.

sentry-7674776014

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

**Step to reproduce :**

1. Create Product A and enable lot tracking for it.
2. Create a Kit product and add Product A as one of its components.
3. Go to PoS and create orders using:
  - Product A
  - The Kit product
  - A combination of Product A and the Kit product
4. Create three different orders with these combinations.
5. Try to close the PoS session.

**Issue :**

An error occurs when attempting to close the PoS session.

The issue is in the pos_mrp module, specifically in the _get_lot_line_qty method. When accessing the following line:

`lines_data[move.bom_line_id.bom_id.product_tmpl_id.product_variant_id.id]['order_lines'].qty`

we expect order_lines to contain a single record. However, in this scenario, multiple order lines can be returned for the same product. As a result, accessing .qty directly on order_lines raises a singleton error.

**Solution :**

With this fix, we first retrieve the quantity from each order line and thensum the quantities together.

This ensures that multiple matching order lines are handled correctly and prevents the singleton error when closing the PoS session.

opw-6442765

Forward-Port-Of: odoo/odoo#285612
Forward-Port-Of: odoo/odoo#281622

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `quality_control` module
- Create a picking order with a product
- From the gear menu, create an on-demand Quality Check
- Set the check to *Control per Quantity* and back to the picking
- Set the done quantity to 10
- Open the Quality Check wizard
- Try to fail 3 units

Issue:
------
Validating the partial failure raises a `ValidationError`:

    - Missing required value for the field 'Team' (team_id)

The quality check split is not performed and the picking cannot be processed.

Cause:
--------
Quality checks created on-demand from the picking (via the gear menu) have 
no associated `quality.point` or `stock.move.line` — only 
`picking_id` is set at creation time.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457

In `_move_to_failure_location()`, the `move_line` branch assumes 
`check.move_line_id` is populated. Since it is empty for on-demand 
checks, the split logic operates on an empty recordset.

The new quality check for the split is then created via:

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493

At this point both `failed_move_line` (a copy of the empty move line) and
 `check.point_id` are empty. `_get_check_values(False)` cannot derive 
fields normally sourced from the quality point (`team_id`, `company_id`,
 `measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation.

Fix:
----
- If the quality check is not linked to a move line, find the matching move line
 from the picking before splitting the failed quantity.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97

- `_get_check_values()` normally takes values from a Quality Point. 
Since on-demand quality checks do not have one, fill the missing 
values (`team_id`,  `measure_on`) from the original quality check instead.

This allows manually created quantity-based quality checks to be 
split correctly after a partial failure.

---

opw-6428749

Forward-Port-Of: odoo/enterprise#130275
Forward-Port-Of: odoo/enterprise#126505