Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.

When creating a Payment Term, the user can now specifically design an early payment discount through an additional part in the wizard.
This will, amongst other things, allow the user to choose in which way the tax should be computed on the discounted invoice (tax included, excluded, or tax base impacted).
(WIP : belgian taxation - Impact Tax Base - isn't yet functional. At terms, the taxation of the whole invoice should be adapted when an Cash Discount is st within a payment term. This option should only be available on the belgian localization. )

The discounted amount and the conditions to fulfill are printed below the invoice PDF.

Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.

Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts are also applied.

Related : https://github.com/odoo/odoo/pull/94050

task: 2968644

Linked PR in upgrade:
https://github.com/odoo/upgrade/pull/3886

#### Summary
Add fields to the product representing the type and amount of
supplementary units the product represents for intrastat purposes,
replacing the old system of trying to calculate this from the units of
measure on the move lines.

#### Context
In intrastat, supplementary units are a way of describing the quantity
of goods in a way that is more relevant than the default (kilograms) in
the statistical context in which the data is utilised.

For instance, when measuring the passage of commodity:

code: 93012000
description: "Rocket launchers; flame-throwers; grenade launchers;
torpedo tubes and similar projectors"

the supplementary unit is "p/st", meaning unit (rather than kilograms).
Which is to say, that when you're selling rocket launchers;
flame-throwers, grenade launchers, etc to other European countries, the
EU it's more statistically relevant to discuss the number of units sold
than the weight. This is true of a large number of other commodities
which can be measured in other ways (e.g. 100 p/st: by the hundreds of
units, c/k: metric carat, 1000 kWh: thousand kilowatt hours, etc)

#### The Problem
Previously, the problem was that the information regarding the
supplementary units was not included in the report. Since it became a
legal requirement, a solution was created (in stable) that utilised
odoo's units of measure to cover a number of the most common
supplementary units: https://github.com/odoo-dev/enterprise/commit/2fbe4deb2051ca8e8559c8b68c66b0c245668480. However, this is inadequate for a
couple of reasons:
a) It provides little control to the user, who might wish to use units
of measure that are not the same as the supplementary units.
(e.g. Sell flamethrowers by the kilogram, though the supplementary unit
is per 'unit').
b) It doesn't cover the supplementary units for which there isn't a
corresponding category in odoo by default.
(e.g. Sell uncut diamonds, with corresponding supplementary unit:
c/k (metric carat), for which there is no corresponding unit of measure
in odoo).

#### The Solution
The first part of the solution involves adding a field to the
account.intrastat.code model. The field is a selection field called
'supplementary_unit' and represents the supplementary unit for the
commodity code. This also allows us to remove the enormous dictionary
currently representing the relationship between commodity codes and
supplementary units in
account_intrastat/models/supplementary_units_codes.py.

The second part of the solution is to have a field representing the
ratio of the product quantity to the number of supplementary units. This
field is called intrastat_supplementary_unit_amount on the product.product
model. If the currently selected commodity code field has a
supplementary unit associated with it, then the
intrastat_supplementary_unit_amount field is displayed below the
commodity code field. If no supplementary unit is associated with the
commodity code, then the weight field is displayed instead. This is the
case for both the product.product, though the product.template makes use
of a related field that displays the value of the
intrastat_supplementary_unit_amount on the product variant (if the
product variant is a singleton), and is otherwise invisible.

The intrastat_variant_id (commodity code) field has been renamed on the
product.product to intrastat_code_id. The intrastat_id (commodity code)
field is removed from the product category and the product.category
views are removed.

The product template and product variant views are adapted to include
these fields. Additionally, the product template view is adapted to hide
the intrastat fields (including those that weren't introduced in this
commit, i.e. commodity code and origin country) when there is more than
one product variant, similar to the way weight and volume is displayed.

The report is altered so that the SQL query now fetches the
supplementary unit field and performs the logic necessary to calculate
the supplementary unit column.

The quantity is calculated with reference to the reference unit of
measure, and then used to multiply the supplementary unit amount. This
avoids the problem where, for instance, a dozen is used as a unit of
measure, and the quantity is 1. Then the
intrastat_supplementary_unit_amount should be multiplied by 12 rather
than 1.

The _intrastat_fill_supplementary_unit function and references to it are
removed as the logic it performs has been superseded.

The existing tests have been minimally reconfigured to work with the
changes. This simply required adding the values of the
'intrastat_variant_supplementary_unit_amount' field on the
product.product records used in the tests.

