Friday, April 17, 2026
18 changes · saas-19.1
Enhancements to existing features
This update simplifies the creation of Spanish tax reports (303 and 347) for users. Specifically, the 'exonerated from 390' field is now automatically displayed on the print wizard for recent periods, eliminating manual setup. Additionally, the annual report 347 now groups data by move type and date for enhanced audit capabilities.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#113644 Forward-Port-Of: odoo/enterprise#108057
Resolved issues and error corrections
This update fixes an issue where individual POS e-invoices were incorrectly showing a zero Total Amount Payable. The change ensures that the payable amount accurately reflects the total e-document amount, as required by the MyInvois tax officer and helpdesk. This prevents discrepancies in the data sent to MyInvois.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#259339 Forward-Port-Of: odoo/odoo#258824
This update fixes an issue where the unit cost of products was incorrectly calculated when considering stock held in internal locations like subcontracting warehouses. The change ensures accurate valuation by properly accounting for all relevant inventory locations, leading to more reliable inventory reporting.
Original PR description
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can…
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273 2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65 ### Steps to reproduce: - In the settings enable Multi-Steps Routes - Create a storable with an avco perpetual valuation with a cost of 5$ - Click the `On hand` smart button > Update Quantity - Put 1 unit in WH/Stock and 2 units in Subcontracting - Go to Inventory > Reporting > Stock #### > The unit cost of your product is 15$ instead of 5$ - Click on locations on the line and remove the `internal` filter #### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$ ### Cause of the issue: The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines: https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363 ### Additional issue: The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it. opw-5959720 opw-5883980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257103
This update resolves an issue where the checkout process became unresponsive when using the l10n_br_avatax_sale module with CPF identification. The previous implementation unnecessarily called external tax APIs, leading to errors and a broken confirmation step. This fix removes the problematic API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259522 Forward-Port-Of: odoo/odoo#256692
A technical issue in the Luxembourg tax reporting module (l10n_lu) was causing negative values to appear for certain tax lines. This update corrects a formula change, ensuring that credited amounts are displayed accurately as positive values in the tax report. This ensures correct tax reporting for Luxembourg businesses.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/odoo#259388
This update corrects a problem where electronic invoices (FatturaPA) generated with units of measure containing special characters (like m² or m³) failed validation. The fix ensures these units are properly formatted before being included in the XML, guaranteeing compliance with Italian tax regulations and preventing invoice rejection.
Original PR description
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259076 Forward-Port-Of: odoo/odoo#257012
This update resolves an issue where mobile self-orders were incorrectly appearing in order lists for different Point of Sale (PoS) configurations within a company. The fix ensures that mobile self-orders are only displayed within their originating PoS configuration, improving order management and preventing confusion. This change enhances the accuracy of order data across our system.
Original PR description
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back,…
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back, open Restaurant, click on Orders tab -> The Bar's self-order shows up in the Restaurant's order list. What's happening ---------------- In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company. But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config). The fix ------- We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method. opw-6068187 Forward-Port-Of: odoo/odoo#258712
This update resolves an issue where the Invoice Journal field wasn't displayed correctly when a user changed the invoice's company and only one suitable journal was available. Previously, this prevented users from updating the journal, leading to an error. Now, the Journal field will always be displayed if it differs from the single suitable journal, allowing for accurate updates.
Original PR description
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases,…
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Description of the issue/feature this PR addresses: The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Current behavior before PR: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal. Desired behavior after PR is merged: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259573
This update ensures payments to Viva.com are consistently confirmed, even if the connection temporarily drops. The system now automatically retries payment confirmations silently, preventing payments from being incorrectly marked as failed and ensuring accurate accounting. A notification alerts the user to connectivity issues.
Original PR description
When a payment was sent to Viva.com and the connection dropped before receiving confirmation, the polling loop in waitForPaymentConfirmation would stop because _handleOdooConnectionFailure set the payment status to "retry" and rejected the promise. This left the payment debited on Viva's side but unconfirmed in the POS. Now the polling uses a direct silent ORM call instead of _call_viva_com to avoid triggering _handleOdooConnectionFailure. On connection failure, the poll silently retries on the next interval until a definitive success/failure response is received. A one-time warning notification informs the user that connectivity was lost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259564
This update enables quick checkout for event tickets, addressing a previous restriction that required full billing details. It recognizes that event locations are typically used for tax purposes, not customer addresses, and avoids a frustrating user experience. A system parameter allows businesses to enable or disable this feature based on their needs.
Original PR description
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#259275 Forward-Port-Of: odoo/odoo#258347
This update fixes an issue where stock quantities were incorrectly displayed for a company when a purchase order was processed through a different company in a multi-company setup. Now, stock quantities are correctly restricted based on the product's assigned company, preventing access errors and ensuring accurate reporting.
Original PR description
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company…
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company environment. If a purchase order with product from company 1 is being confirmed, received, and validated when company 2 is being selected as the primary active company while company 1 is also checked. It will create a stock.quant that is searchable for company 2. However, it will raise an error when company 2 is trying to access it. **After this commit:** Even if the stock.quant is created when company 2 is the primary active company, it will not be searchable for company 2 since the product's company is company 1. **Steps to Reproduce on Runbot:** - Create a storable product exclusive to Company A - Create & validate a receipt for that product in Company A. - Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible. opw-6082330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259733 Forward-Port-Of: odoo/odoo#257211
This update corrects a bug in the landed cost calculation process. Previously, the system incorrectly multiplied currency rates, leading to inflated landed cost figures. The fix ensures landed costs are calculated accurately based on the correct exchange rate, resolving a discrepancy in pricing.
Original PR description
Issue introduced by commit daf196e365f481ffcc8b56664fa361fa9c9bbda9
Steps to reproduce:
- Enable two currencies (e.g., USD and EUR)
- Set exchange rate: 2 EUR = 1 USD
- Set current company currency to USD
- Create a service product "Landed Cost":
- Purchase tab:
- Mark as "Is a Landed Cost"
- Cost: $10
- Create a bill:
- Vendor: any vendor
- Currency: EUR
- Add 1 unit of "Landed Cost" → correctly shows 20 EUR
- Click the "Create Landed Cost" button
Expected behavior:
Landed cost should be calculated as $10
Actual behavior:
Landed cost is incorrectly calculated as $40, because the AML (Account Move Line) price subtotal is multiplied by the currency exchange rate (2) instead of dividing.
opw-6121706
opw-6121407
Opw-6124771
Opw-6123193
Forward-Port-Of: odoo/odoo#259632This update resolves a potential issue where Odoo could create related fields that rely on non-searchable data, leading to errors in searching, reporting, and overall system stability. By adding validation, this change ensures related fields always use stored data, improving data consistency and reliability.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Sale). - Go to Settings → Technical → Database Structure → Fields. - Create a new field using Studio or manually. -…
**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.
**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.
- This leads to runtime issues such as:
- Cannot convert field to SQL because it is not stored
- Failures in search, domains, and reporting
- Inconsistent behavior depending on usage context
- Currently, no validation prevents users from configuring such invalid related fields.
**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.
- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.
This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.
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#259309This update resolves a crash that occurred when confirming rental orders with kit products using multiple pack locations. The change uses a safer method to handle multiple pick transfers, preventing the system from failing due to a single record requirement. This ensures smooth rental order processing for kit-based rentals.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#113879
Forward-Port-Of: odoo/enterprise#112543This update fixes an issue where refunds weren't correctly reflected when calculating outstanding balances in the Point of Sale (POS) system. Previously, only regular orders were considered, leading to inaccurate due amounts. Now, refund orders with negative totals are included, ensuring accurate due calculations and a more reliable user experience.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113663 Forward-Port-Of: odoo/enterprise#107883
A recent update introduced an unnecessary call to external tax services, causing the checkout process to become unresponsive for users with Brazilian tax configurations (CPF). This fix removes the problematic call, streamlining the process and resolving the issue. It ensures a smoother checkout experience for customers using the Avatax module.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114031 Forward-Port-Of: odoo/enterprise#112515
This update resolves an issue where delivery confirmations were failing due to missing tracking data from Easypost. The fix ensures that picking is correctly validated and the carrier tracking URL is empty, preventing shipping creation in Easypost while maintaining accurate order status in Odoo. Easypost support suggested a slight delay between order placement and tracking retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#111833
This update enables quick checkout by default for event and appointment bookings, streamlining the purchase process. Previously, a broad change risked disrupting other checkout flows. A system parameter allows businesses to retain full billing address details if needed, ensuring flexibility.
Original PR description
Forward-Port-Of: odoo/enterprise#113885 Forward-Port-Of: odoo/enterprise#113575