**Current behavior:**
Using auto valuation and anglo saxon accounting, when a project has some profitability report items for auto valued product, the COGS invoice lines will appear under the revenue section rather than the cost section of the project's profitability report.

**Expected behavior:**
COGS lines are shown as costs.

**Steps to reproduce:**
1. Create a service product that generates a project on sale, on the project template set a specific analytic account

2. Create another product with real time valuation and assign the COGS account on the product category's expense account

3. Sell some of the service product and the auto val product in the same order, deliver it -> generate invoice & post it

4. In the project's settings, open the profitability report observe that the invoice line for the cost of goods sold account entry is displayed as a negative revenue, rather than a cost

**Cause of the issue:**
In `sale_project` there is no logic to separate the COGS AMLs from the rest of an invoice's line ids.

**Fix:**
Transform the loop in `_get_revenues_items_from_invoices` https://github.com/odoo/odoo/blob/bb6a4fbb92b1a1a1e13e32b27c4c9f2813570fda/addons/sale_project/models/project.py#L656 into two loops such that the existing one iterates twice.

First iteration collects the `revenues` items data (exactly as it currently does)

Second iteration collects the `costs` items (cogs lines)

And the method will now return a dict of data for both `revenues` report items and `costs` report items (and should be renamed/refactored in master)

opw-4652472

In case of multiple files being imported at the same time (for example, when an email with several attachments was received on a journal mail alias), the previous code was trying to detect if the given files were for the same invoice or not... But it was doing it wrongly and the processing order of attachment mattered, causing a diferent behaviour in one case or another. This bug just enlighted the fact we were trying too hard to do something smart here, where we'd actually don't need it.

So it has been decided to simplify things, and the algorithm will now simply create one invoice per valid attached file. Point. And if people have more complex needs, they should/can install the document app to handle them.

Use case:
* send an email to a mail alias with, attached in this specific order, a PDF (embedding an xml file) and a XLS.
* verify that odoo created 2 invoices, each linked to one of the files
* send an email to the same mail alias, with the same 2 files but attached on the mail in the inverse order: first the XLS and then the PDF
* odoo will create a single invoice, attaching the 2 files to it.

The reason is that
* the embedded XML is always done first
* in case 1 - PDF then XLS 

> Decoding of XML as invoice 1
> Decoding of PDF skipped because embedded XML was already imported as invoice 1 |Decoding of XLS as invoice 2 because the condition
> ```
>       # When receiving multiple files, if they have a different type, we supposed they are all linked
>       # to the same invoice.
>       if (
>           passed_file_data_list
>           and passed_file_data_list[-1]['filename'] != file_data['filename']
>           and passed_file_data_list[-1]['sort_weight'] != file_data['sort_weight']
>       ):
> ```
> 
>   is FALSE: passed_file_data_list[-1]['sort_weight'] == file_data['sort_weight'] == 100

* in case 2 - XLS then PDF 

> Decoding of XML as invoice 1
> Decoding of XLS as invoice 1 skipped because the same condition
> ```
>       # When receiving multiple files, if they have a different type, we supposed they are all linked
>       # to the same invoice.
>       if (
>           passed_file_data_list
>           and passed_file_data_list[-1]['filename'] != file_data['filename']
>           and passed_file_data_list[-1]['sort_weight'] != file_data['sort_weight']
>       ):
> ```
>  is now TRUE: passed_file_data_list[-1]['sort_weight'] == 20 and file_data['sort_weight'] == 100
> Decoding of PDF skipped because the embedded XML was already imported as invoice 1

ticket - 4510745


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

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 currently 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.

opw-4515862