Odoo Changelog — 2026-01-14

Wednesday, January 14, 2026

7 changes · 17.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] l10n_ch_hr_payroll_elm_transmission: Use reference_date when locking period

Enterprise17.0l10n_ch_hr_payrollMEDIUM

This update corrects a potential issue with the transmission of payroll data to the Swiss tax authorities (ELM). By using a reference date when locking payroll periods, the system now accurately reflects the correct tax reporting timeframe, ensuring compliance and reducing the risk of errors.

#payroll#tax#Switzerland#ELM

[FIX] l10n_mx_edi: prevent singleton error

PR #103460

Enterprise17.0l10n_mx_ediMEDIUM

This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving invoice generation reliability. This change ensures consistent invoice generation for users.

Original PR description

- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

#invoice#edi#mexico

[FIX] l10n_latam_invoice_document: get sequence when prefix has numbers

PR #235000

Core17.0accountl10n_latam_invoice_documentMEDIUM

This change fixes an issue where LATAM invoices with numeric sequence prefixes would incorrectly restart the invoice sequence, leading to duplicate document numbers. The update adjusts the invoice numbering logic to properly handle LATAM invoice formats, ensuring unique document numbers are always generated.

Original PR description

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

#invoice#latam#accounting#sequence

[FIX] l10n_pe_edi: get sequence when prefix has numbers

PR #101620

Enterprise17.0l10n_pe_ediMEDIUM

This update fixes an issue where LATAM invoices with numeric sequence prefixes would incorrectly restart the sequence, leading to duplicate document numbers. The fix temporarily bypasses sequence filtering for LATAM invoices to ensure correct sequence generation, resolving a potential data inconsistency.

Original PR description

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

#invoice#LATAM#sequence#PE

[IMP] account_edi_ubli_cii: Split fixed taxes into allowance charges or additional invoice lines.

PR #240706

Core17.0account_edi_ubl_ciiMEDIUM

This update aligns Odoo's UBL export process with recent changes introduced in version 18. It now correctly handles fixed taxes, separating those that impact the tax base (converted to allowance charges) from those that don't (represented as separate invoice lines). This ensures accurate tax reporting for UBL invoices.

Original PR description

Context :
In v18+, fixed taxes are handled differently depending on whether they affect the tax base or not.

Before this commit :
All fixed taxes were systematically converted into allowance charges during UBL exports. This behaviour was incorrect, as some fixed taxes (e.g., recupel) do not affect the tax base and should instead be represented as separate invoice lines.

This commit aligns the v17 behavior with the logic introduced in v18+ by distinguishing between the two cases:
- Fixed taxes that affect the base are converted into allowance charges.
- Fixed taxes that do not affect the base are converted into additional invoice lines.

task-5405115
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#UBL#tax#invoice#export

[FIX] stock_delivery: truncate weight

PR #242826

Core17.0stock_deliveryMEDIUM

This update fixes an issue where stock weights were sometimes inaccurate due to rounding discrepancies between the database and cached values. By rounding the picking weight to the 'Stock Weight' precision during calculation, we ensure consistent and reliable weight data used for carrier integrations. This improves the accuracy of shipping calculations and reduces potential errors.

Original PR description

Main:
Picking weight is computed as the sum of move weights.
Although both fields are limited in decimal precision by 'Stock Weight', the sum can produce a value with more decimal places than allowed.

Before:
Digits limitation is applied in db but not in cache, leading to potential inconsistencies when the cached value is used to prepare API requests to carriers.

After:
Picking weight is rounded according to 'Stock Weight' decimal precision directly when computed to enforce precision in cache.

opw-5406560

#stock#weight#accuracy#shipping

[FIX] l10n_it_stock_ddt: generate DDT before completing the picking action

PR #243492

Core17.0l10n_it_stock_ddtMEDIUM

This update fixes an issue where the DDT number wasn't included in delivery reports. The change ensures the DDT number is generated and added to the report before the email is sent, resolving a problem that prevented accurate tracking of delivery documents. This improves the clarity and completeness of shipping notifications for Italian businesses.

Original PR description

When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email.
This fix changes the order to generate the DDT number before sending the email.

Steps to reproduce:
- Create a database with an Italian company and the `l10n_it_stock_ddt` module installed
- Turn on `Settings > Inventory > Shipping > Email Confirmation`
- Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates`
- Edit the `Shipping: Send by Email` template
- Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`.
- Create a SO, validate it
- On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery.
- In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name.
- If you open the report, the title of the PDF is also missing the DDT name.

Ticket [link](https://www.odoo.com/odoo/project.task/5364265)
opw-5364265

#it_accounting#shipping#delivery#ddt

- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall for item in frame.iterator: File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403 File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__ self.html = ''.join(self.irQweb._render_iterall( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall for item in frame.iterator: File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0 File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}' ^^^^^^^^^^^^^^^^^^^ File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__ record.ensure_one() File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one raise ValueError("Expected singleton: %s" % self) ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24) ``` - OPW-5450360

**Issue:** When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences. **Steps to Reproduce:** - Install l10n_pe_edi - Change to PE Company - Duplicate the Customer Invoice journal, give it shortcode "01A" - Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura - Confirm the invoice, it will have name "F F01-00000001" - Duplicate the invoice -> The new invoice has the same sequence number, and the document number is visible Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002" **Cause:** - LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never" - However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex) - This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex - anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence **Solution:** - Add context value "no_anti_regex" to skip sequence exclusion - If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded. - Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats opw-5111844

Context : In v18+, fixed taxes are handled differently depending on whether they affect the tax base or not. Before this commit : All fixed taxes were systematically converted into allowance charges during UBL exports. This behaviour was incorrect, as some fixed taxes (e.g., recupel) do not affect the tax base and should instead be represented as separate invoice lines. This commit aligns the v17 behavior with the logic introduced in v18+ by distinguishing between the two cases: - Fixed taxes that affect the base are converted into allowance charges. - Fixed taxes that do not affect the base are converted into additional invoice lines. task-5405115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Main: Picking weight is computed as the sum of move weights. Although both fields are limited in decimal precision by 'Stock Weight', the sum can produce a value with more decimal places than allowed. Before: Digits limitation is applied in db but not in cache, leading to potential inconsistencies when the cached value is used to prepare API requests to carriers. After: Picking weight is rounded according to 'Stock Weight' decimal precision directly when computed to enforce precision in cache. opw-5406560

When validating a delivery, Odoo did not include the DDT number in the report, as it was generated after rendering the PDF/email. This fix changes the order to generate the DDT number before sending the email. Steps to reproduce: - Create a database with an Italian company and the `l10n_it_stock_ddt` module installed - Turn on `Settings > Inventory > Shipping > Email Confirmation` - Under `Settings > General Settings > Companies > Email Templates` click `Review all Templates` - Edit the `Shipping: Send by Email` template - Under the `Settings` tab, you find the `Dynamic reports` field (which is a `many2many`), add the `DDT report`. - Create a SO, validate it - On the top of the SO, you see the delivery button with one delivery, click it, then validate the delivery. - In the chatter you see the message that was sent, with the `DDT report` PDF attached, with `False` instead of the DDT name. - If you open the report, the title of the PDF is also missing the DDT name. Ticket [link](https://www.odoo.com/odoo/project.task/5364265) opw-5364265