Daily updates from Odoo
Friday, March 13, 2026
13 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where sales order margins were incorrectly calculated due to a misunderstanding of the product's cost method. The fix ensures margins are accurately determined based on the company associated with the sales order line, regardless of the user's default company setting. This improves margin reporting accuracy.
Original PR description
Steps to reproduce: - Have 2 companies: - Company A with a property_cost_method 'average' - Company B with a property_cost_method 'standard' - Create a sales order in B - Set the default company of the user to A. - Under certain scenarios, when we confirm the sales order, there will be a `flush_all`. - When that's the case, margins are recomputed with `line.product_id.categ_id.property_cost_method` as `average` instead of `standard`. In other words, it will take the property_cost_method from the `user.company_id` (A), instead of the property_cost_method from the `line.company_id` (B). This fix ensures the `property_cost_method` considered is the one related to the company of the sale order line. A similar issue was fixed on https://github.com/odoo/odoo/pull/192890 OPW-5939464
This update resolves a minor typographical error in the help text associated with the 'Country State' field within the Odoo system. The misspelling of 'Departement' has been corrected, ensuring accurate and consistent user guidance. This change improves the overall user experience and data integrity.
Original PR description
Fixes #202198 Split from #249963 per reviewer feedback. **CLA sign-off:** Individual CLA signed (doc/cla/individual/vedantmadane.md)
This update resolves an issue where the copyright background color wouldn't display correctly on the website footer when no specific background color was set. The change adds a fallback value to ensure the copyright color is always visible, regardless of the footer's background color. This improves the website's appearance and consistency.
Original PR description
Before this commit, a css error would happen when the user tried to change the copyright background color if the footer had no background color.
This was due to $-footer-color not having a fallback value when neither o-color('footer-custom') nor o-color('footer') was defined.
This commit adds a fallback value to fix the issue.
task-5452457This update optimizes the validation process for purchase orders with many associated stock moves. By batching operations, the system reduces unnecessary database trips and improves performance, particularly for large deliveries. This results in faster order processing and a better user experience.
Original PR description
Before this PR, `button_validate` was using a `write()` call per matched stock move. On every `write()` there is a Command.create and Command.delete which is resulting in N database round-trips for the unlinks and N for the creates, followed by N separate `_apply_putaway_strategy()` calls. This is problematic for pickings with many move_ids. This PR attempts to accumulates all move lines to delete and to create. Then performs a single `unlink()` and `create()`, followed by a single `_apply_putaway_strategy()` for all pickings. Unlink is done using `.sudo()` to preserve the superuser context that was previously inherited implicitly through the `purchase_order.sudo().search` that produced the recordset used to obtain the `receipt_move`(s). Benchmarks: | No. move lines in delivery | Before | After | | -------------------------- | ------- | ----- | | 7579 | Timeout | < 200 s | opw-5826905
This update corrects a bug where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger. This prevents inaccurate reporting and ensures data consistency.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999
This update addresses a technical issue within Odoo's Instagram integration that could cause error code 9004. The fix provides clearer explanations for this error, helping users troubleshoot problems on their Odoo servers without needing to contact support. This improves the overall user experience and reduces support requests.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#109319
This update resolves an issue where portal users assigned to individual contacts within a company couldn't post messages on related opportunities. The fix ensures that users always have the correct access rights by using the company's record instead of the contact's record, allowing them to perform actions like posting messages.
Original PR description
When a portal user is set on an individual contact belonging to a company, posting a message on an opportunity assigned to that company fails with an access error. ### Cause Before creating a…
When a portal user is set on an individual contact belonging to a company, posting a message on an opportunity assigned to that company fails with an access error.
### Cause
Before creating a mail.message, `_get_mail_message_access` is called to determine the ORM access level the user must hold on the document. The override for `crm.lead` returns `'read'` (sufficient for portal users) when the user is the assigned partner, checking:
lead.partner_assigned_id == self.env.user.partner_id
`partner_assigned_id` is the company set as the assigned partner. `user.partner_id` is the contact record of the logged-in user. When the portal user is an individual contact whose parent is the assigned company, the two records differ, the condition is False, `'write'` is required, and the portal user does not have it.
### Fix
Replace `user.partner_id` with `user.commercial_partner_id`, which always resolves to the top-level company regardless of whether the user is the company contact or one of its child contacts. This is consistent with `_assert_portal_write_access` in the same file, which already uses `commercial_partner_id` for the same reason.
opw-5913214This update fixes an issue where tax calculations in Point of Sale sessions were incorrect due to how taxes were grouped. The code now sorts taxes by company ID before grouping, ensuring that all taxes for a specific company are processed together and assigned accurately. This improves the reliability of tax calculations during sales transactions.
Original PR description
itertools.groupby only groups consecutive elements. When taxes from different companies are interleaved in loaded_data, taxes from the same company get split into multiple groups, causing incorrect tax assignment per company. Sort the tax list by company_id before calling groupby to ensure all taxes per company are contiguous. opw-5931261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the cost of kit products on sales orders was incorrectly calculated. Previously, kits with multiple components were multiplied by the batch size, leading to inflated costs. The fix ensures accurate cost calculations for kit products by normalizing the cost based on the kit's quantity.
Original PR description
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30. ### Cause: The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`. ### Steps to Reproduce: - Costing Method = AVCO, Inventory Valuation = Automated - Comp A (cost 10), Comp B (cost 20), Kit X (cost 0) - Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B - Create and confirm a SO for 1 x Kit X - Expected SO line cost: 30 - Actual SO line cost: 360 Solution: This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs. opw-5969310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where tax calculations in reports related to Indian GST were sometimes inaccurate. The change ensures that taxes are only applied to invoices that have been fully processed (posted) within the system, improving the reliability of the generated reports. This ensures accurate reporting for tax compliance.
Original PR description
if bill is not available then we also create new bill without line so we check taxes only on posted one
This update fixes an issue where delivery DDTs incorrectly displayed the full sales price of kit components instead of the component's individual value. The change ensures that kit BOMs are accurately reflected in the delivery reports, providing more precise cost information for IT companies. This resolves a discrepancy in reporting that impacted financial accuracy.
Original PR description
Steps to reproduce: - Have an IT company setup - Create a product with a Sales Price and define a kit BOM with 2 components - Create SO with product - Confirm, go to delivery, validate - Print Issue: In the delivery DDT, there is a summary of the delivery where each item has its own entry (product, quantity, value). However, in case of kit BOM, each component is reported with the full value of the sale operation. Analysis: This occurs because in the report code we don't consider the possibility of kit products, where multiple components are associated to the same sale line. Ticket [link](https://www.odoo.com/odoo/project.task/5013606) opw-5013606
This update resolves an issue where long tax amounts on invoices were causing display problems. The change ensures that tax totals are accurately and clearly presented, regardless of the numerical value, improving invoice readability and accuracy for users. This addresses a minor display issue impacting invoice reporting.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891
This update fixes an issue where UBL charges weren't being accurately reflected on invoices in version 17.0+. The fix ensures charges are correctly added to the invoice line price, resolving a situation where invoice prices were incorrectly set to zero. This improves the accuracy of invoice calculations and reporting.
Original PR description
# How to reproduce Import in a Vendor Bill an UBL document with InvoiceLines the following properties (the linked ticket has an exemple document) : - The PriceAmount of Item is set to 0 - There are…
# How to reproduce Import in a Vendor Bill an UBL document with InvoiceLines the following properties (the linked ticket has an exemple document) : - The PriceAmount of Item is set to 0 - There are multiple positive and negative AllowanceCharges - The sum of the AllowanceCharges is correctly equal to the LineExtensionAmount # The problem The issue depends on the version, for 17.0+ it is as follows : The AllowanceCharge are NOT added to the invoice as invoice lines, contrary to later versions. Instead they are used to compute the discount of the invoice line but when that discount cannot be applied, they are then ignored. In our case, this makes it so every invoice line has a price of 0, coming from PriceAmount of Item. This issue is funnily enough most of the time resolved by another issue. Indeed, in the unit price calculation for the invoice line, there is a fallback for bad xml that sets the unit price to the subtotal (the right amount in our case). This fallback is based on a condition that compares two floats using the != operator. Due to the floating point imprecision, the fallback is trigerred randomly. In the end, some invoice lines have a price unit of 0 (when the fallback is NOT trigerred) and some others have the correct price unit (when the fallback is trigerred). Correcting the floats comparison would correctly make it so the fallback is never trigerred (since our xml is good), setting the price unit of all the invoice lines to 0. So we also need to add the AllowanceCharge in the calculation of the price unit. opw-5926387 Related to : https://github.com/odoo/odoo/pull/250323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr