Odoo Changelog — 2025-12-01

Monday, December 1, 2025

58 changes

Branch: saas-18.4

12 changes

Bug Fixes(12)

Resolved issues and error corrections

[FIX] sale_project: set allocated hours on task creation

PR #237838

Coresaas-18.4sale_projectMEDIUM

This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain service products. This change ensures that the allocated hours on tasks are accurately set to match the quantity of the corresponding sales order line, improving the accuracy of time tracking.

Original PR description

To reproduce:
=============
- Create service product with `service_tracking = task_in_project` and `service_type = manual`
- Create a SO with this product and set quantity on the line
- Confirm the SO
- check the created task, allocated hours is 0.0 instead of the quantity of the SO line

Problem:
========
When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'.

Solution:
=========
Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity.

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

Forward-Port-Of: odoo/odoo#237398
Forward-Port-Of: odoo/odoo#234524

#sales#tasks#time tracking

[FIX] l10n_mx_reports: DIOT TXT export for entries without partner

PR #100875

Enterprisesaas-18.4l10n_mx_reportsMEDIUM

This update resolves an issue where the DIOT tax report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting reliability. This change addresses a technical bug related to data processing within the DIOT reporting module.

Original PR description

**Steps to reproduce:**
1. Install `Accounting` and `l10n_mx_reports` modules.
2. Create two journal entries using DIOT tax grid: one with partner, one without
3. Confirm the entries.
4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`.
5. Try to print the DIOT report in TXT format from the top-right dropdown.

**Observed behavior:**
* Export fails with a traceback if any entry has no partner.

**Root cause:**
The method `_get_diot_values_per_partner` does not handle entries without partners.

**Solution:**
raise `Usererror` if  entries without partners when sorting and exporting.

note:
The second commit addresses a traceback caused by a missing operation_type_code.
This occurs when all entries lack a partner or when a partner’s operation_type_code
field is not set.

opw-5060825

Forward-Port-Of: odoo/enterprise#100843
Forward-Port-Of: odoo/enterprise#96529

#reporting#tax#mexico

[FIX] hr_holidays_gantt: prevent error when working schedule is not set

PR #100730

Enterprisesaas-18.4hr_holidays_ganttMEDIUM

This update prevents a critical error that occurred when employees without a working schedule attempted to view their time off in the Gantt view. The fix ensures the system gracefully handles missing schedule data, improving the user experience and preventing data display issues. This resolves a technical issue impacting time off reporting.

Original PR description

Currently, an error occurs when an employee has no working schedule set and the user tries to open the Time Off overview in the Gantt view.

**Steps to Reproduce:**
1. Install `hr_holidays_gantt` with demo data.
2. Remove the **Working Hours**(Payroll section) of **Marc Demo**.
3. Navigate to: Time off > Overview.

**Error:**
`AttributeError -  'bool' object has no attribute 'upper'`

**Cause:**
The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error.

**Fix:**
This commit skips the computation when the contract does not have a working schedule set.

[1] - https://github.com/odoo/enterprise/blob/db049f42ad4c2c291b2d64a9e637cd2292c280e8/hr_holidays_gantt/models/hr_leave.py#L204

sentry-7017326141

#hr#time off#gantt#schedule

[FIX] mail: prevent blur applied video stream freeze when switching tab

PR #238077

Coresaas-18.4mailMEDIUM

This update fixes a bug that caused video streams with background blur to freeze when users switched between browser tabs during video calls. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring smooth and uninterrupted calls.

Original PR description

**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…

**Description of the issue/feature this PR addresses:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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

Forward-Port-Of: odoo/odoo#226455

#video#call#performance

[FIX] l10n_ch_hr_payroll_elm_transmission_5_3: Fix field access

PR #100939

Enterprisesaas-18.4hr_payrolll10n_ch_hr_payrollMEDIUM

This update resolves an issue preventing proper access to key fields within the payroll module for Switzerland (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate data transmission related to Swiss payroll reporting, improving the reliability of financial reporting. This change impacts the HR and Payroll functionalities.

#payroll#Switzerland#reporting

18.0 fix broken ds filters rar

PR #237989

Coresaas-18.4spreadsheetMEDIUM

This update resolves an issue where the spreadsheet feature wasn't reliably displaying data errors, leading to a confusing user experience. The team removed a confusing 'clear' button and corrected a technical error that prevented data loading errors from being properly displayed. This ensures data is loaded correctly and errors are clearly communicated to the user.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#236683
Forward-Port-Of: odoo/odoo#233739

#spreadsheet#data loading#error handling

18.0 fix broken ds filters rar

PR #100887

Enterprisesaas-18.4spreadsheetMEDIUM

This update resolves an issue where users creating filters in the spreadsheet edition would encounter errors when working with broken data sources. The fix extends a previous safeguard to all filter types, ensuring a smoother user experience and preventing crashes during filter creation, particularly after data source migrations.

Original PR description

Forward-Port-Of: odoo/enterprise#100027
Forward-Port-Of: odoo/enterprise#98448

#filters#spreadsheet#data sources

[FIX] hr: allow portal user to be linked to employee

PR #237564

Coresaas-18.4hrMEDIUM

This update fixes a previous limitation by allowing portal users to be directly linked to employee records within the HR module. The system now displays all portal users in the employee selection field and defaults the search view to show internal users, improving data accuracy and streamlining workflows. This change simplifies employee management and reporting.

Original PR description

- Display all portal users in the user field.
- Set the default filter in the search view to show internal users.
- Change the placeholder text for the `user_id`.

task-5176046

#hr#portal#employee

[FIX] l10n_cz: prevent invoice date change after updating partner address

PR #238118

Coresaas-18.4l10n_czMEDIUM

This update fixes an issue where the invoice date was incorrectly changing after a company partner's address was updated. The fix ensures that the invoice date remains consistent, regardless of address changes, preventing potential accounting discrepancies. This improves data accuracy and reliability for Czech invoices.

Original PR description

**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…

**Steps to reproduce**

1.Install Accounting, Contacts, and l10n_cz.
2.Create an invoice with a future `invoice date` and confirm it.
3.Go to Contacts → open the company (res.partner).
4.Modify any address field (street, zip, etc.) and save.
5.Return to the invoice → in the chatter, the `date` field has change unexpectedly

> Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction.

**Issue**
- The confirmed invoice `date` changes when updating the company partner’s address.

**Cause**

https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24

- When creating an invoice, the `date` field is correctly set based on the
`taxable_supply_date` while the invoice is in the draft state. After
confirming (posting) the invoice, it moves to the `posted` state.

- However, when updating the partner address, the `_compute_date` method
is triggered again, which calls `super()` and recomputes the `date` field
using the standard logic. Since the invoice is already in the `posted`
state, the CZ-specific condition is not satisfied, and the `date` gets
updated incorrectly.

**Solution**

- Update `_compute_date` to only call super() for invoices in draft state.
- This prevents unwanted recomputation of the `date` on post invoices.

opw - 5086961

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

Forward-Port-Of: odoo/odoo#238045
Forward-Port-Of: odoo/odoo#229513

#accounting#czech#invoice

[FIX] l10n_ch_hr_payroll: Add missing input types corresponding to rules

PR #100992

Enterprisesaas-18.4l10n_ch_hr_payrollMEDIUM

This update fixes a technical issue related to payroll processing in the Odoo Enterprise module for Switzerland (l10n_ch_hr_payroll). It adds missing input types required to accurately reflect Swiss tax and social security regulations, ensuring correct payroll calculations and compliance.

#payroll#Switzerland#compliance

[FIX] account_accountant: deferred entries generation method setting

PR #100933

Enterprisesaas-18.4accountantMEDIUM

This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#deferred revenue#credit notes

[FIX] mrp_workorder: component consumption in shopfloor

PR #100906

Enterprisesaas-18.4mrp_workorderMEDIUM

This update fixes a bug in the shop floor component consumption process when tracking by lot. Previously, the system incorrectly consumed large quantities (e.g., 1000kg instead of 50g) due to an issue with how lot quantities were handled. This change ensures accurate component consumption based on lot quantities, improving inventory management.

Original PR description

**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…

**PROBLEM**
Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg).

**STEP TO REPRODUCE**
1. create a product.
2. create a bom with:
- a component tracked by lot, with kg as product uom, but g as the bom uom.
- create a step, during which 50g of the component is consumed.
3. create two lots of the component, with 1kg each.
4. create a MO for the product with the bom.
5. in the shop floor, try consuming the component and select one of the lot as a source.
6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove).
7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g).

**CAUSE**
1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant.
2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g.
3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter).

opw-5136050

Forward-Port-Of: odoo/enterprise#97005

#inventory#production#lot tracking

Branch: saas-18.3

7 changes

Bug Fixes(7)

Resolved issues and error corrections

[FIX] sale_project: set allocated hours on task creation

PR #237832

Coresaas-18.3sale_projectMEDIUM

This update fixes an issue where tasks created from service orders weren't automatically reflecting the order's quantity in their allocated hours. Previously, the hours were incorrectly set to zero unless the service type was 'milestones' or 'manual'. Now, the task's hours will accurately match the quantity of the corresponding service order line, ensuring accurate time tracking for service projects.

Original PR description

To reproduce:
=============
- Create service product with `service_tracking = task_in_project` and `service_type = manual`
- Create a SO with this product and set quantity on the line
- Confirm the SO
- check the created task, allocated hours is 0.0 instead of the quantity of the SO line

Problem:
========
When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'.

Solution:
=========
Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity.

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

Forward-Port-Of: odoo/odoo#237398
Forward-Port-Of: odoo/odoo#234524

#time tracking#service projects#sales

[FIX] l10n_cz: prevent invoice date change after updating partner address

PR #238045

Coresaas-18.3l10n_czMEDIUM

This update resolves an issue where the invoice date was unexpectedly changing after a company partner's address was modified. The fix prevents the invoice date from being recalculated when an invoice is in the ‘posted’ state, ensuring data accuracy and consistency. This change improves the reliability of invoicing processes for Czech customers.

Original PR description

**Steps to reproduce**

> Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction.

**Issue**
- The confirmed invoice `date` changes when updating the company partner’s address.

**Cause**

https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24

**Solution**

- Update `_compute_date` to only call super() for invoices in draft state.
- This prevents unwanted recomputation of the `date` on post invoices.

opw - 5086961

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

Forward-Port-Of: odoo/odoo#229513

#accounting#czech#invoice

[FIX] l10n_nl_reports_sbr_icp: include negative amount in XBRL report

PR #100702

Enterprisesaas-18.3l10n_nl_reportsMEDIUM

This update fixes an issue where negative sales amounts (like credit notes) were not being included in the exported XBRL report for the EC Sales List. The change ensures that all sales figures, including negative ones, are now correctly generated and available for export, improving report accuracy and compliance.

Original PR description

To replicate:
1. Install l10n_nl_reports_sbr_icp
2. Create an european partner with a VAT number
3. Create a credit note for this partner
4. Go to Accounting > Reporting > EC Sales List
5. The negative line appears in the report
6. Click on XBRL to export the report The negative line is not included in the exported report

Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values.

opw-5220622

Forward-Port-Of: odoo/enterprise#100669
Forward-Port-Of: odoo/enterprise#100009

#reporting#XBRL#VAT#Netherlands

[FIX] mail: prevent blur applied video stream freeze when switching tab

PR #238044

Coresaas-18.3mailMEDIUM

This update resolves an issue where background blur in video calls would cause video streams to freeze when users switched to another tab. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring a smoother experience for users regardless of which tabs they are using.

Original PR description

**Description of the issue/feature this PR addresses:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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

Forward-Port-Of: odoo/odoo#226455

#video#performance#user experience

[FIX] mail: ensure message Shadow DOM has access to CSS rules

PR #225136

Coresaas-18.3mailMEDIUM

This update fixes a bug preventing users from seeing email quotes within the Odoo Chatter interface. The issue stemmed from a Shadow DOM configuration that blocked CSS styles, hiding the quote display and toggle button. Applying the necessary CSS from the existing Odoo assets ensures quotes are now correctly visible and accessible.

Original PR description

Currently, in a chatter message, there's no way for a user to toggle on mail quotes. ### Steps to reproduce * install `crm` * in the settings, enable leads * configure a mail alias for a sales team *…

Currently, in a chatter message, there's no way for a user to toggle on mail quotes.

### Steps to reproduce

* install `crm`
* in the settings, enable leads
* configure a mail alias for a sales team
* forward an email to that mail alias
* open lead that was created, look into the chatter to find the message of the email you sent

You should see that the body of the email you forwarded does not appear in the chatter.

### Cause

Email quotes are supposed to be hidden in the chatter, with an ellipsis button that allows the user to show them. In this case, all these elements are actually there in the DOM, but not visible/interactable by the user.

Both the forwarded email quote and the button are placed inside of a Shadow DOM. However, since Shadow DOMs ignore parent styles, the ellipsis button is lacking the necessary rules to be displayed at all. This leads to there not being any way for the user to unfold email quotes.

### Fix

Apply the CSS from the `web.assets_web` bundle into the Shadow DOM. That bundle should already be loaded in the containing document, so there's no cost or extra request by the browser.

opw-4863953

#chat#email#quotes#user interface

[FIX] account_accountant: deferred entries generation method setting

PR #100923

Enterprisesaas-18.3accountantMEDIUM

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#deferrals#credit notes

[FIX] mail: show reply context for attachment-only messages

PR #238066

Coresaas-18.3mailMEDIUM

This update fixes an issue where replying to messages with only attachments didn't clearly show the original message being responded to. Now, users will always see the context of the message they're replying to, regardless of whether they include text or attachments, leading to a smoother and more intuitive communication experience.

Original PR description

**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent…

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, when replying to a message with only attachments (no text content),
the parent message context is not displayed. This makes it unclear which message
the user is replying to when they only attach files without typing any text.

**Current behavior before PR:**
----------------------------------------------
- Reply messages with only attachments do not show the parent message context
- Users cannot see what message they are replying to when only attaching files
- The MessageInReply component is not rendered for attachment-only replies

**Desired behavior after PR is merged:**
----------------------------------------------
- Reply messages with only attachments now display the parent message context
- Users can clearly see what message they are replying to, even with only attachments
- The MessageInReply component renders consistently for all reply types
- Visual structure maintains proper Odoo message styling
- Better user experience with clear reply context

Task-5109159

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

Forward-Port-Of: odoo/odoo#238047
Forward-Port-Of: odoo/odoo#230574

#communication#attachments#messaging

Branch: saas-18.2

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] documents_account: use the supplier currency for vendor documents

PR #100805

Enterprisesaas-18.2documents_accountMEDIUM

This update fixes an issue where vendor bills created in the Documents module defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and simplifies reconciliation.

Original PR description

**Issue:**

When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's.

However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied.

**Steps to reproduce:**

  - In Documents, upload a bill.
  - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency).
  - Click on "Create Vendor Bill".

The used currency isn't that of the supplier.

opw-4406074

Forward-Port-Of: odoo/enterprise#97417
Forward-Port-Of: odoo/enterprise#78380

#currency#vendor#bills#documents

[FIX] account_accountant: deferred entries generation method setting

PR #100917

Enterprisesaas-18.2accountantMEDIUM

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#credit notes#deferrals

Branch: master

13 changes

Bug Fixes(13)

Resolved issues and error corrections

[FIX] l10n_mx_reports: DIOT TXT export for entries without partner

PR #100900

Enterprisemasterl10n_mx_reportsMEDIUM

This update resolves an issue where the DIOT report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting accuracy. The change includes a safeguard to prevent crashes and a more robust method for retrieving data.

Original PR description

**Steps to reproduce:**
1. Install `Accounting` and `l10n_mx_reports` modules.
2. Create two journal entries using DIOT tax grid: one with partner, one without
3. Confirm the entries.
4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`.
5. Try to print the DIOT report in TXT format from the top-right dropdown.

