Monday, May 4, 2026
14 changes · saas-19.1
Resolved issues and error corrections
This update simplifies the selection of tax rates on invoices for Saudi Arabia (l10n_sa). Previously, incorrect tax selections led to compliance issues. This change ensures the correct tax rates are applied based on supply characteristics, resolving a potential regulatory problem.
Original PR description
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT`…
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT` is visible with the other `0%` taxes such as `0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT` instead of the actual `0%` taxes according to the characteristics of the supply; leading to non-compliance with the ZATCA rules. Before this commit: - `15% PH PE HS` tax was `active`. - `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and distribution for refunds: `base tax grid = 3(B)`. - `0% Not Subject to VAT` tax was `active` and had distribution for invoice: `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)` - `0% IT G and 0% QT` taxes were `active`. After this commit: - `15% PH PE HS` tax is `inactive`. - `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)` and distribution for refunds: `base tax grid = 2(B)` - `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid has been removed. - `0% IT G and 0% QT` taxes have been set to `inactive`. task-5959979 Forward-Port-Of: odoo/odoo#253598
This update fixes an issue where applying a global discount and a gift card resulted in an incorrect order total. The system was incorrectly adding back a portion of the gift card amount as a discount. The fix ensures gift card deductions are handled properly, preventing this calculation error.
Original PR description
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base.…
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back). Steps to reproduce: ------------------- * Open PoS with global discount and a gift card / eWallet program. * Add a product (e.g. $100), apply a global discount (e.g. 10%). * Apply a gift card for part of the balance (e.g. $50). > Observation: Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line. Why the fix: ------------ `pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct. opw-6104090 Forward-Port-Of: odoo/odoo#259577
This update fixes a critical issue preventing the correct import of PINT invoices for Australia, Japan, Malaysia, Singapore, and New Zealand. By adding logic to identify these specific UBL document types, the system now accurately processes and imports these invoices, ensuring data integrity and compliance.
Original PR description
## PINT modules (`l10n_*_ubl_pint`)
The UBL module wasn't able to import PINT documents because there was no logic to detect the type of UBL document for PINT invoices (`urn:peppol:pint:billing-1@{anz, jp, my, sg}-1`). This PR adds the methods to detect PINT UBL documents and provide appropriate EDI decoder model names. Along with the fix, test cases are added to verify proper import of the said UBL's.
## Base EDI module (`account_edi_ubl_cii`)
Additionally, `_correct_invoice_tax_amount` in the base UBL import is fixed to only process TaxSubtotal nodes in the document currency. Previously it iterated over all `TaxTotal/TaxSubtotal` nodes regardless of currency, which caused the JP PINT import to pick up the company-currency tax amount instead of the document-currency one. JP PINT is the only format that includes TaxSubtotal in both TaxTotal nodes.
Forward-Port-Of: odoo/odoo#258017This update resolves an issue preventing users from canceling invoices through the ECPay integration. The fix adds necessary permissions to access a key configuration field, ensuring the cancellation wizard functions correctly for all user roles. This prevents a disruption in invoice processing.
Original PR description
Before this commit, the invoice cancellation wizard failed when clicking "Request Cancel" because l10n_tw_edi_ecpay_staging_mode lacked sudo access, while similar fields had it. The cancel wizard (l10n_tw_edi.invoice.cancel) needs to read this field to determine the API endpoint, but non-superuser accounts couldn't access it, causing a permission error. This commit adds sudo() when accessing staging_mode, consistent with other ECPay API configuration fields. Steps to reproduce: - Install l10n_tw modules with ECPay staging credentials (MerchantID: 2000132) - Use valid Tax ID (10430481) to create and send invoice - As Accounting/Administrator user, cancel the invoice - Access error occurs on button_request_cancel opw-6101478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where loyalty point transactions in a single POS order were only recorded as a net difference. Now, the system accurately tracks both the points earned and the points spent, providing a complete and precise history of loyalty card activity. This ensures accurate reporting and better customer understanding of their loyalty points.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261399 Forward-Port-Of: odoo/odoo#256022
This update optimizes how prices are calculated in Point of Sale, resolving a previous issue that caused unnecessary and costly calculations. By using a smarter system, we've significantly reduced the strain on our system and improved the speed of order processing. The changes also ensure price data is handled efficiently in production environments.
Original PR description
Calling triggerRecomputeAllPrices() synchronously on every orderline mutation (create, merge, delete) caused the full tax/price computation to run 3 times per addLineToOrder call when a merge occurred, and triggered an expensive JSON.parse/JSON.stringify of the price data on each of those calls via logPosMessage. Replace the eager synchronous recompute with a microtask coalescer: the first call within a synchronous operation schedules a single Promise.resolve().then() microtask; subsequent calls within the same tick are no-ops. Because the microtask is queued before the outer await continuation (updatePrograms), _updatePrograms still reads fresh prices when it accesses line.prices. Also guard the args serialization in logPosMessage behind odoo.debug so the JSON deep-clone of the price data object is skipped entirely in production. opw-6091501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260436
This update resolves an issue where the system incorrectly skipped remuneration declarations in certain scenarios, particularly when employees had no worked days but still received a bonus. The fix ensures that all remuneration amounts are accurately declared, preventing potential discrepancies in payroll reporting for Belgian employees. This improves the reliability of the payroll process.
Original PR description
Forward-Port-Of: odoo/enterprise#106689
This update adds logging of Amazon's request identifiers to the SP-API responses. Previously, this information was missing, making it harder for support teams to troubleshoot issues with Amazon. Logging this ID will significantly improve the speed and efficiency of support investigations.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#114483
This update automatically allows users to reconcile bank statements from a parent company with related payments and invoices from its branches. Previously, reconciliation was limited to matching statements directly with company records. This enhancement streamlines the bank reconciliation process, making it easier to manage financial data across multiple locations.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#114850
This update speeds up the process of writing to reconciliation models, a key task for managing financial records. By optimizing how the system handles large numbers of bank statement lines, the change significantly reduces processing time and memory usage, leading to a smoother and faster user experience.
Original PR description
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled…
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time. This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models. ### speedup In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model. | Nbr linked unreconciled lines| Before PR | After PR | |:----------------------------:|:---------:|:--------:| | 702 | 40s | 3s | | 2000 | 40s | 4.47s | | 10000 | 40s | 11.28s | Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch. ### memory For the 702 unreconciled lines case, the memory consumption goes - 2.2 Gb -> 200Mb. Forward-Port-Of: odoo/enterprise#115583
This update corrects an issue where the EC Sales Report exported to KVR (a key reporting tool) displayed values with decimal places, which is not permitted for Swedish reporting requirements. The fix ensures all values are rounded to integers, aligning with local regulations and improving data accuracy for financial reporting. This resolves a previous reporting discrepancy.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115459 Forward-Port-Of: odoo/enterprise#114292
This update corrects a bug where invoices rejected by the Italian tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing invoices to be properly resubmitted after the issue is resolved. This improves the efficiency of invoice processing for Italian businesses.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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#262075 Forward-Port-Of: odoo/odoo#260591
A previous issue prevented custom loyalty domains from functioning properly when using the Point of Sale (POS). This fix expands a system function to correctly handle many2many fields in loyalty domains, resolving a bug that blocked reward usage. This ensures loyalty programs are fully operational within the POS environment.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update fixes an issue where invoices created in a branch environment with tax-included products didn't correctly calculate the unit price after applying a fiscal position. Previously, the price remained unchanged. This change ensures accurate tax calculations on branch invoices, improving financial reporting and compliance.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#262190 Forward-Port-Of: odoo/odoo#256897