When selling a bom kit that have some components that applies on specific variants only, the picking was not correctly created. It would only take one kit variant into account, even if you sold 2 kits with different variants.

Steps to reproduce:
-------------------
* Create a product P
* For product P, create an attribute with type "No variant" and values V1 and V2
* Create a BoM Kit for product P, with 3 components C1 C2 and C3
  - C2 applies only for variant V1
  - C3 applies only for variant V2
* Create a POS order with 2 lines of product P:
  - 1 with variant V1
  - 1 with variant V2
* Validate the order and check the created picking
> Observation: Only C1 and C2 are in the picking, C3 is missing

Why the fix:
------------
When creating the picking, the code was grouping the order lines by product only, and not by product variant. Therefore, the 2 lines would be grouped together, and only one of the variant-specific components would be taken into account.

opw-5051289

Forward-Port-Of: odoo/odoo#237844
Forward-Port-Of: odoo/odoo#235528

_
## Short functional explanation of the error
When creating a time off allocation with a time off type expressed in hours, and having start/end dates for every attendance in the corresponding calendar, an error is raised.

## Reproduction Steps
1. Go to Employees and click on the Configuration tab > Working Schedules.
2. Click on a schedule and click on the button next to Work Entry Type to show the Starting date.
3. Set a starting date for each entry.
4. Go to Time Off. Click on the Configuration tab > Time Off Types.
5. Click on a time off and next to the Take Time Off in, select Hours.
6. Click on the Management tab > Allocations. Click on New.
7. Select an employee that has the schedule you updated earlier.

## Expected behavior
The allocation is created.

## Unexpected Behavior
A traceback occurs:
``` ZeroDivisionError: float division by zero ```

## Origin of the issue
When setting a start or/and an end date to an attendance, this
attendance won't be taken into account for global attendances anymore.
This leads to an erroneous computation of hours_per_day, leading to
a few issues; one of them is related to time off allocation:
When setting a time off with a time off type expressed in hours,
if every single attendance in the calendar has a start/end date, there
will be no global attendance hours left, leading to a division by 0:
https://github.com/odoo/odoo/blob/8097b674a23858ed7692a0b30ca74419b8f890f7/addons/hr_holidays/models/hr_leave_allocation.py#L262


After discussion, we decided that this fix would only fix a symptom, and not the problem itself.
_
opw-5340056

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

Forward-Port-Of: odoo/odoo#237782

**Steps to reproduce:**
* Install and activate the **Uruguayan Localization** for the company.
* Create a contact located in Uruguay.
* Create an invoice for this customer and set **Document Type = 111 (e-Invoice)**.
* From the invoice's gear icon, create a **Debit Note**.

**Observed behavior:**
* The debit note is automatically assigned **Document Type 111 (e-Invoice)**, even though it should use **113 (e-Invoice Debit Note)**.
* Attempting to change the document type manually only shows 113 as an option, confirming the debit note should not have been set to 111.

**Cause:**
* `_compute_l10n_latam_document_type()` applies a rule that assigns Document Type **111** to all Uruguay electronic invoices with RUT identification.
* This logic does **not** check whether the move is a **debit note** (`m.debit_origin_id`), and therefore incorrectly overrides the expected debit note document type.
* The override prevents the correct selection (internal_type == *debit_note*) from being applied.

**Fix:**
* Add a condition in the automatic e-Invoice assignment logic.
* Debit notes now bypass the e-Invoice assignment and fall through to the parent method, which correctly assigns **Document Type 113**.

opw-5154599

Forward-Port-Of: odoo/enterprise#100938

Currently, an error occurs when creating a time off request for an employee.

Steps to Reproduce:

 - Install the `hr_holiday` module.
 - Go to `Management > Time Off`.
 - Create a `new time off` and `remove the start date`.
 - Now `change the employee`.

`AttributeError: 'bool' object has no attribute 'date'`

This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3].

This commit ensures that the system only checks whether the time off is in the past when a start date is provided.

