Daily updates from Odoo
Tuesday, April 28, 2026
9 changes · 19.0
Enhancements to existing features
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insight into where funds are being allocated, reducing errors and improving reconciliation accuracy. The changes were made to the bank reconciliation tools within the Odoo Enterprise system.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382
Resolved issues and error corrections
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during the sale process, preventing double-counting and maintaining accurate fixed asset and depreciation records. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649
This update ensures that the 'Source' (origin) field is correctly populated on replacement invoices generated after a cancellation request. Previously, this information was missing, hindering traceability and compliance. The fix explicitly copies the original invoice's data, maintaining accurate links to the Sales Order and ensuring proper PDF output.
Original PR description
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice…
### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099
This update resolves a bug where portal payments for mixed subscription lines (recurring and one-time) weren't correctly creating recurring invoices. Previously, payments were misdirected, leading to duplicate charges. The fix ensures accurate invoice creation for these mixed subscriptions, preventing payment issues and maintaining subscription accuracy.
Original PR description
Steps to reproduce: - Create a subscription with a recurring line and a non-recurring line invoiced on delivery. - Confirm the subscription so the first period is due. - Pay it from the subscription portal. Issue: The portal charges `next_invoice_amount`, but on the first subscription period the payment can still be evaluated against the broader displayed total. In that mixed setup, the transaction is then handled through sale's generic final invoice flow instead of the subscription recurring invoice flow. As a result, the first successful portal payment may fail to create the expected recurring invoice, leaving the subscription due and allowing the subscription cron to charge it again later. Solution: For first-period `assign_token` subscription transactions without linked invoices, when the displayed total differs from `next_invoice_amount`, compare the payment against `next_invoice_amount` and create the invoice through `_create_recurring_invoice()`. opw-6114730
This update resolves an issue where commission calculations were failing for subscription plans due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly calculated even when currency rates haven't been manually set. This ensures accurate commission payments for recurring subscription orders.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580
This update fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to the production origin in stock movements. Now, byproducts added to MOs are accurately tracked, ensuring correct inventory reporting and shop floor visibility. This improves the accuracy of production data.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582
This update corrects an encoding problem in the XML files used for exporting payroll data to the IRD platform in Hong Kong. The fix ensures the files meet the IRD's specific formatting requirements, preventing potential export errors and ensuring accurate data submission. Further work is needed to ensure compatibility with other file types and a robust testing process.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least)
This update resolves two issues impacting manufacturing order processing within the Barcode app. Previously, changing the unit of measure or production quantity after confirming a MO would reset, leading to data inconsistencies. The fix ensures that UoM changes are correctly applied and that entered production quantities are preserved, improving data accuracy and workflow reliability.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075
This update resolves an issue where the automated vendor invoice retrieval process (cron job) didn't correctly identify the target company within a multi-company Odoo setup. The fix ensures invoices are fetched from the correct company, preventing errors and improving data accuracy. This improves the reliability of reporting for businesses using multiple companies.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115192 Forward-Port-Of: odoo/enterprise#113254