Friday, July 31, 2026
12 changes · saas-19.3
Resolved issues and error corrections
Ri.Ba. batch payments can now be validated when the company bank account uses a valid San Marino IBAN, not only an Italian IBAN. This prevents payment file generation from failing for eligible San Marino accounts and ensures the generated records keep the required format.
Original PR description
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a…
**_Steps to reproduce :_** - Install l10n_it_riba. - Configure a company with a San Marino (SM) IBAN as the bank account for the journal used for Ri.Ba. - Create a customer payment and add it to a Batch Payment using the Ri.Ba. payment method. - Validate the Batch Payment. **_Observed behavior :_** The validation fails with the error: `Only bank accounts with an Italian IBAN are allowed to use Ri.Ba. payments` **_Cause :_** The Ri.Ba. validation logic only accepts IBANs with the IT country code and incorrectly rejects valid San Marino (SM) IBANs. **_Fix :_** - Update the Ri.Ba. IBAN validation to accept both Italian (IT) and San Marino (SM) IBANs when generating Ri.Ba. payment files. - While validating Batch Payments for SM IBANs, we observed that the extracted value could overlap with the branch code portion, causing the generated RIBA record to exceed the expected 120-character length. This change updates the extraction logic to prevent overlap and ensure compliance with the required record format. **_opw_** - 6303820 Forward-Port-Of: odoo/enterprise#126082 Forward-Port-Of: odoo/enterprise#121439
Fixes a Timesheet issue where selecting projects could crash the page and keyboard shortcuts could accidentally open the creation form. Users can now select items and ranges more reliably with the keyboard, improving day-to-day timesheet entry stability.
Original PR description
Previously, selecting items in the project view caused a crash because the component incorrectly iterated over group metadata instead of the underlying `.suggestions`. Additionally, keyboard navigation (Space or Shift+Arrow) inappropriately triggered the creation form, leading to errors on unmounted components. This commit: - Fixes the mapping logic to correctly iterate over `.suggestions`. - Decouples the selection logic from form opening, allowing Space to toggle selection and Shift+Arrow to select ranges smoothly.
AI-generated fields now avoid a Gemini 2.5 limitation that caused them to fail when a fixed response format and web search were requested together. Instead of crashing, the system skips web search in that case so users still receive a value.
Original PR description
Steps to reproduce ------------------ 1. Compute an AI field on a database that uses Gemini 2.5. -> we get a traceback (NotImplementedError) instead of a value. Why it's happening ------------------ An AI field asks the model to answer in a fixed format and to search the web in the same request. Gemini 2.5 does not support both together, so the Google service raises an error and the call fails. The fix ------- On Gemini 2.5, when a fixed format is asked, we drop the web search instead of raising. We still raise when tools are used. opw-6322046
This fix prevents German point-of-sale transaction cancellations from being rejected when the original active transaction lacks receipt schema details. It adds a safe default cancellation receipt format only when needed, helping stores complete cancellations reliably while preserving existing transaction data.
Original PR description
When cancelling active transactions, the schema was forwarded as-is from the listed transaction. ACTIVE transactions can have an empty schema, and Fiskaly rejects the cancellation PUT with:
{
"code": "E_TX_NO_TYPE_DEFINED",
"message": "`schema.raw.process_type` must be defined for
updating or finishing a transaction",
"status_code": 409,
"error": "Conflict"
}
Fall back to a minimal CANCELLATION receipt schema when the transaction has no schema, while preserving any schema that is already present.
opw-6345005
Forward-Port-Of: odoo/enterprise#122130Fixes an error that could prevent the Mexican payroll accounting EDI module from installing correctly. This ensures payroll setup can complete without an unexpected validation crash related to employee or company tax information.
Original PR description
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`]. This typo was introduced in:…
[`_l10n_mx_is_curp_needed`] was called with self instead of slip. However, the method expects a payslip record from its caller, [`_compute_issues`].
This typo was introduced in:
odoo/enterprise@07201466e54f28c6d295d63b908e9a65e39f4862
```py
/home/odoo/src/enterprise/saas-19.3/hr_payroll/models/hr_payslip.py(1913)_compute_issues()
-> issues = generate_issue(slip, context)
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(235)_issue_mx_warnings()
-> if not slip.company_id.l10n_mx_curp and self._l10n_mx_is_curp_needed():
/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py(322)_l10n_mx_is_curp_needed()
-> not self.company_id.partner_id.is_company
/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py(1726)__get__()
-> record.ensure_one()
> /home/odoo/src/odoo/saas-19.3/odoo/orm/models.py(5344)ensure_one()
-> raise ValueError("Expected singleton: %s" % self)
```
This causes module installation to fail with:
```py
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 779, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_mx_hr_payroll_account_edi failed: file l10n_mx_hr_payroll_account_edi/data/hr.employee.type.csv could not be processed:
Ocurrió un error desconocido durante la importación: <class 'ValueError'>: Expected singleton: res.partner(7, 9)
```
upg-4468049
[`_l10n_mx_is_curp_needed`]: https://github.com/odoo/enterprise/blob/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L235
[`_compute_issues`]: https://github.com/odoo/enterprise/blob/saas-19.3/hr_payroll/models/hr_payslip.py#L1904-L1913
Forward-Port-Of: odoo/enterprise#126096
Forward-Port-Of: odoo/enterprise#125623This fixes an error that could block the Employees list when users viewed employees from multiple companies and included the document count field. The list now calculates document counts separately for each relevant employee/company setup, so HR users can use multi-company views without interruption.
Original PR description
Steps to reproduce: ------------------- 1. Install `documents_hr` and `web_studio` with demo data. 2. Add `document_count` to the Employees list view via Studio. 3. Create a second company with an…
Steps to reproduce:
-------------------
1. Install `documents_hr` and `web_studio` with demo data.
2. Add `document_count` to the Employees list view via Studio.
3. Create a second company with an employee, enable multi-company.
4. Open Employees list, click **All** in the search panel.
Issues:
------
Issue 1:
```python
File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 25, in _compute_document_count
if not self.company_id.documents_hr_settings:
File "/home/odoo/odoo/community/odoo/orm/fields.py", line 1429, in __get__
record.ensure_one()
File "/home/odoo/odoo/community/odoo/orm/models.py", line 5640, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.company(1, 2)
```
Issue 2:
```python
File "/home/odoo/odoo/enterprise/documents_hr/models/hr_employee.py", line 31, in _compute_document_count
('partner_id', '=', self.work_contact_id.id)
File "/home/odoo/odoo/community/odoo/orm/fields_misc.py", line 117, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(9, 8, 7)
```
Cause:
---------
https://github.com/odoo/enterprise/blob/38674448e387159d28f98c1678856fcaf5f7f52e/documents_hr/models/hr_employee.py#L23-L48
1. The document count computation assumes all employees belong to the same company by directly accessing `self.company_id.documents_hr_settings`. In a multi-company environment, `self` may contain employees from different companies, making self.company_id a multi-recordset and triggering a singleton error.
2. Similarly, when `documents_hr_settings` is disabled, the fallback computation accesses `self.work_contact_id` on a multi-recordset, causing another singleton error.
Solution:
-----------
Split the employees based on whether `documents_hr_settings` is enabled and compute each group separately.
Additionally, use the current employee's `work_contact_id` in the fallback computation to avoid singleton error.
**NOTE:**
This has been resolved from saas-19.4 onward with this improvement [commit](https://github.com/odoo/enterprise/commit/d018d8205300b434728129e199ae048cefbaa296).
opw-6351141
Forward-Port-Of: odoo/enterprise#126099
Forward-Port-Of: odoo/enterprise#124826This fixes how Mexican electronic invoices calculate payment balances when exchange rate differences are involved. Payments and credit notes are now applied in the correct chronological order, preventing incorrect remaining or paid amounts on official payment documents.
Original PR description
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled.…
### Issue: Attributes of DoctoRelacionado node in the XML display an incorrect value because the exchange rate difference entry distorts the calculation, even though the invoice was fully settled. https://drive.google.com/file/d/1ntQny0o8bkkfYtY5ZNBK0Yq7Rq0I-yfz/view ### Fix: Sorting partials by "not exchange_move_id" first broke the chronological order whenever the invoice/payment partial itself carried an exchange difference (e.g. a foreign currency payment settled at another rate). This made the residual-chain algorithm consume the credit note's "other_residual" on the wrong payment, so ImpSaldoAnt/ImpPagado/ ImpSaldoInsoluto in the payment CFDI's DoctoRelacionado stayed wrong even though the invoice was fully paid. Populate the exchange move mapping in a separate first pass and sort the partials purely by date/id, so credit notes are always deducted from the correct payment. task-id:[6363092](https://www.odoo.com/odoo/project/49/tasks/6363092) Forward-Port-Of: odoo/enterprise#126061 Forward-Port-Of: odoo/enterprise#124882
This fixes an error that could prevent rental product availability from loading on the website. The change restores the expected parameter names so the storefront can correctly request available rental dates.
Original PR description
Error: ``` WebsiteSaleRenting.renting_product_availabilities() missing 3 required positional arguments: '_product_id', '_min_date', and '_max_date' ``` Cause: - The function `renting_product_availabilities()` had its argument names changed from `product_id, min_date, max_date` to `_product_id, _min_date, _max_date` by this linting [PR]. - Whereas the client-side passes the arguments with the names `product_id, min_date, max_date` [1] this causes the error to occur. Solution: - Restored the original parameter names (removed the underscore). [PR]: https://github.com/odoo/enterprise/pull/100770/commits/c226063817c9dbbb1aa5aa18aa6ce09d05d0b559#diff-996b84579dc5aae4ad25c60f99106e2e369fed8f475a0bc368aaf650aecfd126L71-R68 [1]: https://github.com/odoo/enterprise/blob/6209dc66d00fdc6a5de5c67dbe5f0c513fb3eced/website_sale_renting/static/src/interactions/daterange_picker.js#L169-L173 sentry-7324955313
Orders in self-service point of sale are now printed as soon as payment is completed in pay-after-each mode. This prevents missed kitchen or receipt printing when customers leave before the confirmation page loads.
Original PR description
In pay after each mode, sometime the customer isn't waiting the redirection to the confirmation page after payment. In that case the order is not printed because the printing is done in the confirmation page. This commit ensures that the order is printed when the order is paid in pay after each mode.
Payroll users now see a dedicated list of only the time off records that need attention when reviewing pay run errors. This avoids confusion from reopening the same screen and helps users resolve the exact records blocking payroll processing.
Original PR description
## Steps to reproduce: - Create a pay run with an error in the Time Offs step. - Click Continue. - Click Review Time Offs. ## Issue: Review Time Offs reused the regular Time Offs Gantt action. Since the user was already on the time off screen, opening it could look like nothing happened. The Gantt view was also misleading because it displayed all time off records for employees having at least one problematic record, instead of showing only the records that required review. ## Fix: Open a dedicated Time Offs to Review list/form action on hr.leave. The action now uses a domain matching only the problematic time off records for the pay run, so users can review and act directly on the records causing the error. Task-6361141
The Partner Ledger email wizard now opens correctly when multiple companies use different currencies. This prevents a crash during recipient calculation, allowing finance teams to send reports by email reliably in multi-company setups.
Original PR description
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard…
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with: ``` psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist ``` ### Current behavior before PR To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`. Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation. ### Desired behavior after PR is merged `_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged. ### Steps to reproduce 1. Have several companies using different currencies. 2. Select more than one of them in the company switcher. 3. Open **Accounting > Reporting > Partner Ledger**. 4. Click **Send by email** → the wizard crashes on opening. Video: https://drive.google.com/file/d/1skpg7YDtxcY1PCtURyzk5PdFPi7ZPreG/view A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`. I've created the task #6362131 for this issue Forward-Port-Of: odoo/enterprise#124900 Forward-Port-Of: odoo/enterprise#122897
The POS preparation display order-count badge now uses the same rules as the preparation screen, so orders kept open past midnight remain counted correctly. Orders removed from the screen by a reset are no longer incorrectly included in the badge, reducing confusion for restaurant and shop staff.
Original PR description
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The…
Steps to reproduce: - Configure a preparation display on a POS config with a product category - Place an order and leave it in a non-final stage - Keep the session open past midnight Issue: The kanban order-count badge drops the order once its create_date falls behind "today", while the preparation screen still lists it. The same divergence makes the badge keep counting an order that a "Reset" already removed from the screen. _compute_order_count() scoped its search on pos_config_id and create_date >= today, whereas the screen is built by get_preparation_display_order() from _get_open_orders_in_display() and _get_stageless_orders_in_display(), which have no date filter and instead bound the set by the order stage `done` flag and the session state. An order open across midnight is therefore in the screen set but not in the badge set. Conversely reset() marks the current stage done, which drops the order from the screen set, but the badge only skipped orders whose latest stage is the final stage, so an order reset while still in the first stage stayed counted. opw-6414302 Forward-Port-Of: odoo/enterprise#126139 Forward-Port-Of: odoo/enterprise#125984