### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/d5eb3a626 [REL] 18.4.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c25b8c6cb [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426)
https://github.com/odoo/o-spreadsheet/commit/1c099dc42 [FIX] clipboard: don't paste both image and text content [Task: 4876682](https://www.odoo.com/odoo/2328/tasks/4876682)
https://github.com/odoo/o-spreadsheet/commit/a593cb80a [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731)
https://github.com/odoo/o-spreadsheet/commit/a74b221a4 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

### Steps to reproduce:
	- Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours.
	- Create a public holiday with generic time off work entry type.
	- Create one or multiple attendances for marc demo on the public holiday.
	- Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h.

### Cause:
This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day

### Fix:
We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day

opw-4887933

Forward-Port-Of: odoo/odoo#222646
Forward-Port-Of: odoo/odoo#218823

Steps:
-Install the hr_holidays_contract module
- Create two contracts for the same employee: 
- Contract A (Part-time) starting from 01/01/2025 and set to Running 
- Contract B (Full-time) also starting from 01/01/2025 and set to New 
- open holiday dashboard for that employee

Description of the issue/feature this PR addresses: 
The Time Off dashboard incorrectly considers the full-time contract instead of the part-time one, even though the part-time contract is in the running state.

Cause:
The contract selection logic did not correctly prioritize the running contract when multiple contracts existed for the same period.

Fix:
This PR updates the logic to ensure that:
   - If a contract is in the running state at a given time, it is used to determine the working schedule and time off calculations.
   - If no contract is running during that time and multiple contracts exist, the contract with the latest creation_id will be considered.

task-4724155

Forward-Port-Of: odoo/odoo#212959

Currently, there is inconsistent behavior in price calculation 
when a user places a self order for a product containing attributes.

**Pre-requisites:**
- POS module installed and configured.
- Variant enabled in settings.
- Self-ordering is enabled in the POS configuration.
- Two product attributes created in the settings/attributes:
   - One of type radio with variant creation set to Instantly.
   - Another of type multi-checkbox with variant creation set to Never.
- Create attribute lines for both attributes with default extra prices.

**Steps to reproduce:**
1) Create a product template linking the above attributes 
2) Ensure the product is available in POS and self ordering 
3) Open a POS session in one browser tab and the self-ordering in another. 
4) Select the product in the self-ordering interface, first choosing
   an option for the radio attribute, then selecting one or more options
   for the multi-checkbox attribute.

**Error:**

You will see the difference between the expected price and the displayed price

**Example for Clarity:**

Consider a product called Pizza with 2 attributes. The base price of the pizza is $10.

| Attribute                           | Option           | Extra Price           |
| ----------------------------------- | ---------------- | --------------------- |
| **Size** (radio)                    | Small (S)        | \$0 (no extra charge) |
|                                     | Medium (M)       | \$5                   |
|                                     | Large (L)        | \$10                  |
| **Extra Toppings** (multi-checkbox) | Veggies          | \$3                   |
|                                     | Extra Cheese     | \$3                   |
|                                     | Veggies & Cheese | \$5                   |

If the user selects a medium-sized pizza with veggie toppings, 
The expected price is: 
```
$10 (base) + $5 (Medium size) + $3 (Veggies) = $18. However, the price shown is only $13.
```

**Root Cause:**
For attributes of the multi-checkbox type, variant creation is set to Never by default. 
This means no product variants are generated for such attributes.

Because of this, when calculating the price, the extra price associated with the 
multi-checkbox attribute is added directly to the base price of the product template
instead of the price of the selected variant. 

This happens because the variant information is not properly passed to the price calculation method:
https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/pos_self_order/static/src/app/services/card_utils.js#L187-L196 https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/point_of_sale/static/src/app/models/product_template.js#L185-L189

As a result, the extra price for the multi-checkbox attribute is incorrectly added 
to the product template’s base price rather than the variant’s price.

**Solution:**

Pass the product_variant derived from the selected product.product to the price calculation method. 
This ensures that if a variant exists based on the user’s selection, 
the extra price is added to the variant’s price rather than the base product template price, 
resulting in the correct total price.

opw-4963537

Forward-Port-Of: odoo/odoo#221375

