Thursday, May 21, 2026
11 changes · 18.0
Enhancements to existing features
This update adjusts how global discounts are exported in Odoo to align with UBL (Universal Business Language) standards. Previously, discounts were represented as negative invoice lines, which is now corrected by representing them as ‘Allowances’. This change ensures proper compliance with international trade regulations and simplifies UBL invoice generation.
Original PR description
Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a visual issue where the Timesheet Kanban header and dropdown menus were overlapping. The problem stemmed from a styling element (position-sticky) that created a stacking context conflict. Removing this element allows the header to be properly positioned, improving the user experience.
Original PR description
Steps to reproduce: - Open Timesheets. - Switch to kanban view. - Groupby any field. - Start timer and click on task/project field. Issue: - Kanban Header and Dropdown menu of selection overlap. Reason: - It is due to the usage of `postion-sticky` on the header thus creating it's own stacking context, so header and Kanban Renderer body work in different stacking context, thus overlapping each other where they shouldn't have. For more info refer: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/position#sticky Fix: - Remove `postion-sticky` as it doesnt serve any purpose as header can now work being a static postioned node. task-4714235 Forward-Port-Of: odoo/enterprise#103142
A test was failing due to a mismatch in how dates were interpreted across different timezones. This update ensures that leave allocation calculations use a consistent UTC date, preventing incorrect leave limits from being reported. This fix improves the reliability of our leave management system.
Original PR description
Issue: ----------------------------------- At certain times of the day (e.g., around midnight UTC), the test would fail deterministically ``` test_allocation_stats_with_duplicate_leave_type_names…
Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```
Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)
At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.
Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.
Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680This update fixes a limitation in the accounting settings where the 'Deferred Expense' field only showed current asset accounts. Now, it correctly includes prepayment accounts, ensuring users can accurately categorize deferred expenses. This improves the accuracy of financial reporting and simplifies expense tracking.
Original PR description
Problem: The deferred expense account field only allowed to select from current asset accounts, but it should also allow prepayment accounts. Steps to reproduce: 1. Install Accounting app 2. Go to Accounting > Configuration > Settings 3. In the "Deferred expense" section, try to select an account in the "Deferred expense" field and see that only current asset accounts are available. Cause: The domain on the deferred expense account field only included current asset accounts. opw-6134576
This update resolves a technical issue where a test was incorrectly marked as commented instead of updated in the recent code changes. The fix ensures that the test is properly updated, maintaining the integrity of the Belgian Coda integration for financial reporting. This prevents potential disruptions to the accounting process.
Original PR description
Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none
This update ensures that when you refresh a timesheet record after searching, the correct, specialized form view is displayed. Previously, a generic form view was shown, causing confusion. This fix guarantees a smooth and accurate experience when managing timesheets.
Original PR description
…m view * Go to Timesheets > My Timesheets > switch to Grid view. * Hover over a cell with a timesheet entry and click the magnifier (search) icon. * The list opens; click a record to open its form view. * Observe the URL: `/odoo/timesheets/account.analytic.line/<id>`. * Refresh the page (F5). Before this commit, the generic form view was shown instead of the timesheet-specific form view. This occurred because, when reloading a page with a dynamic action and a resId, a generic view layout [false, "form"] was requested instead of the action-defined view. Now, the dynamic action is properly restored on refresh, ensuring the correct specific view is loaded for the form. opw-6133602
This update ensures all date displays in the Point of Sale module consistently use Odoo's standard format. Previously, dates were displayed based on the user's device, leading to potential inconsistencies. This change improves clarity and accuracy for sales reports and receipt printing.
Original PR description
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already…
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69). As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. After this commit: --- <img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" /> All date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259112
This update fixes a bug that allowed users to add a product template as an optional product on itself during import. This caused errors when creating sales orders. The change restricts the system to prevent this scenario, ensuring data integrity and preventing order creation issues.
Original PR description
Issue: --- Due to this issue, a product template can be added as an optional product on itself by using import feature. Steps to reproduce: 1- Import a product using sheets. 2- Re-import it again and this time set `optional_product_ids` the same value as `external_id` in the sheet. 3- Navigate to the product template form and you can see the same product template is added to optional products of the product template. If you create a SO using the product, an error will be raised. This can be prevented by a domain restricting to set this product as optional products. opw-6150049
This update resolves an error that occurred when users removed the date field in the Accrued Expense Entry wizard. The fix adds a check to ensure the date field has a valid value before performing comparisons, preventing a type error. This ensures the Accrued Expense Entry functionality remains stable and reliable.
Original PR description
Currently, error occurs when user removes date on Accrued Expense Entry wizard. Steps to replicate: - Install `purchase` and `accountant` with demo. - Open any Purchase Order > Click on cog menu >…
Currently, error occurs when user removes date on Accrued Expense Entry wizard.
Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.
Error:
```
File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
if not record.reversal_date or record.reversal_date <= record.date:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'
```
Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.
Solution:
- Added a conditional check for `date` before the date comparison.
[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the generic tax report wouldn't display an error when the reported net value was negative. The fix ensures that the report accurately checks for discrepancies in tax amounts, even with negative balances, preventing misleading results.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350
This update fixes a bug where adding serial numbers to outgoing picking when the quantity is zero could lead to incorrect quantity counts. Now, only the manually added serial numbers are correctly applied, ensuring accurate tracking of stock movements. This prevents discrepancies between the number of serial numbers and the actual quantity shipped.
Original PR description
**Problem**: When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few…
**Problem**: When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers. **Before this commit:** If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving. **After this commit:** Only SN-002 and SN-003 will be added to the move, which matches the quantity. **Steps to reproduce:** 1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product. 2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0. 3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking. 4. SN-001 will be added to the move automatically, but the quantity stays at 2. opw-6121208