### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

**Steps to produce:**
- Install `sale_management` without demo data.
- In settings > Under Taxes > Set `Tax Prices` as `Tax Included`.
- Create a product with a sales price of 10.
- Create a quotation with this product.
- Confirm the line amount shows 10 (tax included).
- Click on preview.

**Observation:**
- In the preview, the product line amount is shown as tax excluded.

**Root cause:**
- At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`.
- This logic is not applied in the portal preview and PDF report.

**Solution:**
- Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`.

[1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663

Before:
---
<img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" />

After:
---
<img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" />

opw-6089473
---

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

Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#249793

When creating a refund of a pos order linked to a SO the delivery is not created.

Steps to reproduce:
-------------------
* Create a product tracked by quantity
* Create a SO with the product and confirm it
* Open a session and settle the SO
* Go backend
* Refund the order & pay it
* See the delivery created
> Obsrevation: it has no move lines.
The pos order that settled the SO has move lines.

Why the fix:
------------
Version 18.0 is the only version that filters the lines when creating moves.
We notice the following commit: https://github.com/odoo/odoo/commit/e6678442ffe90e35a00e8b752e607d839920bee6

In the next version we're back with the original line as the logic was moved to a newly created module:
https://github.com/odoo/odoo/commit/42bcc2b49d46695c4afc518bb0f89254e24c12dc

Having a consistent code across version would solve this issue without triggering any issue on the test but the test was passing without the original fix.

So instead we'll add a specific fix here as well to keep the original logic.

A different behavior can be observed if we're refunding from the front or backend. When refunding from the front the refund order is not linked to the original SO thus `lines` don't get filtered. The difference with the backend comes from the fact that the refund is linked to the SO and thus the lines are filtered and we end up using no pos lines for creating move lines.

As this behavior is consistent across versions we don't want to modify it for only 1 version. Plus if we modify the front behavior we still have the issue anyway.

So not if the order has an origin SO id but is a refund of that original SO we don't filter it out for moves.

opw-5963829

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

This PR replaces the legacy HTTP utility with a robust, production-ready HttpService class. The goal is to improve system reliability under high load and unstable network conditions.

Key Features:

Resilience: Implements Exponential Backoff + Jitter for retries. Respects Retry-After headers.

Strict Idempotency: Prevents dangerous retries on non-idempotent methods (POST/PATCH) to avoid data duplication.

Observability: Integrated Correlation IDs and detailed error objects (latency, attempt count) for better debugging.

Safety: Recursive parameter serialization with circular reference protection.

Resource Management: Abort-aware delays to prevent memory leaks during component unmounts.

Extensibility: Interceptor pipeline for request/response manipulation (e.g., Auth injection).

This refactor addresses previous limitations regarding error swallowing and lack of type safety in response parsing.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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