Thursday, September 11, 2025
11 changes · 18.0
Resolved issues and error corrections
Changing an expense product's billing policy no longer recalculates and overwrites analytic account allocations on existing expenses. This preserves previously entered expense accounting details while still applying distribution rules correctly when users create or edit expenses through the normal flow.
Original PR description
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy…
When changing the expense policy of an expense product, the compute of analytic distribution of all expenses linked to the product is triggered. Steps: - Have an expense product X with expense policy 'at_sales' - Create several expenses with an expense product X and any analytic account - Create an analytic distribution model that link the expense account of X with a specific analytic account AA - Create a new expense for product X, the analytic account AA should be set from the distribution model - Go to the form view of product x and change the expense policy to 'cost' - Go back to the expense list view -> All expenses having the product X have the AA account Cause: `sale_order_id` has been added to the `depends` of `hr_expense._compute_analytic_distribution` by 2b3bf5e0fe31d4b4ef6b487da493657f695b14e1 but this wrong since we have the `sale_expense._onchange_sale_order_id` that add the `analytic_dostribution` field to the fields to be computed. The compute is triggered since we change `product_id.expense_policy`, which triggers the `_compute_can_be_reinvoiced` which triggers the `_compute_sale_order_id` Fix: With this commit, we emove the depends on the compute and we also adapt `test_compute_analytic_distribution_expense` in a way that it triggers the onchange as we do in the original flow. opw-4998899
Checkout payments using saved payment methods now wait until the order is validated before sending the payment request. This prevents customers from being charged when a last-minute issue, such as an expired coupon, blocks order completion.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a saved Stripe payment token; 2. create a discount coupon program & a coupon; 3. go to /shop & add a product to your cart; 4. go to checkout; 5. apply coupon; 6. before finalizing payment, set coupon program expiration to yesterday; 7. finalize payment. Issue ----- An error appears, because of the reward change, but a payment request has already been sent. Cause ----- For token transactions, `_send_payment_request` is called immediately upon creation, i.e. before the `WebsiteSale` controller is able to validate the transaction using `_validate_transaction_for_order`. Solution -------- If the payment flow happens via token, add a `delay_payment_request` context value. When creating a token transaction in `PaymentPortal`, only call `_send_payment_request` if this value is not set in the current context. opw-5013284 Forward-Port-Of: odoo/odoo#225008
Fixes planning date calculations so security lead times are applied only once when one warehouse supplies another. This prevents manufacturing and delivery dates from being pushed out too far, and also ensures manufacturing lead times are considered even when a product has no bill of materials.
Original PR description
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp,…
In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations. To reproduce the bug: 1- Create a db with, stock, mrp, sale installed. 2- Unarchive `MTO` route. 3- Set `Security Lead` Time in Setting. 4- Create two warehouses wh1, wh2. 5- In wh1, set `Manufacture to Resupply` to True. 6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1. 7- Create a product and track inventory. 8- Create a BOM for the product. 9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product. 10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote. 11- Open MO. Security lead time is considered twice in dates calculations which is mistake. To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected. This issue is reproduced because this condition is not sufficient to ensure it is called once: https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657 The above condition is written to ensure we are adding the delay only when move location is warehouse stock location. This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2. To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location. related: #112325 opw-4889642
Printing an invoice now uses the same custom PDF report selection as the send workflow. This ensures customers receive invoices with the correct partner or journal-specific layout instead of the generic template.
Original PR description
Before: Clicking 'Print' on an invoice did not respect the custom PDF report template set on the partner profile or journal. The selection was only applied in the 'Send' flow, while 'Print' always fell back to the generic invoice report. After: 'Print' now uses `_get_default_pdf_report_id()` to determine the correct PDF report. This ensures the same priority order is applied as in 'Send'. Explanation: The method `_get_default_pdf_report_id()` encapsulates the logic for choosing the report template (user → invoice default in 18.0, extended with journal in later versions). By reusing this method, we avoid duplicating logic and ensure consistency between 'Send' and 'Print'. task-5072522
Invoice imports now avoid linking products based on overly broad matches for very short item names. This reduces the risk of imported invoices being assigned to the wrong product when names are minimal or ambiguous, such as “-” or “A-1”.
Original PR description
hen resolving a product in _retrieve_product, the code searched by barcode, default_code, and then by name using both exact and ilike domains. For very short item names coming from imports (e.g., “-”, “A-1”, “0001”), the ilike fallback could match unrelated products whose names merely contain that short string. this led to incorrect product linkage on created documents (e.g., EDI-imported invoices). discussed with: Christophe (chkl) Steps to reproudce: Accounting -> Invoices upload an XML with a product name liek `-` or `a` See the product attched to the invoice line. opw-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refreshes Odoo’s spreadsheet engine with several fixes that improve everyday spreadsheet reliability. It prevents formula-related import and clipboard issues, reduces unnecessary Excel import warnings, and improves menu text display so users see cleaner, more predictable behavior.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7e6662c53 [REL] 18.0.44 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7e6662c53 [REL] 18.0.44 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9ca5b656c [FIX] Menu: Fix item text truncation [Task: 5072649](https://www.odoo.com/odoo/2328/tasks/5072649) https://github.com/odoo/o-spreadsheet/commit/6a7eee11b [FIX] xlsx: remove useless warnings on import [Task: 5075112](https://www.odoo.com/odoo/2328/tasks/5075112) https://github.com/odoo/o-spreadsheet/commit/e81d09c1e [FIX] xlsx: `=undefined` when importing array formula [Task: 4812508](https://www.odoo.com/odoo/2328/tasks/4812508) https://github.com/odoo/o-spreadsheet/commit/71808b2b1 [REV] xlsx: make import verbose [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/44df57169 [FIX] clipboard: insert cells bugged with array formulas [Task: 4938311](https://www.odoo.com/odoo/2328/tasks/4938311) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Fixes an issue where loyalty points could be counted twice after a sales order was confirmed, preventing customers from receiving all eligible rewards. This ensures promotions are applied consistently and avoids missed discounts during order processing.
Original PR description
## Versions: 16.0+ ## Issue: After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of…
## Versions:
16.0+
## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.
## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.
## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
- 2 points granted per purchase (minimum $0).
- Rewards:
- 5% discount on "Simple Pen" (costs 1 point).
- 10% discount on "Whiteboard Pen" (costs 1 point).
- Create a Quotation with "Simple Pen" and "Whiteboard Pen".
- Confirm the Quotation into a Sales Order.
- Apply promotions:
- The first reward applies correctly
- The second reward does not apply
opw-4753472
Forward-Port-Of: odoo/odoo#211342Vendor bills in the Chilean accounting localization now use the standard invoice report unless they specifically require the Chilean electronic purchase invoice layout. This prevents company and customer information from appearing swapped on printed vendor bills, reducing confusion and document errors.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type…
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type Purchase and enable Use Documents. 5. Go to Accounting > Vendors > Bills and create a bill. 6. Print Invoices / Invoices without payments. issue: ------ The customer and company data are swapped (interchanged), and It is wrong from vendor bills point of view. solution: --------- The l10n_cl reports layout should only be applied to: - out_invoice or out_refund - or when l10n_latam_document_type_id = (46) Electronic Purchase Invoice **Before:** <img width="762" height="425" alt="image" src="https://github.com/user-attachments/assets/e042485b-5d82-455f-9f34-03a0a9cdf5cc" /> **After:** <img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/c5d09e58-bcf0-48ab-a0ae-0e37c0473a67" /> opw-4937097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224454
UPS shipping rate checks now handle orders that include combo products correctly. This prevents valid orders from being blocked when calculating UPS delivery rates, improving checkout reliability for affected sales.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973
Financial reports now handle formulas that divide by zero without causing the report to fail. This keeps reports such as Profit & Loss accessible even when a custom formula produces an invalid division result.
Original PR description
Currently, an error is encountered when a financial report contains a line with a formula that results in a division by zero. **Steps to Reproduce:** - Install **accountant, account_reports module**…
Currently, an error is encountered when a financial report contains a line with a formula that results in a division by zero. **Steps to Reproduce:** - Install **accountant, account_reports module** (without Demo). - Navigate to Accounting>Reporting>Profit & Loss - Enable Developer mode, Click on the Edit(Gear Icon) smart button, then click Create to add a new line. - In the new expression line, set the following: >- Computation Engine: Aggregate Other Formulas >- Formula: NEP.balance / REV.balance - Save the new report line. - Reopen Profit & Loss, Report error will encounter **Error:** `ZeroDivisionError: float division by zero` **Root Cause:** At [1], in the `else` block, the case of a potential ZeroDivisionError is not handled properly, causing this issue. [1] https://github.com/odoo/enterprise/blob/770582d4c85629568b2e64f58651f59a9a9a5f86/account_reports/models/account_report.py#L3549-L3556 **Solution:** This commit prevents the error by ensuring that the case of a potential zero division is handled properly. Sentry-**6720835207**
Budget amounts in Profit and Loss reports now display with the correct positive or negative sign. This prevents budget figures and percentages from appearing reversed when budgets are selected or edited directly, improving report accuracy for financial review.
Original PR description
Step: - Create a financial budget with an items for 1000 - Go to P&L report, make sure the dates include the month of the budget item - Select previously created bugdet -> In the budget columns, amount is showing as negative value and % Same happens when setting a value directly in the editable cell. This is because we reformat the value according to the subformula '-sum' of the line's expression. opw-4982788