__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#117247
Forward-Port-Of: odoo/enterprise#114147

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#116961
Forward-Port-Of: odoo/enterprise#112578

### Steps to reproduce:

- Install delivery_envia
- Website > Configuration > eCommerce > Delivery Methods > Envia
- Enable the delivery method, sync the carrier and Publish it
- With a portal user > Shop > Add any product to your cart > Checkout
- Register an address a valid 'Chile' address and confirm say: 
    'street and Number': Avenida Providencia 1432, Depto 402
    'city': Santiago 'zip': 8320000
    'country': Chile  'state': Metropolitana
#### > Envia Error: Invalid Option - String is too long at #->properties:destination

### Cause of the issue:

The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43 when the address is converted here:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542 That being said, the `Chile`'s code states of have been changed in [6694a3942c58ff1a56c9e4b36edbe126dd1e66f8](https://github.com/odoo/odoo/commit/6694a3942c58ff1a56c9e4b36edbe126dd1e66f8) to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6210007

Forward-Port-Of: odoo/enterprise#117280

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#117450
Forward-Port-Of: odoo/enterprise#115085

Steps to reproduce
1. Enable "Batch Account Move Lines" in the Payroll settings.
2. Configure two employees' versions with an analytic distribution on the
   same analytic account but with different percentages (e.g. {acc: 50}
   for the first employee and {acc: 70} for the second).
3. Generate a payslip run containing both employees and validate it.

Issue
The generated account move aggregates the two payslips into a single
line whose analytic_distribution matches only the last employee being
processed; the other employee's percentage is silently lost.

`_get_existing_lines` decides whether an incoming line can merge into an
already accumulated one. When the incoming line has an analytic
distribution, the merge condition delegates to
`_check_partially_matching_accounts`:

https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L254-L271
https://github.com/odoo/enterprise/blob/e4a1326c7a8a74da7970aeaa9900c19d01634e31/hr_payroll_account/models/hr_payslip.py#L273-L283

That helper returns True as soon as any analytic account of the new
line appears anywhere in the existing line's distribution dict, without
comparing percentages. Two distributions such as {acc: 50} and
{acc: 70} share the same account, so the helper returns True, the
lines are merged, and whichever distribution ends up on the merged line
overwrites the other — the total amount is correct but the analytic
split is wrong.

The logic introduced in commit https://github.com/odoo-dev/enterprise/commit/e40a3166286a6bc546e9543b935233d2a110dc52 successfully addressed merging for rule-level distributions
with composite keys (e.g., {'13,7,12': 40}). However, that implementation is overly inclusive for employee-specific distributions.
It fails to differentiate between cases where the same analytic account is utilized across various employees but with different percentage allocations.
Because it only checks for an account overlap rather than a perfect distributional match, it incorrectly aggregates distinct financial dimensions into a single journal line

Solution
Compare the full analytic_distribution dict by strict equality. Lines
merge only when the distribution is identical (same keys AND same
percentages), keeping the batch feature anonymizing identically
configured employees while preserving one line per distinct
distribution.

opw-6102508

Forward-Port-Of: odoo/enterprise#117453
Forward-Port-Of: odoo/enterprise#114156

In Mexico, the basic salary must be calculated based on the total calendar days of the period. This ensures that both worked days and non-working days (e.g. Sundays) contribute equally to the total payment. This calculation also applies to the daily schedule, as the proportional daily wage must be divided equivalently across the hours of the day.

Current behavior:
When an employee has an unpaid leave, the basic salary is incorrectly prorated using only the registered days/hours.
Example: For a monthly wage of 30,000 MXN in a month with 22 scheduled days (21 attendances + 1 unpaid leave), the implicit daily rate becomes 1,363.63 (30,000 / 22). This leads to an incorrect basic salary of 28,636.36 MXN for the days worked. This also happens with unpaid leave for x hours, e.g., for 2 hours, the unpaid leave is calculated as 2 hours * (30,000 / (22 days * 8 hours)) = 340.90 MXN, which is incorrect.

