Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

Forward-Port-Of: odoo/odoo#267479

Currently, an error occurs when the user clicks on the translate button.

**Steps to Reproduce:**

 - Install the `CRM` module.
 - Go to `settings` and in `Languages` add 1 more language.
 - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`.
 - Click `New` and, in the `Name` field click the `translate button` on the right.

**Behavior in 18.0**

When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, 
the translation dialog shows the translated value on the second click.

**Behavior in saas-19.1**

`AssertionError: Invalid falsy real id`

Error:
After this [recent commit], when the user clicks on the translate button, if the record has a 
root record, the root record is saved before opening the translation dialog. However, in the 
case of an editable DynamicList view, the record does not have a root record so saving 
the record returns a promise instead of the resolved value [1].
Because of this promise, the condition fails [2], and the translation dialog is opened with a 
falsy ID since the record is not yet saved [3]. 
In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f).

This commit ensures that await is used so the resolved value is returned after the record is 
saved before opening the translation dialog.

[recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be

[1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23

[2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26

[3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41

sentry-7384270487

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

**Problem:**
If the Rental Transfers setting is enabled, a traceback occurs
when validating a delivery order containing a kit that will be exploded
during the validation.

**Cause:**
When validating a delivery (`button_validate`), `_action_done` is run
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/stock/models/stock_picking.py#L1441

The `sale_stock_renting` and `sale_mrp_renting` overrides of this
method both execute after other overrides
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_stock_renting/models/stock_move.py#L63
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_mrp_renting/models/stock_move.py#L11

The `mrp` override of `_action_done` calls `action_explode`, which can
unlink records contained in `self` in the calls of `_action_done`
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/mrp/models/stock_move.py#L543-L544
https://github.com/odoo/odoo/blob/af6e45146e3ac3d43f8cfb312e3392ed0c747855/addons/mrp/models/stock_move.py#L582

The `sale_stock_renting` and `sale_mrp_renting` overrides of
`_action_done` then resolve after this, and attempt to iterate on `self`
or values within `self`, causing a Missing Record Error to occur when
attempting to read properties of a deleted record within `self`
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_stock_renting/models/stock_move.py#L65
https://github.com/odoo/enterprise/blob/37ccd8bffea96fcd5a0f2f7fae658951824f7f9a/sale_mrp_renting/models/stock_move.py#L13

**Purpose:**
Modify the _action_done method's overrides to ensure that
records that no longer exist are not iterated on. This allows the
validation to resolve correctly and explode the kit, requiring a second
validation for the individual components of the kit.

**Steps to Reproduce in Runbot:**

1. Enable the Rental Transfers setting.
2. Create a Product with Tracked Inventory, then add it to a Quotation
   and confirm it.
3. Add a Kit type Bill of Materials to the Product.
4. Attempt to validate the Delivery made when confirming the Quotation.

Similar Fix: https://github.com/odoo/odoo/pull/258403

opw-6144693

**Problem:**
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. and the schedule is flexible and is set to 40h per week. When we open the Attendances app, the expected hours for this employee show 48h.

**Steps to reproduce:**
- Create an employee with a flexible 40h/week schedule and a contract.
- Set employee timezone to Asia/Pyongyang and the working schedule timezone to Europe/Brussels.
- Open Attendances > Overview > Dashboard in week view.
- denominator shows 48h or any other number than 40h.

**Cause:**
In flexible calendars, weekly expected hours are computed by iterating within `[start_dt, end_dt]`. and That logic truncated bounds to `.date()`, assuming `end_dt - 1 second` would always move to the previous day.

That assumption breaks when employee timezone differs from schedule timezone and the employee timezone is far from UTC (like Asia/Pyongyang). so, `end_datetime` is no longer near midnight in local time, so subtracting one second keeps the same date. The loop then includes one extra day and allocates an extra 8h, showing 48h expected instead of 40h in Attendances.

**Fix:**
This change keeps full datetime bounds (instead of truncating to date), so comparisons preserve timezone offset and time of day precision. This prevents the extra day and restores correct weekly expected hours. The original code before this 332cb43 was like this:
```python
                    start_date = start_datetime.date()
                    end_datetime_adjusted = end_datetime - relativedelta(seconds=1)
                    end_date = end_datetime_adjusted.date()
```
this will not work as `.date()` will do the same problem of the extra day allocation.

Affected from 18.0 -> 18.4
Fixed in 19.0+ by this
Backport of https://github.com/odoo/odoo/pull/252847

opw-6171432

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

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

**Step to reproduce :**

1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.

**Issue :**

Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.

**Reason :**

The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix introduced in:
https://github.com/odoo/odoo/pull/248215

However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
    
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
    
**Solution:**
    
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.

opw-6210411

**Steps to reproduce:**
* Install the **l10n_es_edi_sii** module.
* Create a **Portuguese customer**.
* Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping.
* Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**).
* Go to **Accounting → Reporting → Tax Report → OSS Sales**.
* Export the **VAT Record Books (XLSX)** file and open it.

**Observed behavior:**
* The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17".
* The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17".

**Cause:**
* In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01".
* This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table.

**Fix:**
* Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`.
* For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise.
* For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise.

opw-6197141,6216485

**Problem:**
If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted.

**Steps to Reproduce:**
- Ensure project_purchase is not installed
- Create a new project with "Billable" enabled
- Go to the project settings and create an analytic account
- Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5
- Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill

-> Go to the project updates and see that the vendor bill costs is wrong (15)

**Solution:**
A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly.

opw-6172523

Forward-Port-Of: odoo/odoo#265378