Daily updates from Odoo
Friday, May 8, 2026
19 changes · saas-18.3
Resolved issues and error corrections
This update resolves a problem where invoices weren't correctly processing extra components within kit products. Specifically, the system incorrectly handled unit of measure discrepancies during invoicing, leading to errors. This change ensures accurate invoicing for kit products with multiple components.
Original PR description
### Steps to reproduce: - In the settings Enable: "Automatic accounting" - Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time')…
### Steps to reproduce:
- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.
### Cause of the issue:
The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34
opw-6041375
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141This update fixes a UI issue where the change amount displayed to customers was incorrectly shown as a positive value. Now, change amounts are displayed as negative, accurately reflecting the money leaving the store. This ensures accurate financial reporting and a better customer experience.
Original PR description
Steps to Reproduce ------------------------ - Install point of sale. - Do a order and pay more than the amount. Issue ------ - The change amount is displayed as a positive value on the UI. - Typically, amounts going out of the shop (like change given to the customer) should be shown as negative. Cause ------- - The change amount was not correctly represented in the UI. - Since the change flows in the opposite direction of the payment, it should be displayed as the negation of the original amount. FIX ----- - Updated the frontend to display the change amount with the correct (negative) sign. - No backend changes were required, as the correct value was already being handled during order synchronization Enterprise PR: https://github.com/odoo/enterprise/pull/112560 task: 6074620 Forward-Port-Of: odoo/odoo#263122 Forward-Port-Of: odoo/odoo#256776
This update fixes a visual issue in the Point of Sale (POS) system where the change amount was not displayed with the correct negative sign. The change ensures that customers accurately see the amount of change they receive, improving the user experience and preventing potential errors.
Original PR description
In this commit: --------------- - The tours are updated to adapt the change as now frontend display the change amount with the correct (negative) sign. Community PR: https://github.com/odoo/odoo/pull/256776 task: 6074620 Forward-Port-Of: odoo/enterprise#116441 Forward-Port-Of: odoo/enterprise#112560
This update resolves two issues impacting the export of sales data for DIAN compliance in the POS system. Specifically, a validation error during order processing and a problem downloading the Sales Details report have been corrected. The fix ensures accurate data generation and report availability.
Original PR description
Steps to reproduce: --- - Install `l10n_co_edi_pos` and configure it. - Set the POS Serial Number in the POS configuration. - Open a POS session, create an order, and validate it. Issues: --- 1. A traceback occurs while validating the order. 2. After fixing the above issue, another traceback occurs when downloading the Sales Details report from the backend. Causes: --- 1. During UBL DIAN data generation, the `name` field is overwritten with `pos_order.l10n_co_edi_pos_name`, which can be empty. 2. `l10n_co_edi_pos_serial_number` is accessed on an invalid type (ID/list instead of a recordset). Fixes: --- - Preserve the original `name` if `l10n_co_edi_pos_name` is not set. - Ensure `config_ids` is always a recordset and safely compute serial numbers using `mapped`, joining unique values. task-6051285 Forward-Port-Of: odoo/enterprise#111306
This update resolves an issue where deleting menus in the Odoo 18.3 system caused a critical error. The fix ensures the system gracefully handles the absence of menus, preventing data loss or system instability. This improves overall system reliability and data integrity.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist. 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
This update fixes a bug in the Sale Timesheet module that occurred when certain menus were deleted from the database. The change ensures the system correctly identifies and handles the absence of these menus, preventing errors and maintaining stability. This resolves an issue that could have impacted users' ability to access and utilize the Sale Timesheet functionality.
Original PR description
to reproduce issue: 1) make a database in 18.3 . 2) delete the menu/menus. 3) it will fail on _load_menus_blacklist.
This update fixes an issue where refund payments were incorrectly routed to the wrong accounts, leading to inaccurate journal entries. The change ensures that inbound and outbound payments use the correct accounts, resulting in accurate financial reporting for point-of-sale transactions. This improves the reliability of our accounting data.
Original PR description
Step to reproduce: - we need a session, where in total, we gave out money (when we refund) - for this, start a pos session, do a order, pay using bank and close session - restart the pos, refund the order, and pay using bank, close it. - go to accounting > customer > payment - open payment for both session Observation: - in journal entries for both payment, amount is credit into `account_receivable` and debit from `outstanding account` Cause: - commit[1] swaps accounts when we have outbound payments, which is functionally incorrect and lead to this issue. [1] https://github.com/odoo/odoo/commit/844d2960af6b2cdd8620eb1681bda03dd48a97e4 Fix: - do not swap accounts between `outstanding` and `destination` accounts. Expected after fix: - Inbound and outbound payments use the same accounts - Journal entries are correct: - Inbound: debit outstanding, credit account_receivable - Outbound: reverse of inbound entries opw-6044883 Forward-Port-Of: odoo/odoo#256258
This update fixes a bug where Colorado state income tax calculations resulted in a positive value on payslips, which incorrectly indicated a refund instead of a withholding. The fix aligns with established payroll tax rules, ensuring accurate withholding of state income taxes. This ensures correct payroll processing for Colorado-based employees.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#116305
Forward-Port-Of: odoo/enterprise#112724This update fixes a bug in the Belgium Payroll DMFA report that incorrectly displayed 'Days Per Week' as 5 when employees worked fewer than 5 days. The fix ensures the report accurately reflects the employee's actual working schedule, improving the accuracy of tax reporting.
Original PR description
## Issue When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5. ## Steps to reproduce 1. Install…
## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.
## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
- set *ONSS Registration Number* to `0830123456`
- set *DMFA Employer Class* to `083`
- create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
- Work from 8:00 to 12:00
- Lunch from 12:00 to 13:00
- Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
- In the *Payroll* tab, set the start date of the contract to 01/01/2026.
- In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**
## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.
opw-6103934
Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804This update fixes an issue where changing the delivery date for Hungarian invoices caused incorrect journal entries due to outdated exchange rates. The fix ensures that the correct exchange rate is applied when the delivery date is modified, preventing financial discrepancies and maintaining accurate accounting records.
Original PR description
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause:…
### Issue: When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries ### Cause: `expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines: https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031 https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637 These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently As a result, when the base amount increases, the tax amount decreases, and vice versa ### Steps to reproduce: - Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company` - Go to Currencies → USD and add two rates: April 5: HUF per Unit = 100 April 6: HUF per Unit = 150 - Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%) - Open the Journal Items and duplicate the browser tab for comparison - In the duplicated tab, change the Delivery Date to April 5 and save - Change the Delivery Date back to today and compare both tabs ### Before the fix: The values differ between both tabs because the tax lines keeps the old exchange rate opw-5801126 Forward-Port-Of: odoo/odoo#258310
This update corrects inaccuracies in the data files used for payroll calculations in Belgium (l10n_be_hr_payroll_prisma). Specifically, it addresses missing rules for leave types (LEAVE280 and LEAVE115) related to work accidents and occupational diseases, ensuring more accurate reporting.
Original PR description
Issue: ---------------------------------------- Some prisma codes are wrong. Solution: ---------------------------------------- Change the data files. There are some subtilities that were not implemented: - LEAVE280: 0304 (if less than a year) and 0345 (if more) - LEAVE115: 0820 (Work accident) and 0830 (Occupational Disease) opw-6090081 Forward-Port-Of: odoo/enterprise#112949
This update fixes an issue where some UBL invoices were being processed incorrectly. The system now intelligently checks for a specific customization ID to identify UBL invoices, preventing errors and ensuring proper invoice handling. This improves the reliability of our UBL invoice processing.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263349 Forward-Port-Of: odoo/odoo#263285
This update corrects a misleading validation error that appeared when using the translation button on Sale Order Templates. Previously, the system incorrectly flagged a missing `sale_order_template_id` instead of highlighting the required field. This change ensures the system correctly handles nested records, improving the user experience when translating templates.
Original PR description
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing…
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing validation error appears for missing `sale_order_template_id` Issue: * Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id` Cause: * `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead. Affected Version: 17.0 Before: <img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" /> After: <img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262988 Forward-Port-Of: odoo/odoo#262755
This update fixes an issue where the navbar menu items and app icon would disappear when users zoomed out or increased the screen width in mobile view. The change ensures the navbar dynamically adjusts to display the full menu and icon when sufficient screen space is available, improving the user experience.
Original PR description
**Issue:** In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear.…
**Issue:** In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout. **Fix:** The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes. **Before:** After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden. **After:** When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected. opw-6107660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263296 Forward-Port-Of: odoo/odoo#263039
This update fixes an issue where tax returns were incorrectly including all tax amounts, regardless of the specific region (e.g., British Columbia). Now, tax return entries accurately reflect taxes related to the correct tax jurisdiction, ensuring accurate reporting for businesses using Odoo's tax return functionality. This improves the reliability of tax reporting across Canada, Ecuador, Egypt, Pakistan, and South Africa.
Original PR description
Issue: Validating a tax return creates an entry with all the tax aml from the company instead of filtering them according to the tax return type. Steps to reproduce: - In a company in Canada - Invoice a Customer from British Columbia in the previous month (A) - Confirm - Go to tax report -> Return - Review and Validate tax return for "Manitoba PST Return (CA)" for month A - Click on the 3 dots -> View Entry Current Behavior: - Entry has lines for PST in British-Columbia and GST taxes Expected behavior: - Entry has lines for PST in Manitoba only Cause: https://github.com/odoo/enterprise/pull/98158 introduces method `_get_vat_closing_entry_additional_domain` in the wrong class. opw-6065838
This update resolves an error that occurred when searching for links (short URLs) within the email tracking system. Previously, searching by short URL resulted in a server error. The fix addresses the technical issue of searching a computed field and ensures the search functionality now works correctly.
Original PR description
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing…
Overview ------ When searching based on the `Link (short_url)` field in the search bar, in the `link.tracker.click` list view, an error fires up. How to Reproduce ------ 1. Open the Email Marketing app 2. Create a new mailing (or you can use an existing one that has some clicks) and send it 3. Make a click in the email from the recipient's side 4. Open the link tracker `click` related to that mailing (select the mailing → `Link Trackers` stat button → click on a link → `Clicks` stat button) 5. Make a search based on the Link (short_url) field Expected Behavior ------ Return the list of links that matches the entered search query. Current Behavior ------ Odoo Server Error. Cause & Solution ------ The cause of this error is that the `shor_url` field is a computed, non-stored, field, and hence, we cannot directly make a search on it. So, either we make the `short_url` a stored field, which is not so efficient, or we create our own custom `_search_..` method. Task-6131693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash in the website editor that occurred when an event was set as the homepage. The issue stemmed from a missing match in the event ID retrieval process. By adding a default return value, the editor now correctly identifies event objects, ensuring a stable experience for users managing their website events.
Original PR description
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the…
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage. In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67). **Steps to reproduce bug:** 1. Create an event website 2. Create an event and visit it 3. On the page click Site > Properties 4. Enable `Is Homepage` 5. Return to the homepage of the application and open the editor https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link **Current behavior before PR:** https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link opw-6101680 Forward-Port-Of: odoo/odoo#258502
The customer list view was displaying incorrect total calculations (showing dashes instead of numbers) when certain columns were enabled. This fix ensures that total due and overdue amounts are accurately calculated and displayed, providing reliable financial reporting. The change was made to properly format currency data within the list view.
Original PR description
In the partner list view, enabling the "Total Due" and "Total Overdue" columns results in empty aggregates (—) at the bottom of the list. Steps to reproduce: - Navigate to Accounting -> Customers -> Customers - Add columns 'Total Due' and 'Total Overdue'. - Check the computed totals. Issue: The totals displays dashes (—) instead of the numbers. Analysis: The web client list renderer requires a currency field to be present in the view to correctly format and display aggregate sums for monetary fields, otherwise empty dashes are shown as fallback. opw-6169513 Forward-Port-Of: odoo/odoo#261820
This update resolves an error in the FAIA report XML export for Luxembourg customers. The issue stemmed from a missing 'TVA' TaxType element, which was required by the report's specifications. This fix ensures accurate report generation and avoids potential export failures.
Original PR description
This is one of several commits fixing the FAIA xml export. The customer in ticket [opw-5427296](https://www.odoo.com/odoo/unassigned-tasks/5427296) received several errors which mention that the `TaxType` element should be 'TVA'. This is corroborated by one of these elements in the XSD files for the FAIA report. The XSD files can be found at the link below. https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-6118272 [link](https://www.odoo.com/odoo/project.task/6118272) Forward-Port-Of: odoo/enterprise#115293 Forward-Port-Of: odoo/enterprise#113720