**Observed behavior:**
* Export fails with a traceback if any entry has no partner.

**Root cause:**
The method `_get_diot_values_per_partner` does not handle entries without partners.

**Solution:**
raise `Usererror` if  entries without partners when sorting and exporting.

note:
The second commit addresses a traceback caused by a missing operation_type_code.
This occurs when all entries lack a partner or when a partner’s operation_type_code
field is not set.

opw-5060825

Forward-Port-Of: odoo/enterprise#100843
Forward-Port-Of: odoo/enterprise#96529

#reporting#tax#mexico

[FIX] l10n_lu_hr_payroll: make indexed wage readonly for LU Company

PR #98299

Enterprisemasterl10n_lu_hr_payrollMEDIUM

This update ensures that the indexed wage for Luxembourg employees remains read-only after a contract is signed. This prevents manual changes to the base salary threshold, aligning with local regulations and guaranteeing accurate payroll calculations based on annual indexing.

Original PR description

In LU, when you sign a new contract, the salary should automatically increase henceforth and is indexed each year.
The indexed wage at a given year defines the base threshold for the employee's salary. It is dependent on the
country's salary rules, index at signature and current index, and must not be modifiable by the company's officers.
The field should thus be read-only.

TaskID: 5217101

#payroll#lu#hr#salary

