**Problem:**
The problem happens when  a service is linked to a task but it's not billed on timesheet.

If a quotation is created with this service (which creates the task linked to it) and a timesheet is added to the task, this will trigger a recompute of `purchase_price` (the cost column) of the sale order line in the quotation.

If the client had written another cost on the sale order line of the quotation than the original one (coming from the `standard_price` of the product) this will erase it and set the value back to the standard price of the product. 

Because the service is not billed on timesheet we don't want a modification of timesheet to affect the cost set on the quotation.

**Steps to reproduce:**
- In settings, activate the "margins" setting in Sales
- Open Sales/products and create a new product
- Set the product type as "Service"
- Set the "create on order" field as Task
- Set the "project" field to an existing project
- Set a strictly positive value in the cost field
- Set a name and save
- Create a new quotation and add the product you just created
- Confirm the quotation
- In the order lines page, add the cost column
- Change the value of the cost column
- Click on the "Tasks" smart button
- Add a new timesheet in the timesheet page and save
- Come back to the sale order via the smart button

**Current behavior:**
The value of the cost column was reset the the cost of the product

**Expected behavior:**
Mofifying the timesheets shouldn't impact the cost of a service which is not invoiced on timesheets

**Cause of the issue:**
Because the sale_timesheet_margin module is installed the
_compute_purchase_price method is overriden and depends on
analytic_line_ids.amount
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L8
when this method is called in our flow, because
sol.product_id.purchase_price is not null our sale order line
will not get filtered out
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_timesheet_margin/models/sale_order_line.py#L11
and it will reach the original
_compute_purchase_price method were the value of purchase_price
will be reset to the value of self.product_id.standard_price
https://github.com/odoo/odoo/blob/c335d03e776014e0b7172a3f44507404a083aaed/addons/sale_margin/models/sale_order_line.py#L30


**Fix:**
We want to filter out the sale.order.lines for which the computation
of purchase_price has been triggered via the analytic_line_ids.amount
dependency and for which we don't want the computation to happen
(when the service_policy is not "timesheet").
We need to do this without filtering out the sales.order.lines for which the
computation of purchase_price has been triggered by a dependency from
the original compute_purchase_price method
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_margin/models/sale_order_line.py#L20-L21
or another orverride of this method
(for now there are two of those : one in sale_expense_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_expense_margin/models/sale_order_line.py#L10-L11
and one in sale_stock_margin
https://github.com/odoo/odoo/blob/11cdfe50bda17b004249546a67708e954b3667fc/addons/sale_stock_margin/models/sale_order_line.py#L10-L11
)

is_expense is defined in the sale module
is_service is defined in the sale_service module
service_policy is defined in the sale_project module
all those field are available when sale_timesheet_margin is installed



opw-4627037

Forward-Port-Of: odoo/odoo#205415

Before, `l10n_ar_edi` had only live test cases. This means that if there is an error in a PR or forward port, no tests would catch it as the were marked `external_l10n` and not ran. Using both `l10n_ke_edi_oscu` and and `l10n_br_edi_pos` recent mock setup as an example, this PR aims to mock the soap requests sent in the module.

Notes:
- As of now this is only one individual test case. More tests will come as there is time, but having 1 will prevent errors from happening again.

- Within this module, when the first record within an EDI journal is created, it will try to pull the sequence from the database, and if it can't find a suitable last sequence, it will query the API. This means that any onchange on the first journal entry that will recompute the name or sequence leads to the `_get_last_sequence` function being called and making an API request as the sequence isn't stored in the database yet.

  The point of this appears to be convenience when transfering from another system to odoo and pulling the latest invoice number they had. The main downside of this feature is that creating the first record now
has around 11 API calls returning the same value due to different onchanges on the record.

  The main calls come from `_compute_name` in the base account module but the rest are from other methods that use the sequence or call `_compute_name` (like `_onchange_l10n_latam_document_type_id`)

  As this PR is only intended to write tests for the module, the test file matches what occurs in the front-end but future PRs can look into if there are improvements that can be made on stable to simplify this.

task-4714096

Forward-Port-Of: odoo/enterprise#84609
Forward-Port-Of: odoo/enterprise#83553

If you have a company A that has a journal set up with bank synchronization, and a company B that is a branch of company A, you have access to the journal and the bank synchronization (account.online.link) of company A in company B.

This causes an issue when fetching the transactions from the context of company B, as that will create the fetched transactions with a `company_id` set to B, which will cascade on the journal entries and items linked to these transactions.

To ensure the correct company is set on the transactions, we force the company in the context when creating them.

As a result:
- When only company A is selected, transactions are correctly created in company A.
- When both company are selected, no matter if the transactions are fetched from A or B, the transactions are correctly created in company A.
- When only company B is selected, the user is faced with an access error, as Odoo is trying to open a view with the fecthed transaction, which belong to company A.

To prevent this access error, it was decided that the "Fetch Transaction" buttons should not appear when the company owning the bank synchronization is not selected.

A new computed field was then introduced on the account.online.account to check if we should allow fetching given the currenctly selected companies. That field is also added on the account.online.link as a logical conjunction of its account.online.account values of the field.

These fields are then used to decide whether if we show the transaction fetching buttons on the dashboard and on the online link form view.

Another issue with branches is the 'connect bank' button.

With the same configuration as above, let's have companies A and B enabled, with B as the selected company.

If you connect a bank to a journal belonging to company A by clicking on the 'connect bank' button on the dashboard, it will successfully connect, but the account.online.link will belong to company B.
Then, if you try to access the accounting dashboard with only company A enabled, you will be faced with an access error, as the journal from company A tries to diplay informations computed with the above account.online.link of company B.

To prevent this, we only make the 'connect bank' button appear if company A (i.e. the company owning the journal) is selected as the active company.

This did not require a new field, and was done by adding an entry in the dashboard data.

opw-4515862

Forward-Port-Of: odoo/enterprise#83134