Before this **PR**:
When creating a new partner for the first time, the compute method for the invoice EDI format is triggered as expected. However, if a country is set while creating the partner, compute method is not triggered again.

This breaks the intended flow where a default edi_format should be automatically set based on the country (using _get_suggested_invoice_edi_format). Since the compute method doesn’t re-trigger upon changing the country during record creation, the inverse method ends up setting invoice_edi_format_store to 'none'. This prevents subsequent calls to _get_suggested_invoice_edi_format from resolving the appropriate format, requiring users to manually set it — defeating the purpose of automatic localization-based assignment.

After this **PR**:
The dependency for the compute method has been changed from commercial_partner_id.country_code to country_code. This ensures the compute method reacts to changes in the country field during record creation. The logic still utilizes commercial_partner_id internally, so the intended behavior and correctness should be preserved, while ensuring the default format is set appropriately.

A series of recent commits were aiming at allowing to change the partner of some journal entries in batch to allow de-duplicating the database, in the context of the EC Saleslist report[^1]

There are a few residual issues:
1. the lock dates can prevent any change on the lines. However in this specific case, the partner is not really changing and we want to allow it. This issue is solved by adding a context key, using a sentinel to avoid any users bypassing it.
2. if the lines are reconciled, it was also impossible to update the lines. Since all the lines are changing the partner at the same time, there is no need to block changing it as the reconciliation keeps its meaning.
3. After the second commit, we were actually not checking that the VAT was indeed the same on the partner getting a `parent_id` assigned
4. We don't check that the user has a specific accounting group anymore to allow invoicing users to set the main partner. It should not be an issue since the accounting values stay the same (same VAT)

[^1]: https://github.com/odoo/odoo/commit/38d43360781250415c63aba36eadcdce586fcbc0
https://github.com/odoo/odoo/commit/3941972dc7bba3e9a3d4497b312ff7f86a497157

This PR addresses multiple issues related to flexible working hours across several Odoo modules, including attendance, overtime calculation, time off (leave) management, and work entry generation. The primary change modifies the _attendance_intervals_batch method in the `resource` module to create daily attendance blocks for flexible calendars, using the average daily hours and the required weekly hours.

Attendance Intervals for Flexible Hours:

Old Behavior: For flexible employees, a single interval spanned the entire requested period, leading to inaccurate calculations.
New Behavior: For flexible calendars (not fully flexible), daily attendance blocks are created, centered around 12:00 PM, with each block’s duration equal to the average daily hours (hours_per_day). Fully flexible employees (no calendar) retain a single interval covering the full period.

A flexible employee’s attendance was one continuous block over the entire period.

+---------------------------+
|        Attendance         |
|   (e.g., Mon to Fri)     |
+---------------------------+

New Behavior (Daily Blocks):

For a flexible calendar with 8 hours/day, attendance is split into daily blocks centered at 12:00 PM (e.g., 8:00 AM - 4:00 PM).

+-----+ +-----+ +-----+
|  8h | |  8h | |  8h |
| Mon | | Tue | | Wed |
+-----+ +-----+ +-----+

Overtime Calculation:

Updated hr_attendance.py to skip overtime computation for fully flexible employees (is_fully_flexible). For flexible calendars, overtime is now based on the new daily attendance blocks.

Time Off:

In hr_leave.py, flexible calendars now center leave intervals around 12:00 PM for each day, matching the attendance blocks. For half-day leaves, the duration is halved.
Single-day leaves use specified hours, while multi-day leaves align with the virtual schedule.

Work Entry Generation:

In hr_contract.py, work entries for flexible calendars distinguish between one-day and multi-day leaves. Multi-day leaves align with the daily attendance blocks, while one-day leaves use exact hours.
Updated hr_work_entry.py to skip marking leaves outside the schedule for flexible hours, as their virtual schedule is dynamically generated.

Timesheet:

In hr_holidays.py, timesheet generation for flexible employees uses the new attendance intervals or exact hours for hourly/half-day leaves.