[FIX] l10n_be_intrastat: order file intrastat export

PR #99645

Enterprisemasterl10n_be_intrastatMEDIUM

This update resolves an issue where the generation of Intrastat export files for Belgium was inconsistent, potentially leading to discrepancies in reporting. The change ensures a predictable and reliable export process, improving the accuracy of Intrastat data. This fix addresses a technical problem that impacts the integrity of business reporting.

Original PR description

Ensure be intrastat file export is deterministic

Runbot error 234045

#reporting#Belgium#Intrastat

[FIX] hr_work_entry,hr_contract_salary_payroll: offer contract template

PR #100814

Enterprisemasterhr_contract_salary_payrollMEDIUM

This update resolves an issue where changing a contract template on a new offer would trigger a validation error. The fix ensures that the system correctly handles work entries and salary simulations, preventing incorrect contract assignments. This improves the accuracy of offer creation and avoids potential data inconsistencies.

Original PR description

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Forward-Port-Of: odoo/enterprise#100151

#contracts#offers#validation

[FIX] l10n_mx_edi_pos: use partner CFDI usage

PR #100820

Enterprisemasterl10n_mx_edi_posMEDIUM

This update ensures that when a customer in Mexico uses the Point of Sale (PoS), the correct CFDI usage (as defined on their partner record) is automatically applied to the order. Previously, the system defaulted to 'G03', which is now corrected to reflect the customer's specific CFDI setting, ensuring compliance with Mexican tax regulations.

