Daily updates from Odoo
Friday, May 8, 2026
10 changes · 19.0
Resolved issues and error corrections
This update resolves an issue where payment reminders wouldn't display properly when the 'Payment' module wasn't installed. The fix ensures the system checks for the necessary 'payment.method' model before attempting to use it, preventing rendering errors and ensuring payment reminders function as expected.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116443 Forward-Port-Of: odoo/enterprise#116079
This update resolves a technical error that prevented the Journal Audit report from correctly displaying data when the 'Load More Limit' was set. The fix ensures accurate report generation by addressing a key error related to data formatting during report expansion.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit >…
Steps to reproduce:
- Install `Accounting` module
- Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1
- Accounting > Review > Journal Audit > Expand Sales
Traceback: `KeyError: 'no_format'`
Cause:
This error occurs when we expand the lines. During the expansion, we [append] a `Load more...` pagination row inside the report lines. In that row, we pass empty [dictionaries] in
`columns`, like: `columns': [{}, {}, {}, {}, {}, {}]`. and we have offset. So, after expanding, there are two lines, and the second one is the Load more line. Because its [columns] contain empty dictionaries, the `no_format` key is not found, which results in a `KeyError`.
Solution:
We are passing a `None` value if `no_format` is not present in the line's columns.
[append]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5765
[dictionaries]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5867-L5878
[columns]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_journal_report.py#L158
opw-6125082This update resolves an issue where account reports with large datasets would crash when attempting to unfold prefix groups. The fix ensures the prefix filter correctly uses account codes instead of names, and skips invalid prefix characters to prevent incorrect grouping. This improves the stability and performance of account reporting for larger databases.
Original PR description
…roup Steps to reproduce: - Set a low value for `prefix_groups_threshold` in account reports so that lines are grouped by prefix (e.g. in databases with large volumes, such as 6k+ lines). - Open a…
…roup
Steps to reproduce:
- Set a low value for `prefix_groups_threshold` in account reports so that lines are grouped by prefix (e.g. in databases with large volumes, such as 6k+ lines).
- Open a report (e.g. Trial Balance or General Ledger).
- Unfold a prefix group.
Issue:
```python
File "/home/odoo/src/enterprise/account_reports/models/account_report.py",
line 5718, in get_expanded_lines_readonly
return self.get_expanded_lines(options, line_dict_id, groupby,
expand_function_name, progress, offset, horizontal_split_side)
File "/home/odoo/src/enterprise/account_reports/models/account_report.py",
line 5707, in get_expanded_lines
lines = self.env[self.custom_handler_model_name]._custom_line_postprocessor
(self, options, lines)
File "/home/odoo/src/enterprise/account_reports/models/account_general_ledger.py
", line 354, in _custom_line_postprocessor
if report._parse_line_id(lines[0]['id'])[-1] ==
('', 'account.report.line', report.line_ids[0].id):
IndexError: list index out of range
```
Cause:
Prefix groups are built based on the displayed line name, which includes
the account code (e.g. "401000 Sales"). However, during unfold, the
filter was applied on `account_id.name`.
As a result, applying a prefix like '4%' on `account_id.name` (e.g. "Sales")
returned no records, leading to empty results and the above crash.
Additionally, prefix grouping could create invalid or meaningless groups
when the extracted prefix character was non-alphanumeric (e.g. spaces or
special characters).
Fix:
- This patch updates the unfold filtering logic to use `account_id.code` when grouping by `account_id`, ensuring that the prefix filter is applied on the correct field.
- Skip non-alphanumeric prefix keys during grouping to avoid generating irrelevant or invalid groups.
opw - 6106726
upg - 3985833This update corrects a minor typo in the automated tests for Odoo's Point of Sale module. The change ensures that test results accurately reflect the order flow, preventing potential issues during processing. This fix improves the reliability of the testing process.
Original PR description
Correct a typo in `test_01_order_flow` assertions. `pdis_order1` was reassigned multiple times; the second assertion should use `pdis_order2`. Task-6065459 Forward-Port-Of: odoo/enterprise#116424 Forward-Port-Of: odoo/enterprise#111917
This update resolves a problem where DIAN XML files (specifically `AttachedDocument` type) weren't being imported correctly, resulting in lost data. The fix ensures the system correctly identifies the file structure, allowing for accurate parsing and data extraction from these important electronic invoices.
Original PR description
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN…
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf However, no strict validation is enforced, so variants should still be supported ### Cause: When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:` This causes issues with documents structured like: ```xml <AttachedDocument> <CustomizationID>Documentos adjuntos</CustomizationID> <ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID> </AttachedDocument> ``` In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian` As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document ### Steps to reproduce: - Install `l10n_co_dian` - Go in Bills and import the test document: `import_attached_document_2` Before the fix, nothing it extracted from the xml opw-6083523 Forward-Port-Of: odoo/enterprise#115599
This update fixes a visual inconsistency in the Point of Sale (POS) interface. Previously, combo products looked different from regular products. Now, both product and combo product cards have a unified style, creating a more consistent and professional look for the customer experience. This improves the overall user experience and brand presentation.
Original PR description
In this commit: --- - Applied the same background styling to combo items as normal product cards. - Ensured visual consistency between product cards on the product screen and in combo configuration popup. | Before | After | | -------- | -------- | | <img width="979" height="447" alt="image" src="https://github.com/user-attachments/assets/6d91e1d7-99d5-47c4-a1bf-6604765d08d5" /> | <img width="979" height="453" alt="image" src="https://github.com/user-attachments/assets/602c9a8f-9e56-4633-84bf-0710cb5debab" /> | task-6103260 Forward-Port-Of: odoo/enterprise#113159
This update resolves a crash issue that occurred when creating Point of Sale (POS) orders with the Avatax module installed. The fix re-introduced a method to correctly identify the customer's shipping information, ensuring order creation stability. This improves the reliability of the POS system for our users.
Original PR description
Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field. This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id. opw-6122280 Forward-Port-Of: odoo/enterprise#115840
This update resolves an issue preventing users from modifying multi-step routes for Romanian warehouses. The fix addresses a coding error that caused a crash when updating warehouse routes, specifically related to accessing data within the system. This ensures that users can now successfully adjust routes without encountering errors.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
This update resolves two issues preventing proper validation of POS orders and successful download of Sales Details reports for the l10n_co_edi_pos module. The fix ensures correct data generation during UBL DIAN export and prevents errors related to data type mismatches, improving the reliability of the POS reporting process.
Original PR description
Steps to reproduce: --- - Install `l10n_co_edi_pos` and configure it. - Set the POS Serial Number in the POS configuration. - Open a POS session, create an order, and validate it. Issues: --- 1. A traceback occurs while validating the order. 2. After fixing the above issue, another traceback occurs when downloading the Sales Details report from the backend. Causes: --- 1. During UBL DIAN data generation, the `name` field is overwritten with `pos_order.l10n_co_edi_pos_name`, which can be empty. 2. `l10n_co_edi_pos_serial_number` is accessed on an invalid type (ID/list instead of a recordset). Fixes: --- - Preserve the original `name` if `l10n_co_edi_pos_name` is not set. - Ensure `config_ids` is always a recordset and safely compute serial numbers using `mapped`, joining unique values. task-6051285 Forward-Port-Of: odoo/enterprise#111306
This pull request corrects an error in the CFDI (Mexican electronic invoice) generation process when calculating payroll for employees with IMSS (Mexican Social Security Institute) disabilities. The fix ensures the correct XML node is populated to declare these disabilities, resolving issues with incorrect invoice amounts and preventing validation errors.
Original PR description
Several error are logged in the chatter when signing a payslip that includes an IMSS incapacity time off. Steps to reproduce: * Install l10n_mx_hr_payroll_account modules * Switch to "INNOVACION…
Several error are logged in the chatter when signing a payslip that includes an IMSS incapacity time off.
Steps to reproduce:
* Install l10n_mx_hr_payroll_account modules
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company
* Go to Employees and open Cesar Osbaldo Cruz Solorzano
* Click on "Time Off" smart button and create a new time off with
"Disability due to illness (IMSS)" type for "02/01/2026"(Any date).
* Go to Payroll > Payslips > Payslips and create a new pay run
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly'
and the Period '01/01/2026 -> 01/31/2026'
* Click on Continue, select Cesar and click on Select
* Open the payslip, click on "Validate" and "Ok"
* Mark as paid, open the "Journal Entry" from the smart button and click
on "Post".
* Back to the payslip, and click on "Generate CFDI" button.
* An error is added to the chatter.
### Missing node to declare disabilities
Translated message
```py
An error occurred while signing the CFDI document with the government:
Code: NOM111 Message: Unclassified error. Extra Info: The "Incapacidades"
(Disabilities) node must be reported if the perception key 014
"Subsidios por Incapacidad" (Disability Subsidies) is included, or if
the deduction key 006 "Descuento por incapacidad" (Disability Deduction)
is included.
```
Legal Context:
According to Mexican law, IMSS disabilities must be declared in a specific XML node.
There are two primary scenarios for reporting these amounts:
* Deduction (Type 006): The employer does not pay for these days, as the IMSS is responsible for the payment to the employee. This is the most common scenario.
* Perception (Type 014): The employer pays for these days as a superior benefit. For example, by law, the IMSS does not pay for the first 3 days of a disability due to illness, and employers are not obligated to cover them either. However, companies offering superior benefits may choose to pay these days as a "Disability Subsidy."
Solution:
The chosen approach is to configure the Deduction node.
For the `l10n_mx_regular_pay_imss_disabilities` rule, the `l10n_mx_concept` has been set to `l10n_mx_concept_d6` (D06 - Disability Deduction). This ensures the required node is added.
### Missing "ImporteMonetario" attribute
Translated message
```
An error occurred while signing the CFDI document with the government:
Code: NOM95 Message: The attribute "Deduccion:Importe" does not match
the sum of the "Incapacidad:ImporteMonetario" nodes, as the key
expressed in "Nomina.Deducciones.Deduccion.TipoDeduccion" is "006".
```
Problem:
The "Incapacidades" node requires the "ImporteMonetario" attribute, which should represent the sum of the monetary value associated with the disabilities.
Solution:
Add the "ImporteMonetario" attribute and calculate its value using `l10n_mx_daily_salary`.
### Invalid "DiasIncapacidad" format
```py
An error occurred while signing the CFDI document with the government:
Code : 301 Message : XML mal formado Extra Info : Element
'{http://www.sat.gob.mx/nomina12}Incapacidad', attribute
'DiasIncapacidad': '4.0' is not a valid value of the local atomic type.
```
Problem:
Altough the defaultdict where the values are sum up, `number_of_days` is a float field, and when we get back the value, it is a float, adding for example 4.0 instead of 4, which is not a valid value.
Solution:
Cast the value to int.
### Duplicate deduction on disabilities
```py
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Salary Slip - Cesar Osbaldo Cruz Solorzano - 05/01/2026 - 05/15/2026
- Salary rule: ISR (Income Tax) (ISR)
- Error: TypeError('cannot unpack non-iterable NoneType object') while
evaluating
"
def find_rates(x, rates):
for low, high, fix, rate in rates:
if low <= x <= high:
return low, high, fix, rate
gross = categories['GROSS']
result = 0
if gross:
isr_table = payslip._rule_parameter('l10n_mx_isr_tables')[version.schedule_pay]
low, high, fix, rate = find_rates(gross, isr_table)
result = -((gross - low) * rate + fix)
period_factor = payslip._rule_parameter('l10n_mx_schedule_table')[version.schedule_pay]
if period_factor >= 15:
period_factor = (period_factor / 30) * (365 / 12)
min_wage = payslip._rule_parameter('l10n_mx_daily_min_wage') * period_factor
if gross <= min_wage:
result_qty = 0.0
"
```
Problem:
The IMSS incapacity amount is being deducted twice:
1. During "Worked Days" calculation, the IMSS incapacity is already not considered because the work entries belong to the "Unpaid Work Entry Types" of "Mexico: Regular Pay" structure.
2. During "Salary Computation", the `IMSS_DISABLE` salary rule deducts another time because it is in the `TAXABLE_ALW` category, and this one is deducted in the `NET` rule.
When the incapacity covers more than half of the period (e.g., 20 days in a monthly schedule), the double deduction causes the NET to become negative. This prevents the ISR rule from finding a correct stage in the tax tables, leading to a traceback.
Example: For a monthly wage of 30,000.0 and 5 incapacity days:
- The total amount in "Worked Days" is 25,000.0 (incapacities already deducted).
- The IMSS_DISABLE rule calculates -5,000.0, and when the NET rule is calculated, the incapacities are deducted again. Total NET becomes 16,843.84 instead of the expected 20,834.85.
Solution:
Change the rule category to `INTERMEDIARY_COMPUTATION` and avoid the double deduction when the `NET` is calculated, as it is already considered in the "Worked Days".
### Absenteeism and Disabilities
By law, the calculation of IMSS contributions depends on these two types of unpaid days:
* Disabilities: Refers to medical leave issued by the Institute (IMSS).
* Absenteeism: Refers to unjustified leave; apply for periods of fewer than 8 days.
Source: [Artículo 31](https://www.imss.gob.mx/sites/all/statics/pdf/leyes/LSS.pdf)
Translated text:
> Article 31. When wages are not paid due to the employee's absence from work, but the employment relationship persists, the monthly contribution shall be adjusted according to the following rules:
> I. If the employee's absences are for periods of fewer than eight consecutive or non-consecutive days, contributions shall be calculated and paid for such periods only for the sickness and maternity insurance...
If the employee's absences are for periods of eight consecutive days or more, the employer shall be released from the payment of employer-employee contributions...
> IV. In the case of absences covered by medical disabilities issued by the Institute, it shall not be mandatory to cover the employer-employee contributions, except regarding the retirement branch.
The following table summarizes the contribution requirements based on the type of absence:
Insurance Branch | Section I (Absenteeism) | Section IV (Disability)
--------------------------------|-------------------------|------------------------
Sickness and Maternity | Paid | Not Paid
Disability and Life | Not Paid | Not Paid
Severance and Old Age | Not Paid | Not Paid
Work Risk | Not Paid | Not Paid
Daycare and Social Benefits | Not Paid | Not Paid
INFONAVIT | Not Paid | Paid
Retirement | Not Paid | Paid
The type of unpaid day to be considered depends on the specific insurance branch being calculated within the employer-employee contributions.
Incorrect values in the XML
The signing process completes without errors, but some amounts in the generated XML are incorrect.
Problem:
The introduction of the Deduction 006 (Disability) directly impacts the calculation of the SubTotal and Total attributes in the Comprobante node.
For a monthly payslip with a wage of 30,000.00 (daily salary of 1,000.00) and 5 disability days (work risk), the values are calculated incorrectly as follows:
Attribute | Calculation | Actual Value | Correct Value
---------------------|----------------------------------|--------------|--------------
Comprobante:SubTotal | Sum of Perceptions (P01) | 25000.00 | 30000.00 (1)
Comprobante:Total | SubTotal - Total Deductions (2) | 15803.74 | 20803.74
(1) Must include the 5,000.00 from disabilities to balance the deduction.
(2) Total Deductions = D06 (5,000.00) + ISR (3,451.65) + IMSS (744.61) = 9,196.26.
The Total is currently undercalculated because the 5,000.00 is being deducted from the SubTotal that already had those 5,000.00 excluded.
Solution:
Since the `SubTotal` is derived from Perceptions, and the "(P01) Salaries, Wages, Stripes, and Day Labor" amount is driven by the `GROSS_WITHOUT_HOLIDAY` rule, the disability amount must be added. This balances the Deduction 006, ensuring `SubTotal` is correct.
* Add test for CFDI with incapacities.
target: 19.0
task-6066160