Daily updates from Odoo
Thursday, January 8, 2026
15 changes · 18.0
Enhancements to existing features
This update modifies the chart of accounts for Odoo's Vietnamese localization to align with recent accounting regulations (Circular 99/2025). This change is necessary to ensure compliance with Vietnamese tax laws, taking effect in January 2026. It impacts financial reporting within the Odoo system for Vietnamese businesses.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the longpolling controller by adding detailed logging and performance monitoring. These changes improve the stability and efficiency of the system, ensuring smoother operation and faster response times. This is a key improvement for overall system performance.
Original PR description
This PR adds logging and performance check for the longpolling controller Related PR for >= saas-18.3: https://github.com/odoo/odoo/pull/241467 Forward-Port-Of: odoo/odoo#241469
This update adds crucial data attributes to Odoo's tax calculations and NFS-e submissions when the Brazilian fiscal reform is active. Specifically, the system now includes 'name', 'businessName', 'federalTaxId', and 'type' fields, ensuring accurate tax reporting and compliance with new regulations. This change improves the reliability of Brazilian tax processing.
Original PR description
Purpose: Additional attributes are required to be sent in the rendered node for tax calculation and NFS-e submission when the fiscal reform is enabled. The additional required attributes are: - name - businessName - federalTaxId - type task-5450129 Forward-Port-Of: odoo/enterprise#103438
Resolved issues and error corrections
This update fixes an issue where inline code blocks were difficult to remove, particularly at the end of list entries. It also addresses problems with cursor placement and empty code block removal, ensuring a smoother and more reliable editing experience for users. These changes enhance the overall usability of the Odoo web editor.
Original PR description
Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140 Forward-Port-Of: odoo/odoo#238552
This update fixes a problem where customers on one website could access and pay through payment providers enabled only on a different website. The fix ensures that payment providers are correctly filtered based on the customer's website, preventing incorrect payment options from appearing in the sales portal. This improves the customer experience and ensures accurate payment processing.
Original PR description
[FIX] website_sale, adding website_id in portal controller Version: 17.0+e Steps to reproduce ------------------ The database has two different websites. A payment provider is enabled for just one of…
[FIX] website_sale, adding website_id in portal controller Version: 17.0+e Steps to reproduce ------------------ The database has two different websites. A payment provider is enabled for just one of them (website1). When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1. The problem also occurs when previewing the customer’s portal view. Why it's happening ------------------ When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions. As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible. The Fix ------- We now add the current website's id to the method if none has been added before. opw-5172444, “Payment provider visible on sales order portal" --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235954
This update resolves an issue where Manufacturing Orders weren't being created correctly when using the Barcode app. The fix ensures that necessary data is properly set before creating the order, preventing errors related to Stock Move Lines. This improves the reliability of the manufacturing process.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163 Forward-Port-Of: odoo/enterprise#98440
This update resolves a sporadic error in how Odoo calculates taxes based on base amounts. The issue stemmed from an unordered set of allowed tokens used during formula evaluation, leading to inconsistent results. This fix ensures accurate tax calculations by addressing the random iteration order of the allowed tokens.
Original PR description
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the…
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this: There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this: (base >= 100) and (base * 0.05) or (base * 0.07) <img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" /> This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100. This formula will work sometimes, but sometimes, it will fail with this error. <img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" /> The position of the error is the '=', because the '=' is not a valid token in this list: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10. The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error appears sometimes? So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127 sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle. When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail. But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail. You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error. The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done. 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 account balances weren't accurately reflecting transactions across a company's branch hierarchy. By changing the filtering logic to include child companies, the balance calculations now correctly aggregate balances from all branches, providing a more complete and accurate view of financial data. This ensures consistency with other Odoo accounting features.
Original PR description
Description of the issue/feature this PR addresses: This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a…
Description of the issue/feature this PR addresses:
This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a parent company should be able to see the aggregated balances of its child branches. Currently, the strict equality operator prevents this consolidation, creating a discrepancy between the expected "Global" view and the displayed balance.
Current behavior before PR:
The _compute_current_balance method in account_account.py uses the = operator for the company_id domain: domain=[('account_id', 'in', self.ids), ..., ('company_id', '=', self.env.company.id)]
This restricts the balance calculation exclusively to the current active company, excluding any transactions made in its branches (child companies), even when the user is positioned at the parent level.
Desired behavior after PR is merged:
The operator is changed to child_of. When a user is in a parent company/branch, the current_balance of the account will include the sum of all journal entries from that company and all its descendants in the hierarchy. This ensures consistency with how other parts of Odoo (like https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/account_followup/models/res_partner.py#L230) handle company-related domains.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue preventing PEPPOL invoices with cash rounding from passing XML validation. The fix removes a blocking XML node related to cash rounding, ensuring accurate invoice creation and transmission. This ensures compliance with PEPPOL standards for invoices with cash rounding.
Original PR description
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash…
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: Add a rounding line - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding 6. Confirm & Send (with PEPPOL) Current Behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€ - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€ - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax" - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `BR-E-08`: "In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount BT-116 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT"" Expected behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ Solution: Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines. https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals As invoice lines should contain their item name. Rounding line won't have one. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/ As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information. https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310 As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order. This commit also: - fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08). opw-5434335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that customers purchasing event tickets through POS are accurately registered as attendees. Previously, information wasn't consistently captured, leading to inaccurate registration data. This fix aligns the POS registration process with the website's behavior, guaranteeing consistent attendee tracking.
Original PR description
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks…
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks for name but is not required * Open pos and sell on ticket * Do not put name info * Select a customer for the order * Validate order * Check registrations > Observation: The customer is not registered as the attendee Why the fix: ------------ We compare the scenarios with the same flow but from website registrations. On the website if there is no user registered: - If information is not filled, nothing will be registered on the registration - If information is filled it will be used to populate attendee fields If there is a user registered while on website: - If no information is filled, attendee fields will be populated with the data from the connected user - If information is filled, it will be used for attendee fields - If partial information is filled, it will be used for attendee fields but will also be completed with data coming from the connected user To achieve the same behavior from the pos we first need to register the customer as the partner for the event. During event creation we also remove values regarding attendee name, email, phone and company if they were not provided during the order. From the website they are not used during creation if they were not given by the customer. However, in the pos this information is present anyway (as empty string or False) as they are fields on the model "event.registration" and are still send to the backennd even if we remove the information here https://github.com/odoo/odoo/blob/787621e44a9cef30469849929df267cae9e977f2/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L127 We do the fix server-side as a fix in the frontend would not be as straightforward. A customer might be on the order before selecting event ticket and it's easy but one might also add the customer after the ticket was selected. opw-5137197
This update corrects a bug that incorrectly flagged some bank statements as invalid, even when they were accurate. The fix adjusts how statement validity is calculated, ensuring that all statements are properly recognized as valid based on their balances. This improves the reliability of bank reconciliation within the accounting module.
Original PR description
Some bank account statements are computed as not valid, although they are valid. Statement 1 and 3 appear, and statement 3 is shown as invalid, while both statements should be shown as valid. Statement validity is computed depending on previous statement end balance and current statement start balance. The SQL query uses a window function to retrieve the previous statement. However, the function is applied after the WHERE clause. Therefore, it uses the end_balance of the previously selected statement instead of the previous statement. #### Step to reproduce: - In the bank dashboard of the accounting app - Create journal entry 1 - Create statement 1 - Create journal entry 2 - Create statement 2 - Validate the journal entry 2 - Create journal entry 3 - Create statement 3 - filter statement per "Not Matched" Ticket [link](https://www.odoo.com/odoo/project.task/5341433) opw-5341433 Forward-Port-Of: odoo/odoo#238381
This update corrects a bug where delivery fees weren't accurately calculated when sales orders and company currencies differed. The fix ensures that delivery fees are correctly priced based on the sales order's currency, preventing discrepancies in pricing displayed to customers. This improves financial accuracy and reduces potential errors in delivery costs.
Original PR description
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in…
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate. Sell for 15 EUR of products => the delivery picking shows 10 EUR Steps to reproduce ----- - Activate EUR currency at 1.5 EUR = 1 USD rate - Setup company in USD - Setup INTL FEDEX delivery method - Create a dummy product with a 10 USD sale price - Create a pricelist using the EUR currency - Create a sale for some INTL client - set pricelist to EUR - add dummy product - add INTL FEDEX shipping - confirm the sale - Confirm the linked delivery > Message in chatter shows a price of 10 EUR instead of 15 EUR Cause ----- The problem is with the `carrier_price` field of `stock.picking`. https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21 The value is set by https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155 which gets its' value from the response of https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157 We then go through https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382 where we call https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484 The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598 we should also filter to ensure the rate matches the order's specified currency. ----- Ticket: opw-5419724
This update prevents the automatic cancellation of post-production pickings when a backorder is cancelled in multi-step production routes. Previously, cancelling a backorder would also remove the 'ready' picking. This change ensures that pickings are only cancelled if no related production orders have been completed, improving order accuracy and reducing unnecessary disruptions.
Original PR description
Issue ----- For multi step routes, cancelling the backorder MO also cancels the (post -> stock) picking for the produced quantity. Steps to reproduce ----- - Activate routes - Go to the main warehouse and activate 3 step production - Creation of a MO for 100 units - Validate the pre production picking - Produce 40 units and create a backorder for remaining quantity - Cancel the backorder > The "post -> stock" picking is cancelled as well Cause ----- The picking is in "ready" state, so it gets cancelled by https://github.com/odoo/odoo/blob/083d53c688a0d18a1f4594b9fcbbfa738aa5e86d/addons/mrp/models/mrp_production.py#L1743-L1744 Desired behaviour ----- > Only cancel related MO pickings (pre prod/post prod) if no MO (or MOs) done yet. Don't cancel related MO pickings if any MO validated. ----- Ticket: opw-5405024
This update fixes an issue where purchase taxes weren't correctly applied to purchase orders created from purchase agreements in child companies. The fix removes a company-specific filter in the tax mapping process, ensuring that taxes associated with the parent company are now accurately applied to child company purchase orders. This improves tax accuracy and reporting across the Odoo system.
Original PR description
### Issue: In a child company, adding a product from a Purchase Agreement to a Purchase Order does not apply the associated parent company's purchase taxes ### Cause: In the onchange, taxes were filtered by company: ```python taxes_ids = fpos.map_tax(line.product_id.supplier_taxes_id.filtered(lambda tax: tax.company_id == requisition.company_id)).ids ``` This filter fails for taxes belonging to the parent company, so they were not applied on the child company purchase order ### Steps to reproduce: - Create a company branch and switch to it - Enable `Purchase Agreements` in Settings - Create a product with a Purchase Taxes (ex. 15%) - Create a Purchase Agreement for any vendor with this product - Create a RFQ for the vendor and add the agreement - Observe that the tax is not applied opw-5121243
This update resolves an issue where the height of image gallery snippets would unexpectedly reset when images were reordered. The fix removes outdated code that forced a 70% screen height and now allows users to set and maintain custom heights through the snippet's settings. This ensures consistent image gallery display.
Original PR description
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The…
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281 Forward-Port-Of: odoo/odoo#126766