Daily updates from Odoo
Friday, July 31, 2026
61 changes
9 changes
Enhancements to existing features
The Timesheet Assistant now lets users move through suggestions with the keyboard, select individual items, and select ranges using Shift plus arrow keys. This improves accessibility and makes reviewing and managing timesheet suggestions faster for users who prefer keyboard workflows.
Original PR description
Implement full keyboard controls for managing timesheet suggestions to improve accessibility and user efficiency. This adds support for the following interactions: - ArrowUp / ArrowDown to navigate focus through rows - Space to select/deselect the focused item (and set the selection anchor) - Shift + Arrows to select continuous ranges of suggestions task: 6267620 Forward-Port-Of: odoo/enterprise#125027 Forward-Port-Of: odoo/enterprise#120437
Resolved issues and error corrections
This fix updates the Hungarian Intrastat tax return process to match recent changes in the Hungarian reporting setup. It prevents errors during return generation, helping businesses submit the required Intrastat information reliably.
Original PR description
Here https://github.com/odoo/odoo/pull/253556, we made few changes in the `l10n_hu` report. We basically split some expresions into multiple small one. This has been done for the integration of ec sales list (a60). But hu intrastat was still using the old expressions, leading to an error. This commit aims to adapt the intrastat code to fit with the new a60 expressions. no-task Forward-Port-Of: odoo/enterprise#122662
Ri.Ba. batch payment validation now accepts valid San Marino bank accounts in addition to Italian ones. This prevents payment file generation from being blocked for companies using San Marino IBANs and keeps the exported record format compliant.
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
This fix prevents crashes when selecting projects in the timesheet grid and makes keyboard selection behave as expected. Users can now use Space and Shift+Arrow to select items without accidentally opening forms or causing errors.
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. Forward-Port-Of: odoo/enterprise#126248
This fix prevents German point-of-sale transaction cancellations from being rejected when earlier transaction data lacks receipt details. It automatically uses a minimal cancellation receipt when needed, helping stores complete cancellations reliably while keeping existing transaction details unchanged.
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#122130The Partner Ledger email wizard now opens correctly when several companies use different currencies. This prevents a crash during recipient calculation, allowing finance teams to send reports by email without interruption.
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
Corrected a small payroll validation error that could prevent the Mexican payroll accounting EDI module from installing successfully. This helps ensure companies using Mexican payroll localization can install or upgrade the module without encountering an unexpected failure.
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 how Mexican electronic payment documents calculate related invoice balances when exchange rate differences and credit notes are involved. Businesses should see accurate paid and remaining amounts in CFDI payment XMLs, reducing reporting errors after invoices are fully settled.
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
The POS preparation display badge now counts the same active orders that appear on the preparation screen. This prevents overnight orders from disappearing from the badge too early and stops reset orders from being counted after they are removed from the screen.
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
12 changes
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
6 changes
Enhancements to existing features
The bank reconciliation setup now handles long payment references much more efficiently when creating automatic reconciliation rules. This prevents memory errors and reduces delays for customers processing bank statement lines with lengthy transaction descriptions.
Original PR description
When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5…
When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference. ### Current Implementation The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`. ### Proposed Fix This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity. The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced. Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process ### speedup In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption. Because of the memory consumption it was not possible to gather timing value on the current version. Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database (831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms. Forward-Port-Of: odoo/enterprise#118824
Resolved issues and error corrections
This fixes how Mexican electronic payment documents calculate related invoice balances when foreign currency exchange differences are involved. Payments and credit notes are now applied in the right order, helping ensure XML amounts match fully settled invoices and reducing compliance or reconciliation confusion.
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#125475 Forward-Port-Of: odoo/enterprise#124882
This fix ensures active German POS transactions can be cancelled even when their transaction details are missing required receipt information. It avoids rejection by the certification service by supplying a minimal cancellation receipt only when needed, while keeping existing transaction data unchanged.
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#122130Fixed an issue that could crash the Employees list when document counts were shown across multiple companies. This keeps HR users able to view all employees reliably in multi-company environments, including when document settings differ by company.
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#124826The POS preparation display badge now counts the same active orders shown on the preparation screen, including orders left open overnight. It also stops counting orders that were removed from the screen after a reset, reducing confusion for restaurant and retail 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
Sending the Partner Ledger report by email no longer crashes when multiple companies use different currencies. This ensures the email wizard opens reliably for accounting teams working in multi-company, multi-currency environments.
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
8 changes
Resolved issues and error corrections
This fix prevents cancellation attempts in German point-of-sale certification from being rejected when an active transaction lacks receipt details. It adds a safe default cancellation receipt only when needed, helping stores avoid failed cleanup of active transactions 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#122130Employees lists could fail when showing document counts across multiple companies. The update calculates counts separately for each relevant employee group, so HR users can open the full employee list without errors in multi-company setups.
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#124826The POS preparation display order-count badge now uses the same logic as the preparation screen. This keeps counts accurate for orders left open overnight and for orders removed by a reset, reducing confusion for staff monitoring kitchen or preparation queues.
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
Rental orders using a custom Make-to-Order buying route now correctly create the expected return transfer when the order is confirmed. This prevents missing return logistics for rented products, helping teams track rentals reliably from delivery through return.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322 Forward-Port-Of: odoo/enterprise#126078 Forward-Port-Of: odoo/enterprise#124097
Peruvian electronic invoices now use the current SUNAT-required address structure for UBL 2.1. This helps invoices validate correctly by formatting district and urban subdivision information according to the latest rules.
Original PR description
Update electronic invoicing address nodes to align with current SUNAT requirements. This transitions the geographic data formatting from the legacy UBL 2.0 schema to the standard UBL 2.1 specification, ensuring proper structural validation for districts and urban subdivisions. Documentation used: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia+xml+factura+version+2-1+1+0+(2)_0+(2).pdf opw-6282314 Forward-Port-Of: odoo/enterprise#121390
Fixes an Accounting Reports issue that could cause the Journal Audit report to fail after changing and removing the Generic Tax Report root report. This keeps accounting reporting accessible and avoids internal server errors for affected users.
Original PR description
Step To Reproduce: - Install the Accounting module. - Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report. - Set the Root Report to "Balance Sheet" and save. - Remove the…
Step To Reproduce:
- Install the Accounting module.
- Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report.
- Set the Root Report to "Balance Sheet" and save.
- Remove the Root Report and save again.
- Open Accounting -> Reporting -> Journal Audit.
Issue:
Opening the Journal Audit report raises an Internal Server Error with: psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "account_move_line__move_id"
Reason:
The code that recreates the missing "account.move" join was not updated consistently with the other "_join()" usages. Without calling "._sudo()", the ORM builds the join using a filtered subquery (for example, adding the company filter), which changes the generated join alias(https://github.com/odoo/odoo/blob/saas-19.1/odoo/orm/fields_relational.py#L559). The SQL query still references the regular alias (account_move_line__move_id), causing the query to fail.
Reference PR:- https://github.com/odoo/enterprise/pull/101230
Solution:
Use "query.table._sudo()._join()" when recreating the missing "account.move" join, matching the other "_join()" usages and ensuring the expected join alias is generated.
before fix:-
`'account_move_line__move_id__2': (SQL('JOIN'), SQL('(SELECT "account_move".* FROM "account_move" WHERE "account_move"."company_id" IN %s)', (1,)), SQL('"account_move_line"."move_id" = "account_move_line__move_id__2"."id"'))`
Query : `JOIN (
SELECT
account_move.*
FROM account_move
WHERE account_move.company_id IN (1)
) AS account_move_line__move_id__2
ON account_move_line.move_id = account_move_line__move_id__2.id`
after fix:-
`'account_move_line__move_id': (SQL('JOIN'), SQL('"account_move"'), SQL('"account_move_line"."move_id" = "account_move_line__move_id"."id"'))`
Query : `JOIN account_move AS account_move_line__move_id
ON account_move_line.move_id = account_move_line__move_id.id`
opw-6425842This fix ensures overtime calculations use the correct period setting, such as weeks instead of always treating rules as days. It prevents extra shifts from being incorrectly marked as overtime when public holidays fall within the affected period.
Original PR description
In the function '_get_expected_hours_from_contract', there is an improper super call where period is set to 'days' instead of passing in the value already passed into the original function. So when an overtime rule has a quantity_period not set to 'day', downstream calculations can go astray. In one example, when regenerating overtimes, weeks containing public holidays will have multiple shifts set as overtime shifts rather than just the shift on the holiday. Steps to recreate: 1. Create employee 2. Give them contract and flexible work schedule 3. On overtime ruleset, set overtime rule's quantity_period to Weeks (default is days) 4. Add a typical weeks worth of attendances 5. Create public holiday on one of the attendance days 6. Regenerate overtimes 7. See extra hours have been added to multiple shifts that week By fixing this super call, issues like these should be resolved going forward. opw-6373300 Forward-Port-Of: odoo/enterprise#126094
The German DATEV general ledger export now uses the correct foreign-to-base currency exchange rate and rounds it to six decimal places. This makes exported accounting files align with DATEV requirements and avoids overly long or incorrect rate values.
Original PR description
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses:…
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses: **Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`. **Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places. ### Current behavior before PR: Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long. ### Desired behavior after PR: The csv files should output the correct rate and be rounded appropriately. **Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch opw-6366276s Forward-Port-Of: odoo/enterprise#125097
3 changes
Resolved issues and error corrections
German POS fiscal certification now handles active transactions that are missing receipt details when they are cancelled. This prevents cancellation failures with Fiskaly and helps stores keep transaction cleanup reliable without changing existing completed receipt 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#122130Employee availability is now shown consistently across Attendance and Time Off planning views. Days outside an employee's contract are greyed out, and flexible schedules are handled more accurately, reducing confusion for managers reviewing calendars.
Original PR description
purpose: 1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days,…
purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees.
2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.
Fix:
1.
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
- more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
- greys out "out of contract" periods
- for flexible and fully flexible employees, the whole period is considered available except leave periods
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion
2.
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it
task-id: 5473055Customer balances shown in Point of Sale now stay accurate when the company and PoS use different currencies. This prevents pay-later amounts from being converted twice, so staff see the correct total due for each customer.
Original PR description
Steps to reproduce: - set the company currency to XCG - set the PoS sales journal currency and the PoS pricelist currency to USD - configure a XCG <-> USD rate - create a customer without any…
Steps to reproduce: - set the company currency to XCG - set the PoS sales journal currency and the PoS pricelist currency to USD - configure a XCG <-> USD rate - create a customer without any outstanding balance - open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method - open the Customers screen and look at the Total Due of that customer Issue: The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100. Cause: get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time. opw-6403320 Forward-Port-Of: odoo/enterprise#126111 Forward-Port-Of: odoo/enterprise#125798
2 changes
Enhancements to existing features
ISO 20022 payment files now include building number information in address details. This helps keep bank payment exports compliant with upcoming requirements that become mandatory in November 2026.
Original PR description
This commit adds the <BldgNb> node in the iso20022 XML files, as it will be mandatory starting November 2026. Linked: https://github.com/odoo/odoo/pull/271855 task-6317758 Forward-Port-Of: odoo/enterprise#121674
Resolved issues and error corrections
This fix ensures German POS transaction cancellations succeed even when the original transaction record lacks receipt details. It avoids rejection by the fiscal certification service, reducing interruption risk during cancellation workflows while keeping existing receipt information unchanged when available.
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#12213012 changes
Enhancements to existing features
Quality managers can now find existing Quality Spreadsheet Templates in the spreadsheet selector when templates are available. This makes it easier to insert list views into quality reporting templates and reuse them without extra workarounds.
Original PR description
Before this commit: - Quality Spreadsheet Templates were not available in the spreadsheet selector. - Quality managers could not insert list views into existing Quality Spreadsheet Templates. After this commit: - Quality Spreadsheet Templates are exposed in the spreadsheet selector when at least one template exists. - The session `can_insert_in_spreadsheet` flag is enabled for Quality managers in that case. Task: [6321126](https://www.odoo.com/odoo/project/2328/tasks/6321126)
Payroll managers can now configure a recurring monthly child bonus directly in an employee's benefits. The amount is automatically reflected in payslip calculations, shown separately on payslips, and included in the relevant net pay, accounting, and withholding tax bases while staying excluded from ONSS.
Original PR description
Before this commit, there was no dedicated way to configure a recurring additional child bonus. Payroll managers had to handle this amount outside the employee's salary package, and it was not automatically included in payslip calculations. After this commit, payroll managers can configure the monthly child bonus from the employee's benefits. Updating the amount triggers a payslip recomputation, and a dedicated salary rule displays the bonus separately on the payslip. The bonus is added to the employee's net-pay and accounting remuneration bases. It is also included in the withholding tax base, while remaining excluded from the ONSS base. Task-6392125
Belgian payroll now makes it easier to monitor voluntary overtime by grouping related entries and adding direct access from employee records. The update also enforces overtime hour limits with validation warnings, helping payroll teams stay compliant and avoid threshold overruns.
Original PR description
Add follow up support for voluntary overtime in Belgian payroll: - Add a salary rule category "Overtime", give it to the overtime time types (VOLOT150/VOLOT200/VOLOTNET and Overtime Belgium) + the voluntary overtime rules - Add a smart button `Overtime` on the employee form view to show all overtime leaves of the employee, grouped by year then by type - Add/adjust the voluntary overtime threshold hours and show a validation error when the employee exceeds the threshold. TaskID: 6048398
Payroll officers now receive warnings on the payroll dashboard when employee data or work schedules may not meet Belgian DMFA requirements. This helps teams correct issues earlier and reduce the risk of payroll reporting blocks later.
Original PR description
In order to aid the payroll officers with their daily tasks and ensure that work schedules and employees personal data are up to the DMFA standards and avoiding any blockings in the future, few warnings have been added to the payroll dashboard. Task: 6299170
Resolved issues and error corrections
This fix updates Swedish ISO 20022 payment files so they use bank identifiers and party IDs in the format expected by Swedbank. It helps reduce rejected payment files and improves compatibility for Swedish bank payment processing.
Original PR description
Fix some issues with the iso20022 XML file for Sweden:
1. Swedbank doesn't allow the us of `CUST` value in the `SchmeNm`
node but force the `BANK` value.
2. Currently, we use the same Id in both `InitgPty` & `Dbtr`, which
looks to be wrong with Swedbank. The format for Swedbank is
`06{company_registry}B001`.
opw-5395736
Forward-Port-Of: odoo/enterprise#125751
Forward-Port-Of: odoo/enterprise#122119Ecuadorian electronic invoices that include Special Consumption (ICE) taxes no longer fail during processing. The update ensures the correct tax information is included in the electronic invoice, helping businesses stay compliant and avoid blocked invoice workflows.
Original PR description
Currently, an error occurs when processing Ecuadorian EDI invoices that use taxes from the `Special Consumptions (ICE)` tax group. **Steps to reproduce:** - Install `l10n_ec_edi` and switch to an EC…
Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.
**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.
**Error:**
```
File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```
**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.
At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.
**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is
that it is not working on the versions where we already introduced the feature.)
[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38
[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377
[here]:
https://www.odoo.com/mail/message/1121493378
opw-6373984
opw-6430589
opw-6423812
Forward-Port-Of: odoo/enterprise#123918Saudi payroll now calculates GOSI contributions without incorrectly reducing them for partial periods. This helps ensure payslips and related accounting tests reflect the expected statutory contribution amounts.
Original PR description
task-id: 6380239 Forward-Port-Of: odoo/enterprise#125349 Forward-Port-Of: odoo/enterprise#124122
Hungarian Intrastat tax returns now work with recent changes to the Hungarian tax report structure. This prevents errors during return generation and helps businesses continue submitting Intrastat information reliably.
Original PR description
Here https://github.com/odoo/odoo/pull/253556, we made few changes in the `l10n_hu` report. We basically split some expresions into multiple small one. This has been done for the integration of ec sales list (a60). But hu intrastat was still using the old expressions, leading to an error. This commit aims to adapt the intrastat code to fit with the new a60 expressions. no-task Forward-Port-Of: odoo/enterprise#122662
Fixes an issue where the Payroll dashboard could crash when checking the “Employees Under Minimum Wage” warning for Belgian companies with multiple CP200 employees. This ensures payroll teams can open the dashboard reliably after employee contract changes.
Original PR description
Opening the Payroll dashboard may crashes with an error: - Have a Belgian company with 2 or more CP200 employees having active contracts - Create or modify a contract for at least 2 of them (this marks l10n_be_computed_seniority_years as dirty for the batch) - Open the Payroll dashboard, the "Employees Under Minimum Wage" warning evaluation crashes In _compute_l10n_be_computed_seniority, the for version in cp200_versions loop was incorrectly referencing self instead of version. Since self is the full batch recordset, self.employee_id returns a multi-record set, causing ensure_one() to fail inside _get_first_version_date. task-6358718 Forward-Port-Of: odoo/enterprise#123000
This fix ensures Mexican electronic payment documents calculate invoice balances correctly when payments involve exchange rate differences or credit notes. It helps prevent incorrect payment XML values for fully settled invoices, improving tax document accuracy.
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
Ri.Ba. payment validation now accepts valid San Marino bank accounts in addition to Italian ones. This prevents batch payment validation failures for companies using San Marino IBANs and ensures generated payment files 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#126208 Forward-Port-Of: odoo/enterprise#121439
Fixed an issue that caused Belgium payroll DMFA reports to fail for student employees. The report now uses the correct student contribution value, helping payroll teams generate required declarations reliably.
Original PR description
[FIX] l10n_be: fix DMFA bug
Bug reproduction:
1 - Go to master → new employee → make it student → joint committee=200
2 - Create payslip -> generate DMFA report
3 - Traceback is there.
Bug cause:
1 - contribution.amount is used for student in DMFA report. 2 - DMFAStudentContribution hasn't amount
2.1 - it has student_contribution_amount field
Bug solution:
1 - Use student_contribution_amount for students instead of amount
task-64103386 changes
Resolved issues and error corrections
Polish JPK tax exports now use the vendor bill reference in the purchase document field when one is provided. This helps companies generate XML reports that better match supplier documents and official reporting guidance.
Original PR description
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting >…
**Steps to reproduce:** - Install the `l10n_pl_reports` module and switch to a `PL Company`. - Create and confirm a vendor bill with a `Bill Reference` and `Taxes`. - Navigate to Accounting > Reporting > Tax Report and select `This Month`. - From the dropdown, click `JPK` > `Export XML`. - Open the generated XML file and observe the `DowodZakupu` field. **Observation:** `DowodZakupu` contains the vendor `Bill Number` even when a `Bill Reference` is set. **Root Cause:** At [1], `DowodZakupu` is populated only with the vendor `Bill number`(`move_name`) instead of using the `Bill reference`(`ref`) when available. **Fix:** This commit ensures `DowodZakupu` contains the `Bill Reference` when it is available in JPK exports. **Reference:** https://www.podatki.gov.pl/media/eqrn3dey/broszura-jpk_vat-z-deklaracj%C4%85-od-1-lutego-2026-r-en.pdf (page 41) [1]: https://github.com/odoo/enterprise/blob/4b0404058b280136f6865090562f95e18d4d7e0b/l10n_pl_reports/data/jpk_export_templates.xml#L208 opw-6299827 Forward-Port-Of: odoo/enterprise#126113 Forward-Port-Of: odoo/enterprise#121117
German POS certification now handles cancellations even when an active transaction has missing receipt details. This prevents rejected cancellation requests and helps keep certified point-of-sale operations running smoothly.
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#122130Fixed an issue where expected hours were always calculated by day, even when overtime rules were configured for another period such as weeks. This prevents incorrect extra overtime shifts from being created around public holidays and helps payroll/time tracking stay accurate.
Original PR description
In the function '_get_expected_hours_from_contract', there is an improper super call where period is set to 'days' instead of passing in the value already passed into the original function. So when an overtime rule has a quantity_period not set to 'day', downstream calculations can go astray. In one example, when regenerating overtimes, weeks containing public holidays will have multiple shifts set as overtime shifts rather than just the shift on the holiday. Steps to recreate: 1. Create employee 2. Give them contract and flexible work schedule 3. On overtime ruleset, set overtime rule's quantity_period to Weeks (default is days) 4. Add a typical weeks worth of attendances 5. Create public holiday on one of the attendance days 6. Regenerate overtimes 7. See extra hours have been added to multiple shifts that week By fixing this super call, issues like these should be resolved going forward. opw-6373300
Sendcloud DPD deliveries now include the recipient tax number in customs details, preventing validation failures for international shipments. The fix also ensures required customs fields have usable fallback values and uses English tax labels accepted by Sendcloud.
Original PR description
### This is a revision of #119399 which had to be reverted. Original issue ----- Deliveries cannot be validated using DPD with Sendcloud, users get an error. Steps to reproduce ----- - Set up…
### This is a revision of #119399 which had to be reverted. Original issue ----- Deliveries cannot be validated using DPD with Sendcloud, users get an error. Steps to reproduce ----- - Set up Sendcloud DPD - Create a SO - Interntional customer - Some VAT number - Some product - Add sendcloud delivery - Confirm SO - Validate the linked picking > Error: “The receiver VAT number is missing; please provide it to continue” Issue's cause ----- Tax numbers should be included in the `customs_information` field of the request as per the API https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-customs-information-tax-numbers For the `vat_label` field, we have to force the language to English in the context because the field is translated by default, but sendcloud only accepts the english names (eg French "TVA" is not accepted, expected value is "VAT"). https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75 Revert cause ----- The vat_label field is marked for translation (translate=True) https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75 So if the user has the DB in french for example, we are sending "TVA" instead of "VAT" in the name field. Other issues ----- - We need to provide an actual fallback for `customs_invoice_nr`. As it stands, if we create a new delivery it cannot be validated because Sendcloud doesn't accept for the field to be empty. - Same for `name`, we need to provide an actual fallback. ----- Ticket: opw-6250860
This fixes the German DATEV general ledger export so the exchange rate column uses the correct foreign-to-base currency ratio and rounds it to six decimal places. Businesses using DATEV exports will get files that better match DATEV requirements and avoid confusing overly long or reversed rate values.
Original PR description
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses:…
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses: **Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`. **Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places. ### Current behavior before PR: Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long. ### Desired behavior after PR: The csv files should output the correct rate and be rounded appropriately. **Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch opw-6366276s
Rental orders using custom routes such as make-to-order now correctly generate the expected return transfer alongside delivery and purchasing steps. This prevents missing return operations and helps rental workflows stay complete and traceable.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322 Forward-Port-Of: odoo/enterprise#125715 Forward-Port-Of: odoo/enterprise#124097
3 changes
Enhancements to existing features
Payment XML files now include building number details in ISO20022 addresses. This prepares SEPA and ISO20022 payment exports for upcoming November 2026 requirements, reducing future compliance risk for companies using these payment formats.
Original PR description
This commit adds the <BldgNb> node in the iso20022 XML files, as it will be mandatory starting November 2026. Linked: https://github.com/odoo/odoo/pull/271855 task-6317758
SEPA direct debit batch validation has been optimized to handle large payment batches more efficiently. This reduces processing time for thousands of payments and helps avoid timeouts during validation and customer pre-notification.
Original PR description
- Replace the `id:recordset` aggregation in `_get_expiry_date_per_mandate()` with `date:max` to compute the latest payment date directly in SQL. - Render `email_from` for all payments in batch and cache the computed authors by sender email to avoid repeated partner lookups during SDD pre-notification. This reduces ORM/cache overhead when validating large SEPA batches containing thousands of payments. Measured on a production-sized database: | metric | before | after | factor | |--------|-------:|------:|-------:| | `_get_expiry_date_per_mandate` (500 payments) | 564 ms | 111 ms | ~5x | | `_send_after_validation` notification (500 payments) | 92.9 s | 55.7 s | ~1.7x | | `_get_expiry_date_per_mandate` (1000 payments) | 890 ms | 178 ms | ~5x | | `_send_after_validation` notification (1000 payments) | timed out (>159 s) | 108.9 s | completed | OPW-6377340
Resolved issues and error corrections
Quality team email aliases now keep the correct company information, including in single-company setups. This ensures incoming emails can consistently create quality tickets instead of being blocked by missing company details.
Original PR description
Issue Before This Commit: ---------------------------------- In a single-company environment, the quality team email alias was created without a company ID. As a result, incoming emails could not…
Issue Before This Commit: ---------------------------------- In a single-company environment, the quality team email alias was created without a company ID. As a result, incoming emails could not generate quality tickets, making the email alias ineffective. Steps to produce: ---------------------------------- - Install `quality_control` in a single-company environment. - Create a quality team with a name and an email alias. - Navigate to Settings → Technical → Aliases and check the newly created alias. - The Company ID is False, preventing the creation of new tickets via email. Cause ---------------------------------- In a single-company environment, the company_id field is not visible, is not required, and has no default value, so it is never set. The same issue can also occur in a multi-company environment when the user explicitly creates a team without selecting a company. After this Commit: ---------------------------------- The company_id is now set in the alias default values based on the quality team’s company. It is also updated whenever the team’s company changes, ensuring consistency and allowing incoming emails to reliably create quality tickets in all environments. Task ID: 4595798 Forward-Port-Of: odoo/enterprise#82808