Original PR description

When making an order in the PoS in Mexico, if the customer has a CFDI usage set on their partner, it should be used for the order instead of the default one.

Steps to reproduce:
-------------------
* Install l10n_mx_edi_pos
* Create a partner with a CFDI usage different than 'G03'
* Open the PoS, select the partner and make an order
* Validate the order and check the order in the backend
> Observation: The CFDI usage is 'G03' instead of the one set on the
  partner.

opw-5018288

Forward-Port-Of: odoo/enterprise#98607

#Mexico#CFDI#POS#Tax Compliance

[FIX] project_timesheet_forecast: Exclude leaves/ holidays from planning reports

PR #100892

Enterprisemasterproject_timesheet_forecastMEDIUM

This update corrects a reporting issue where employee leave days were incorrectly included in planned hour calculations. The fix ensures that leave and holidays are properly excluded, providing more accurate data for project planning and analysis within the Timesheets > Planning Analysis report. This improves the reliability of time tracking information.

Original PR description

**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100664
Forward-Port-Of: odoo/enterprise#97657

#timesheet#planning#reporting#leave

[FIX] sign: comply with ESIGN Act for U.S. companies

PR #100905

EnterprisemastersignMEDIUM

This update ensures the Sign app meets the ESIGN Act requirements for U.S. companies. Users are now notified when a U.S. sender is involved and given the option to request a paper copy of signed documents, providing legal protection.

Original PR description

Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance.

task-5166918

Forward-Port-Of: odoo/enterprise#100674
Forward-Port-Of: odoo/enterprise#97163

#compliance#legal#sign

[FIX] account_accountant: Fix st_line edit with exchange diff

PR #100904

EnterprisemasteraccountantMEDIUM

This update fixes a bug that prevented users from editing statement lines when currency exchange differences were involved. Previously, attempting to mark an invoice as fully paid triggered an error. The fix now intelligently filters out exchange moves during reconciliation checks, allowing users to successfully edit statement lines without encountering this issue.

Original PR description

When you create a statement line with one currency rate, and you reconcile it with
a move with a different currency rate, this creates an exchange move.
But when you want to edit the statement line amount, like marking the invoice as
fully paid, this raise a UserError, as the Exchange move is reverted and reconciled,
which means it throw an error like "You are trying to reconcile some entries that are already reconciled."

This commit, fix this behaviour, by excluding the exchange moves from the check process.

Linked:https://github.com/odoo/odoo/pull/237367

