Friday, April 17, 2026
2 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where rental price calculations were inconsistent due to how relativedelta handled time-zoned dates. The change ensures accurate price calculations across different time zones, specifically addressing discrepancies in rental durations. This improves the reliability of rental pricing for all users.
Original PR description
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work…
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates. Example: Consider a website in UTC+1 (Brussels timezone DST off). And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). Converted in UTC for the back-end, we have: from the 30/11/2025 23h00 to the 31/12/2025 22h59. relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow: 30/11/2025 23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. Time difference = 1 month, 23 hours, 59 minutes. Price = 2 months. Consider a second rental from the 01/01/2026 to the 31/01/2026. 31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. Time difference = 30 days, 23 hours, 59 minutes. Price = 1 month. opw-5130762 Forward-Port-Of: odoo/enterprise#102109 Forward-Port-Of: odoo/enterprise#98571
This update resolves an error that occurred when processing DTE XML files from Chile. Specifically, the system was incorrectly setting a default journal, leading to a 'journal_id' error during account move calculations. This fix ensures proper DTE XML processing and prevents data discrepancies.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041