**Steps to reproduce:**
* Install **Accounting**, **Documents**, and **Peppol** modules.
* Enable `Workspace` in Accounting settings to automatically sync documents.
* Create and confirm a Customer Invoice.
* Click 'Send & Print', ensure the Peppol checkbox is ticked, and send.

**Observed behavior:**
* The PDF preview on the invoice disappears.
* `invoice_pdf_report_id` on the move is empty.
* A `KeyError: 'proforma_pdf_attachment'` may occur in certain fallback conditions because the expected PDF vanished.

**Cause:**
* When sending an invoice via Peppol, `account_peppol` calls `message_post` to log the API transmission in the chatter.
* This chatter message creates new attachments. `documents.document` instantly creates corresponding Documents for these attachments.
* Immediately after, Peppol intentionally modifies these attachments, changing their `res_model` to `mail.message`.
* The associated Document's `res_model` is a computed field that mirrors its attachment, so the Document's `res_model` also dynamically updates to `mail.message`.
* Finally, the core send flow finishes generating the actual invoice PDF (`res_model='account.move'`) and assigns it as the main attachment.
* The `documents_account` override intercepts this assignment and links the new PDF to the existing Document.
* Inside `documents.document.write()`, a versioning logic detects that a new attachment (`account.move`) is being linked to a Document (`mail.message`). To enforce consistency, it forcefully overwrites the new PDF attachment's `res_model` to `mail.message`.
* This breaks the `res_model` of the PDF, preventing `_compute_linked_attachment_id` from finding it, thereby nullifying `invoice_pdf_report_id`.

**Fix:**
* In `documents_account`, guard the document reuse path with a check that the found document still belongs to `account.move`.
* If the document has drifted to any other `res_model` (e.g. `mail.message` after a Peppol chatter message), skip reuse entirely and let `_update_or_create_document` create a fresh document if the document is not exist or update exesting, correctly-linked document for the invoice PDF instead.
* This avoids fighting the versioning logic after the fact and addresses the root cause: a drifted document should never be reused as the invoice PDF document.

opw-5936331

### 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

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

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

A customer that belongs to a pricelist that is based on another pricelist sees the price set on the product as the base price used to display the discount

Steps to reproduce:
1. Install eCommerce
2. Go to Settings > Website > Shop - Products and enable "Advanced price rules"
3. Go to Website > eCommerce > Products, create a new product called "test" with price $1000 and publish it to the website
4. Go to Website > eCommerce > Pricelists and create a new pricelist called "pricelist1" with a price rule with a fixed price of $500
5. Create another pricelist called "pricelist2" with Discount Policy "Show public price & discount to the customer", Selectable enabled and with a price rule with Computation "Formula", Based on "Other Pricelist", Other Pricelist "pricelist1" and Discount "50.00"
6. Open the eCommerce, select "pricelist2" and open the product page of product "test"
7. The base price of the product is $1000, it should show $500

Issue:
We always use the product price as the base price to compute the discount on a product page

Solution:
When a user belongs to a pricelist that is based on another pricelist, use the price set on the base pricelist as base price

opw-6122009