Tuesday, January 13, 2026
5 changes · saas-18.2
Enhancements to existing features
This update modifies the NCM (National Customs) code list used in Odoo Enterprise for Brazil, aligning with the latest tax regulations. The changes include marking expiring codes as ‘DEPRECATED’ and adding new codes to ensure accurate tax reporting and compliance.
Original PR description
This **PR** updates the NCM code list as per latest requirement. It appends `DEPRECATED` at the end of expires codes. Also it introduces a few new codes. **task**-5381617 Forward-Port-Of: odoo/enterprise#102009
This update allows system administrators to customize the main Odoo Enterprise home menu with a targeted message. Administrators can set a message through a configuration parameter, visible to all users, to communicate important information like scheduled maintenance. This provides a direct way to notify users about critical events.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#103752
Forward-Port-Of: odoo/enterprise#102239Resolved issues and error corrections
This update resolves an issue where a reordering rule would incorrectly attempt to update a manufacturing order (MO) that had been locked due to a quality check. The fix ensures that the MO remains locked when a quality point is completed, preventing data inconsistencies and errors. This improves the reliability of the MRP process.
Original PR description
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an…
### Issue: In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised: ``` Odoo Warning You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed. ``` ### Steps to reproduce: - Create a product tracked by quantity - Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point) - Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1) - Click on Order - Open the created MO and the Shop Floor (Remove the filters to see the WO) - Complete the Quality Point - Modify the Reordering Rule (Min/Max: 2) - Click on Order - the error should be raised ### Cause: The MO to update is retrieved here: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function: https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153 In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created opw-5012588 Forward-Port-Of: odoo/enterprise#101313
This update resolves a bug in the General Ledger reporting where analytic accounting groupings were displaying incorrect information and linking to unrelated journal entries. The fix corrects a technical issue related to how the system identified lines for grouping, ensuring accurate reporting and correct navigation to the relevant journal entries. This improves the reliability of the General Ledger reports.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#103169
This update fixes an issue where the quantity of products scanned via GS1 barcodes wasn't correctly reflected in manufacturing orders. Previously, the system only added one unit regardless of the barcode's specified quantity. Now, the system accurately uses the barcode's quantity to update the finished product's output, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#103675 Forward-Port-Of: odoo/enterprise#95174