Expected behavior:
The basic salary should be derived from the full period (e.g., 30 days for a month, 15 for a bi-weekly period).
Example: For a 30,000 MXN wage, the daily rate should be 1,000 MXN (30,000 / 30 days). If there is 1 unpaid leave, the basic salary should be 29,000 MXN (29 days * 1,000 MXN), regardless of the number of scheduled working days in the calendar. For unpaid leaves by hours, e.g., for 2 hours, the unpaid leave should be calculated as 2 hours * (30,000 / (30 days * 8 hours)) = 250.00 MXN.

To achieve this, the calculation of the days in the `_get_worked_day_lines` is:
* Adjust worked days/hours for out-of-contract entries where necessary, ensuring that rest days(Sundays) are included in the count.
* Get all worked hours in the lines.
* Calculate the number of days to pay based on the total hours and the hours per day.

### Case: payslip does not cover the complete pay period
Current behavior:
If a payslip is created for a partial period, the total amount is the full period wage.

Expected behavior:
The total amount should be pro-rated based on the days of the period. For example, if a payslip is created for 25 days(with a monthly schedule pay), the total amount should be the daily salary multiplied by 25 days.

To achieve this, `_compute_amount` is updated to calculate the wage based on the `l10n_mx_daily_salary`.

Changes on tests:
* Add:
  * `test_monthly_payslip_with_partial_leave`, `test_partial_payslip`, `test_partial_payslip_new_hire_month_31_days` and `test_partial_payslip_new_hire_month_28_days`.
  * `test_hourly_payslip_by_attendance` to validate when `Work Entry Source` is set to "attendance".
* Update:
  * `test_hourly_payslip`, `test_monthly_payslip` and `test_partial_payslip_new_hire` to align with the new calculation.
  * Adjust payslips dates to match the `schedule_pay` in `test_regular_payslip_subsidy` and `test_weekly_schedule_pay_no_code`
  * Fix a one-day difference in `TestMxEdiHrPayrollCommon`(16 days instead of 15 days for a bi-weekly schedule), and update the corresponding CFDI values.
* Refactor tests and add new helpers.

### Error on [warning issues generation][1] and [`_compute_is_wrong_duration`][2]

The warning: `"The duration of the payslip is not accurate according to the structure type."` appears with these custom periods for Mexican Payroll, although the period is correct:
* `10_days`
* `14_days`
* `bi-weekly`

Steps to replicate:
* Install `l10n_mx_hr_payroll` module.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Employees and open "Cesar Osbaldo Cruz Solorzano".
* Click on "Payroll" tab, change the "Pay Schedule" to any option listed above, for example "Bi-weekly".
* Go to Payroll > Payslips > Payslips and create a new pay run.
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and the Period '01/01/2026 -> 01/15/2026'.
* Click on "Continue", select Cesar and click on "Select".
* It appears the warning issue.

Problem:
The warning is raised because of `slip.date_from + slip._get_schedule_timedelta() != slip.date_to` condition, because `_get_schedule_timedelta` function calls [`self._schedule_timedelta(schedule, self.date_from)`][3] without the `country_code` argument.
In the Mexican Payroll [_schedule_timedelta is overriden][4] but it is necessary to call it with the country code to use the custom periods; similar to how the [`date_end` is computed][5].

Solution:
Call `_get_schedule_timedelta` passing the `country_code`

[1]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1367
[2]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1454
[3]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L275
[4]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/l10n_mx_hr_payroll/models/hr_payslip.py#L58
[5]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip_run.py#L211

target: 19.0
task-6073601

Forward-Port-Of: odoo/enterprise#116883
Forward-Port-Of: odoo/enterprise#112524

Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

Forward-Port-Of: odoo/enterprise#116914
Forward-Port-Of: odoo/enterprise#112522