*= pos_restaurant_preparation_display, pos_enterprise

Steps to Reproduce
==================
- Create an order with Product A ×2 and Product B ×2
- Send the order to the preparation display
- Split the order and pay for one unit of each product
- On the remaining order, add another product
- Send the order to the preparation display 
- The preparation display incorrectly cancels previously sent products

Fix
===
- Prevent cancellation of existing preparation order lines
- Avoid duplication of preparation lines when split orders are sent to the kitchen

Covered Scenario
================
1. Send an order with Coca-Cola ×2, Minute Maid ×2, Water ×1 to the kitchen.
2. Split 1 qty of each product into a new order, increase split quantities, and send it.
3. Increase quantities on the original order and send it again.

Expected Behavior
=================
- Initial preparation order remains unchanged (no line cancellations)
- Split order creates a new preparation card with only unsend split quantities
- Original order creates a new preparation card with only newly added quantities
- No preparation line incorrectly aggregates quantities across orders

Task-5355899

Related Comm. PR: https://github.com/odoo/odoo/pull/244195

**Problem:**
When an attendance has overtimes across multiple days, those overtimes can
overlap when calculating their intervals.

There will always be rounding errors since only the durations are saved to 3
decimals, but this is normally fine since the durations are accumulated when
calculating the next interval.

However, on a day boundary in the employee timezone, the end of the interval is
forced to the end of day, which incidentally removes the rounding error. This
causes the overlap when calculating the next interval since its start will be
based on the rounded duration, not the actual end of day.

**Steps to Reproduce:**
- Configure an overtime rule where >8 hours is considered overtime, and a
second rule applies to non-working days
- Set Overtime Rule on employee "Anita Oliver"
- Set employee work entry source to "Attendances"
- Create an attendance that exceeds 8 hours in a day and crosses into a
non-working day and creates enough of a rounding error (see unit test)

-> Traceback error:
`ValueError: Expected singleton: hr.attendance.overtime.line(1, 2)`

**Solution:**
Add an additional check to ensure the overtime cannot start on the previous
day.

opw-6067969

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#114759
Forward-Port-Of: odoo/enterprise#112041

Step to reproduce:
- install "pos_settle_due"
- create a pos order, set order price = 0, select a customer
- go to payment page, select "customer account" as payment method
- here you can set any amount to pay, ex 100$
- fulfill the  order.

Observation:
- the order amount is 0, if we pay 100$ using customer account, it is considered as change (which means we returned it to customer)
- As per PO, this flow doesn't make sense

Issue:
- customer has 100$ due for this order, but he won't be able to settle this as fetch order to settle with amount != 0, after commit [1] 
- [1] https://github.com/odoo/enterprise/commit/12af23d5382e972facfaa999e4c5ab30c97e8d1f

https://github.com/odoo/enterprise/blob/951e5f42884c898bc14d9c32ae6a8f08c31ff06d/pos_settle_due/static/src/app/screens/partner_list/partner_line/partner_line.js#L35

Fix:
- we hide payment method of type "pay_later" in case of 0 price order

opw-6123699

Forward-Port-Of: odoo/enterprise#118093
Forward-Port-Of: odoo/enterprise#116556

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#117577
Forward-Port-Of: odoo/enterprise#113227

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293