To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).

1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra>  (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact> 
        *Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999

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

1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate". 
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
    * Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate". 

3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes. 
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.

Task latam side: 1330
Task Adhoc side: 52999

Description of the issue/feature this PR addresses:
When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. 

<img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" />

Each reconnect attempt causes a log entry: 
```
2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 
2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Lead/Opportunity, Modern Open Space (crm.lead: 25)

Blame the following rules:
- Personal Leads

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. 

```



Current behavior before PR:
Reconnect loop.

Desired behavior after PR is merged:
Do not add channels without sufficient rights.


Related to: https://www.odoo.com/de_DE/my/tasks/5026412

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

## Description of the issue

The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount

## Steps to reproduce

1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 
2. Add a line with quantity 1. price 0
3. Add a second line with quantity 1, price 500 and discount 100% 

## Before this PR

1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery.
4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all 

## After this PR

Both lines are informed to DGI using the invoice indicator 5 (Free Delivery)
You can check this on to generate CFE XML in demo mode (not need to connect to UCFE)
If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file.


References
[Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691)
LATAM 1350 / ADHOC task 53445

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

Forward-Port-Of: odoo/odoo#224298

Issue Before This Commit:
=======================
When a user updates `qty_producing` in a subcontracting MO, it creates new move lines with empty lots or serials, even though the required quantity is already available in existing `reserved move lines`. This requires the user to manually reassign lots/serials; otherwise, validating the picking raises a UserError of `missing Lot/Serial numbers`.

Steps to Reproduce:
=======================
- Install the `mrp_subcontracting` and `Purchase` module.
- Create product1 with Vendor1. Create product2 with lot tracking and set it `Resupply  Subcontractor on order` in Inventory.
- Create a BOM for product1, with product2 as a component (quantity 10) and subcontractor Vendor1.
- Create and confirm a purchase order for product1 (quantity 10) with Vendor1.
- Go to Resupply → Supply Product2, deliver 100 units of Product2 to Vendor1 using lot-01, then validate the picking.
- Go to the source PO → Receipt → Record Component. Observe that the move line is created with 100 units from lot-01
- Set qty_producing to 2 → the current component line updates to 20 quantity.
- Increase qty_producing by 1 → a new line is created with empty lot, even though the existing line already has 100 quantity of the same lot.

Cause of the issue:
=======================
When `qty_producing` is updated in the subcontracting MO wizard, the `_set_quantity_done_prepare_vals` method recalculates quantities based on the already modified move line quantity instead of referencing its original `reserved quantity`.This causes incorrect comparisons on subsequent updates, leading to the creation of new move lines with empty lots even when sufficient quantity already exists in the existing move line.

With This Commit:
=======================
`_set_quantity_done_prepare_vals` method now uses `ml._origin.quantity or ml.quantity`. ` _origin.quantity` ensures the reserved quantity of existing move lines is counted, while `ml.quantity` handles newly created lines without an origin. This prevents unnecessary move lines with empty lots when sufficient quantity already exists in existing reserved lines, eliminating manual reassignment and avoiding UserError on picking validation.

opw-5116273