Monday, September 1, 2025
13 changes · saas-18.3
Enhancements to existing features
This update adds support for using and testing Odoo's paper-muncher report rendering tool, including timeout handling for web-based report processing. It helps improve reliability when generating or validating printable documents.
Resolved issues and error corrections
This fixes an issue where selecting an afternoon time in a 12-hour clock format could save it as a morning time instead. Users working with AM/PM date and time fields can now rely on the selected time being recorded accurately.
Original PR description
Be in (or configure) a language with the 12 hour time format (i.e. such that times are displayed with am/pm). In a datetime field, open the datepicker and set the time in the afternoon (e.g. 6pm). Before this commit, the value that was actually set in the input was in the morning (6am in this case). The cause of the issue came from the date parsing. As we do not display the seconds in the input, the value was "06:00 pm", which couldn't be parsed properly. This commit fixes the issue by adding a step in parseDateTime, to try to parse with the short time format. opw~4996133 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
The POS now correctly calculates additional down payments on the same sales order by subtracting amounts already paid. This prevents customers from being charged the full down payment percentage again and keeps payment requests accurate.
Original PR description
- Create a SO of 450 with 15% tax for a total of 517.50 - Create a first down payment from the POS of 10% => you pay 51.75 - Create a second down payment from the POS of 10% => we ask you to pay 51.75 again => We should ask him to pay 10% of 517.50 - 51.75 instead --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The update adds a clear log entry when a user retries India EDI, e-waybill, or e-waybill IRN processing. This helps businesses identify who retried a government tax request, which is important because too many requests can temporarily block access for 24 hours.
Original PR description
Manual fw-port of https://github.com/odoo/odoo/pull/223957, https://github.com/odoo/odoo/pull/223886, https://github.com/odoo/odoo/pull/207184 *=edi,ewaybill,ewaybill_irn Following the implementation of [Black list request by GST](odoo/iap-apps#1039) the users are blocked for 24 hours on generating too many request. When processing through EDI there is no log when clicked on the retry button, Which is more essentially needed now to know by which user the EDI was retried and we logged the same on the move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224169
Hungarian electronic invoicing now classifies credit notes more accurately when invoices have already received payments. This helps ensure reports sent to NAV use the correct cancellation or modification status, reducing compliance errors.
Original PR description
Before this PR: - Previously, a credit note was marked as STORNO if the base invoice's residual amount was zero, regardless of whether any payments had been made. This led to incorrect STORNO reports being sent to NAV in cases where the invoice had been partially or fully paid before reversal. After this PR: - If any payment was made, the credit note is marked as MODIFY instead of STORNO. Example: - Case 1: No payments before reversal Invoice: 1000 Credit Note 1: -100 Credit Note 2: -900 => Credit Note 1 should be sent as a Modification, Credit Note 2 as STORNO. - Case 2: Payments before reversal Invoice: 1000 Payment: -100 Credit Note: -900 => The Credit Note should be sent as a Modification. task-4818762 Forward-Port-Of: odoo/odoo#224861 Forward-Port-Of: odoo/odoo#211831
Point of Sale now calculates combo child item prices using the currency's rounding precision instead of product price precision. This prevents small rounding discrepancies, ensuring POS order totals match expected sale totals such as 31.00 instead of 31.01.
Original PR description
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total…
Currently, when you have a difference in precision between currency and product price, there can be a discrepency in the computation of the line prices, leading to a difference in the price total between the sale and pos app. Steps to reproduce: ------------------- * Modify the product precision to have 4 digits * Modify the burger menu combo product * Sale price 26.5 * Burger choice: Cheese burger, remove taxes, change price to 10 * Drinks choice: Coca cola, remove taxes, change price to 10, extra price set to 4.5 * Add another combo choice with 1 product only, no tax, price 10 * Open pos session * Add the combo, select the product that were modified > Total is 31.01 when it should be 31.00 Why the fix: ------------ Point of sale was using the decimal precision set on the product price to compute the price unit of the child lines. We can notice that the sale app was using the currency precision. We will use the same approach as sales. The decision was driven by the fact that 1) both scenarios could make sense, 2) total should be as set, 3) child line prices are not as important as the total and don't have a big influence. opw-4769227 Forward-Port-Of: odoo/odoo#220352
Saving a form can now correctly guide users to the intended follow-up action when a validation warning includes a redirect and extra context. This helps users resolve save-blocking issues through the right screen instead of being left with a broken or incomplete error flow.
Original PR description
Have a web_save that raises a RedirectWarning which has the ID of an action and an additional context in its parameters. Trigger the warning in the form view by clicking on the save button in the form view. Before this commit, this feature did not work like at all. - The additional context was not taken into account - the path taken by clicking on the form's save button was not able to handle interacting with the main form view - The error dialog did not handle going into an action in target other than new After this commit, all this is fixed and the whole flow, that allow an error to be enriched such that the user could do the correct action to correct the error now works. opw-4742952 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#224536 Forward-Port-Of: odoo/odoo#223198
This fix ensures returned dropshipped products sent to an internal subcontracting location are recorded with the correct accounting direction. It prevents inventory value from being reduced incorrectly, improving financial accuracy for companies using subcontracting and automated stock valuation.
Original PR description
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will…
…ml internal dropship return **Problem:** when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it **Steps to reproduce:** - enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings - create a storable product with dropshipping route and a vendor - in 'general information' write a non null cost - make sure the product category's inventory valuation' is 'automated' - create a new quotation for this product, confirm it and confirm the linked purchase order - click on the dropship smart button and validate the picking - click on return and select 'Physical Locations/Subcontracting Location' as the return location - validate and click on the valuation smart button - on the only stock valuation layer for this move, click on the book shaped widget **Current behavior:** the account move credits Stock Valuation and debits stock interim (received) **Expected behavior:** As we are returning the product to stock it should increase the value of the stock valuation account. Therefore, it should debit stock valuation and credit stock interim (received) **Cause of the issue:** If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location) https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614 opw-4894755 Forward-Port-Of: odoo/odoo#221771 Forward-Port-Of: odoo/odoo#221009
Razorpay payments now check whether the payment access token has expired before processing. If needed, the system automatically generates a new token, helping prevent payment failures for customers using Razorpay.
Original PR description
Version: - saas-18.2 Issue: - The refresh token method was removed in PR https://github.com/odoo/odoo/pull/188774. Because of this, the Razorpay access token expiry was no longer being checked. Fix: - When a user makes a payment, the system now checks if the Razorpay access token has expired. If it has, a new token will be generated automatically. opw-4953953 Forward-Port-Of: odoo/odoo#224233
Tax return warning checks now refresh when a user opens them, so resolved issues such as draft entries no longer appear incorrectly. This helps users see the current status of a return without slowing down the broader Tax Returns overview.
Original PR description
Before, when opening a Return that had bypassed checks such as Draft Entries, and we had deleted or confirmed those entries it wouldn't have refreshed the check number and would still display that there are draft entries. Now, we are forcing the check to be refreshed when someone wants to see them as to not crash the performances when someone opens the Tax Returns Kanban view. task-4850581
Odoo Studio now correctly keeps the “Extra rights / Technical Features” group visible when editing field visibility rules. This prevents fields from unexpectedly disappearing for users working outside debug mode and makes Studio customization more predictable.
Original PR description
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to…
Steps to reproduce ================== - In debug mode - Go to Contacts - Open any record - Open studio - Click on any field - Add the "Extra rights / Technical Features" group to "Allow visibility to groups" => The group is not displayed as a tag - Restore the view - Now without debug mode (?debug=0), repeat the same steps => The field disappears, we need to toggle "Show Invisible Elements" to see it again Cause of the issue ================== https://github.com/odoo/odoo/pull/179354/commits/15aeaf88c268f047b8b83a5aa66f5da246c2b675 When calling get_views, the "base.group_no_one" is removed from the groups attribute and "invisible" is set to true if we are in debug mode. Solution ======== Adding "base.group_no_one" is still the way to have the expected behavior for now. We override some ir.ui.view functions when in studio to be able to edit it. According to the docstring of _postprocess_debug_to_cache, this feature is temporary. Another solution will be needed in the future. opw-4969262 Forward-Port-Of: odoo/enterprise#91647
Credit note validation for Kenyan OSCU e-invoicing now only considers credit notes that are actually reconciled with the original invoice. This prevents cancelled or draft credit notes from incorrectly blocking valid new credit notes due to overstated quantity or value totals.
Original PR description
[FIX] l10_ke_edi_edi_oscu: ensure quantity and monetary values checks are performed on reconciled reversals only. Fixes a behavior where the checks performed on the credit notes related to their quantities and monetary values include non reconciled credit notes. Steps to reproduce: 1 - activate `l10n_ke` on some company. 2 - Create an invoice. 3 - Create a partial or full credit note ( this one will be reconciled with the invoice automatically ) 4 - cancel the credit note or reset it to draft. 5 - create another credit note where the quantities and/or monetary values exceed that of the invoice if summed up with the cancelled credit note. Following the steps will result in an error message saying that the monetary value or quantities on the credit notes exceed that of the invoice. The correct behavior is to simply not count any credit note that isn't explicitly reconciled with the invoice. opw-4779976 Forward-Port-Of: odoo/enterprise#92319
This fix ensures sales orders in the Mexican localization show the correct invoiced quantity after an invoice cancellation is completed through CFDI. It prevents sales order quantities from incorrectly dropping to zero when the original invoice has been cancelled and replaced, improving billing accuracy and follow-up.
Original PR description
How to reproduce the issue: In l10n_mx: 1. Create a sale order. 2. Create an invoice from the SO, with yesterday’s date, and send it to the CFDI. 3. Lock the period at yesterday’s date. 4. Request the invoice cancellation with the “01” method. This creates a new invoice — confirm it. 5. Create a credit note for the original invoice. 6. Retry sending the cancel request to the CFDI; the CFDI state is now cancelled for the original invoice. On the original SO, the quantity invoiced is 0 despite the CFDI state of the original invoice being cancelled. This commit forces a recompute of the quantity invoiced when the CFDI state changes. Since _compute_qty_invoiced uses _get_invoice_lines, which filters out invoices in sent state, only lines from invoices in cancelled state will be taken into account. opw-4910139 Forward-Port-Of: odoo/enterprise#93480 Forward-Port-Of: odoo/enterprise#91924