Thursday, February 19, 2026
18 changes · 19.0
New functionality added to Odoo
This update adds a new module that automatically sends CFDI XML and PDF files alongside payslips via email. This simplifies compliance with Mexican tax regulations by streamlining the delivery of required payroll documents, improving efficiency and reducing manual effort.
Original PR description
Introduce a new module to enable sending CFDI XML with payslips. task: 5114611
Enhancements to existing features
This update allows users to manage multiple bank statements and reconciliation lines simultaneously, streamlining the accounting process. Previously, users could only handle one statement at a time. This enhancement increases efficiency and reduces manual effort for large-scale reconciliation tasks.
Original PR description
This commit will allow to do the set account, set partner and apply reco models on multiple lines. To select multiple line you need to use alt + click and then you will have button on top to trigger the actions. - The set partner function was modified to work with multiple statement lines and keep all existing functionality (modify line with same partner_name) - The trigger reconcile model function was also modified to work with multiple statement lines - The set account function was not touched because we use the aml_id of the suspense as a parameter but here we will have multiple suspense line to modify. Since we are doing this change in stable, we created a new function set_account_multiple_bank_statement_line. This function will have the same behavior for reco models as the basic set account. task-5253778
Resolved issues and error corrections
This update adjusts the calculation for Swiss CH reports to accurately include account 2970, which represents the 'Annual profit or annual loss'. The previous formula excluded this account, leading to incorrect report data. This change ensures compliance with Swiss accounting standards.
Original PR description
This recent commit:
odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba
changed the formula for `account_financial_report_line_ch_290_a_balance` from:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
to:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
The main goal of the commit was to remove the unaffected earnings account from the CH reports. While doing so, the formula was also modified by replacing `account_id.code = 2991` with `account_id.code = 2970`.
However, since the condition uses the `<` operator, the account with `code = 2970` is not taken into account. Account `2970` is the last account that should be considered before `Annual profit or annual loss`. see:
https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L106
Ticket [link](https://www.odoo.com/odoo/project.task/5387092)
opw-5387092This update fixes a discrepancy in accounting calculations within the l10n_mx_edi_pos module. Previously, the POS was not correctly loading necessary assets, leading to incorrect amounts compared to Python calculations. This change ensures accurate accounting for transactions processed through the POS in Mexico.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5935191
This update resolves an issue where Odoo was incorrectly including a UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and ensuring seamless payment processing for our European users. This improves compatibility with major banking systems.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#105792 Forward-Port-Of: odoo/enterprise#105518
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked unless a customer is selected, preventing unintended public disclosures of invoices. This improves data accuracy and compliance.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 --- Forward-Port-Of: odoo/enterprise#106943
This pull request resolves an issue where the Odoo enterprise template inheritance fails due to an outdated XPath targeting a renamed button. The fix updates the XPath to correctly identify the 'Add as link(s)' button, restoring proper dialog rendering and preventing errors.
Original PR description
[FIX] ai_documents_source: fix xpath after button rename
There is an issue where the template inheritance fails with an
OwlError because the xpath targets a button containing the text
"Paste Link(s)", which no longer exists.
How to reproduce:
- open the SelectAddDocumentCreateDialog
- trigger the dialog rendering
- the view crashes with an Owl lifecycle error
Issue:
- the xpath contains(., 'Paste Link') cannot locate the element
- the button label was renamed to "Add as link(s)" in commit
a4ca17329d7c21be487a53c5e0b9afa39e6dad3a
- template inheritance fails and raises an OwlError
Resolution:
Update the xpath to correctly target the new button definition
("Add as link(s)") instead of the old label, preventing the
element lookup failure and restoring proper dialog rendering.
Task-5946396This change reverses a recent update that caused all upsell quotes to be canceled, disrupting business processes. The previous code incorrectly called a function that resulted in errors and prevented proper filtering of alternative quotes. This reversion restores the expected functionality.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update addresses a recent discovery that the SAT (Mexican tax authority) sometimes accepts accented characters in invoices. Previously, the system automatically removed accents to comply with SAT rules. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the full extent of SAT acceptance of accented characters.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) ---- *Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.* Forward-Port-Of: odoo/enterprise#107677
This update resolves an issue where grouped tax reports were failing when invoices included both positive and negative tax amounts. The fix ensures that all tax lines, including those with negative balances (CABA moves), are correctly processed, preventing report errors. This ensures accurate tax reporting for all invoice types.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
This update resolves an issue preventing standard payroll users from accessing the 'One-time payments' section within Swiss company contracts. The fix allows payroll officers and managers to open wages, ensuring proper access to critical payroll data. This improves usability for key personnel.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467 Forward-Port-Of: odoo/enterprise#107628 Forward-Port-Of: odoo/enterprise#106598
This update ensures Odoo's Mexican payroll system accurately reflects the latest Social Security Law regarding minimum wage exemptions. Specifically, it adjusts calculations for IMSS, ISR, and subsidy contributions when employee earnings are at or below the minimum wage, streamlining XML generation and improving compliance. Existing tests have been updated to align with these changes.
Original PR description
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage…
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit. - The next rules are zeroed out when the gross salary is equal or less than the minimum wage: - IMSS_EMPLOYEE: IMSS Total (Employee) - ISR: ISR (Income Tax) - SUBSIDY: Used Subsidy - IMSS_EMPLOYEE and ISR are omitted from the generated XML. - As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed. - The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0. This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage. target: 19.0 task-5226971
This update resolves a potential issue where global invoices sent from the POS could fail due to timeouts when interacting with the SAT portal. Increasing the timeout duration for these requests helps ensure invoices are successfully transmitted, preventing duplicate documents and improving the overall reliability of the Mexico tax filing process. This addresses a reported problem impacting users in Mexico.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of how contracts are created or modified. Previously, this date was only calculated during a manual archive process, leading to inaccuracies. This fix automatically updates the date whenever a new contract or version is created or changed, improving reporting and payroll accuracy.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.This update corrects a problem that prevented wage statements in Switzerland from being properly sent out. The fix ensures accurate and timely delivery of these important financial documents, complying with Swiss regulations. This resolves a previous error impacting payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#107827
This update fixes a bug where discounts on subscription orders were unintentionally reset when an upsell was added. Previously, confirming an upsell would erase the original subscription discount. This change ensures discounts are correctly applied across both the subscription and any subsequent upsells, improving order accuracy and customer satisfaction.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270
This update resolves a problem where kiosk transactions would unexpectedly disconnect, leading to lost sales. It also improves the user experience by providing clearer error messages when issues occur during these transactions. This ensures smoother operation for self-order kiosks.
Original PR description
This PR fixes the scneario when the terminal transaction times out during kiosk request. It also adapts the error messages shown to the user whenever an error occurs community: https://github.com/odoo/odoo/pull/249101 task-5946033
This update automatically calculates and transmits the 2050 pension contribution amount for employees in Switzerland. This ensures accurate compliance with Swiss tax regulations and avoids potential errors in payroll processing. The change corrects a previous issue related to the calculation of this specific contribution.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#103856 Forward-Port-Of: odoo/enterprise#103453