task-id: 2884512

It seems in some CAMT files that the rate is sometimes rounded to 4
digits:
```
        <AmtDtls>
          <TxAmt>
            <Amt Ccy="CHF">25805</Amt>
          </TxAmt>
          <CntrValAmt>
            <Amt Ccy="EUR">25000</Amt>
            <CcyXchg>
              <SrcCcy>CHF</SrcCcy>
              <TrgtCcy>EUR</TrgtCcy>
              <XchgRate>0.9688</XchgRate>
            </CcyXchg>
          </CntrValAmt>
        </AmtDtls>
```

While the real computed rate would be: 25000/25805 = 0.968804495

This leads to a rounding issue:
25805 * 0.9688 = 24999.88 while we should have 25000.

We also faced another example with a batch payment and large amounts
with a rate rounded to 4 digits:

```
                <Amt Ccy="CHF">19736.93</Amt>
                <AmtDtls>
                    <TxAmt>
                        <Amt Ccy="EUR">19946.37</Amt>
                        <CcyXchg>
                            <SrcCcy>EUR</SrcCcy>
                            <TrgtCcy>CHF</TrgtCcy>
                            <XchgRate>0.9895</XchgRate>
                        </CcyXchg>
                    </TxAmt>
                </AmtDtls>
                <NtryDtls>
                    <Btch>
                        <NbOfTxs>3</NbOfTxs>
                    </Btch>
                    <TxDtls>
                        <Amt Ccy="EUR">21.85</Amt>
                    </TxDtls>
                    <TxDtls>
                        <Amt Ccy="EUR">19717.52</Amt>
                    </TxDtls>
                    <TxDtls>
                        <Amt Ccy="EUR">207</Amt>
                    </TxDtls>
                </NtryDtls>
```

This leads also to a rounding issue:
21.85 * 0.9895 = 21.62
19717.52 * 0.9895 = 19510.49
207 * 0.9895 = 204.83

21.62 + 19510.49 + 207 = 19736.94 while we should have 19736.93.

In this second case, we do not have the single transaction amount in
journal's currency directly, and we need to look at batch level to
retrieve the globalized amount in journal's currency to compute the
correct rate.

We should handle these cases properly to avoid forcing the user to
manually modify the retrieved amount after.

Forward-Port-Of: odoo/enterprise#31312
Forward-Port-Of: odoo/enterprise#30121

To reproduce the issue:
(Let WH01 be the main warehouse)
1. Create a second warehouse WH02
2. Edit WH01:
    - Resupply From: WH02
3. Edit the resupply route of WH01:
    - Edit the rule from InterWH Transit to WH01/input
        - Lead time: 1
4. Create a storable product P:
    - Type: Storable
    - Routes: "WH01: Supply... from WH02"
5. Add P on MPS view and enable the row "Actual Replenishment"
6. Set a positive replenish quantity for P (not in the first interval)
7. Replenish P

Error: The actual replenishment is updated on the previous interval. It
should be on the interval defined at step 6.

When computing the date of an incoming stock move, we get and use the
delay of its dest moves but we don't consider the delay of the move
itself.

Moreover, `_get_dest_moves_delay` handles the case where a SM does not
have any dest move, so `_get_moves_and_date` can be simplified

OPW-2906741

Forward-Port-Of: odoo/enterprise#31274
Forward-Port-Of: odoo/enterprise#31067

Steps to reproduce the bug:
- Have companies A and B
- Select company A as current company and B as allowed company
- Go to barcode app > Operations > Select receipts of the company B
- Try to create a new picking

Problem:
An access error is triggered because we access company B data while only
company A is in the allowed companies.

When we get the record `stock.picking`, we make sure that the value of
`env.company` is correct with the `with_company`, but this function will
also redefine the authorized companies with the context key
`allowed_company_ids`, Except that this key is not present in the
context of the record. So`with_company` will define "company A" as the
current company (correct) but as the only authorized company
(incorrect):
https://github.com/odoo/odoo/blob/4c611efa959f8b856ef4ba1a16df664acd0cfecf/odoo/models.py#L5283-L5293

Instead, we can define the allowed companies with the `with_context`
function. The ORM will be able to deduce the current company:
https://github.com/odoo/odoo/blob/e902713648bca329e6821859462b2128aad62c09/odoo/api.py#L639

opw-2926638

Forward-Port-Of: odoo/enterprise#31068