When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.

The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.

With this commit, we allow moves coming from
expense to be taken into account by adding a
check on move.move_type.

opw-3044141

closes odoo/odoo#105023

X-original-commit: 70729dd41cc0050d55758e0fb9ccbed6b06537ea
Signed-off-by: John Laterre (jol) <jol@odoo.com>

closes odoo/odoo#100573

Related: odoo/enterprise#31507
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
  to improve perfs.

_______________________________________________________________________

The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
  `write`
* by saving when switching tabs on the Invoice form, to synchronize
  before showing the values

This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
  intercompany, ...)
* the performance for invoices with many lines improves drastically, going
  from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
  instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
  which was unexpected and needed to be managed manually in all the
  onchange methods

This means that:
* Some fields need to be exclusively computed on journal entries values
  or invoice values, more specifically the Tax Summary widget.
  It is now
    - computed from entry lines, when opening the view
    - computed from invoice lines when changing those, because the tax lines
      will need to be recomputed anyways, erasing previously set values
    - set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
  (i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
  This is because such a behavior was undefined (how is changing the balance going
  to affect the unit price? How is the amount currency going to affect it?)

_______________________________________________________________________

Implementation Details
----------------------

The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.

Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)

By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`

The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.

Performances
------------

You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.

```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
    self.env['account.move'].create([
        {
            'move_type': 'out_invoice',
            'partner_id': random.choice(partners),
            'invoice_line_ids': [
                Command.create({
                    'name': f'line{i}',
                    'product_id': random.choice(products),
                    'tax_ids': [Command.set([random.choice(taxes)])],
                })
                for i in range(nline)
            ]
        }
        for j in range(nmove)
    ])
                                                             # After  | Before
print(timeit("create(1, 1)", globals=globals(), number=1))   # 0.11   | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76   | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56  | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03   | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99   | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44  | 79.55
```

Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)

Why this commit title?
----------------------

Someone told me that this was the perfect way of naming your commits.
c04065ab

task-2711317

closes odoo/odoo#96134

Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>

Task: 2856281

- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed

closes odoo/odoo#93212

Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>

Since 'check_number' is now part of the journal item's label, the account_accountant_check_printing module is no longer necessary.

Task: 2555114
Part-of: odoo/odoo#91448

closes odoo/odoo#87527

Related: odoo/upgrade#3497
Related: odoo/enterprise#26939
Signed-off-by: Raphael Collet <rco@odoo.com>

With this commit, we allow mutliple payments with manual
check printing.

Steps to reproduce:

- With manual check numbering
- Create +=3 vendor bills
- In bills list view, select all bills and register payment
- Select Checks as payment methos, and validate
-> Validation Error: The following numbers are already used ...

Setting the check_numbers before calling the super of
payment.action_post.

opw-2830586

closes odoo/odoo#91128

X-original-commit: c26cd9fa
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>

In some languages and layout the currency symbol might be wrapped in a separate
line, which is not acceptable from accounting point of view. Fix it by replacing
space with a special symbol.

STEPS for v15:
* install MX localization;
* create a Spanish speaking customer
* generate a pdf:
1) Create quotation with products
2) Add IVA 16%tax
3) print a report

BEFORE: the currency symbol is incorrectly displayed on a separate line
AFTER:  currency symbol is always with the amount

---

https://github.com/odoo/odoo/pull/89722


opw-2829138

closes odoo/odoo#90961

X-original-commit: 684687226b87022bc9f9ba7667b295e545100645
Related: odoo/enterprise#27138
Signed-off-by: William André (wan) <wan@odoo.com>

Remove most values uselessly specified because giving the same value as 
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)

* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default

This will reduce noise/inconsistencies between manifests specifications, 
simplify analysis of manifests content, ...

closes odoo/odoo#90209

Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

X-original-commit: 8ad018ca6050435247ae284444108def3828572f
Part-of: odoo/odoo#89157

Fix two issues linked to payment methods and their journal link.

SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.

There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.

opw-2777522

X-original-commit: 0ad8faf3
[FIX] account_*: payment method journal filter

Fix two issues linked to payment methods and their journal link.

SEPA Credit Transfer was marked as only available on EUR journals, but
from what we have been told, and we have seen, it should also be made
available for other currencies (CHF/SEK).
So we are changing the rule used to determine if SEPA Credit Transfer
is available on a journal to allow to use it on journals using CHF or
SEK as a currency.

There is another issue, where the filtering is done differently at the
journal creation and when the user add the payment method manually in
the lists.
The filter rules were not respected at the journal creation, which
would lead to incorrect default inbound and outbound payment method list.
For example, a new journal would have the company currency (let's say,
USD) but still have SEPA Credit Transfer (EUR,CHF,SEK) added on it by
default while it should not be available there.

opw-2777522

closes odoo/odoo#88677

X-original-commit: e2cd91ad8339f73b2547bc839e675443528f3adf
Related: odoo/enterprise#26172
Signed-off-by: Florian Gilbert <flg@odoo.com>

Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608

closes odoo/odoo#88159

X-original-commit: 2f83737b
Signed-off-by: Florian Gilbert <flg@odoo.com>

* Previously, when reconciling  journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.

==== RATIONALE ====

This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:

Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)

..leads to a partial of 120 EUR and min(80, 60) = 60 USD

After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.

2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.

In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.

In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.

==== REFERENCES ====

Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.

github issue: https://github.com/odoo/odoo/issues/37469



closes odoo/odoo#84201

Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Steps to reproduce:

- On bank journal, set at least two manual
  outbound_payment_method_line_ids
- Set a vendor X with manual property_payment_method_id
- Create a Vendor Bill with vendor X, confirm it, and register payment
OR
- Create a payment with outbound method and select vendor X

Issue:

Got a traceback

The reason is we expected one value instead of several.

With this commit, we take the manual payment method with the
highest priority based on its sequence number.

opw-2743110

closes odoo/odoo#86270

X-original-commit: 6235466e
Signed-off-by: William André (wan) <wan@odoo.com>

When install the module on a db with huge amount of account move,
prefetching data when accessing partner_id of first move iteration is
costly and should be avoided.

closes odoo/odoo#84989

X-original-commit: c80700ee
Signed-off-by: William André (wan) <wan@odoo.com>

Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.

Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)

closes odoo/odoo#84280

Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>

The method constraint to validate the Check Number is slow

1. Analyzing the following query:

```sql
SELECT
    payment.check_number,
    move.journal_id
