Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point.

## Steps to replicate:
- Install Quality, Purchase, IoT
- Quality > Quality Control > Control points
- Create a new Control point with
   - Type: Take A Picture
   - Operations: My Company: Receipts
- Create and confirm a purchase order for a test product
- Receipts > Quality Checks > Take A picture

## Observed behavior:
TypeError: Cannot read properties of undefined (reading '0')

## Root cause:
This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined.

These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined.
[1]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 
[2]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 
[3]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 
[4]:
https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32

## Solution:
Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4]

opw-6010095

Forward-Port-Of: odoo/enterprise#110615

**Behavior:**
Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number.

The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner.

**Steps to reproduce:**
- Log to a Belgian company
- Create a contact that is a person
- Add the 281.50 tag to them
- Create a credit note for any positive amount for that person and set the date to the previous year
- Make sure the account used in the credit note has any 281.50 x tag assigned
- Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note
- When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact

opw-5930339

Forward-Port-Of: odoo/enterprise#111310

Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx).

- Fill the text field with a value (e.g., "John Doe") and save the PDF.
- (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field).
- Upload this PDF to the Sign app.

**Current behavior:**
The text field's string value is ignored and replaced with a checkmark (✓).

**Expected behavior:**
The text field should correctly render the string value that the user entered.

**Cause of the issue:**
In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713).
However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons.

**Solution:**
This PR fixes the issue safely for stable versions across two commits:

[REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit.

[FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. 

Task: 6018260

Forward-Port-Of: odoo/enterprise#110292

The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.

This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.

In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.

For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.

Task: 6043957

Forward-Port-Of: odoo/enterprise#111140

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#110324
Forward-Port-Of: odoo/enterprise#105115

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Forward-Port-Of: odoo/enterprise#110874
Forward-Port-Of: odoo/enterprise#99784

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353

Forward-Port-Of: odoo/enterprise#110696
Forward-Port-Of: odoo/enterprise#108912

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

Forward-Port-Of: odoo/odoo#248142

BUG 1:
-----------

**Steps to reproduce:**
1. Install Time Off and Timesheets with demo data.
2. Create a time off for an employee and approve it.
3. Check the related timesheet entry for that employee.
4. Delete the approved time off.
5. Check the timesheet entries again.

**Issue:**
The timesheet entry remains even after the related time off record is deleted.

**Cause:**
Following commit 944c11e, admins can delete [approved time off ](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L956-L959)records. 
The relationship between the leave and the analytic line (timesheet) did not
have a deletion policy defined. When the leave was [unlinked](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L961-L964), the analytic
line remained without its parent reference.

**Solution:**
Explicitly remove related timesheet entries before deleting the leave record.


BUG 2:
-----------


Currently, refusing/cancelling a time off record can lead to orphan 
timesheets/duplicated hours (16h instead of 8h) if a public holiday 
exists on the same day.

**Root cause:**
The issue comes from this write method:
https://github.com/odoo/odoo/blob/79ff1d63caed2c1058aa338947b9af90ebb6cd20/addons/project_timesheet_holidays/models/hr_leave.py#L128-L130
The method first unlinks the holiday_id from the timesheets
and then attempts to delete them.

However, once the holiday_id is set to False, the timesheets are
no longer linked to the leave. As a result, leave.timesheet_ids becomes empty,
and nothing is deleted. This leads to orphan timesheet records.

When the leave is later refused or cancelled, a new public holiday timesheet
entry is generated (if applicable), resulting in duplicated timesheet entries
for the same day.

**Steps to reproduce:**
1. Create a time off for one day and validate it (8h timesheet generated).
2. Create a public holiday for the same day.
3. Observe that leave duration becomes 0, but the timesheet remains.
4. Refuse or cancel the time off.
5. Observe two timesheet entries for the same day (16h total).

opw-5384428





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

Forward-Port-Of: odoo/odoo#247155

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

   * Enable **Cash Rounding**
   * Set a **Rounding Method**
   * Enable **Only on cash methods**
3. Create a product:

   * Sale Price: 260
   * Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
   *(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

Forward-Port-Of: odoo/odoo#254844

Currently when the user creates an invoice the delivery date is set incorrectly.

<h2>Steps to produce:</h2>

* Set system timezone to Asia/Kolkata and time to 5:00
* Install Sales, Inventory
* Create and confirm a sale order
* Go to Delivery and Validate the delivery
* Go back to the Sale order and create an invoice.


<h2>Observed Behavior:</h2>
The delivery date on the customer invoice is set to one day before the current date, even though the effective date for the delivery correctly reflects the system date and time.

<h2>Root cause:</h2>

This issue occurs because, when a delivery is validated, the `date_done` field is set using the current time in UTC at [1], because odoo operates in UTC by default. This value is then used to compute the effective date on the
sales order at [2], which in turn is used to determine the delivery date on the invoice at [3] and [4].

Users see the effective date on the delivery in their own timezone because `Datetime` fields are converted from UTC to the user’s timezone on the client side as stated in [5]. However problem arises from a type mismatch. The delivery date field is of type `Date`, while the effective date is a `Datetime`. As a result, when the value is assigned at [3] or at [4], only the date portion is passed.

Because a Date field does not carry any timezone information, no timezone conversion occurs, leading to the observed discrepancy.

[1]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/stock/models/stock_picking.py#L1274
[2]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L87-L88
[3]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/account_move.py#L122
[4]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L301
[5]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/odoo/orm/fields_temporal.py#L214-L217

## **Solution:**
Using the `context_timestamp` function makes it possible to work with the `Datetime` in the client’s timezone, which can then be used to correctly assign the delivery date on the invoice.


opw-5391189

Forward-Port-Of: odoo/odoo#247122