## Issue:
Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year.

## Steps to reproduce:
- Create a fiscal year A of one month for year X-1 (December 1st to December31th year X-1)
- Create a fiscal year B of 1 year and 1 month (January 1st Year X to January 31th year X+1)
- Create Invoices in November year X-1, December year X-1, year X and in January year X+1 and confirm them
- Go to General Leder
- Set date to the fiscal year B
- Export as SIE4

### Current behavior:
- **for previous fiscal year**
	- declared fiscal year (#RAR field) goes :
		- from fiscal year X date_from -1 year
		- to fiscal year X date_to -1 year
	- However data are computed:
		- from fiscal year X date_from -1 year
		- to fiscal year X date_from -1 day
- **for current fiscal year**
	- declared fiscal year (#RAR field) goes :
		- from fiscal year X date_from
		- to fiscal year X date_to
	- However data are computed:
		- from fiscal year X date_from
		- to fiscal year X date_from +1 year

### Expected behavior:
Declared fiscal year match the one that is use for computation.
- for previous fiscal year
	- from fiscal year X-1 date_from
	- to fiscal year X date_from -1 day
- for current year
	- from fiscal year X date_from
	- to fiscal year X date_to

Cause:
Current year length was wrong because it [relied on](https://github.com/odoo/enterprise/blob/22b4100006ec24bf6e4b64042cbfdba360fcf470/l10n_se_sie4_export/models/account_general_ledger.py#L139-L140) the next_date_from which was wrong.


opw-6264766

Forward-Port-Of: odoo/enterprise#125354

**Step To Reproduce:**

1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display).
2. Create a new order in the POS and add the first product.
3. Observe that the order does not appear on the Kitchen Display.
4. Add a second product to the same order.
5. Observe that the order now appears on the Kitchen Display.

**Issue:**

The first product of a new restaurant order is not synchronised with the Kitchen Display when the German Fiskaly localisation is enabled.

**Reason:**

`syncAllOrders()` only processes orders returned by `getPendingOrder()` and ignores orders explicitly passed through `options.orders`. After the initial Fiskaly synchronisation, the order is serialised and removed from the pending queue. Consequently, the Preparation Display synchronisation receives no orders from `getPendingOrder()`, preventing the order from reaching the backend.

**Solution:**

Update `syncAllOrders()` to prioritize the orders explicitly provided through `options.orders`. When `options.orders` is not available, fall back to the existing behavior by synchronizing the orders from `orderToCreate` and `orderToUpdate`.

opw-6321376

Steps to reproduce:
-------------------
1. Install Timesheets.
2. Create a new employee with a fully fixed working schedule (40h/week).
3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours).
4. Observe the overtime indicator for the employee (it shows 32 hrs)
   (Click the left arrow to display it).
5. Change the timesheet encoding unit to "Days / Half-Days".
6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days).
7. Install a language other than English (e.g. French).
8. Return to Timesheets and observe the overtime indicator again.

Issue:
--------
The remaining time value changes unexpectedly and displays 32 hours instead of 4 days.

Cause:
---------
In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`.

Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead.
https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169

Solution:
-----------
Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values.


see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82

opw-6279133

Forward-Port-Of: odoo/enterprise#125909
Forward-Port-Of: odoo/enterprise#120595

Steps to reproduce:
-------------------
1. Install `documents_hr` and `web_studio` with demo data.
2. Add `document_count` to the Employees list view via Studio.
3. Create a second company with an employee, enable multi-company.
4. Open Employees list, click **All** in the search panel.

Issues:
------
Issue 1:
```python
File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 25, in _compute_document_count
    if not self.company_id.documents_hr_settings:
File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1429, in __get__
    record.ensure_one()
File "/home/odoo/odoo/community/odoo/orm/models.py", line 5640, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.company(1, 2)
```

Issue 2:
```python
  File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 31, in _compute_document_count
    ('partner_id', '=', self.work_contact_id.id)
  File "/home/odoo/odoo/community/odoo/orm/fields_misc.py", line 117, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(9, 8, 7)
