Friday, February 13, 2026
10 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where duplicate account codes could be created, even for archived accounts. Previously, the system only checked active accounts for uniqueness, leading to potential data inconsistencies. Now, the system validates account codes against both active and archived accounts, ensuring data integrity and preventing errors.
Original PR description
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
This update fixes a crash that occurred when creating vendor bills with multiple purchase orders linked through the autocomplete field. The issue stemmed from an error in how Odoo tracked record IDs during data insertion, leading to duplicate key errors. By limiting the number of linked purchase orders, this change ensures stable bill creation.
Original PR description
Steps to reproduce ================== - Edit the Vendor Bill form view to set a limit of 2 on the invoice_line_ids field. - Create 2 purchase orders with the same vendor and 4 products - Create a vendor bill - Set the same vendor - Using the autocomplete field, select the first purchase order - Save the form - Select the other purchase order in the autocomplete field - Delete the record before the last one => Got duplicate key in t-foreach: datapoint_12 Cause of the issue ================== Before inserting the last 4 lines: `this._currentIds = [1, 2, 3, 4]` After the second insert, we have `this._currentIds = [1, 2, virtual_1, 3, virtual 2, virtual_3, virtual_4, 4]` Only the first record is inserted at the correct place, following ones are off by one. opw-5264594 Forward-Port-Of: odoo/odoo#248451
This update resolves an issue where comments within invoice XML files, specifically added during Peppol transmission, were causing the system to fail to recognize invoices. The fix removes these comments during XML parsing, ensuring invoices are correctly processed and uploaded. This prevents empty invoices from being created.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
This update fixes several issues related to how website snippets are displayed in the editor. Specifically, it ensures carousel preview heights are consistent, parallax previews now correctly show zoom effects, and custom snippet labels are properly displayed. These changes enhance the user experience and accuracy of the website editor.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present**
This update prevents users from creating new lot/serial numbers directly from the Contacts app. Previously, this unintended feature led to inconsistent data. The fix hides the 'New' button, ensuring data integrity until a proper creation flow is implemented.
Original PR description
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts`…
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts` modules. - Enable `Lots & Serial Numbers` from the inventory settings. - Open the `Contacts` app and open any contact record. - Click the `Lots/Serial Numbers` smart button. **Observation:** The user can `create` a new lot/serial number from the Contacts, even though this flow is not supported and results in inconsistent data. **Root cause:** After PR [1], `lot/serial number` creation was accidentally enabled from the Contact. The intended behavior is that Contacts should only be able to view related lots/serial numbers, not create them. (Confirm with PO `crl`) **Fix:** This commit disables the creation of Lot/Serial Numbers from the contact by `hiding` the New button. This prevents users from creating inconsistent records until a complete and correct flow is implemented in a future improvement as mentioned at [2]. [1]: https://github.com/odoo/odoo/pull/184242 [2]: https://www.odoo.com/mail/message/978482657 opw-5504073
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the POS experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244103 Forward-Port-Of: odoo/odoo#241373
This update fixes an issue where invoices created in foreign currency didn't accurately display the amount in the company's local currency when generating reports. The fix ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for SA companies. This improves the reliability of financial data.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. 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#245840
This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The change adjusts the date validation to align with Colombian regulations, allowing for invoice dates up to 6 days before and after the current date, ensuring accurate electronic invoicing.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107255 Forward-Port-Of: odoo/enterprise#105763
This update resolves a bug that prevented users from correctly applying amounts during bank reconciliation, specifically for both full and partial amount adjustments. The fix ensures that currency amounts are used accurately, improving the reliability of the reconciliation process.
Original PR description
In this commit: We broke the way the apply amount work, this commit will solve that. For the apply full amount, we modified the field fetch by fetchReconciledLines and also the substraction of the amount currency to use the amount currency and not the balance For the partial, keep it like before we actually take the value of the suspense so it's ok. opw-5925046
This update resolves a bug that prevented users from successfully editing reconciled bank statement lines. The fix initializes necessary variables to avoid an error that occurred when attempting to adjust the balance of a reconciled line. This ensures the bank reconciliation process functions correctly.
Original PR description
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting`…
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting` module. - Create an `invoice` with an `invoice line` having an amount greater than zero. - `Confirm` the invoice. - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice. - Click `Reconcile` on that `statement line` and select the newly `created invoice line`. - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save. `UnboundLocalError: local variable 'original_base_lines' referenced before assignment` The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2]. This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error. [1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394 [2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411 sentry-7189027839