task-4771288

Currently, when you try to settle a SO in POS which has sections/notes before the product line (producted tracked), a traceback will appear and the amount to settle will be set to 0.

Steps to reproduce:
-------------------
* Crete a product tracked by SN
* Create a SO, the first line should be a section line and the second the product newly created
* Open pos session
* Try to settle the SO
> Observation: Traceback, when closing the traceback, the line on the
pos order has an amount of 0.

Why the fix:
------------
This commit https://github.com/odoo/odoo/commit/4c0fdfe23c6302929bf05f2223f41b7ac5587e66 didn't take into account that `read_converted` could potentially return less data than the number of sale order lines (sections and notes).

Thus using a loop invariant to track the converted_line related to the SO line does not make sense. In our example above, `i=1` when reaching the product line but `converted_lines` only had one element. In this case, `sale_order.order_line[1]` is related to `converted_lines[0]`.

opw-4800339

**Current behavior:**
Using the return & exchange functionality when the product to exchange is a kit's component will not correctly update the SOL `qty_delivered` field upon validation of the exchange (out) picking.

**Expected behavior:**
accurate `qty_delivered`

**Steps to reproduce:**
1. Create a product w/ kit bom like:
* 2 units componentA
* 1 units componentB

2. Sell 1 unit of the kit product, validate delivery

3. Create a return for the 1 unit of componentB and select the exchange option on the wizard

4. Validate the return, then validate the exchange

5. Look at the sale order line `qty_delivered` -> it's 0

**Cause of the issue:**
The exchange picking move doesn't get a `bom_line_id` and thus is not properly aggregated in the computation of qty_delivered when incoming and outgoing quantities are being calculated (wherein these quantities must offset, but can't in this situation).

**Fix:**
When the procurement occurs to create the exchanging move, find the `bom_line_id` by looking at the original sale line's moves' bom's bom lines.

opw-4676609

### Description of the issue/feature this PR addresses:

Given
https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90

Then `test_import_product_demo_xls` incorrectly pairs .xls file extension with mime type `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`

### Current behavior before PR:

Tests in the product module fail when openpyxl is installed.

```
2025-05-19 15:08:32,243 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.supplierinfo]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
 
2025-05-19 15:08:32,268 1 WARNING odoo odoo.addons.base_import.models.base_import: Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'). 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 429, in _read_file
    return getattr(self, '_read_' + file_extension)(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 509, in _read_xlsx
    book = load_workbook(io.BytesIO(self.file or b''), data_only=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 344, in load_workbook
    reader = ExcelReader(filename, read_only, keep_vba,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 123, in __init__
    self.archive = _validate_archive(fn)
                   ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 95, in _validate_archive
    archive = ZipFile(filename, 'r')
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1349, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1416, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
2025-05-19 15:08:32,269 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.template]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
```

### Desired behavior after PR is merged:

Tests pass even when openpyxl is installed.

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

…compute

**PROBLEM**
When creating a new operation type, changing the type to Delivery throws a warning to create a warehouse first despite there already being one.

**STEPS TO REPRODUCE**
1. On a fresh database, install stock with drop shipping and storage locations enabled.
2. Create a new operation type and set the type to Delivery.
3. You will receive the following warning, despite an existing warehouse:

```
Please create a warehouse for company <company>
```

**CAUSE**
https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock/models/stock_picking.py#L308-L316

https://github.com/odoo/odoo/blob/138983cc81cd1565c1582a1523efa8c0c4dcc434/addons/stock_dropshipping/models/stock.py#L70-L74

When the form is first loaded, the type is Receipt and the source location is consequently Vendors. After changing the type to Delivery, the source location is recomputed.

Observe the above code snippets. Before the source location is done being computed, the warehouse is accessed and computed. When computing the warehouse (in the midst of the source location compute), the `default_location_src_id` is still Vendors and `default_location_dest_id` is Customers, thus `warehouse_id` is set to False.

