Daily updates from Odoo
Sunday, November 2, 2025
6 changes
1 change
Resolved issues and error corrections
Product forms now show the correct tax information when a branch company uses taxes shared from its parent company. This helps ensure displayed sale prices match the taxes that will actually be applied on invoices and sales orders.
Original PR description
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax…
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form. Cause: - After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company. Fix: - Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents. [PR]: https://github.com/odoo/odoo/pull/194881 [17.0 PR]: https://github.com/odoo/odoo/pull/125642 opw-5042833 Forward-Port-Of: odoo/odoo#233720
1 change
Resolved issues and error corrections
This fixes an issue where Stripe payments in Point of Sale could not correctly support adding a tip after payment. Payments are now adjusted and captured properly, helping restaurants avoid failed or incomplete tipped transactions.
Original PR description
Since [^1], tip after payment has been broken for stripe as `_update_payment_line_for_tip` is no longer called anywhere. This means that all payments were put in as uncaptured and no future tipping would work. This PR fixes it by using the "new" send_payment_adjust method like ayden to guarantee the payments are properly handled. Note that this is solved by wrapping `capturePayment` into a new method `capturePaymentStripe` to keep the stable policy. A followup PR will move the data back to `capturePayment` in master with the new parameters. opw-5121568 [^1]: 9c37f42ef4e23372f5e2bdbb956b625b3a47d8e1 Forward-Port-Of: odoo/odoo#232574
1 change
Resolved issues and error corrections
Fixed an issue in the Journal Report where the Global Tax Summary did not refresh when users changed the rounding unit. This keeps tax summary figures consistent with the rest of the report and reduces confusion when reviewing rounded financial values.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98508 Forward-Port-Of: odoo/enterprise#94660
2 changes
Resolved issues and error corrections
Purchase order tax totals now use the currency from the current order instead of mixing currencies from multiple records. This prevents an error that could block users from calculating taxes on purchase orders involving different currencies.
Original PR description
On the tax computation, when trying to compute the total tax, customer was having an error " Expected singleton: res.currency(1, 69) " As Odoo is trying to get the currency of all the records instead of the one in the current order opw-5177551 Forward-Port-Of: odoo/odoo#233471
Product forms now show the correct tax information when a branch company uses taxes shared from its parent company. This helps users see accurate sales pricing on products, matching the taxes applied later on invoices and sales orders.
Original PR description
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax…
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form. Cause: - After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company. Fix: - Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents. [PR]: https://github.com/odoo/odoo/pull/194881 [17.0 PR]: https://github.com/odoo/odoo/pull/125642 opw-5042833 Forward-Port-Of: odoo/odoo#233720
1 change
Resolved issues and error corrections
Product forms now show the correct tax information when a branch company uses taxes inherited from its parent company. This prevents misleading sale prices from appearing on products and keeps the product view consistent with invoices and sales orders.
Original PR description
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax…
Steps: - Install account app. - Create a branch company under the main company. - Create a tax for the branch company. - Add a main company tax on a product. - Switch to branch company. Issue: - Tax string is not displaying on the product form even though its setting tax from parent company on invoice line and SO line so its displaying wrong sale price on product form. Cause: - After [PR] taxes are only consider from current company even though company is branch company but in [17.0 PR] we share taxed and other accounting related data b/w main and branch company so if branch does not it's specific tax applied on product then it should take tax from its parent company. Fix: - Compute tax_string in product the way we compute tax on invoice line, SOL etc using `_filter_taxes_by_company` method this way it'll give proper tax which will be applied on related documents. [PR]: https://github.com/odoo/odoo/pull/194881 [17.0 PR]: https://github.com/odoo/odoo/pull/125642 opw-5042833 Forward-Port-Of: odoo/odoo#233720