Monday, September 8, 2025
10 changes · saas-18.4
Enhancements to existing features
This update adds support for official Turkish company information codes required by Nilvera. It helps prevent non-compliant invoice submissions by blocking invoices when required codes are missing and ensuring the codes appear in both PDF and XML outputs.
Original PR description
Description of the issue/feature this PR addresses: Nilvera requires official codes on company contacts for submission to be compliant. Current behavior before PR: Invoices may be sent to Nilvera…
Description of the issue/feature this PR addresses: Nilvera requires official codes on company contacts for submission to be compliant. Current behavior before PR: Invoices may be sent to Nilvera without the required codes, resulting in non-compliance. Currently, only the VKN and TCKN codes are sent, while other required codes are not supported. Desired behavior after PR is merged: Official codes are added as non-deletable tags (non-mandatory ones archived). An error is raised when required tags are missing or empty. Invoices cannot be sent to Nilvera without valid codes. Codes are always reflected in both PDF and XML. [IMP] l10n_tr_nilvera: support for official information codes Added codes as tags from the official list and archived non-mandatory ones. These tags cannot be deleted, and an error is shown on attempt. Invoices are blocked from being sent to Nilvera if either MERSISNO or TICARETSICILNO is missing, or if assigned but without a value. Codes are reflected in both PDF and XML. task-4992049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224945 Forward-Port-Of: odoo/odoo#223182
UAE payroll calculations now better support contracts based on employee attendance or planning schedules. This helps businesses produce more accurate payslips for different working arrangements and includes test coverage to reduce payroll errors.
Original PR description
Updates for the salary rules to accomodate Attendance and Planning-based contracts and test cases for said scenarios opw-[4873312](https://www.odoo.com/odoo/all-tasks/4873312) Forward-Port-Of: odoo/enterprise#93802 Forward-Port-Of: odoo/enterprise#90407
Resolved issues and error corrections
This fixes an issue in the website builder where product variant options could appear at the wrong time when configuring an Add to Cart button. It makes the editor behavior more reliable for users building online shop pages.
Original PR description
### [FIX] html_builder: avoid recomputing item value equal to undefined With initial [website builder refactor], state of `useGetItemValue` is recomputed too often if it is equal to undefined. This commit fixes to comparison to check if the key is in the map. [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 ### [FIX] html_builder: fix add to cart button options With 4e25350bde07ca4267887aa612b538bac0b3c6eb, `useDomState` became async, thus reading it in `getValue` in a dependency definition became incorrect. With this commit, `BuilderMany2One` uses only the synchronous part for the dependency value computation Steps to reproduce: - Open website builder (with website_sale) - Drop the inner snippet "Add to Cart Button" - Choose a "Product" that has variants (for example "Conference Chair") - Bug: the option for the variant is not shown - Remove the choice - Bug: the option for variant now appears task-4367641
Creating an invoice from a Point of Sale order could fail when the product had no taxes and the customer used Singapore e-invoicing. The fix treats missing tax as zero, allowing the invoice to be created normally and avoiding disruption at checkout reconciliation.
Original PR description
Currently, an error occurs when a user creates the invoice for a POS order. Steps to Reproduce: - Install the `point_of_sale` module. - Start a `Point of Sale session`. - Go to `Products` > create a…
Currently, an error occurs when a user creates the invoice for a POS order. Steps to Reproduce: - Install the `point_of_sale` module. - Start a `Point of Sale session`. - Go to `Products` > create a product without `Sales Taxes and Purchase Taxes`, and in the `Point of Sale` tab, select your `POS session category`. - Go to `Customers` > `create a customer` and In the `Invoicing tab` of the customer, select `Singapore BIS Billing 3.0 SG` in the `eInvoice format` field. - Go to the Point of Sale session and validate an order with the newly created product. - Go back from the session, open the newly created order in Orders and select the newly created customer in the Customer field, and click the `Invoice button`. `AttributeError: 'NoneType' object has no attribute 'amount'` This error occurs after [this commit](https://github.com/odoo/odoo/commit/840bd1832edcc7815b8df70ec52dca10ef978fae), When a user creates an invoice for a POS order, the system calculates the tax_category_code [1], and if the product does not have any type of tax, then an error occurs here [2]. This commit ensures that if the tax is not present, it treats the tax amount as 0 as in [3] and returns the tax_category_code safely. [1]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L432 [2]- https://github.com/odoo/odoo/blob/2627168eea8562477f600c97c42d443a072ddccc/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_sg.py#L23 [3]- https://github.com/odoo/odoo/blob/9ea122e605366d076a2d6798dce63f1011a579da/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L434-L435 sentry-6814145551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where Spanish Veri*Factu invoice users could not select a required regime key because the dropdown appeared empty. The hidden supporting field is now included in the invoice view so the available choices are calculated correctly, helping users complete compliant invoices without manual workarounds.
Original PR description
### Issue: The dropdown for the regime key doesn't show any value, even when it's supposed to. ### Steps to reproduce: - Install "l10n_es_edi_verifactu" and switch to a Spanish company - Create an invoice for a Spanish partner with the tax "21% G (Goods)" for example - In the page "Veri*factu" the field "Veri*Factu Regime Key" has a dropdown but no values to choose from ### Cause: This field uses the widget `dynamic_selection` which applies a filter on the possible values of the selection. This filter is simply the field `l10n_es_edi_verifactu_available_clave_regimens` which is computed from the list of possible values and the tax_ids on the invoice. As this field is computed and non stored but do not appear in the view, it is never recomputed, so the dropdown shows no values. ### Solution: Add the field in the view, and make it invisible. opw-5039271 Forward-Port-Of: odoo/odoo#225478
Invoices for sales between companies now correctly show the related lot and serial numbers when that setting is enabled. This ensures inter-company customers receive the same traceability information as other customers, improving invoice accuracy and compliance with tracking processes.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223455 Forward-Port-Of: odoo/odoo#222492
Fixes an error that could prevent users from enabling the Calendar view in Studio for Employees. The system now avoids unsuitable date fields when automatically creating calendar views, improving reliability without changing user workflows.
Original PR description
**Steps to reproduce:** - Install `hr` and `web_studio` - Go to Employees → click Studio icon. - Click on Views → try to activate Calendar view. **Observation:** - You will get a traceback…
**Steps to reproduce:** - Install `hr` and `web_studio` - Go to Employees → click Studio icon. - Click on Views → try to activate Calendar view. **Observation:** - You will get a traceback `ValueError: Cannot convert hr.version.date_end to SQL because it is not stored ` **Issue:** - Since saas-18.4, the `hr_version` model introduced `date_start` and `date_end` fields, which are non-stored computed fields. https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/addons/hr/models/hr_version.py#L139-L140 - These field names overlap with the default date field names (`date_start` and `date_end`) used when generating Calendar views. So, the Calendar view tried to use a non-stored field, and it caused the error. https://github.com/odoo/odoo/blob/21f18b1a6fdbf1a01c3dda83acfa66addd01a759/odoo/addons/base/models/ir_ui_view.py#L2591-L2630 **Solution:** - Add an extra check in `set_first_of` to ensure that only stored fields are considered when selecting the default date field for Calendar views. opw-4967654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when the same contact is linked to employees in different companies, a vehicle is assigned to the employee from the vehicle's company. It prevents incorrect driver records in fleet vehicles and assignment logs for multi-company setups.
Original PR description
There is a bug when multiple employees from different companies are linked to the same contact. Steps to reproduce: - Create two employees, in two different companies that relate to the same contact (partner) - In one of the two companies, create a vehicle and assign it to the partner created - The field driver_employee_id in the vehicle and assignation log will be assigned to one of the two employees, without taking care of the company of the car To fix this, the domain should also contain the company of the car, and must match the company of the employee. task-4978443 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221154
Disabled Urban Piper delivery providers now remain disabled when a point of sale session is resumed. This prevents unwanted provider reactivation and avoids unnecessary update requests, helping staff continue selling with the correct delivery setup.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969 Forward-Port-Of: odoo/enterprise#93119 Forward-Port-Of: odoo/enterprise#90987
Fixed an issue in Data Cleaning where the discard button in deduplication could reload the page without removing the selected record. This restores the expected workflow for users managing duplicate records after a recent system change.
Original PR description
…efactor. Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature. Steps to replicate: - Go to: Data Cleaning > Configuration >…
…efactor. Currently, the discard button is not working correctly when trying to discard a record in the deduplication feature. Steps to replicate: - Go to: Data Cleaning > Configuration > Deduplication. - Open any Deduplication Rules > Deduplicate > select any record or directly click on the discard button. (Make sure at least one record is available in list view.) - Click `discard` on top left. Issue: `It will load the page but not discard the record.` This is not work because of a recent [refactor](https://github.com/odoo/odoo/pull/205486) where the data of a `many2one` will be an object rather than an array. (task-[3547961](https://www.odoo.com/odoo/project/49/tasks/3547961)) The discard button in the deduplication feature was not working correctly after a recent refactor in Odoo SaaS version 18.4. Previously (in SaaS 18.3), the record.data.group_id many2one field was represented as an array. The discard logic was written to access the group ID as record.data.group_id. After the refactor, the record.data.group_id field is now represented as an object. Thus, record.data.group_id became undefined, which made parseInt() return NaN. Because of this, the application failed to identify the correct group and records to discard, causing the discard action to silently fail and only reload the page without discarding any records. `The issue is also occurring in the runbot.` Summary: This change ensures that the discard button correctly identifies the group and record IDs to discard records. The lines that returns object is [this](https://github.com/odoo/odoo/blob/564348a5172ea98b38c903686c21d007d0e57b48/addons/web/static/src/model/relational_model/utils.js#L517-L523). cause of code : https://github.com/odoo/enterprise/blob/7d020d73762a17386cae4b68c15a5d59a51fb480/data_cleaning/static/src/views/data_merge_list_view.js#L67 reference pr:- https://github.com/odoo/enterprise/pull/90157 **saas~18.4** <img width="1914" height="564" alt="image" src="https://github.com/user-attachments/assets/d8079d6b-abad-4367-b9d5-9055ee4f8cfa" /> **saas~18.3** <img width="1907" height="545" alt="image" src="https://github.com/user-attachments/assets/8add0c64-a6ce-40bd-9df9-ca5de5ab9ac8" /> OPW:- [5043092](https://www.odoo.com/odoo/project/70/tasks/5043092) UPG:- [3116896](https://upgrade.odoo.com/odoo/upgrade.request/3116896)