FROM
    account_payment payment
    JOIN account_move move ON move.id = payment.move_id
    JOIN account_journal journal ON journal.id = move.journal_id,
    account_payment other_payment
    JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
    payment.check_number::integer = other_payment.check_number::integer
    AND move.journal_id = other_move.journal_id
    AND payment.id != other_payment.id
    AND payment.id IN (1085159)
    AND move.state = 'posted'
    AND other_move.state = 'posted';
```

The output is:

    Planning Time: 3.354 ms
    Execution Time: 2514.660 ms

Discarding null values

```diff
    AND other_move.state = 'posted';
+    AND payment.check_number IS NOT NULL
+    AND other_payment.check_number IS NOT NULL
```

The output is

    Planning Time: 3.216 ms
    Execution Time: 0.140 ms

2. The constraint is computed even if the payment is not a check (check_number is empty)

Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table

3. The validation to check is it not a number is not optimal

It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again

    python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
        > 1 loop, best of 5: 323 msec per loop

    python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
        > 2 loops, best of 5: 135 msec per loop

It is better but not enough, using `str.isdigit` method is 5x faster than original approach

    python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
        > 5 loops, best of 5: 64 msec per loop

closes odoo/odoo#83851

X-original-commit: 31e0ed8c
Signed-off-by: Olivier Colson <oco@odoo.com>

Taskid: 2703085
Part-of: odoo/odoo#80824
Co-authored-by: Victor Feyens <vfe@odoo.com>

closes odoo/odoo#80181

X-original-commit: efd178da
Related: odoo/enterprise#22439
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#76542

X-original-commit: 63e68074
Related: odoo/enterprise#20882
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.

closes odoo/odoo#74245

Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Define `data-hotkey` on most used action buttons.

For the modals, the following keys are dedicated for "special"
actions:
 - Alt+G: add
 - Alt+V: save
 - Alt+Z: cancel

closes odoo/odoo#73275

Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>

The payment method added by account_check_printing is meant as:

> Preferred payment method when paying this vendor. This is used to
> filter vendor bills by preferred payment method to register payments
> in mass. Use cases: create bank files for batch wires, check runs.

But it may also select the default payment method on an account.payment.

With this changeset, we copy what is done in account.payment to
account.payment.register so the behavior is the same for it.

forward-port of #72655

opw-2508263

X-original-commit: a546e7e870987e882ab2c9a6fa2618476b76fcb8

To improve the payment method system, proceed to a few changes
such as changing the view a bit, making sure payment acquirers are not
linked to a journal by default and that only the manual payment method
type can be used multiple times in a single journal.

Task id #2573145

closes odoo/odoo#73596

X-original-commit: 9122b367baea10e59b66e45bf7c458a6f1e82efb
Related: odoo/enterprise#19623
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Without demo data

closes odoo/odoo#73560

X-original-commit: 802e46541117573e028b711ea33dad9df9075a39
Related: odoo/enterprise#19602
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.

This will allows that.

Task id #2414749

closes odoo/odoo#67331

Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>

Currently, across Odoo, there are around 40+ many2one fields defined with a
'selection' widget. Since the many2one widget has options to limit record
creation and opening, there is no reason to define a many2one field with a
selection widget. The selection widget does not allow for searching, and is
limited to 100 records.

PURPOSE
to update the definition of any many2one on which we applied a 'selection'
 widget, and instead use the standard many2one widget with disabled
opening/creation instead.

after this commit,
for each many2one field defined with widget="selection",  widget="selection" is
replaced with options="{'no_open': True, 'no_create': True}"

Task : 2476488

closes odoo/odoo#68387

Related: odoo/enterprise#17316
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Use Cheque instead of Check (American spelling)

closes odoo/odoo#70196

X-original-commit: 58966deb
Related: odoo/enterprise#18079
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce the bug:

- Let's consider a user U not in group group_system
- Log with U
- Create a vendor payment with payment method Checks
- Print it

Bug:

An access error was raised because U didn't have the rights to write on model ir.sequence

opw:2513014

closes odoo/odoo#70062

X-original-commit: 11376c88
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>