Thursday, March 12, 2026
9 changes · 19.0
New functionality added to Odoo
This update introduces a new report to track outstanding payments to MSME vendors, improving financial compliance. It includes an MSME-specific XLSX export and a new 'MSME Report' variant within the aged payable reports. This enhances visibility and reporting for MSME vendor relationships.
Original PR description
- Provides a report for monitoring payment dues to MSME registered vendors. - Adds MSME-related XLSX export. - Adds a new aged payable report variant 'MSME Report'. Comm PR: https://github.com/odoo/odoo/pull/226297 task-4140405
Enhancements to existing features
This update enhances the payroll accrual calculation by adding thorough testing to ensure future changes don't break the system. It also resolves a security issue, granting access to tracking values (used for accrual calculations) to non-admin users, while maintaining data security.
Original PR description
Accrual is computed based on tracking values, checking added or removed leaves in a given request, based on their datetimes. This feature does not seems tested currently, so let us cover it. That way we ensure future changes in tracking model do not break current feature. By the way, fix an ACL issue when trying to access tracking values and not being admin. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com>
Resolved issues and error corrections
This update fixes an issue where currency exchange differences weren't correctly appearing in the DATEV export file. The fix adjusts how the export calculates amounts, now using the line balance instead of the currency amount, ensuring accurate reporting of exchange rate variances. This improves the reliability of financial data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product pricing (price-embedded). The fix mirrors the functionality in the Point of Sale app, ensuring accurate product recognition for these common barcode formats. This improves the reliability of inventory management.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
This update clarifies error messages for declined payments related to international vendors. Previously, the message "Country not allowed" was misleading when the vendor was located outside of Belgium. The change now incorporates payment data to provide more accurate and helpful error messages to users.
Original PR description
A company in belgium creates a card, it's "allowed countries" is set to Belgium by default. If said card is used to pay online on a website ending with .be, it is understandable that the user believes the vendor to be located in Belgium If it is not the case (the vendor is actually in Luxembourg), the payment is refused but the message on the refused expense is unclear "Country not allowed" The change adds the data received to make the decision in the error message task: 5478443
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's selection. Now, the system uses the BoM specified in the product schedule, ensuring correct demand calculations and inventory updates.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#109693This update fixes an issue where Belgian VAT return PDFs generated after locking were missing crucial fields like 'Ask Restitution' and 'Client Nihil'. The fix ensures these fields are correctly included in the PDF attachment, improving the accuracy and completeness of the reports for our Belgian users. This resolves a discrepancy in the generated documents.
Original PR description
When locking a Belgian VAT return, the PDF attachment was generated without 'l10n_be_closing_vat_return', 'ask_restitution', and 'client_nihil' in the options. The wizard called _proceed_with_locking() without options_to_inject, so when export_to_pdf() rebuilt options via get_options(), _custom_options_initializer() read those keys from previous_options as None — making <t t-if="options.get( 'l10n_be_closing_vat_return')"> always False. Steps to reproduce: 1. Create a Belgian company 2. Navigate to Accounting → Reporting → Tax Return 3. Create a VAT Return, fill in "Ask Restitution", and lock it 4. Open the generated PDF attachment => "Ask Restitution" and "Client Nihil" fields are missing from the header => Fields now appear correctly Ticket [link](https://www.odoo.com/odoo/project.task/5509725) opw-5509725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a memory issue that was causing slowdowns when processing large accounting asset records. The fix uses a more efficient method to calculate depreciation, reducing the amount of data loaded into memory and improving performance. This ensures the system can handle a greater volume of assets without running into errors.
Original PR description
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the…
The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.
Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version.
```
Traceback (most recent call last):
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
result = records.read(fields, **read_kwargs)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
return needle(*args)
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
self._read(fnames)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
opw-5921410
upg-3891767
Forward-Port-Of: odoo/enterprise#109008This update ensures that the system correctly accesses company-specific information needed to process UY Electronic Data Interchange (EDI) documents. Previously, users without specific permissions would encounter errors when validating these documents. This change adds necessary permissions to guarantee proper document processing and avoid validation failures.
Original PR description
This pull request makes a small update to the `_ucfe_inbox` method in `l10n_uy_edi_document.py` to ensure that company-specific fields are always accessed with the appropriate permissions. This is achieved by using the `sudo()` method when retrieving the `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields from the `company` record. * Ensured that `l10n_uy_edi_ucfe_commerce_code` and `l10n_uy_edi_ucfe_terminal_code` fields are accessed with elevated permissions by calling `company.sudo()` in the `_ucfe_inbox` method (`l10n_uy_edi_document.py`). Without this fix, if the user doesn't belong to group "base system", it won't be able to validate CFEs, receiving the following message: <img width="1272" height="400" alt="image" src="https://github.com/user-attachments/assets/ec4223fb-5b96-4a3e-babf-2f6a35ecd123" /> Forward-Port-Of: odoo/enterprise#105918