Saturday, February 21, 2026
12 changes · 18.0
Resolved issues and error corrections
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend system. The issue stemmed from a misinterpretation of data keys, leading to incorrect gift card tracking. This ensures all gift cards are properly recorded, improving order accuracy and reporting.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320
This update fixes a bug that prevented users from adding columns within list items in the HTML editor. The issue stemmed from incorrectly restoring selections after list items were removed. The fix ensures stable column insertion functionality within lists, improving the editor's usability.
Original PR description
Problem: When trying to add a column under a list item, a traceback occurs. Cause: The list item is removed during the operation, but the selection that is restored still references the removed list item. As a result, the selection is restored on a disconnected element, causing a traceback. Solution: Handle column insertion inside lists separately. In this case, according to the specifications, we split the list and insert the columns between the resulting lists (or after the list if the cursor is in the last list item). This avoids restoring the selection on a removed node. Steps to reproduce: - Add any list. - Run `/column` while the cursor is inside a list item. - Observe the traceback. task-5916246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that opening notes are consistently saved to the system, regardless of whether the cash payment method is used. Previously, this data was lost when the cash method wasn't configured, leading to potential data inconsistencies. This change improves the reliability of POS note information.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822
This update improves the handling of invoice generation when using BIS3 files, particularly for Business-to-Consumer (B2C) transactions. Previously, checks for R010/R020 were always performed, even when the EndpointId wasn't required. This change optimizes the process by only performing these checks when PEPPOL is enabled, ensuring efficiency for B2C scenarios.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rounding issue that occasionally occurred in Point of Sale invoices. The change prevents unnecessary rounding, ensuring more accurate and reliable invoice totals for our customers. This improves the overall transaction process and reduces potential discrepancies.
Original PR description
Backport of https://github.com/odoo/odoo/pull/247223. opw-5890586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where payment beneficiary accounts were incorrectly assigned after merging inbound and outbound payments. Specifically, when a refund is merged, the system now correctly identifies the payment as an outbound transaction, ensuring the correct bank account is used. This improves payment accuracy and reduces potential accounting errors.
Original PR description
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same…
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account. Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient. The `partner_bank_id` can be assigned through different processes: - If the wizard has only one batch: The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`. - If there are multiple batches: Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id']. The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly. I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are. -Previous PR : [242863](https://github.com/odoo/odoo/pull/242863) However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here. Ticket: opw-5401372 Forward-Port-Of: odoo/odoo#246558
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. It replaces outdated taxonomy data with the final 20251210 NT20 taxonomy, ensuring compliance and accurate reporting.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries with excessively large negative hour values (over six digits) are now properly flagged as errors. Previously, these entries could be added without warning, leading to potential data inaccuracies. This fix improves data integrity and prevents incorrect time tracking.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
This update fixes an issue where invoices weren't correctly using product category accounts. Now, Odoo automatically checks the entire category hierarchy (parent to child) to find an appropriate account, ensuring invoices accurately reflect the intended income or expense. This improves financial reporting accuracy.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an…
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an **expense account** on the child category. * Leave the parent category without any accounts. * Create a product assigned to the child category. * Create a customer invoice using this product. **Observed behavior:** * The invoice line uses the **default income account** from settings instead of the grandparent category’s income account. * The category hierarchy is not checked to retrieve parent accounts. **Expected behavior:** * If no account is defined on a category, Odoo should traverse the **parent categories** to find one. * Only if no account exists in the hierarchy should it fall back to journal or default accounts. **Cause:** * Account lookup only checked the **immediate category**. * Parent categories were not considered. **Fix:** * Traverse the product category hierarchy when searching for accounts. * Use the first account found in the parent chain. opw-5869592 Forward-Port-Of: odoo/odoo#248389
This update resolves an issue where expense reports generated with encrypted PDFs would fail to process due to a missing library dependency. The change ensures that the system gracefully handles PDFs without requiring the PyCryptodome library, improving the reliability of expense report generation. This prevents errors and ensures users can continue to accurately track their expenses.
Original PR description
**Issue:** This is a complement to the previous commit: https://github.com/odoo/odoo/commit/2eb12ba5e8055c5a0aa3ab86d0e173b3ca3ff2f0 When using version 2.12.1 of PyPDF2 as required if python version > 3.10, if PyCryptodome library is not installed, a DependencyError will be raised when trying to decrypt the file: "PyCryptodome is required for AES algorithm". opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249737
This update fixes an issue preventing the Hungarian VAT integration from correctly communicating with the NAV system. A change in how the software ID was generated resulted in a shortened string, failing validation. The fix adds padding to ensure the ID is exactly 18 characters, resolving the error and enabling proper functionality.
Original PR description
**Steps to reproduce:** * Create a **Hungarian** database with **Accounting** or **Invoicing**. * Set a valid **VAT number** on the company. * Configure **NAV credentials** in **production mode**.…
**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.
**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.
**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.
**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.
opw-5902414
Forward-Port-Of: odoo/odoo#247737This update addresses an issue where vendor bills received via Peppol as XML lacked a PDF attachment, hindering users' ability to preview and verify the data Odoo parsed. The commit now automatically generates and attaches a PDF when one isn't present, ensuring a complete and verifiable vendor bill experience.
Original PR description
Some vendor bills received via Peppol as XML do not include an attached PDF, preventing users from previewing the document and verifying the values parsed by Odoo. This commit generates and attaches a PDF when the XML does not provide one. task-5500236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr