Daily updates from Odoo
Wednesday, July 9, 2025
12 changes · master
Resolved issues and error corrections
Credit notes in the Kenya eTIMS workflow can now only be submitted when they are linked to an invoice that was already successfully submitted. This helps prevent rejected or invalid credit note submissions and keeps tax reporting aligned with eTIMS requirements.
Original PR description
To ensure credit notes are only submitted for invoices that have been submitted to eTIMS, we now restrict credit note submission to cases where the related invoice has already been successfully submitted. Forward-Port-Of: odoo/enterprise#89464 Forward-Port-Of: odoo/enterprise#89385
Customer follow-up reports now ignore accounting entries that do not have a due date or payment terms. This prevents customers from being incorrectly flagged for follow-up or receiving statements that show a zero balance as overdue.
Original PR description
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with -…
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accounting Dashboard > Bank > new with Amount: 500.0 - "Save & Close" then click on it - In the page "Manual Operations" change the partner to the one from the MISC entry - Change the Account to "400000 Customers" - Validate - The follow-up report is no longer "In need of action" - Create an invoice with a due date in the future - The follow-up report is back to "In need of action" with the amount of the invoice - When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€" ### Cause: The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€. The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`. ### Solution: The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due. So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`. opw-4784250 Forward-Port-Of: odoo/enterprise#89627 Forward-Port-Of: odoo/enterprise#87873
This fix ensures several enterprise apps consistently target real-time message updates to the correct recipients. It helps prevent missed or misrouted notifications in workflows such as approvals, knowledge articles, helpdesk live chat, VoIP, e-invoicing, and WhatsApp conversations.
Original PR description
\* = approvals, knowledge, l10n_mx_edi, voip, website_helpdesk_livechat, whatsapp Enterprise counter-part. https://github.com/odoo/odoo/pull/215869 Forward-Port-Of: odoo/enterprise#88531
Fixes an issue where tax reports could overstate the net taxable amount when invoice lines used the same tax but different analytic distributions. This helps businesses rely on accurate tax reporting while keeping the tax amount calculation unchanged.
Original PR description
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales…
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with two lines (eg both at $100), add the tax on both - Change the analytic distribution on both lines to different values - Confirm the invoice - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is doubled ($400), the tax amount is correct ($20) ### Cause: On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution). The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled. The result of the query have the base amount doubled. ### Solution: We cannot fix the query as there is no link to find the tax line origin amongst the base lines. The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example. The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it. opw-4753676 Forward-Port-Of: odoo/enterprise#89569 Forward-Port-Of: odoo/enterprise#87404
The Contact map view now opens Google Maps using the contact's full address instead of potentially imprecise stored coordinates. This helps users get the correct destination when choosing to view a contact location in Google Maps, especially when OpenStreetMap geolocation is less accurate.
Original PR description
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be…
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be slightly different from given one (when using OpenStreeMap) - Click on the position marker > `Navigate To` the address is recomputed correctly - Click on `View in Google Maps` the address given is often wrong **Issue:** Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results. As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results. **Fix:** Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps. opw-4649910 Forward-Port-Of: odoo/enterprise#87430
Planning now calculates open shifts correctly when a copied weekly schedule includes a day where an employee is on leave. This prevents lunch breaks from being counted as extra allocated time, giving managers more accurate staffing hours.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#89542
Forward-Port-Of: odoo/enterprise#73478Users can now upload files from the Documents app control panel as expected. This fixes a bug where choosing a file appeared to do nothing, helping teams add documents without switching workflows.
Original PR description
Reproduce: 1. In the Documents app's control panel, click on New 2. "Upload" 3. Choose a file and confirm -> nothing happens. Task-4926208
Creating a new employee contract through the salary configurator now automatically ends the previous contract the day before the new one begins. This prevents overlapping contract periods and keeps employee contract records accurate without manual correction.
Original PR description
When you create a new contract through the salary configurator flow, it will create automatically a new version with the date encoded in the offer wizard. However, the 'contract_end_date' for the old version is not automatically updated. The logic has been adjusted to end old contract date the day before the new contract's start date. Forward-Port-Of: odoo/enterprise#88915
This fixes an error that prevented Belgian companies from exporting the Social Balance Sheet report as PDF or XLSX. Payroll users can now generate the required report without interruption.
Original PR description
Since the introduction of versions, a traceback occurs due to an old function call Task: 4911701 Forward-Port-Of: odoo/enterprise#89149
The employee payroll tab has been corrected in several country-specific payroll setups. This helps HR teams access the right payroll information consistently when viewing employee records.
Original PR description
This fixes the payroll tab in the inherited view of employee for various loca. Task: 4885749 Forward-Port-Of: odoo/enterprise#88734
This fix improves how Odoo detects overlapping project tasks when filters use related information. It prevents valid overlaps from being missed and corrects a test so planned hours are properly considered.
Original PR description
The query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first one, injecting the second one's where clause as join condition, but that composition does not work if the second query has extra joins. Those extra joins come from related fields that may occur from the domain. The fix consists in recomposing the query with a join condition that does not depend on a dynamic domain, and injecting the domain in the where clause of the main query. With this strategy, the joins that appear because of the related fields in the domain are part of the main query, and are no longer lost by the composition. Note also that the test test_same_user_overlap_with_allocated_hours_less_than_workable_hours was actually broken, because the field allocated_hours wasn't flushed when doing the SQL query. The new query flushes the field, and the test has been fixed.
This fix ensures that refunds in Point of Sale correctly wait for all required steps before continuing. Businesses using both Spanish TicketBAI and Peruvian e-invoicing POS localizations will now see the required refund reason prompt as expected, reducing refund processing errors.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/enterprise#89423 Forward-Port-Of: odoo/enterprise#88813