Friday, May 8, 2026
10 changes · saas-18.3
Enhancements to existing features
This update ensures Odoo can correctly process Brazil's new alphanumeric CNPJ format for company registration. The Brazilian government is transitioning to this format to avoid registration limits, and this change updates Odoo's validation process to accommodate the new standard. This ensures accurate data processing for Brazilian businesses.
Original PR description
Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its…
Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its capacity to generate new CNPJ numbers. The current, exclusively numeric model is approaching its limit. The transition to a format that includes letters and numbers expands the number of possible combinations, ensuring the future availability of registrations for new companies. With the government expanding the CNPJ numbers, we need to implement a solution to support the alphanumeric CNPJ that will be issued starting July 2026. Current Behavior: The method, `is_valid,` from stdnum is currently used to determine whether the CNPJ is valid or not. This is now considered an outdated method to determine the validation. Changed Behavior: The new validation logic by stdnum, found here https://github.com/arthurdejong/python-stdnum/commit/d3ec3bd7fefe0d0a708b6594a66de28777eb9b8d, is patched into `check_vat_br.` The reasoning for patching this rather than calling stdnum is because using stdnum will cause library dependency issues for older versions of Odoo. task-5234869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262654 Forward-Port-Of: odoo/odoo#260516
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 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 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 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 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