Thursday, November 13, 2025
27 changes · saas-18.3
Resolved issues and error corrections
This change fixes an issue where certain payment amounts could be written incorrectly in BACS batch files because of floating-point rounding. It ensures the exported amount matches the actual payment value, preventing underpayment by one penny in affected cases.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
This update refreshes the spreadsheet component to its latest version and includes several bug fixes. It improves reliability when editing charts and filters, handles unusual sheet names better, and prevents some interface issues from appearing during normal use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f31a75208 [REL] 18.3.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f31a75208 [REL] 18.3.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3bfeb2c7f [FIX] composer: set editionMode to inactive when composer is unmounted [Task: 5149215](https://www.odoo.com/odoo/2328/tasks/5149215) https://github.com/odoo/o-spreadsheet/commit/1e94c7c0c [FIX] filter menu: truncate long filter values [Task: 5219611](https://www.odoo.com/odoo/2328/tasks/5219611) https://github.com/odoo/o-spreadsheet/commit/12b77d011 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762) https://github.com/odoo/o-spreadsheet/commit/0682b866f [FIX] charts: crash when converting empty chart to scorecard/gauge [Task: 5181741](https://www.odoo.com/odoo/2328/tasks/5181741) https://github.com/odoo/o-spreadsheet/commit/9017d0700 [FIX] helpers: setXcToFixedReferenceType support all xc [Task: 5165969](https://www.odoo.com/odoo/2328/tasks/5165969) https://github.com/odoo/o-spreadsheet/commit/49f1e4223 [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fix restores the expected taxes on invoices for Saudi Arabia customers. It prevents default fiscal settings from unintentionally removing tax lines, so products with VAT now show the correct tax again.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882
Odoo now reliably hides the Raspberry Pi 5’s built-in serial port from the device list, even on newer Raspberry Pi OS versions. This prevents an internal port from appearing as if it were an available external device, which avoids confusion and misconfiguration.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235074
This update fixes the Italian electronic document type names and their translations. It helps users see the correct labels when creating invoices and related documents, reducing confusion and improving consistency with the official format.
Original PR description
Simplified and fixed labels and labels translations. Ref: https://help.fattureincloud.it/help/articolo/544-crea-autofattura-elettronica Ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiGeneraliDocumento/TipoDocumento Forward-Port-Of: odoo/odoo#235374 Forward-Port-Of: odoo/odoo#233943
This update prevents a timing issue in Knowledge that could sometimes show the wrong article after reorganizing items and then opening another one. As a result, users should now reliably see the article they clicked and continue editing without interruption.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073 Forward-Port-Of: odoo/enterprise#99174
This update corrects how inventory value is recorded when a subcontracted product is delivered directly from the supplier. It prevents the received stock layer from keeping a leftover value and quantity, which could otherwise distort product costing, especially for FIFO products.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644 Forward-Port-Of: odoo/odoo#234573 Forward-Port-Of: odoo/odoo#233041
Opening Studio on a calendar view now works correctly even when the calendar includes a field with access restrictions. Previously, this could cause the page to crash; now the editor safely handles those fields, improving reliability for users configuring calendars.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash Forward-Port-Of: odoo/enterprise#99254 Forward-Port-Of: odoo/enterprise#98903
When a user deletes a rating message in the portal, the rating summary cards now update immediately to reflect the change. This prevents stale ratings from staying visible after content has been removed, keeping the page accurate for visitors and editors.
Original PR description
*: portal, portal_rating, website_slides PR #221050, makes it possible to properly remove a message in the portal and PR #216044 retrieves the rating cards feature. There is an overlap between what these two PRs do. When a user removes a rating message and there is a rating cards feature on the page, it should be updated. Most of the remove method changes are indeed what we did in forward port of #221050 (#222517). task-5106543 Forward-Port-Of: odoo/odoo#235137 Forward-Port-Of: odoo/odoo#224258
This fix restores the ability to choose an existing saved payment method when registering a payment for an invoice. It ensures the system looks up saved payment details for both the company and invoice contact, preventing valid customer payment methods from being hidden.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718 Forward-Port-Of: odoo/odoo#235368 Forward-Port-Of: odoo/odoo#234173
This fix ensures that links to scoped apps such as Discuss open the matching page instead of sending users back to the main home screen. It improves navigation consistency and prevents users from losing their place when opening these app URLs.
Original PR description
This commit fixes the '/scoped_app' redirection to '/odoo' without loosing the history state. Previously, when opening a route such as '/scoped_app/discuss', the webclient would use an empty state and redirect to the home screen with '/odoo' instead of redirecting to '/odoo/discuss'. Two tests have been added in router to assert the different redirection behavior when using scoped apps from the browser instead of a standalone app. task-5159471 Forward-Port-Of: odoo/odoo#234946
Product warning messages will only appear on sales, purchase, and stock documents when the warning feature is enabled in settings. This prevents users from seeing warnings after the feature has been turned off, keeping document behavior consistent with the configuration.
Original PR description
Step to reproduce:
- install purchase
- go to setting -> (enable) warning
- create a new products and add purchase warning
- now disable the warning from setting
- create a PO with that product
Observation:
- warning is visible, even though we disabled the setting
Cause:
- After commit [1] , once a warning is set on a product, it is displayed on
document regardless of the warning setting.
[1]:https://github.com/odoo/odoo/commit/1e13520ca9bb18deba85110ce9362ac2adb55904
Fix:
- Fix the computes of warning message to run only,
when the warning setting is enabled
opw-5156107
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes how subscription invoices are tracked when only part of an invoice is credited. After a partial credit note, the remaining billed quantity now stays correctly recorded instead of being reset to zero, so subscription totals stay accurate.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#98892 Forward-Port-Of: odoo/enterprise#91344
A test and report query that depended on enterprise-only fleet data were moved out of the community code. This fixes the community build failure while keeping the fleet-specific tax reporting behavior available in Enterprise.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/odoo#235339 Forward-Port-Of: odoo/odoo#234095
The fleet tax report test and its data lookup were moved into the enterprise version, where the vehicle-based logic is available. This prevents community builds from failing and ensures the report continues to work correctly in enterprise.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462 Forward-Port-Of: odoo/enterprise#99288 Forward-Port-Of: odoo/enterprise#98650
This update prevents AI conversations from breaking if a user closes the chat before the reply arrives. It also ensures replies are not posted to a new, unrelated chat, so the conversation stays consistent and users avoid missing or misplaced answers.
Original PR description
If a user sends a message to an ai agent and then closes the chat channel before receving the response, - For AI composer channels (channels opened through AI chatter button) an error occurs. - For…
If a user sends a message to an ai agent and then closes the chat channel before receving the response, - For AI composer channels (channels opened through AI chatter button) an error occurs. - For other AI channels, A new ai chat channel gets created and the response is posted to that channel instead of the deleted one. Cause of the Issue : When the channel is deleted, a serialization error occurs because one transaction is trying to delete the channel while the other is trying to post the ai response to the channel. The delete transaction finishes execution and the response generation transaction is retried. - For AI composer channels some fields of the deleted channel are accessed inside `_ai_add_message_to_context` and `_ai_create_response` which raises an error. - For other AI channels, when generate_response is retried,_get_or_create_ai_chat is called and given that the old channel has already been deleted, a new one is created and the response is posted to that channel. Note: No issue will happen if the response generation transaction is executed and the deletion transaction is retried, because it will delete the channel after the response was posted which is a normal behavior. task-5063221
Receipts in Point of Sale will now show the cashier or server name even when a preset like “Eat in” is used. This ensures customers and staff can always see who handled the order, making receipts more consistent and informative.
Original PR description
Currently cashier name is only shown if no preset is shown or if the present identification is set on name. Steps tot reproduce: -------------------- * Open restaurant * Make sure you use the Eat in preset * Place an order and pay it > Observation: On the receipt the "Served by:" indication is not shown. Why the fix: ------------ The cashier/server information should not depend on the preset used. opw-5154347 Forward-Port-Of: odoo/odoo#231930
This update improves how fixed taxes are represented in electronic invoice documents. It separates taxes that should be shown as invoice additions from those that should be treated as allowances or charges, which helps avoid incorrect totals and improves invoice accuracy.
Original PR description
This commit contains 2 things: - an helper to extract any tax_data and move it to another base_line - the usage of this helper in UBL to turn emptying taxes into additional base_lines == Add helpers…
This commit contains 2 things: - an helper to extract any tax_data and move it to another base_line - the usage of this helper in UBL to turn emptying taxes into additional base_lines == Add helpers to turn tax_data into new base_lines easily == With this helper, you can now exclude any tax from any base line and turn them into new base lines. Also, I changed a bit the smooth distribution of rounding because the math.ceil is sometimes too greedy and make the whole results to be less accurate. == Make a different behavior between recycling contribution taxes / emptying taxes == In UBL, all fixed taxes are treated as allowances/charges. In this commit, we make a clear distinction between recycling contribution taxes that are treated as allowances/charges and emptying taxes that are exempted of tax and are treated as addition invoice lines in the document. == Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function == The aggregator wasn't called when setting the 'target_base_line' at the very first time. task_id: 5182783 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A browser-specific issue caused some dropdowns on blog pages to behave like a link click when they were opened, which could reload the page before a user made a selection. This fix prevents that unwanted reload, making the Archive dropdown work normally.
Original PR description
In some browsers, opening a `<select>` triggers a click event. Because of this when the blog's sidebar "Archive" dropdown is opened, it might reload the page before the selection is actually made. This commit solves this by detecting a distinct event when PostLink is activated on `<select>` element. Steps to reproduce: - Using Firefox - Install `website_blog` - Edit the blogs page - Activate the sidebar - Save - Open the "Archive" dropdown => The page was reloaded Forward-Port-Of: odoo/odoo#233202
This update corrects how rounding is applied in accounting tests and related invoice scenarios, ensuring amounts are handled in the right place. It also updates outdated comments and test values so the checks better reflect real behavior, reducing the risk of confusing or incorrect accounting results.
Original PR description
Also fixes the comments that were wrong. Change some values to better test things 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#235392 Forward-Port-Of: odoo/odoo#234213
This change fixes an issue that could prevent pending bank transactions from displaying correctly in the reconciliation view. It also corrects a missing asynchronous step so account totals are calculated properly instead of returning an unfinished result.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/1691a9d6ec426566b81537544cafe09d9c62ad78 We added a template to inherit BankRecKanbanRenderer, but we forgot to add the extension. By doing that it broke the pending transaction template override. Also this: https://github.com/odoo/enterprise/commit/5d5a7aca4f0abb4492314324631e8b5463a35332 change the getJournalTotalAmount to use a super instead, but it was missing an await otherwise we just have a promise no task id
When a template is duplicated, its attachments are now copied too instead of being shared between versions. This prevents changes in one template from affecting others and helps avoid access issues when permissions are applied to attachments.
Original PR description
Copying tmeplates should copy their attachments. Otherwise they are
shared, which means
* wrong res_id: ACL check on attachments relies on a specific
template, as res_model / res_id is used in access check;
* propagated changes: changing one attachment changes it on all
duplicated templates;
If custom rules on templates are implemented, this means notably
ACL issues when accessing attachments. It is not the case in standard
Odoo 17 as everyone can read templates but this notably changes in
future versions of Odoo.
While being there, also fix 'default' usage in copy override. User
given values should not be erased by default computation of name.
Task-5128863
Forward-Port-Of: odoo/odoo#234351
Forward-Port-Of: odoo/odoo#232877Odoo now uses the Colombian national bank’s new exchange-rate service instead of the old SOAP-based API that was discontinued. This keeps currency rates for Colombia working reliably and avoids interruptions in automatic updates.
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262 Forward-Port-Of: odoo/enterprise#99152
When inserting a table or other element into a new report, the editor now keeps the cursor and selection in the right place. This makes it easier for users to continue typing or interacting with the inserted content without losing their place.
Original PR description
On a new report, add a X2Many table in a new Report. In many cases there will be some issues with the selection as, when inserting the Element via the command of the report Editor we explicitly focus the editable of the html_editor. We need the document inside the iframe to get the focus, because our flow implied to click on some popover bound to the main window. But focusing the editable element changed the selection. So, instead, we focus the iframe's inner window, and the selection stays at the right place, and the user can immediately interact with it (by continuing typing after the insertion) task-5159482 Forward-Port-Of: odoo/enterprise#97642
This change restores the ability to find products in sales orders using a supplier’s product name or code. It fixes a search issue introduced by a previous view cleanup, helping users locate the right product faster and avoid manual lookup.
Original PR description
Commit 6e69b1d4a357bf236695a2ed5b09fd62de911872 cleaned up SO views and removed some context fields from the product_id and product_template_id fields which were in fact used in the `_search_display_name` override of the related models. This commit brings back those values to allow finding products by their seller product name or code. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes sure bank statement lines are indexed correctly when they are created or updated. It helps prevent incorrect bank journal balances caused by a missing line index.
Original PR description
Ensure proper computation of first_line_index when line.internal_index or line.state changes. Previously, the computation of first_line_index was grouped with the date computation. However, due to a specific ORM behavior, the compute method is not triggered when one of the computed fields (in this case, the date) is provided in the create values. As a result, first_line_index could remain falsy, leading to an incorrect balance in the bank journal. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoices and vendor bills with deferred amounts can now be reset to Draft more than once, even when audit trail protections are enabled. This avoids unnecessary blocking during accounting corrections and makes it easier to adjust documents safely.
Original PR description
Resetting a vendor bill or invoice with deferred amounts will unlink or reset all existing deferred entries. If the audit trail is enabled, some of these entries must be cancelled instead. [AccountMove.button_draft()](https://github.com/odoo/enterprise/blob/a3f461040cb3443fbcb190c28fddae7044bbd1e7/account_accountant/models/account_move.py#L80-L88) If a protected entry is already cancelled, `AccountMove._unlink_or_reverse()` will still attempt to cancel it. This prevents entries from being Reset to Draft more than once. The current commit removes this restriction. opw-5187737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235223