[1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597

[2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279

[3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237

No Task ID

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

Forward-Port-Of: odoo/odoo#238281

Steps to reproduce:
-------------------
1. Install mrp_mps
2. Go to Inventory > Operations > Procurement > MPS
3. Click "Toggle search panel"(▼)
4. Click “Import Records”

Issue:
------
Nothing happens when clicking “Import Records”.

Cause:
------
After this 646bee6, initialization moved to `onWillStart()`, but it only runs
when the current action type is `ir.actions.act_window`. MPS triggers
the import from a [client action](https://github.com/odoo/enterprise/blob/142d86ad89435cd0751e9865ff62e8263a67e060/mrp_mps/views/mrp_mps_menu_views.xml#L4-L9), so the condition returns early and [get_import_templates](https://github.com/odoo/odoo/blob/f272eb19813be4254fd461ec21f1cc47e8834559/addons/base_import/static/src/import_model.js#L238) never loads.

Solution:
---------
Allow initialization for client actions as well, same as window actions.

Reference: MPS(Master Production Schedule)

opw-5248073



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

**Steps to reproduce:**
1. Install l10n_tw_edi_ecpay.
2. Switch to the TW company.
3. Go to Configuration → search for "ECPay".
4. Enable staging mode.
5. Enter all credentials.
6. Create a new invoice → select “Taiwan Semiconductor” as customer → set an email and leave the phone field empty.
7. Add a product → confirm → click “Send” → select only “Send to ECPay” → send.
 
> You can find ECPay testing credentials here : https://developers.ecpay.com.tw/?p=24174

**Issue:**
A traceback occurs while sending the e-invoice:
`AttributeError: 'res.partner' object has no attribute 'mobile'`
    
**Cause:**
In commit https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be the `mobile` field was removed from `res.partner`. The ECPay integration still attempted to read `partner.mobile`, which causes the traceback on versions where the field no longer exists.

Additionally, the code was still using the deprecated `self._cr` cursor reference, which was replaced by `self.env.cr` as part of the cleanup in: https://github.com/odoo/odoo/pull/193636/commits/ad7606195a4ba44bf9854506bf2e305d3dd13dbb

**Fix:**
Remove the reference to the obsolete `mobile` field and rely solely on the `phone` field, which is the only supported contact number field in 19.0. 
Also replace deprecated `self._cr` with `self.env.cr`

**opw-5357429**

**Description**

When a company's working schedule has flexible hours enabled, the timesheet grid was incorrectly displaying random weekdays as non-working days (greyed out cells). The affected days varied by month because the unavailability calculation was time-dependent.

**Steps to reproduce**

1. Enable flexible hours on company's working schedule
2. Go to Timesheets > All timesheets
3. Switch to Grid view and filter by month
4. Observe that random weekdays (e.g., Wed/Thu or Mon/Tue) are greyed out

**Fix**

The grid_unavailability method now checks if the company calendar has flexible_hours enabled. When true, it returns an empty list of unavailable days, treating all days as potential working days.

This fix adds the flexible_hours check in two locations within the grid_unavailability method to cover all code paths:
1. get_company_unavailable_dates() helper function - prevents unnecessary calculation when called as fallback
2. company_unavailable_days assignment from calendar_work_intervals - handles the direct path when company calendar is found

This follows the same pattern as the gantt view fix #100385

opw-5215646

Forward-Port-Of: odoo/enterprise#100881

The system will crash when user tries to create new bank statement line.

**Steps to produce:**
- Install `Invoicing` module without demo data.
- Go to `Configuration > Journals` and duplicate the default Bank journal to create `Bank (Copy)`.
- Dashboard and `Click on 3 dots` of Bank(Copy) and click on Transactions.
- Create a new transaction and set the Statement also(Create new and assign it).
- Go to that statements and Add a line and set the `foreign currency` as USD.

**Error:**
`ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)`

**Cause:**
- When we try to create a transaction in a statement of a non-default journal, its journal is not set by default, resulting in two records being fetched. At line [1], our code attempts to read `statement_id.journal_id` , but encounters multiple records, causing the issue.

**Solution:**
- Here I added context to pass `journal_id` as default and made `payment_ref` required(because at [2], also we do the same).
- Also added hidden `journal_id` field in the list view.

[1]: https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887
[2]: https://github.com/odoo/enterprise/blob/bff451101bb23b4f9acc7982ed1138d7cefa13b9/account_accountant/views/bank_rec_widget_views.xml#L220

**sentry-6928858335**
**opw-5256565**

## Issue:
When a fiscal position should apply based on the address provided during Express Checkout, it was not applied automatically
The correct fiscal position only appeared after reloading the checkout page
This issue affects public users using the eCommerce with Stripe Express Checkout

## Cause:
The fiscal position was correctly determined during the `availableCarriers` computation, but it was not propagated to the payment request itself
As a result, prices and taxes were only updated after a full page reload

## Steps to reproduce:
- Configure Stripe with Express Checkout (e.g., Google Pay)
- Create a fiscal position with automatic detection (Country = US, Tax mapping: 15% → 0%)
- Create a product using the 15% tax
- Go to the website shop and add the product to the cart
- Use Express Checkout with a US address
- Observe that the fiscal position is not applied unless the page is reloaded

opw-5018238

Forward-Port-Of: odoo/odoo#238690
Forward-Port-Of: odoo/odoo#236832

[FIX] website, website_crm: fix crash on save if property field in form
---

__Before commit:__
1. Go to CRM app
2. Open a lead
3. Add a new property field by clicking on the cogwheel at the top left
and then *Edit Properties*
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* to the newly created property field
7. Save
=> Traceback:
`ValueError: Unable to whitelist field(s) ['xxxx'] for model 'crm.lead'`

__Cause:__
We are trying to whitelist a property field which is not an actual field
to the `crm.lead` model but rather a property of one of the `crm.team`.

__Fix:__
Filter the property fields to whitelist.

---

[FIX] html_builder: make builder_list work with non-integer ids
---
__Before commit:__
1. Go to CRM app
2. Open a lead
3. Click on the cogwheel at the top left and then on *Edit Properties*
    - Set *Field Type* to *Selection*
    - Add two values
4. Open the website builder
5. Drag a new form
    - Set *Action* to *Create an Opportunity*
    - Set *Sales Team* to *Sales*
6. Add a new field and set *Type* as the newly created property field
7. Click on *Add New Radio*
=> There are still items to add although there are already all included.
8. Click on an item
=> Two tracebacks appear:
- `TypeError: Cannot use 'in' operator to search for '_id' in null`
- `TypeError: Cannot read properties of null (reading 'id')`

__Cause:__
When adding item to the selection, the id is casted to `Number` although
it can be a string if the field type is a property.

__Fix:__
When comparing two ids, cast both side of the comparison to strings to
make sure a match can always be found.

task-5248526

Forward-Port-Of: odoo/odoo#237638