Daily updates from Odoo
Thursday, June 4, 2026
8 changes · saas-18.2
Resolved issues and error corrections
This update fixes a bug that allowed internal transfer validations to proceed without scanning the destination location. Previously, deleting a line would cause validation to succeed even if the location wasn't scanned. The fix ensures validation only occurs after a destination location has been scanned, improving data accuracy and user experience.
Original PR description
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.…
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required. ## Steps to produce: - Install the Inventory module - Go to Settings and enable Storage Locations. - Inventory > Configuration > Operation Types > Internal Transfers > Barcode App - Configure the Destination Location to require scanning after each product. - Create an Internal Transfer for Pedal Bin, demand 1. - Mark the transfer as To Do and open it in the Barcode app. - Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493). - Delete the newly added line and attempt to Validate. ## Observed Behavior: The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line. ## Root cause: This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates. As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned. [1]: https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] : https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]: https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948 ## Solution: We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product. To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed. However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned. To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily. opw-6069614 Forward-Port-Of: odoo/enterprise#113618
This update fixes an issue where the General Ledger and Balance Sheet reports were incorrectly exporting all accounts instead of the selected one when changing date filters. The fix removes unnecessary filtering logic, ensuring the report accurately reflects the user's chosen account. This improves report accuracy and usability.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update fixes a calculation error in the executive summary report that was underreporting the length of time periods. Previously, the report was calculating the gap between dates instead of the number of days. This change ensures the report accurately reflects the period length, specifically for metrics like Average Debtor Days, leading to more reliable reporting.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update addresses an issue where manual operations were incorrectly being matched during account reconciliation. This reversion restores the previous system behavior, ensuring accurate reconciliation processes. It's a technical fix to improve the reliability of our accounting system.
Original PR description
This reverts commit 038f527793757c3148b775af1657c5a70a5abc66. opw-6230807 Forward-Port-Of: odoo/enterprise#118169
This update resolves an error that occurred when users attempted to use property fields within auto-fill fields in the sign module. The fix restricts property field selection, ensuring data integrity and preventing the application from crashing. This change improves the stability of the sign process.
Original PR description
Currently, an error occurs when user tries to select a property field in auto field. Steps to replicate: - Install `sale_management` and `sign`. - Open Sales > Products > Products > Open any product.…
Currently, an error occurs when user tries to select a property field in auto field.
Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.
Error:
- saas-18.3 and later:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
field = records._fields[field_name]
^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```
- saas-18.2:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
if len(records) > PREFETCH_MAX:
^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```
Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.
- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.
Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.
[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41
sentry-7378769090This update resolves an issue preventing the automatic saving of IRN numbers when sending invoices via e-invoicing with email in the Indian localization. Previously, a technical glitch caused the IRN to be lost, now it's correctly recorded. This ensures accurate e-invoicing compliance.
Original PR description
**Issue**: Sending invoice through e-invoicing with email in Indian localization will not save the IRN number on the invoice because of a cache issue on the attachment id. **Steps to reproduce:** 1. Install l10n_in_edi_gstr module. 2. Create an invoice and send it through e-invoicing with email option. 3. The IRN number will not be saved on the invoice. **Causes:** When sending the invoice through e-invoicing with email option, the attachment id is not saved on the invoice before calling the method _l10n_in_edi_send_invoice(). This causes a cache issue and the IRN number is not saved on the invoice. **Fix:** Save the attachment id on the invoice after the creation of the attachement. **Note:** This pr: https://github.com/odoo/enterprise/pull/114350 fixes the issue in 18.3+ when only selecting e-invoicing while sending the invoice but the issue still happens in 18.2. The issue still happens when email is also selected for versions 18.2+. opw-6243256
This update resolves an issue where customer labels appeared blank and refund flows failed in DIAN POS orders. The fix ensures the 'Final Consumer' partner is always included in the POS order data, preventing data loading problems and improving the customer experience. This aligns with recent improvements.
Original PR description
When DIAN POS is enabled, l10n_co_edi_pos auto-assigns the `Consumidor Final` partner to new POS orders. However, POS only preloads a limited partner set in frontend memory. If `Consumidor Final` is not part of that set, the order gets a partner id whose full partner data is not loaded in the UI. This causes the customer label to appear blank and refund flows to fail with "Can't change customer" mentioning `undefined`. To avoid this, always include the final consumer partner in `get_limited_partners_loading()`. This matches the approach already present in newer branches. opw-6238935 Forward-Port-Of: odoo/enterprise#118408
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used for identifier values, improving the accuracy and clarity of the exported data. This enhances the reliability of the ICP reporting process.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119152 Forward-Port-Of: odoo/enterprise#112995