# How to reproduce
- Install the l10n_hu_edi module
- Switch to a Hungarian company
- Enable a currency (e.g., EUR) and configure two different exchange rates on two different dates
- Create a new invoice with :
	- Delivery Date: One of the configured date
	- A line with a price unit and a tax
- Save the invoice
- Edit the invoice :
	- Delivery Date : The other configured date
	- Change the price unit of the line
- Save the invoice

# The problem
The taxed amount total is using the old price unit

# Cause
## TLDR
This commit (https://github.com/odoo/odoo/pull/225407) made it so we recompute the tax when the currency is changed with round globally. This recomputation is based on the old tax values, so it should not be done when editing the base lines in the form view. To prevent this, a condition checks that the invoice date was not changed (which should be the only way to change the currency rate from that view if I understand correctly).

Sadly, the l10n_hu_edi module changes this behavior and makes it so the currency rate is also recomputed when the delivery date changes

## Detailed analysis

In the write() method of an account_move, we try to determine `round_from_tax_lines`. Before, in the situation where a base line is modified, it was computed here :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3032-L3049

In our use case, `round_from_tax_lines` would then equal to `False`

But, this commit (https://github.com/odoo/odoo/pull/225407) added the following condition that made it so in our use case, `round_from_tax_line` is trucy :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3029-L3031

That value is then used right after in the computation of the tax line values :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3061

Since `round_from_tax_line` is trucy, we pass the tax_lines to the `_round_base_lines_tax_details()` function

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L1638

Which calls the `_round_tax_details_tax_amounts_from_tax_lines()` function. That function changes `base_lines["tax_details"]["tax_data"]` `tax_amount` and `tax_currency` based on the tax_lines `balance` and `amount_currency`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L2143-L2144

Except, those tax_lines values are the values of the current tax_lines, not the updated one. So they use the `balance` and `amount_currency` values of before the write

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L1631-L1632

`base_lines["tax_details"]["tax_data"]` is later used to define `tax_rep_data`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L2437-L2452

Which is then used to determine `base_lines_to_update`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L3074-L3080

Nevertheless, this issue is quite niche because the condition to assign `round_from_tax_lines` checks that the invoice date has not changed, which would be the only way to edit the currency rate and the base lines at the same time

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3029

Except that the l10n_hu_edi module defines an override to recompute the currency rate when the delivery date changes

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/l10n_hu_edi/models/account_move.py#L128-L130

# Proposed solution
Since the tax recomputation is done using the values before the write, we never want to do it if the base lines have changed. Editing the condition of the commit that introduced the issue would not be enough because any module can ask for a currency rate recomputation for any reason.

Because of this, we should do the tax recomputation only if the base_lines have not changed.

opw-5800521

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, finding a bom for a recordset of `products` involved looping over all the boms and it will loop over all the `product_variant_ids` of `bom.product_tmpl_id` if the bom's `product_id` is NULL. This approach might loop over variants which we are not trying to find a bom for. In additon to that, due to the fact that multiple boms might have the same `product_tmpl_id`, this approach might consider the same variants in the inner loop redundantly even though we matched the variant with a bom in a previous itration.

Worst case, this might result in a time complexity of $O(N * M)$ where N is the number of boms and M is the number of variants.

To improve the performance, I only considered the variants given in the paramater `products` and in addition to that, I created a new dictionary mapping a `product_tmpl_id` to its bom if the bom doesn't have a variant set. By doing this, I can loop over the `products` given and if it doesn't have a bom set then it will be set to the one its template had taken from the previos loop.

In a method call with the following constraints
    - **2** products the method was finding a bom for
    - The 2 products had the same template and the template contained **550** active variants
    - The boms were only related to the template rather than the variants themselves.

| Input Size | Before | After |
| :--- | :--- | :--- |
| 100 | 0.78s | 0.03s |
| 1000 | 8.53s | 0.11s |
| 10000 | 80.99s | 0.73s |

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

**Problem:**
When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error.

**Steps to Reproduce:**
- Make a branch of "My Company (San Francisco)"
- Set user "Marc Demo" to only have access to the branch
- Add a new bank journal set to "EUR" currency
- Switch to Marc Demo
- Try to add a transaction in the new bank journal

**Root Cause:**
When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error.

**Solution:**
If the company is the parent company of the active company, get the currency
`inverse_rate` from the active company instead. Since branches use the rate of
the parent, this will return the same result but without an access error.


Ticket [link](https://www.odoo.com/odoo/project.task/6186901)
opw-6186901

Forward-Port-Of: odoo/odoo#263425