Daily updates from Odoo
Friday, January 9, 2026
24 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting. The change ensures that contract overlap dates are limited to the payslip period, providing more reliable payroll data. This improves the accuracy of employee time and cost tracking.
Original PR description
Steps to Reproduce: 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). Reason: - If a contract ends before the payslip period, it adds all days from the end of the contract until the end of the payslip period as "Out of Contract", ignoring the payslip start date. - If a contract starts after the payslip period, it adds all days from the payslip start date until the contract start date, ignoring the payslip end date. Solution: Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5350519 Forward-Port-Of: odoo/enterprise#103500 Forward-Port-Of: odoo/enterprise#100700
This update resolves a technical issue that caused a traceback when users accessed the bank reconciliation popover feature in debug mode, specifically when reconciling statements with invoices in different currencies. The fix ensures the popover component functions correctly, preventing errors and improving user experience.
Original PR description
In Bank reconciliation widget, when reconciling a statement with a move in different currency, users may display a popover to access some reconciliation info. Currently, accessing this component in debug mode may raise a traceback. Steps to reproduce: - Have a Bank statement in company currency - Reconcile with an invoice in foreign currency - Go in debug mode - From the reconciliation widget, locate the reconciled bank statement - Click on the reconciled bank statement popover button Issue: Traceback is shown `OwlError: Invalid props for component 'BankRecLineInfoPopOver': 'exchangeMove' is not a object` It occurs because props validation of the Owl component will fail BankRecLineInfoPopOver opw-5355964
This update ensures that all MOA (Monthly Accounting) values within the French accounting module are positive integers. The changes involve rounding and adding a check to prevent negative values and removing unnecessary calculations. This improves the accuracy and reliability of financial reports generated for French businesses using Odoo.
Original PR description
All MOA fields should be positive integer. task-5380637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239587
This update fixes a visual issue in the email composer where long email content would overflow the message bubble, disrupting the user experience. The change makes email content scrollable within the bubble, ensuring a cleaner and more readable display for longer messages. This improves usability for sending and receiving emails.
Original PR description
Current behavior before PR: When the email template (message_type = `comment`) has content that is longer (in width), the content tends to overflow out of the bubble which breaks the UI. Desired behavior after PR is merged: This commit fixes the issue by making the content scrollable inside the bubble. Task-5363388 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237878
This update corrects a minor issue where typing 'B)' was automatically replaced with a 😎 emoji. This change ensures user input remains unaltered, improving the overall user experience and preventing unintended modifications to messages.
Original PR description
Before this PR, typing `B)` was automatically converted into a 😎 emoji, which could unintentionally alter user input. This PR disables that conversion. task-[5221032](https://www.odoo.com/odoo/project/1519/tasks/5221032) Forward-Port-Of: odoo/odoo#242831
This update ensures the Helpdesk dashboard's styling aligns with other Odoo dashboards, specifically addressing a formatting issue where the Top Customers pivot wasn't correctly highlighting the last row. This improves the overall visual consistency and user experience of the Helpdesk dashboard.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103019
This update resolves an issue where canceled orders and their items were incorrectly displayed in new orders, particularly with online payments. The fix ensures that canceled orders and line items are fully removed from the system's data storage, guaranteeing accurate order displays and calculations.
Original PR description
`point_of_sale`, `pos_self_order` ### step to reproduce: - Configure self order with online payment. - Open POS Self Order. - Add some products to the cart. - Cancel the order. - Create a new order and pay it via an "online payment" method. - Click on "Order Now". ### issue: - Previously cancelled products reappear as selected in the new order. ### reason: - Cancelled orders and orderlines were not removed from IndexedDB. - With Pay after Meal, a second order on the same table reused the existing one, causing the product card, order widget, and cart to show quantity and total from the old order instead of the new changes. ### fix: - Ensure both the order and its orderlines are removed from indexeddb when cancelling an order. - Product/cart page must show changed quantity and amount. task: 5005174
This update resolves an issue where invoices couldn't be sent correctly due to a technical error (a 'timeout' situation). The fix corrects a problem with how error messages were handled, ensuring invoices are now sent reliably. This improves the overall stability of the Danish Nemhandel integration.
Original PR description
In case of timeout when sending an invoice there is a traceback due to the following error. ``` AttributeError: 'UserError' object has no attribute 'message' ``` It is fixed in this commit. task-None Forward-Port-Of: odoo/odoo#242811
This update fixes an issue where account balances weren't correctly reflecting transactions across a company's branch hierarchy. By changing the filtering logic to include 'child_of', the balance calculations now accurately aggregate balances from all companies, including child branches, providing a more complete and consistent view of financial data.
Original PR description
Description of the issue/feature this PR addresses: This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a…
Description of the issue/feature this PR addresses:
This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a parent company should be able to see the aggregated balances of its child branches. Currently, the strict equality operator prevents this consolidation, creating a discrepancy between the expected "Global" view and the displayed balance.
Current behavior before PR:
The _compute_current_balance method in account_account.py uses the = operator for the company_id domain: domain=[('account_id', 'in', self.ids), ..., ('company_id', '=', self.env.company.id)]
This restricts the balance calculation exclusively to the current active company, excluding any transactions made in its branches (child companies), even when the user is positioned at the parent level.
Desired behavior after PR is merged:
The operator is changed to child_of. When a user is in a parent company/branch, the current_balance of the account will include the sum of all journal entries from that company and all its descendants in the hierarchy. This ensures consistency with how other parts of Odoo (like https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/account_followup/models/res_partner.py#L230) handle company-related domains.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242576This update fixes an issue where combo lines in the Point of Sale (PoS) system weren't accurately reflecting the selected product variants. The fix ensures that variant information is displayed on both the order confirmation and receipt screens, improving the user experience. The underlying issue was a misinterpretation of how combo configurations were being handled.
Original PR description
**Steps to reproduce:** - Create a combo including products with different variants - The variants should be set to "Instantly" - Go to PoS and click on that combo - When confirming, the lines do not…
**Steps to reproduce:** - Create a combo including products with different variants - The variants should be set to "Instantly" - Go to PoS and click on that combo - When confirming, the lines do not show the selected variant - The ticket on the receipt screen does not show it either **Why the fix:** We were trying to map the combo lines using the line's configuration, but the configuration did not always contain the needed information, in this case the attribute_value_ids. This happens because when clicking on a combo, we are setting the configuration as the configuration popup is displaying, meaning we do not know which variants are going to be chosen. Instead, we now access the correct variants using the current combo line directly if the configuration is not set. An existing test had to be changed because before this fix, as we did not care for variants in certain cases, we did not add the price_extra from the variant to the combo's price, which seems to be the behavior we want. opw-5392530
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, when a refund was processed, these attributes were lost. The fix correctly transfers the attributes from the original order to the new refund order, improving the accuracy of refund records.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332
This update resolves a technical issue within the HTML editor that could cause errors when content is deleted during editing. The fix ensures the editor continues to function correctly even when all inserted content is removed, improving overall stability and user experience. This was triggered by a disconnect between selection nodes.
Original PR description
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`,…
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`, and some specific `<br>` nodes. Ultimately, the selection is set after the last inserted node. In some cases, none of the inserted content remains after the clean up. When this happens, the selection is being set after the last inserted node, which is not part of the DOM anymore, and therefore leads to an error. This commit prevents this from happening by detecting when all inserted content was actually already removed. Steps to reproduce: - In a plain web page, copy a <br> into the clipboard - In an editor, put a character on a line - Paste => An error popup was displayed task-5429909 [FIX] html_editor: avoid failing when selection nodes are disconnected This commit addresses a traceback that was spotted but for which the actual scenario remains undetermined. The only possible way this traceback may occur is if nodes inside a selection are disconnected. The test added by this commit produces the same traceback as the observed one. task-5429909 Forward-Port-Of: odoo/odoo#242488
This update resolves an issue where Google Input Tool caused errors in HTML fields, specifically when typing Arabic numbers. The fix ensures the system correctly handles `keydown` events, even those triggered by the Google Input Tool, preventing tracebacks and improving overall stability.
Original PR description
Problem: When using Google Input Tool, typing Arabic numbers causes a traceback in HTML fields. Cause: The tool triggers a fake `keydown` event without the `key` attribute. This is failing before c10fd06320b013057831a6a46b2922b5386b71ef. Solution: Explicitly check that the `key` attribute exists on the event before using it. Steps to reproduce: - Install Google Input Tool in your browser. - Open any HTML field. - Add any character using the extension. - Observe a traceback. opw-5447680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242498
This update prevents the automatic cancellation of 'post -> stock' pickings when a backorder is cancelled in multi-step production routes. Previously, cancelling a backorder would also remove the completed picking. This change ensures that pickings are only cancelled if the related MO is fully completed, streamlining operations and reducing unnecessary disruptions.
Original PR description
Issue ----- For multi step routes, cancelling the backorder MO also cancels the (post -> stock) picking for the produced quantity. Steps to reproduce ----- - Activate routes - Go to the main warehouse and activate 3 step production - Creation of a MO for 100 units - Validate the pre production picking - Produce 40 units and create a backorder for remaining quantity - Cancel the backorder > The "post -> stock" picking is cancelled as well Cause ----- The picking is in "ready" state, so it gets cancelled by https://github.com/odoo/odoo/blob/083d53c688a0d18a1f4594b9fcbbfa738aa5e86d/addons/mrp/models/mrp_production.py#L1743-L1744 Desired behaviour ----- > Only cancel related MO pickings (pre prod/post prod) if no MO (or MOs) done yet. Don't cancel related MO pickings if any MO validated. ----- Ticket: opw-5405024 Forward-Port-Of: odoo/odoo#239865
This update prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets needing attention, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#102860 Forward-Port-Of: odoo/enterprise#52355
This update resolves an issue where the summary lines within the Barcode app appeared in a light color scheme, regardless of the user's Dark Mode setting. The fix utilizes dynamic color variables to ensure the summary lines correctly display in dark mode, improving the user experience and visual consistency across the Odoo platform.
Original PR description
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before"…
## Issue In the Barcode app (`stock_barcode`), the summary line appears in its light color scheme, even if the user is using dark mode. <img width="1914" height="989" alt="before" src="https://github.com/user-attachments/assets/39f47454-6dc5-4fe6-927d-8ebc984b13b7" /> ## Cause The `background` property was set to a constant (light) color. ## Steps to reproduce 1. Install the Barcode (`stock_barcode`) and Purchase (`purchase`) apps. 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. Turn on Dark Mode by clicking in the upper-right corner and toggling *"Dark Mode"* 3. Create a product tracked *By Unique Serial Number*. 4. Create a Purchase Order for the product created in step 3 with a quantity greater or equal than 2, then click *Confirm*. 5. Go to the Barcode app, click *Operations*, then *Receipts*, and select the picking created from the PO. 6. The summary line appears in white (or light blue when selecting it). ## Solution We can use variables instead of constant colors. The `--list-group-bg` variable holds a different color depending on whether the line is selected, faulty, or completed. https://github.com/odoo/enterprise/blob/999009c859a1fb8e244f754a530fe39d71ede506/stock_barcode/static/src/components/line.scss#L27-L47 ## After this commit <img width="1912" height="983" alt="after" src="https://github.com/user-attachments/assets/899366fc-0290-42e8-9c50-fd3298e262d6" /> opw-5364654 Forward-Port-Of: odoo/enterprise#102270
This update fixes a data inconsistency issue in Peruvian invoices and credit notes. Previously, the document number was formatted with leading zeros, but the related name field wasn't updated. This change ensures all invoice fields are consistently formatted, improving accuracy in vendor invoices and reports.
Original PR description
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not…
When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields. Steps to reproduce: 1. Create a purchase invoice for a Peruvian company 2. Select a document type (Factura, Boleta, or Credit/Debit Note) 3. Enter a document number like "F01-100" 4. Save the record 5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports. 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#241948
This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that tax calculations are handled correctly when creating these expense reports, preventing inaccurate accounting entries. This ensures consistent and reliable expense tracking.
Original PR description
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2. Confirm and generate the expense report. 3. Reset the expense’s journal entry to draft and add an analytic account on the first line. → An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited. ## Cause For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*. In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes. However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`. This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines. As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate. ## Solution Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`. **opw-5166707** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241545 Forward-Port-Of: odoo/odoo#233841
This update resolves a validation error that occurred when generating PEPPOL invoices with cash rounding enabled. The fix removes a problematic XML node that was causing issues with the invoice's UBL structure, ensuring invoices are correctly processed and validated against PEPPOL standards. This ensures accurate invoice generation and compliance.
Original PR description
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash…
Issue: A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding Step to reproduce: 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: Add a rounding line - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding 6. Confirm & Send (with PEPPOL) Current Behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€ - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€ - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax" - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `BR-E-08`: "In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount BT-116 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT"" Expected behavior: Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ Solution: Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines. https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals As invoice lines should contain their item name. Rounding line won't have one. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/ As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information. https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310 As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order. This commit also: - fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08). opw-5434335 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241717
This update fixes an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The fix corrects a restriction in the system's access controls, ensuring all users with accounting rights can now view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update corrects a bug where purchase taxes weren't correctly applied to purchase orders when products were added from purchase agreements. The fix ensures that taxes associated with the parent company are now accurately reflected on child company purchase orders. This improves financial accuracy and reporting across the Odoo system.
Original PR description
### Issue: In a child company, adding a product from a Purchase Agreement to a Purchase Order does not apply the associated parent company's purchase taxes ### Cause: In the onchange, taxes were filtered by company: ```python taxes_ids = fpos.map_tax(line.product_id.supplier_taxes_id.filtered(lambda tax: tax.company_id == requisition.company_id)).ids ``` This filter fails for taxes belonging to the parent company, so they were not applied on the child company purchase order ### Steps to reproduce: - Create a company branch and switch to it - Enable `Purchase Agreements` in Settings - Create a product with a Purchase Taxes (ex. 15%) - Create a Purchase Agreement for any vendor with this product - Create a RFQ for the vendor and add the agreement - Observe that the tax is not applied opw-5121243 Forward-Port-Of: odoo/odoo#242909 Forward-Port-Of: odoo/odoo#237114
This update fixes a minor issue where discounts could result in a small, unexpected tax difference ($0.01) in sales orders. The change ensures that tax adjustments are correctly applied even when the overall tax total is zero due to discounts. This improves the accuracy of order totals.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set tax rounding to "Round Globally"; 2. create a 19.99% tax; 3. create a new sales order; 4. add a line with a $19.99 unit price & 19.99% tax; 5. add a second line with identical values; 6. apply a 100% global discount (-$38.98 subtotal, -$47.97 total). Issue ----- The order total is $0.01 due to VAT. Cause ----- The `_round_tax_details_tax_amounts` method distributes the "tax delta" across the tax details, but currently it only does this if there's a non-zero target tax amount. In our scenario, we have a $0.01 tax delta, but because our tax total is $0.00 due to the 100% discount, the delta doesn't get distributed, leading to the $0.01 difference not getting corrected. Solution -------- When deciding whether to distribute a tax delta, check the tax delta value instead of the target tax amount. opw-5345538 opw-5097907 Forward-Port-Of: odoo/odoo#240633
This update resolves a problem preventing connections to IAP Codaclean, which is crucial for accurate financial reporting. The issue stemmed from a missing parameter in the system, now corrected to ensure seamless integration and data transfer for Belgian users.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id Forward-Port-Of: odoo/enterprise#103724
This change reverts a previous update that was causing problems when multiple companies used the same accounting entries. It ensures that account records are correctly linked to the appropriate company, resolving inconsistencies and improving data accuracy. This addresses an issue reported in our internal tracking system.
Original PR description
This reverts commit 7a2b03846f07dcf04743d745c7c942ea17721d0a. This commit created issues with account shared by multiple companies Forward-Port-Of: odoo/odoo#243081