Daily updates from Odoo
Tuesday, June 9, 2026
12 changes · master
Resolved issues and error corrections
This update fixes an issue preventing users from accessing the payroll tab when creating a new employee in the Belgium localization. The fix involved adjusting how a related field is calculated, ensuring the payroll tab opens correctly without errors. This improves the employee onboarding process for Belgian companies.
Original PR description
[FIX] l10n_be: payroll tab opening
Bug reproduction:
1 - Master -> Belgium company -> Employee app.
2 - Create new employee, before saving it press to payroll tab, traceback is there.
Bug cause:
1 - available_l10n_be_worker_status has a compute
2 - l10n_be_worker_status uses filterable_selection widget that uses available_l10n_be_worker_status as whitelist_fname.
3 - Before available_l10n_be_worker_status compute works, the JS of widget executes and this.props.record.data[this.props.whitelist_fname].includes raises the error, since False has not includes
Bug solution:
1 - I have used the filterable_selection in the Belgium Localization before and it was not causing this issue.
2 - I noticed that inherited=True is used in field available_l10n_be_worker_status for the employee, but there is no upper model that uses this field so inherited=True is meaningless.
3 - When we deleted it, it works.
task - 6275543This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports. Specifically, fields 2955 and 2956 must always be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the eCDF, preventing data rejection and maintaining accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
This update adds a warning banner to key Philippine tax reports (SAWT/QAP, BIR 2306/2307, SLSP) to alert users when contacts within the report lack a defined entity type. This ensures accurate reporting and helps users quickly correct missing information, preventing potential issues with tax compliance.
Original PR description
Add a warning banner on SAWT/QAP, BIR 2306/2307, and SLSP reports when one or more contacts appearing in the report do not have an entity type set. The banner includes a link to view and update the affected contacts. Community PR: https://github.com/odoo/odoo/pull/268460 task-6278053
This update corrects an issue where combo products incorrectly appeared in the 'Invoiced Not Delivered' report even after full delivery of their items. The fix ensures the report accurately reflects only genuinely undelivered items by excluding the combo parent line, which doesn't track actual stock movements.
Original PR description
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps…
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps to reproduce:** 1. Create a combo product bundling two storable items. 2. Sell the combo on a sale order, confirm and invoice it. 3. Deliver every combo item. 4. Open Accounting > Review > Invoiced Not Delivered. **Current behavior:** The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information. **Expected behavior:** The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered. **Cause of the issue:** A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where `qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever. **Fix:** Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct. opw-6215110 Forward-Port-Of: odoo/enterprise#119243 Forward-Port-Of: odoo/enterprise#118942
This update corrects a bug in the Belgian payroll calculation that prevented the correct handling of the 'forced variable salary' for the 13th month pay structure. The fix ensures the system accurately incorporates this salary value during payslip computation, resolving a previous type error.
Original PR description
Steps to reproduce: * Create a new payslip in belgian localization * Set pay structure type to 13th month * Set the input value for the forced variable salary * Compute the payslip sheet Issue: * Despite the change of benefits to properties, the avg_variable_revenues was still being set as one of the benefit lines instead of ref_property value which was causing an type_error traceback Solution: A simple approach is to be followed to retrieve the value fo the forced variable salary from the actual property being set by the user at the payslip form view and will be accounted for in the payslip computation. Task: 6241608 Forward-Port-Of: odoo/enterprise#118862 Forward-Port-Of: odoo/enterprise#118644
This update fixes an issue preventing standard users from accessing timesheet configuration options and sharing rules with higher-level users. The change ensures all users with appropriate access, including those with 'All Timesheets' permissions, can correctly configure and share timesheet rules.
Original PR description
Issue 1: Assistant Rules inaccessible to standard users Steps to Reproduce: - Install sale_timesheet. - Disable the "Billing Rate Indicators" setting. - Log in as a user with only "Own Timesheets"…
Issue 1: Assistant Rules inaccessible to standard users Steps to Reproduce: - Install sale_timesheet. - Disable the "Billing Rate Indicators" setting. - Log in as a user with only "Own Timesheets" access. - Open the Timesheets app. Current Behavior: - The Configuration menu is completely hidden, making Assistant Rules inaccessible to the user. Cause: - When sale_timesheet is installed, the "All Timesheets" access restriction is inaccurately applied to the main Configuration parent menu rather than specifically targeting the Billing Rate child menus. - The Configuration menu is blacklisted using a strict AND condition, requiring the user to have the Use Assistant group and hold a Timesheets Admin / Administrator / Technical Features role. This prevents standard timesheet users from configuring their own rules. Fix: - Remove the "All Timesheets" access restriction from the parent Configuration menu and apply it directly to the Billing Rate menus instead. - Update the blacklisting logic to use an OR condition, ensuring the configuration menu is visible if a user has Admin access to timesheets or belongs to the Use Assistant group. --- Issue 2: Unable to share rules with higher-level users Steps to Reproduce: - Create a user with "All Timesheets" access. - Open the Timesheets app and navigate to Assistant Rules. - Attempt to share any rule with the newly created user. Current Behavior: - The new user is missing from the dropdown selection list. Cause: - The domain on the user selection field filters based on explicitly assigned groups (using group_ids for "Own Timesheets" access). Users with higher-level access, such as "All Timesheets" or "Timesheets Admin", have this access implied rather than explicitly assigned, meaning it only registers in `all_group_ids`. Fix: - Update the field domain to evaluate `all_group_ids` instead of `group_ids`. This ensures users with implied group access are correctly populated in the dropdown list. task-6236300 Forward-Port-Of: odoo/enterprise#117984
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price and total price accurately reflect the tax amount, providing correct order totals for UrbanPiper integrations. This improves the accuracy of online sales transactions.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119587 Forward-Port-Of: odoo/enterprise#92854
This update ensures that plugins used within the Odoo Sign service are correctly set up as services. This improves the stability and reliability of the sign request process, preventing potential errors and ensuring a smoother user experience for customers.
The Documents app's search feature was temporarily broken after a recent update to improve memory usage. This fix re-introduced a necessary step to ensure uploaded files are correctly indexed for searching. While the memory optimization remains in place, this change restores the core search functionality.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains…
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains the searched keyword/content **Issue:** After [1] (19.3+) the file upload process was reworked to avoid loading entire files into memory during attachment creation (removed `'raw': file.read()`). But this breaks the index content creation as it was using the `raw` field value during the create to trigger the `_index` function in `_get_datas_related_values`. Also, restoring the previous behavior for the indexation would undo the memory usage improvements that were made. **Fix:** Added the `_index` call in `_upload_file` after the attachment creation. Also optimize the default text index to avoid reducing too much the memory improvements (but for now the other mimetypes can still be impacted by the type-specific `_index_*` and the external libraries performances). [1] https://github.com/odoo/odoo/commit/6222dedaf89a595b6f499679c3f553aa081c46bd opw-6232999 Forward-Port-Of: odoo/enterprise#119635
This update corrects a bug that prevented signature requirement features from working correctly for US deliveries using UPS. The change adjusts the API request to match UPS's requirements for package-level deliveries, ensuring accurate rate calculations and delivery confirmation. This resolves an error message related to unavailable options.
Original PR description
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create…
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create a product with some weight - Create a SO for the product - Add UPS delivery and try to get a rate > Error: "The requested accessory option is unavailable between the selected locations." Cause ----- Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link) https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US US50 -> US50 & Canada -> Canada is package level Everything else is shipment level By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value. https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911 For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421 ----- Ticket: opw-6173624 Forward-Port-Of: odoo/enterprise#117564
This update introduces support for calculating and reporting voluntary overtime hours in Belgium, aligning with local regulations. It includes new work entry types, salary rules, and reporting mechanisms for DMFA and 281.10 tax forms, ensuring accurate payroll and tax compliance.
Original PR description
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) *…
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1) * Add salary rules and categories for voluntary overtime remuneration. * Enforce yearly thresholds through payroll parameters: * 240h for voluntary overtime exempt from ONSS * 120h for voluntary overtime subject to ONSS * Exclude voluntary overtime from employment bonus calculations and paid amount computation where required. * Include voluntary overtime remuneration in payroll calculations and DMFA declarations. * Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields. * Fix DMFA service hour computation and add payroll/DMFA test coverage. TaskID: 6275791 Forward-Port-Of: odoo/enterprise#119355
This update resolves an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank file exports, leading to rejections. The fix ensures '&' is preserved in human-readable fields like partner names and addresses, aligning with banking standards and preventing errors.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#119640
Forward-Port-Of: odoo/enterprise#115409