Daily updates from Odoo
Sunday, April 5, 2026
7 changes · saas-19.1
Enhancements to existing features
This update optimizes the installation process for the l10n_jo_edi module by preventing a lengthy calculation from running automatically during module setup. This change avoids delays when Odoo is installed on systems with many existing account records, resulting in a faster and smoother installation experience.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204 Forward-Port-Of: odoo/odoo#257748 Forward-Port-Of: odoo/odoo#257658
Resolved issues and error corrections
This update corrects errors in the generation of XML files for commercial events, ensuring accurate data transmission to the Dian authority. The fix addresses issues with naming conventions and QR code references, preventing rejection of submitted documents. This improves compliance and reduces potential delays in processing.
Original PR description
When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls _add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g. "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash: Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE. _dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's. We now render commercial events like how invoices are rendered. [1] odoo/enterprise#107170 opw-6065701 Forward-Port-Of: odoo/enterprise#112812
This update fixes an issue where single-letter unit of measure names (like 'm', 'l', 'g') couldn't be included in translations. The change simplifies the filtering process to ensure these names are now correctly exported, addressing a translator's reported problem and improving translation workflow efficiency.
Original PR description
Single-letter strings (as used for units of measure, like `m`, `l`, `g`) are not exportable for translation, because the export of translation strings was filtering out different strings based on the type of the translation. This commit harmonized the filtering to the single condition of a string containing at least one letter, which allows exporting single-letter strings while still filtering out non-meaningful strings like `:`, `...`, `.00`, etc. Issue reported by one of our translators. Forward-Port-Of: odoo/odoo#257080
This update fixes an issue where the IAP account balance would reset to zero after a record was saved. Now, the balance accurately reflects the selected service's value even after saving the account, providing a more reliable user experience. This ensures users always see the correct balance information.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#257706 Forward-Port-Of: odoo/odoo#256589
This update significantly improves the speed and efficiency of loading product attributes on the shop page, especially when displaying a large number of products. The change optimizes how product data is retrieved, reducing memory usage and dramatically speeding up loading times. This results in a smoother and more responsive shopping experience for customers.
Original PR description
Before this commit, fetching product template attributes was slow and memory-intensive when handling a large number of products. The domain included IDs of all fetched products, leading to high memory usage and slow performance. To fix this, use the product domain directly instead of passing product IDs. Below is the performance comparison for the read_group used for attribute fetching: | Products | Before (Memory) | Before (Time) | After (Time) | | -------- | --------------- | ------------- | ------------ | | 900K | 113MB | 2.5s | 2ms | | 2M | 200MB | 7s | 2.5ms | | 9M | OOM | +15s (OOM) | 11ms | opw-5949132 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256124
This update resolves a technical error that prevented inactive TDS/TCS taxes from being correctly applied on invoices. The fix ensures that inactive tax calculations are handled properly, preventing errors and ensuring accurate tax reporting within the Odoo system. This improves the reliability of financial data for users of the Russian localization.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534 Forward-Port-Of: odoo/odoo#257735 Forward-Port-Of: odoo/odoo#256809
This update fixes a problem where PoS orders with additional products prevented successful settlement from the PoS. The system now correctly calculates the unpaid amount based on the total PoS order amount, ensuring sales can be settled properly even with multiple items. This resolves a previous issue impacting payment processing.
Original PR description
The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232 Forward-Port-Of: odoo/odoo#256590 Forward-Port-Of: odoo/odoo#251387