Thursday, August 14, 2025
18 changes · saas-18.3
Enhancements to existing features
The eInvoicing format dropdown now uses clearer, country-aware labels when customers choose an invoice format in the account settings. This helps users pick the right option more confidently, especially in localizations where previous technical names were unclear.
Original PR description
Renamed the selection labels for invoice_edi_format field to make them easier to understand based on the user's country context when choosing format inside customer's account tab. This improves the usability of the dropdown when selecting an eInvoicing format, especially for users in localizations where the technical name was unclear or confusing. 4889699 shzi Forward-Port-Of: odoo/odoo#220397
This update adds Mexican localization support for additional 16% withholding tax scenarios with specific split distributions, along with the required accounts and fiscal positions. It also improves precision for existing 10.67% tax calculations, helping businesses apply Mexican tax rules more accurately.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/enterprise/pull/83582 task-4571928 Forward-Port-Of: odoo/odoo#206406
Mexican localization now includes additional 16% withholding tax options with specific allocation splits, along with the related accounts and fiscal positions needed to apply them correctly. The update also improves rounding precision for 10.67% taxes, helping invoices and payments produce more accurate tax results.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/odoo/pull/206406 task-4571928 Forward-Port-Of: odoo/enterprise#83582
Opening the customer list in Point of Sale is now much faster when many customers are loaded and the current cart has many items. The system avoids repeating the same total calculation while the customer list is open, reducing wait times for cashiers during active sales.
Original PR description
Before this commit, opening the customer list in PoS could be slow when many customers were loaded (common in active PoS environments) and the current order had numerous orderlines. This performance hit was due to repeated recalculations of `get_total_with_tax`. This commit resolves the issue by storing the `get_total_with_tax` value of the current order when the customer list is opened. This value remains constant while the customer list is active, eliminating unnecessary recalculations. Performance Impact: With 500 customers loaded and 20 orderlines in the cart, opening the customer list improved from 5 seconds to 200 ms. opw-4921262 Forward-Port-Of: odoo/enterprise#91753 Forward-Port-Of: odoo/enterprise#89526
The invoicing flow now warns users when sending a Mexican electronic invoice for a customer missing required country or ZIP details while not using the public customer option. This helps prevent rejected or invalid invoices by prompting users to review customer information or intentionally override the default behavior.
Original PR description
Adding a warning and a check to account.move.send constraints for trying to send an invoice for a customer that doesn't have either country or ZIP specified, when 'CFDI to Public' is set to False (requires user action to override default behavior). task-4963869 Forward-Port-Of: odoo/enterprise#91655
Resolved issues and error corrections
This fix adjusts when Spanish POS orders can be sent to Veri*Factu, so users can send eligible orders after closing a session while avoiding unsupported registered-order submissions. It also prevents Veri*Factu cancellation of POS orders and directs users to use refunds instead, reducing compliance and accounting errors.
Original PR description
- The "Send Veri*Factu" button is currently also visible for registered orders (but we can not send documents for such orders anyway; we do not support subsanacion) - We do not allow generating Veri\*Factu documents for posted orders. That makes it impossible to (Veri\*Factu) send orders after the session is closed. - We should not allow to Veri*Factu cancel orders. They would still be included in the closing move. The user should create refund instead. task-None Forward-Port-Of: odoo/odoo#222927 Forward-Port-Of: odoo/odoo#222668
Fixes an issue where loyalty discounts for specific products could disappear after scanning an unrecognized barcode in Point of Sale. This ensures eligible discounts remain correctly applied or can be reapplied, improving checkout reliability for cashiers and customers.
Original PR description
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion…
With a discount applied on specific products, after scanning an unknown product, the discount disappeared and could not be reapplied. Steps to reproduce: ------------------- * Create a promotion program that grants a discount on a specific product category * Open PoS * Add to the order a product that triggers the discount * Scan an unknown barcode * (Try to reapply the discount) > Observation: The discount disappears and cannot be reapplied Why the fix: ------------ In v18.0, the method used `reward.update(...)` to apply the computed list of discountable products, ensuring proper handling by the reactive OWL model. In v18.2, a direct assignment was used instead, which did not properly set the internal state. When the filtered product list was empty, the resulting structure `[['link']]` became invalid, causing the discount to disappear and preventing it from being reapplied. opw-4923687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222017
This fixes an issue in Point of Sale loyalty rewards where selecting a product with multiple variants did not always automatically add the promised free product. Businesses can now rely on free product promotions applying correctly at checkout, reducing manual corrections and customer confusion.
Original PR description
Before this commit, when using a free product reward on multi products that have several variants, adding the desired product to the order would not always trigger the automatic addition of the free product as expected. opw-4841759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221998 Forward-Port-Of: odoo/odoo#215576
This fix improves tax calculations when invoices or orders use down payments, global discounts, manual tax amounts, and multiple currencies. It helps prevent small rounding errors and mismatched tax totals, making accounting results more reliable across sales, purchases, invoicing, and point of sale.
Original PR description
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts…
When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. That way, we could also use the manual_tax_amounts for amounts in company's currency. For down payment/global discount, let's handle both currencies instead of only the foreign one. Also, the percentage is applied for each line to keep the whole thing as most accurate and close to the input percentage. If we don't do that, we could end up with a base of 99.99 and a tax amount of 15.01 for a tax of 15%. Since the percentage is applied in a more "global" way, this commits also partially revert https://github.com/odoo/odoo/commit/3a269864534f234127c87ff1567f796904a27d5b This approach is more complex and doesn't give always better results when using round_per_line either. Let's keep it simple and come back to a global approach. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Purchase orders created from make-to-order sales will no longer be incorrectly treated as dropship orders. This prevents customer addresses from appearing on supplier requests for quotation when the goods are meant to be received normally, reducing confusion for purchasing teams and vendors.
Original PR description
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a…
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a product "Prod" - Select both buy and MTO routes - Add a vendor line - Create a SO for "Prod" - Confirm the SO - Go to the linked PO When printing the RFQ, the address field is that of the customer as if the PO was a dropshipped one Cause ----- 564b909 introduced an override of `_compute_dest_address_id` to update the delivery address of dropshipped purchases upon change of the SOL's `partner_shipping_id`. The problem is that the field having a value means it is a dropshipped purchase https://github.com/odoo/odoo/blob/35be5c9edf637fb813025f6817c16a9f50475fa8/addons/purchase/models/purchase_order.py#L89-L91 However, here, the value is set as long as the PO is linked to a SO, even if there was none to begin with. We can make sure that the field was already set via the vals when creating the PO, and that we just want to update it because the depends triggered the compute. ----- Ticket: opw-4925962
Employees can no longer create time off requests through a shortcut when the time off type requires an approved allocation. This keeps the shortcut behavior aligned with the standard request flow and prevents accidental overuse of leave balances.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves. - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221022 Forward-Port-Of: odoo/odoo#208214
Point of Sale now recognizes the exact product variant when a barcode is typed into the search bar, so staff no longer need to manually choose attribute values for matching products. This reduces checkout friction and speeds up sales for items whose barcodes must be entered manually.
Original PR description
Before this commit, when a user manually entered a product barcode in the search bar, and the product had multiple attributes and values, the configuration popup required the user to manually select the correct attribute values—even though the barcode uniquely identified the product variant. This slowed down the selling process and caused unnecessary friction. With this commit, when a product is found via its barcode (including manual entry), the configuration popup is automatically preset to the correct attribute values associated with that barcode. This improves the user experience and speeds up sales, especially for products whose barcodes cannot be scanned and must be entered manually. opw-4635497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220609 Forward-Port-Of: odoo/odoo#207086
This fix prevents search suggestions from interrupting Chinese, Japanese, and other composed text input on iPhones and iPads. Users can now select characters from their keyboard suggestions without the text disappearing, making Odoo usable for these languages on iOS.
Original PR description
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes…
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes it impossible for users to input text in these languages on iOS devices (iPhone/iPad). This regression was introduced between versions 18.0 and 18.2 when the search bar was modified to automatically open the suggestion dropdown during typing. Purpose: This commit fixes the IME input issue by preventing the suggestion dropdown from opening while the user is composing text with an IME. Opening the dropdown during IME composition disrupts the input process on iOS Safari, causing the composed text to disappear. The fix ensures that the dropdown only opens after IME composition is complete, allowing Chinese, Japanese, and other IME-based language users to properly input text on iOS devices. Steps to Reproduce on Runbot: 1. Access Odoo instance (version 18.2) on an iOS device (iPhone or iPad) 2. Switch keyboard to Chinese (Pinyin) or Japanese (Romaji) input method 3. Click on the search bar in any view (e.g., Customers, Sales Orders) 4. Type characters that require IME conversion: -For Chinese: type "ni" (for 你) -For Japanese: type "ka" (for か) 5. When the IME suggestion appears, press Enter or tap the suggested character 6. Bug: The text vanishes instead of being inserted into the search field Current behavior before PR: The character disappears immediately after selection Desired behavior after PR is merged: The selected character should be inserted into the search field Notes: -This issue only affects iOS devices (Safari/WebKit) due to how they handle DOM manipulation during IME composition events -The issue does not occur on Android devices or desktop browsers -The fix checks the `isComposing` property of the input event to avoid opening the dropdown during IME composition -No test added as IME input behavior is difficult to simulate in automated tests 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#222151
Surveys using randomized selection now shuffle questions even when all questions in a section are shown, removing an inconsistent ordering behavior. The change also allows section order to be randomized, giving survey creators more flexibility and reducing order bias in responses.
Original PR description
1/ When using Question Selection "Randomize per section", and a small number of questions is chosen, the order in which questions are shown is random. If, however, we choose to show all questions of the section (choose N of N), the order is not random, which is inconsistent, especially as setting `random_questions_count=0` can already be used to show them all in order. 2/ It was possible to randomize questions order per section but not sections order. It doesn't cost much and it's useful from saas-18.3. Task-4962940
The German EC Sales List CSV export now includes the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps German businesses submit their VAT-related reporting without manual file corrections.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314 Forward-Port-Of: odoo/enterprise#92110
The General Ledger report no longer crashes when users apply the Account Types filter and expand an account. This improves reliability for finance teams reviewing payable and receivable activity.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411
Forward-Port-Of: odoo/enterprise#87431Employees can no longer create time off requests through a shortcut when the time off type requires an approved allocation. This closes a loophole so leave balances and company policies are enforced consistently across the Time Off app.
Original PR description
Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open a time off type that requires allocation. - Click on the 'Time Off' smart button and try to create a request. Issues: - Employees could create time off requests via the smart button even without an approved allocation. - This bypassed the existing restriction enforced in the standard time off request creation flow. Fix: - Added a constraint on the time off model to validate allocations even when requests are created via the smart button. - Ensured validation covers both allocation presence and allowed negative leaves - Raised a ValidationError when no valid allocation is found. - Added a test case to ensure constraint behaves correctly. - Adjusted some of tests to comply with the new validation. Task - 4671236 Forward-Port-Of: odoo/enterprise#91257 Forward-Port-Of: odoo/enterprise#89975
Fixed an issue where Mexico POS orders paid with eWallet could show a tiny negative balance because of rounding in tax calculations. The system now treats these negligible differences as zero, allowing customers to continue to the payment screen as expected.
Original PR description
Before this commit, paying an order with eWallet could result in a small negative residual amount (due to tax calculation), instead of zero. This prevented users from proceeding to the payment screen. With this commit, the "lt" function is used to compare amounts while taking rounding precision into account, ensuring the residual is treated as zero when appropriate. opw-4867365 Forward-Port-Of: odoo/enterprise#88275