Daily updates from Odoo
Saturday, December 6, 2025
7 changes
1 change
Resolved issues and error corrections
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time zones differed from UTC. The change ensures that calendar event times are correctly aligned with the employee's time zone, improving the accuracy of time off scheduling.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818
1 change
Resolved issues and error corrections
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time off was scheduled in a timezone different from UTC. The change ensures that calendar events correctly display the actual start and end times of time off requests, improving accuracy and usability.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818
2 changes
Resolved issues and error corrections
This update resolves a crash that occurred when users attempted to add bank statement lines to journals other than the default. The fix ensures the correct journal is selected during transaction creation, preventing data inconsistencies and improving stability.
Original PR description
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the…
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the default Bank journal to create `Bank (Copy)`. - Dashboard and `Click on 3 dots` of Bank(Copy) and click on Transactions. - Create a new transaction and set the Statement also(Create new and assign it). - Go to that statements and Add a line and set the `foreign currency` as USD. **Error:** `ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)` **Cause:** - When we try to create a transaction in a statement of a non-default journal, its journal is not set by default, resulting in two records being fetched. At line [1], our code attempts to read `statement_id.journal_id` , but encounters multiple records, causing the issue. **Solution:** - Here I added context to pass `journal_id` as default and made `payment_ref` required(because at [2], also we do the same). - Also added hidden `journal_id` field in the list view. [1]: https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887 [2]: https://github.com/odoo/enterprise/blob/bff451101bb23b4f9acc7982ed1138d7cefa13b9/account_accountant/views/bank_rec_widget_views.xml#L220 **sentry-6928858335** **opw-5256565** Forward-Port-Of: odoo/enterprise#98995
This update significantly speeds up VAT report generation by removing a slow check and cleaning up outdated data. It also corrects a critical issue where users lacked access to returns, preventing accurate reporting across all company branches. This ensures data integrity and a smoother user experience for financial reporting.
Original PR description
The "No negative amount in VAT report" return check was too slow, we removed it and clean the database. On the other hand, refreshing checks had issues with the access rights when there was company branches. task-id: 5145537 Forward-Port-Of: odoo/enterprise#98633 Forward-Port-Of: odoo/enterprise#97125
2 changes
Resolved issues and error corrections
This update ensures that the delivery address is now correctly included in requests for tax calculations and EDI documents (NF-e invoices). Previously, this information was missing, which could lead to tax discrepancies. This change is crucial for accurate tax reporting and seamless EDI processing.
Original PR description
Purpose: For invoice goods(NF-e), the delivery address can differ from the invoice address. It is necessary for both fiscal and logistical reasons to provide the delivery address in the tax calculation and EDI requests. Failure to do so may result in tax issues for the issuer. Expected Behavior: Users will be able to set a delivery address on the sales order and invoice and the delivery address will be sent in the requests for tax calculation and EDI. The returned EDI document will display the delivery address information. Current Behavior: The delivery address is not sent in the requests. task-5171186
This update ensures that when stock is spread across multiple locations for a Lot/Serial Number, the correct location is always displayed in the system. Previously, the location was incorrectly set to 'False', preventing users from seeing where the stock was actually stored. This improvement enhances inventory tracking and accuracy.
Original PR description
Fixed (Issue #237701 ) Description of the issue/feature this PR addresses: When a Lot/Serial Number has positive stock spread across multiple locations, the field lot.location_id is currently set to False Current behavior before PR: The Lot/Serial form shows no location Users cannot see where the stock actually exists If stock exists in multiple locations → the location is cleared (False) Desired behavior after PR is merged: Users always see a stock location when stock exists A valid stock location will still be shown instead of None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time off was scheduled in a timezone different from UTC. The change ensures that calendar events now correctly display the actual start and end times of time off requests, improving accuracy and usability.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818