Friday, December 19, 2025
7 changes · 17.0
Enhancements to existing features
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to streamline Peppol identifier verification through the company registry.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. back-port of: https://github.com/odoo/odoo/pull/233160 task: 5172378 Forward-Port-Of: odoo/odoo#240178
Resolved issues and error corrections
This update fixes an issue where DIN5008 invoices weren't showing Incoterm information. The change adds the necessary logic to include Incoterm codes and locations on these invoices, ensuring compliance with DIN5008 reporting requirements. This improves invoice accuracy and reporting for international transactions.
Original PR description
**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267**
This update fixes an error in how sales margins are calculated for multi-currency POS orders. The previous calculation was producing an incorrect margin figure. The fix ensures accurate margin reporting by applying the correct formula, resulting in more reliable sales data.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (TWD) - set that pricelist and journal in a pos - have a product with sales(1000$) and cost price(300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation (for TWD pricelist, multiply with currency rate i.e 36.833) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Note: Backkport of #239407 opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up product searches used in EDI invoice processing, particularly for PEPPOL transactions. By restructuring the database query, the system now utilizes indexes more effectively, dramatically reducing processing times. This improvement is crucial for handling large volumes of invoices efficiently.
Original PR description
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents…
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow. This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one. This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line. Benchmarks: Importing a peppol document of 173 invoice lines. | Num products | Num invoice lines | Before | After | | ------------ | ----------------- | -------- | ------- | | 864873 | 173 | 868.18 s | 19.43 s | | 397005 | 173 | 468.91 s | 20.68 s | | 8064 | 173 | 125.08 s | 20.1 s | | 564 | 173 | 119.9 s | 20.21 s | opw-5245007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238853
This update resolves a bug where invoices using the Solucion Factible PAC were being rejected due to incorrect exchange rate precision. The fix ensures the exchange rate is rounded to 6 decimal places, aligning with requirements for Mexican tax compliance (CFDI). This prevents invoice errors and ensures smooth payment processing.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.
This update resolves a memory issue that occurred when generating reports in the Odoo Enterprise system. The fix optimizes how data is retrieved from the database, preventing the system from running out of memory and crashing. This ensures reports can be generated reliably, especially for large customer databases.
Original PR description
- The method _compute_l10n_in_transaction_type currently fetches all columns…
- The method _compute_l10n_in_transaction_type currently fetches all columns https://github.com/odoo/enterprise/blob/1a67dadd2b1b3f94125f4088d1c36a77057443b4/l10n_in_reports/models/account_move.py#L20-L29
from the account_move table, whereas only a subset of fields is actually
required. Since account_move is typically a large table in customer databases,
this approach can lead to high memory consumption and potentially result in
MemoryError.
- I used the fetch method to ensure that non-stored fields are ignored and that only the specified fields are retrieved from the database, fetching only what is strictly necessary.
https://github.com/odoo/odoo/blob/574a67c73633755438d0aff7ff85f380fec9ef0d/odoo/models.py#L3826-L3830
- Moreover, this fix is implemented in version 18.0. As a result, it is not
applied in version 17.0, which explains why the MemoryError occurs in that
version.
https://github.com/odoo/enterprise/pull/76502/commits/be655971e7059b79bc3200b83d5e76b3c0b12059
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 519, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 221, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 239, in exec_script
migrate(cr, installed_version)
File "/tmp/tmp259m4qqf/migrations/l10n_mx/saas~16.2.2.0/end-migrate.py", line 9, in migrate
CoA.try_loading("mx", company=company, install_demo=False)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/point_of_sale/models/chart_template.py", line 22, in _load
result = super()._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 215, in _load
self._load_translations(companies=company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 1351, in _load_translations
translation_importer.save(overwrite=False)
File "/home/odoo/src/odoo/17.0/odoo/tools/translate.py", line 1460, in save
env.flush_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 737, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 733, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6977, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1379, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1352, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/l10n_in_reports/models/account_move.py", line 23, in _compute_l10n_in_transaction_type
if move.country_code == "IN":
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
select COUNT(*) from account_move
+--------+
| count |
|--------|
| 511738 |
+--------+
SELECT 1
Time: 0.177s
```
opw-5414648
upg-3570209This update fixes an issue where marketing automation emails weren't displaying translated text when run through the Odoo cron job. The problem stemmed from a language context being overwritten, preventing the correct translation of dynamic fields like email titles. This change ensures all marketing automation emails are translated accurately, regardless of how they are triggered.
Original PR description
We have a dynamic placeholder in the marketing automation's mail template like object.title.name. Odoobot's preferred language is, let's say "Dutch". When the marketing automation is tested manually, with the user whose language is "Dutch", the field is translated fine. But when ran vai cron, "Marketing Automation: execute activities", the field isn't translated properly, because the context with lang Dutch gets overwritten earlier in the process. To fix this, we add a lang context right before the execution. Step To Reproduce: 1.Create a marketing automation. 2.In the mail template, add a dynamic placeholder with field object.title.name. 3.Switch the Odoobot's preferred language to anything but English. But here let's say "Dutch". 4.Now, switch to superuser, and then run the cron manually. 5.We can see that the title didn't get translated properly. opw-5062328