```
Cause:
---------
https://github.com/odoo/enterprise/blob/38674448e387159d28f98c1678856fcaf5f7f52e/documents_hr/models/hr_employee.py#L23-L48
1. The document count computation assumes all employees belong to the same company by directly accessing `self.company_id.documents_hr_settings`. In a multi-company environment, `self` may contain employees from different companies, making self.company_id a multi-recordset and triggering a singleton error.

2. Similarly, when `documents_hr_settings` is disabled, the fallback computation accesses `self.work_contact_id` on a multi-recordset, causing another singleton error.

Solution:
-----------
Split the employees based on whether `documents_hr_settings` is enabled and compute each group separately.
Additionally, use the current employee's `work_contact_id` in the fallback computation to avoid singleton error.

**NOTE:**
This has been resolved from saas-19.4 onward with this improvement [commit](https://github.com/odoo/enterprise/commit/d018d8205300b434728129e199ae048cefbaa296).

opw-6351141

Forward-Port-Of: odoo/enterprise#125772
Forward-Port-Of: odoo/enterprise#124826

**_Steps to reproduce :_**

-  Install l10n_it_riba.
-  Configure a company with a San Marino (SM) IBAN as the bank account for the
   journal used for Ri.Ba.
-  Create a customer payment and add it to a Batch Payment using the Ri.Ba.
   payment method.
-  Validate the Batch Payment.

**_Observed behavior :_**

 The validation fails with the error:
   `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments`

**_Cause :_** 

 The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs.

**_Fix :_**

-  Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files.

-  While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format.

**_opw_** - 6303820

Forward-Port-Of: odoo/enterprise#125694
Forward-Port-Of: odoo/enterprise#121439

# How to reproduce
For an employee with full attendances for april and may:
- Create payslip for the month of April, Compute Sheet & Confirm
- Create a Time off request for that employee ffrom the 1st of April to the 10th of April, Approve & Validate
> Since the April payroll is closed, you need to defer the Time Off
- Report to Next Month
- Create payslip for the month of May
> The deffered time off should be there
- Compute Sheet & Confirm
- Create a Time off request for that employee for the 3rd of May, Approve & Validate
> Again, the May payroll is closed, so you need to defer the Time Off

# The issue
You cannot defer the time off because "There is no work entries linked to this time off to report"

# The cause
When deferring a time off, we call `action_report_to_next_month` that will look for work entries generated during the leave period to defer :
https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/hr_payroll_holidays/models/hr_leave.py#L94-L101

The issue is that, since [this commit], we search for work entries that are not leaves and the first deferring we did transformed the work entries at the start of may into leaves.

[this commit]: https://github.com/odoo/enterprise/commit/13ce65b8ca61f9a825f2876e2727cddfae83f894

opw-6318809

Forward-Port-Of: odoo/enterprise#125791
Forward-Port-Of: odoo/enterprise#123263

Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.

**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.

**Error:**
```
  File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
    code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```

**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.

At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.

**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is 
that it is not working on the versions where we already introduced the feature.)

[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38

[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377

[here]:
https://www.odoo.com/mail/message/1121493378

opw-6373984
opw-6430589
opw-6423812

Forward-Port-Of: odoo/enterprise#123918

**Issue**
Changing the `partner_id` of an outgoing rental transfer could reset its destination location to the partner customer location instead of the rental location.

**Steps to reproduce**
- Enable Rental Transfers from Rental Configuration.
- Create a Sales Order for a rental product.
- Open the related delivery transfer.
- Using Studio, make the Destination Location field visible. -> Current destination location is: Partner/Customer/Rental
- Change the delivery address -> The destination location become: Partner/Customer

**Cause**
Changing the delivery address (i.e: the partner_id) triggers `_compute_location_id`: https://github.com/odoo/odoo/blob/85372b625a80ab50fe2d8a6bce49a890b2bf1665/addons/stock/models/stock_picking.py#L949-L950 
Since commit https://github.com/odoo/odoo/commit/8c90fc1fd336ee872fd67d8d72473e4f6c55b2e0, not only draft picking are recomputed. As a result, `location_dest_id` is set as `picking.partner_id.property_stock_customer` https://github.com/odoo/odoo/blob/85372b625a80ab50fe2d8a6bce49a890b2bf1665/addons/stock/models/stock_picking.py#L959-L961 https://github.com/odoo/odoo/blob/85372b625a80ab50fe2d8a6bce49a890b2bf1665/addons/stock/models/stock_picking.py#L963 
Regardless whether we are in rental setup

opw-6237495

Forward-Port-Of: odoo/enterprise#123564