Tuesday, February 17, 2026
9 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a unique DateV ID is always required, regardless of a partner's active status, preventing data inconsistencies. This improves data accuracy for German reporting.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves a technical error that prevented users from removing a date filter within the booking management interface. The fix ensures the booking kanban view functions correctly, improving the user experience for scheduling appointments. This change focuses on a minor, internal technical issue.
Original PR description
Steps: - Install pos_appointment. - Open a POS session with bookings configured. - Open the Booking tab and click Remove date filter in the header. Issue: - A traceback occurs with `Invalid handler`. Cause: - The Remove date filter button’s onclick handler was not defined. Fix: - Define a valid onclick handler for the Remove date filter button. Task-5902656 Forward-Port-Of: odoo/enterprise#106684
This update resolves an issue where the journal filter wasn't correctly applied when viewing journal items within the general ledger report. Now, when you select a journal in the report, the 'Journal Items' view accurately displays both the related invoices and the corresponding journal entry. This ensures accurate reporting and analysis of financial data.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a problem where payment reference data from a financial system (Codabox) was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before creating reco models, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update ensures that all VAT reports (inf-a and inf-b) accurately include business partners without VAT numbers, addressing a previous reporting issue. The report warnings have also been standardized to better align with the main query, providing clearer guidance on potential VAT discrepancies.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update clarifies the visibility of specific fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the original design, hiding BE-specific fields while maintaining their functionality within the Belgian version. This ensures accurate reporting and compliance for our Belgian clients.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves a technical error that was causing a crash when creating new payroll records. The fix utilizes a standard Odoo method to handle virtual records, ensuring the payroll module functions correctly and reliably. This prevents disruptions to business processes.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303
This update resolves an issue where Odoo couldn't successfully process Fedex delivery requests due to a missing piece of information required by the Fedex API. Specifically, the system was failing with an 'INVALID' error. By adding a necessary field to the API request, we now ensure accurate delivery rate calculations and validation for Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
This update ensures that printed payslips display rates with a maximum of 4 decimal places. This improves the visual clarity and consistency of payslip reports, aligning with reporting standards. The change was implemented as a fix to a formatting issue.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739 Forward-Port-Of: odoo/enterprise#104915