Thursday, September 24, 2026
8 changes · saas-19.3
Resolved issues and error corrections
French companies can now select and send multiple invoices without the process crashing. This ensures the batch sending wizard opens as expected, helping users complete electronic invoicing workflows smoothly.
Original PR description
Sending several invoices at once from the list view of a French company crashes instead of opening the batch sending wizard. Steps to reproduce: - Activate French Electronic Invoicing - Create a French customer with a valid PDP endpoint - Post two invoices for that customer, select them in the invoice list and click 'Send' Issue: The batch sending wizard raises ``` AttributeError: 'account.move.send.batch.wizard' object has no attribute 'company_id' ``` opw-6558940 Forward-Port-Of: odoo/odoo#289666 Forward-Port-Of: odoo/odoo#289547
This fixes currency formatting so amounts in currencies without decimal places, such as Japanese yen, no longer lose important zero digits. Business reports and project update summaries will now show correct values like 100 instead of 1, reducing the risk of misleading monetary information.
Original PR description
Description of the issue/feature this PR addresses: In Odoo 19.0, format_amount(..., trailing_zeroes=False) removes significant integer zeroes when the currency has no decimal places, such as JPY.…
Description of the issue/feature this PR addresses:
In Odoo 19.0, format_amount(..., trailing_zeroes=False) removes
significant integer zeroes when the currency has no decimal places,
such as JPY. Project update monetary summaries use this formatter
with trailing_zeroes disabled.
Steps to reproduce in an Odoo shell with the default JPY configuration:
```python
from odoo.tools.misc import format_amount
currency = env.ref('base.JPY')
format_amount(env, 100, currency, trailing_zeroes=False)
format_amount(env, 0, currency, trailing_zeroes=False)
```
Current behavior before PR:
The numeric part of 100 becomes 1, and the numeric part of 0
disappears. Grouped amounts can also lose digits and leave an
incomplete thousands group.
Desired behavior after PR is merged:
Preserve all integer digits for currencies without decimal places.
Only strip trailing zeroes when a fractional part is present.
Regression coverage includes zero, positive, negative and grouped
amounts, both currency symbol positions, and languages with distinct
or identical decimal and thousands separators.
Validation:
- Before the fix: the new regression test fails in 20 subcases.
- After the fix: all 9 tests in TestFormatAmountFunction and
TestFormatLangDate pass on an isolated PostgreSQL 16 database.
- git diff --check passes.
Test selection:
--test-tags=/base:TestFormatAmountFunction,/base:TestFormatLangDate
This PR also includes my signed Individual Contributor License
Agreement in doc/cla/individual/ysnkucuker.md.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#290374Hungarian electronic invoice files sent to NAV will no longer include cash rounding as a separate invoice line. This helps keep submitted invoices aligned with Hungarian legal requirements by treating rounding as a settlement difference rather than a sold good or service.
Original PR description
Global cash rounding can be applied to customer invoices. Before this commit, the rounding would be included in the XML file sent to NAV. It would be included as a new invoice line (same as the products lines) and the ATK tax is applied on it. As stated in the legal Hungarian Documentation, an invoice line should always relate to the supply of a good or the service provided. In this case, a cash rounding (which is not a financial advantage or disadvantage) will be considered by the law as a settlement difference, that is not part of the invoice. So, this commit removes cash rounding lines from the NAV XML. Moreover, it uses base_lines for the amounts computation instead of line_ids. task-6527383 Forward-Port-Of: odoo/odoo#286258
This fix ensures reconciliations without exchange differences use the company currency consistently. It prevents small residual company-currency balances from being left behind when foreign currency is involved, helping accounting records stay accurate.
Original PR description
When doing reconciliation with no exchange difference, the currency used should always be the company currency. Using foreign currency in that case could leave residual amounts in company currency. task-6582723
Users who receive mentions in Odoo will no longer get two separate alerts for the same message when browser notifications are enabled. This reduces confusion and keeps notification behavior consistent when a tab is open but not in focus.
Original PR description
Steps to reproduce: - Grant browser notification permission (subscribes to web push). - Set user A's `notification_type` to `inbox` in preferences and reload. - Keep A's tab open but unfocused. - As user B, post an @-mention on a non-channel chatter record targeting A. A receives two alerts: the JS one from the `mail.message/inbox` bus event and the native notification from web push. `OutOfFocusService.notify()` gated JS skip on `message.thread.model`, but the server never sends `mail.thread`, so chatter fell through. Replace it with a `message_type` + `!isSelfAuthored` filter mirroring the server side `_notify_get_recipients_for_extra_notifications`. Also swap the `isInbox` SW handshake workaround added by [1] when the user is busy. [1]: https://github.com/odoo/odoo/pull/232431 Forward-Port-Of: odoo/odoo#290052 Forward-Port-Of: odoo/odoo#282981
Time off requests for types that require supporting documents can no longer be saved or moved forward without the required attachment. This helps ensure absence records are complete and compliant with company policy before they remain active in the system.
Original PR description
Problem: When a time off type is configured to require a supporting document, the system should prevent users from submitting a request without one. However, users could bypass this requirement by…
Problem: When a time off type is configured to require a supporting document, the system should prevent users from submitting a request without one. However, users could bypass this requirement by creating and saving a request without uploading a file. Because the validation was not strictly enforced during creation or subsequent write operations, requests could enter or remain in active states without the mandatory documentation. Solution: This commit ensures the system enforces mandatory attachments during the modification of time off requests that require a supporting document. The system now evaluates state transitions to block undocumented submissions. Steps to reproduce(runbot v19): 1. Go to Time Off > Configuration > Time Off Types, create a new leave type and enable the "Allow To Attach Supporting Document" setting. 2. Create a new time off request for this type, leave the attachment empty, and save. 3. Notice that the system allows the invalid request to be saved and persist in the database without a document. opw-6413621 Forward-Port-Of: odoo/odoo#289577 Forward-Port-Of: odoo/odoo#278991
This fix ensures that when a user is not allowed to subscribe to one update channel, the system skips only that channel instead of failing the entire subscription request. This helps keep unrelated real-time updates working reliably for users.
Original PR description
`_build_bus_channel_list` should never raise. Otherwise, the entire request is aborted, meaning the client fails to subscribe to *all* channels, including completely unrelated channels. Instead, if a client do not have permission to subscribe to a channel, the channel should just be skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287142
Payment reconciliation now uses the company currency when any reconciled item belongs to an account that does not support payment reconciliation. This prevents incorrect foreign exchange difference entries and keeps accounting records more accurate.
Original PR description
When reconciling journal items, if one of them is using an account with no payment reconciliation, then the currency of the reconciliation should be the company currency regardless of which currency was used on the items. Also, in that case, no exchange difference entry should be created. task-6582723