Daily updates from Odoo
Navigate
Branch
Monday, August 3, 2026
281 changes
17 changes
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in one operation, making report generation faster and more reliable. The update also refines the six-column layout, tax credit and withholding calculations, and preserves upgrade compatibility for existing installations.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Resolved issues and error corrections
This fixes an error that could prevent users from opening the Journal Audit report after changing and clearing the root report on the Generic Tax Report. The report now rebuilds its internal query consistently, avoiding an Internal Server Error and keeping accounting reporting accessible.
Original PR description
Step To Reproduce: - Install the Accounting module. - Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report. - Set the Root Report to "Balance Sheet" and save. - Remove the…
Step To Reproduce:
- Install the Accounting module.
- Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report.
- Set the Root Report to "Balance Sheet" and save.
- Remove the Root Report and save again.
- Open Accounting -> Reporting -> Journal Audit.
Issue:
Opening the Journal Audit report raises an Internal Server Error with: psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "account_move_line__move_id"
Reason:
The code that recreates the missing "account.move" join was not updated consistently with the other "_join()" usages. Without calling "._sudo()", the ORM builds the join using a filtered subquery (for example, adding the company filter), which changes the generated join alias(https://github.com/odoo/odoo/blob/saas-19.1/odoo/orm/fields_relational.py#L559). The SQL query still references the regular alias (account_move_line__move_id), causing the query to fail.
Reference PR:- https://github.com/odoo/enterprise/pull/101230
Solution:
Use "query.table._sudo()._join()" when recreating the missing "account.move" join, matching the other "_join()" usages and ensuring the expected join alias is generated.
before fix:-
`'account_move_line__move_id__2': (SQL('JOIN'), SQL('(SELECT "account_move".* FROM "account_move" WHERE "account_move"."company_id" IN %s)', (1,)), SQL('"account_move_line"."move_id" = "account_move_line__move_id__2"."id"'))`
Query : `JOIN (
SELECT
account_move.*
FROM account_move
WHERE account_move.company_id IN (1)
) AS account_move_line__move_id__2
ON account_move_line.move_id = account_move_line__move_id__2.id`
after fix:-
`'account_move_line__move_id': (SQL('JOIN'), SQL('"account_move"'), SQL('"account_move_line"."move_id" = "account_move_line__move_id"."id"'))`
Query : `JOIN account_move AS account_move_line__move_id
ON account_move_line.move_id = account_move_line__move_id.id`
opw-6425842
Forward-Port-Of: odoo/enterprise#125968The Timesheets overtime indicator now shows remaining time in the selected unit even when users switch languages. This prevents confusion for multilingual teams using day or half-day timesheet entry, where values could previously appear as hours instead of days.
Original PR description
Steps to reproduce: ------------------- 1. Install Timesheets. 2. Create a new employee with a fully fixed working schedule (40h/week). 3. Open Timesheets > All Timesheets and create a new timesheet…
Steps to reproduce: ------------------- 1. Install Timesheets. 2. Create a new employee with a fully fixed working schedule (40h/week). 3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours). 4. Observe the overtime indicator for the employee (it shows 32 hrs) (Click the left arrow to display it). 5. Change the timesheet encoding unit to "Days / Half-Days". 6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days). 7. Install a language other than English (e.g. French). 8. Return to Timesheets and observe the overtime indicator again. Issue: -------- The remaining time value changes unexpectedly and displays 32 hours instead of 4 days. Cause: --------- In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`. Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead. https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169 Solution: ----------- Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values. see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82 opw-6279133 Forward-Port-Of: odoo/enterprise#126256 Forward-Port-Of: odoo/enterprise#120595
Swiss payroll calculations now use consistent rounding to the nearest 0.05 instead of combining cent rounding with manual adjustments. This prevents tiny rounding differences from incorrectly appearing in salary declarations, improving payroll accuracy and test reliability.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
In single-company setups, users could not change the journal on depreciation models when no company was set because the company selector was hidden and the visible journal field was read-only. The update keeps the company field available and removes an unnecessary warning in single-company environments, making depreciation model setup editable again.
Original PR description
When no company is set on a depreciation model, we only display the `journal_placeholder_id` field which is readonly. But in a single company environment, the 'company_id` field is hidden, therefore it becames impossible to change the journal for depreciation models. Fix: Always display the `company_id` field, but we remove the warning in the onchange when we are in a single company environment. opw-6299390 Forward-Port-Of: odoo/enterprise#121518
Users can now click custom fields in the Documents list view and edit them directly, without first activating another standard field. This makes customized document workflows smoother and avoids a confusing extra step for teams using Studio-created fields.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125378 Forward-Port-Of: odoo/enterprise#125239
This fixes an issue in Mexican payroll where removing a payslip start or end date could cause an error. Users can now edit or clear payslip dates without the form crashing, improving reliability during payroll preparation.
Original PR description
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI`…
Currently, an error occurs when a user removes the payslip dates. **Steps to reproduce:** - Install the `l10n_mx_hr_payroll_account_edi` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company - Go to `Payslips`, create a payslip. - Set an `employee`, and remove either the `start date` or the `end date` from Period.. `TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'` After the [recent commit] adding a warning about the employee exceeding the salary limit, when the user removes the dates from the payslip, the compute method attempts to compute the warning from [1], and when it adds relativedelta to date_from, which is False, it raises the error [2]. This commit ensures that the payslip dates are checked first before adding relativedelta to the date and performing the comparison. [recent commit]: https://github.com/odoo/enterprise/commit/6abfa47dafe439f9328d606ef6ac5126ec6eb1f6 [1]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/hr_payroll/models/hr_payslip.py#L1446 [2]- https://github.com/odoo/enterprise/blob/53a7fd4d53ffd510ad42632c69ce9d3a22c59e70/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py#L272-L276 Forward-Port-Of: odoo/enterprise#125479 Forward-Port-Of: odoo/enterprise#122643
Fixed an issue that could cause the field service planning map to crash when opening the routing popup for groups with unassigned or mixed resources. The popup now appears only when the selected group consistently matches the records' resources, making the experience more reliable across languages and planning setups.
Original PR description
This commit fixes an issue where we search the resources' types in a group's records, possibly not having any resource. Prior to this commit, a condition filtered out the "None" group. However, this causes three issues: 1. The condition does not consider translations (so this would fail for the "None" group in French for instance); 2. If there is any other group than Open Shifts not having resources, this would fail. 3. If there is another group that does not belong to a resource or to Open Shifts that has some records without resources, we should not display the popup. Instead, we dynamically check whether the groupId is part of the resource_ids of *every* group's record in order to display the popup. no-task
The Timesheet Assistant no longer suggests calendar events marked as available. This keeps recommendations focused on events that can actually be timesheeted and helps users avoid irrelevant entries.
Original PR description
## Previous Behavior In the Timesheet Assistant view, calendar events marked as *available* were still being suggested. These events are not intended to be timesheeted and should not appear in the assistant’s recommendations. Their presence could also obscure more relevant events that require user attention. ## New Expected Behavior Calendar events marked as *available* are now excluded from Timesheet Assistant suggestions. task-[6431591](https://www.odoo.com/odoo/project/4105/tasks/6431591) Forward-Port-Of: odoo/enterprise#126183
Users can now resize scheduled work orders in the Gantt planning view without triggering an error. The fix makes schedule updates more reliable, especially when work orders depend on each other.
Original PR description
## Problem When dragging the edge of a scheduled workorder to change the start or end time, _web_gantt_move_candidates would throw a traceback. This is because the web call only supplies the new time…
## Problem When dragging the edge of a scheduled workorder to change the start or end time, _web_gantt_move_candidates would throw a traceback. This is because the web call only supplies the new time chosen by the drag+drop. That is, if date_end was changed, date_start wouldn't be present, so accessing the missing field directly triggers a KeyError. This also revealed a secondary issue involving dependent tasks, where if the parent task is rescheduled with the pills, the child task would fail to find candidate reschedule dates (since its only dependency is being moved), and no boundary date would be supplied when calling _web_gantt_reschedule_compute_dates. This led to another traceback. ## Solution For the first issue, we will get the start date and end date from the supplied values more safely, using get() to default to the original start/end. For the second issue, if the boundary date isn't found by _web_gantt_get_first_and_last_possible_dates, we fall back to the candidate's existing start or end date. ## Steps to replicate (Runbot saas-19.4) 1. Create a product with a BOM with 2 operations on the same workcenter 2. Create an MO for this product, confirm it, and plan it 3. Head to Manufacturing > Planning > Work Orders / Planning 4. Try to change the end date of the first work order by dragging the edge of the pill opw-6378769
This fix makes the Swedish point of sale test consistently create its order before finishing. It reduces random test failures, helping keep validation of Swedish POS behavior stable without changing customer-facing functionality.
Original PR description
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing:…
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing: https://github.com/odoo/enterprise/blob/0f6f6fac892bc8cec477160a790d52fbf053be99/l10n_se_pos/tests/test_se_pos.py#L40-L42 ## Steps to reproduce 1. Install `l10n_se_pos` 2. Run the test `test_l10n_se_pos_01` 3. **The test fails non-deterministically** ## Fix We use `clickNextOrder()` at the end of the tour to ensure the creation of the order, like other tests already do (e.g., [FinishResidualOrder](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L676-L677), [test_name_preset_skip_screen](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L1333-L1334), [PosOrderCreationTourPdis](https://github.com/odoo/enterprise/blob/08d5172a8c3310af0c51e18a281c544f83f5aed7/pos_enterprise/static/tests/tours/point_of_sale/pos_tour.js#L141-L142), ...). runbot-238568 Forward-Port-Of: odoo/enterprise#125672
This fix ensures Swiss payroll automatically calculates salary code 2050 during payroll processing. It reduces manual work and helps produce more accurate Swissdec payroll reporting.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#114650 Forward-Port-Of: odoo/enterprise#103453
Guatemalan invoice PDFs now show the same customer tax identifier used in the official electronic XML, including using “CF” when no valid VAT is available. The legal 2,500 threshold is also checked in the company currency, helping avoid inconsistent compliance results on foreign-currency invoices.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
The Stripe expense cardholder field now follows the correct setup method, ensuring filters from the form are applied as expected. This helps users see the right selectable cardholders and prevents incorrect or confusing choices when managing expenses.
Original PR description
After https://github.com/odoo/odoo/issues/196785; the standard way to build a custom m2o field in JS is to call a method from the Many2one module, instead of extending an object from it. This commit solves issues regarding domain in the view not being passed to the widget opw-6399906 Forward-Port-Of: odoo/enterprise#125346
A Timesheet Grid rule was adjusted so notification counts in Discuss are ignored when matching messages. This prevents false matches and helps timesheet-related automation behave consistently when users have unread notifications.
Original PR description
task: 6416889 Forward-Port-Of: odoo/enterprise#125877 Forward-Port-Of: odoo/enterprise#125519
The automated tests for assigning resources in Planning Field Service were made more reliable by avoiding a timing issue in the resource selection step. This reduces false test failures and helps keep development and release checks stable without changing user-facing behavior.
Original PR description
This commit fixes undeterministic failures in the `many2many_avatar_resource` tests. Previously, resources were added by typing its name, waiting for the list to update and clicking on the resource. However, `edit` auto-completes with some delay, thereby resulting in random errors where the first resource from the list was added. Instead, we let the `edit` autocomplete to run in order to add a resource, ensuring the first resource from the list is not added as a consequence. runbot-error-941174
Customers can no longer complete checkout for planning-based rental services when the requested time slot has no available resources. The cart now warns and blocks payment until the customer chooses an available date or reduces the quantity, preventing paid orders that cannot be fulfilled.
Original PR description
**Problem:** On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The…
**Problem:** On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate. **Steps to reproduce:** 1. Install `website_sale_renting_planning`. 2. Create a planning role with `sync_shift_rental` and one resource. 3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above. 4. Pre-book the resource for some window via a `planning.slot`. 5. From eCommerce, add the product to the cart for the same window. 6. Proceed to checkout/payment. **Current behavior:** The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period. **Expected behavior:** The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity. **Cause of the issue:** `sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but `website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all. **Fix:** Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types. opw-6247034 Forward-Port-Of: odoo/enterprise#125732 Forward-Port-Of: odoo/enterprise#118943
21 changes
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in a single process, improving performance and reliability. The update also refines the six-column layout, tax credit handling, withholding sections, and submission flow so businesses can review and file tax information more accurately.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Resolved issues and error corrections
The Accounting Reports module now correctly rebuilds report data queries after Generic Tax Report settings are changed. This prevents an Internal Server Error when users open the Journal Audit report, improving reliability for accounting workflows.
Original PR description
Step To Reproduce: - Install the Accounting module. - Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report. - Set the Root Report to "Balance Sheet" and save. - Remove the…
Step To Reproduce:
- Install the Accounting module.
- Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report.
- Set the Root Report to "Balance Sheet" and save.
- Remove the Root Report and save again.
- Open Accounting -> Reporting -> Journal Audit.
Issue:
Opening the Journal Audit report raises an Internal Server Error with: psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "account_move_line__move_id"
Reason:
The code that recreates the missing "account.move" join was not updated consistently with the other "_join()" usages. Without calling "._sudo()", the ORM builds the join using a filtered subquery (for example, adding the company filter), which changes the generated join alias(https://github.com/odoo/odoo/blob/saas-19.1/odoo/orm/fields_relational.py#L559). The SQL query still references the regular alias (account_move_line__move_id), causing the query to fail.
Reference PR:- https://github.com/odoo/enterprise/pull/101230
Solution:
Use "query.table._sudo()._join()" when recreating the missing "account.move" join, matching the other "_join()" usages and ensuring the expected join alias is generated.
before fix:-
`'account_move_line__move_id__2': (SQL('JOIN'), SQL('(SELECT "account_move".* FROM "account_move" WHERE "account_move"."company_id" IN %s)', (1,)), SQL('"account_move_line"."move_id" = "account_move_line__move_id__2"."id"'))`
Query : `JOIN (
SELECT
account_move.*
FROM account_move
WHERE account_move.company_id IN (1)
) AS account_move_line__move_id__2
ON account_move_line.move_id = account_move_line__move_id__2.id`
after fix:-
`'account_move_line__move_id': (SQL('JOIN'), SQL('"account_move"'), SQL('"account_move_line"."move_id" = "account_move_line__move_id"."id"'))`
Query : `JOIN account_move AS account_move_line__move_id
ON account_move_line.move_id = account_move_line__move_id.id`
opw-6425842
Forward-Port-Of: odoo/enterprise#125968A timesheet-related automation rule was corrected so notification counters in Discuss do not interfere with how messages are recognized. This reduces false matches and helps keep timesheet notifications and related workflows behaving as expected.
Original PR description
task: 6416889 Forward-Port-Of: odoo/enterprise#125519
Fixes German DATEV general ledger exports so the exchange rate column uses the correct foreign-to-base currency ratio and rounds values to 6 decimal places. This helps exported accounting files match DATEV requirements and avoids long or incorrect rate values that could disrupt reporting or imports.
Original PR description
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses:…
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses: **Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`. **Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places. ### Current behavior before PR: Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long. ### Desired behavior after PR: The csv files should output the correct rate and be rounded appropriately. **Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch opw-6366276s Forward-Port-Of: odoo/enterprise#125097
Audit reports now use the company selected for the report instead of the user's default company. This ensures the correct company address appears in accounting report headers when working across multiple companies.
Original PR description
When adding the accounting reports to the audit report, we browse the reports with the request's environment which is defaulting to the user's main company. As a result, the company's address displayed in the reports' header is not correct if we generate the audit report for any other company with a different address. https://github.com/odoo/enterprise/blob/aaab137897e6ad794247470e48d5ea91382577a3/account_reports/data/pdf_export_templates.xml#L85 We propose to inject the correct company in the report's environment. opw-6373956 Forward-Port-Of: odoo/enterprise#125125
The Timesheets overtime indicator now shows remaining time in the selected unit, even after users switch to another language. This prevents confusion where values could appear as hours instead of days for multilingual users.
Original PR description
Steps to reproduce: ------------------- 1. Install Timesheets. 2. Create a new employee with a fully fixed working schedule (40h/week). 3. Open Timesheets > All Timesheets and create a new timesheet…
Steps to reproduce: ------------------- 1. Install Timesheets. 2. Create a new employee with a fully fixed working schedule (40h/week). 3. Open Timesheets > All Timesheets and create a new timesheet in the past week for this employee (e.g. 8 hours). 4. Observe the overtime indicator for the employee (it shows 32 hrs) (Click the left arrow to display it). 5. Change the timesheet encoding unit to "Days / Half-Days". 6. Return to Timesheets and observe the overtime indicator (it now correctly shows 4 days). 7. Install a language other than English (e.g. French). 8. Return to Timesheets and observe the overtime indicator again. Issue: -------- The remaining time value changes unexpectedly and displays 32 hours instead of 4 days. Cause: --------- In `get_timesheet_and_working_hours_for_employees`, the code determines whether the timesheet UoM is expressed in days by comparing the UoM name with the string `"days"`. Since UoM names are translatable, this comparison becomes invalid when the user language changes (e.g. `"jours"` in French), causing the logic to skip the day conversion and return values in hours instead. https://github.com/odoo/enterprise/blob/c48290e90fdeadf4f9ca8c44b035e601e7ed380a/timesheet_grid/models/hr_employee.py#L165-L169 Solution: ----------- Compare the timesheet UoM record with the day UoM record directly instead of relying on translated string values. see commit: https://github.com/odoo/enterprise/commit/5fbf194c5056566453a124812fd2614edfe19a82 opw-6279133 Forward-Port-Of: odoo/enterprise#126256 Forward-Port-Of: odoo/enterprise#120595
The timesheet assistant now uses the correct color rules when comparing recorded time with expected working hours. This prevents misleading green highlights and avoids showing a status color for flexible hours, helping users interpret their timesheet totals more accurately.
Original PR description
Fix the wrong color selection of total hours on the timesheet assistant page before: green if total time > working hours after: - green if total time < working hours - no color for flexible hours --- task-6409938 Forward-Port-Of: odoo/enterprise#125177
Users can now click and edit custom fields directly in the Documents list view. This removes an extra step and makes fields added through Studio behave like standard editable fields.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125378 Forward-Port-Of: odoo/enterprise#125239
Swiss payroll calculations now round monetary values directly to the required 0.05 precision instead of using an intermediate workaround. This avoids tiny rounding discrepancies that could incorrectly affect payroll declaration results and related tests.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
This fixes an intermittent issue in the Swedish Point of Sale test flow where an order was not always created before the test finished. The change makes the automated check more reliable, reducing false test failures without changing day-to-day user behavior.
Original PR description
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing:…
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing: https://github.com/odoo/enterprise/blob/0f6f6fac892bc8cec477160a790d52fbf053be99/l10n_se_pos/tests/test_se_pos.py#L40-L42 ## Steps to reproduce 1. Install `l10n_se_pos` 2. Run the test `test_l10n_se_pos_01` 3. **The test fails non-deterministically** ## Fix We use `clickNextOrder()` at the end of the tour to ensure the creation of the order, like other tests already do (e.g., [FinishResidualOrder](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L676-L677), [test_name_preset_skip_screen](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L1333-L1334), [PosOrderCreationTourPdis](https://github.com/odoo/enterprise/blob/08d5172a8c3310af0c51e18a281c544f83f5aed7/pos_enterprise/static/tests/tours/point_of_sale/pos_tour.js#L141-L142), ...). runbot-238568 Forward-Port-Of: odoo/enterprise#125672
The Documents kanban view now keeps the favorite icon properly aligned after a shared styling change affected its spacing. This preserves a clean, consistent layout for users managing documents.
Original PR description
The favorite icon in the Documents kanban view became misaligned after the `me-1` spacing class was removed from the generic favorite field widget in PR https://github.com/odoo/odoo/pull/250051. Apply the equivalent spacing in the Documents kanban view styles to preserve the icon alignment. Task-6326435
Payroll correction batches are now created under the same company as the payslips they contain. This prevents corrections for employees in one company from being grouped under another active company, improving accuracy in multi-company payroll operations.
Original PR description
Steps to reproduce: - Have an employee in company B, with a paid payslip - Log in with company A active (company B allowed but not selected) - Open the employee's paid payslip and click "Correct" The refund and correction payslips are computed in company B (their company follows the employee), but the pay run created for them by the wizard has no explicit company and falls back to the active company A. Set the pay run's company from the payslips it contains, and group the payslips by company as well as by structure so that a batch never mixes companies. task-6428755
The timesheet assistant now keeps the latest selected date in sync with the suggestions it displays. This prevents users from seeing outdated suggestions when quickly moving between dates, reducing confusion and helping ensure time entries are based on the intended day.
Original PR description
Before this commit, when the user hits multiple times the arrow button to change the date displayed in timesheet assistant, the suggestions displayed could be the suggestions from another day because a rpc is made each time the user changes the date and amoung all rpcs call, the one which takes more time then the one will be taken but it is not necessary the date shown in the view. This commit uses `KeepLast` class to avoid the concurrency issue with those rpcs to be able to always take the last rpc call to get the data. Forward-Port-Of: odoo/enterprise#126283
Customers can no longer increase rental product quantities in the cart beyond what is available for the selected dates. The fix also rechecks availability when rental dates are changed, helping prevent overbooking for rentals linked to planning shifts.
Original PR description
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning…
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. Add as much product "test" to the cart as possible (the quantity is limited) 7. Open the cart 8. You can increase the amount of the product regardless of its availability Issue: We don't check the renting availabilities to limit the maximum quantity of the product Solution: Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates opw-6274035 Forward-Port-Of: odoo/enterprise#126007 Forward-Port-Of: odoo/enterprise#123056
Normal invoicing users can now post invoices or reset them to draft when Avalara tax integration is enabled. This fixes an access issue where a setting needed for those actions was only readable by administrators.
Original PR description
The field `avalara_connection_method` has a restriction to only admins, but needs to be read by normal invoicing users in order to post or reset invoices to draft.
The Timesheet Assistant now ignores calendar events marked as available, since those are not meant to be timesheeted. This keeps suggestions focused on relevant work events and helps users avoid incorrect or distracting recommendations.
Original PR description
## Previous Behavior In the Timesheet Assistant view, calendar events marked as *available* were still being suggested. These events are not intended to be timesheeted and should not appear in the assistant’s recommendations. Their presence could also obscure more relevant events that require user attention. ## New Expected Behavior Calendar events marked as *available* are now excluded from Timesheet Assistant suggestions. task-[6431591](https://www.odoo.com/odoo/project/4105/tasks/6431591) Forward-Port-Of: odoo/enterprise#126183
Users can now generate sample timesheet activity data even when ActivityWatch is connected. This lets teams view sample entries together with real activity data, making demonstrations and testing easier without disconnecting ActivityWatch.
Original PR description
Before this commit, the Generate Sample Data button only worked when the ActivityWatch server was unavailable. When ActivityWatch was running, users could only load real activity data. After this commit, clicking Generate Sample Data while ActivityWatch is connected injects the generated sample events alongside the real ActivityWatch events, allowing both to be displayed together. task-6373606 Forward-Port-Of: odoo/enterprise#124981
The Stripe expense cardholder field now correctly respects filtering rules set in the view. This helps users see the right selectable records and prevents incorrect or missing choices when working with expense cardholders.
Original PR description
After https://github.com/odoo/odoo/issues/196785; the standard way to build a custom m2o field in JS is to call a method from the Many2one module, instead of extending an object from it. This commit solves issues regarding domain in the view not being passed to the widget opw-6399906 Forward-Port-Of: odoo/enterprise#125346
Guatemalan electronic invoice PDFs now match the official XML when a customer is treated as final consumer (CF). The fix also handles placeholder tax IDs as missing and applies the legal invoice value threshold consistently across currencies, reducing reporting mismatches.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
Activity Watch timesheet entries can now use a task ID found directly in a page URL or window title when matching recorded work to tasks. This reduces incorrect or uncertain task suggestions and helps users log time more accurately with less manual correction.
Original PR description
Before this commit, when the task_id to link to activity watch can be found in the URL or window/tab name but it is not possible for the user to create a regex to be able to automatically say to the system the task_id is found in the event name recorded by activity watch. This commit adds the possibility to define `task_id` group name inside the regex to be able to take that information instead of searching which task is linked to that event based on previous key event or the frequency of the current user. task-[6384029](https://www.odoo.com/odoo/project.task/6384029) Forward-Port-Of: odoo/enterprise#124113
Date and datetime fields are now handled like other fields when adding spreadsheet columns. Once added, they disappear from the selection popover, preventing duplicate columns and reducing inconsistent spreadsheet behavior.
Original PR description
Current behavior before PR: - Date and datetime fields remained visible in the popover after being added as columns, allowing the same field to be added multiple times. - Since column fields do not consider granularity, allowing duplicate date fields could create duplicate IDs and inconsistent behavior. Desired behavior after PR is merged: - Treat date and datetime fields the same as other column fields when determining which fields to display in the popover. - Once a date or datetime field is added as a column, it is no longer shown in the popover to prevent duplicate IDs. Task: [6295794](https://www.odoo.com/odoo/project/2328/tasks/6295794)
16 changes
Enhancements to existing features
The Chilean F29 tax report has been updated to use a clearer six-column layout and calculate all report lines more efficiently in one step. This improves performance, accuracy, and usability for companies preparing Chilean tax submissions.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Payroll runs now avoid repeating unnecessary work when preparing payslips, making large payroll batches complete much faster. This improves processing time for HR and payroll teams, especially when handling many employees at once, without changing payroll results.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/124776 without the populate blueprint.
Resolved issues and error corrections
The Journal Audit report could crash after changing and then removing the root report on the Generic Tax Report. This fix restores the report query correctly so accounting users can open Journal Audit without an internal server error.
Original PR description
Step To Reproduce: - Install the Accounting module. - Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report. - Set the Root Report to "Balance Sheet" and save. - Remove the…
Step To Reproduce:
- Install the Accounting module.
- Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report.
- Set the Root Report to "Balance Sheet" and save.
- Remove the Root Report and save again.
- Open Accounting -> Reporting -> Journal Audit.
Issue:
Opening the Journal Audit report raises an Internal Server Error with: psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "account_move_line__move_id"
Reason:
The code that recreates the missing "account.move" join was not updated consistently with the other "_join()" usages. Without calling "._sudo()", the ORM builds the join using a filtered subquery (for example, adding the company filter), which changes the generated join alias(https://github.com/odoo/odoo/blob/saas-19.1/odoo/orm/fields_relational.py#L559). The SQL query still references the regular alias (account_move_line__move_id), causing the query to fail.
Reference PR:- https://github.com/odoo/enterprise/pull/101230
Solution:
Use "query.table._sudo()._join()" when recreating the missing "account.move" join, matching the other "_join()" usages and ensuring the expected join alias is generated.
before fix:-
`'account_move_line__move_id__2': (SQL('JOIN'), SQL('(SELECT "account_move".* FROM "account_move" WHERE "account_move"."company_id" IN %s)', (1,)), SQL('"account_move_line"."move_id" = "account_move_line__move_id__2"."id"'))`
Query : `JOIN (
SELECT
account_move.*
FROM account_move
WHERE account_move.company_id IN (1)
) AS account_move_line__move_id__2
ON account_move_line.move_id = account_move_line__move_id__2.id`
after fix:-
`'account_move_line__move_id': (SQL('JOIN'), SQL('"account_move"'), SQL('"account_move_line"."move_id" = "account_move_line__move_id"."id"'))`
Query : `JOIN account_move AS account_move_line__move_id
ON account_move_line.move_id = account_move_line__move_id.id`
opw-6425842
Forward-Port-Of: odoo/enterprise#125968German DATEV general ledger exports now show the exchange rate in the correct direction and round it to six decimal places. This improves compliance with DATEV formatting expectations and prevents overly long or misleading values in exported accounting files.
Original PR description
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses:…
### Steps to Reproduce: 1. Activate l10n_de 2. Navigate to the General Ledger and export the "Datev DATA" 3. Column D, "Kurs," is incorrect ### Description of the issue/feature this PR addresses: **Issue:** DATEV documentation states that the column for "Kurs" should be the ratio of WKZ-Umsatz : WKZ-Basisumsatz, which is Foreign : Base Currency. Additionally, all sample files show this column's values being rounded to 6 decimal places. Currently, when Odoo exports the general ledger as DATEV data, there is no rounding of decimal places and the formula does base / foreign amount, `line_amount / line_amount_currency`. **Solution:** In the `datev_export_csv.py` file, the relevant method is called `_l10n_de_datev_get_csv()`. In there, we can fix the line to round the value of `line_amount_currency / line_amount` to 6 decimal places. ### Current behavior before PR: Exporting the general ledger as DATEV data currently gives the reverse foreign currency rate and fails to round to 6 decimal places, which causes some values to be extremely long. ### Desired behavior after PR: The csv files should output the correct rate and be rounded appropriately. **Releted Documentation:** https://developer.datev.de/en/file-format/details/datev-format/format-description/booking-batch opw-6366276s Forward-Port-Of: odoo/enterprise#125097
Audit reports now use the company selected for the report when adding accounting report sections. This prevents the header from showing the user's default company address when the audit report is generated for another company.
Original PR description
When adding the accounting reports to the audit report, we browse the reports with the request's environment which is defaulting to the user's main company. As a result, the company's address displayed in the reports' header is not correct if we generate the audit report for any other company with a different address. https://github.com/odoo/enterprise/blob/aaab137897e6ad794247470e48d5ea91382577a3/account_reports/data/pdf_export_templates.xml#L85 We propose to inject the correct company in the report's environment. opw-6373956 Forward-Port-Of: odoo/enterprise#125125
This fixes a crash that stopped employees without Sales access from using the attendance time clock. Those users can now check in normally, while sales-only billing information is handled only when the user has the right permissions.
Original PR description
## Current behavior: When users without Sales rights open the attendance systray (the green dot icon) to check-in, the system will crash with error `TypeError: Cannot read properties of undefined (reading 'relatedPropertyField')` ## Expected behavior: Users without Sales rights should still be able to log time without any problems ## Steps to reproduce: 1. In Users setting > Access Rights tab > Sales section, give your own account any rights to access (e.g. Own Documents), observe that your account can log time via green dot icon. 2. Now try to set the Sales rights to 'No', then log time by clicking on the green dot icon to check-in. Oops! ## Cause of the issue: For users without sales access, is_billable was not returned by fields_get (group-restricted), but it still ended up in record.data ## Fix: Ensure user has the salesman rights before assigning is_billable to record data opw-6323881
This fix makes the Swedish Point of Sale test consistently complete order creation at the end of its automated flow. It reduces random test failures, helping maintain confidence in Swedish POS localization quality without changing user-facing behavior.
Original PR description
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing:…
## Issue The tour `test_l10n_se_pos_01` does not consistently create its `pos_order`. This leads to the following assert failing: https://github.com/odoo/enterprise/blob/0f6f6fac892bc8cec477160a790d52fbf053be99/l10n_se_pos/tests/test_se_pos.py#L40-L42 ## Steps to reproduce 1. Install `l10n_se_pos` 2. Run the test `test_l10n_se_pos_01` 3. **The test fails non-deterministically** ## Fix We use `clickNextOrder()` at the end of the tour to ensure the creation of the order, like other tests already do (e.g., [FinishResidualOrder](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L676-L677), [test_name_preset_skip_screen](https://github.com/odoo/odoo/blob/7fc645e5a3fad9255432e7cc68d47bd0971d3d77/addons/pos_restaurant/static/tests/tours/pos_restaurant_tour.js#L1333-L1334), [PosOrderCreationTourPdis](https://github.com/odoo/enterprise/blob/08d5172a8c3310af0c51e18a281c544f83f5aed7/pos_enterprise/static/tests/tours/point_of_sale/pos_tour.js#L141-L142), ...). runbot-238568 Forward-Port-Of: odoo/enterprise#125672
Users can now click directly into custom fields added to the Documents list view and edit them inline. This removes an extra workaround step and makes customized document workflows behave consistently with standard fields.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125378 Forward-Port-Of: odoo/enterprise#125239
This fix makes an automated barcode workflow test wait until a transfer is clearly ready to validate before pressing the validate button. It reduces random test failures, helping keep the stock barcode feature stable and release checks more dependable.
Original PR description
Make sure the validate button has the 'primary-btn' class as it means that the transfer is valid before clicking on it. runbot-939917 Forward-Port-Of: odoo/enterprise#125221 Forward-Port-Of: odoo/enterprise#125005
Swiss payroll calculations now round amounts directly to the required 0.05 precision instead of relying on a workaround that could create tiny, incorrect differences. This improves consistency in payroll declarations and helps avoid unnecessary salary-change entries caused only by rounding noise.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
Internal CRM users who are not administrators can once again use the business card lead generation option when the related app is available. The change fixes an overly restrictive access check while keeping administrator-only installation and proper access messages where specific permissions are required.
Original PR description
**Steps to reproduce:** - Go to CRM app as an internal user (non-admin) - Click on Generate button - Can't create leads from business card pictures - Only setting the user as admin enables it (was…
**Steps to reproduce:** - Go to CRM app as an internal user (non-admin) - Click on Generate button - Can't create leads from business card pictures - Only setting the user as admin enables it (was working fine in previous versions) **Issue:** Dropdown action is restricted to admin only by default using `hasAccess`. If there is a corresponding model on the `LeadGenerationDropdown` it is later changed according to the current user access rights using `await user.checkAccessRight(model, "create")`. **Fix:** Default `hasAccess` to `True` as there is no related model for the lead generation of business cards. (Note: could also provide the missing model ?) - Installation should be restricted to the admin. - Access message should be shown to the user if he doesn't have enough rights to the related model. - Non-admin users should be able to use the feature if no model is provided and the related app is available. dropdown: https://github.com/odoo/odoo/commit/978019522746ccb971eeb15c5d9530e438b7d2f3 business card: https://github.com/odoo/enterprise/commit/48a9cba24cb51b11a08dd9c0ff1291e15232260f opw-6258689
Activity Watch can now identify the related task directly from a configured pattern in the window title or URL. This reduces incorrect timesheet suggestions when task references are already present in activity data.
Original PR description
Before this commit, when the task_id to link to activity watch can be found in the URL or window/tab name but it is not possible for the user to create a regex to be able to automatically say to the system the task_id is found in the event name recorded by activity watch. This commit adds the possibility to define `task_id` group name inside the regex to be able to take that information instead of searching which task is linked to that event based on previous key event or the frequency of the current user. task-[6384029](https://www.odoo.com/odoo/project.task/6384029)
This fix prevents a live Argentina ARCA currency-rate test from running in daily builds where internet access is blocked. It keeps the test available for nightly runs, reducing false build failures without changing customer-facing behavior.
Original PR description
Description of the issue this commit addresses: The live ARCA currency rate test keeps the inherited `standard` tag. It is therefore selected by daily builds whose HTTP guard blocks the request. The guard also blocks it when selected by the external localization suite. --- Desired behavior after this commit is merged: This commit removes the `standard` tag from the live ARCA test. Daily builds skip the test while nightlies still run it with HTTP access. --- runbot-[238857](https://runbot.odoo.com/odoo/error/238857)
Calendar events marked as available are no longer shown as Timesheet Assistant suggestions. This keeps recommendations focused on events that may actually need timesheet entries and reduces clutter for users.
Original PR description
## Previous Behavior In the Timesheet Assistant view, calendar events marked as *available* were still being suggested. These events are not intended to be timesheeted and should not appear in the assistant’s recommendations. Their presence could also obscure more relevant events that require user attention. ## New Expected Behavior Calendar events marked as *available* are now excluded from Timesheet Assistant suggestions. task-[6431591](https://www.odoo.com/odoo/project/4105/tasks/6431591) Forward-Port-Of: odoo/enterprise#126183
This fix updates how Peruvian electronic invoices format address details so they match SUNAT's current requirements. It helps invoices pass validation by correctly handling districts and urban subdivisions under the newer standard.
Original PR description
Update electronic invoicing address nodes to align with current SUNAT requirements. This transitions the geographic data formatting from the legacy UBL 2.0 schema to the standard UBL 2.1 specification, ensuring proper structural validation for districts and urban subdivisions. Documentation used: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia+xml+factura+version+2-1+1+0+(2)_0+(2).pdf opw-6282314 Forward-Port-Of: odoo/enterprise#125406 Forward-Port-Of: odoo/enterprise#121390
Rental orders using a custom make-to-order buying route now correctly create the expected return transfer as well as the delivery and purchase. This prevents missing return operations and helps teams track rented products reliably through the full rental cycle.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes and rental transfers - Unarchive the MTO route - Create a rental product P with a buy route and a set vendor - Create a rental order for 1 x P and set the the MTO route on the sol - Confirm the order #### > The delivery as well as the purchase for 1 unit of P was generated but the return was not. ### Cause of the issue: The procurement generated to handle both the delivery and the return rental picking are handled by the `_create_procurements`: https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/sale_stock_renting/models/sale_order_line.py#L353-L374 The `route_ids` set and used is the `mto_route` set on the sol: https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L415-L422 https://github.com/odoo/odoo/blob/0f061503e26ac8c441d62d91947419119e48c47a/addons/sale_stock/models/sale_order_line.py#L282-L297 However, in the present case, the mto route does not contain any rule with a relevant `location_src_id` in the rental location so that the return will not be generated. opw-6361322 Forward-Port-Of: odoo/enterprise#126078 Forward-Port-Of: odoo/enterprise#124097
11 changes
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in one pass, improving performance and reliability for users preparing tax declarations. The update also refines the six-column report layout, tax credit handling, withholding sections, and related submission flow to better match reporting needs.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Payment export files now include building numbers in structured addresses for ISO 20022 formats. This prepares businesses for upcoming banking requirements that make this information mandatory from November 2026.
Original PR description
This commit adds the <BldgNb> node in the iso20022 XML files, as it will be mandatory starting November 2026. Linked: https://github.com/odoo/odoo/pull/271855 task-6317758 Forward-Port-Of: odoo/enterprise#126377 Forward-Port-Of: odoo/enterprise#121674
Resolved issues and error corrections
Bank transaction matching now ignores archived bank accounts when choosing the customer or vendor. This prevents transactions from being assigned to outdated partners and helps automatic reconciliation follow the expected payment details instead.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124537
Users can now click and edit custom fields directly in the Documents list view, including fields added through Studio. This removes an extra step and makes document data entry faster and more intuitive.
Original PR description
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The…
**Description of the issue/feature this PR addresses:** When adding a custom field (e.g., via Studio) to the Documents list view, clicking the cell directly does not trigger inline edit mode. The user has to first click a standard editable field (like "Owner") to put the row into edit mode before they can modify the custom field. This occurs because we use a hardcoded whitelist (`editableColumns`) of standard fields allowed to trigger edit mode. Custom fields (`x_`) are missing from this static list. This commit resolves the issue by dynamically injecting visible, non-readonly custom fields into the `editableColumns` whitelist. This allows user-created fields to be edited inline as expected. **Steps to reproduce:** - Documents > Studio > List view > Add any field that accepts user input (e.g. Text/char) > save/exit - In the same Documents list view > select a row > click the cell belonging to the newly created field > observe that the row does not enter edit mode - In the same Documents list view > select a row > click a standard editable cell, then click the cell belonging to our newly created field > observe that this then allows us to edit our field **Current behavior before PR:** - Custom fields do not trigger inline edit mode **Desired behavior after PR is merged:** - Custom fields trigger inline edit mode opw-6378102 Forward-Port-Of: odoo/enterprise#125378 Forward-Port-Of: odoo/enterprise#125239
Audit reports now use the company selected for the report instead of defaulting to the user's main company. This ensures the correct company address appears in accounting report headers, avoiding misleading audit documentation for multi-company users.
Original PR description
When adding the accounting reports to the audit report, we browse the reports with the request's environment which is defaulting to the user's main company. As a result, the company's address displayed in the reports' header is not correct if we generate the audit report for any other company with a different address. https://github.com/odoo/enterprise/blob/aaab137897e6ad794247470e48d5ea91382577a3/account_reports/data/pdf_export_templates.xml#L85 We propose to inject the correct company in the report's environment. opw-6373956 Forward-Port-Of: odoo/enterprise#125125
Guatemalan electronic invoice PDFs now show 'CF' whenever the official XML uses it, keeping the customer-facing document aligned with the submitted tax file. The fix also treats placeholder VAT entries as missing and applies the 2,500 threshold in company currency, reducing compliance inconsistencies on foreign-currency invoices.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
The Timesheet Assistant now filters out calendar events marked as available, so users only see events that are relevant for timesheet entry. This reduces clutter and helps prevent less important calendar items from hiding events that may need attention.
Original PR description
## Previous Behavior In the Timesheet Assistant view, calendar events marked as *available* were still being suggested. These events are not intended to be timesheeted and should not appear in the assistant’s recommendations. Their presence could also obscure more relevant events that require user attention. ## New Expected Behavior Calendar events marked as *available* are now excluded from Timesheet Assistant suggestions. task-[6431591](https://www.odoo.com/odoo/project/4105/tasks/6431591)
This fixes rounding in Swiss payroll calculations so amounts are rounded directly to the correct 0.05 precision. It prevents tiny calculation differences from appearing in monthly salary declarations, improving consistency and reducing false changes in payroll reporting.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
This fixes an intermittent failure in barcode transfer tests by ensuring the validation button is only clicked once the transfer is actually ready. It helps keep automated checks stable without changing day-to-day warehouse operations.
Original PR description
Make sure the validate button has the 'primary-btn' class as it means that the transfer is valid before clicking on it. runbot-939917 Forward-Port-Of: odoo/enterprise#125221 Forward-Port-Of: odoo/enterprise#125005
The aged payable and receivable drill-down now hides fully paid invoices and bills, so users only see items that were genuinely outstanding. Historical reports also respect the selected reporting date, improving accuracy when reviewing past balances.
Original PR description
Steps to Reproduce: 1. Create a vendor/customer with multiple bills/invoices. 2. Fully pay one or more, leaving at least one still open for the same partner. 3. Open Accounting > Reporting > Partner…
Steps to Reproduce:
1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set to any date and click into an aging bucket for that partner.
Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.
Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.
Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:
action['context'] = {
'recon_limit': options['date']['date_to'],
}
Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.
Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.
opw 6333699Manufacturing planning forecast tests were updated to match the latest demand calculation, which now includes replenishment scheduled later on the current day. This helps keep planning checks accurate and supports more reliable forecast suggestions.
Original PR description
Updated the forecast suggestion test expectations after monthly demand was updated to count the full current day, so same-day orderpoint replenishment moves scheduled later in the day are also included Community PR: odoo/odoo#262435 TaskID-5490137 Forward-Port-Of: odoo/enterprise#115944
5 changes
Resolved issues and error corrections
Automatic bank transaction matching now ignores archived bank accounts when identifying the related partner. This prevents payments from being assigned to the wrong partner and helps reconciliation rules choose the correct match.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124537
Guatemalan electronic invoice PDFs now show “CF” whenever the official XML uses CF, keeping the customer-facing document aligned with the tax submission. Placeholder tax IDs are treated as missing, and the legal threshold is checked in the company currency so the rule is applied consistently across currencies.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
This fixes small rounding errors in Swiss payroll calculations by using the proper 0.05 rounding precision directly. It helps ensure salary declaration values are consistent and avoids tiny discrepancies that could affect payroll reporting tests or outputs.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
This fix makes the automated barcode workflow wait until a transfer is truly ready before validating it. It reduces random test failures, helping keep warehouse barcode processes more stable during updates.
Original PR description
Make sure the validate button has the 'primary-btn' class as it means that the transfer is valid before clicking on it. runbot-939917 Forward-Port-Of: odoo/enterprise#125221 Forward-Port-Of: odoo/enterprise#125005
Follow-up filters are now only shown to invoicing and accounting users who have access to the related follow-up status information. This prevents other users from encountering access errors when viewing or using customer follow-up options.
Original PR description
Description of the issue this commit addresses: Follow-up filters are visible to users without access to the restricted followup status field. Using these filters queries journal items and raises an access error. --- Desired behavior after this commit is merged: This commit limits the follow-up filters to invoicing and accounting users, matching the access groups of the followup status field. --- runbot-[161825](https://runbot.odoo.com/odoo/error/161825) Forward-Port-Of: odoo/enterprise#125674
4 changes
Enhancements to existing features
SEPA direct debit batch validation has been optimized to handle large payment batches more efficiently. Businesses processing hundreds or thousands of direct debit payments should see noticeably faster validation and notification steps, reducing delays and timeouts.
Original PR description
- Replace the `id:recordset` aggregation in `_get_expiry_date_per_mandate()` with `date:max` to compute the latest payment date directly in SQL. - Render `email_from` for all payments in batch and cache the computed authors by sender email to avoid repeated partner lookups during SDD pre-notification. This reduces ORM/cache overhead when validating large SEPA batches containing thousands of payments. Measured on a production-sized database: | metric | before | after | factor | |--------|-------:|------:|-------:| | `_get_expiry_date_per_mandate` (500 payments) | 564 ms | 111 ms | ~5x | | `_send_after_validation` notification (500 payments) | 92.9 s | 55.7 s | ~1.7x | | `_get_expiry_date_per_mandate` (1000 payments) | 890 ms | 178 ms | ~5x | | `_send_after_validation` notification (1000 payments) | timed out (>159 s) | 108.9 s | completed | OPW-6377340 Forward-Port-Of: odoo/enterprise#125439
Resolved issues and error corrections
Guatemalan electronic invoice PDFs now match the official XML by showing 'CF' whenever the XML uses it. Placeholder tax IDs are treated as missing, and invoice limits are checked in the company currency so legal thresholds are applied consistently across currencies.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
Swiss payroll calculations now use the correct 0.05 rounding directly, avoiding tiny precision differences that could affect monthly salary comparisons and declarations. This makes payroll results more consistent and prevents unnecessary changes from appearing in Swissdec ELM reporting tests and outputs.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
Follow-up filters are now only shown to invoicing and accounting users who have access to the related follow-up status information. This prevents other users from triggering access errors when viewing or filtering customer follow-up data.
Original PR description
Description of the issue this commit addresses: Follow-up filters are visible to users without access to the restricted followup status field. Using these filters queries journal items and raises an access error. --- Desired behavior after this commit is merged: This commit limits the follow-up filters to invoicing and accounting users, matching the access groups of the followup status field. --- runbot-[161825](https://runbot.odoo.com/odoo/error/161825)
8 changes
New functionality added to Odoo
Adds support for Mexican expense workflows by letting employees upload CFDI XML documents directly from an expense. This helps companies handle local compliance needs before the expense is approved and fully connected to the accounting entry.
Original PR description
Currently, the expenses module is not compatible on how the mexican market manages the expenses. The usual way of creating an expense and waiting to approval is not compatible on how in Mexico the expenses are usually done. To target this, a new button is added in the expense form view to upload a CFDI xml and create or link an existing edi document, instead of linking with the accounting entry, allowing to have access to this entry until the expense is approved and the expense is completely linked to the entry target: master task: 4455671
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in a single process, improving performance and consistency. The update also refines the six-column report layout, tax calculations, withholding sections, and submission flow to better support Chilean tax reporting needs.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648 Forward-Port-Of: odoo/enterprise#106701
Spreadsheet date fields now use Odoo’s standard date picker in calendar buttons. This makes choosing dates in conditional formatting and data validation panels more consistent and easier for users.
Original PR description
DateTimePickerPopover from Odoo is now used in the CalendarButton component of spreadsheet (CF and DV side panels) Task: 5395190
Resolved issues and error corrections
Ecuadorian invoice printouts now show the company logo in the header again. The header layout was slightly adjusted so the logo fits cleanly within the existing invoice format.
Original PR description
### Issue: In 19.3, the EC invoice header completely replaces the standard header in `report_invoice_document` after commit `08d17cc49c` The company logo was not included in the custom header, leaving invoices without a logo ### Cause: The logo was simply missing from the header template ### Fix: The logo is added and some header elements are resized (`h5` → `h6`, reduced margin) to keep the layout within the existing paper format without requiring a new one ### Steps to reproduce: - Install `l10n_ec_edi` with demo data - Open and print any invoice Before the fix, the company logo is missing from the header opw-6377830 Forward-Port-Of: odoo/enterprise#125469
Fixes an issue where changing and then removing the root report on the Generic Tax Report could cause the Journal Audit report to fail with an internal server error. This ensures accounting users can open the report reliably after configuration changes.
Original PR description
Step To Reproduce: - Install the Accounting module. - Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report. - Set the Root Report to "Balance Sheet" and save. - Remove the…
Step To Reproduce:
- Install the Accounting module.
- Go to Accounting -> Configuration -> Accounting Reports -> Generic Tax Report.
- Set the Root Report to "Balance Sheet" and save.
- Remove the Root Report and save again.
- Open Accounting -> Reporting -> Journal Audit.
Issue:
Opening the Journal Audit report raises an Internal Server Error with: psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "account_move_line__move_id"
Reason:
The code that recreates the missing "account.move" join was not updated consistently with the other "_join()" usages. Without calling "._sudo()", the ORM builds the join using a filtered subquery (for example, adding the company filter), which changes the generated join alias(https://github.com/odoo/odoo/blob/saas-19.1/odoo/orm/fields_relational.py#L559). The SQL query still references the regular alias (account_move_line__move_id), causing the query to fail.
Reference PR:- https://github.com/odoo/enterprise/pull/101230
Solution:
Use "query.table._sudo()._join()" when recreating the missing "account.move" join, matching the other "_join()" usages and ensuring the expected join alias is generated.
before fix:-
`'account_move_line__move_id__2': (SQL('JOIN'), SQL('(SELECT "account_move".* FROM "account_move" WHERE "account_move"."company_id" IN %s)', (1,)), SQL('"account_move_line"."move_id" = "account_move_line__move_id__2"."id"'))`
Query : `JOIN (
SELECT
account_move.*
FROM account_move
WHERE account_move.company_id IN (1)
) AS account_move_line__move_id__2
ON account_move_line.move_id = account_move_line__move_id__2.id`
after fix:-
`'account_move_line__move_id': (SQL('JOIN'), SQL('"account_move"'), SQL('"account_move_line"."move_id" = "account_move_line__move_id"."id"'))`
Query : `JOIN account_move AS account_move_line__move_id
ON account_move_line.move_id = account_move_line__move_id.id`
opw-6425842
Forward-Port-Of: odoo/enterprise#125968Users in single-company setups can now change the journal on depreciation models when no company was previously set. This removes a configuration blocker that prevented asset depreciation settings from being updated correctly.
Original PR description
When no company is set on a depreciation model, we only display the `journal_placeholder_id` field which is readonly. But in a single company environment, the 'company_id` field is hidden, therefore it becames impossible to change the journal for depreciation models. Fix: Always display the `company_id` field, but we remove the warning in the onchange when we are in a single company environment. opw-6299390 Forward-Port-Of: odoo/enterprise#121518
The Belgian payroll help text for spouse fiscal status thresholds has been corrected to reduce ambiguity and help users apply the right status. The update also includes the 2026 low-income threshold, supporting more accurate payroll handling for upcoming fiscal rules.
Original PR description
The spouse fiscal status thresholds help text was not accurate enough and could lead to misinterpretation. This commit updates the help text to provide a more accurate description of the thresholds, and adds the low income threshold for 2026. task-6320606
Dragging and dropping planning events no longer crashes when a related resource filter is absent. This keeps scheduling workflows stable after configuration changes in field service planning.
Original PR description
A [recent change](https://github.com/odoo/enterprise/pull/122027/changes#diff-48a8aacbd3dc336e47073b496aa80c310674bc0fd0f84fbb05d9472a9289afe4R264) in `planning_field_service` uses `position="replace"` to completely remove the `resource_ids` field. Because the field is missing from the XML, the frontend never builds `this.data.filterSections.resource_ids`. Dragging and dropping an event blindly assumes this object exists, resulting in a `TypeError` crash. task: 6421678
8 changes
Enhancements to existing features
The Chilean F29 tax report has been optimized to calculate all report lines in a single process, improving performance and reliability. The update also refines the six-column layout and related submission/reporting logic so businesses can review tax information more efficiently.
Original PR description
This commit optimizes the F29 report by using just one big query to compute the data for all the report lines at once. task-4329648
Resolved issues and error corrections
Fixed an issue where rental stock availability for click & collect could be blocked by reservations or orders from a different warehouse. Customers can now rent items from the selected pickup location when stock is actually available there, reducing false out-of-stock errors.
Original PR description
When using the click & collect option, the available qty for renting was not taking the selected warehouse into account. Steps to reproduce: ------------------- * Create 2 different warehouses with 2…
When using the click & collect option, the available qty for renting was not taking the selected warehouse into account. Steps to reproduce: ------------------- * Create 2 different warehouses with 2 different adresses * Create a product available for renting * Setup the product to use serial numbers * Create 2 serial number, 1 in each warehouse * Activate the click & collect option on the website * Create a first sale order to collect in warehouse 1 * In the backend, confirm the order and pick it up * Go back to the website and make a second order for the second warehouse > Observation: When clicking on the "Add to cart" you get an error saying that there is no quantity available Why the fix: ------------ When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses. opw-6328475
Bank transaction matching now ignores archived bank accounts when choosing the related partner. This prevents old account details from assigning payments to the wrong partner and helps automated reconciliation follow the expected active records and transaction details.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124537
The Malaysian Statement of Account option now appears only for companies based in Malaysia. This prevents users in other countries from seeing or running a country-specific report that does not apply to them.
Original PR description
### Current behavior: After installing `l10n_my_reports`, the Malaysian's Statement of Account button appears on Aged Receivable for every company, and the partner Action "Print Statement of Account" can be run from non-MY companies ### Expected behavior: To avoid user confusion, it is advised to restrict its visibility so that it is only accessible to Malaysia-specific companies ### Steps to reproduce: 1. Install `l10n_my_reports` 2. Switch to a non-Malaysian company 3. Open Invoicing > Reporting > Aged Receivable 4. Observe the "Statement of Account" button on partner lines ### Cause of the issue: Missing checks for 'MY' company country code in UI and print report action ### Fix: - show the Aged Receivable SoA button only when `company_country_code === 'MY'` - guard `action_print_report_statement_account` for non-MY companies opw-6340854
Swiss payroll calculations now round amounts directly to the required 0.05 precision instead of using an indirect method that could create tiny differences. This improves consistency in payslip and declaration values and prevents unnecessary salary change entries caused only by rounding artifacts.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
Guatemalan electronic invoice PDFs now match the tax ID logic used when generating the official XML file. This prevents mismatches by treating common placeholder VAT values as missing and applying the legal 2,500 threshold in the company currency.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333 Forward-Port-Of: odoo/enterprise#120985
Appointment cancellation emails are now sent in the language of the customer who booked the appointment, matching the behavior of confirmation emails. This avoids confusing customers with messages in the staff member's language while keeping the old behavior for non-appointment events.
Original PR description
**Problem:** When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation,…
**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.
**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.
**Current behavior:**
The cancellation email is rendered in the organizer's language.
**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.
**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.
**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.
opw-6323179
Forward-Port-Of: odoo/enterprise#124116The barcode workflow test now waits until a transfer is clearly ready to validate before proceeding. This prevents occasional false test failures and helps keep inventory barcode processes stable during updates.
Original PR description
Make sure the validate button has the 'primary-btn' class as it means that the transfer is valid before clicking on it. runbot-939917 Forward-Port-Of: odoo/enterprise#125221 Forward-Port-Of: odoo/enterprise#125005
5 changes
Resolved issues and error corrections
This fix corrects how Swiss payroll amounts are rounded to the nearest 0.05, avoiding tiny calculation differences caused by floating-point arithmetic. It helps produce more consistent payslip and Swissdec declaration values, reducing unexpected test or reporting discrepancies.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937 Forward-Port-Of: odoo/enterprise#121401
Guatemalan invoice PDFs now show 'CF' consistently with the official electronic XML when customer tax details are missing or use placeholder values. The tax threshold check also uses the company currency, helping ensure legal limits are applied correctly for invoices in any currency.
Original PR description
with this commit:- - Display 'CF' in the invoice PDF whenever the generated XML uses CF. - Treat placeholder VAT values such as '/', 'NA', and 'na' as missing VAT. - Compare the invoice total using the company currency instead of the document currency when evaluating the 2,500 threshold, ensuring the legal limit is applied consistently regardless of the invoice currency task-6305333
Accounting-only users can now print Spanish VAT record books even when the report includes point-of-sale transactions. This prevents an access error and lets finance teams complete VAT reporting without needing extra POS permissions.
Original PR description
Steps to reproduce:
- With an ES Company
- Open a POS session, add product with tax and pay
- As a user with only accounting access
- Go to Accouting > Reporting > Tax report
- Select Generic Tax report
- Print "VAT record Books"
Issue:
An AccessError will raise
```
Access Error
You are not allowed to access 'Point of Sale Session' (pos.session) records.
This operation is allowed for the following groups:
- Point of Sale/User
Contact your administrator to request access if necessary.
```
Analysis:
Vat Record Books handler for POS needs to read pos.session and pos.order records. Currently, the action is performed with the rights of the user running the report, so accounting-only user face an error.
As POS records are only read internally to build the report, we add sudo call to get the data.
opw-5862529
Forward-Port-Of: odoo/enterprise#125980The UK CIS report now correctly includes payments linked to receipts that have CIS tax applied. This ensures businesses get a more complete and accurate CIS reporting view, matching the behavior already available for vendor bills.
Original PR description
With the l10n_uk_reports_cis module installed: - Create a vendor bills and add a CIS tax --> This vendor's bills appear correctly in the report. - Create a receipt and add a CIS tax --> This type of bill appears in the report, but the payment is not showing up. opw-6282548
UrbanPiper online orders with tax-included products now calculate the correct per-item price when customers order more than one unit. This prevents inflated Point of Sale order totals and keeps reporting and customer charges accurate.
Original PR description
Steps to reproduce: --- - Configure a Point of Sale with UrbanPiper credentials. - Create a product priced at 100 with a 5% GST (Tax Included). - Sync the product with UrbanPiper. - Place an online order with a quantity greater than 1. Issue: --- - `total_with_tax` was incorrectly treated as the unit price for multi-quantity tax-included orders. Fix: --- - Calculate the unit price by dividing `total_with_tax` by the ordered quantity before creating the POS order line. task-6427634
5 changes
Resolved issues and error corrections
This fixes barcode transfers so each scanned package is kept as its own movement line when source and destination locations are the same. It prevents one package from being mistakenly absorbed into another line, ensuring package contents are transferred correctly and warehouse staff see the expected scan results.
Original PR description
On an internal transfer whose operation type has the same source and destination location, scanning a package was treated as a put in pack: since the package sits at the line's destination, it became the result package of the previous line, so package was absorbed and never moved. Skip that assignment when the package is also at the line's source location: it's then a package to move, not a result package. Steps to reproduce: - Internal Transfers operation type with the same source and destination, Packages and Storage Locations enabled - Two packages with content stored at that location - Barcode > scan the first package, then the second one - Expected: two lines, one per package - Actual: one line, the 2nd package becomes the result package of the first and its content is not transferred opw-6319481
Swiss payroll calculations now round amounts directly to the required 0.05 precision, avoiding tiny floating-point differences that could affect declaration comparisons. This makes salary values more consistent across months and keeps related payroll declaration tests aligned with the corrected results.
Original PR description
In multiple places within l10n_ch_hr_payroll_elm we use float_round to a precision of 0.01 but then manually round to 0.05 precision. 1. Open a python terminal 2. Enter 1000 % 0.05 >= 0.025 3. See this results to true, even though it shouldn't Fix this by using float_round with a precision of 0.05 instead. https://github.com/odoo/enterprise/blob/7f9cd01ff3dd470b06ae176982fd042243be8f3c/l10n_ch_hr_payroll_elm/models/hr_payslip.py#L102-L105 The change to `ema_declaration.json` is needed as previously it was expected that there was a small difference between salary over the months due to the odd rounding (a difference of like 0.000000000001). Adding the new rounding makes the values equal and test_ema_declaration_2023_01 would fail due to changeSalary no longer being in the computed dict. All the way to master! opw-6322937
Planning filters now apply employee and material role checks only to open shifts, avoiding incorrect results for already assigned shifts. This helps planners see more accurate shift lists when filtering by employee or material resources.
Original PR description
Before this commit, the domain wrongly assumes that we always search on shifts having no role or a role containing resources of types 'user' or 'material' (1). Additionally to the basic domain which searches on the shifts having resources of types 'user' or 'material' (2). After this commit, we add a condition on domain (1) to only apply it for open shifts (shifts having no resource_id). no-task
Fixed an issue in financial reports where clicking to expand the same line multiple times quickly could prevent it from closing again. This makes report navigation more reliable, especially on slower connections or when users click repeatedly.
Original PR description
Steps to reproduce:- - Open any report. - Click on a particular line to unfold more than once very fast(or throttle network to 3G) - Once line is unfolded click again to fold that line. - Line is not folding. Cause:- - When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked). - Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold the same line, resulting in unfolding the same line multiple times. - In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible. Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times. task-6260425
Fixes an issue where browsing between pages in the IoT device list could stop working after opening a device record. Users can now navigate device pages reliably when managing connected IoT hardware.
Original PR description
Since #72351, the pagination on IoT devices was broken due to how we were getting to the full device form when clicking on a record. We now change the override to use the existing method from the framework `switchToForm` which handles it better. opw-6058532