Monday, December 29, 2025
9 changes · saas-19.1
Resolved issues and error corrections
This update resolves an error that prevented users from sending customer statements. The fix ensures the system correctly handles scenarios where a custom email template isn't used, defaulting to the current user's email address to avoid a technical error. This improves the reliability of the customer statement generation process.
Original PR description
Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the…
Currently, an error occurs when a user sends a customer statement. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):** - Install the `account_reports` module. - Go to `Invoicing` > `Customers` > `Customers`. - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`. - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`. **Error:** `ValueError: Expected singleton: mail.template()` After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from. This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior. [this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7 [1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246 [2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693 [3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892 sentry-7106576491 Forward-Port-Of: odoo/enterprise#102682 Forward-Port-Of: odoo/enterprise#102219
This update resolves an issue where UrbanPiper orders were incorrectly showing a payment difference after completion. The fix ensures that the final payment amount accurately reflects the total, improving the reliability of UrbanPiper order processing. This change impacts the UrbanPiper integration.
Original PR description
In this commit, The amount difference should be 0.0 after the Urbanpiper order has been paid. task-5441252 Forward-Port-Of: odoo/enterprise#102894 Forward-Port-Of: odoo/enterprise#102872
This pull request updates the core spreadsheet component within Odoo. It addresses several bugs related to spreadsheet rendering, border issues, and compatibility with Safari's zoom feature. These improvements ensure a more stable and reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e6313bd89a [REL] 19.1.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e6313bd89a [REL] 19.1.1 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e46a4ae735 [FIX] borders: merged cell loses adjacent border after import [Task: 5390397](https://www.odoo.com/odoo/2328/tasks/5390397) https://github.com/odoo/o-spreadsheet/commit/2a5e901dad [FIX] Style: Ignore undefined style in commands [Task: 5439120](https://www.odoo.com/odoo/2328/tasks/5439120) https://github.com/odoo/o-spreadsheet/commit/25bf5e0a80 [FIX] array_formula_highlight: avoid false spill outline [Task: 5403906](https://www.odoo.com/odoo/2328/tasks/5403906) https://github.com/odoo/o-spreadsheet/commit/7476f37316 [FIX] Spreadsheet: Make zoom work on Safari [Task: 5232092](https://www.odoo.com/odoo/2328/tasks/5232092) https://github.com/odoo/o-spreadsheet/commit/fa395d8ce9 [FIX] Highlights: Adapt for zoomed spreadsheets [Task: 5232092](https://www.odoo.com/odoo/2328/tasks/5232092) https://github.com/odoo/o-spreadsheet/commit/2930f8a47c [REL] version 19.1.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/5dd3ed7a22 [FIX] tests: remove or fix skipped tests [Task: 5423848](https://www.odoo.com/odoo/2328/tasks/5423848) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update ensures that the analytic distribution linked to expenses is correctly applied when reinvoicing to a customer. Previously, the distribution would shift unexpectedly, leading to inaccurate reporting. Now, the analytic account from the sales order takes precedence, guaranteeing consistent tracking of costs and revenue across all related documents.
Original PR description
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account…
Steps to reproduce the flow: - Create an expensable product “Hotel” that can be reinvoiced to a customer - Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel” - Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction” - Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing” - Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information - When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong. - On the vendor bill, the analytic distribution is “Home Construction” Now: 1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO 2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO. task-4564463 Forward-Port-Of: odoo/odoo#240762 Forward-Port-Of: odoo/odoo#233794
This update resolves an issue where sending vendor bills to eTIMS would fail when the eTIMS configuration wasn't properly set up. Specifically, the system requires the 'eTIMS Server Mode' to be configured, otherwise the sending process is skipped. This change ensures the system correctly handles this scenario, preventing errors and allowing bills to be sent to eTIMS.
Original PR description
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills. Steps to Reproduce: - Install `l10n_ke_edi_oscu` module without demo data. - Create a New company with `Kenya` as…
Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.
Steps to Reproduce:
- Install `l10n_ke_edi_oscu` module without demo data.
- Create a New company with `Kenya` as the Country and switch to it.
- Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
- Confirm it, then click `Send to eTIMS`.
Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
content = move._l10n_ke_oscu_json_from_move()
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
tax, line_tax_details = next(
StopIteration: null
```
This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.
Here we raise a warning when the `eTIMS` configuration is not set up correctly.
[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93
sentry-7083978544
Forward-Port-Of: odoo/enterprise#101319This update restores the ability to track negative overtime (undertime) within the HR attendance module. Previously removed in 19.0, this feature allows for accurate recording of situations where employees work less than their scheduled hours, addressing a previous client concern and improving attendance tracking accuracy.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240263
This update restores the ability to generate negative overtime (undertime) in the attendance tracking system. This change, implemented after reviewing the Absence Management settings, ensures more accurate time reporting for clients, addressing a previous removal that caused potential revenue loss.
Original PR description
…time generation Forward-Port-Of: odoo/enterprise#102271
This update resolves a crash in the Partner Kanban view when editing payments in the mobile POS. The fix ensures that necessary data, specifically `activity_state`, is loaded for the view, preventing errors and improving stability for users.
Original PR description
Steps to reproduce: =================== - Use the POS in mobile view - Complete a payment - Click on "Edit Payment" - Select customer or Edit customer Issue: ====== - The partner kanban view crashes in the frontend - `activity_state` is accessed in the template but not loaded Cause: ====== - The partner kanban view uses activity-related fields - `activity_state` was not included in the kanban fields Fix: ==== - Explicitly load `activity_state` in the partner kanban view Task:5406890
This update fixes an issue where e-invoices in the Hungarian localization were incorrectly using the invoice date to calculate currency exchange rates. Now, the system accurately uses the delivery date, aligning with Hungarian tax regulations and ensuring correct e-invoice generation. This resolves a discrepancy impacting financial reporting accuracy.
Original PR description
In the Hungarian localization, the currency exchange rate for invoices is based on the delivery date. Steps to reproduce: - With HU localization setup - Create an invoice Issue: Currently, when issuing the e-invoice, the system would compute the currency exchange rate using the invoice date. opw-5126816 Forward-Port-Of: odoo/odoo#240999