Daily updates from Odoo
Wednesday, February 11, 2026
16 changes · 18.0
Enhancements to existing features
This update enhances the handling of Romanian VAT invoices from the ANAF tax authority. Now, the system automatically downloads and attaches the official PDF version of the invoice, providing accountants with a visual document for comparison and compliance. This eliminates the previous reliance solely on XML data.
Original PR description
### Before For bills from the Romanian ANAF we only downloaded an XML and imported the data. There is no visual aid for the accountant to see and compare the received document. ### Now We use the ANAF service to get the official "PDF" version of the invoice. This is requested for any new bill we get through ANAF that doesn't already contain a pdf from the vendor and it is set as the main attachment. task-5877171
This update enhances the partner information displayed in Odoo's chatter by integrating data from DnB. Now, a dedicated company card is created in chatter, pulling in relevant details alongside the previously stored industry tags. This provides a more complete view of partner information directly within conversations.
Original PR description
Before: Industry tags coming from DnB were stored in the Tags section of res.partner. and there was no Company info card in chatter. After: Industry tags coming from DnB are not stored in the Tags section of res.partner. Company card is created in chatter that is having details from Dnb along with tags. task-5373200 Forward-Port-Of: odoo/odoo#239464
Resolved issues and error corrections
This update fixes an issue where the Stock Forecasted report incorrectly displayed stock quantities after a repair order was deleted. The fix ensures that related stock moves are properly cancelled when a draft repair order is removed, providing accurate stock reporting. This improves the reliability of inventory tracking within the repair process.
Original PR description
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in…
**Steps to reproduce:** * Install the *repair* module. * Create a *storable product* and set some **On Hand** quantity. * Go to *Repairs* and create a new **Repair Order**. Keep the repair order in *draft* state (do not confirm). * In the **Parts** tab, add the storable product with the operation type set to *Add*. * Open the **Stock Forecasted** report for the added product. Note the quantity shown under *Outgoing Draft Transfer*. * Delete the **Repair Order**. * Open the **Stock Forecasted** report for the same product again. **Observed behavior:** * The quantity still appears in the **Stock Forecasted** report under *Outgoing Draft Transfer* even after the repair order is deleted. **Cause:** * Deleting a draft repair order triggers `_unlink_except_confirmed`. * This method prevents related stock moves from changing their state to cancel when the repair order is deleted. * The *Outgoing Draft Transfer* value is calculated as the sum of quantities of stock moves in draft state at draft state. https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49 https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90 * As a result, deleting a draft repair order leaves related stock moves in draft state, causing them to appear under *Outgoing Draft Transfer* https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335 **Fix:** * Ensure that related stock moves are properly cancelled when a draft repair order is deleted. --- opw-5449323 Forward-Port-Of: odoo/odoo#241970
This update enhances the reliability of sending Peppol documents by limiting the number of invoices processed in each request. Previously, sending a large batch of invoices could cause system slowdowns. Now, the system batches invoices in groups of 100, preventing timeouts and ensuring smoother operation.
Original PR description
The current implementation of Peppol document sending attempts to process all selected invoices in a single API call. When a user sends a very large number of invoices at once, this can lead to timeouts from the Peppol proxy or Odoo worker, resulting in system instability. This commit introduces batching for the `send_document` API call, limiting each request to a maximum of 100 invoices. This ensures more reliable processing and prevents request payload size issues. Task-5877964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a sporadic error in the barcode scanner test within the Odoo web interface. The change ensures the view is fully re-rendered before the test runs, making the test results more reliable and consistent. This improves the stability of the barcode scanning functionality.
Original PR description
This commit ensure to await the view to be correctly re-rendered. runbot-error-233551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where website redirects were losing important URL parameters, causing errors when users attempted to access specific features. The fix ensures all parameters are correctly encoded during redirects, preventing errors and maintaining expected functionality. This improves the user experience and prevents disruptions to workflows.
Original PR description
Scenario from 17.0:
- set domain on website
- go to website /website/force/1?path=%2F%3Fa%3Db%26c%3Dd with another
domain
=> you are redirected to {domain}/?a=b instead of {domain}/?a=b&c=d
Scenario from 18.0:
- set domain on website
- go to /appointment/1 on other domain, select person date and time
- click on "Editor"
=> you get error:
> TypeError: AppointmentController.appointment_type_id_form() missing 1
> required positional argument: 'duration'
Cause: the /website/force/ domain redirection doesn't encode the
parameter when redirecting, so we lose parameters after the first one.
Fix: encode parameters when redirecting domain in /website/force/ route.
opw-5441957
Forward-Port-Of: odoo/odoo#242252This update resolves a bug that caused Odoo module updates to fail when encountering certain field types (like text fields) during the update process. The fix adds a check to ensure fields are of the correct type ('selection' or 'reference') before attempting to access their 'ondelete' attribute, preventing errors and ensuring smoother updates.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where validating purchase receipts for kits with different unit of measure categories (e.g., 'Units' vs. 'Length') would cause errors. The fix ensures accurate quantity calculations for kit receipts, particularly when the purchase order currency differs from the company currency, by correctly aggregating component move quantities.
Original PR description
Steps to reproduce ------------------ 1. Enable Units of Measure and Automatic Valuation. 2. Create: Product KIT, stockable, UoM category Unit, UoM = Units. BoM for KIT with at least one component…
Steps to reproduce
------------------
1. Enable Units of Measure and Automatic Valuation.
2. Create:
Product KIT, stockable, UoM category Unit, UoM = Units.
BoM for KIT with at least one component whose UoM is in a different
category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.
Issue
-----
Validating the receipt raises:
> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…
If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.
Cause of the issue
------------------
Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108
Fix
---
The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.
https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126
For kits, `qty_received` must be calculated by aggregating component
moves to accurately determine this status. Since the standard logic
crashes due to UoM mismatch, the override in `purchase_mrp` is
necessary to provide the correct quantity for this date selection.
opw-5030761
Forward-Port-Of: odoo/odoo#236276This update resolves a potential performance issue with the image field in Odoo. Previously, the system struggled to reliably display images due to delays in encoding. The change now explicitly waits for the image to load, ensuring a smoother and more consistent user experience.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from sending invoices via PEPPOL, which is a key feature for international sales. The problem stemmed from an audit trail restriction preventing attachment modifications during the PEPPOL sending process. The fix ensures attachments are handled correctly, allowing invoices to be successfully transmitted.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_de - Switch to a German company (e.g. DE Company) - In Accounting settings, activate Peppol - Create an invoice: * Customer: [a German customer…
**Steps to reproduce:** - Install Accounting and l10n_de - Switch to a German company (e.g. DE Company) - In Accounting settings, activate Peppol - Create an invoice: * Customer: [a German customer with VAT] * Invoice Lines: [a line with a tax] - Confirm the invoice - Send the invoice via PEPPOL **Issue:** A UserError is raised: "You cannot remove parts of the audit trail.". **Cause:** The audit trail prevent modifying an attachment. When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment. During the process, "res_model" and "res_id" fields of the attachments are set to the message record. Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error. However, it fails because the value is still in cache. **Solution:** Invalidate these fields as it is done when sending the invoice without PEPPOL. https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20 opw-5916696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247949
This update fixes an issue where the HTML editor toolbar incorrectly appeared on non-editable elements, causing instability. Now, the toolbar only displays for editable elements, ensuring a smoother and more reliable editing experience for users. This improves the overall usability of the HTML editor.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416
This update corrects a bug where a POS order could incorrectly apply a pricelist even if it wasn't a valid option for the customer. The fix ensures that only available pricelists are used when changing a customer on a POS order, improving order accuracy and preventing potential pricing errors. This resolves issue OPW-5461556.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update incorporates new 2026 codes for intrastat reporting, aligning with European statistical requirements. These codes, sourced from the National Bank of Belgium, ensure accurate reporting of foreign trade data within Odoo Enterprise. This change improves compliance with international trade regulations.
Original PR description
This commit adds 2026 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes opw-5504187 Forward-Port-Of: odoo/enterprise#106896
This update resolves two critical errors in the Hong Kong payroll calculations. Specifically, it corrects a mistake where rental allowances were incorrectly included in IRD reports and removes an incorrect deduction of ERMPF from taxable salaries. This ensures accurate tax reporting and compliance with Hong Kong regulations.
Original PR description
Fixes two issues related to computations; The taxable salary wrongly deduce the ERMPF which it should not. in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs. task-5353781
This update resolves two issues related to the LNE scale certification process. It now prevents users from manually altering order line weights for products measured on a scale, and it restricts the input of negative tare weights, ensuring accurate net weight calculations. These changes enhance data integrity and compliance for certified products.
Original PR description
This PR fixes 2 issues we currently have with out LNE scale certification 1) You can manually change the value of a order line for a product which was weighed with a scale --> should not be possible 2) User can input negative tare weight resulting in a manual net weight --> should not be possible task-5926814
This update resolves an issue where reports related to Peruvian sales (l10n_pe) were occasionally generating duplicate records. The fix ensures that the system consistently picks the correct stock valuation layer during report generation, leading to accurate financial reporting. This improves data reliability for Peruvian accounting.
Original PR description
Occasionally the test_kardex_report test fails: ``` Traceback (most recent call last): File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in…
Occasionally the test_kardex_report test fails:
```
Traceback (most recent call last):
File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']
First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'
- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
? ^ ^
+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
? ^ ^
```
The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.
The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.
This commit makes the behavior deterministic by sorting on PO line and SO line ids.
runbot-error-238888
Forward-Port-Of: odoo/enterprise#107047