**FIX**
In the conditional that checks if the picking type is drop shipping, check the `code` instead. The value in `code` is up-to-date at the conditional, unlike `default_location_src_id`.

opw-4603495

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

If one uploads a vendor bill from the list view using the "Upload" button, a banner is then shown on the form view of the created move to reload the data that were extracted via IAP.

However, this banner is not shown if one creates an empty move, then uploads via the attachments, then the banner is never shown.

This is because when we arrive in the `onWillStart` of the `StatusHeader`, we subscribe to a channel using the `extract_document_uuid` which does not exist upon creating a new empty move. Then, when we upload our document, the move record is saved, and is sent to the backend. At this point, the move exists, and a `extract_document_uuid` is set. Then we get the OCR results (in `_check_ocr_status`) and we have a new status, we send this status on the bus but on a channel named `f"extract.mixin.status#{self.extract_document_uuid}"` where the `extract_document_uuid` is set. However, in the JS part, it was empty because it was created in the `onWillStart`.

To resolve this, we create a new channel to detect newly created documents. We send the new `extract_document_uuid` in this channel from the backend to the frontend. The JS can now subscribe to the correct channel using an existing `extract_document_uuid`.

Now, correctly the JS receives the updates of the Python via the bus, and can update the view accordingly.

opw-4566944

In version 18.0, a traceback occurs when editing the 'Appointment:
Attendee Invitation' email template and then signing up for an
appointment.

**Steps to reproduce:**
1. Go to **Appointments**.
2. Click the **"Action"** gear icon next to an appointment, then select **Edit**.
3. Navigate to the **Options** tab.
4. Hover over the **Booking Email** template and click the **arrow icon** to open
    it.
6. In the Content tab, add some text near "Hello", then click **Save**.
7. Return to the **Appointment form**
8. Click the "**Go to Website**" smart button at the top
9. Select a date and time.
10. Confirm the appointment.

This raises a traceback

**In saas-18.3**, editing the `Appointment: Attendee Invitation` email
template throws an error when saving, making the template uneditable.


**Issue:**

The issue originates from this [commit](https://github.com/odoo/enterprise/commit/8b9a1a4462453bf64e7bc1307ededd0d127a27fa), which introduced a
`<div>` inside a `<p>` — a structure that violates the HTML specification.
Editing anything near the word 'Hello' in the template causes the
`<p>` tag to close prematurely during rendering. This pushes the `<div>`
outside of the `<p>`, breaking the directive chain and resulting in
the following error:
     

> SyntaxError: t-elif directive must be preceded by t-if or t-elif directive

    
Previously, the `<div>` was also pushed outside the `<p>`, but only after
evaluating all `t-if, t-elif, and t-else` conditions. Hence, it worked
correctly without editing the template.


**Solution:**

Placed the `<span>` as a child of the `<p>` tag to resolve the issue.
    
This fix also resolves the issue of being unable to edit the template
"Appointment: Attendee Invitation" in the UI **on saas-18.3**.

[Task-4624645](https://www.odoo.com/odoo/project.task/project.task/4624645)

When Acerta Affiliation Number is unset and user tries to generate export file,
A traceback will appear.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll_acerta`` module and switch to belgian company
- Create an employee A > Create a contract(Status: Running) for that employee A >
  Details > Set Acerta code > save
- Go to Payroll > Configuration > Settings > Unset Acerta Affiliation Number
- Go to Payroll > Reporting > Export Work Entries to Acerta > New > Populate > Click on Generate Export File button

Traceback:
```
File "/home/odoo/src/enterprise/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py", line 45, in _generate_line
    return 'KLX1' + self.company_id.acerta_code + contract.acerta_code.zfill(20) \
TypeError: can only concatenate str (not "bool") to str
```

https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/l10n_be_hr_payroll_acerta/models/hr_payroll_export_acerta.py#L45
When ``self.company_id.acerta_code`` is not set,
It will lead to the above traceback.

sentry-6620429585