Steps to reproduce:
-------------------
1. From the Purchase app, create a purchase order (don't link it to any project with the project field)
2. Add a line on the PO with a distribution
3. On the line, add the project's analytic account
4. Go to the Project > Top bar > Purchase Orders > The new purchase order is not there

Fix:
-------------------
We should take into account the purchase orders whose lines have an analytic distribution corresponding to the project. We will do a second _read_group() call for that purpose.

- Others fixes: - Still in Purchase app, when changing the project_id of the PO, it changes the analytic distribution of all PO lines (including PO lines with non-empty distribution). To be consistent with SO and SO lines, it should only affect PO lines that do not have their analytic distribution set.

    - In Expenses app, when changing the 'Customer to Reinvoice' field of an expense, it should automatically fill in the analytic distribution of the expense with the account
    of the project of the sale order linked to the 'Customer to Reinvoice'. The problem is that it does not systematically change the analytic distribution if such account exists.

    - When creating an expense from the top bar action, and changing the distribution of the expense (the percentage for instance), it does not get saved on saving the record.

task-4191106
version-18.0

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

Fix the status of invoices when registering a payment. Also improves the portal view depending on the invoice payment state.

The following cases assume that no outstanding account is set on the bank journal

Portal:
 - In case the invoice payment state is 'in payment', the portal should display "Processing payment", the "Next installment" section should be hidden, and a banner should appear in the popup of the payment (when pressing the "Pay Now" button).

Portal list view:
- Same payment state should be displayed as in the portal form view, e.g. "Processing Payment"

Invoice Payment state:
 - If a payment is created for an invoice, then the state of the invoice is set to 'in payment' When the invoice is reconciled, and the payment is manually validated (This manual operation of validating the payment will be made automatically in another task) if the payment corresponds to a portion of the invoice amount, the invoice payment state is 'Partial' if the payment corresponds to the full invoice amount, the invoice payment state is 'Paid' If the payment is rejected, then the invoice payment state is reset If the payment is confirmed (before any reco), then the invoice payment state keeps being "in payment"

 task-4212954

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

[IMP] account_sepa_direct_debit: better sequence of error messages
    
    The check validating the collection date was made before we've checked all mandates are in the right state, yet it depended on the mandates to check the minimum collection date available for this batch. We now make it so we first check all the mandates are valid, for usability.

===================================================

[FIX] account_sepa_direct_debit: Don't crash when validating a batch when the company has no creditor identifier

A check for that already existed in validate_batch, raising an error, but it wasn't called in time, and this caused a traceback because the super call had been moved at the beginning of the function.

===================================================

[IMP] account_sepa_direct_debit: clearer error message

===================================================

    [FIX] account_sepa_direct_debit: don't crash when trying to generate a batch containing a single SDD payment without mandate
    
    To reproduce:
    
    1) Create a payment for some new partner, using SEPA Direct Debit. Make sure no mandate exists for this partner.
    2) Add the payment created in 1 into a new batch. It must be the only payment in it
    3) Try validating the batch
    ====> Traceback
    
    This is because the query checking which mandates are used for the first time receives an empty tuple for its "mandate_ids" parameter. SQL tries to run "... IN ()", which crashes.
    
    After fixing this bug, the same flow still crashes because we're trying to call max() on an empty sequence in validate_batch in order to compute the pre_notification_period. We fix that by adding a new check in order to redirect the user in case some payments of the batch are missing a mandate.