Problem: The journal dashboard show wrong values for the late invoices.
Details:
The filter for the "Late" invoices is this:
```xml
                    <filter name="late" string="Overdue" domain="['&amp;', ('invoice_date_due', '&lt;', time.strftime('%%Y-%%m-%%d')), ('state', '=', 'posted'), ('invoice_payment_state', '=', 'not_paid')]" help="Overdue invoices, maturity date passed"/>
```
But the SQL query in the background of the journal dashboard filters for a different date field:
```sql
SELECT
                    (CASE WHEN type IN ('out_refund', 'in_refund') THEN -1 ELSE 1 END) * amount_residual AS amount_total,
                    currency_id AS currency,
                    type,
                    invoice_date,
                    company_id
                FROM account_move move
                WHERE journal_id = %s
                AND date <= %s
                AND state = 'posted'
                AND invoice_payment_state = 'not_paid'
                AND type IN ('out_invoice', 'out_refund', 'in_invoice', 'in_refund', 'out_receipt', 'in_receipt');
```

Solution:
Need to change the date field in the SQL code.

Journal dashboard before:
![before](https://user-images.githubusercontent.com/210099/97556287-8da60f00-19d9-11eb-8040-b37721b17900.jpg)


After:
![after](https://user-images.githubusercontent.com/210099/97556299-91d22c80-19d9-11eb-913a-e4ab45eaffd5.jpg)

Hint: the late counter is not in the default dashboard, but i put it there with a modification:
```xml
<xpath expr="//t[@id='account.JournalBodySalePurchase']/div[2]" position="inside">
                    <t t-if="journal_type == 'sale'">
                        <div class="row">
                            <div class="col-7">
                                <a type="object" name="open_action" context="{'search_default_late': '1'}">
                                    <span title="Late Invoices"><t t-esc="dashboard.number_late"/> Late Invoices</span>
                                </a>
                            </div>
                            <div class="col-5 text-right">
                                <span><t t-esc="dashboard.sum_late"/></span>
                            </div>
                        </div>
                    </t>
            </xpath>
```



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

Forward-Port-Of: odoo/odoo#60956

When getting the remaining days before the deadline of an activity, the
module applies the TZ offset on the deadline date. This leads to
incorrect data.

To reproduce the error:
(Need crm)
1. Configure your computer:
    - TZ: America/Anchorage (UTC-8)
2. Log in DB
3. Ensure user's profile has the correct TZ
4. Create a lead
5. Schedule an activity A:
    - To Do
    - Due Date: tomorrow
6. CRM > Sales > My Activities

Error: The deadline of A is "Today" instead of "Tomorrow"

To get the days difference, the module computes the current date in
user's TZ. Then, it takes the deadline value and applies the offset
between UTC and user's TZ to this deadline value. Eventually, it
compares the two dates.

Here is the problem: the deadline is a date, not a datetime. As a
result, when applying the offset, if the user's TZ is a "negative" one
(UTC-...), it will change the date to the previous day.

For instance, suppose current date is 2021/08/06. In above use case, the
deadline is 2021/08/07. When comparing the dates, the deadline
(2021/08/07 00:00:00) becomes 2021/08/06 16:00:00 (because we are
UTC-8), thus the module will display "Today".

We shouldn't add any offset on a date field.

OPW-2448835

Forward-Port-Of: odoo/odoo#74820

Previous fix commit 5e34a02 was too aggressive in when it would delete
the move_finished_ids. In certain use cases it would result in no
move_finished_ids and a corrupted MO:

Steps to reproduce:
1. Create a new MO
2. Save the MO (do NOT confirm)
3. Update the qty to product_qty (qty to produce)
4. Confirm + Mark As Done

End result: "qty to produce must be positive" error whenever MO was
attempted to be completed and MO can never be completed.

To fix this, we split out when the move_finish_ids. They should all
be deleted ONLY when the product to produce is changed. Unfortunately to
cover all cases, we must always wipe the moves whenever the product is
changed (e.g. when changing the product twice with the original product
being the final saved value, we have no way of knowing to keep the
original move_finished_ids due to onchange only being able to check
against the last saved value, not last selected value).

Additional test + test update done to support preventing this
catastrophe in the future.

Part of Task: 2618962

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#74843
Forward-Port-Of: odoo/odoo#74831

“Umsatz” is calculated based on the tax line balance & base amount.
But 100% of this amount is set on each line. So if a same tax is set on lines with
different accounts, the full amount is set once per account, instead of splitting
the total between lines.
Also “BU-Schlüssel” is missing on some lines.
Vendor Bill example :

Product     Account                            Price   Tax
Product 1   3400 Wareneingang 19% Vorsteuer    10      19% Vorsteuer
Product 2   3400 Wareneingang 19% Vorsteuer    30      19% Vorsteuer
Product 3   3980 Bestand Waren 19% Vorsteuer   50      19% Vorsteuer
                                         ---------------------------
                                         Total 97.6 (tax incl)
ERRONEOUS DATEV CSV :
Umsatz (ohne Soll/Haben-Kz)   Konto      BU-Schlüssel
107,1                         34000000
107,1                         39800000   19

RIGHT DATEV CSV :
Umsatz (ohne Soll/Haben-Kz)   Konto      BU-Schlüssel
47,6                          34000000   19
59.5                          39800000   19

This fix splits the total amount based on the move's aml's balances.

Task: 2608222

Forward-Port-Of: odoo/enterprise#20014
Forward-Port-Of: odoo/enterprise#19934