Thursday, April 30, 2026
14 changes · saas-19.1
Enhancements to existing features
This update adapts the XLSX export reports to align with new Indonesian tax regulations (Act 2025). Previously, reports relied on specific tax sections, but now they utilize report line names and tax tags for accurate reporting, ensuring compliance with the latest requirements.
Original PR description
In this commit, the XLSX export and report warning are adapted to support the newly introduced TDS/TCS reports as per Act 2025. Previously, the XLSX reports depended on TDS/TCS sections. However, with Act 2025, certain taxes no longer have associated sections. This dependency has been removed, and report generation now relies on report line names and tax tags instead. task-6124431 Forward-Port-Of: odoo/enterprise#113916
Resolved issues and error corrections
This update fixes a performance issue where updating a product's lot or serial number in a picking could trigger slow requests due to fetching all stock quantities. The change ensures that the system respects the specified limit when retrieving quantities, resulting in significantly faster update times. This improves the overall responsiveness of the barcode picking process.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update corrects a reporting issue where the '18% IGST (IMP-Service)' tax wasn't accurately reflected in the GSTR-3B report. The fix adjusts how tax distributions are handled, ensuring the correct service tax amount is imported. This ensures accurate tax reporting for Indian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves an issue where multi-company invoices were experiencing errors due to incorrect tax calculations. The change ensures that tax data is handled securely, preventing access errors when products from different companies are involved. This improves invoice processing reliability for businesses using Odoo's multi-company feature.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update resolves an issue where backorders created from returns weren't properly associated with the original return. The fix ensures the `return_id` is correctly set during the backorder creation process, allowing for accurate tracking and reporting of returned items. This improves the reliability of our inventory management system.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue preventing the MPESA payment method from correctly processing transactions initiated by Safaricom. Specifically, it disables CSRF checks on callback endpoints and ensures URLs use HTTPS, addressing a common error related to invalid URLs. Additionally, the code now incorporates the till number for transactions, streamlining the process.
Original PR description
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will…
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will disable CSRF checks on the callback endpoints which are expected to be called from an external service 2. Sometimes the `web.base.url` parameter is automatically set to http. But safaricom expects https for all the urls. So we need to ensure that the urls we send on `lipa_na_mpesa_register_urls` use https, otherwise the registration fails with an `invalid url` error. Additionally, I added the error message in case of error 4. In addition to the business short code we also need a till number for transactions. Since this is stable, I've added the till number as an extension of the business shortcode field and then parse it before usage. On master there is a new PR which will properly separate the fields Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254993
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts for vendor bills with multiple tax repartition lines. The fix ensures accurate tax reporting by correctly summing the tax amounts when multiple lines are associated with a single tax, improving the reliability of financial data exports.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue where incorrect Nemhandel identifiers were generated when Danish company VAT numbers with the 'DK' prefix were entered. The change removes the 'DK' prefix from CVR numbers, ensuring accurate identifier generation and a better experience for Danish businesses using Odoo.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - The prefix is removed if the CVR contains the 'DK' country code, to ensure the correctness of the Nemhandel identifier. task-5449059 Forward-Port-Of: odoo/odoo#261856 Forward-Port-Of: odoo/odoo#261719
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This change ensures all printers, including those connected via IoT, are properly loaded and functional within the PoS environment.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable.
This update resolves an issue causing FEC imports to crash for French association companies in Guadeloupe and Martinique. The fix prevents the import process from incorrectly attempting to link asset models, which were unexpectedly included in the account templates. This ensures smoother and more reliable FEC imports for our French users.
Original PR description
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account…
Description of the issue: Importing an FEC on saas-19.1 can crash for French association companies in Guadeloupe or Martinique. During the import, account data is completed from the fr_comp account templates. Since 19.1, those templates may include asset_model_ids, which makes the import try to resolve asset XML IDs that do not exist for that company setup. Steps to reproduce: 1. Create a new company with Guadeloupe or Martinique for country. 2. Set the French associations chart of accounts on it. 3. Go to Accounting -> Configuration -> Chart of Accounts. 4. Import the FEC file linked on the ticket. 5. Import fails with traceback. Desired behavior after fix: FEC import should keep the existing template completion behavior, but it should not copy asset_model_ids onto imported accounts. Importing an FEC for French association companies in Guadeloupe or Martinique should therefore no longer crash because of unrelated asset model references. Ticket [link](https://www.odoo.com/odoo/project.task/6053048) opw-6053048
This update corrects a problem that occurred when switching accounting chart templates, specifically when changing from a company to an association localization. The change ensures that old accounting records are properly removed during template updates, preventing errors related to foreign key constraints. This improves stability and prevents disruptions during localization adjustments.
Original PR description
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account"…
**Issue:** Switching chart template/localization (Belgium Companies -> Belgium Associations) produces an error: ``` The operation cannot be completed: update or delete on table "account_account" violates RESTRICT setting of foreign key constraint "account_cash_rounding_profit_account_id_fkey" on table "account_cash_rounding" DETAIL: Key (id)=(1919) is referenced from table "account_cash_rounding" ``` **Steps to reproduce:** 1) install l10n_be module 2) make a new belgium company 3) go to accounting > configurations 4) change the fiscal localization package to "Belgium- Associations and Foundations" **Cause:** `account.cash.rounding` was not included in the chart template cleanup models. As a result, old `account.account` records were unlinked while still referenced by cash rounding records with `ondelete='restrict'` **Solution:** Include `account.cash.rounding` in `TEMPLATE_MODELS` so cleanup removes cash rounding records before deleting old accounts. And Add an assertion in `test_change_coa` to ensure old cash rounding records are deleted during COA switch. opw-6165374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies post-fix adjustments to the untaxed amount, aligning with standard tax rounding methods. This ensures accurate invoice generation and compliance with UBL standards.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260992
This update fixes an issue where invoices were incorrectly including non-validated timesheets in sales orders. The change ensures that invoices only reflect the quantity of timesheets that have been fully validated, aligning with the 'only validated TS' invoicing policy. This prevents over-invoicing and maintains accurate financial records.
Original PR description
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product.…
**Steps to reproduce** - Settings: Timesheets > Invoicing policy = only validated TS. - Have a service product with an invoicing policy based on timesheets. - Create a sales order using this product. - From the SO, click on the "Recorded" smart button and create 2 timesheets. Validate only one of them. - Invoice the SO, using a timesheets period that includes both TS. - Notice that the quantity of the invoice line includes the non-validated timesheet. **Cause** The domain excluding non-validated timesheets provided by `_timesheet_compute_delivered_quantity_domain` is not considered since c3b6053b09222d4bd2237e7de589a63fbef118f1 **Change** Since the purpose of the previous fix was to exclude timesheets linked to an invoice with a date before the "Invoicing Switch Threshold", this can be achieved by tweaking the `timesheet_domain` slightly, similar to the `_timesheet_domain_get_invoiced_lines` domain. opw-6116670 Forward-Port-Of: odoo/odoo#261621 Forward-Port-Of: odoo/odoo#259224