Friday, January 9, 2026
10 changes · saas-18.3
Enhancements to existing features
This update adjusts the Vietnamese accounting chart of accounts to align with new regulations (Circular 99/2025) issued in January 2026. This change ensures compliance with current Vietnamese accounting standards and is a necessary update for accurate financial reporting in Vietnam.
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 Forward-Port-Of: odoo/odoo#242907 Forward-Port-Of: odoo/odoo#238983
Resolved issues and error corrections
This update resolves an issue where canceled orders and their items were incorrectly displayed in new orders, particularly with online payments. The fix ensures that canceled orders and line items are fully removed from the system's data storage, guaranteeing accurate order displays and calculations.
Original PR description
`point_of_sale`, `pos_self_order` ### step to reproduce: - Configure self order with online payment. - Open POS Self Order. - Add some products to the cart. - Cancel the order. - Create a new order and pay it via an "online payment" method. - Click on "Order Now". ### issue: - Previously cancelled products reappear as selected in the new order. ### reason: - Cancelled orders and orderlines were not removed from IndexedDB. - With Pay after Meal, a second order on the same table reused the existing one, causing the product card, order widget, and cart to show quantity and total from the old order instead of the new changes. ### fix: - Ensure both the order and its orderlines are removed from indexeddb when cancelling an order. - Product/cart page must show changed quantity and amount. task: 5005174
This update fixes an issue where account balances weren't correctly reflecting transactions across a company's branch hierarchy. By changing the filtering logic to include 'child_of', the balance calculations now accurately aggregate balances from all companies, including child branches, providing a more complete and consistent view of financial data.
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-pr
Forward-Port-Of: odoo/odoo#242576This update fixes an issue where combo lines in the Point of Sale (PoS) system weren't accurately reflecting the selected product variants. The fix ensures that variant information is displayed on both the order confirmation and receipt screens, improving the user experience. The underlying issue was a misinterpretation of how combo configurations were being handled.
Original PR description
**Steps to reproduce:** - Create a combo including products with different variants - The variants should be set to "Instantly" - Go to PoS and click on that combo - When confirming, the lines do not…
**Steps to reproduce:** - Create a combo including products with different variants - The variants should be set to "Instantly" - Go to PoS and click on that combo - When confirming, the lines do not show the selected variant - The ticket on the receipt screen does not show it either **Why the fix:** We were trying to map the combo lines using the line's configuration, but the configuration did not always contain the needed information, in this case the attribute_value_ids. This happens because when clicking on a combo, we are setting the configuration as the configuration popup is displaying, meaning we do not know which variants are going to be chosen. Instead, we now access the correct variants using the current combo line directly if the configuration is not set. An existing test had to be changed because before this fix, as we did not care for variants in certain cases, we did not add the price_extra from the variant to the combo's price, which seems to be the behavior we want. opw-5392530
This update prevents the automatic cancellation of 'post -> stock' pickings when a backorder is cancelled in multi-step production routes. Previously, cancelling a backorder would also remove the completed picking. This change ensures that pickings are only cancelled if the related MO is fully completed, streamlining operations 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 Forward-Port-Of: odoo/odoo#239865
This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that tax calculations are handled correctly when creating these expense reports, preventing inaccurate accounting entries. This ensures consistent and reliable expense tracking.
Original PR description
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2. Confirm and generate the expense report. 3. Reset the expense’s journal entry to draft and add an analytic account on the first line. → An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited. ## Cause For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*. In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes. However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`. This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines. As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate. ## Solution Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`. **opw-5166707** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241545 Forward-Port-Of: odoo/odoo#233841
This update resolves a validation error that occurred when generating PEPPOL invoices with cash rounding enabled. The fix removes a problematic XML node that was causing issues with the invoice's UBL structure, ensuring invoices are correctly processed and validated against PEPPOL standards. This ensures accurate invoice generation and compliance.
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 Forward-Port-Of: odoo/odoo#241717
This update corrects a bug where purchase taxes weren't correctly applied to purchase orders when products were added from purchase agreements. The fix ensures that taxes associated with the parent company are now accurately reflected on child company purchase orders. This improves financial 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 Forward-Port-Of: odoo/odoo#242909 Forward-Port-Of: odoo/odoo#237114
This update resolves a problem preventing connections to IAP Codaclean, which is crucial for accurate financial reporting. The issue stemmed from a missing parameter in the system, now corrected to ensure seamless integration and data transfer for Belgian users.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id Forward-Port-Of: odoo/enterprise#103724
This change reverts a previous update that was causing problems when multiple companies used the same accounting entries. It ensures that account records are correctly linked to the appropriate company, resolving inconsistencies and improving data accuracy. This addresses an issue reported in our internal tracking system.
Original PR description
This reverts commit 7a2b03846f07dcf04743d745c7c942ea17721d0a. This commit created issues with account shared by multiple companies Forward-Port-Of: odoo/odoo#243081