Wednesday, July 15, 2026
6 changes · saas-19.3
New functionality added to Odoo
This update adds functionality to seamlessly integrate with Taiwan's E-invoice system for point-of-sale transactions. It automatically transfers relevant data from the POS order to the invoice, simplifying the e-invoice creation process and ensuring compliance with local regulations. This improves the user experience for businesses operating in Taiwan.
Original PR description
This module adds extra functions on the point of sale for l10n_tw_edi_ecpay, passing values from pos order to invoice for creating Taiwan E-invoice task-5122414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255980
Enhancements to existing features
The Mexican payroll localization now includes the latest SAT payroll perception and deduction concepts used for CFDI reporting. This helps businesses keep payroll documents aligned with current Mexican tax authority requirements.
Original PR description
Adds the new SAT perception and deduction concepts to the Mexican payroll CFDI concept catalog. task-6295124 Forward-Port-Of: odoo/enterprise#121568
Resolved issues and error corrections
This fix prevents payroll screens from crashing when users add Daily Salary or Integration Factor fields to Mexican payslip forms with Odoo Studio. It ensures these values are only calculated once the needed employee and contract details are available, so users can create off-cycle payslips and review salary information safely.
Original PR description
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule…
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.
### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.
### Current behavior:
A traceback is raised depending on the field added
#### For the Daily Salary field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```
#### For the Integration Factor field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
self.ensure_one()
File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```
### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.
### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.
target: 19.0
task-6267003
Forward-Port-Of: odoo/enterprise#121718Automatic bank statement reconciliation now gives failed lines one retry before excluding them. This helps avoid losing items because of temporary system issues, improving reliability for accounting teams.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
Rental pickup and return receipts now include the separate invoicing and shipping address details when customer addresses are enabled. This prevents missing address information on customer-facing rental documents and helps ensure deliveries, returns, and billing are handled with the right contact details.
Original PR description
**Steps to Reproduce:** 1. Install sale_renting and enable "Customer Addresses" in the settings 2. Confirm a rental order with shipping address and invoice address 3. Print the Pickup and Return Receipt **Issue:** Only the general partner address is printed; the invoicing/shipping `information_block` is missing **Why this happens:** The 19.2 layout rework (abf18ba250bae2f390f93f70abef1d7fb601c524) switched `web.external_layout` calls to accept macro arguments (e.g. `address="address"`). report_rental_order_document was only partially migrated: `address` was set above the t-call and passed as an argument, but `information_block` was left as a t-set inside the call body, which was the old convention. Once external_layout is called with explicit arguments, content t-set nodes in the body no longer populate the callee's scope, so address_layout's `t-if="information_block"` never triggers. opw-6366091 Forward-Port-Of: odoo/enterprise#124077
Opening the manufacturing planning view now ignores maintenance requests with incomplete scheduling information instead of failing. This prevents a blocking error for planners when a maintenance request has an end date but no start date.
Original PR description
#### Issue: Opening the MRP planning view could raise a traceback when a maintenance request had a ``Scheduled End`` but no ``Scheduled Date``. ```TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'``` #### Cause: In `_get_maintenances_intervals`, `mrp_maintenance` loaded maintenance intervals for gantt unavailability without filtering out incomplete rows. If an interval like False, datetime reached Intervals, it crashed when comparing None with a datetime. #### Fix: Filter out incomplete maintenance intervals in the gantt query. Also added a constraint on `maintenance.request` to require `schedule_date` and `schedule_end` to either both be set or both be empty in this community PR: https://github.com/odoo/odoo/pull/265208 opw-6225772 Forward-Port-Of: odoo/enterprise#117710