Daily updates from Odoo
Saturday, May 23, 2026
17 changes
2 changes
Enhancements to existing features
This update enhances the Indian Profit & Loss report by incorporating 'Other Expenses' into the calculations. This ensures the report accurately reflects all overhead costs, aligning with standard accounting practices and providing a more complete financial picture for Indian businesses using Odoo Enterprise.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
This update fixes an issue where fiscal positions weren't correctly created for US companies due to an outdated configuration. Now, fiscal positions are automatically generated based on the correct localization (US or Canada), ensuring accurate accounting and tax reporting. This simplifies the system and improves data accuracy.
Original PR description
The fiscal position was being created specifically for countries using the Generic CoA. This stems from before the US had its own CoA [1]. Because of this, US companies no longer had an Avatax fiscal position created for them. Now that the US has its own CoA, we move to a simpler `@template()` approach and take the opportunity to add Canada as well. [1] odoo/odoo#223745 task-6228639 Forward-Port-Of: odoo/enterprise#117966
2 changes
Enhancements to existing features
This update improves the accuracy of Indian Profit & Loss reports by incorporating 'Other Expenses' into the calculation. This ensures that net profit figures more closely align with standard accounting practices and provides a more complete financial picture for Indian businesses using Odoo Enterprise.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
A recent update to Odoo's document processing caused errors when downloading signed documents through the Sign app. This fix ensures that compression is applied correctly after a document is merged, resolving compatibility issues with newer versions of the pypdf library. This prevents download failures and improves the reliability of the Sign app.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#266192 Forward-Port-Of: odoo/odoo#265304
4 changes
Enhancements to existing features
This update improves the accuracy of Indian Profit & Loss reports by incorporating 'Other Expenses' into the calculation. This ensures the reports align with standard accounting practices and provide a more complete picture of business profitability.
Original PR description
Update the Indian P&L report structure to capture accounts categorised under 'Other Expenses'. This ensures that the net profit calculation accounts for all overheads, aligning with standard accounting practices. task-6166626 Forward-Port-Of: odoo/enterprise#115402
Resolved issues and error corrections
This change refactors the partner retrieval logic within the account statement line processing to avoid redundant queries. By intelligently filtering partners based on initial matching criteria (bank account), the system eliminates unnecessary searches based on name, preventing performance degradation and improving query efficiency. This optimization primarily targets scenarios where multiple statement lines might initially match on the bank account, reducing the overall processing time.
Original PR description
Various improvements related to performance for `<account.bank.statement.line>._retrieve_partner` Forward-Port-Of: odoo/enterprise#117738
This update fixes an issue where tip payments, even with a 0% tip, weren't always being fully processed by Stripe. The change ensures that a capture payment is always initiated, regardless of the tip amount, aligning with Stripe's requirements and preventing pending payments from being automatically cancelled. This improves payment accuracy and reliability for restaurant orders.
Original PR description
Currently, the `pos_restaurant` module only calls capture payment within `validateTip` if there is an amount to tip. Since Stripe requires a capture for all payments and we defer that to later if it can be adjusted, this means that if customers have tip after payment enabled and enter a tip of 0%, it will never be captured, stay pending, and then be automatically cancelled later down the line. This commit catches that by hooking into the `validateTip` method and calling capture anyway on 0% tips. opw-6082596 Forward-Port-Of: odoo/odoo#265507 Forward-Port-Of: odoo/odoo#261129
This update fixes issues with website translations, ensuring accurate formatting and preserving text meaning. It now correctly handles metadata like image attributes and prevents multiple translation requests, leading to a more reliable and consistent user experience for translated content. This improves the quality of our global website offerings.
Original PR description
This commit fixes and improves several aspects of the recently merged
[translate the whole page].
- Fix formatting issues in the translation like:
- Space getting removed while translating
- Meaning of text is not preserved after translation.
- Example :
- 'Enhance Your' and '<b>Experience</b>' becomes, 'Enhance Your<b>Enhance Your Experience</b>'
- 'hello <b>world</b>' becomes 'Hola<b>mundo</b>' space is trimmed.
- Exclude non-translatable elements such as `.o_brand_promotion` from
translation.
- Support metadata translation, ensuring that translatable attributes
are correctly handled (`alt`, `title`, `placeholder`, and `value`
attributes).
- Disable the “Translate” button while the translation process is
running to prevent multiple concurrent requests.
[translate the whole page]: https://github.com/odoo/odoo/commit/6e1e359ec6a7ae23cfa7d7c96380f845c7fdcfe5
task-5047714
Forward-Port-Of: odoo/odoo#2298948 changes
Resolved issues and error corrections
This update fixes an issue where ticket close times were inaccurate when tickets were reopened and closed again. Now, the calculation considers only the time spent in currently open stages related to the ticket's team, providing a more precise record of time spent resolving the issue. This ensures more reliable reporting on support team efficiency.
Original PR description
Issue: When a ticket is reopened and closed again, `close_hours` included time spent in previous closing stages, causing inaccurate total close time. Before this commit: The `close_hours` field was computed as the total time from ticket creation to close date. If a ticket was closed and later reopened, the time spent in the closed stage was still included in the final `close_hours`, which led to inaccurate results. After this commit: `close_hours` is now computed by summing the working minutes from `duration_stage_tracking` field, considering only the open stages related to the ticket's team. task-4133988
This update fixes an error in how VAT reimbursement moves are generated when unclaimed tax is carried over to the next month. The previous calculation incorrectly used data from the previous month's tax report, leading to inaccurate reimbursement amounts. This ensures accurate VAT reporting and proper reimbursement processing.
Original PR description
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and…
When generating a VAT return with an unclaimed tax amount carried to the next month, the carryover reimbursement move amounts are computed with an incorrect ratio. Steps to reproduce: - Create and post a bill in May containing a VAT amount. - Create and post a bill in June containing a VAT amount. - Create a VAT return for May to carry over the VAT amount to the next month. - Create a VAT return for June, requesting the full VAT amount to be reimbursed. - Validate and send the June VAT return. - Check the generated reimbursement move Issue: Line values does not correspond to anything real/tangible. It occurs because when computing the ratio for the move we check the last tax report entry, where we find the amount of tax from the past months and a line balancing the last month that should not be taken into account. The "Balance tax current account (receivable)" line from the tax closing entry is mistakenly picked up as a tax carried forward line, throwing off the amounts. opw-5961836 Forward-Port-Of: odoo/enterprise#117927 Forward-Port-Of: odoo/enterprise#115451
This update fixes a bug where the Odoo Agent would repeatedly fail when updating records without the specific 'natural language query' topic. By adding a list of available menus and models to the context, the Agent now correctly identifies and interacts with records, preventing timeouts and improving stability.
Original PR description
Purpose: -------- The update and create tools can generate a link to show a preview of the created/updated record. However, the list of available menus is only added when the agent has the natural language query topic. Therefore, when using the Odoo Agent (that does not have that topic) to update a record, the LLM loops on the update record tool guessing random menu ids and eventually times out because the tool calls fail since the menu ids guesses do not match the model of the updated record. The list of available menus is now added in the context if the create or update records topics are available on the agent. The list of available models has also been added in this case. Task-6236642 Forward-Port-Of: odoo/enterprise#117998
This update fixes a problem where adding rental products to the cart would fail due to mismatched date calculations. The fix ensures that rental product durations are correctly handled, preventing errors when mixing different rental periods and improving the overall rental experience. This resolves a conflict between how dates are stored and processed during the cart addition process.
Original PR description
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3.…
Steps to reproduce: =================== 1. Go to the shop page and use the rental date picker to select a start and end date with hours. 2. Find a rental product configured with "Days" pricing. 3. Add to card directly from the product card 4. Add a rental product from product image that has date type value date 5. Go to that product details page. 6. Click add to cart -> Invalid operation, You cannot mix different rental periods... Cause: ====== When adding a product from the shop list view, the system uses the default start/end dates (from the rental period) exactly as first added. However, the "Add to Cart" logic on the product details page attempts to adapt the selected dates to the product's specific rental unit (e.g., normalizing the time component for 'Day' pricing). This re-calculation creates a timestamp mismatch between the item already in the cart (from the shop view) and the new item being added (from the details page). Solution: ========= The add-to-cart flow has been updated to correctly utilize the default duration values (the globally selected dates) if they exist. opw-5450576 Forward-Port-Of: odoo/enterprise#117946 Forward-Port-Of: odoo/enterprise#103373
This update fixes an issue where users could attempt to change assets to draft after setting lock dates in the accounting system. This prevented users from modifying finalized accounting records, ensuring data integrity and compliance with accounting standards. The change restricts draft status for assets after lock dates are applied.
Original PR description
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting…
Steps to reproduce: 1- Install Accounting 2- Go to [Accounting -> Assets] and create a new asset with start date 1/1/2025 3- Specify the fixed asset account and confirm the asset 4- Open [Accounting -> Lock Dates] 5- Set a Lock date on everything with the date 31/12/2025 and save 6- Cancel the asset, set to draft and confirm again Issue: `Invalid Operation: The remaining value on the last depreciation line must be 0` Expected behavior: Should not be able to set to draft once the asset is cancelled Why this happens: Commit 66db1d5 introduced a new condition on the `Set to Draft` button which results in the button being visible when it should not be. If a Lock Date is set after an asset is confirmed, the acquisition and any depreciation entries are effectively finalized in the accounting history. Allowing a user to "Set to Draft" at that point would involve deleting or modifying entries in a closed period, which violates accounting integrity. opw-6152777 Forward-Port-Of: odoo/enterprise#116900
This update resolves a crash that occurred when users clicked the 'hide' button on the payroll dashboard due to an error in how in-memory payrun warnings were handled. The fix ensures warnings are correctly identified and processed, preventing the database error and improving dashboard stability. This change impacts the payroll dashboard functionality.
Original PR description
Closing date payrun warnings are created as in-memory records (.new()), giving them a NewId instead of a real integer DB id. When the user clicked the hide button, this NewId string was passed to action_snooze/action_archive, causing a psycopg2.errors.InvalidTextRepresentation SQL error. Fix by sending False as the id for in-memory warnings in get_payroll_dashboard_warning_cards, and suppressing the hide button on the dashboard when warning.id is falsy. task-6205849 Forward-Port-Of: odoo/enterprise#117854
This update fixes an issue where the POS incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now prioritizes AvaTax fiscal positions only when AvaTax is enabled in the accounting settings, ensuring accurate tax calculations for POS transactions. This improves the reliability of the Point of Sale tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update fixes inconsistencies in how barcode settings are applied to Manufacturing Orders. Previously, mandatory scan requirements weren't consistently enforced, allowing users to bypass them. Now, the system correctly utilizes MRP operation type configurations, ensuring accurate barcode tracking during production processes.
Original PR description
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For…
Before this commit, the "Allow full order validation" were partially ignored in the Barcode app when used for Manufacturing Orders, and the "Mandatory scan" settings didn't work very well. For example, setting the scan of lot/serial as mandatory didn't prevent the user to set automatically a SN on consummed component by generating a lot/serial on the produced product or by clicking on "Produce All" button. This commit adds some conditions to avoid to update barcode lines in case they should depending of the config. This commit also fixes a related issue where the MRP operation type's config wasn't used at all when a MO is created directly from the Barcode app. As the config is get from the MO's picking type and no MO exists when a new one is created from the Barcode app, there is no MO's config returned in the data send by the server. To fix that, the config is now updated clientside when the data are fetched after a save. [Task-5420762](https://www.odoo.com/odoo/project/966/tasks/4655907/project.task/5420762) [opw-5223507](https://www.odoo.com/odoo/project/49/tasks/5223507) Forward-Port-Of: odoo/enterprise#117816 Forward-Port-Of: odoo/enterprise#113318
1 change
Resolved issues and error corrections
This update resolves an issue where bank statement matching was incorrectly preventing multi-step reconciliation flows for liquidity and transfer accounts. The fix limits the matching filter to receivable and payable accounts, restoring the ability to accurately reconcile complex payment sequences like payouts through internal transfers.
Original PR description
Commit e2a9f3bfbb8a excludes from the bank statement matching domain any AML whose source statement line is already reconciled, to prevent false-positive label matches on past manual counterparts. However, the filter is applied to every account type, which breaks legitimate multi-step reconciliation flows on liquidity / transfer accounts (e.g. payout -> internal transfer account -> destination bank). After the first statement line is reconciled, the transfer-account AML is no longer offered as a candidate for the destination bank line; the line falls back to the suspense account and the AML is also invisible in "Match Existing Entries". Scope the new filter to receivable / payable accounts only, which is the case the original commit was actually guarding against. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265653