[opw-5184679](https://www.odoo.com/odoo/my-support-tasks/5184679)

Forward-Port-Of: odoo/enterprise#100864
Forward-Port-Of: odoo/enterprise#100493

#currency#reconciliation#statement

[FIX] l10n_co_dian: prevent removal of CUFE code

PR #100946

Enterprisemasterl10n_co_dianMEDIUM

This update prevents the loss of CUFE codes during DIAN invoice processing for Colombian companies. The fix addresses a technical issue where invoices were being incorrectly marked as duplicates, leading to the removal of the necessary code. This ensures accurate reporting and compliance with Colombian tax regulations.

Original PR description

This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed…

This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed and a Colombian company:

- Set up the DIAN Sales journal with the correct *Technical Key / Technical Control Key* as described in the article.
- Ensure that each invoice name follows the required format.
- Create a commercial invoice in the DIAN Sales journal (invoice date set in the past) and send it to DIAN.
- Create the corresponding bill by copying the invoice reference and the CUFE code, then acknowledge receipt.
- Run the server action **“Colombian EDI: Update Invoice Commercial States”**.

Repeat this process at least twice. The CUFE code on the older invoice is removed.

The server action calls `_l10n_co_dian_cron_update_event_status()`, which triggers `l10n_co_dian_action_update_event_status`. In this method, we remove `l10n_co_dian_document_ids` from moves considered duplicates. This deletion removes the `document_id` from the older move since it is treated as a duplicate of the newer one (both are in the “sent” state).

However, in the compute method for `l10n_co_edi_cufe_cude_ref` (`_compute_l10n_co_dian_cufe`), we always reset `l10n_co_edi_cufe_cude_ref` to `False` before checking documents. Since the oldest move ends up with no documents, it never enters the loop and the CUFE code is lost.

opw-5257129

Forward-Port-Of: odoo/enterprise#99776

#DIAN#CUFE#Colombia#reporting

[FIX] l10n_be_hr_contract_salary: fix Mobility Budget computation in part time

PR #100903

EnterprisemasterhrMEDIUM

This update fixes an issue where the mobility budget was incorrectly calculated for part-time employees during salary simulations. The system now accurately computes the budget based on a full-time equivalent, aligning with Belgian regulations. This ensures accurate budget reporting and compliance.

Original PR description

Mobility budget should be computed based on a full time equivalent:
https://lebudgetmobilite.be/fr/6-quel-est-le-montant-du-budget-mobilite#te

During salary simulation, that is based on work time rate, a payslip is
computed and triggers to recompute the version on which the payslip is bas
That makes the mobility budget recompute as well, but this time, based on
part time wage (e.g.: 2000 instead of 4000 for a mid-time).

This PR adds context keys to ensure that during the salary simulation,
the Mobility budget is still computed based on a full time equivalent.

Also, this PR reintroduces wage with mobility budget on employee view

Task-5360844

Forward-Port-Of: odoo/enterprise#100597

#payroll#mobility#Belgium

[FIX] l10n_be_hr_payroll: fix leave types in departure holiday attest

PR #100901

Enterprisemasterl10n_be_hr_payrollMEDIUM

This update corrects a flaw in how time off requests are searched within the departure holiday attest process. The system now prioritizes searching based on the work entry type, which is a more reliable and consistent method. This ensures more accurate and reliable time off calculations for payroll.

Original PR description

The search on legal and european time off were barely based on leave types. It's safer to search based on the leave type of the corresponding work entry types as work entry types are more rigid.

task-5367240

Forward-Port-Of: odoo/enterprise#100860

#payroll#leave#holiday

[IMP] account_accountant: open list view for invalid statements alert

PR #101009

EnterprisemasteraccountantMEDIUM

This update streamlines the process for correcting invalid financial statements. Previously, users were bounced to a limited view, requiring manual navigation to fix errors. Now, the alert directly opens the list view, allowing for immediate and efficient corrections, saving user time and effort.

Original PR description

When the dashboard shows an invalid statement, clicking the alert redirected users to the kanban view of statements. That view does not allow editing or performing any corrective actions, forcing users to manually switch to the list view to fix the invalid entries.

This commit updates the 'Invalid Statement(s)' alert so it redirects directly to the list view, allowing users to correct the statements without extra navigation.

task-5346063

Forward-Port-Of: odoo/enterprise#100407

#finance#statements#alerts

[FIX] account_accountant: deferred entries generation method setting

PR #100970

EnterprisemasteraccountantMEDIUM

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#deferred revenue#credit notes

Branch: 19.0

17 changes

Bug Fixes(17)

Resolved issues and error corrections

[FIX] sale_project: set allocated hours on task creation

PR #237851

Core19.0sale_projectMEDIUM

This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain product types. Now, the task's allocated hours will accurately match the quantity of the sales order line, ensuring accurate time tracking for service-based projects.

Original PR description

To reproduce:
=============
- Create service product with `service_tracking = task_in_project` and `service_type = manual`
- Create a SO with this product and set quantity on the line
- Confirm the SO
- check the created task, allocated hours is 0.0 instead of the quantity of the SO line

Problem:
========
When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'.

Solution:
=========
Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity.

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

Forward-Port-Of: odoo/odoo#237398
Forward-Port-Of: odoo/odoo#234524

#sales#tasks#time tracking

[FIX] l10n_fr_payroll : Contract name fix to version

PR #100879

Enterprise19.0l10n_fr_hr_payrollMEDIUM

This update fixes an error in the French payroll module that prevented users from correctly calculating payslips. The issue stemmed from an outdated reference to 'contract' instead of 'version' within the module's data files. This change ensures accurate payroll processing for French companies.

Original PR description

Steps to reproduce: 1. Open database with version saas-18.4 2. Install module l10n_fr_hr_payroll_with_accounting 3. Make sure that your company's country is France. 4. Set `Salary Journal` in:…

Steps to reproduce:
1. Open database with version saas-18.4
2. Install module l10n_fr_hr_payroll_with_accounting
3. Make sure that your company's country is France.
4. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
5. In Payroll app create a payslip for any employee having contract.
6. Make sure in `other inputs` you make new type and in that in the `availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

In saas-18.4, the model hr.contract was [changed](https://github.com/odoo/upgrade/blob/fa44eb03c2b46d948e20dc6f5ac01dca2b625b90/migrations/hr/saas~18.4.1.1/pre-migrate.py#L41) to hr.version . All related code https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8 was updated to use version instead of contract. in this commit.

However, in the module l10n_fr_hr_payroll, there where some fields which is still using `contract` to refer other fields .
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/data/l10n_fr_hr_payroll_employe_cadre_data.xml#L130 Because of this, Odoo raises the error `Wrong python code name 'contract' is not defined when evaluating the code`.

I have fixed the issue by updating the name from contract to version in that module contract to version.

opw: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

Forward-Port-Of: odoo/enterprise#100112

#payroll#french#hr#error

[FIX] l10n_ae: use commercial contact to decide simplified or tax invoice

PR #237975

Core19.0l10n_aeMEDIUM

This update fixes an error in how Odoo handles invoices for customers in the UAE. Previously, invoices issued to related contacts were incorrectly labeled as 'Simplified Tax' invoices. Now, the system uses the customer's commercial contact information to accurately determine whether an invoice should be a 'Tax' or 'Simplified Tax' invoice, ensuring proper accounting and compliance.

Original PR description

Before this commit:
- If an invoice is issued to a related contact of a company contact, it is labeled as a 'Simplified Tax' invoice. This is incorrect since the invoice is being issued to the related company on behalf of the company, so it should be a 'Tax' invoice.

After this commit:
- The commercial_partner field is now used to decide whether an invoice is a 'Tax' or 'Simplified Tax' invoice.

task-5366608

#accounting#UAE#tax#invoice

[FIX] l10n_co_dian: prevent removal of CUFE code

PR #99776

Enterprise19.0l10n_co_dianMEDIUM

This update prevents the loss of CUFE codes during DIAN invoice processing for Colombian companies. The previous process incorrectly removed the code due to a technical issue, now fixed to ensure accurate reporting and compliance. This resolves a critical bug impacting financial data integrity.

Original PR description

This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed and a Colombian company:

- Set up the DIAN Sales journal with the correct *Technical Key / Technical Control Key* as described in the article.
- Ensure that each invoice name follows the required format.
- Create a commercial invoice in the DIAN Sales journal (invoice date set in the past) and send it to DIAN.
- Create the corresponding bill by copying the invoice reference and the CUFE code, then acknowledge receipt.
- Run the server action **“Colombian EDI: Update Invoice Commercial States”**.

Repeat this process at least twice. The CUFE code on the older invoice is removed.

The server action calls `_l10n_co_dian_cron_update_event_status()`, which triggers `l10n_co_dian_action_update_event_status`. In this method, we remove `l10n_co_dian_document_ids` from moves considered duplicates. This deletion removes the `document_id` from the older move since it is treated as a duplicate of the newer one (both are in the “sent” state).

However, in the compute method for `l10n_co_edi_cufe_cude_ref` (`_compute_l10n_co_dian_cufe`), we always reset `l10n_co_edi_cufe_cude_ref` to `False` before checking documents. Since the oldest move ends up with no documents, it never enters the loop and the CUFE code is lost.

opw-5257129

#DIAN#CUFE#Colombia#reporting#compliance

[PERF] point_of_sale: optimize loading of product configurator popup

PR #235967

Core19.0point_of_saleMEDIUM

This update optimizes how the product configurator popup loads in Point of Sale, making the system faster and more responsive. Previously, the system was slow when calculating exclusions for product attributes due to an inefficient search process. This change improves the overall user experience and reduces potential delays during sales transactions.

Original PR description

Before this commit, to compute the exclusions of a ptav, it would loop through all ptav records to find those that exclude the current one. This could be slow when there are many attributes and values.

opw-5230890

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

#performance#sales#product configurator

[FIX] website_sale_collect: fix cash on delivery for in store delivery type

PR #238001

Core19.0website_sale_collectMEDIUM

This update corrects a bug where 'Cash on Delivery' was incorrectly offered for 'in-store' delivery types. The fix ensures that cash on delivery is only available when the delivery type is set to 'pick up in store', streamlining the checkout process for customers using this payment method. This improves the overall customer experience.

Original PR description

### Issue:
In this issue, `allow_cash_on_delivery` is allowed when delivery type is pick up in store.

#### Steps to reproduce:
1. Create a `fixed_price` delivery method
2. Check `Cash on delivery` checkbox
3. Change the delivery type to `in_store` and configure it
4. Activate cash on delivery payment method
5. Choose a storable ptoduct on the /shop, checkout with a created dm and proceed to payment
6. Observe that you see the 'cash on delivery' pm for pickup in store.

Currently, `allow_cash_on_delivery` is invisible when `delivery_type` is set to `in_store`. However, it's not set to `False`, once the type is changed to `in_store`.

opw-5258535

Forward-Port-Of: odoo/odoo#235434

#payment#delivery#checkout

[FIX] mail: prevent blur applied video stream freeze when switching tab

PR #238078

Core19.0mailMEDIUM

This update resolves an issue where background blur in video calls would cause streams to freeze when users switched tabs. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring a smoother and more reliable experience during calls, regardless of tab activity.

Original PR description

**Description of the issue/feature this PR addresses:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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

Forward-Port-Of: odoo/odoo#226455

#video#calls#performance

[FIX] point_of_sale, pos_restaurant: prevent new order with skip screen

PR #236897

Core19.0pos_restaurantMEDIUM

This update resolves an issue where a new order was incorrectly created when the 'Skip Preview Screen' option was enabled in the restaurant POS. The fix ensures that orders are only initialized when a table is selected or a floating order is created, preventing data access errors and improving stability. This change primarily impacts the restaurant POS experience.

Original PR description

**Steps to reproduce:**
- In the config, click the ePos Printer checkbox
- Also check Automatic Receipt Printing and Skip Preview Screen
- Put a default preset with Name as it's identification
- Go in the restaurant and make a sale, pay for it
- When going back to the floor plan, a traceback appears

**Why the fix:**
This current problem arises because we are trying to access the current order, but we are on the floor plan, so there is no current order yet. The order is undefined, so we try to access *undefined.floating_order_name* and a traceback appears.

But the root issue is deeper than this. In the restaurant, the order is initialized when clicking a table, or when we create a floating order. But when the Skip Preview Screen option is enabled, we try to initialize the order right after the last order has been validated, like we do it in the normal PoS.

Doing this, we will try to handle the preset selection way too early, as the order is not fully initialized yet, and we will try to access data that have not been set yet.
The current error is not the only one we have with this setup, as other errors also arise if we bypass this specific error.

To fix this, we are now only initilizing the new order when we click on a table that has no order or when making a floating order. We do not create a new order after the validation of the last one, even if the Skip Preview Screen option is enabled. This is only true in the restaurant, as we keep on initializing a new order after the validation in the regular PoS.

Before this commit, we also tried to create a new order when opening the restaurant from the frontend (see image below), which resulted in a traceback.
We now only create a new order if the default screen is different from the Floor Screen.
<img width="375" height="249" alt="image" src="https://github.com/user-attachments/assets/e38520f6-81e2-471e-a987-98d9426a6493" />

Starting in version 19.0, there is another waiting screen after paying and before going back to the floor plan, which handles things, so the bug is not present anymore. But the traceback we get when opening the register from the frontend is still present in future versions.

opw-5131309

Forward-Port-Of: odoo/odoo#230796

#POS#Restaurant#Order Processing

[FIX] mrp: fix overview for bom with decimal quantity

PR #237927

Core19.0mrpMEDIUM

This update resolves an issue where the time calculations for operations on Bills of Materials (BoMs) were inaccurate when decimal quantities were used. The fix ensures that operation times are now correctly computed, leading to more precise production planning and costing. This improves the reliability of BoM-based reports and calculations.

Original PR description

When a BoM has a decimal quantity, the operations' times are not correctly computed.

task: 5366973

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

#bom#production#inventory

[IMP] account_accountant: open list view for invalid statements alert

PR #100407

Enterprise19.0accountantMEDIUM

This update streamlines the process for correcting invalid financial statements. Previously, users were directed to a view that couldn't be edited, requiring extra steps to fix errors. Now, the alert automatically directs users to the list view, allowing for immediate correction and saving time.

Original PR description

When the dashboard shows an invalid statement, clicking the alert redirected users to the kanban view of statements. That view does not allow editing or performing any corrective actions, forcing users to manually switch to the list view to fix the invalid entries.

This commit updates the 'Invalid Statement(s)' alert so it redirects directly to the list view, allowing users to correct the statements without extra navigation.

task-5346063

#finance#statements#alerts

[FIX] stock_account: avoid zero-division in FIFO valuation

PR #237302

Core19.0stock_accountMEDIUM

This update resolves a bug that occurred when calculating inventory values (FIFO method) due to a potential division by zero. When a stock move results in a zero quantity, the system now defaults to using the product's standard price instead, ensuring accurate valuation calculations. This improves the reliability of inventory reporting.

Original PR description

In some cases an incoming FIFO move can end up with a valued quantity of 0 (e.g. partial receipts or leftover move lines).
The valuation code was still trying to compute `value / qty`, which caused a `ZeroDivisionError`.

```py
File "/home/odoo/src/odoo/19.0/addons/stock_account/models/product.py", line 169, in _compute_value
    product.avg_cost = product._get_standard_price_at_date()
   File "/home/odoo/src/odoo/19.0/addons/stock_account/models/product.py", line 230, in _get_standard_price_at_date
    return last_in._get_value(at_date=date) / last_in._get_valued_qty()
 ZeroDivisionError: float division by zero
```

Fallback to the product’s standard price when the last incoming move has no valued quantity.

opw-5223443
upg-3275142
tbg-2284



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

#inventory#valuation#FIFO

[FIX] account_accountant: duplicate name in reco model auto creation

PR #100919

Enterprise19.0accountantMEDIUM

This update resolves a bug that prevented bank statement reconciliations from completing when using the 'Set Account' feature. The issue stemmed from the system not properly handling deleted reconciliation models, leading to errors about duplicate names. The fix ensures that reconciliation models are named uniquely, preventing these failures.

Original PR description

It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name" Steps…

It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name"

Steps to reproduce:

1. Create a current liability, reconciliable account "455010 My Account"
2. Create 2+ with a common labels (TEST RECONCILIATION)
3. Use "Set Account" button to reconcile the first transaction with account 455010.
4. Repeat 2-3 with a shorter label
5. Open Reconciliation models for the Journal and delete the one named "455010 My Account"
6. Repeat 2-3 with an even shorted label

Issue:

Reconciliation will be blocked by error during automatic creation of reconciliation model

Analysis:

It occurs because we don't take into account that old reconciliation models may have been deleted, so even if we count a singe record it may have already been labeled "<account_name> (1)"
Improved the naming by looking at the existing models and increasing the counter if necessary

opw-5184696

Forward-Port-Of: odoo/enterprise#100468
Forward-Port-Of: odoo/enterprise#98785

#reconciliation#bank statements#accounts

[FIX] stock_account: compute avg price using only move with same product

PR #236946

Core19.0stockMEDIUM

This update fixes a bug that prevented users from successfully validating returns after duplicating and changing products within a picking. The fix ensures accurate average price calculations by limiting stock move usage to the same product, preventing UoM errors and improving return processing reliability.

Original PR description

When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…

When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product.

The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error.

Steps to reproduce:
- Create storable products P1 and P2:
  - Category: AVCO
  - P1 UoM: Unit
  - P2 UoM: Dozen
- Create a sale order with 1 unit of P1
- Confirm the SO
- Open the generated picking
- Duplicate it → a new picking is created and still linked to the same SO
- Change the product on the duplicated picking to P2
- Confirm and validate it
- Create a return on this picking and validate it
- Go back to the original picking of P1 and try to validate it

Problem:
A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)”

This fix ensures that average price is computed only using stock moves belonging to the same product.

opw-5027089

Forward-Port-Of: odoo/odoo#236706

#stock_returns#valuation#picking

[FIX] account_accountant: deferred entries generation method setting

PR #100950

Enterprise19.0accountantMEDIUM

This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will properly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#deferred revenue#credit notes

[PERF] mail: faster rendering of message list

PR #237430

Core19.0mailMEDIUM

This update optimizes how Odoo renders message lists, resulting in a faster loading experience. The change reduced rendering time from 374ms to 315ms on a laptop with 75 messages, improving user performance. This enhancement contributes to a smoother and more responsive user interface.

Original PR description

374ms to 315ms, laptop, 75 msgs

Task-5265271

#performance#user experience#mail

[FIX] l10n_ch_hr_payroll_elm_transmission_5_3: Fix field access

PR #100988

Enterprise19.0hr_payrollMEDIUM

This update resolves an issue preventing the correct transmission of data related to the Swiss Elm system. The fix ensures that necessary fields within the payroll module are accessible, allowing for accurate reporting and compliance with Swiss tax regulations. This ensures the continued proper functioning of the HR payroll calculations.

Original PR description

Forward-Port-Of: odoo/enterprise#100939

#payroll#Switzerland#tax

[PERF] mail: faster click handler of message action "reply"

PR #238122

Core19.0mailMEDIUM

This update significantly speeds up the "reply" click handler in the email interface. Previously, the system unnecessarily processed all emails to determine which ones to visually highlight. The change now only renders the selected email, resulting in a much faster response time – reducing processing time from 320ms to 60ms with 125 messages loaded.

Original PR description

Before this commit, message action "reply" click handler could be slow. This happens because visually all messages but the one to reply is selected, and non-selected messages have their opacity reduced. The reduced opacity was triggered from re-rendering all the message, which all observe `thread.composer.replyToMessage` to compare with themselves.

This is quite inefficient, especially when lots of messages are loaded, just to reduce opacity of all but the selected message to reply.

This commit improves by rendering only the selected message, and adapt style of all other messages in CSS.

With about 125 messages loaded, click handler timing goes from about 320ms to 60ms.

Task-5262770

#performance#email#user experience

Branch: 18.0

6 changes

Bug Fixes(6)

Resolved issues and error corrections

[FIX] spreadsheet_sale_management: Fix FieldSync Input

PR #96431

Enterprise18.0spreadsheet_sale_managementMEDIUM

This update fixes a bug where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. Now, changes made to the input are reliably saved, ensuring data accuracy and a smoother user experience. This resolves a previous issue impacting data consistency.

Original PR description

Currently, the FieldSync record input suffers from two issues:

1) The input value can be reset by parasitic renders
   While the user is inputting a value, if they did not confirm it and a
   global render occurs (other user joining the session, dragging the mouse
   on the grid), the input value will be reset to the one stored in the
   plugin, therefore erasing the last change of the user

2) In Chrome-based navigators, users can change the value of the input
   by using their mouse scrolling wheel. Such action *does not* trigger
   an `onChange` event; which means that the new value is never directly
   saved.

Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input.

Task-5123069

#spreadsheet#sale#data integrity

[Fix] l10n_be_hr_payroll_prisma: export traceback

PR #96743

Enterprise18.0l10n_be_hr_payroll_prismaMEDIUM

This update resolves a critical issue that caused the generation of payroll export files to fail. The fix corrects a naming discrepancy in the code, ensuring accurate retrieval of employee data. A new test suite has been implemented to guarantee the reliability of the export process.

Original PR description

The export generation crashed due to a mismatch between field names —
the code was referencing employee_ids, while the model actually defines
employee_id.
Since the Prisma code is now stored on the employee model, the logic was updated
to correctly access the employee_id field and retrieve the related Prisma code.

Additionally, a comprehensive test suite was added to validate Prisma code behavior, 
including:
- validation of code length for employees, companies, and work entry types,
- handling of codes across different companies,
- and the complete Prisma export flow (from work entry creation and validation
to export file generation).

task-5153727

#payroll#export#prisma#data

[FIX] {,purchase_}stock,stock_picking_batch: generate correct svl whe…

PR #235601

Core18.0stockpurchaseMEDIUM

This fix resolves an issue where stock valuations were incorrect after splitting a purchase order receipt into a batch and validating the batch. The problem stemmed from how the system calculated values during batch validation, leading to miscalculated stock values. This update ensures accurate stock valuations are generated when using batch billing.

Original PR description

…n batch billed on ordered qty **Problem:** When the picking of a purchase order (of a product billed on ordered quantity) is split into different moves and put in a batch, at batch validation, svls…

…n batch billed on ordered qty

**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.

 **Steps to reproduce:**
    - enable "Batch, Wave & Cluster Transfers" settings
    - create a storable product with a standard price of 1
    - set the category as avco
    - in the Purchase tab select the control policy as
    "on ordered quantities"
    - create and confirm a purchase order for 50 of this product
    - on the Receipt, change the quantity to 20 and split the
    picking
    - go back the the PO and create and confirm a bill for
    the full amount
    - click on the receipt smart button
    - select the two pickings and then the 'Action' button
    - select add to batch
    - check 'new batch transfer' and confirm
    - open the batch and validate it
    - open stock valuation
    
**Current behavior:**
    the newly created svls have total values of
    50 and 50.10

**Expected behavior:**
    it should be 20 and 30
    
**Cause of the issue:**
When the batch is validated, _action_done is called 
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.

Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit : 
- because the super method of action_done was already called, 
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30. 
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1 

**fix**
We do not take into account the move(s) of the 
same batch in the remaining value (because svls are not created yet)
so we should not  take them into account in the remaining quantity.

opw-5179581

#stock valuation#batch billing#purchase order

[FIX] pos_sale: prevent lot lines duplication on SO import

PR #234165

Core18.0pos_saleMEDIUM

This update resolves an issue where Sale Orders with lot-tracked products were incorrectly duplicated during import into POS. The fix prevents unnecessary line splits based on unit of measure, ensuring accurate order processing and avoiding data inconsistencies. This improves the reliability of the POS system when handling lot-based inventory.

Original PR description

## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the…

## Issue:
After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines

## Cause:
In the `settleSO` function, the line is first split because the UoM differs and is not `pos_groupable`
Among the default UoMs, only Units, Pack of 6, and Dozen have `is_pos_groupable` = True, meaning most other UoMs will trigger a line split

After duplicating the line due to the UoM split, an additional line is then added for each lot to link, causing duplicate entries in the POS order

## Steps to reproduce:
- In Settings, enable Lots & Serial Numbers and Units of Measure & Packagings
- Create a Product (Tracking: Lot, Sale Unit: g)
- Update the Quantity On Hand (Lot: "LOT", Quantity: 5)
- Create and confirm a Sale Order for the product (Quantity: 2)
- Open POS and import the SO
- Before the fix, there is 3 lines (2x no lots, 1x with lot + qty 2

## Other issues:
- The discount was not imported on the lot lines
- Some lines were missing when importing lines where part of the quantity had no available lot
- (This fix was already made in PR: https://github.com/odoo/odoo/pull/229075/files but was not forward-ported)

opw-5018295

#inventory#pos#lot tracking

[REV] pos_event_sale, event_sale: revert recent changes to event sale

PR #238152

Core18.0event_salepos_event_salewebsite_event_saleMEDIUM

This update reverts recent changes to the event sale report that were causing database compatibility problems. The fix previously intended to include PoS-sold tickets, but this resulted in errors for some Odoo databases. This reversion ensures stability and continued functionality of the event sale reporting feature.

Original PR description

This recent commit is causing dependencies issues in some Odoo database that rely on the pos_event_sale module. To maintain stability and ensure compatibility, reverting the recent changes made to the event sale reports and related files.

Original commit:
https://github.com/odoo/odoo/pull/226544/commits/e968ff178a0f0d11949dfac67b98e1b8acf771b0

Add event registration sold through PoS to the event sale report.

Steps to reproduce:
-------------------
* Create an event with tickets
* Sell a ticket through the PoS
* Go to the event sale report
> Observation: The ticket sold through PoS is not included in the report

Why the fix:
------------
We modify the SQL query of the event sale report to include event registrations sold through PoS. We also make sure to remove duplicates from the original query.

opw-4935195

#reporting#event sales#POS

[FIX] account_accountant: deferred entries generation method setting

PR #100910

Enterprise18.0accountantMEDIUM

Original PR description

The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do.
As a result, deferred entries for credit notes are not created when expected.

Steps to reproduce:
- Go to Accounting → Configuration → Settings.
- In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped
- In the Deferred Revenue Entries section, set Generate entries to: On bill validation
- Navigate to Accounting → Customers → Credit Notes.
- Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line).
- Validate the credit note.
- No deferred revenue entries are created.

Ticket [link](https://www.odoo.com/odoo/project.task/5187051)
opw-5187051

Forward-Port-Of: odoo/enterprise#100211

#accounting#deferrals#credit notes

Branch: 17.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_jo_edi: Fixed non-sequential counter values

PR #202731

Core17.0l10n_jo_ediMEDIUM

This update resolves a problem where invoice counters submitted to the Jordanian tax authority (ISTD) were not consistently sequential. The fix utilizes a new calculation to ensure counters are always in order, meeting ISTD requirements and preventing potential export delays. This improves the accuracy and reliability of our Jordan-specific accounting processes.

Original PR description

Before this commit, the invoice counter in the XML submitted to JoFotara was set to the move id. The problem with the move id is that it's not guaranteed that submitted counters would be sequential; they may contain gaps or even be out of order.
The ISTD expects counters to be sequential.

This commit solves this issue by relying on a computed field in assigning invoice counter in the EDI XML.

task-4632768




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

#Jordan#EDI#Tax Compliance