Daily updates from Odoo
Thursday, January 22, 2026
5 changes · 19.0
Resolved issues and error corrections
This update resolves an issue where a Point of Sale order incorrectly remained flagged as a 'settlement' after a user canceled a payment attempt. By resetting the order flag, this prevents users from bypassing important business rules related to invoicing and reporting. This ensures accurate order processing and integration with other systems.
Original PR description
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current…
## Description of the issue/feature this PR addresses: The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation. ## Current behavior before PR: When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True. This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this. ## Desired behavior after PR is merged: After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. task-id - 5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#104438 Forward-Port-Of: odoo/enterprise#98463
This update fixes a discrepancy between the quantity of components consumed displayed in the Shopfloor dialog and the Manufacturing Order itself after a work order is completed. Previously, the numbers didn't align, leading to potential data inconsistencies. This change ensures accurate reporting of consumed quantities, improving the reliability of manufacturing data.
Original PR description
Before this commit: ================================== In a Manufacturing Order(MO) with manual consumption of components, The quantity of component consumed shown in Shopfloor dialog didn’t match…
Before this commit: ================================== In a Manufacturing Order(MO) with manual consumption of components, The quantity of component consumed shown in Shopfloor dialog didn’t match with consumed quantity shown in MO after marking a work order as done. Steps to Reproduce: ================================== 1. Install `mrp_workorder` module. 2. Create a BOM with one component and two operations. 3. Set the component to be consumed in the first operation (manual consumption). 4. Create a MO for the finished product.(e.g., MO to produce 10 quantity) 5. Go to the Shopfloor and register a production.(e.g., 7 instead of 10). 6. Click on the component line → Check the consumed quantity shown in the dialog → Close dialog without applying it. 7. Validate the workorder in Shopfloor (A backorder creation dialog will appear; choose either option). 8. Check the consumed quantity of component in the MO form view. There is a mismatch between what was shown in Shopfloor dialog and what is shown in the MO form view. Cause of the Issue: ================================== The Shopfloor dialog `MrpQuantityDialog` uses the `quantity` field of the move, and this field is updated when the work order is marked as done to align consumed quantity with produced quantity, resulting in an inconsistency. After this commit: ================================== These changes ensure the consumed quantity shown in shop floor dialog correctly matches the consumed quantity shown in MO after marking a work order as done, enhancing data consistency between Shopfloor and the Manufacturing Order. TaskId-5068382
This update fixes a usability issue where bank statement information was hidden at the bottom of the search dialog. The changes move this critical data to the top of the form, making it much easier for users to quickly find and review their bank reconciliation details. This improves efficiency and accuracy in managing financial records.
Original PR description
The info of the bank statement line are now in the bottom but nobody sees them. This commit aims to have it on the top of the form. task-5212851
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix ensures the map renders properly, but further work is needed to enable user interaction with the map. This improves the usability of the Studio for creating and customizing maps.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104968 Forward-Port-Of: odoo/enterprise#104114
This update corrects a bug in the Master Production Schedule (MPS) that caused excessive component reordering for kit products. Specifically, the system was incorrectly calculating the quantity of components needed, leading to inflated order quantities. This fix ensures accurate MPS calculations and prevents over-ordering of components.
Original PR description
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it…
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components. When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount. ***Steps to reproduce:*** - Create a second warehouse. - Check Resuply From 'First Warehouse' (this will unarchive a route) - Create a product that uses that route for reordering. - Create a second product - Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1 - In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route. - Add any amount to reorder in 'Replenishment' then click the Order button. - If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount. opw-5351460 Forward-Port-Of: odoo/enterprise#101462