There was an unneeded mapped of the initial statements that fetches a lot of
data from statement lines that are not going to be used later, so let's
remove it and optimize a bit the initial opening time.
In a customer database, we have improved the opening time from 120 seconds
to 15.
TT48753
Steps to reproduce the problem:
- Issue an invoice.
- Add a bank statement for paying such invoice.
- Reconcile the statement with the invoice. It gets paid.
- Revert reconciliation from the statement.
- Go again to reconcile the statement line.
Expected behavior: The invoice is available to be reconciled again.
Current behavior: The invoice is not available.
That's because the move line of the AR/AP account was linked to the
statement line in the reconciliation process through the field
`statement_line_id`. That field is used for linking the generated
move lines to the generating statement line, not for other things.
This is probably a bad migration from v13 original code to v14, where
the reconciliation and the datamodel changed.
It includes a migration script that mitigates a bit the problem on
past reconciled invoices, removing such link. It doesn't cover other
AR/AP lines, but at least we keep data consistent for these ones.
TT46644
When getting propositions from the reconcile models, we should
explicitly exclude the amls of the bank statement lines.
If not, we can get a situation where the journal item of the bank
statement line is proposed to itself.
TT45568
When having a statement line in a foreign currency, each resulting
journal item computes the debit/credit amount from the foreign currency
rate, and then rounding the result to company currency digits.
There's a chance in this process that the journal entry final balance
is not 0 summing the rounded balances in company currency.
For fixing this, there can be several strategies, like creating an
extra journal item for the difference, but I have opted for removing
the difference in the latest counterpart aml, so no extra noise and
no need of account decision algorithm for this extra move.
As currency amounts are correct and are the ones used in reconciliation,
there won't be any problem adjusting this amount.
TT45568
There's no need to synchronize business models (payments and statement
lines) when the reconcile is done, as the only value written in
the journal item is `full_reconcile_id`.
This way, we speed up the reconciliation process through the widget.
When coming from previous versions of Odoo, you may have payments
directly done against the bank account. On the reconciliation widget,
they are represented as blue lines.
One possibility is to replace in all these pending entries the bank
account by the outstanding payment/receipt account, but this means to
modify past accounting that may be locked.
So this commit is restoring the ability to reconcile against these blue
lines, although this is a deprecated thing.
Things done:
- Repair the JS widget for informing correctly about the blue lines
to reconcile.
- When having such lines to reconcile, the temporary statement line is
removed, and the payment one is linked.
- When reverting reconciliation of the statement lines linked to
payments, the entry is not removed, just removed the link, and a new
entry is created for the statement line.
TT43713
If the journal destination account is reconcilable, as the journal entry
is pre-generated before reconciling, the line is appearing in the
reconciliation widget, provoking user confusion and error if that one
is selected.
We explicitly exclude in the matching domain for avoiding the problem.
TT42983
Notifications displayed at the start of the reconciliation interface are
back up and running (it was working in v10, broken in v12 and v13).
For example, when you import an OFX file and go directly to the
reconciliation interface, it will display the number of transactions
that were automatically dropped because they were already present in
Odoo (detected via the unique_import_id).
When decimal separator is a dot, it has a special meaning in the regex (any character) that cause problem
For instance in 123.40 the regex will match .4 and remove it.
And then the proposal will be base on the number 120 instead of 123.40
The other problem with the actual regex is that minus sign get removed
In the fix, we start by replacing the decimal_separator by a dot (before it was done after the cleaning) and the clean with a character class that is clearly specified (dot, minus, numbers)
Bug was already present in odoo13 EE and CE
When decimal separator is a dot, it has a special meaning in the regex (any character) that cause problem
For instance in 123.40 the regex will match .4 and remove it.
And then the proposal will be base on the number 120 instead of 123.40
The other problem with the actual regex is that minus sign get removed
In the fix, we start by replacing the decimal_separator by a dot (before it was done after the cleaning) and the clean with a character class that is clearly specified (dot, minus, numbers)
Bug was already present in odoo13 EE and CE
