Wednesday, April 8, 2026
5 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where the breadcrumb navigation within the Barcode app was displaying incorrect or blank entries when moving between related records. Now, users can easily identify the originating document when navigating from the Barcode interface, improving usability and reducing confusion.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#99165This update corrects a flaw in how the digest KPI calculates user connections. Previously, it only considered a user's default company, leading to inaccurate metrics. Now, it correctly accounts for users working across multiple companies, providing a more reliable view of connected users.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#247806
This update fixes an issue where payments wouldn't automatically update to 'paid' status after fully reconciling vendor bills, particularly when early payment discounts were involved. The change ensures payments accurately reflect the status of associated bills, improving financial reporting and reducing manual adjustments.
Original PR description
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without…
Currently, payments may remain in the 'in_process' state even when the associated vendor bills are fully paid. This occurs primarily when using early payment discounts (EPD) and journals without outstanding accounts. Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Analysis: The issue occurs because the reconciliation process misses the trigger to set the payment state to 'paid'. Specifically: - The payment amount does not match the bill total due to the EPD. - The payment compute method does not monitor 'reconciled_bill_ids', causing it to ignore the status of linked vendor bills. This change adds 'reconciled_bill_ids' to the compute dependencies and ensures that if a payment is reconciled with any moves (invoices or bills), their payment_state is considered to determine the final state of the payment. Test in enterprise: https://github.com/odoo/enterprise/pull/112398 opw-5881976
This fix resolves an issue where a save button would fail when using the liquidity account for bank reconciliation. The change prevents automatic reconciliation attempts with this account, avoiding a frustrating popup and ensuring data integrity. This improves the usability of the bank reconciliation process.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654
This update fixes a potential data inconsistency issue. Previously, users could erase a lot number from a Purchase Order-related Move, leading to errors. Now, the system prevents this action when the Move is linked to lot valuation, ensuring accurate inventory tracking and preventing data lockups.
Original PR description
When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked. ### Steps to reproduce: * Create a product tracked by lot and lot_valuated * Create a BoM for this product…
When we erase a sn/lot on a MO for a product that is tracked by lot, we will be deadlocked. ### Steps to reproduce: * Create a product tracked by lot and lot_valuated * Create a BoM for this product * Create a MO for this product * Confirm and Produce all * erase the lot and save -> the MO is deadlock, it's not possible to modify the lot number, nor it's possible to unbuild. ### Current behavior: A user is able to erase a lot/SN from a MO of a lot_valuated product. ### Expected behavior: It should not be possible to erase a lot/SN form a MO of a lot_valuated product. ### Observation: When the MO is done, its valuation will be calculated which in our case, it means, we have to have a lot number. When trying to add a lot/SN of a MO where it has been erased, we will remove the quantities from the previous lot, but in our case, since we don't have one, it will trigger the user error. https://github.com/odoo/odoo/commit/33e192de30526ea7fe320bcaa7a16dac8108feff This error is not triggered when removing the SN/lot because when we remove the value, it will be update to False which means it will skip _update_svl_quantity(): https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L35-L36 https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock_account/models/stock_move_line.py#L62-L65 This use case is also protected when creating a product tracked by lot but not lot_valuated: https://github.com/odoo/odoo/commit/4963103e5587d36364b8df84d0b3407a1977efdf opw-6039885 Forward-Port-Of: odoo/odoo#255098