Daily updates from Odoo
Tuesday, March 24, 2026
11 changes · 18.0
Resolved issues and error corrections
This update ensures that when scanning barcodes in batches, the correct lot is always used, regardless of the initial barcode serial number. Previously, the system incorrectly relied on the reserved serial number, leading to inaccurate inventory tracking. This fix guarantees accurate lot updates during batch processing.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#109671This update fixes an issue where project budget totals were incorrectly summing expense and revenue amounts. The fix adjusts how budget amounts are calculated, ensuring that expenses and revenues are accurately reflected in the project dashboard's total spending and allocation figures. This improves the accuracy of project financial reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131
This update ensures that attaching VAT documents to invoices is done as part of the same transaction as the invoice data update. Previously, this could lead to inconsistencies where the invoice was updated but the attachment wasn't, causing potential issues with VAT reporting. This change improves data integrity and reliability for Polish VAT compliance.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where employees with accrued Extra Hours were not visible on their Time Off dashboard. The fix adjusts how Extra Hours are calculated and displayed, ensuring accurate reporting of overtime allocations. This improves the visibility of employee time off data.
Original PR description
### Issue: When an employee has Extra Hours, they are not shown in the dashboard. ### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ## Cause: The extra hours are added in [`get_allocation_data()`](https://github.com/odoo/odoo/blob/5c3deb11627f4d6762c4994207bd582afb96f064/addons/hr_holidays_attendance/models/hr_leave_type.py#L35-L66), but then they are removed in [`get_allocation_data_request()`](https://github.com/odoo/odoo/blob/5c3deb11627f4d6762c4994207bd582afb96f064/addons/hr_holidays/models/hr_leave_type.py#L489) just before returning because `max_leaves` is zero. ### Solution: We also set `max_leaves` to `employee.total_overtime`. If the employee doesn't have any extra hours, then it will not display. opw-5925258
This update corrects a problem where downpayment invoices for orders with fixed taxes were incorrectly generated without associated tax lines. This prevented proper invoice formatting for Peppol, causing errors. The fix removes the problematic downpayment calculation related to fixed taxes to ensure accurate invoice creation.
Original PR description
When making a downpayment for an order containing product using fixed taxes, the downpayment invoice would contain line without tax associated This is an issue when sending these invoices to Peppol. Steps to reproduce: ------------------- * Create a fixed tax of 5€ * Set this tax on any product along another tax * Create a sale order for this product * Make a downpayment of 10% * The invoice created has a line without any tax set > Observation: When sending to Peppol we get an error Why the fix: ------------ We remove the downpayment part that concerns fixed tax to avoid having lines without tax set. opw-5853070 Forward-Port-Of: odoo/odoo#254335
This update corrects a bug where selecting a PO would reset the prices of unselected alternative POs to the standard price. The fix now properly cancels unselected POs, preserving their original prices and preventing incorrect recalculations. This ensures accurate PO pricing and avoids potential financial discrepancies.
Original PR description
**Issue**: Choosing a PO among several alternative POs resets the price of all the unselected ones. **Steps to reproduce**: - Create a storable product with a standard price of 1 - Add two vendors…
**Issue**: Choosing a PO among several alternative POs resets the price of all the unselected ones. **Steps to reproduce**: - Create a storable product with a standard price of 1 - Add two vendors for a quantity of 1 with a unit price 1.1 and 1.2 - Create a PO for one vendor with 10 units at price 1.3 - Create an alternative PO for the other vendor with 10 units at price 1.4 - Compare the POs and choose the first one -> The unit price of the second one (1.4) is reset to the standard price (1) **Cause**: When choosing a PO, the quantities of alternative POs are reset to 0: https://github.com/odoo/odoo/blob/1b5072c0e0af6be340389e0c429ca370d8dc169d/addons/purchase_requisition/models/purchase.py#L317-L321 https://github.com/odoo/odoo/blob/1b5072c0e0af6be340389e0c429ca370d8dc169d/addons/purchase_requisition/models/purchase.py#L304 which will trigger the `_compute_price_unit_and_date_planned_and_name`. Since the quantity no longer matches any vendor, no seller is found (10 on the pol and 1 in vendor): https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1198-L1203 but `unavailable_seller` is found, since the quantity is not in the search https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1210-L1215 As a result, the price is recomputed using `standard_price`: https://github.com/odoo/odoo/blob/f5a24b10cb3a4cf32c6c185df65f3099c8da3ff1/addons/purchase/models/purchase.py#L1218 **Solution** Cancel unselected alternative POs instead of resetting their quantities to 0. This avoids triggering `_compute_price_unit_and_date_planned_and_name` and preserves original prices. opw-[6022718](https://www.odoo.com/web#id=6022718&view_type=form&model=project.task)
This update significantly speeds up the process of creating manufacturing orders when a Sale Order triggers a large Bill of Materials (BoM) explosion. Previously, this process could take several minutes. Now, a contextual cache is used to avoid redundant calculations, resulting in a much faster and more efficient experience.
Original PR description
Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed. The slowdown comes from…
Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed. The slowdown comes from `mrp.bom.line._get_cost_share()`, which is called for every line during a BoM explosion. When no explicit `cost_share` is set, the method recomputes the list of eligible BoM lines and checks whether any of them has a manual cost share. That computation depends only on the BoM and the product variant, but it is recomputed for every exploded line during `mrp.bom.explode()`. This causes a full BoM scan to be repeated for every single line. This commit introduces a contextual cache, initialized in `mrp.bom.explode()`, to store that metadata. We compute it once and reuse it for all lines of the same (BoM, variant) within the same explosion. ### Benchmark: | BoM lines | Before PR | After PR | | --- | ---: | ---: | | 100 | 3.747s | 1.094s | | 300 | 26.554s | 2.826s | | 600 | 85.378s | 5.299s | | 992 | 229.246s | 9.068s | opw-6017626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where marketing emails created in RTL languages (like Arabic) were incorrectly rendered as left-to-right. The fix ensures that email formatting respects the user's language direction, delivering emails in the correct layout. This improves the user experience for international customers.
Original PR description
**Steps to reproduce:**
- Install Mail Marketing app
- Change user language to a RTL language (such as Arabic)
- Create a marketing campaign with RTL content
- Send it
- Mail received changes from RTL to LTR
**Issue:**
Conversion doesn't seem to take into account the `dir` top-level attribute when creating the inline styling. This keeps the mails in the default format ('ltr').
**Fix:**
Check if the top-level element has such attributes, and manually add the `direction` style instead (style is applied on all direct children to ensure it's taken into account when taking the `innerHTML`).
opw-5982854This update fixes an issue where invoices processed through Nemhandel were incorrectly using the VAT ID instead of the company partner's EAN/GLN as the EndpointID. The change ensures invoices are correctly formatted for Nemhandel processing, improving data accuracy and compliance. This resolves a problem that could have resulted in incorrect invoice transmission.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_dk_nemhandel, and activate nemhandel. 2. Create a company partner, with a EAN/GLN as the nemhandel id. 3. Create an individual partner linked to the company partner. 4. Create an invoice with this individual partner. 5. Send the invoice with nemhandel. 6. open the xml file, and notice that the EndpointID doesn't use the EAN/GLN of the company partner. (It falls back to the VAT instead). opw-5945440
This update resolves communication issues with printers running on localhost (127.0.0.1) by correctly utilizing the 'loopback' TargetAddressSpace. This enhancement ensures stable connections with locally running printers, eliminating previous restrictions and simplifying setup.
Original PR description
This commit backports support for loopback TargetAddressSpace from 19.0. Before: LNA requests to localhost (127.0.0.1) used "local" TargetAddressSpace, which caused communication issues (CORS/PNA restrictions). After: Requests to localhost now correctly use "loopback" TargetAddressSpace, allowing proper communication with locally running devices. Impact: Enables stable communication with USB/network printers running on localhost without requiring IoT devices. Reference: https://github.com/odoo/odoo/pull/250972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a potential issue where Italian VAT withholding invoices were incorrectly processed due to mismatched withholding reasons. The change broadens the system's search criteria to allow for the use of taxes with the same withholding type, even if the specific reason differs. This ensures more accurate VAT calculations and reporting for Italian businesses.
Original PR description
Some invoice come in with a wrong ENASARCO withholding reason. We now broaden the search to allow taxes with the same withholding type to be used during import even if the withholding reason doesn't match. In the test, I change the Enasarco tax to reason Q to check that it gets correctly assigned. Ticket [link](https://www.odoo.com/odoo/project.task/5175587), [link](https://www.odoo.com/odoo/project.task/5933699) opw-5175587 opw-5933699 Forward-Port-Of: odoo/odoo#236251