Currently, An Error occurs on removing the **Date To** or **Date From** value from a payslip's period.

**Steps to Reproduce**
1) Install **l10n_id_hr_payroll module**.
2) Create a new **Pay-Slip**.
3) Remove **Date** from **Period**

**Error:**
`AttributeError: 'bool' object has no attribute 'month'`

**Root Cause:**
The `_compute_l10n_id_include_pkp_ptkp` method at [1] assumes that `date_to` and `contract_id.date_end` are always set and valid. If either of them is missing (False), accessing `.month` or `.year` causes an error.

[1] - https://github.com/odoo/enterprise/blob/34aa0ffb82c1bd7c90b4cb161ea515f2cad8e65f/l10n_id_hr_payroll/models/hr_payslip.py#L87

**Solution:**
This commit prevents the computation from failing when `slip.date_to` and `slip.contract_id.date_end` fields are unset by adding a conditional check to ensure that both fields are valid date objects before accessing their `.month` and `.year` attributes.

sentry-6608982173

Forward-Port-Of: odoo/enterprise#85701

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

**Current behavior:**
COGS dashboard items in a project's profitability report do not open any details when clicked on.

**Expected behavior:**
This should open a detailed view for an invoice linked via the analytic account on the project.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report and click on the `Cost of Goods Sold` dashboard item

**Cause of the issue:**
There is no action set up to return for this section, as it was just added in: 0fbc592

**Fix:**
Add an action to return the account move line records with COGS display type for the invoice record in question (in the request's `res_id`).

opw-4813885

Forward-Port-Of: odoo/odoo#212547

…followers

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

Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only portal users have access.

**Current behavior before PR:**
The 'follower' group in _notify_get_recipients_groups is being explicitly marked with 'has_button_access': True. Therefore followers without portal access are having access to the button.

**Steps to reproduce:**

1. Configure odoo to be able to send out emails.
2. Install sale_management.
3. Create a sale order for a customer and add as follower another partner that has no portal access. This follower needs to have an email you have access to.
4. Send a message to the follower.
5. Test in the received email that the "View Quotation/Order" button is shown and when clicked, the user is redirected to the login page.

**Desired behavior after PR is merged:**
Only followers with portal access will have access to the button.

Note that followers with portal access are directly categorized as 'portal_customer', so that is why it would make sense to simply remove the code where the followers without portal access are given access to the button.





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

Forward-Port-Of: odoo/odoo#210343
Forward-Port-Of: odoo/odoo#208402

When creating an inter-wh transfer, the replenish order was showing the product's supplier in the Received From (partner_id) field and not the correct wh.

Steps to reproduce:
-------------------
* In Inventory, activate Multi-step Routes
* Create a new WH that can be Resupplied From another WH
* On a product, in the Inventory tab, activate the Route 'ABC: Supply Product from XYZ'
* On the forecast of that product, click on Replenish
* Match fields: Warehouse = ABC, Preferred Route = 'ABC: Supply Product from XYZ'
* Confirm
* Open the generated order

> Observation:
> The field Receive From contains the supplier of the product instead of the supplying WH.

Why the fix:
------------
The supplier_id was automatically set with the product's supplier_id. It's not correct for every routes. It's now updated accordingly to the route used and if we need the vendor.

opw-4717654


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

Forward-Port-Of: odoo/odoo#210336

[FIX] website: update sitemap lastmod on website page view changes

Before this commit, since the introduction of the website page model at
commit [1], the lastmod for pages indicated in the sitemap was not
entirely accurate: it only considered *page record* changes, not their
internal *view changes*.

Steps to reproduce:
- Create a new website page and publish it
- Go to /sitemap.xml, see the page is mentioned with correct lastmod
- Wait for one day **
- Update the page URL
- Go to /sitemap.xml, see the lastmod was updated
- Wait for one day **
- Update the page content
- Go to /sitemap.xml
=> The lastmod was unchanged

**: the lastmod does not show the hours. You will need to update the
    write_date manually in your database to test this. Also, when
    visiting the sitemap, you need to first delete the cached version
    in the backend (Debug -> Settings -> Technical -> Attachments).

[1]: https://github.com/odoo/odoo/commit/4ecbacaf59576a22ff45615a5aa5c67244e4fb93

Forward-Port-Of: odoo/odoo#212055
Forward-Port-Of: odoo/odoo#211749

…ivery

**Problem:**
When a product is added to a sale order from the delivery 
the cost is not computed

**Steps to reproduce:**
- Activate the "Margins" Settings
- Open Sales/Products and create a product
- In the product Type field, choose consumable 
and set a postive cost
- Do the same for a second product
- Navigate to Sales/Order and create a new quotation
- Add your first product and Confirm
- Click on the Delivery smart button and then on the 
Detailed Operations smart button
- Click on New, add your second product and set 
a quantity of 1
- Go back to the delivery and validate it
- Go back to the sale order

**Current behavior:**
A line has been added with the product but the Cost is zero 

**Expected behavior:**
The cost should be computed

**Cause of the issue:**

Because of the elif logic here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L17-L22
the cost of products added on delivery with a standard price 
will be computed using _compute_average_price
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
We should instead add the line to "line_ids_to_pass" so 
they're computed with the super method

**Fix:**

Changing the elif logic to make sure that if a product is added in 
delivery and has a non standard cost method it's cost is computed 
here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
but if it's added in delivery and has a standard cost method,
we call the super method for this line

opw-4581531

Forward-Port-Of: odoo/odoo#208176

Steps to Reproduce:
-----------------
1) Create an Accrual
	 - Set carryover_date to other
	 - Set carryover_month to April.
	 - Set carryover_day to Last Day.
2) Add an Accrual Rule to the accrual.
3) Create a Leave Allocation
	 - Set allocation_type to Accrual.
	 - Assign the Employee.
	 - Define the Validity Period (date_from, date_to).

**Issue:**
-------------------
On accrual creation when the user selects the "last day" option for carryover_day, we are currently assigning the 31st as the day Hardcoding the 31st as the `carryover_day` can lead to errors when the `_get_carryover_date` method is triggered. For example, this causes failures in months with fewer days (e.g., February or April).

**Fix:**
-----------
evaluate the correct carryover_day based on the selected month & year when the value is set to last day, before using it to prepare the final date. This ensures that the last day of each month is accurately determined and applied.

**Traceback:**
------------
 ValueError: day is out of range for month


**OPW:** 4792938

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

Forward-Port-Of: odoo/odoo#211205

**Steps to reproduce:**
- Install Accounting and l10n_es_edi_facturae
- Switch to a Spanish company (e.g. ES Company)
- Create or edit a Spanish customer and set "Facturae" as eInvoice format
- Create an invoice:
  * Customer: [the Spanish customer]
  * Product: [any]
  * Customer Reference: [anything]
- Confirm the invoice
- Generate Facturae edi file via "Send & Print" button
- Check the generated XML

**Issue:**
When submitting the XML to FACe service, the XML is rejected with the following error:
"Element 'ReceiverContractReference': This element is not expected. Expected is one of ( FileDate, SequenceNumber, DeliveryNotesReferences, ItemDescription )."
It is caused by "ReceiverContractReference" being set after "FileReference" in the invoice line section.
Apparently, the order defined in the documentation should be respected.
"ReceiverContractReference" should be set before "ReceiverTransactionReference".

The issue has been introduced by this other fix:
https://github.com/odoo/odoo/commit/ac1af565161d70d57f51d579d0530eb7766c0c76

opw-4579987



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

Forward-Port-Of: odoo/odoo#211177

Steps to reproduce:
- Open Follow-up levels for 15 days -Check the option for “Automatic”
- Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration.
- Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic.
- There will appear a red ribbon on the right corner that says “In need of action”
- In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup”
- Run this action manually

Issue:
Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address

Note:
This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses.

Cause:
When running the cron, the recipients aren't in the options

Solution:
Add an helper to find all necessary recipients from the template if no recipient ids in the options

opw-4527398

Forward-Port-Of: odoo/enterprise#84714
Forward-Port-Of: odoo/enterprise#83944