[FIX] account_accountant: fix multi_currency payment_widget
To reproduce:
- Make a statement line for partner_a for 200 $
- Make an invoice for same partner for 100 $
- Reconcile it with the statement line
- Duplicate the invoice and post it
=> First issue, you don't see the 100$ left on the statement line
It's still reconciliable

To fix that, we only remove fully reconciled statement lines.

Second issue:
- Have a bank journal in EUR  with a rate of 2
- Make a statement line for 400€ in this journal
- Create an invoice for the same partner of 100$
=> The widget proposes a statement line of 400$ instead of a 200$
equivalent (with the rate conversion)

The issue is that we convert with a foreign_currency_id that is not
present in that case.

To fix both, we change the way we compute the amount to always use
the residual converted from the right currency

[FIX] account_accountant: partial on statement line for invoice widget
To reproduce:
- Make a statement line for partner_a for 200 $
- Make 2 invoice for same partner for 100 $
- Reconcile them with the statement line (via the widget)
- Unreconcile first invoice via the payment widget
=> The second invoice is also unreconciled

To solve:
Only unreconcile the lines that are part of the partial that we want to unlink

Forward-Port-Of: odoo/enterprise#92005

### Steps to reproduce:
	- Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours.
	- Create a public holiday with generic time off work entry type.
	- Create one or multiple attendances for marc demo on the public holiday.
	- Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h.

### Cause:
This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day

### Fix:
We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day

opw-4887933

Forward-Port-Of: odoo/enterprise#92193
Forward-Port-Of: odoo/enterprise#90163

**Issue:**
When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers

**Cause:**
The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed

**Fix:**
We added a `partner_latitude` and `partner_longitude` reset when changing address in write
We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation
The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list
In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude`
We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields`

**Limitations:**
One issue remains during import: the parent-child address synchronization is disabled on contact creation
This means children may be created with addresses different from the parent’s and have mismatch positions on Map
This can be corrected by updating or re-importing the parent to trigger synchronization

**Steps to reproduce:**
With Form:
- Add a parent contact company with a valid address
- Add a child contact related to company, with a valid address
- Open the Map View, both address must appear on Map
- Modify the parent address to remove street (make it invalid)
- Check that the child address match the parent one
- Check the Map View, before the fix the child should remain with a wrong position

With import:
Create an import file (an example is in on the ticket)
- Add a sheet for the Parent contact with an valid address
- Add a sheet to add the Child contact with a parent_Id, with a valid address
- Add a sheet to break the address on the parent, removing the street
- Open the contacts app
- Import the valid Parent and Child sheets (you need to select Related Company / External ID)
- Add a filter to get your created contacts
- Check the Map View (You should see both parent and child)
- Import the Break parent sheet
- Check that the child address match the parent one in the Form
- Check the Map View, before the fix the child should remain with a wrong position

A file can be found on the ticket with pre-made data

**Technical notes:**
The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases
Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently

On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo
Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used

We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably

An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication

opw-4842910

Forward-Port-Of: odoo/enterprise#92658
Forward-Port-Of: odoo/enterprise#90392

Currently, an IndexError traceback occurs when changing the order state 
in the preparation display if it contains only one stage.

**Steps to reproduce this issue:**
1) Install POS, Kitchen Display
2) Create a preparation display by removing all but
   one stage in the prep settings.
3) Open a restaurant session and create an order.
4) Open the preparation display and mark the created order as DONE. 5) A traceback will occur

**Error:**
```
IndexError: tuple index out of range
```

**Cause:**

When the Done button is clicked in a preparation display with only one stage, 
an ORM call to `change_state_status` is triggered. This then calls 
`_record_status_change_prep_time`, followed by `is_stage_position`.
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_state.py#L31-L40
https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_stage.py#L21-L22
In `is_stage_position`, static positions [0, -1, -2] are used to access items in the `stage_ids`. 
If only one stage exists, accessing indices -2 results in an IndexError.

**Solution:**

Before accessing a stage by position, check that the length of stage_ids 
is greater than or equal to the absolute value of the position.
This prevents attempts to access out-of-range indices.

opw-4985306

Forward-Port-Of: odoo/enterprise#91918